Re: RFR(L): 8151179: address issues raised by JCK team on JEP 274 API

[Michael Haupt]

Hi John,

thank you very much - some comments are inlined below.

> Am 28.09.2016 um 08:26 schrieb John Rose <john.r.r...@oracle.com>:
> 
> Reviewed.  This is a huge leap forward.
> 
> A few small comments to consider:
> 
> In FacLoop, the argument k should be named acc:
> +-  int fin(int i, int k) { return k; }
> ++  int fin(int i, int acc) { return acc; }
> 
> This affects *two* files, a JDE.java and MHs.java.

Fixed.

> Fix awkwardness:  s/A similar same example/A similar example

Fixed.

> I'm really glad to see the FacLoop example, BTW; I think it is often the 
> right pattern to use.
> 
> There is a redundant phrase in the javadoc which reads oddly:
> 
> + A non-void value returned from the body (which must also be of type V) 
> 
> But the previous line just defined V as the return value of the body:
> + If the body handle returns a non-void type V, a leading loop iteration 
> variable of that type is also present. 
> 
> Seems like you can just omit "(which must also be of type V)" or shorten it 
> to "(of type V)" or perhaps "(which is the leading iteration variable)".  In 
> any case, the role of "V" is fully described in the bullet item list that 
> follows.

Right; I've changed this to "(of type V)".

> The whole section beginning "Example. As a consequence of step 1A above" is 
> kind of fluffy.  It doesn't add much, although it is technically correct.  
> You could take it out if you feel the same.  (The fact that the "pred" guys 
> are assumed to take no arguments means that it's a pretty useless loop.)  I 
> don't mind leaving it in, though, in the interests of converging this review 
> process!

I'd rather leave it in; I think I added it at some point in response to a 
clarification request from JCK.

> Thank you for putting in the extra working examples.  That will really help 
> users pick the right patterns.

Yes. It's interesting new API that deserves some examples. ;-)

I'll push shortly, with the aforementioned modifications.

Best,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining

[Michael Haupt]

Hi Claes,

yes please. Thumbs up. :-)

Best,

Michael

> Am 28.09.2016 um 13:48 schrieb Claes Redestad <claes.redes...@oracle.com>:
> 
> Hi,
> 
> as discussed recently on hotspot-compiler-dev[1], having a private class with 
> no default constructor can lead to C2 failing to inline, due to the synthetic 
> bridge constructor using a dummy argument of an uninitialized class. This is 
> really a problem in C2, as well as something which could ultimately be 
> resolved by nestmates...
> 
> However, there is an easy workaround in adding an empty package-private 
> constructor. In the most recently found case - a microbenchmark stressing 
> MethodHandles.iteratedLoop - adding this to ArrayList$Itr lead to a 2.5-3x 
> speedup.
> 
> This is me asking nicely to do a quick-fix for this in 
> java.util.ArrayList$Itr now:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8166840
> Webrev: http://cr.openjdk.java.net/~redestad/8166840/webrev.01/
> 
> Thanks!
> 
> /Claes
> 
> [1] 
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-September/024407.html

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR: 8166287: MultiReleaseJarAPI.isMultiReleaseJar(): failure java.nio.file.AccessDeniedException: custom-mr.jar

[Michael Haupt]

Hi Claes,

thumbs up.

Best,

Michael

> Am 28.09.2016 um 12:56 schrieb Claes Redestad <claes.redes...@oracle.com>:
> 
> Hi,
> 
> recently added test cases to MultiReleaseJarAPI can cause an 
> AccessDeniedException on some Windows systems, and using a distinct name of 
> the jar generated for each test should avoid this.
> 
> webrev: http://cr.openjdk.java.net/~redestad/8166287/webrev.01/
> bug: https://bugs.openjdk.java.net/browse/JDK-8166287
> 
> Since the only hosts I've found where the stars align to cause this issue are 
> some used in our nightly hotspot testing, I intend to push this to jdk9/hs - 
> unless anyone objects.
> 
> Thanks!
> 
> /Claes

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(L): 8151179: address issues raised by JCK team on JEP 274 API

[Michael Haupt]

Hello,

reviews, please ... ?

Thanks,

Michael

> Am 26.09.2016 um 21:01 schrieb Michael Haupt <michael.ha...@oracle.com>:
> 
> Hi John, all,
> 
> thank you very much for your reviews - may I ask for a second round?
> 
> The updated webrev is at 
> http://cr.openjdk.java.net/~mhaupt/8151179/webrev.01/ 
> <http://cr.openjdk.java.net/~mhaupt/8151179/webrev.01/>;
> an accompanying specdiff, at 
> http://cr.openjdk.java.net/~mhaupt/8151179/specdiff.01/ 
> <http://cr.openjdk.java.net/~mhaupt/8151179/specdiff.01/>.
> 
> Thanks,
> 
> Michael
> 
>> Am 16.08.2016 um 01:39 schrieb John Rose <john.r.r...@oracle.com>:
>> 
>> I'm working on this.  The javadoc has some re-filling which creates lots of 
>> diffs of whitespace only, which makes things go a little slower.
>> 
>> I am trying to like the cleaner, more restricted semantics for the utility 
>> methods, but they really do some harm to the use cases.  The really notable 
>> change is the loss of defaulting behavior of the first parameter to 
>> iteratedLoop, which was List::iterator.  That was intended to corresponding 
>> to the for-each syntax, and it is hard (and probably non-performant) to ask 
>> the user to rebuild a MH for Iterable::iterator at each use site for 
>> iteratedLoop.
>> 
>> — John
> 
> 
> -- 
> 
> <http://www.oracle.com/>
> Dr. Michael Haupt | Principal Member of Technical Staff
> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
> Oracle Java Platform Group | LangTools Team | Nashorn
> Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, 
> Germany
> 
> ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
> München
> Registergericht: Amtsgericht München, HRA 95603
> 
> Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
> 3543 AS Utrecht, Niederlande
> Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
> Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
> <http://www.oracle.com/commitment>Oracle is committed to developing 
> practices and products that help protect the environment
> 

Re: RFR(L): 8151179: address issues raised by JCK team on JEP 274 API

[Michael Haupt]

Hi John, all,

thank you very much for your reviews - may I ask for a second round?

The updated webrev is at http://cr.openjdk.java.net/~mhaupt/8151179/webrev.01/ 
<http://cr.openjdk.java.net/~mhaupt/8151179/webrev.01/>;
an accompanying specdiff, at 
http://cr.openjdk.java.net/~mhaupt/8151179/specdiff.01/ 
<http://cr.openjdk.java.net/~mhaupt/8151179/specdiff.01/>.

Thanks,

Michael

> Am 16.08.2016 um 01:39 schrieb John Rose <john.r.r...@oracle.com>:
> 
> I'm working on this.  The javadoc has some re-filling which creates lots of 
> diffs of whitespace only, which makes things go a little slower.
> 
> I am trying to like the cleaner, more restricted semantics for the utility 
> methods, but they really do some harm to the use cases.  The really notable 
> change is the loss of defaulting behavior of the first parameter to 
> iteratedLoop, which was List::iterator.  That was intended to corresponding 
> to the for-each syntax, and it is hard (and probably non-performant) to ask 
> the user to rebuild a MH for Iterable::iterator at each use site for 
> iteratedLoop.
> 
> — John


-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(L): 8161211: better inlining support for loop bytecode intrinsics

[Michael Haupt]

Hi John,

thank you for your review. Comments on your suggestions are inlined.

> Am 22.09.2016 um 20:04 schrieb John Rose <john.r.r...@oracle.com>:
> On Sep 22, 2016, at 12:23 AM, Michael Haupt <michael.ha...@oracle.com 
> <mailto:michael.ha...@oracle.com>> wrote:
>> The new webrev is at http://cr.openjdk.java.net/~mhaupt/8161211/webrev.01/ 
>> <http://cr.openjdk.java.net/~mhaupt/8161211/webrev.01/>; please review.
> 
> 
> Suggestion:  Filter all loop clause functions with ".asFixedArity" when you 
> wrap up the constant array.
> This will do two things:  1. double-check for nulls (which @Stable doesn't 
> like) and 2. allow you to
> omit all asFixedArity calls from the driver function (MHI.loop).  The 
> asFixedArity normalization could
> move into MethodHandles.java, in fact, since that's part of the advertised 
> semantics (hmm, right?).

The double-checking for nulls is not strictly required, as none of the handles 
in any of the loop clauses will be null at the point the call to 
MethodHandleImpl.makeLoop() is made. I still like the idea of moving these 
calls out of the driver and will apply it. I'm applying the same transformation 
to the tryFinally combinator.

> Also (this is a nit) consider commoning (binding a temp for) the three 
> expressions 'init[i]' in the driver.
> I noticed that while peeking at the asFixedArity calls.  The JIT will DTRT 
> here, but we might as well
> make its job a bit easier.  JITs enjoy little favors like that; they are less 
> likely to drop optimizations.

Agreed.

With the performance measurements showing no difference, I'm going to push with 
these modifications.

Best,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(L): 8161211: better inlining support for loop bytecode intrinsics

[Michael Haupt]

 167.619





> Am 20.09.2016 um 21:54 schrieb John Rose <john.r.r...@oracle.com>:
> 
> There should also be an assert in the new LF constructor, which ensures that 
> the two
> arguments are congruent.  Better yet, just supply one argument (the 
> speciesData),
> and derive the MT.  These new LFs are pretty confusing, and it's best to nail 
> down
> unused degrees of freedom.
> 
> — John
> 
> P.S.  I would have expected this problem to be solved by having the 
> MHI.toArray function
> return a box object with a single @Stable array field.  Did that approach 
> fail?
> 
> I.e., this wrapper emulates a frozen array (until that happy day when we have 
> real
> frozen arrays):
> 
> class ArrayConstant {
>  private final @Stable T[] values;
>  public ArrayConstant(T[] values) {
>for (T v : values)  Objects.requireNonNull(v);
>this.values = values.clone();
>  }
>  public T get(int i) { return values[i]; }
>  //public int length() { return values.length; }
> }
> 
> The JIT should be able to constant fold through ac.get(i) whenever ac and i 
> are constants.
> 
> On Sep 20, 2016, at 8:17 AM, Vladimir Ivanov <vladimir.x.iva...@oracle.com> 
> wrote:
>> 
>> Looks good.
>> 
>> src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java:
>> +LambdaForm bmhArrayForm(MethodType type, BoundMethodHandle.SpeciesData 
>> speciesData) {
>> +int size = type.parameterCount();
>> +Transform key = Transform.of(Transform.BMH_AS_ARRAY, size);
>> +LambdaForm form = getInCache(key);
>> +if (form != null) {
>> +return form;
>> +    }
>> 
>> Please, add an assert to ensure the cached LF has the same constraint as 
>> requested (speciesData).
>> 
>> Best regards,
>> Vladimir Ivanov
>> 
>> On 9/20/16 3:53 PM, Michael Haupt wrote:
>>> Dear all,
>>> 
>>> please review this change.
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161211
>>> Webrev: http://cr.openjdk.java.net/~mhaupt/8161211/webrev.00/
>>> 
>>> The method handle loop combinators introduced with JEP 274 were originally 
>>> not intrinsified, leading to poor performance as compared to a pure-Java 
>>> baseline, but also to handwired method handle combinations. The intrinsics 
>>> introduced with 8143211 [1] improved on the situation somewhat, but still 
>>> did not provide good inlining opportunities for the JIT compiler. This 
>>> change introduces a usage of BoundMethodHandles as arrays to carry the 
>>> various handles involved in loop execution.
>>> 
>>> Extra credits to Vladimir Ivanov, who suggested the BMH-as-arrays approach 
>>> in the first place, and Claes Redestad, who suggested to use LambdaForm 
>>> editing to neatly enable caching. Thanks!
>>> 
>>> Performance improves considerably. The table below reports scores in ns/op. 
>>> The "unpatched" column contains results from before applying the patch for 
>>> 8161211; the "patched" column, from thereafter.
>>> 
>>> The create benchmarks measure the cost of loop handle creation. The 
>>> baseline and baselineMH benchmarks measure the cost of running a pure Java 
>>> and handwired method handle construct.
>>> 
>>> Relevant comparisons include loop combinator results versus baselines, and 
>>> versus unpatched loop combinator results. For the latter, there are 
>>> significant improvements, except for the creation benchmarks (creation has 
>>> a more complex workflow now). For the former, it can be seen that the 
>>> BMH-array intrinsics generally perform better than handwired handle 
>>> constructs, and have moved much closer to.
>>> 
>>> Thanks,
>>> 
>>> Michael
>>> 
>>> 
>>> 
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8143211
>>> 
>>> 
>>> 
>>> Benchmark   (iterations) 
>>> unpatchedpatched
>>> MethodHandlesCountedLoop.Create.create3 N/A  
>>> 16039.10818400.405
>>> MethodHandlesCountedLoop.Create.create4 N/A  
>>> 15621.95917924.696
>>> MethodHandlesCountedLoop.Invoke.baseline3   02.858  
>>>   2.839
>>> MethodHandlesCountedLoop.Invoke.baseline3   15.125  
>>>   5.164
>>> MethodHandlesCountedLoop.Invoke.baseline

Re: MethodHandle loop body parameters and Stream.reduce accumulator parameters are not in the same order

[Michael Haupt]

Hi Rémi,

I think you can stay tuned for the fix to JDK-8151179; part of what it 
addresses is just this. The changes are currently in the CCC loop but should 
come up for public re-review soon.

Best,

Michael

> Am 14.09.2016 um 15:19 schrieb Remi Forax <fo...@univ-mlv.fr>:
> 
> Hi everybody,
> i've just found that the parameters of the body (a MethodHandle) of 
> MethodHandles.countedLoop (both overloads) and iteratedLoop are not in the 
> same order as the accumulator in methods Stream.reduce, given that they 
> conceptually represent the same thing, i think the first two parameters of 
> body should be swapped in countedLoop and iteratedLoop.
> 
> in Stream:
>  U reduce(U identity,
> BiFunction<U,? super T,U> accumulator,
> BinaryOperator combiner)
> so this is equivalent to value = accumulator(value, element)
> 
> In MethodHandles:
>   MethodHandle iteratedLoop(MethodHandle iterator,
> MethodHandle init,
> MethodHandle body)
>  with value = body(element, value, iterable)
> it should be
>  value = body(value, element, iterable).
> 
> Same things for 
>   MethodHandle countedLoop(MethodHandle start,
>MethodHandle end,
>MethodHandle init,
>MethodHandle body)  
>  it should be
>value = body(value, index, array); 
>  instead of
>value = body(index, value, array);
> 
> the other loop combinators do not be to be changed.
> 
> cheers,
> Rémi
> ___
> mlvm-dev mailing list
> mlvm-...@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

RFR(L): 8161211: better inlining support for loop bytecode intrinsics

[Michael Haupt]

791 
  7.153
MethodHandlesDoWhileLoop.Invoke.doWhileLoop 10   158.985
  16.990
MethodHandlesDoWhileLoop.Invoke.doWhileLoop 100  1391.746   
  130.946
MethodHandlesIteratedLoop.Create.create N/A  13547.499  
  15478.542
MethodHandlesIteratedLoop.Invoke.baseline   02.973  
  2.980
MethodHandlesIteratedLoop.Invoke.baseline   16.771  
  6.658
MethodHandlesIteratedLoop.Invoke.baseline   10   14.955 
  14.955
MethodHandlesIteratedLoop.Invoke.baseline   100  81.842 
  82.582
MethodHandlesIteratedLoop.Invoke.baselineMH 014.893 
  14.668
MethodHandlesIteratedLoop.Invoke.baselineMH 120.998 
  21.304
MethodHandlesIteratedLoop.Invoke.baselineMH 10   73.677 
  72.703
MethodHandlesIteratedLoop.Invoke.baselineMH 100  613.913
  614.475
MethodHandlesIteratedLoop.Invoke.iteratedLoop   033.583 
  9.603
MethodHandlesIteratedLoop.Invoke.iteratedLoop   182.239 
  14.433
MethodHandlesIteratedLoop.Invoke.iteratedLoop   10   448.356
  38.650
MethodHandlesIteratedLoop.Invoke.iteratedLoop   100  4189.034   
  279.779
MethodHandlesLoop.Create.create N/A  15505.970  
  17559.399
MethodHandlesLoop.Invoke0.baseline  13.179  
  3.181
MethodHandlesLoop.Invoke0.baseline  10   5.952  
  6.115
MethodHandlesLoop.Invoke0.baseline  100  50.942 
  50.943
MethodHandlesLoop.Invoke0.loop  146.454 
  5.353
MethodHandlesLoop.Invoke0.loop  10   514.230
  8.487
MethodHandlesLoop.Invoke0.loop  100  5166.251   
  52.188
MethodHandlesLoop.Invoke1.loop  134.321 
  5.277
MethodHandlesLoop.Invoke1.loop  10   430.839
  8.481
MethodHandlesLoop.Invoke1.loop  100  4095.302   
  52.206
MethodHandlesTryFinally.baselineExceptional N/A  3.005  
  3.002
MethodHandlesTryFinally.baselineMHExceptional   N/A  166.316
  166.087
MethodHandlesTryFinally.baselineMHNormalN/A  9.337  
  9.276
MethodHandlesTryFinally.baselineNormal  N/A  2.696  
  2.683
MethodHandlesTryFinally.create  N/A  406.255
  406.594
MethodHandlesTryFinally.invokeTryFinallyExceptional N/A  154.121
  154.692
MethodHandlesTryFinally.invokeTryFinallyNormal  N/A  5.350  
  5.334
MethodHandlesWhileLoop.Create.createN/A  12214.383  
  14503.515
MethodHandlesWhileLoop.Invoke.baseline  03.886  
  3.888
MethodHandlesWhileLoop.Invoke.baseline  15.379  
  5.377
MethodHandlesWhileLoop.Invoke.baseline  10   16.000 
  16.201
MethodHandlesWhileLoop.Invoke.baseline  100  142.066
  143.338
MethodHandlesWhileLoop.Invoke.baselineMH011.028 
  11.012
MethodHandlesWhileLoop.Invoke.baselineMH121.269 
  21.159
MethodHandlesWhileLoop.Invoke.baselineMH10   97.493 
  97.656
MethodHandlesWhileLoop.Invoke.baselineMH100  887.579
  886.532
MethodHandlesWhileLoop.Invoke.whileLoop 024.829 
  7.108
MethodHandlesWhileLoop.Invoke.whileLoop 146.039 
  8.573
MethodHandlesWhileLoop.Invoke.whileLoop 10   240.963
  21.088
MethodHandlesWhileLoop.Invoke.whileLoop 100  2092.671   
  159.016



-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 

Re: RFR: 8164451: Generate all zero and identity forms at link time

[Michael Haupt]

Hi Claes,

thumbs up.

Best,

Michael

> Am 19.08.2016 um 12:08 schrieb Claes Redestad <claes.redes...@oracle.com>:
> 
> Hi,
> 
> after the internal improvements in JDK-8164451, adding pre-generation of zero
> and identity forms turns out to be very trivial.
> 
> Webrev: http://cr.openjdk.java.net/~redestad/8164451/webrev.01/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8164451
> 
> This removes runtime generation of 2 classes from the test in JDK-8086045, 
> leaving
> only 2 generated forms to deal with to get down to no(!) bytecode generation
> during java.lang.invoke bootstrap.
> 
> Thanks!
> 
> /Claes

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

RFR(S): 8164102: MethodHandles.countedLoop/4 works incorrect for start/end = Integer.MAX_VALUE

[Michael Haupt]

Dear all,

please review this fix.
Bug: https://bugs.openjdk.java.net/browse/JDK-8164102
Webrev: http://cr.openjdk.java.net/~mhaupt/8164102/webrev.00/

The countedLoop implementation would yield loops with wrong iteration counts if 
start and end values around the fringes of the int value space were chosen. The 
fix - passing the decremented counter value to the predicate as well as the 
body - is temporary, as a larger overhaul of the JEP 274 API is under way as 
part of the fix to JDK-8151179.

Thanks,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR: 8164044: Generate corresponding simple DelegatingMethodHandles when generating a DirectMethodHandle

[Michael Haupt]

Hi Claes,

thumbs up.

Best,

Michael

> Am 17.08.2016 um 23:33 schrieb Claes Redestad <claes.redes...@oracle.com>:
> 
> Hi,
> 
> please review this change which adds pre-generation of simple 
> DelegatingMethodHandles corresponding to the DirectMethodHandles we already 
> pre-generate during linking.
> 
> webrev: http://cr.openjdk.java.net/~redestad/8164044/webrev.02/
> bug: https://bugs.openjdk.java.net/browse/JDK-8164044
> 
> This also includes some cleanup suggested by Vladimir during internal review, 
> such as:
> 
> - adding an enum to control this behavior, which allows removing the special 
> version of LF.compileToBytecode introduced by JDK-8163369
> - refactored resolution of pregenerated code to the InvokerBytecodeGenerator
> - removing reliance on the LF.debugName (which we have some loose ideas to 
> remove from LF and tuck away in a map we only create and initialize when 
> actually debugging).
> 
> This patch removes 11 out of the 39 classes generated on first use of the 
> StringConcatFactory in a simple test, amounting to a ~10ms speedup on my 
> machine.
> 
> Thanks!
> 
> /Claes

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(L): 8151179: address issues raised by JCK team on JEP 274 API

[Michael Haupt]

... anyone, please? :-)

