Re: RFR (XS): 8157188: 2 test failures in demo/jvmti due to unexpected class file version 53

On 19/05/2016 05:52, David Holmes wrote: Not sure who really owns this file so cc'ing core-libs and serviceability. bug: https://bugs.openjdk.java.net/browse/JDK-8157188 The file src/java.base/share/native/include/classfile_constants.h describes information about classfiles and is used by lib

Re: RFR (XS): 8157188: 2 test failures in demo/jvmti due to unexpected class file version 53

David, Looks good for me. Probably I was the last person who do something with java_crw_demo.c. -Dmitry On 2016-05-19 07:52, David Holmes wrote: > Not sure who really owns this file so cc'ing core-libs and serviceability. > > bug: https://bugs.openjdk.java.net/browse/JDK-8157188 > > The file

RFR (XS): 8157188: 2 test failures in demo/jvmti due to unexpected class file version 53

Not sure who really owns this file so cc'ing core-libs and serviceability. bug: https://bugs.openjdk.java.net/browse/JDK-8157188 The file src/java.base/share/native/include/classfile_constants.h describes information about classfiles and is used by libverify and ./demo/share/jvmti/java_crw_dem

Re: [PING] [9] RFR of 5100935: No way to access the 64-bit integer multiplication of 64-bit CPUs efficiently

Hi Brian, On 5/18/2016 8:16 PM, Brian Burkhalter wrote: Hi Joe, On May 18, 2016, at 5:37 PM, joe darcy > wrote: Sorry for the belated review. No worries. For multiplyFull, currently the wording is 833 * Returns the product of the arguments allowing ove

Re: [PING] [9] RFR of 5100935: No way to access the 64-bit integer multiplication of 64-bit CPUs efficiently

Hi Joe, On May 18, 2016, at 5:37 PM, joe darcy wrote: > Sorry for the belated review. No worries. > For multiplyFull, currently the wording is > > 833 * Returns the product of the arguments allowing overflowed values > within > 834 * the range of {@code long}. > > I think it would

RFR: 8156484: ZipFile retains too much native memory from caching Inflaters

Another batch of ZipFile hackery. I think I finally understand how weak references and finalizers interact. We could eliminate the Inflater cache entirely, but this proposal keeps a one-element Inflater cache. http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ZipFile-Inflater-cache/ https://bug

Re: [PING] Re: [9] RFR of 5100935: No way to access the 64-bit integer multiplication of 64-bit CPUs efficiently

Hi Brian, Sorry for the belated review. For multiplyFull, currently the wording is 833 * Returns the product of the arguments allowing overflowed values within 834 * the range of {@code long}. I think it would work about as something like "Returns the exact mathematical product

RFR(s): 8133977u1 add specification for serial form of immutable collections

Hi all, Please review this updated webrev/specdiff. Changes since previous: - removal of mention of CollSer from the API specification - make CollSer's Object[] field transient, and handle its contents as custom serial data in readObject/writeObject - specification changes to reflect t

RE: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version

Hi, Mandy. Thanks for taking the time to Review. >>http://cr.openjdk.java.net/~iris/verona/8144062/webrev.1/ > The change looks fine. Minor comments: > > 1178 * @throws IllegalArgumentException > 1179 * If the given string cannot be interpreted as a valid > 1180

Re: RFR(s): 8133977 add specification for serial form of immutable collections

On 5/18/16 2:42 AM, Stephen Colebourne wrote: My original blog on the topic was in 2010: http://blog.joda.org/2010/02/serialization-shared-delegates_9131.html Bear in mind that a key reason for sharing the serialization proxy is to share the "serialized object header, serial version UID, class d

RE: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version

Hi, Jon. >> http://cr.openjdk.java.net/~iris/verona/8144062/webrev.1/ > Langtools changes are OK, including the indirect use of the revised > Version in jar-fs. Thanks for the Review. Regards, Iris

[PING] Re: [9] RFR of 5100935: No way to access the 64-bit integer multiplication of 64-bit CPUs efficiently

Following up on the as yet unresolved thread initiated here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035289.html Thanks, Brian On Sep 21, 2015, at 11:15 AM, Brian Burkhalter wrote: > Hello, Sergey, > > On Sep 19, 2015, at 12:51 PM, Sergey Bylokhov > wrote: > >

[PING] Re: [9] RFR of 8023217: Additional floorDiv/floorMod/multiplyExact methods for java.lang.Math

Following up on the as yet unresolved thread initiated here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035468.html Thanks, Brian On Sep 29, 2015, at 5:49 PM, Brian Burkhalter wrote: > I revised floorMod(long x, int y) not to check explicitly check for integer > ove

Re: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version

Langtools changes are OK, including the indirect use of the revised Version in jar-fs. -- Jon On 05/13/2016 04:20 PM, Iris Clark wrote: Hi. Reviving this work from a few months back. Please review the following changes to move jdk.Version to jdk.lang.Runtime.Version. Bug 8144062: Move

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

