Re: RFR JDK-8141491: Unaligned memory access in Bits.c

On 26/01/2016 04:57, Mikael Vidstedt wrote: I've finally found some time to return to this and have a new version of the patch which looks more promising: http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.02/webrev/ This uses memcpy to read/write the native data and the preliminary

RFR [9] 8148220: Update TEST.groups to include jdk/internal/math and jdk/internal/misc

The test groups, that make up jdk_core, should be updated to include jdk/internal/math and jdk/internal/misc. These updates were overlooked when doing re-orgaziation and cleanup in preparation for JEP 260. diff --git a/test/TEST.groups b/test/TEST.groups --- a/test/TEST.groups +++

Re: Regarding the removal of com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java

Hi Christoph, Instead of trying to access com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java in your test - would it be possible for your test to embed that functionality instead? I am not sure how much sense that makes - the workings of that class seemed a bit convoluted - and not

Re: Stream.limit parallel ordered performance

Hi Tagir, It is insane :-) in hindsight i cannot believe i missed this trick! You patch looks reasonable and i don’t see any issue with it. Each leaf-task will collect at most n elements. The truncation will take care of everything else. Note that it is still the case that in almost all

Re: ClassFileTransformer does not apply to anonymous classes

Hi Remi, this is what I am doing. At least using Byte Buddy, you turn a switch such that Byte Buddy redefines the LambdaMetafactory to spin custom classes where Byte Buddy also applies a ClassFileTransformer. Currently this results in the (almost) exact class file as if the default

Re: ClassFileTransformer does not apply to anonymous classes

Hello, - Mail original - > De: "Rafael Winterhalter" > À: "Remi Forax" > Cc: "Vladimir Ivanov" , "Coleen Phillimore" > , > core-libs-dev@openjdk.java.net, "serguei.spit...@oracle.com

Re: RFR 8147505: Clarification of BaseStream.onClose() behavior

Hi Tagir, StreamCloseTest.java — 181 try(Stream s = countTo(100).stream()) { 182 s.map(x -> x).forEach(i -> {}); 183 checkISE(() -> s.onClose(() -> fail("2"))); 184 } We don’t need this one, it’s redundant. The other performing the s.close() is i

Re: RFR 8148115: Stream.findFirst for unordered source optimization