Thanks,

Michael

> Am 12.08.2016 um 02:27 schrieb Michael Haupt <michael.ha...@oracle.com>:
> 
> Dear all,
> 
> please review this change.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8151179
> Webrev: http://cr.openjdk.java.net/~mhaupt/8151179/webrev.00/
> 
> The change addresses concerns about the JEP 274 API that were raised by the 
> JCK team. One consequence is that the convenience wrappers for the generic 
> loop combinator are now somewhat restrictive about the handles passed to them 
> as arguments. They have to be created with the appropriate matching 
> signatures. This minor inconvenience is easily overcome by utilising 
> available API such as MethodHandles.constant(), .empty(), or .dropToMatch(). 
> In case the full handle signature inference power is desired, the generic 
> loop combinator, MethodHandles.loop(), still provides this.
> 
> Most of the changes affect the API documentation, but the behavioural changes 
> in some of the methods also reflect on the pertaining tests.
> 
> Thanks,
> 
> Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR: 8163946: java/lang/String/concat/WithSecurityManager.java fails after 8163878

[Michael Haupt]

Hi Claes,

thumbs up. Fix those tests. :-)

Best,

Michael

> Am 12.08.2016 um 05:55 schrieb Claes Redestad <claes.redes...@oracle.com>:
> 
> Hi,
> 
> changing to use GetPropertyAction in MethodHandleImpl unexpectedly caused a 
> nasty bootstrap issue. Moving the MAX_ARITY constant to MethodHandleStatics 
> avoids the issue and might be sensible to do regardless.
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8163946
> webrev: http://cr.openjdk.java.net/~redestad/8163946/webrev.01/
> 
> Thanks!
> 
> /Claes

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

RFR(L): 8151179: address issues raised by JCK team on JEP 274 API

[Michael Haupt]

Dear all,

please review this change.
Bug: https://bugs.openjdk.java.net/browse/JDK-8151179
Webrev: http://cr.openjdk.java.net/~mhaupt/8151179/webrev.00/

The change addresses concerns about the JEP 274 API that were raised by the JCK 
team. One consequence is that the convenience wrappers for the generic loop 
combinator are now somewhat restrictive about the handles passed to them as 
arguments. They have to be created with the appropriate matching signatures. 
This minor inconvenience is easily overcome by utilising available API such as 
MethodHandles.constant(), .empty(), or .dropToMatch(). In case the full handle 
signature inference power is desired, the generic loop combinator, 
MethodHandles.loop(), still provides this.

Most of the changes affect the API documentation, but the behavioural changes 
in some of the methods also reflect on the pertaining tests.

Thanks,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR: 8163878: Remove unnecessary bridge methods, allocations in java.lang.invoke

[Michael Haupt]

Hi Claes,

thumbs up - I'd appreciate if Aleksey could take a glance at the changes in the 
String concatenation logic though.

Best,

Michael

> Am 11.08.2016 um 10:55 schrieb Claes Redestad <claes.redes...@oracle.com>:
> 
> Hi,
> 
> while further untangling the bootstrap of java.lang.invoke I found a number 
> of trivial/minor/small contrivances, including:
> 
> - calling of private methods and constants in parent classes generates and 
> heavily exercise synthetic bridge methods; carefully making more of these 
> package-private cleans the air
> - use of MethodType.parameterList() and .subList() pull in extra classes in 
> places I missed during JDK-8163370 analysis; preferring 
> parameterType/parameterCount/Arrays.copyOf also reduces allocations
> - removed some pointless bookkeeping and duplicate checks of constant 
> placeholders in InvokerBytecodeGenerator
> - since I was already changing around in StringConcatFactory I reworked some 
> changes I made during JDK-8163370 that proved controversial
> 
> Webrev: http://cr.openjdk.java.net/~redestad/8163878/webrev.01/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8163878
> 
> All in all -45K executed bytecodes and 9 fewer loaded classes in my favored 
> startup test.
> 
> Thanks!
> 
> /Claes

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR: 8163814: JDK build has been failing after 8163373

[Michael Haupt]

Hi Claes,

thumbs *way* up.

Thanks,

Michael

> Am 10.08.2016 um 13:58 schrieb Claes Redestad <claes.redes...@oracle.com>:
> 
> Hi,
> 
> missed adding 
> src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java to 
> the outgoing changeset for 8163373, breaking the build.
> 
> Please approve pushing it under this bug ID ASAP: 
> http://cr.openjdk.java.net/~redestad/8163373/webrev.02/src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java.html
> 
> Thanks, and sorry
> 
> /Claes
> 

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(S): 8161212: Test times out: java/lang/invoke/LoopCombinatorLongSignatureTest.java

[Michael Haupt]

Hi Claes,

thank you. Of course you're right about the -run option; I've replaced this 
with a -D interface and pushed that version.

Best,

Michael

> Am 18.07.2016 um 12:57 schrieb Claes Redestad <claes.redes...@oracle.com>:
> 
> Hi,
> 
> On 2016-07-13 15:12, Michael Haupt wrote:
>> Dear all,
>> 
>> please review this fix.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161212
>> Webrev: http://cr.openjdk.java.net/~mhaupt/8161212/webrev.00/
> 
> fix looks OK, but I'm genuinely curious about best practice when it comes to 
> pass arguments to jtreg tests. How do I even pass -run to the actual test?
> 
> Naively System properties seems easier and possibly less fragile (assuming 
> tests aren't run with a very strict security policy somewhere so that we'd 
> have to pair the test with the associated permissions):
> 
> jtreg ... -Djava.lang.invoke.LoopCombinatorLongSignatureTest.run 
> java/lang/invoke/LoopCombinatorLongSignatureTest.java
> 
> boolean run = 
> System.getProperty("java.lang.invoke.LoopCombinatorLongSignatureTest.run") != 
> null;
> 
> Thanks!
> 
> /Claes
> 
>> 
>> Running the test in LambdaForm interpretation mode takes a long time. As the 
>> test is actually about capturing excessively long loop clause lists, running 
>> the constructed loop should be optional. The fix disables running the loop 
>> by default and introduces a -run option that can be used if the loop should 
>> actually be run.
>> 
>> Thanks,
>> 
>> Michael
>> 
> 

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

RFR(S): 8161212: Test times out: java/lang/invoke/LoopCombinatorLongSignatureTest.java

[Michael Haupt]

Dear all,

please review this fix.
Bug: https://bugs.openjdk.java.net/browse/JDK-8161212
Webrev: http://cr.openjdk.java.net/~mhaupt/8161212/webrev.00/

Running the test in LambdaForm interpretation mode takes a long time. As the 
test is actually about capturing excessively long loop clause lists, running 
the constructed loop should be optional. The fix disables running the loop by 
default and introduces a -run option that can be used if the loop should 
actually be run.

Thanks,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR 8160885 Unsafe.compareAndExchangeDouble/FloatAcquire should defer to compareAndExchangeLong/IntAcquire

[Michael Haupt]

Hi Paul,

thumbs up.

Best,

Michael

> Am 07.07.2016 um 12:06 schrieb Paul Sandoz <paul.san...@oracle.com>:
> 
> Hi,
> 
> Please review the simple patch below.
> 
> As spotted by Andrew Haley the Unsafe.compareAndExchangeDouble/FloatAcquire 
> methods were incorrectly deferring to compareAndExchangeLong/IntVolatile 
> rather than compareAndExchangeLong/IntAcquire. Other, related, double/float 
> Unsafe methods defer correctly to the long/int variants.
> 
> Thanks,
> Paul.
> 
> diff -r 7ca81adc8bad src/java.base/share/classes/jdk/internal/misc/Unsafe.java
> --- a/src/java.base/share/classes/jdk/internal/misc/Unsafe.java   Wed Jul 
> 06 17:38:29 2016 +0200
> +++ b/src/java.base/share/classes/jdk/internal/misc/Unsafe.java   Wed Jul 
> 06 19:08:55 2016 +0200
> @@ -1709,9 +1709,9 @@
> public final float compareAndExchangeFloatAcquire(Object o, long offset,
>   float expected,
>   float x) {
> -int w = compareAndExchangeIntVolatile(o, offset,
> -  
> Float.floatToRawIntBits(expected),
> -  Float.floatToRawIntBits(x));
> +int w = compareAndExchangeIntAcquire(o, offset,
> + 
> Float.floatToRawIntBits(expected),
> + Float.floatToRawIntBits(x));
> return Float.intBitsToFloat(w);
> }
> 
> @@ -1793,9 +1793,9 @@
> public final double compareAndExchangeDoubleAcquire(Object o, long offset,
> double expected,
> double x) {
> -long w = compareAndExchangeLongVolatile(o, offset,
> -
> Double.doubleToRawLongBits(expected),
> -
> Double.doubleToRawLongBits(x));
> +long w = compareAndExchangeLongAcquire(o, offset,
> +   
> Double.doubleToRawLongBits(expected),
> +           
> Double.doubleToRawLongBits(x));
> return Double.longBitsToDouble(w);
> }
> 

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(S): 8160717: MethodHandles.loop() does not check for excessive signature

[Michael Haupt]

Hi Claes, Paul, Andrej,

thank you very much for your reviews. I've added lazy initialisation. This is 
the change I'm going to push: 
http://cr.openjdk.java.net/~mhaupt/8160717/webrev.02/

Best,

Michael