Hi, I compared 8u65 and 9b116 performance on a simple Throwable.getStackTrace() JMH benchmark that I have, using a variety of call stack depths. Performance looks very similar between the two; if anything, 9b116 has a slight edge for larger stack depths. So I don't think the difference is d

Re: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version

> On May 13, 2016, at 4:20 PM, Iris Clark wrote: > > Hi. > > Reviving this work from a few months back. > > Please review the following changes to move jdk.Version to > jdk.lang.Runtime.Version. > > Bug > >8144062: Move jdk.Version to java.lang.Runtime.Version >https://bugs.openjdk.

Re: RFR: 8156807: Pack200 must support v53.0 class files

Will fix that, thanks for the reviews!. I was told by Amy, meanwhile this test has been added to ProblemList.txt so I will have to remove that line as well. Thanks Kumar On 05/18/2016 05:20 PM, Kumar Srinivasan wrote: The second part is fixing up the test, which does not read the process stre

Re: RFR 8154192: Deprivilege java.scripting module

> On May 18, 2016, at 12:55 AM, Sundararajan Athijegannathan > wrote: > > Please review the updated webrevs. > > * Fixed Modules.gmk for order of modules: > > http://cr.openjdk.java.net/~sundar/8154192/top/webrev.01/ > > * From quick reading of j.u.ServiceLoader: AccessControlContext is > ca

Re: RFR: 8156807: Pack200 must support v53.0 class files

On 05/18/2016 05:20 PM, Kumar Srinivasan wrote: > The second part is fixing up the test, which does not read the > process streams correctly and causes a test hang, simplified > the test with time tested utilities. > > http://cr.openjdk.java.net/~ksrini/8156807/webrev.00/ A very minor snag in Con

Re: Helpers for MethodHandles.byteArrayViewVarHandle VarHandle

> On 18 May 2016, at 16:50, Jaroslav Kameník wrote: > > Hi, > > thank you for response! > > I would prefer not to spread such functionality beyond that of ByteBuffer and > the VarHandle producing methods on MethodHandles. It’s an advanced feature so > think ok if less visible. > > > On the

Re: RFR: 8156807: Pack200 must support v53.0 class files

> On May 18, 2016, at 7:20 AM, Kumar Srinivasan > wrote: > > Hi, > > Alex or someone please review this simple fix, the first part is > simply bumping the class file version number, and some cleanup > of redundant constants in the native unpacker. > > The second part is fixing up the test, w

Re: Can an object be finalized while still weakly reachable?

Sherman, Thank you very much for pointing me at that old thread. I was indeed going down the same path and stumbling over the same obstacles! I still think we can do better, but it's definitely not easy. On Tue, May 17, 2016 at 8:15 AM, Xueming Shen wrote: > On 5/17/16 12:55 AM, Martin Buchhol

Re: Helpers for MethodHandles.byteArrayViewVarHandle VarHandle

Hi, thank you for response! > I would prefer not to spread such functionality beyond that of ByteBuffer > and the VarHandle producing methods on MethodHandles. It’s an advanced > feature so think ok if less visible. > > On the other side, this would be easier to use and understand than ByteBuffe

RFR: 8156807: Pack200 must support v53.0 class files

Hi, Alex or someone please review this simple fix, the first part is simply bumping the class file version number, and some cleanup of redundant constants in the native unpacker. The second part is fixing up the test, which does not read the process streams correctly and causes a test hang, sim

Re: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival

Brent, Have you considered increasing the visibility of just the EntrySet constructor from private to default access? This should get rid an extra generated class file if you compare the javac output since you are accessing just the constructor from the enclosing class. Jason ___

Re: RFR 8157152: Atomic add for VarHandle byte[]/ByteBuffer views is incorrect for endian conversion

Looks good. Best regards, Vladimir Ivanov On 5/18/16 2:24 PM, Paul Sandoz wrote: Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8157152-vh-array-views-atomic-add-endianness/webrev/

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

Thanks Vladimir! This is how I understood it, but I did not see the place in code where the actual switch between those "modes" is done, as I have seen they are compiled-up-front. The decision is made in LambdaForm.prepare() and LF.checkInvocationCounter(). MethodHandleStatics.COMPILE_THRE

Re: RFR (M) 8148604: JEP 280, Switch to more optimal concatenation strategy

+1 I think it's a good time to enable this. I do expect some impact to various startup tests based on some earlier experiments, but that will help us pinpoint areas to focus startup optimization efforts on going forward. Thanks! /Claes On 2016-05-18 14:09, Aleksey Shipilev wrote: Hi, We

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

Hi, > > P.S.: I am not so familiar with the intrinsic stuff, so here is my > > question: The > intrinsic for the array accesses is always created before caching the MH; so > why do we need the static implementation methods at all? I had the same > question also about the old element getters and s

Re: RFR (M) 8148604: JEP 280, Switch to more optimal concatenation strategy

> On 18 May 2016, at 14:09, Aleksey Shipilev > wrote: > > Hi, > > We have been waiting for this for at least 8 weeks, waiting for Jigsaw > to settle in, and hs-main -> jdk9/dev integration to happen that brings > a few testbug fixes into the jdk9/dev. > > Bug: > https://bugs.openjdk.java.net