Hi Tagir, Looks good. Just small things. FindOps.java — 293 if (!this.mustFindFirst) { 310 if (this.mustFindFirst) { Small thing, no need for “this”. LambdaTestHelpers — 404 public static void assertContains(Optional actual, Iterator it) { 405 if

Re: ClassFileTransformer does not apply to anonymous classes

On 26/01/16 08:39, Rafael Winterhalter wrote: > Another note on this subject: I found that applying a > reretransformation on a lambda expression's class does not provide the > original class file to the retransformer but the class file that > resulted from a previous retransformation. (If a

Re: RFR JDK-8141491: Unaligned memory access in Bits.c

On 26/01/16 04:57, Mikael Vidstedt wrote: > > I've finally found some time to return to this and have a new version of > the patch which looks more promising: > > http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.02/webrev/ > > This uses memcpy to read/write the native data and the

RE: RFR: JDK-8147912: test "parseWithZoneWithoutOffset" of java/time/tck/java/time/format/TCKDTFParsedInstant.java fail on de_DE locale

Hi all, Please help me in reviewing this test fix. Regards, Ramanand. From: Ramanand Patil Sent: Monday, January 25, 2016 1:05 PM To: i18n-...@openjdk.java.net Cc: core-libs-dev@openjdk.java.net Subject: RFR: JDK-8147912: test "parseWithZoneWithoutOffset" of

Re: RFR: JDK-8147912: test "parseWithZoneWithoutOffset" of java/time/tck/java/time/format/TCKDTFParsedInstant.java fail on de_DE locale

Looks OK to me. But I'd like some java.time people to review this change to see if the intention of this test is to run only in English. Thanks, Masayoshi On 1/27/2016 1:51 PM, Ramanand Patil wrote: Hi all, Please help me in reviewing this test fix. Regards, Ramanand. From:

RE: RFR: JDK-8147912: test "parseWithZoneWithoutOffset" of java/time/tck/java/time/format/TCKDTFParsedInstant.java fail on de_DE locale

Hi Masayoshi, Thank you for review. This test was contributed by me for bug HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8066982"JDK-8066982. Running this only in English should be Ok as per me, since this was added just to test one of the parsing scenario when Zone information is

Re: ClassFileTransformer does not apply to anonymous classes

Another note on this subject: I found that applying a reretransformation on a lambda expression's class does not provide the original class file to the retransformer but the class file that resulted from a previous retransformation. (If a lambda class is retransformed several times.) This is

Re: RFR: 8076458: java/util/stream/test/org/openjdk/tests/java/util/stream/FlatMapOpTest.java timeout

Hi Hamlin, Conservatively I would prefer not to remove data sets if at all possible. It will affect all tests, and leaf tasks for parallel streams should have enough data to crunch on. I suspect the problem of the flatMap test is not necessarily due to the source sizes being of 1000 elements

Re: RFR:8146218: Producing streams in java.time?

> On 25 Jan 2016, at 18:47, Xueming Shen wrote: > > The proposed change looks fine with me. > Yes, +1 nice work. Paul.

Re: RFR:8146218: Producing streams in java.time?

While there is no blockng reason why the concept could not be pulled up to ChronoLocalDate, the method signatures would differ. LocalDate::datesUntil(LocalDate) LocalDate::datesUntil(LocalDate, Period) ChronoLocalDate::datesUntil(ChronoLocalDate) ChronoLocalDate::datesUntil(ChronoLocalDate,

Re: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

It is wonderful to see the various ideas on this thread about the longer term solution to the prompt releasing of direct buffer native memory. I do not want to obstruct that ( it is very informative ), but I’d like to warp up the review on the actual moving of Cleaner. To that end, I’ve update

RE: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

Hi, looks good to me. Once we have EA builds with that I will adapt the ByteBufferIndexInput code in Lucene. One thing about the Runable: This should work perfectly fine, because we only need to make call the getCleaner() method accessible, call it and finally check if return type implements

Re: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

On 26/01/2016 14:05, Uwe Schindler wrote: Hi, looks good to me. Once we have EA builds with that I will adapt the ByteBufferIndexInput code in Lucene. One thing about the Runable: This should work perfectly fine, because we only need to make call the getCleaner() method accessible, call it

RE: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

Hi, > On 26/01/2016 14:05, Uwe Schindler wrote: > > Hi, > > > > looks good to me. Once we have EA builds with that I will adapt the > ByteBufferIndexInput code in Lucene. > > > > One thing about the Runable: This should work perfectly fine, because we > only need to make call the getCleaner()

Re: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

Hi Chris, Looks fine. Perhaps update the copyrights. Upgrading the shell based test to java based would be good sometime too. Also, there is a more recent version of webrev [1] that provides convenient next and previous links. Thanks, Roger [1]

Re: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

On 26/01/2016 13:55, Chris Hegarty wrote: It is wonderful to see the various ideas on this thread about the longer term solution to the prompt releasing of direct buffer native memory. I do not want to obstruct that ( it is very informative ), but I’d like to warp up the review on the actual

Re: API review of VarHandles

Hi Many thanks for the feedback so far. Some high-level responses: 1) I don’t think there is much we can do right now to reduce the verbosity of reflective lookup. We have discussed this at least once before in the past. We need field literals, as mentioned in the JEP, to really knock this on

Re: 8148250 Stream.limit parallel ordered performance

Hello! Thank you for review! Here's the issue: https://bugs.openjdk.java.net/browse/JDK-8148250 Will post complete webrev later. PS> Note that it is still the case that in almost all scenarios this PS> is likely to be a bad form of parallel stream. Well not always it's possible to estimate in

Re: RFR JDK-8141491: Unaligned memory access in Bits.c

On 1/26/16 4:28 AM, Alan Bateman wrote: On 26/01/2016 04:57, Mikael Vidstedt wrote: I've finally found some time to return to this and have a new version of the patch which looks more promising: http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.02/webrev/ This uses memcpy to

Re: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

Hi Chris, Looks good, thanks for updating the test. One typo: "Unexpected *exist *code" Roger On 1/26/2016 11:27 AM, Chris Hegarty wrote: Latest webrev updated in-place: http://cr.openjdk.java.net/~chegar/8148117/ * to execute the run method requires an appropriate permission *

Re: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

Latest webrev updated in-place: http://cr.openjdk.java.net/~chegar/8148117/ * to execute the run method requires an appropriate permission * reverted any copyright changes ( leave to a bulk update ) * updated the test to remove the script -Chris. On 26 Jan 2016, at 15:23, Alan Bateman

RE: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

Hi, API changes l and security check look good to me. I don't have time to compile and test a JDK, but I trust you that it works :-) Uwe - Uwe Schindler uschind...@apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -Original Message-

Re: 8148250 Stream.limit parallel ordered performance

> On 26 Jan 2016, at 16:51, Tagir F. Valeev wrote: > > Hello! > > Thank you for review! Here's the issue: > https://bugs.openjdk.java.net/browse/JDK-8148250 > Will post complete webrev later. > > PS> Note that it is still the case that in almost all scenarios this > PS> is

Re: RFR: JDK-8146568 NegativeArraySizeException in ArrayList.grow(int)

On Tue, Jan 26, 2016 at 5:44 AM, Jason Mehrens wrote: > Hi Martin, > > Are you sure about the change where addElement is now calling the public > (non-final) version of add? I would think that we would want to avoid any > type of compatibility changes with regard to

Re: RFR: JDK-8146568 NegativeArraySizeException in ArrayList.grow(int)

webrev refreshed - http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Vector-grow/ On Tue, Jan 26, 2016 at 4:28 AM, Remi Forax wrote: > Hi Martin, > sorry for jumping on this conversation lately, > please don't be seduced by the dark side, Too late! I've already committed

Re: RFR JDK-8141491: Unaligned memory access in Bits.c

On 01/26/2016 06:32 PM, John Rose wrote: > On Jan 26, 2016, at 1:04 AM, Andrew Haley wrote: >> >> I agree that memcpy is the right thing to use. It's portable and is >> inlined well on production-quality C compilers. > > But it is not strong enough to uphold the Java memory

Re: RFR JDK-8141491: Unaligned memory access in Bits.c

On Jan 26, 2016, at 10:48 AM, Andrew Haley wrote: > > On 01/26/2016 06:32 PM, John Rose wrote: >> On Jan 26, 2016, at 1:04 AM, Andrew Haley wrote: >>> >>> I agree that memcpy is the right thing to use. It's portable and is >>> inlined well on

Re: RFR JDK-8141491: Unaligned memory access in Bits.c

On 01/26/2016 07:04 PM, John Rose wrote: > Unsafe.copyMemory bottoms out to Copy::conjoint_memory_atomic. > IMO that's a better starting point than memcpy. Perhaps it can be > given an additional parameter (or overloading) to specify a swap size. OK, but conjoint_memory_atomic doesn't guarantee

Re: RFR JDK-8141491: Unaligned memory access in Bits.c

On Jan 26, 2016, at 11:08 AM, Andrew Haley wrote: > > On 01/26/2016 07:04 PM, John Rose wrote: >> Unsafe.copyMemory bottoms out to Copy::conjoint_memory_atomic. >> IMO that's a better starting point than memcpy. Perhaps it can be >> given an additional parameter (or

Re: ClassFileTransformer does not apply to anonymous classes

Hi Vladimir, I have previously explored what you suggest (instrumenting the lambda exception's method bodies) but decided against it, mainly for three reasons: 1. Instrumentation has to be done more eagerly: To avoid redefinition (and the constraints involved), the instrumentation has to be

Re: API review of VarHandles

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

Re: RFR: JDK-8146568 NegativeArraySizeException in ArrayList.grow(int)

On 1/26/16 4:28 AM, Remi Forax wrote: please don't be seduced by the dark side, Clearly, he feels the call from light. :-) On 1/26/16 10:25 AM, Martin Buchholz wrote: webrev refreshed - http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Vector-grow/ Hi Martin, Thanks for the updates.

Re: API review of VarHandles

I think that expectation is just out of date (if not outright mistaken.) Yes, j.l.i was originally called "java.dyn", but prior to shipping *7* we renamed it to j.l.i precisely because it had turned into a general customizable linkage mechanism that was usable far beyond dynamic languages.

Re: API review of VarHandles

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

Re: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

> On Jan 26, 2016, at 8:27 AM, Chris Hegarty wrote: > > Latest webrev updated in-place: > http://cr.openjdk.java.net/~chegar/8148117/ > > * to execute the run method requires an appropriate permission > * reverted any copyright changes ( leave to a bulk update ) > *

Re: ClassFileTransformer does not apply to anonymous classes

VM anonymous classes are an implementation detail that is opaque to system components except for the lowest layers of the JDK runtime and the JVM itself. Transformers and other instrumentation should not look inside them expecting to interpose on their behavior. Ideally we should not make them

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

> On Jan 25, 2016, at 8:54 AM, Alan Bateman wrote: Somehow I missed this, sorry for the delayed response. >> >> Changed to BASE, i.e. Release.BASE >> > This looks better. Release.BASE is probably okay although it still feels like > Release.UNVERSIONED, esp. when it

Re: ClassFileTransformer does not apply to anonymous classes

Maybe this is a more graphic example of a problem that end-users currently face: http://stackoverflow.com/questions/33912026/intercepting-calls-to-java-8-lambda-expressions-using-byte-buddy 2016-01-26 10:02 GMT+01:00 : > Hello, > > - Mail original - >> De: "Rafael

Re: ClassFileTransformer does not apply to anonymous classes

Hi Rafael, why not providing a LambdaInterceptor as asked ? My point is that a lambda should be considered as a feature by itself instead as a way to create a class that implement an interface at runtime. If you do that, your code will still work when future release (maybe a point release),

Re: RFR [9] 8148220: Update TEST.groups to include jdk/internal/math and jdk/internal/misc

Looks fine to me Chris. Regards, Sean. On 26/01/2016 12:27, Chris Hegarty wrote: The test groups, that make up jdk_core, should be updated to include jdk/internal/math and jdk/internal/misc. These updates were overlooked when doing re-orgaziation and cleanup in preparation for JEP 260. diff

Re: RFR: JDK-8146568 NegativeArraySizeException in ArrayList.grow(int)

Hi Martin, sorry for jumping on this conversation lately, please don't be seduced by the dark side, I understand that the code is 1 byte bigger, but i think that the following code final int s = this.size; Object[] elementData = this.elementData; if (s == elementData.length) {