> Am 06.07.2016 um 16:31 schrieb Claes Redestad <claes.redes...@oracle.com>:
> 
> 
> 
> On 2016-07-06 16:05, Paul Sandoz wrote:
>> 
>>> On 6 Jul 2016, at 13:31, Claes Redestad <claes.redes...@oracle.com> wrote:
>>> 
>>> 
>>> 
>>> On 2016-07-06 12:45, Paul Sandoz wrote:
>>>> 
>>>>> On 6 Jul 2016, at 12:04, Michael Haupt <michael.ha...@oracle.com> wrote:
>>>>> 
>>>>> Hi Paul,
>>>>> 
>>>>> thanks for your comments.
>>>>> 
>>>>> Lazy initialisation of the PerfCounter is good, as is the warning 
>>>>> suppression.
>>>>> 
>>>>> I'll let Claes comment on the broader PerfCounter question, as he 
>>>>> suggested using them. I think PerfCounter is a convenient abstraction for 
>>>>> what we want to achieve, but the way it's used here may smell a bit 
>>>>> abusive.
>>>>> 
>>>> 
>>>> Ok.
>>> 
>>> I know of a number of Java-side PerfCounters created early (and they're 
>>> rather lean on dependencies in the first place, a select number of 
>>> j.u.c.atomic classes IIRC), so I wouldn't worry about much of a startup 
>>> penalty here.
>>> 
>>> Lazy initialization might not save us much, and would hide the counter from 
>>> showing up.
>>> 
>>> I guess what I'm saying is I'm good with webrev.00. :-)
>>> 
>> 
>> LambdaForm is initiated very early in the startup, and that is gonna change 
>> the order in which other classes are loaded, namely Buffers etc. I am 
>> concerned it might induce a circular dependency with VarHandles and the 166 
>> patches that will arrive soon, e.g. see use of static AtomicInteger fields 
>> in Bits.
>> 
>> If you want to retain the PerfCounter usages i think you may need to make it 
>> lazy.
> 
> Ah, right, it's one of the classes the VM preloads, so it'll be loaded long 
> before anyone actually uses java.lang.invoke. Yes, that might cause bootstrap 
> issues, and needs to be lazy.
> 
> For the record: I perceived a need to have some discoverable event in case 
> this fallback ever takes effect. A PerfCounter is certainly not be the best 
> fit for that, but it's readily available and would allow for a quick and 
> dirty diagnostic. Perhaps it's best to move it to a follow-up improvement, 
> but I'd prefer to have something in that can be improved/replaced than 
> nothing at all.
> 
> /Claes

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(S): 8160717: MethodHandles.loop() does not check for excessive signature

[Michael Haupt]

Hi Claes,

> Am 06.07.2016 um 13:31 schrieb Claes Redestad <claes.redes...@oracle.com>:
>>> I'll let Claes comment on the broader PerfCounter question, as he suggested 
>>> using them. I think PerfCounter is a convenient abstraction for what we 
>>> want to achieve, but the way it's used here may smell a bit abusive.
>>> 
>> 
>> Ok.
> 
> I know of a number of Java-side PerfCounters created early (and they're 
> rather lean on dependencies in the first place, a select number of 
> j.u.c.atomic classes IIRC), so I wouldn't worry about much of a startup 
> penalty here.
> 
> Lazy initialization might not save us much, and would hide the counter from 
> showing up.
> 
> I guess what I'm saying is I'm good with webrev.00. :-)

thank you - some sensible improvements notwithstanding; see 
http://cr.openjdk.java.net/~mhaupt/8160717/webrev.01/.

>> A wild thought: is there anyway to add some context/data to the ASM 
>> processing indicating what intrinsic is being processed, so when you get the 
>> exception you can at least differentiate.
> 
> While out of scope for this change, maybe we should seek to improve 
> robustness by asking the ASM project to add more distinctive exceptions, say, 
> create a MethodTooLargeException or similar, in which case we could change 
> the catch to be more specific.

Four thumbs up: domain-specific meaningful exceptions are A Good Thing.

Best,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(S): 8160717: MethodHandles.loop() does not check for excessive signature

[Michael Haupt]

Hi Paul,

> Am 06.07.2016 um 12:45 schrieb Paul Sandoz <paul.san...@oracle.com>:
>> What do you mean with "differentiate between the two cases"? Assuming it's 
>> Error/Exception vs. BytecodeGenerationException, here's the current 
>> rationale. There are cases when it makes sense to fall back to LFI, e.g., 
>> when, as here, methods grow too large. In many other cases it is justified 
>> to bail altogether with an InternalError. Wrapping cw.toClassBytes() is a 
>> first approximation.
>> 
> 
> I meant to say:
> 
>>> Is it correct to say we *cannot* differentiate between the two cases. If so 
>>> the danger is that we add another intrinsic and don’t realize it contains 
>>> an actual error and we notice too late when we observe performance falling 
>>> off a cliff.
> 
> 
> I don’t know if we can differentiate between a valid error (reaching the 
> certain byte code limits) and an unexpected error where say we add a new 
> intrinsic and its code generation is faulty causing ASM to throw 
> RuntimeException.
> 
> A wild thought: is there anyway to add some context/data to the ASM 
> processing indicating what intrinsic is being processed, so when you get the 
> exception you can at least differentiate.

thanks for clarifying that.

The way it's implemented now treats anything that occurs during bytecode 
assembly as a Real Problem and consequently raises an InternalError. Any 
RuntimeException raised from ASM during class file generation 
(cw.toByteArray()) is treated as a problem that should imply falling back to 
LFI mode. Given ASM only throws RuntimeExceptions, their messages could be used 
to distinguish between problem types, but that is brittle.

It is definitely possible to attach additional information, such as the current 
LambdaForm or Intrinsic, to the wrapping exception, but the approach does not 
scale very well. There is, in principle, nothing that prevents a LambdaForm 
from containing multiple intrinsifiable idioms in a row. When a problem arises 
only during class file generation, it will not be easy to trace that back to 
the problematic intrinsic. Also, inlining at LF level is conceivable, 
complicating the matter further.

Best,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(S): 8160717: MethodHandles.loop() does not check for excessive signature

[Michael Haupt]

Hi Paul,

thanks for your comments.

Lazy initialisation of the PerfCounter is good, as is the warning suppression.

I'll let Claes comment on the broader PerfCounter question, as he suggested 
using them. I think PerfCounter is a convenient abstraction for what we want to 
achieve, but the way it's used here may smell a bit abusive.

What do you mean with "differentiate between the two cases"? Assuming it's 
Error/Exception vs. BytecodeGenerationException, here's the current rationale. 
There are cases when it makes sense to fall back to LFI, e.g., when, as here, 
methods grow too large. In many other cases it is justified to bail altogether 
with an InternalError. Wrapping cw.toClassBytes() is a first approximation.

Best,

Michael

> Am 06.07.2016 um 11:30 schrieb Paul Sandoz <paul.san...@oracle.com>:
> 
> 
>> On 6 Jul 2016, at 10:43, Michael Haupt <michael.ha...@oracle.com> wrote:
>> 
>> Hi Andrej,
>> 
>> thanks for your remarks; see below for a comment.
>> 
>> In addition, I need an upper-case Review, please.
> 
> I am concerned that PerfCounter will introduce more dependencies and overhead 
> to startup.
> 
> Notice for other usages PerfCounter instances are lazily created.
> 
> This seems a nice to have, but i think is not strictly necessary given this 
> is not something that occurs all the time and is triggered more so by edge 
> case limits producing incorrect byte code, or perhaps actual errors in code 
> generation. i.e. it’s association with performance counters seems a little 
> fuzzy compared to the other usages.
> 
> Is it correct to say we can differentiate between the two cases. If so the 
> danger is that we add another intrinsic and don’t realize it contains an 
> actual error and we notice too late when we observe performance falling off a 
> cliff.
> 
> 
>> 
>>> Am 06.07.2016 um 10:25 schrieb Andrej Golovnin <andrej.golov...@gmail.com>:
>>> 767 static final long serialVersionUID = -1L; // no serialisation
>>> 
>>> Just because you set serialVersionUID to -1L, it does not mean that it
>>> is not serializable. Either remove the comment "// no serialisation"
>>> or remove the serialVersionUID at all because you never serialize this
>>> exception. And btw. serialVersionUID should be private if you decide
>>> to keep it.
>> 
>> I know that setting the field to -1 does not hinder serialisation. The 
>> comment was intended to make clear that no serialisation of instances of 
>> this class will ever happen. I'll make that more clear. Omitting the field 
>> is not possible; the compiler will complain. Having serialVersionUID is 
>> enforced in the build.
>> 
> 
> You should be able to use the following on the exception class:
> 
>  @SuppressWarnings("serial”)
> 
> Paul.

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(S): 8160717: MethodHandles.loop() does not check for excessive signature

[Michael Haupt]

Hi Andrej,

thanks for your remarks; see below for a comment.

In addition, I need an upper-case Review, please.

> Am 06.07.2016 um 10:25 schrieb Andrej Golovnin <andrej.golov...@gmail.com>:
> 767 static final long serialVersionUID = -1L; // no serialisation
> 
> Just because you set serialVersionUID to -1L, it does not mean that it
> is not serializable. Either remove the comment "// no serialisation"
> or remove the serialVersionUID at all because you never serialize this
> exception. And btw. serialVersionUID should be private if you decide
> to keep it.

I know that setting the field to -1 does not hinder serialisation. The comment 
was intended to make clear that no serialisation of instances of this class 
will ever happen. I'll make that more clear. Omitting the field is not 
possible; the compiler will complain. Having serialVersionUID is enforced in 
the build.

Best,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

RFR(S): 8160717: MethodHandles.loop() does not check for excessive signature

[Michael Haupt]

Dear all,

please review this fix.
Bug: https://bugs.openjdk.java.net/browse/JDK-8160717 
<https://bugs.openjdk.java.net/browse/JDK-8160717>
Webrev: http://cr.openjdk.java.net/~mhaupt/8160717/webrev.00/ 
<http://cr.openjdk.java.net/~mhaupt/8160717/webrev.00/>

The fix captures failures during bytecode generation and marks the respective 
LambdaForms as permanently executable in LF interpretation mode only. The fix 
also introduces two debugging aids:

-Djava.lang.invoke.MethodHandle.LOG_LF_COMPILATION_FAILURE: if set to true 
(default is false), LF compilation failures will be logged to the console.

The PerfCounter java.lang.invoke.failedLambdaFormCompilations tracks failing LF 
compilations. It can be printed with jstat -J-Djstat.showUnsupported=true -snap 
-a file://

Best,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR of JDK-8160866: IntPrimitiveOpsTests.java still in ProblemList.txt while related bug has been closed

[Michael Haupt]

Hi Hamlin,

thumbs up.

Best,

Michael

> Am 06.07.2016 um 06:55 schrieb Hamlin Li <huaming...@oracle.com>:
> 
> Would you please review the following patch which remove 
> IntPrimitiveOpsTests.java from ProblemList.txt?
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8160866
> webrev: http://cr.openjdk.java.net/~mli/8160866/webrev.00/
> 
> Thank you
> -Hamlin

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(L): 8143211: provide bytecode intrinsics for loop and try/finally executors

[Michael Haupt]

Hi Vladimir,

> Am 01.07.2016 um 14:00 schrieb Vladimir Ivanov <vladimir.x.iva...@oracle.com>:
> Stale LF shape in the comment.

Fixed.

> -if (assertStaticType(cls, n))
> -return;  // this cast was already performed
> +assertStaticType(cls, n);
> 
> This change completely defeats localClasses purpose. I'd like to understand 
> more why the verifier complains about missing checkcast.

After internal discussion, the fix we arrived at is now here: 
http://cr.openjdk.java.net/~mhaupt/8143211/webrev.03/

Best,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(L): 8143211: provide bytecode intrinsics for loop and try/finally executors

[Michael Haupt]

Hi Vladimir,

thank you once more - your comments led to more improvements. The results are 
at http://cr.openjdk.java.net/~mhaupt/8143211/webrev.02/, and some details are 
inlined below.

> Am 29.06.2016 um 17:57 schrieb Vladimir Ivanov <vladimir.x.iva...@oracle.com>:
> I'd prefer to see loopStateTypes attached to the intrinsic itself. Right now, 
> it's unrelated and you look it up by offset. You can pass it as an additional 
> parameter into MHI.loop instead and access it directly from the Name marked 
> as the loop intrinsic.
> 
> LFE.noteLoopLocalTypesForm() looks fragile. It assumes the LF being edited 
> contains only loop intrinsic and adds type info as the first non-argument 
> Name. What if you explicitly pass loop intrinsic position into it, check that 
> the Name represents a loop, and substitute loop types argument.
> 
> Such representation will support multiple loops inside a single LF and allow 
> per-loop editing.

The loop invoker (MHImpl.loop()) now accepts an initial BasicType[] that 
captures the loop clause types. The loop LF for a method type is initialised to 
pass null in this place. For each combination of loop clause types, the 
LambdaFormEditor will now replace this null with the appropriate BasicType[]. 
This argument is altogether ignored in LambdaForm interpretation mode, but read 
and used in bytecode generation in InvokerBytecodeGenerator.emitLoop().

Thereby, the loop clause types, which are crucial for boxing-free bytecode 
generation, are now associated with (rather: stored in) the LambdaForm 
representing a particular loop state distribution, but they do not consume 
extra space in the names array comprising the LambdaForm.

> Regarding loopStarts, loopStateStarts, and currentLoop fields in IBG.
> 
> Since IBG iterates over the LF sequentially, you should be able to get rid of 
> arrays and convert the position where loop state should be stored into a 
> local variable in IBG.generateCustomizedCodeBytes().
> 
> The only problem is localsMapSize (which is eagerly allocated).
> Current eager initialization logic looks over-complicated and I think it 
> doesn't work as expected (mapLoopLocalState() overwrites locals which are 
> used by Names following the loop).
> 
> I'd prefer suggest to see it simplified.
> 
> You can just do a single pass over the LF being compiled and sum up slots 
> needed to represent loops state. After that, you can initialize them 
> incrementally during compilation when you encounter a loop intrinsic.
> 
> If you put loop state after locals used for other LF Names, you don't need to 
> adjust local slot indexes for non-loop Names.

InvokerBytecodeGenerator now adopts a solution where localsMap and localClasses 
are dynamically resized as loops are encountered in the LambdaForm. Thereby, no 
additional state about local slot allocation for loops needs to be maintained 
any more.

> Another thought: what if loop state is so large it overflows 65k locals 
> limit? I don't see any checks of clauses array size in MHs.loop().

This is filed as a bug: https://bugs.openjdk.java.net/browse/JDK-8160717.

Best,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(L): 8143211: provide bytecode intrinsics for loop and try/finally executors

[Michael Haupt]

... small correction: the FC extension for this RFE has been *requested*.

Best,

Michael