RFR (M) 8148604: JEP 280, Switch to more optimal concatenation strategy

Hi, We have been waiting for this for at least 8 weeks, waiting for Jigsaw to settle in, and hs-main -> jdk9/dev integration to happen that brings a few testbug fixes into the jdk9/dev. Bug: https://bugs.openjdk.java.net/browse/JDK-8148604 Webrev: http://cr.openjdk.java.net/~shade/8148604/we

Re: RFR 8157152: Atomic add for VarHandle byte[]/ByteBuffer views is incorrect for endian conversion

> On 18 May 2016, at 13:44, Aleksey Shipilev > wrote: > > On 05/18/2016 02:24 PM, Paul Sandoz wrote: >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8157152-vh-array-views-atomic-add-endianness/webrev/ > > Looks horrible (as many other endianness fixes), but correct. Reviewed. > John would s

Re: RFR 8157152: Atomic add for VarHandle byte[]/ByteBuffer views is incorrect for endian conversion

On 05/18/2016 02:24 PM, Paul Sandoz wrote: > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8157152-vh-array-views-atomic-add-endianness/webrev/ Looks horrible (as many other endianness fixes), but correct. Reviewed. Thanks, -Aleksey

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

Hi Stanislav, yes please, file and assign to me. Best, Michael > Am 18.05.2016 um 12:52 schrieb stanislav lukyanov > : > > Hi Michael, > > I've noticed that neither the new method nor its friends, arrayElementGetter > and arrayElementSetter, > discuss the invocation-time behavior. > It seem

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

Uwe, P.S.: I am not so familiar with the intrinsic stuff, so here is my question: The intrinsic for the array accesses is always created before caching the MH; so why do we need the static implementation methods at all? I had the same question also about the old element getters and setters. O

RFR 8157152: Atomic add for VarHandle byte[]/ByteBuffer views is incorrect for endian conversion

Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8157152-vh-array-views-atomic-add-endianness/webrev/ The implementation for the atomic add methods for array and byte buffer vi

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

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 cor

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

Hi, looks good to me! I am also fine with the method name arrayLength() - my original proposal was arrayLengthGetter(); to be consistent with the element accessors: arrayElementGetter, arrayElementSetter. Uwe P.S.: I am not so familiar with the intrinsic stuff, so here is my question: The in

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

Hi Vladimir, pushed already. I'll piggyback this on a future change. Best, Michael > Am 18.05.2016 um 11:47 schrieb Vladimir Ivanov : > > src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java > +throw new AssertionError(); > > +throw new IllegalStateExcept

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

Hi, I noticed the same when skimming through the patch! I'd change this, too. Uwe - Uwe Schindler uschind...@apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -Original Message- > From: core-libs-dev [mailto:core-libs-dev-boun...@openjd

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

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

Re: RFR(s): 8133977 add specification for serial form of immutable collections

My original blog on the topic was in 2010: http://blog.joda.org/2010/02/serialization-shared-delegates_9131.html Bear in mind that a key reason for sharing the serialization proxy is to share the "serialized object header, serial version UID, class descriptor" etc. It is that header overhead that

Re: RFR 8154192: Deprivilege java.scripting module

Thanks. I'll make that change and push it. -Sundar On 5/18/2016 2:17 PM, Alan Bateman wrote: > On 18/05/2016 08:55, Sundararajan Athijegannathan wrote: >> Please review the updated webrevs. >> >> * Fixed Modules.gmk for order of modules: >> >> http://cr.openjdk.java.net/~sundar/8154192/top/webrev

Re: RFR 8154192: Deprivilege java.scripting module

On 18/05/2016 08:55, Sundararajan Athijegannathan wrote: Please review the updated webrevs. * Fixed Modules.gmk for order of modules: http://cr.openjdk.java.net/~sundar/8154192/top/webrev.01/ * From quick reading of j.u.ServiceLoader: AccessControlContext is captured in ServiceLoader construct

Re: MethodHandle for array length

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 : > > Hi, > > One addition, maybe add to issue: > > If this was added, jdk.dynalink module could use it, too - this was mentioned > by At

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

+1 Minor comment: File: MethodHandleImpl.java If "checks" can be inside the assert. + if (access == ArrayAccess.SET) assert(mh.type().parameterType(2) == Object.class); + if (access == ArrayAccess.GET) { + assert(mh.type().returnType() == Object.class); + assert(correctType.parameterType(0).getC

Re: RFR 8154192: Deprivilege java.scripting module

Please review the updated webrevs. * Fixed Modules.gmk for order of modules: http://cr.openjdk.java.net/~sundar/8154192/top/webrev.01/ * From quick reading of j.u.ServiceLoader: AccessControlContext is captured in ServiceLoader constructor & used for iteration (RestrictedIterator). So, ScriptEng

Re: MethodHandle for array length

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 : > > Hi, > > OK, thanks for creating an issue! > > Uwe > > - > Uwe Schindler > uschind...@apache.

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

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 -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331