> Am 29.06.2016 um 11:49 schrieb Michael Haupt <michael.ha...@oracle.com>:
> 
> Hi again,
> 
> as there have been no comments on the .01 version, I have updated it in place 
> with a new revision. This was necessary because there was a bug in 
> InvokerBytecodeGenerator that led to the benchmarks crashing. The current 
> revision, which is still available from 
> http://cr.openjdk.java.net/~mhaupt/8143211/webrev.01 
> <http://cr.openjdk.java.net/~mhaupt/8143211/webrev.01>, fixes this.
> 
> The bug consisted in a lack of CHECKCAST generation that would only occur if 
> the verifier was turned on (which it is not by default for 
> Unsafe.defineAnonymousClass), or if, voilà, C2 kicked in for compilation.
> 
> The benchmark results are attached. Explanation:
> * "unpatched" scores are without; "patched", with bytecode intrinsics (scores 
> are given in ns/op, i.e., smaller is better)
> * "bl" are baseline measurements; simple "bl" is plain Java, "blMH" is 
> invoking the constituent handles
> * "Cr" are handle creation measurements
> * "Inv" are handle invocation measurements
> * "Itr" are for iteratedLoop
> * "Cnt" are for countedLoop (with 3 and 4 handle arguments)
> * "Wh" and "DoWh" are for whileLoop and doWhileLoop
> * "L" are for plain loop
> * "TF" are for tryFinally
> 
> Observations:
> * considerable performance improvements for all creation and handle constructs
> * exception: iteratedLoop is slowed down
> 
> Proposal:
> * accept the change as is (RFE with FC extension)
> * deal with necessary further improvements as performance bugs
> 
> Reviews please! :-)
> 
> Thanks,
> 
> Michael
> 
>> Am 23.06.2016 um 16:43 schrieb Michael Haupt <michael.ha...@oracle.com>:
>> 
>> Dear all,
>> 
>> thank you, Claes, Vladimir, and Paul, for your reviews. See 
>> http://cr.openjdk.java.net/~mhaupt/8143211/webrev.01/ for the next round.
>> 
>> The difference to the previous version is, roughly, as follows. Rev 01 ...
>> 
>> ... honours the possibility of there being more than one loop in a 
>> LambdaForm; InvokerBytecodeGenerator now has extra state summarising 
>> characteristics of the loops, while the concrete types are extracted from 
>> the LambdaForm during the actual compilation step.
>> 
>> ... does away with the extra intrinsic data for loops. Instead, the 
>> LambdaFormEditor is used to create (and cache) an appropriate LambdaForm as 
>> a specialisation of a template. This was a very good suggestion from 
>> Vladimir (thanks!), and it makes the code much more tidy in my opinion.
>> 
>> ... contains various small fixes that were suggested.
>> 
>> Things I think should be expressed in other issues rather than being 
>> piggybacked on this one:
>> * Removing IntrinsicMethodHandle.
>> * Taking care of Transform cache cleanup.
>> 
>> Best,
>> 
>> Michael
>> 
>>> Am 16.06.2016 um 15:17 schrieb Michael Haupt <michael.ha...@oracle.com>:
>>> 
>>> Dear all,
>>> 
>>> please review this change.
>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8143211
>>> Webrev: http://cr.openjdk.java.net/~mhaupt/8143211/webrev.00/
>>> 
>>> The change puts the tryFinally and loop method handle combinator 
>>> implementations, which were introduced as part of the JEP 274 effort, on a 
>>> LambdaForm basis, which executes in bytecode generating (default) and 
>>> LambdaForm interpretation 
>>> (-Djava.lang.invoke.MethodHandle.COMPILE_THRESHOLD=-1) modes. It also 
>>> changes the output formatting of LambdaForms, introducing a (hopefully) 
>>> more readable format.
>>> 
>>> Thanks,
>>> 
>>> Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(L): 8143211: provide bytecode intrinsics for loop and try/finally executors

[Michael Haupt]

Hi again,

as there have been no comments on the .01 version, I have updated it in place 
with a new revision. This was necessary because there was a bug in 
InvokerBytecodeGenerator that led to the benchmarks crashing. The current 
revision, which is still available from 
http://cr.openjdk.java.net/~mhaupt/8143211/webrev.01 
<http://cr.openjdk.java.net/~mhaupt/8143211/webrev.01>, fixes this.

The bug consisted in a lack of CHECKCAST generation that would only occur if 
the verifier was turned on (which it is not by default for 
Unsafe.defineAnonymousClass), or if, voilà, C2 kicked in for compilation.

The benchmark results are attached. Explanation:
* "unpatched" scores are without; "patched", with bytecode intrinsics (scores 
are given in ns/op, i.e., smaller is better)
* "bl" are baseline measurements; simple "bl" is plain Java, "blMH" is invoking 
the constituent handles
* "Cr" are handle creation measurements
* "Inv" are handle invocation measurements
* "Itr" are for iteratedLoop
* "Cnt" are for countedLoop (with 3 and 4 handle arguments)
* "Wh" and "DoWh" are for whileLoop and doWhileLoop
* "L" are for plain loop
* "TF" are for tryFinally

Observations:
* considerable performance improvements for all creation and handle constructs
* exception: iteratedLoop is slowed down

Proposal:
* accept the change as is (RFE with FC extension)
* deal with necessary further improvements as performance bugs

Reviews please! :-)

Thanks,

Michael

> Am 23.06.2016 um 16:43 schrieb Michael Haupt <michael.ha...@oracle.com>:
> 
> Dear all,
> 
> thank you, Claes, Vladimir, and Paul, for your reviews. See 
> http://cr.openjdk.java.net/~mhaupt/8143211/webrev.01/ for the next round.
> 
> The difference to the previous version is, roughly, as follows. Rev 01 ...
> 
> ... honours the possibility of there being more than one loop in a 
> LambdaForm; InvokerBytecodeGenerator now has extra state summarising 
> characteristics of the loops, while the concrete types are extracted from the 
> LambdaForm during the actual compilation step.
> 
> ... does away with the extra intrinsic data for loops. Instead, the 
> LambdaFormEditor is used to create (and cache) an appropriate LambdaForm as a 
> specialisation of a template. This was a very good suggestion from Vladimir 
> (thanks!), and it makes the code much more tidy in my opinion.
> 
> ... contains various small fixes that were suggested.
> 
> Things I think should be expressed in other issues rather than being 
> piggybacked on this one:
> * Removing IntrinsicMethodHandle.
> * Taking care of Transform cache cleanup.
> 
> Best,
> 
> Michael
> 
>> Am 16.06.2016 um 15:17 schrieb Michael Haupt <michael.ha...@oracle.com>:
>> 
>> Dear all,
>> 
>> please review this change.
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8143211
>> Webrev: http://cr.openjdk.java.net/~mhaupt/8143211/webrev.00/
>> 
>> The change puts the tryFinally and loop method handle combinator 
>> implementations, which were introduced as part of the JEP 274 effort, on a 
>> LambdaForm basis, which executes in bytecode generating (default) and 
>> LambdaForm interpretation 
>> (-Djava.lang.invoke.MethodHandle.COMPILE_THRESHOLD=-1) modes. It also 
>> changes the output formatting of LambdaForms, introducing a (hopefully) more 
>> readable format.
>> 
>> Thanks,
>> 
>> Michael


-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR[9]: 8158169: MethodHandles.dropArgumentsToMatch(...)

[Michael Haupt]

Hi Shilpi,

in that case, please make sure to give the test that already covers the IAE a 
@bug annotation for this issue.

Thanks,

Michael

> Am 27.06.2016 um 17:18 schrieb "shilpi.rast...@oracle.com" 
> :
> 
> Thanks Michael and Paul for comments!!
> 
> Yes we already have negative test cases which throws IAE.
> This test i have added to test the scenario where pos is equal to 
> newTpes.size() and skip is equal to target.type.parameterList.size(). 
> (positive)
> 
> Best Regards,
> Shilpi
>> On 6/27/2016 6:42 PM, Paul Sandoz wrote:
>> Hi,
>> 
>> 
>>> On 27 Jun 2016, at 14:22, shilpi.rast...@oracle.com wrote:
>>> 
>>> Hi All,
>>> 
>>> Please review fix for
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8158169
>>> http://cr.openjdk.java.net/~srastogi/8158169/webrev.00/
>> The test you added is not testing the constraints you added to the 
>> documentation? are those constraints already tested?
>> 
>> Paul.
> 

Re: RFR[9]: 8158169: MethodHandles.dropArgumentsToMatch(...)

[Michael Haupt]

Hi Shilpi,

thumbs up, with one remark (see below). It seems this change would require CCC 
approval; please take care of the process. I will be happy to sponsor the push 
thereafter.

Remark: how about adding negative tests? The documentation change specifies 
under what circumstances IAE will be thrown, but the accompanying test does not 
cover these cases.

Best,

Michael

> Am 27.06.2016 um 14:22 schrieb shilpi.rast...@oracle.com:
> 
> Hi All,
> 
> Please review fix for
> 
> https://bugs.openjdk.java.net/browse/JDK-8158169
> http://cr.openjdk.java.net/~srastogi/8158169/webrev.00/
> 
> Thanks,
> Shilpi

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(L): 8143211: provide bytecode intrinsics for loop and try/finally executors

[Michael Haupt]

Dear all,

thank you, Claes, Vladimir, and Paul, for your reviews. See 
http://cr.openjdk.java.net/~mhaupt/8143211/webrev.01/ for the next round.

The difference to the previous version is, roughly, as follows. Rev 01 ...

... honours the possibility of there being more than one loop in a LambdaForm; 
InvokerBytecodeGenerator now has extra state summarising characteristics of the 
loops, while the concrete types are extracted from the LambdaForm during the 
actual compilation step.

... does away with the extra intrinsic data for loops. Instead, the 
LambdaFormEditor is used to create (and cache) an appropriate LambdaForm as a 
specialisation of a template. This was a very good suggestion from Vladimir 
(thanks!), and it makes the code much more tidy in my opinion.

... contains various small fixes that were suggested.

Things I think should be expressed in other issues rather than being 
piggybacked on this one:
* Removing IntrinsicMethodHandle.
* Taking care of Transform cache cleanup.

Best,

Michael

> Am 16.06.2016 um 15:17 schrieb Michael Haupt <michael.ha...@oracle.com>:
> 
> Dear all,
> 
> please review this change.
> RFE: https://bugs.openjdk.java.net/browse/JDK-8143211
> Webrev: http://cr.openjdk.java.net/~mhaupt/8143211/webrev.00/
> 
> The change puts the tryFinally and loop method handle combinator 
> implementations, which were introduced as part of the JEP 274 effort, on a 
> LambdaForm basis, which executes in bytecode generating (default) and 
> LambdaForm interpretation 
> (-Djava.lang.invoke.MethodHandle.COMPILE_THRESHOLD=-1) modes. It also changes 
> the output formatting of LambdaForms, introducing a (hopefully) more readable 
> format.
> 
> Thanks,
> 
> Michael


-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

RFR(L): 8143211: provide bytecode intrinsics for loop and try/finally executors

[Michael Haupt]

Dear all,

please review this change.
RFE: https://bugs.openjdk.java.net/browse/JDK-8143211
Webrev: http://cr.openjdk.java.net/~mhaupt/8143211/webrev.00/

The change puts the tryFinally and loop method handle combinator 
implementations, which were introduced as part of the JEP 274 effort, on a 
LambdaForm basis, which executes in bytecode generating (default) and 
LambdaForm interpretation 
(-Djava.lang.invoke.MethodHandle.COMPILE_THRESHOLD=-1) modes. It also changes 
the output formatting of LambdaForms, introducing a (hopefully) more readable 
format.

Thanks,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR[9]: 8147585: Annotations with lambda expressions has parameters result in wrong behavior.

[Michael Haupt]

Hi Shilpi,

I will be happy to sponsor the push.

Best,

Michael

> Am 07.06.2016 um 11:39 schrieb shilpi.rast...@oracle.com:
> 
> Thanks Joseph!!
> Please see http://cr.openjdk.java.net/~srastogi/8147585/webrev.05/
> 
> Regards,
> Shilpi
> 
> On 6/7/2016 6:00 AM, Joseph D. Darcy wrote:
>> Hello,
>> 
>> The test
>> 
>>  45 void testAnnotationWithLambda() {
>>  46 Method[] methods = 
>> AnnotationWithLambda.MethodsWithAnnotations.class.getDeclaredMethods();
>>  47 for (Method method : methods) {
>>  48 assertEquals(1, method.getDeclaredAnnotations().length);
>>  49 }
>>  50 }
>> 
>> is very non-specific in what it is testing. A better test would include 
>> something like
>> 
>>method.isAnnotationPresent(@LambdaWithParameter) &&
>>method.isAnnotationPresent(@LambdaWithouParameter)
>> 
>> if both annotations were put on the same method.
>> 
>> Cheers,
>> 
>> -Joe
>> 
>> On 6/6/2016 12:20 AM, shilpi.rast...@oracle.com wrote:
>>> Gentle reminder!!
>>> 
>>> On 6/3/2016 11:40 AM, shilpi.rast...@oracle.com wrote:
>>>> Thanks Vladimir and Joel!!
>>>> Please see http://cr.openjdk.java.net/~srastogi/8147585/webrev.04/
>>>> Added restriction for synthetic methods as well.
>>>> 
>>>> On 6/2/2016 5:04 PM, Vladimir Ivanov wrote:
>>>>> 
>>>>> 
>>>>> On 6/2/16 12:02 AM, Joel Borggrén-Franck wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> I think this was caught by the verifier before 8 since you couldn't have
>>>>>> concrete or private methods in an interface. Now you can (though not in
>>>>>> Java for private ones).
>>>>>> 
>>>>>> My spider sense tells me there might be something lurking here (though
>>>>>> it was a while since this was in my L1 cache). It is not likely, but I'm
>>>>>> not 100% sure that it is impossible to make javac produce a bridge when
>>>>>> compiling an annotation type for example, so why not remove synthetic
>>>>>> methods as well?
>>>>> 
>>>>> I'm not an expert in annotation processing, but it bothers me as well, 
>>>>> since current behavior looks too Java-centric. There are valid (in JVMS 
>>>>> sense) class files which are not produced by javac or from java source 
>>>>> file.
>>>>> 
>>>>> What is expected behavior in such case? It is unfortunate when non-Java 
>>>>> languages have to obey to Java rules. It reminds me a problem with 
>>>>> Class.getSimpleName() (see JDK-8057919 [1]) we fixed some time ago.
>>>>> Best regards,
>>>>> Vladimir Ivanov
>>>>> 
>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8057919
>>>>> 
>>>>>> 
>>>>>> Spending some time with ASM to do a bunch of tests not compilable in
>>>>>> java might be useful, there should also be some frameworks in langtools
>>>>>> to produce invalid classfiles IIRC.
>>>>  Raised https://bugs.openjdk.java.net/browse/JDK-8158510 to include new 
>>>> test cases.
>>>> 
>>>> Regards,
>>>> Shilpi
>>>>>> 
>>>>>> cheers
>>>>>> /Joel
>>>>>> 
>>>>>> On Tue, 31 May 2016 at 17:49 shilpi.rast...@oracle.com
>>>>>> <mailto:shilpi.rast...@oracle.com> <shilpi.rast...@oracle.com
>>>>>> <mailto:shilpi.rast...@oracle.com>> wrote:
>>>>>> 
>>>>>>Thanks Paul!!
>>>>>>Please see http://cr.openjdk.java.net/~srastogi/8147585/webrev.03/
>>>>>> 
>>>>>>Thanks,
>>>>>>Shilpi
>>>>>> 
>>>>>>On 5/31/2016 7:57 PM, Paul Sandoz wrote:
>>>>>>> >"Returns an array containing Method objects reflecting all the
>>>>>>declared methods of the class or interface represented by this Class
>>>>>>object, including public, protected, default (package) access, and
>>>>>>private methods, but excluding inherited methods."
>>>>>> 
>>>> 
>>> 
>> 
> 

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR: 8159031: jjs throws NoSuchFileException if ~/.jjs.history does not exist

[Michael Haupt]

Hi Hannes,

lower-case thumbs up for both the JDK and Nashorn changes.

Best,

Michael

> Am 08.06.2016 um 13:18 schrieb Hannes Wallnöfer 
> <hannes.wallnoe...@oracle.com>:
> 
> Please review the following changes:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8159031
> JDK webrev: http://cr.openjdk.java.net/~hannesw/8159031/jdk/webrev.00/
> Nashorn webrev: http://cr.openjdk.java.net/~hannesw/8159031/nashorn/webrev.00/
> 
> These are two one-liners that add a file existence check in Nashorn and a 
> null check in jline.
> 
> Thanks, 
> Hannes
> 

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR[9]:MethodHandles.dropArgumentsToMatch(...) non-documented IAE

[Michael Haupt]

Hi Shilpi,

CCC approval is in. My review is lower-case, so another one is needed ere I can 
sponsor the push.

Best,

Michael

> Am 02.06.2016 um 14:53 schrieb Michael Haupt <michael.ha...@oracle.com>:
> 
> Hi Shilpi,
> 
> lower-case thumbs up. Please obtain CCC approval for this change.
> 
> Best,
> 
> Michael
> 
>> Am 02.06.2016 um 11:38 schrieb shilpi.rast...@oracle.com:
>> 
>> Hi All,
>> 
>> Please review fix for
>> https://bugs.openjdk.java.net/browse/JDK-8158171
>> http://cr.openjdk.java.net/~srastogi/8158171/webrev.00/
>> 
>> 
>> Thanks,
>> Shilpi


-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR[9]: 8156868 MethodHandles.zero(Class) doc issues

[Michael Haupt]

Hi Shilpi,

lower-case thumbs up, and I'll be happy to sponsor this push.

Best,

Michael

> Am 24.05.2016 um 14:23 schrieb Paul Sandoz <paul.san...@oracle.com>:
> 
> 
>> On 24 May 2016, at 08:40, shilpi.rast...@oracle.com wrote:
>> 
>> Thanks Paul!!
>> 
>> Please see http://cr.openjdk.java.net/~srastogi/8156868/webrev.02/
>> 
> 
> +1
> 
> Paul.

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(M): 8156915: introduce MethodHandle factory for array length

[Michael Haupt]

... thank you so much, Uwe - it's up for review now.

Best,

Michael

> Am 20.05.2016 um 09:42 schrieb Uwe Schindler <uschind...@apache.org>:
> 
> Hi,
> 
> I just noticed that there is the @since missing in javadocs: 
> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fd39cefc5c8f#l3.13
> arrayConstructor has @since 9, but arrayLength() not.
> 
> Uwe


-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

RFR(XS): 8157590: MethodHandles.arrayLength() lacks @since tag, implementation throws wrong exception

[Michael Haupt]

Dear all,

please review this fix.
Bug: https://bugs.openjdk.java.net/browse/JDK-8157590
Webrev: http://cr.openjdk.java.net/~mhaupt/8157590/webrev.00/

Thanks,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(M): 8156915: introduce MethodHandle factory for array length

[Michael Haupt]

Hi Stanislav,

yes please, file and assign to me.

Best,

Michael

> Am 18.05.2016 um 12:52 schrieb stanislav lukyanov 
> <stanislav.lukya...@oracle.com>:
> 
> Hi Michael,
> 
> I've noticed that neither the new method nor its friends, arrayElementGetter 
> and arrayElementSetter,
> discuss the invocation-time behavior.
> It seems important since there are exceptions to be documented.
> 
> I think the best way would be to make a connection between the methods and 
> corresponding instructions,
> so as not to explain every NPE and, especially, ArrayStoreException in 
> Javadoc.
> Probably no need to go deep in details on how, for example, 
> arrayElementGetter(T) maps on 8 Taload instructions,
> but just give a basic notion of that.
> 
> WDYT? Should I file a separate RFE for that? (for arrayElementGetter/Setter? 
> for all three?)
> 
> Thanks,
> Stanislav
> 
> On 18.05.2016 10:52, Michael Haupt wrote:
>> Dear all,
>> 
>> please review this change.
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8156915
>> Webrev: http://cr.openjdk.java.net/~mhaupt/8156915/webrev.00/
>> 
>> Thanks,
>> 
>> Michael
>> 
> 

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(M): 8156915: introduce MethodHandle factory for array length

[Michael Haupt]

Hi Vladimir,

pushed already. I'll piggyback this on a future change.

Best,

Michael

> Am 18.05.2016 um 11:47 schrieb Vladimir Ivanov <vladimir.x.iva...@oracle.com>:
> 
> src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java
> +throw new AssertionError();
> 
> +throw new IllegalStateException("should not reach here");
> 
> Please, use InternalError to signal about error conditions (there's 
> MHS.newInternalError(String)) and put a message containing description of 
> problematic parameters to simplify problem diagnostics.
> 
> Otherwise, looks good!
> 
> Best regards,
> Vladimir Ivanov
> 
> On 5/18/16 10:52 AM, Michael Haupt wrote:
>> Dear all,
>> 
>> please review this change.
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8156915
>> Webrev: http://cr.openjdk.java.net/~mhaupt/8156915/webrev.00/
>> 
>> Thanks,
>> 
>> Michael
>> 

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: MethodHandle for array length

[Michael Haupt]

Hi Uwe,

it's a different issue, but still: 
https://bugs.openjdk.java.net/browse/JDK-8157225

Best,

Michael

> Am 13.05.2016 um 12:14 schrieb Uwe Schindler <uschind...@apache.org>:
> 
> Hi,
> 
> One addition, maybe add to issue:
> 
> If this was added, jdk.dynalink module could use it, too - this was mentioned 
> by Attila already: 
> http://hg.openjdk.java.net/jdk9/dev/nashorn/file/4b118e012ac4/src/jdk.dynalink/share/classes/jdk/dynalink/beans/BeanLinker.java
> 
> Uwe
> 
> -
> Uwe Schindler
> uschind...@apache.org 
> ASF Member, Apache Lucene PMC / Committer
> Bremen, Germany
> http://lucene.apache.org/
> 
>> -Original Message-
>> From: Uwe Schindler [mailto:uschind...@apache.org]
>> Sent: Friday, May 13, 2016 11:55 AM
>> To: 'Remi Forax' <fo...@univ-mlv.fr>
>> Cc: 'Michael Haupt' <michael.ha...@oracle.com>; 'Core-Libs-Dev' > d...@openjdk.java.net>
>> Subject: RE: MethodHandle for array length
>> 
>> Hi,
>> 
>> OK, thanks for creating an issue!
>> 
>> Uwe
>> 
>> -
>> Uwe Schindler
>> uschind...@apache.org
>> ASF Member, Apache Lucene PMC / Committer
>> Bremen, Germany
>> http://lucene.apache.org/
>> 
>>> -Original Message-
>>> From: Remi Forax [mailto:fo...@univ-mlv.fr]
>>> Sent: Friday, May 13, 2016 10:37 AM
>>> To: Uwe Schindler <uschind...@apache.org>
>>> Cc: Michael Haupt <michael.ha...@oracle.com>; Core-Libs-Dev >> d...@openjdk.java.net>
>>> Subject: Re: MethodHandle for array length
>>> 
>>> Hi Uwe,
>>> I was planning to add a bug for this feature but it seems that Michael was
>>> faster than me,
>>>  https://bugs.openjdk.java.net/browse/JDK-8156915
>>> 
>>> regards,
>>> Rémi
>>> 
>>> - Mail original -
>>>> De: "Uwe Schindler" <uschind...@apache.org>
>>>> À: "Michael Haupt" <michael.ha...@oracle.com>, "Core-Libs-Dev"
>> >> libs-...@openjdk.java.net>
>>>> Envoyé: Jeudi 12 Mai 2016 14:34:34
>>>> Objet: RE: MethodHandle for array length
>>>> 
>>>> Hi Michael,
>>>> 
>>>>>> Am 11.05.2016 um 21:35 schrieb Uwe Schindler
>>> <uschind...@apache.org>:
>>>>>> With Java 9 this gets a bit worse: There is no "easy way" with the
>>>>> MethodHanldes class to generate a MethodHandles.countedLoop() on
>> all
>>>>> elements of an array:
>>>>>> 
>>>>>> public static MethodHandle countedLoop(MethodHandle iterations,
>>>>> MethodHandle init, MethodHandle  body) [new in Java 9]
>>>>> 
>>>>> this isn't a remedy when you need the index in each iteration, but you
>>> can
>>>>> generate a loop over all elements of an array using iteratedLoop(), as
>>>>> illustrated by this test from LoopCombinatorTest:
>>>>> 
>>>>> @Test
>>>>> public static void testIterateSum() throws Throwable {
>>>>>// Integer[] a = new Integer[]{1,2,3,4,5,6}; int sum = 0; for (int e :
>>>>>a) { sum
>>>>> += e; } return sum; => 21
>>>>>MethodHandle loop =
>>>>> MethodHandles.iteratedLoop(Iterate.MH_sumIterator,
>>> Iterate.MH_sumInit,
>>>>> Iterate.MH_sumStep);
>>>>>assertEquals(Iterate.MT_sum, loop.type());
>>>>>assertEquals(21, loop.invoke(new Integer[]{1, 2, 3, 4, 5, 6}));
>>>>> }
>>>>> 
>>>>> ... where MH_sumIterator is a handle to this method:
>>>>> 
>>>>> static Iterator sumIterator(Integer[] a) {
>>>>>return Arrays.asList(a).iterator();
>>>>> }
>>>> 
>>>> Of course this works, too.
>>>> 
>>>> My proposal or question here was more about the API inconsistency in
>>> general.
>>>> You can do a lot here and there, you can implement effective or
>>>> non-effective loops with MethodHandles, but still the following holds
>> true:
>>>> java.lang.invoke.MethodHandles is missing an accessor for
>> "array.length",
>>>> which is not understandable. The "countedLoop" here was just an
>> example
>>> use
>>>> case (if that one is great or not does not matter), it was just posted to
>>>> actually show the API and how it *could* be used.
>>>

Re: MethodHandle for array length

[Michael Haupt]

Hi Uwe,

you're welcome. Note it's up for review now: 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/041211.html

Best,

Michael

> Am 13.05.2016 um 11:54 schrieb Uwe Schindler <uschind...@apache.org>:
> 
> Hi,
> 
> OK, thanks for creating an issue!
> 
> Uwe
> 
> -
> Uwe Schindler
> uschind...@apache.org 
> ASF Member, Apache Lucene PMC / Committer
> Bremen, Germany
> http://lucene.apache.org/
> 
>> -Original Message-
>> From: Remi Forax [mailto:fo...@univ-mlv.fr]
>> Sent: Friday, May 13, 2016 10:37 AM
>> To: Uwe Schindler <uschind...@apache.org>
>> Cc: Michael Haupt <michael.ha...@oracle.com>; Core-Libs-Dev > d...@openjdk.java.net>
>> Subject: Re: MethodHandle for array length
>> 
>> Hi Uwe,
>> I was planning to add a bug for this feature but it seems that Michael was
>> faster than me,
>>  https://bugs.openjdk.java.net/browse/JDK-8156915
>> 
>> regards,
>> Rémi
>> 
>> - Mail original -
>>> De: "Uwe Schindler" <uschind...@apache.org>
>>> À: "Michael Haupt" <michael.ha...@oracle.com>, "Core-Libs-Dev" > libs-...@openjdk.java.net>
>>> Envoyé: Jeudi 12 Mai 2016 14:34:34
>>> Objet: RE: MethodHandle for array length
>>> 
>>> Hi Michael,
>>> 
>>>>> Am 11.05.2016 um 21:35 schrieb Uwe Schindler
>> <uschind...@apache.org>:
>>>>> With Java 9 this gets a bit worse: There is no "easy way" with the
>>>> MethodHanldes class to generate a MethodHandles.countedLoop() on all
>>>> elements of an array:
>>>>> 
>>>>> public static MethodHandle countedLoop(MethodHandle iterations,
>>>> MethodHandle init, MethodHandle  body) [new in Java 9]
>>>> 
>>>> this isn't a remedy when you need the index in each iteration, but you
>> can
>>>> generate a loop over all elements of an array using iteratedLoop(), as
>>>> illustrated by this test from LoopCombinatorTest:
>>>> 
>>>> @Test
>>>> public static void testIterateSum() throws Throwable {
>>>>// Integer[] a = new Integer[]{1,2,3,4,5,6}; int sum = 0; for (int e :
>>>>a) { sum
>>>> += e; } return sum; => 21
>>>>MethodHandle loop =
>>>> MethodHandles.iteratedLoop(Iterate.MH_sumIterator,
>> Iterate.MH_sumInit,
>>>> Iterate.MH_sumStep);
>>>>assertEquals(Iterate.MT_sum, loop.type());
>>>>assertEquals(21, loop.invoke(new Integer[]{1, 2, 3, 4, 5, 6}));
>>>> }
>>>> 
>>>> ... where MH_sumIterator is a handle to this method:
>>>> 
>>>> static Iterator sumIterator(Integer[] a) {
>>>>return Arrays.asList(a).iterator();
>>>> }
>>> 
>>> Of course this works, too.
>>> 
>>> My proposal or question here was more about the API inconsistency in
>> general.
>>> You can do a lot here and there, you can implement effective or
>>> non-effective loops with MethodHandles, but still the following holds true:
>>> java.lang.invoke.MethodHandles is missing an accessor for "array.length",
>>> which is not understandable. The "countedLoop" here was just an example
>> use
>>> case (if that one is great or not does not matter), it was just posted to
>>> actually show the API and how it *could* be used.
>>> 
>>> The real example from our script engine was not related to loops, it was an
>>> actual invokedynamic callsite implementation where it was not possible to
>>> figure out how to get a method handle to the very special arraylength byte
>>> code, aka "array.length javac sugar". Everything else to handle arrays is
>>> there at one single place, but the array length is missing and you get very
>>> annoyed. If you are not so familiar to bytecode and the mechanics behind,
>>> you have a very hard time to find out how to do this: the intuitive
>>> solutions does not work: "array.length" -> aha it’s a field, so let's try
>>> Lookup.findGetter(long[].class, "length", int.class) -> does not work!
>>> 
>>> What is so hard to accept the proposal to have
>>> MethodHandles.arrayLengthGetter, implemented in the most effective
>> way (as a
>>> methodhandle that solely calls the special bytecode "arraylength")? In fact
>>> thais is like a 10 liner to implement + Javadocs. No need to delay a
>>> release, there are still changes in JDK 9 going on that are far more risky
>>> than this.
>>> 
>>> Best,
>>> Uwe


-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

RFR(M): 8156915: introduce MethodHandle factory for array length

[Michael Haupt]

Dear all,

please review this change.
RFE: https://bugs.openjdk.java.net/browse/JDK-8156915
Webrev: http://cr.openjdk.java.net/~mhaupt/8156915/webrev.00/

Thanks,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: MethodHandle for array length

[Michael Haupt]

Hi Uwe,

> Am 11.05.2016 um 21:35 schrieb Uwe Schindler <uschind...@apache.org>:
> With Java 9 this gets a bit worse: There is no "easy way" with the 
> MethodHanldes class to generate a MethodHandles.countedLoop() on all elements 
> of an array:
> 
> public static MethodHandle countedLoop(MethodHandle iterations, MethodHandle 
> init, MethodHandle  body) [new in Java 9]

this isn't a remedy when you need the index in each iteration, but you can 
generate a loop over all elements of an array using iteratedLoop(), as 
illustrated by this test from LoopCombinatorTest:

@Test
public static void testIterateSum() throws Throwable {
// Integer[] a = new Integer[]{1,2,3,4,5,6}; int sum = 0; for (int e : a) { 
sum += e; } return sum; => 21
MethodHandle loop = MethodHandles.iteratedLoop(Iterate.MH_sumIterator, 
Iterate.MH_sumInit, Iterate.MH_sumStep);
assertEquals(Iterate.MT_sum, loop.type());
assertEquals(21, loop.invoke(new Integer[]{1, 2, 3, 4, 5, 6}));
}

... where MH_sumIterator is a handle to this method:

static Iterator sumIterator(Integer[] a) {
return Arrays.asList(a).iterator();
}

Best,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass()

[Michael Haupt]

... yes.

Best,

Michael

> Am 12.05.2016 um 06:44 schrieb Sundararajan Athijegannathan 
> <sundararajan.athijegannat...@oracle.com>:
> 
> +1
> 
> -Sundar
> 
> 
> On 5/11/2016 10:01 PM, shilpi.rast...@oracle.com wrote:
>> Hi All,
>> 
>> Please review the updated webrev-
>> http://cr.openjdk.java.net/~srastogi/8149574/webrev.07/
>> 
>> Changed the anonymous class package with no package name.
>> 
>> Regards,
>> Shilpi
>> 
>> On 5/11/2016 8:22 PM, Paul Sandoz wrote:
>>> Hi Shilpi,
>>> 
>>> What makes me slightly queasy about the constant pool patching of T
>>> is it’s quite fragile and it produces a class with a slightly
>>> inconsistent state regarding the InnerClasses structures. It’s
>>> probably mostly harmless but still bothers me.
>>> 
>>> One solution is to combine ASM with constant pool patching. Use ASM
>>> to generate the class bytes, and query the constant pool in the
>>> ClassWriter, then remember the class bytes, the pool size, and index
>>> to patch (a cursory glance at ClassWriter suggests this is possible).
>>> 
>>> But i think Michael raises an important point about simplification
>>> using the default package, if that is possible. However, if the
>>> default package is to be used ASM is still required to generate class
>>> bytes and define the class anonymously within the scope of the host
>>> class. Thus in this approach the addition of patching should not add
>>> much more complexity and i think would be more in sync with that of
>>> the host class.
>>> 
>>> Paul.
>>> 
>>>> On 11 May 2016, at 13:24, shilpi.rast...@oracle.com wrote:
>>>> 
>>>> Hi All,
>>>> 
>>>> Please review the following-
>>>> 
>>>> https://bugs.openjdk.java.net/browse/JDK-8149574
>>>> 
>>>> Solution: Changed anonymous class package name with the package name
>>>> of its host class.
>>>> 
>>>> Two approaches to solve this-
>>>> 1.  Parse .class and get the class name index form constant pool and
>>>> patch it with new name
>>>> http://cr.openjdk.java.net/~srastogi/8149574/webrev.05/
>>>> 
>>>> 2. Create class with new name (With ASM)
>>>> http://cr.openjdk.java.net/~srastogi/8149574/webrev.06/
>>>> 
>>>> Which approach is better?
>>>> 
>>>> Thanks,
>>>> Shilpi
>>>> 
>>>> 
>>>> 
>> 
> 

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode

[Michael Haupt]

Hi Shilpi,

thanks for the clarification. OK by me then - please note this is a lower-case 
review.

Best,

Michael

> Am 11.05.2016 um 15:55 schrieb shilpi.rast...@oracle.com:
> 
> Thank You Michael for comments!
> 
> It was fixed for VarargsArrayTest.java  but not fixed for 
> java/lang/invoke/CustomizedLambdaFormTest.java.
> 
> 
> Boris Molodenkov 
> <https://bugs.openjdk.java.net/secure/ViewProfile.jspa?name=bmoloden>added a 
> comment -2016-05-02 02:37-Restricted toConfidential
> One more test
> RULE "java/lang/invoke/CustomizedLambdaFormTest.java" StatusError Parse 
> Exception: [-esa]: vm option(s) found, need to specify /othervm
> 
> Thanks,
> Shilpi
> 
> On 5/11/2016 6:47 PM, Michael Haupt wrote:
>> Hi Shilpi,
>> 
>> not a review - the bug mentions that this issue is fixed in Jake already and 
>> that the bug should be closed once the fix from Jake propagates to dev. What 
>> is the status of that?
>> 
>> Best,
>> 
>> Michael
>> 
>>> Am 11.05.2016 um 13:24 schrieb shilpi.rast...@oracle.com:
>>> 
>>> Hi All,
>>> 
>>> Please review one small fix for
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8155791
>>> http://cr.openjdk.java.net/~srastogi/8155791/webrev.00/
>>> 
>>> Thanks,
>>> Shilpi
> 

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass()

[Michael Haupt]

Hi Shilpi,

thank you for preparing these patches. They both implement solution (A), which 
is to patch the package name. As it happens, most of the complexity in the 
solutions is due to the desire to make the solution tidy in terms of 
association of the anonymous class with the host class' package. As the bug 
description mentions, this is not necessary: the alternative solution (B), 
namely to have the anonymous class in the default package, appears to be more 
interesting due to the following reasons:

1. It does not require the excessive logic to find the right place in the 
constant pool to patch in the package name (your approach 1).

2. It does not require to go through ASM every time to generate the class in 
the right package (your approach 2).

How about adopting the simpler scheme?

Best,

Michael

> Am 11.05.2016 um 13:24 schrieb shilpi.rast...@oracle.com:
> 
> Hi All,
> 
> Please review the following-
> 
> https://bugs.openjdk.java.net/browse/JDK-8149574
> 
> Solution: Changed anonymous class package name with the package name of its 
> host class.
> 
> Two approaches to solve this-
> 1.  Parse .class and get the class name index form constant pool and patch it 
> with new name
> http://cr.openjdk.java.net/~srastogi/8149574/webrev.05/
> 
> 2. Create class with new name (With ASM)
> http://cr.openjdk.java.net/~srastogi/8149574/webrev.06/
> 
> Which approach is better?
> 
> Thanks,
> Shilpi
> 
> 
> 

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode

[Michael Haupt]

Hi Shilpi,

not a review - the bug mentions that this issue is fixed in Jake already and 
that the bug should be closed once the fix from Jake propagates to dev. What is 
the status of that?

Best,

Michael

> Am 11.05.2016 um 13:24 schrieb shilpi.rast...@oracle.com:
> 
> Hi All,
> 
> Please review one small fix for
> 
> https://bugs.openjdk.java.net/browse/JDK-8155791
> http://cr.openjdk.java.net/~srastogi/8155791/webrev.00/
> 
> Thanks,
> Shilpi

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

RFR(S): 8155106: MHs.Lookup.findConstructor returns handles for array classes

[Michael Haupt]

Dear all,

please review this change.
Bug: https://bugs.openjdk.java.net/browse/JDK-8155106
Webrev: http://cr.openjdk.java.net/~mhaupt/8155106/webrev.00/

Thanks,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(S): 8154754: MethodHandles.countedLoop errors in deriving loop arguments, result type, and local state

[Michael Haupt]

Hi Claes,

thanks for this one as well; see 
http://cr.openjdk.java.net/~mhaupt/8154754/webrev.01/ for an updated webrev. 
This patch still depends on the one for 8154751.

Best,

Michael

> Am 22.04.2016 um 12:18 schrieb Claes Redestad <claes.redes...@oracle.com>:
> 
> Hi,
> 
> looks good to me. resultType == void.class ? zero(void.class) : 
> identity(resultType) appears twice and unconditionally used at least once, 
> thus could be profitably extracted to a variable for readability/imaginary 
> performance gain. Thanks! /Claes
> 
> On 2016-04-20 15:46, Michael Haupt wrote:
>> Dear all,
>> 
>> please review this change. It depends on the one about 8154751 posted 
>> earlier [1].
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154754
>> Webrev: http://cr.openjdk.java.net/~mhaupt/8154754/webrev.00/
>> 
>> Thanks,
>> 
>> Michael
>> 
>> [1] 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040386.html
>> 
> 

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(S): 8154751: MethodHandles.countedLoop does not accept empty bodies

[Michael Haupt]

Hi Claes,

thank you. I've applied the refactoring - see 
http://cr.openjdk.java.net/~mhaupt/8154751/webrev.01/ for an update.

Best,

Michael

> Am 22.04.2016 um 12:09 schrieb Claes Redestad <claes.redes...@oracle.com>:
> 
> Hi Michael,
> 
> voidReturn ? zero(void.class) : identity(init.type().returnType()) is used 
> twice, breaking it out to variable would improve readability, possibly 
> performance. Same goes for the subexpression init.type().returnType() which 
> is used three times currently.
> 
> Otherwise it looks fine to me.
> 
> Thanks!
> 
> /Claes
> 
> On 2016-04-20 15:13, Michael Haupt wrote:
>> Dear all,
>> 
>> please review this change.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154751
>> Webrev: http://cr.openjdk.java.net/~mhaupt/8154751/webrev.00/
>> 
>> Thanks,
>> 
>> Michael
>> 
> 

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(S): 8152667: MHs.iteratedLoop(...) throws unexpected WMTE, disallows Iterator subclasses, generates inconsistent loop result type

[Michael Haupt]

Hi Claes,

thank you - I've applied this simple change and pushed.

Best,

Michael

> Am 22.04.2016 um 12:13 schrieb Claes Redestad <claes.redes...@oracle.com>:
> 
> Hi,
> 
> change looks good.
> 
> There's a small pre-existing inefficiency in that initit is created 
> unconditionally but only used if iterator == null, thus could be refactored 
> into an if (iterator == null) ... else construct
> 
> Thanks!
> 
> /Claes
> 
> On 2016-04-20 11:25, Michael Haupt wrote:
>> Dear all,
>> 
>> please review this change.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152667
>> Webrev: http://cr.openjdk.java.net/~mhaupt/8152667/webrev.00/
>> 
>> Thanks,
>> 
>> Michael
>> 
> 

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

RFR(S): 8154754: MethodHandles.countedLoop errors in deriving loop arguments, result type, and local state

[Michael Haupt]

Dear all,

please review this change. It depends on the one about 8154751 posted earlier 
[1].
Bug: https://bugs.openjdk.java.net/browse/JDK-8154754
Webrev: http://cr.openjdk.java.net/~mhaupt/8154754/webrev.00/

Thanks,

Michael

[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040386.html

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

RFR(S): 8154751: MethodHandles.countedLoop does not accept empty bodies

[Michael Haupt]

Dear all,

please review this change.
Bug: https://bugs.openjdk.java.net/browse/JDK-8154751
Webrev: http://cr.openjdk.java.net/~mhaupt/8154751/webrev.00/

Thanks,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

RFR(S): 8152667: MHs.iteratedLoop(...) throws unexpected WMTE, disallows Iterator subclasses, generates inconsistent loop result type

[Michael Haupt]

Dear all,

please review this change.
Bug: https://bugs.openjdk.java.net/browse/JDK-8152667
Webrev: http://cr.openjdk.java.net/~mhaupt/8152667/webrev.00/

Thanks,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

RFR(S): 8150956: j.l.i.MethodHandles.whileLoop(...) and .iteratedLoop(...) throw unexpected exceptions in the case of 'init' return type is void

[Michael Haupt]

Dear all,

please review this change.
Bug: https://bugs.openjdk.java.net/browse/JDK-8150956
Webrev: http://cr.openjdk.java.net/~mhaupt/8150956/webrev.00/

Thanks,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

RFR(S): 8150824: Exceptions when omitting trailing arguments in cleanup

[Michael Haupt]

Dear all,

please review this change.
Bug: https://bugs.openjdk.java.net/browse/JDK-8150824
Webrev: http://cr.openjdk.java.net/~mhaupt/8150824/webrev.00/

The actual bug was fixed with the push for 8150829; this change merely 
contributes tests for the issue.

Thanks,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

RFR(S): 8153637: MethodHandles.countedLoop/3 initialises loop counter to 1 instead of 0

[Michael Haupt]

Dear all,

please review this change.
Bug: https://bugs.openjdk.java.net/browse/JDK-8153637
Webrev: http://cr.openjdk.java.net/~mhaupt/8153637/webrev.00/

The countedLoop implementation currently initialises the loop counter to the 
start value and, because this takes place in the very first loop clause, 
increments it immediately, leading to start+1 being passed to the first body 
invocation. The solution passes counter-1 to body. Alternatives that were 
considered include initialising the counter to start-1 (possible counting range 
is diminished), and to reorder loop clauses to move counter increment to the 
end of the loop (requires argument permutation).

Thanks,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR 8151705 VarHandle.AccessMode enum names should conform to code style

[Michael Haupt]

Hi Paul,

note this is a lower-case review. Thumbs up, with one remarks (no new webrev 
required IMO).

* VarHandle.java: static initialiser of AccessMode, comment:
  // Initial capacity of # values will is sufficient to avoid resizes
  -> remove "will"

Best,

Michael

> Am 07.04.2016 um 15:39 schrieb Paul Sandoz <paul.san...@oracle.com>:
> 
> Hi,
> 
> Please review:
> 
>  
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151705-VH-AccessMode-names/webrev/
> 
> I was persuaded (in internal CCC review) to change the enum 
> VarHandle.AccessMode constant names to conform to the expected Java style.
> 
> Previously, for convenience, the names corresponded exactly with the VH 
> sig-poly method names.
> 
> Most of the patch is just refactoring.
> 
> I have added two new methods to translate to/from the sig-poly method name 
> domain:
> 
> 1175 /**
> 1176  * Returns the {@code VarHandle} signature-polymorphic method 
> name
> 1177  * associated with this {@code AccessMode} value
> 1178  *
> 1179  * @return the signature-polymorphic method name
> 1180  * @see #valueFromMethodName
> 1181  */
> 1182 public String methodName() {
> 1183 return methodName;
> 1184 }
> 1185
> 1186 /**
> 1187  * Returns the {@code AccessMode} value associated with the 
> specified
> 1188  * {@code VarHandle} signature-polymorphic method name.
> 1189  *
> 1190  * @param methodName the signature-polymorphic method name
> 1191  * @return the {@code AccessMode} value
> 1192  * @throws IllegalArgumentException if there is no {@code 
> AccessMode}
> 1193  * value associated with method name (indicating the 
> method
> 1194  * name does not correspond to a {@code VarHandle}
> 1195  * signature-polymorphic method name).
> 1196  * @see #methodName
> 1197  */
> 1198 public static AccessMode valueFromMethodName(String methodName) {
> 1199 AccessMode am = methodNameToAccessMode.get(methodName);
> 1200 if (am != null) return am;
> 1201     throw new IllegalArgumentException("No AccessMode value for 
> method name " + methodName);
> 1202 }
> 
> Paul.
> 

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR 8151706: Update VarHandle implementation to use @Stable arrays

[Michael Haupt]

Hi Paul,

note this is a lower-case review. Having looked at 8151705, thumbs up for this 
one as well - they go hand in hand and looking at one of them only doesn't feel 
right. :-)

Best,

Michael

> Am 08.04.2016 um 11:56 schrieb Paul Sandoz <paul.san...@oracle.com>:
> 
> Hi,
> 
> Please review:
> 
>  
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151706-VH-form-table-stable/webrev/
>  
> <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151706-VH-form-table-stable/webrev/>
> 
> Now that @Stable arrays are supported by C1 (thanks Vladimir!) we can switch 
> from the explicit use of MemberName fields in VarForm to a @Stable 
> MemberName[] array.
> 
> I also took the opportunity to simplify the linking from a VarHandle impl to 
> MemberName[] array, now that the implementation has settled down. This will 
> reduce initialization costs and memory churn.
> 
> 
> I held off making further improvements for now. For example, VarForm can 
> probably go away (also removing the dependency on ClassValue). A VarHandle 
> instance can directly hold a MemberName[] array whose source reference is 
> statically held on the associated VarHandle implementation. It should also be 
> possible to lazily create MemberName instances as required, rather than 
> aggressively doing so, which may further reduce initialization costs and 
> memory usage in common cases.
> 
> Paul.

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR 8152645 VarHandle lookup access control tests

[Michael Haupt]

Hi Paul,

note this is a lower-case review. Thumbs up.

I like how the test lucidly documents the access rules, and would applaud an 
extended test that additionally covers module boundaries.

Just as a suggestion, how about using the fact that enum values are technically 
instances of subclasses of the enum and getting rid of the switches in 
FieldLookup.lookup/isAccessibleField by replacing the two with overridden 
methods in each of the enum elements? Switching over "this" just calls for 
polymorphism, and the default cases are dead code. Admittedly, it's a matter of 
style. :-)

Best,

Michael

> Am 07.04.2016 um 11:07 schrieb Paul Sandoz <paul.san...@oracle.com>:
> 
> Hi,
> 
> Please review a test to verify access control of looking up fields using a 
> VarHandle:
> 
>  
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8152645-VH-access-control/webrev/
>  
> <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8152645-VH-access-control/webrev/>
> 
> For completeness i also added tests for MH as i could not find any such 
> existing tests.
> 
> 
> Further follow on work might be to test lookup to fields across module 
> boundaries.
> 
> Paul.

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR 8150829: Enhanced drop-args, identity and default constant, varargs adjustment

[Michael Haupt]

Hi Shilpi,

note this is not a *R*eview, but thumbs up, and I'll be happy to sponsor the 
push once a *R*eviewer agrees.

Best,

Michael

> Am 22.03.2016 um 12:41 schrieb shilpi.rast...@oracle.com:
> 
> Hi All,
> 
> Please review the following-
> 
> https://bugs.openjdk.java.net/browse/JDK-8150829
> http://cr.openjdk.java.net/~srastogi/8150829/webrev.04
> 
> 
> Thanks,
> Shilpi

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

RFR(XS): 8151778: TestLookup.java fails after push of JDK-8150782

[Michael Haupt]

Dear all,

please review this one-line fix.
Bug: https://bugs.openjdk.java.net/browse/JDK-8151778
Webrev: http://cr.openjdk.java.net/~mhaupt/8151778/webrev.00/

TestLookup is lacking a @compile directive.

Thanks,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

RFR(S): 8150782: findClass / accessClass throw unexpected exceptions

[Michael Haupt]

Dear all,

please review this change.
Bug: https://bugs.openjdk.java.net/browse/JDK-8150782
Webrev: http://cr.openjdk.java.net/~mhaupt/8150782/webrev.00/

The unexpected exceptions turned out to be non-issues; however it was advisable 
to add some explanations to the API documentation. Also, the change contains 
some tests that illustrate these cases.

CCC approval is pending.

Thanks,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(S): 8150957: j.l.i.MethodHandles.whileLoop(...) fails with IOOBE in the case 'init' is null, 'step' and 'pred' have parameters

[Michael Haupt]

Hi Paul,

> Am 03.03.2016 um 11:58 schrieb Paul Sandoz <paul.san...@oracle.com>:
> Minor comment, up to you to accept/reject: you could assert that “w.i” is the 
> expected value after the loop invocation.

thank you. Excellent suggestion, I'll push with that added.

Best,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(M): 8150832: split T8139885 into several tests by functionality

[Michael Haupt]

Hi Claes,

thanks a lot, and I agree with the renaming.

Best,

Michael

> Am 02.03.2016 um 13:59 schrieb Claes Redestad <claes.redes...@oracle.com>:
> 
> Hi,
> 
> this looks good to me.
> 
> Maybe rename LoopTest to LoopCombinatorTest to add a bit of specificity?
> 
> /Claes
> 
> On 2016-03-02 13:46, Michael Haupt wrote:
>> Dear all,
>> 
>> please review this change.
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8150832
>> Webrev: http://cr.openjdk.java.net/~mhaupt/8150832/webrev.00
>> 
>> This is a refactoring; the monolithic test for JEP 274 was split into 
>> several tests along functionality covered. Also, data providers and other 
>> declarative annotations were introduced where it made sense.
>> 
>> Thanks,
>> 
>> Michael
>> 
> 

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

RFR(M): 8150832: split T8139885 into several tests by functionality

[Michael Haupt]

Dear all,

please review this change.
RFE: https://bugs.openjdk.java.net/browse/JDK-8150832
Webrev: http://cr.openjdk.java.net/~mhaupt/8150832/webrev.00

This is a refactoring; the monolithic test for JEP 274 was split into several 
tests along functionality covered. Also, data providers and other declarative 
annotations were introduced where it made sense.

Thanks,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

RFR(XS): 8150953: j.l.i.MethodHandles: example section in whileLoop(...) provides example for doWhileLoop

[Michael Haupt]

Dear all,

please review this fix.
Bug: https://bugs.openjdk.java.net/browse/JDK-8150953
Webrev: http://cr.openjdk.java.net/~mhaupt/8150953/webrev.00/

The API docs and corresponding JavaDocExampleTest test case for 
MethodHandles.whileLoop() wrongly used the example for 
MethodHandles.doWhileLoop().

Thanks,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(M): 8150635: j.l.i.MethodHandles.loop(...) throws IndexOutOfBoundsException

[Michael Haupt]

Hi Paul,

> Am 29.02.2016 um 14:46 schrieb Paul Sandoz <paul.san...@oracle.com>:
>> A new webrev with the above changes (save the renaming) is at 
>> http://cr.openjdk.java.net/~mhaupt/8150635/webrev.01
>> 
> 
> +1

thank you. I'll push once CCC approves.

Best,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(M): 8150635: j.l.i.MethodHandles.loop(...) throws IndexOutOfBoundsException

[Michael Haupt]

Hi Paul,

thank you for your comments. BTW I filed a CCC request in the meantime, as this 
change also affects the details of when exceptions are thrown. Answers below ...

> Am 29.02.2016 um 12:23 schrieb Paul Sandoz <paul.san...@oracle.com>:
> MethodHandles.java
> —
> 
> ...
> You can use List.of() (or before that method was added 
> Collections.emptyList()) for the empty list as the returned lists will be 
> unmodifiable (that returned from MethodType.parameterList is).

Right, thanks.

> We also know in the second case that the stream can never be empty so 
> arguably a get is sufficient, but that is just a trivial comment (really we 
> want to assert, and the second best thing there would be a orElseThrow, but 
> it looks odd in this context perhaps).

Indeed the list cannot be empty, and the stream will always produce a result, 
so get() it is. Thanks!

>> * @apiNote Example:
>> * {@code
>> * // iterative implementation of the factorial function as a loop handle
>> * static int one(int k) { return 1; }
>> * int inc(int i, int acc, int k) { return i + 1; }
>> ...
> 
> Do you need to update this example since it is referring to virtual methods? 
> since you need to permute the arguments.

I've updated it to use static methods only, which was the intent, and which is 
what JavaDocExamplesTest covers. A test for using virtual methods was added 
anyway.

> T8139885.java
> —
> 
> Could we rename that test to say “LoopCombinatorTest” ?

With more and more bugs being covered by this test, that clearly makes sense. 
:-) I like the suggestion to split the test in several ones you made in 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-February/039138.html 
- I've filed the RFE here: https://bugs.openjdk.java.net/browse/JDK-8150832

A new webrev with the above changes (save the renaming) is at 
http://cr.openjdk.java.net/~mhaupt/8150635/webrev.01

Best,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(S): 8150825: MethodHandles.tryFinally throws IndexOutOfBoundsException for non-conforming parameter lists

[Michael Haupt]

Hi Claes,

> Am 29.02.2016 um 13:59 schrieb Claes Redestad <claes.redes...@oracle.com>:
> Looks good to me!

thank you!

> (Slightly off-topic: would it be possible to rename the test to something 
> more descriptive, or is such things frowned upon?)

This being the second Reviewer request, and the naming having nagged me for a 
while, I'll do it at some point in the near future (probably by piggybacking 
the renaming onto something else). :-)

Best,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

RFR(S): 8150825: MethodHandles.tryFinally throws IndexOutOfBoundsException for non-conforming parameter lists

[Michael Haupt]

Dear all,

please review this fix.
Bug: https://bugs.openjdk.java.net/browse/JDK-8150825
Webrev: http://cr.openjdk.java.net/~mhaupt/8150825/webrev.00

The logic for checking conformance of tryFinally arguments did not take a too 
short target parameter type list into account.

Thanks,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

RFR(M): 8150635: j.l.i.MethodHandles.loop(...) throws IndexOutOfBoundsException

[Michael Haupt]

Dear all,

please review this fix.
Bug: https://bugs.openjdk.java.net/browse/JDK-8150635
Webrev: http://cr.openjdk.java.net/~mhaupt/8150635/webrev.00

There were two issues to address that led to IOOBE being thrown.

1. Lack of support for deriving the loop signature from given parameter type 
lists in case no init function is given at all.

2. The loop combinator reporting a wrong exception in case a parameter type 
list is longer than the common parameter sequence. In this case, an error about 
non-effectively identical parameter type lists should be signalled.

See the JIRA issue for details and examples.

Thanks,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(S): 8143410: augment pseudo-code descriptions in MethodHandles API

[Michael Haupt]

Hi Paul,

thanks - all right; I'll consider using "and" rather than "/" and push the 
result.

Best,

Michael

> Am 23.02.2016 um 09:13 schrieb Paul Sandoz <paul.san...@oracle.com>:
> 
>> 
>> On 23 Feb 2016, at 07:39, Michael Haupt <michael.ha...@oracle.com> wrote:
>> 
>> Hi Paul,
>> 
>> thank you. I'm holding off on pushing; a new webrev is at 
>> http://cr.openjdk.java.net/~mhaupt/8143410/webrev.01. See below for two 
>> specific comments.
>> 
>>> Am 22.02.2016 um 21:45 schrieb Paul Sandoz <paul.san...@oracle.com>:
>>>> Webrev: http://cr.openjdk.java.net/~mhaupt/8143410/webrev.00
>>>> 
>>>> The change documents the type variables used in the pseudo-code in the API 
>>>> documentation of the following methods in MethodHandles: catchException(), 
>>>> collectArguments(), filterArguments(), filterReturnValue(), 
>>>> foldArguments(), and guardWithTest().
>>> 
>>> Just minor stuff:
>>> 
>>> 2642  * Here is pseudocode for the resulting adapter. In the code, 
>>> {@code T}
>>> 2643  * denotes the return type of both the {@code target} and 
>>> resulting adapter.
>>> 2644  * {@code P}/{@code p} and {@code B}/{@code b} represent the types 
>>> / values
>>> 2645  * of the parameters / arguments that precede / follow the filter 
>>> position
>>> 2646  * {@code pos}. {@code A[i]}/{@code a[i]} stand for the types / 
>>> values of
>>> 
>>> 
>>> "precede / follow ..." -> "proceed and follow …, respectively” ? like that 
>>> for the last modified method doc.
>> 
>> That's "precede" as in "coming before in the list". "Proceed" wouldn't make 
>> sense in this context. Or did you mean "... respectively" should be 
>> appended? (In the webrev, I've applied the latter.)
>> 
> 
> Oops, I typed “proceed and follow …, respectively” but meant “precede and 
> follow…, respectively” :-)
> 
> Tis a minor thing, I find the use of “and” rather than “/“ flows better, 
> given the already heavy use of ‘/‘.
> 
> 
>>> 2884  * }
>>> 2885  * Here is pseudocode for the resulting adapter. In the code, 
>>> {@code V}
>>> 2886  * represents the result type of the {@code target}; {@code T}, 
>>> that of the
>>> 2887  * {@code filter}; and {@code A}/{@code a}, the types / values of 
>>> the
>>> 2888  * parameters / arguments of the {@code target} as well as the 
>>> resulting
>>> 2889  * adapter.
>>> 2890  * {@code
>>> 2891  * V target(A...);
>>> 2892  * T filter(V);
>>> 
>>> 
>>> Should target return a type of T, and filter V for consistency with the 
>>> other pseudocode examples? That might be more changes than you wanna apply 
>>> in this case :-)
>> 
>> You're right, the naming should be consistent. I've applied this throughout.
>> 
> 
> Ok.
> 
> Paul.

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(S): 8143410: augment pseudo-code descriptions in MethodHandles API

[Michael Haupt]

Hi Paul,

thank you. I'm holding off on pushing; a new webrev is at 
http://cr.openjdk.java.net/~mhaupt/8143410/webrev.01. See below for two 
specific comments.

> Am 22.02.2016 um 21:45 schrieb Paul Sandoz <paul.san...@oracle.com>:
>> Webrev: http://cr.openjdk.java.net/~mhaupt/8143410/webrev.00
>> 
>> The change documents the type variables used in the pseudo-code in the API 
>> documentation of the following methods in MethodHandles: catchException(), 
>> collectArguments(), filterArguments(), filterReturnValue(), foldArguments(), 
>> and guardWithTest().
> 
> Just minor stuff:
> 
> 2642  * Here is pseudocode for the resulting adapter. In the code, 
> {@code T}
> 2643  * denotes the return type of both the {@code target} and resulting 
> adapter.
> 2644  * {@code P}/{@code p} and {@code B}/{@code b} represent the types / 
> values
> 2645  * of the parameters / arguments that precede / follow the filter 
> position
> 2646  * {@code pos}. {@code A[i]}/{@code a[i]} stand for the types / 
> values of
> 
> 
> "precede / follow ..." -> "proceed and follow …, respectively” ? like that 
> for the last modified method doc.

That's "precede" as in "coming before in the list". "Proceed" wouldn't make 
sense in this context. Or did you mean "... respectively" should be appended? 
(In the webrev, I've applied the latter.)

> 2884  * }
> 2885  * Here is pseudocode for the resulting adapter. In the code, 
> {@code V}
> 2886  * represents the result type of the {@code target}; {@code T}, that 
> of the
> 2887  * {@code filter}; and {@code A}/{@code a}, the types / values of the
> 2888  * parameters / arguments of the {@code target} as well as the 
> resulting
> 2889  * adapter.
> 2890  * {@code
> 2891  * V target(A...);
> 2892  * T filter(V);
> 
> 
> Should target return a type of T, and filter V for consistency with the other 
> pseudocode examples? That might be more changes than you wanna apply in this 
> case :-)

You're right, the naming should be consistent. I've applied this throughout.

Best,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(S): 8150360: augment/correct MethodHandle API documentation

[Michael Haupt]

Hi Paul,

> Am 22.02.2016 um 21:22 schrieb Paul Sandoz <paul.san...@oracle.com>:
> Looks good. Minor thing, no need for another webrev round.
> 
> MethodHandles
> —
> 
> 3849  * The {@code target} and {@code cleanup} handles must have the same 
> corresponding argument and return types, except
> 3850  * that the {@code cleanup} handle may omit trailing arguments. 
> Also, the {@code cleanup} must have one or two extra
> 3851  * leading parameters:
> 
> Either “Also, the {@code cleanup} handle must...” or “Also, {@code cleanup} 
> must…” ?


thank you. Fixed and pushed.

Best,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

RFR(S): 8143410: augment pseudo-code descriptions in MethodHandles API

[Michael Haupt]

Dear all,

please review this (doc-only) fix.
Bug: https://bugs.openjdk.java.net/browse/JDK-8143410
Webrev: http://cr.openjdk.java.net/~mhaupt/8143410/webrev.00

The change documents the type variables used in the pseudo-code in the API 
documentation of the following methods in MethodHandles: catchException(), 
collectArguments(), filterArguments(), filterReturnValue(), foldArguments(), 
and guardWithTest().

Thanks,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

RFR(S): 8150360: augment/correct MethodHandle API documentation

[Michael Haupt]

Dear all,

please review this (doc-only) fix.
Bug: https://bugs.openjdk.java.net/browse/JDK-8150360
Webrev: http://cr.openjdk.java.net/~mhaupt/8150360/webrev.00

The fix addresses one contradiction in the API documentation of 
MethodHandles.tryFinally(), and adds the following note to the API 
documentation of the method handle combinators given below:

+ * 
+ * Note: The resulting adapter is never a {@linkplain 
MethodHandle#asVarargsCollector
+ * variable-arity method handle}, even if the original target method 
handle was.

* MethodHandle.asCollector(), .bindTo()
* MethodHandles.collectArguments(), .dropArguments(), .filterArguments(), 
.filterReturnValue(), .foldArguments(), .permuteArguments()

Thanks,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR 8144931: Assert class signatures are correct and refer to valid classes

[Michael Haupt]

All,

I'll sponsor this.

Best,

Michael

> Am 19.02.2016 um 12:37 schrieb Paul Sandoz <paul.san...@oracle.com>:
> 
> 
>> On 19 Feb 2016, at 06:32, shilpi.rast...@oracle.com wrote:
>> 
>> Hi All,
>> 
>> Please see the updated webrev
>> http://cr.openjdk.java.net/~srastogi/8144931/webrev.03/
>> 
> 
> +1
> 
> Paul.

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR: 8071368 Use more concrete types for NamedFunction constants in the code

[Michael Haupt]

Hi,

I'll be happy to sponsor this.

Best,

Michael

> Am 10.02.2016 um 09:03 schrieb Paul Sandoz <paul.san...@oracle.com>:
> 
> Hi Shilpi,
> 
> I think you can consider this reviewed. It got the ok from Vladimir, with 
> reference to John’s feedback in the bug.
> 
> Pau.
> 
>> On 10 Feb 2016, at 08:01, shilpi rastogi <shilpi.rast...@oracle.com> wrote:
>> 
>> 
>> Gentle Reminder!
>>> 
>>> On 2/5/2016 9:18 PM, Vladimir Ivanov wrote:
>>>> Proposed fix looks good.
>>>> 
>>>> Quoting John: "The use of erased types (any ref => Object) in the MH 
>>>> runtime is an artifact of bootstrapping difficulties, early in the 
>>>> project. I hope it is not necessary any more."
>>>> 
>>>> Best regards,
>>>> Vladimir Ivanov
>>>> 
> 

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR 8138884:MethodHandles.Lookup.findVirtual() Javadoc fails to consider private interface methods

[Michael Haupt]

Hi,

I'll be happy to sponsor this.

Best,

Michael

> Am 10.02.2016 um 09:06 schrieb Paul Sandoz <paul.san...@oracle.com>:
> 
> 
>> On 10 Feb 2016, at 08:00, shilpi rastogi <shilpi.rast...@oracle.com> wrote:
>> 
>> Hi All,
>> 
>> Please review my updated patch
>> http://cr.openjdk.java.net/~srastogi/8138884/webrev.01/ 
>> <http://cr.openjdk.java.net/~srastogi/8138884/webrev.01/>
>> 
> 
> Just add a “,” after the new statement
> 
>  .. {@code static},
> 
> No need for another review.
> 
> 
>> Same is not applicable for "Lookup.unreflect()".
>> 
> 
> Ok. Thanks for checking.
> 
> Paul.

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR 8138578:MethodHandles.Lookup.findSpecial() Javadoc fails to consider static methods

[Michael Haupt]

Hi all,

lower-case thumbs up, and I'll be happy to sponsor this push.

Best,

Michael

> Am 08.02.2016 um 14:26 schrieb Vladimir Ivanov <vladimir.x.iva...@oracle.com>:
> 
> Looks good.
> 
> Best regards,
> Vladimir Ivanov
> 
> On 1/29/16 3:43 PM, shilpi rastogi wrote:
>> Hi All,
>> 
>> Please review the updated patch-
>> 
>> http://cr.openjdk.java.net/~srastogi/8138578/webrev.01/
>> 
>> I verified Lookup.unreflectSpecial() also throws
>> java.lang.IllegalAccessException so updated the JavaDoc.
>> 
>> Thanks,
>> Shilpi


-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: API review of VarHandles

[Michael Haupt]

Hi Martin,

how about seeing j.l.i as a framework for lightweight reflection on the one 
hand, and for method handle-based meta-programming on the other? That's clearly 
usable beyond the domain of dynamic language implementation. Granted, the 
latter remains an important application area, but there are others. For 
example, JEP 280 uses invokedynamic for string concatenation.

In that vein, how about seeing VarHandles as a safer replacement for some of 
the Unsafe API? It's going to be public API, readily usable without having to 
enable access to the carefully tucked-away Unsafe.

Best,

Michael

> Am 26.01.2016 um 21:31 schrieb Martin Buchholz <marti...@google.com>:
> 
> There's a big "expectations" effect here.  j.l.invoke is "supposed to
> be" for making dynamic languages less slow, not for making low-level,
> ultra-non-dynamic operations faster.  Asking the Unsafe users of the
> world to switch to dynamic VarHandle is like asking C programmers to
> rewrite their code in perl 6 ... for performance!  It's the same
> "srsly?" feeling one gets reading """We can currently use RPerl to
> speed up low-magic Perl 5 code with over 300x performance gain."""

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

RFR(S): 8147078: MethodHandles.catchException does not enforce Throwable subtype

[Michael Haupt]

Dear all,

please review this fix.
Bug: https://bugs.openjdk.java.net/browse/JDK-8147078
Webrev: http://cr.openjdk.java.net/~mhaupt/8147078/webrev.00

Unlike MethodHandles.throwException, MethodHandles.catchException does not 
enforce that the passed exception type is indeed a subtype of Throwable. The 
change adds the corresponding check, and a test.

Thanks,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

RFR(S): 8146786: [TESTBUG] straighten out testability for several issues

[Michael Haupt]

Dear all,

please review this fix.
Bug: https://bugs.openjdk.java.net/browse/JDK-8146786
Webrev: http://cr.openjdk.java.net/~mhaupt/8146786/webrev.00/

The fix adds some missing @bug annotations in tests and contributes two files 
that were accidentally not pushed earlier.

Thanks,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

RFR(XS): 8081512: Remove sun.invoke.anon classes, or move / co-locate them with tests

[Michael Haupt]

Dear all,

please review and sponsor this change.
RFE: https://bugs.openjdk.java.net/browse/JDK-8081512
Webrev: http://cr.openjdk.java.net/~mhaupt/8081512/webrev.00/

The change removes the sun.invoke.anon package and one pertaining test.

Thanks,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(XS): 8081512: Remove sun.invoke.anon classes, or move / co-locate them with tests

[Michael Haupt]

(... please ignore the "and sponsor" part ...)

> Am 08.12.2015 um 10:37 schrieb Michael Haupt <michael.ha...@oracle.com>:
> 
> Dear all,
> 
> please review and sponsor this change.
> RFE: https://bugs.openjdk.java.net/browse/JDK-8081512
> Webrev: http://cr.openjdk.java.net/~mhaupt/8081512/webrev.00/
> 
> The change removes the sun.invoke.anon package and one pertaining test.
> 
> Thanks,
> 
> Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(S): 8144723: MethodHandleImpl.initStatics is no longer needed

[Michael Haupt]

Hi Claes,

this is a lower-case review, but thumbs up. Truth or dare. ;-)

Best,

Michael

> Am 04.12.2015 um 17:28 schrieb Claes Redestad <claes.redes...@oracle.com>:
> 
> Hi,
> 
> please review this issue to remove explicit initialization of 
> MethodHandleImpl, which doesn't seem to be needed after recent j.l.invoke 
> bootstrap improvements.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8144723
> Webrev: http://cr.openjdk.java.net/~redestad/8144723/webrev.01/
> 
> This removes 21 classes from jdk9/dev startup. I additionally identified a 
> few eagerly initialized functions that can be made lazily initialized, which 
> defers 6 classes from loading eagerly in startup tests that use lambdas 
> explicitly.
> 
> Thanks!
> 
> /Claes

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

RFR(XS): 8072844: Use more efficient LambdaForm type representation

[Michael Haupt]

Dear all,

please review this change.
RFE: https://bugs.openjdk.java.net/browse/JDK-8072844
Webrev: http://cr.openjdk.java.net/~mhaupt/8072844/webrev.00

Thanks,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(XS): 8072844: Use more efficient LambdaForm type representation

[Michael Haupt]

Dear all,

thank you, Claes, Sundar, and Ulf - here's a new webrev: 
http://cr.openjdk.java.net/~mhaupt/8072844/webrev.01

The string signature is now only used in tracing and assertions, which is why 
caching it is not necessary.

Caching the method type might be worthwhile, but this requires further 
analysis: it is used in LF bytecode generation and DMH creation only. I'll keep 
it out of this change but bear it in mind.

Thanks,

Michael

> Am 03.12.2015 um 11:05 schrieb Michael Haupt <michael.ha...@oracle.com>:
> 
> Dear all,
> 
> please review this change.
> RFE: https://bugs.openjdk.java.net/browse/JDK-8072844
> Webrev: http://cr.openjdk.java.net/~mhaupt/8072844/webrev.00
> 
> Thanks,
> 
> Michael


-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(XS): 8072844: Use more efficient LambdaForm type representation

[Michael Haupt]

Hi Ulf,

the change (as of webrev.01) is pushed. Nevertheless, thanks for your comments 
- responses below.

> Am 03.12.2015 um 15:40 schrieb Ulf <ulf.zi...@cosoco.de>:
> why not simply? :
> 1282 MethodType type = mt.changeParameterType(0, MethodHandle.class);
> 
> In any case, the state of the external mt becomes changed, so better clone mt.

Cloning mt here is not necessary, as changeParameterType() will create a new MT 
instance. If that's what you mean.

> Additional suggestion to save the in and out packing with MethodType:
> 1279 static MemberName generateLambdaFormInterpreterEntryPoint(Type 
> rType, Type[] pTypes) {

A MethodType is an apt abstraction for what is needed here; I don't think 
breaking it up into its components would help much.

Thanks,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

RFR(S): 8143343: add JEP 274 Javadoc tests to JavaDocExamplesTest

[Michael Haupt]

Dear all,

please review this change.
RFE: https://bugs.openjdk.java.net/browse/JDK-8143343
Webrev: http://cr.openjdk.java.net/~mhaupt/8143343/webrev.00

The change adds the JEP 274 Javadoc tests to JavaDocExamplesTest and fixes 
three glitches in the pertaining Javadoc.

Thanks,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

RFR(XS): 8076596: BytecodeDescriptor.parseMethod doesn't work during bootstrapping

[Michael Haupt]

Dear all,

please review this change.
Bug: https://bugs.openjdk.java.net/browse/JDK-8076596
Webrev: http://cr.openjdk.java.net/~mhaupt/8076596/webrev.00/

The bug was actually fixed by the fix to 
https://bugs.openjdk.java.net/browse/JDK-8136893; the proposed change adds a 
test for the original bug. It is not reproducible in current 9-dev and jake 
builds.

Thanks,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR: 8143131: Remove unused code from java.lang.invoke

[Michael Haupt]

Hi Claes,

note that this is a lower-case review: thumbs up. Good catches! Thanks! :-)

Best,

Michael

> Am 01.12.2015 um 17:06 schrieb Claes Redestad <claes.redes...@oracle.com>:
> 
> Hi,
> 
> please review this patch to cleanup various things in and around 
> java.lang.invoke:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8143131
> Webrev: http://cr.openjdk.java.net/~redestad/8143131/webrev.01/
> 
> /Claes

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

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

[Michael Haupt]

Hello,

FYI, I've requested backport approval for this fix to 8u.
http://mail.openjdk.java.net/pipermail/jdk8u-dev/2015-November/004540.html

Best,

Michael

> Am 09.11.2015 um 16:28 schrieb Michael Haupt <michael.ha...@oracle.com>:
> 
> ... thanks a lot, Peter and Vladimir!
> 
> Best,
> 
> Michael
> 
>> Am 09.11.2015 um 13:42 schrieb Vladimir Ivanov 
>> <vladimir.x.iva...@oracle.com>:
>> 
>> 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 SPECIES_DATA field of
>>> the generated class. It caught a bug I made when I specified a binary
>>> class name "java/lang/invoke/Stable" in FieldVisitor.visitAnnotation()
>>> instead of type signature "Ljava/lang/invoke/Stable;"
>>> 
>>> The consequence was not drastic - the field was just not being
>>> interpreted by VM as @Stable.
>>> 
>>> With that adjustment and successful re-run of jtreg tests, I ask for
>>> re-confirmation to push the following:
>>> 
>>>http://cr.openjdk.java.net/~plevart/jdk9-dev/BMH.race/webrev.07/
>>> 
>>> Regards, Peter
>>> 
>>> On 11/06/2015 01:31 PM, Vladimir Ivanov wrote:
>>>> Peter,
>>>> 
>>>>> 
>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/BMH.race/webrev.06/
>>>>> 
>>>> 
>>>> Looks really good! Reviewed.
>>>> 
>>>>> - the SPECIES_DATA field in generated class can not be static final when
>>>>> it is initialized out of . Just static. It was just static
>>>>> before when it was initialized in  and could be static final. We
>>>>> can make it @Stable at least.
>>>>> 
>>>> Not sure it is on hot path, but I'm all for marking the field as @Stable
>>>> 
>>>>> - there's no need for empty  method now. Removed.
>>>>> 
>>>>> Basic java/lang/invoke jtreg tests pass.
>>>> 
>>>> Best regards,
>>>> Vladimir Ivanov
>>> 
> 
> -- 
> 
> <http://www.oracle.com/>
> Dr. Michael Haupt | Principal Member of Technical Staff
> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
> Oracle Java Platform Group | LangTools Team | Nashorn
> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
> <http://www.oracle.com/commitment>Oracle is committed to developing 
> practices and products that help protect the environment
> 

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

RFR(S): 8143798: jck failures: api/java_lang/invoke/MethodHandle/index_MethodsTests[asSpreaderWMTE]: java.lang.VerifyError: Bad type on operand stack

[Michael Haupt]

Dear all,

please review this change.
Bug: https://bugs.openjdk.java.net/browse/JDK-8143798
Webrev: http://cr.openjdk.java.net/~mhaupt/8143798/webrev.00/

The issue is an array iteration boundary bug in the JEP 274 implementation.

Thanks,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(L): 8139885: implement JEP 274: enhanced method handles

[Michael Haupt]

Hi John, Paul,

thanks for your reviews - they have helped me polish the code and documentation 
some more and add some more tests. The result is at 
http://cr.openjdk.java.net/~mhaupt/8139885/webrev.02

I noticed both of you emphasised how the Streams API helps the implementation - 
I second that. Streams "made my day" there. :-)

I'm replying below to those of your remarks I didn't address in the new webrev.

> Am 19.11.2015 um 05:25 schrieb John Rose <john.r.r...@oracle.com>:
> My usual practice, though, is to move argument checking and error reporting 
> code out of line, away from the main logic.  I think this is good style, and 
> it gives the JIT a little bit (a very little bit) of help.

In the most generic loop combinator, the tests are somewhat dispersed over the 
implementation because they depend on results that are not readily available at 
the beginning of the method's execution. I haven't put them all in one test 
method because I prefer early failure with clear messages over possibly hard to 
interpret failure due to inconsistencies in mid-run.

> One wishful item:  It would be nice if the javadoc examples could be 
> integrated into JavaDocExamplesTest.java.  I see that is messy since we are 
> now using TestNG instead of JUnit.  The point of JavaDocExamplesTest was to 
> make it easy to "sync" the javadoc with the examples, by having one place to 
> copy-and-paste the javadoc.

I've filed this RFE for that: https://bugs.openjdk.java.net/browse/JDK-8143343

> Am 19.11.2015 um 11:45 schrieb Paul Sandoz <paul.san...@oracle.com>:
> I have a mild preference to maintain the 80 char limit for JavaDoc, to me 
> it’s easier to read. For code i don’t mind a 100 or more limit.

The formatting in the files I've touched is inconsistent; I'll stick with the 
120 character limit for both code and Javadoc.

> 3458  * The loop handle's result type is the same as the sole loop 
> variable's, i.e., the result type of {@code init}.
> 
> s/variable’s/variable ?

No; the genitive is intentional (result type = loop variable type, rather than 
result type = loop variable).

> I guess in the future there may be ample opporunity to specialize the generic 
> “loop” mechanism with LambdaForms?

Yep: https://bugs.openjdk.java.net/browse/JDK-8143211

Best,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 <http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment