Re: RFR [9] 8157154: jmod jlink properties file need copyright header

On 19/05/2016 22:56, Chris Hegarty wrote: Yes of course. I'll add the year range before pushing. -Chris Looks fine. There is someone on jdk9-dev with translations of this file where the missing headers came up too. -Alan.

Re: JDK 9 RFR of JDK-8157211: Mark tools/launcher/FXLauncherTest.java as intermittently failing

Would you please help to review the code change? Thank you -Hamlin On 2016/5/18 12:52, Hamlin Li wrote: tools/launcher/FXLauncherTest.java This test is known to fail intermittently (JDK-8130392 ), it should be marked accordingly with@key

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

Hi Brian, Looks okay; thanks, -Joe On 5/18/2016 12:06 PM, Brian Burkhalter wrote: 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

JDK 9 RFR of JDK-8151904: test/java/lang/StackWalker/VerifyStackTrace.java needs to handle update releases

The test currently hardcodes the version number "9". We should build a JDK with a different release number e.g. 9.1 and checks if this test handles it properly. Test run successfully on 9-ea+118, dummybundles(9-ea+255, 9.1-ea+255, 9.0.1-ea+255, 9.0.0.1-ea+255). bug:

Review request 8153042: jdeps should continue to report JDK internal APIs that are removed/renamed in JDK 9

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153042/webrev.00/index.html Several JDK internal APIs have been removed JDK 9. It’d be helpful to continue to flag those internal APIs if they are used by existing libraries. This fix is an interim solution. A longer-term solution may be for

Re: Review Request: 8157391: jdeps left JarFile open

We should have a debugging version of the JDK that fails whenever an AutoCloseable object is not properly closed in JDK code! On Thu, May 19, 2016 at 8:55 PM, Mandy Chung wrote: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157391/webrev.00/index.html > >

Review Request: 8157391: jdeps left JarFile open

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157391/webrev.00/index.html tools/jdeps/modules/GenModuleInfo.java tools/jdeps/modules/TransitiveDeps.java tools/jdeps/modules/InverseDeps.java These tests still failed on windows after JDK-8152502. Now I have the jtreg logs showing that JAR

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

On 5/19/16 5:51 PM, Martin Buchholz wrote: On Thu, May 19, 2016 at 7:29 AM, Peter Levart wrote: So Martin, what do you think? I studied your code and we are fundamentally in agreement! ... Except for need for periodic cleanup of the cache... Maybe we should do

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

On Thu, May 19, 2016 at 7:29 AM, Peter Levart wrote: > So Martin, what do you think? I studied your code and we are fundamentally in agreement! ... Except for need for periodic cleanup of the cache... Maybe we should do CompletableFuture.runAsync(purgeCache,

Re: Review request: 8152502: tools/jdeps/modules/GenModuleInfo.java and TransitiveDeps fails on windows

Looks good to me. -- Jon On 05/19/2016 04:50 PM, Mandy Chung wrote: These jdeps tests fails running on windows “Error. failed clean up files after test”. A bug in the tests and implementation that calls Files.walk without try-with-resources. Webrev at:

Review request: 8152502: tools/jdeps/modules/GenModuleInfo.java and TransitiveDeps fails on windows

These jdeps tests fails running on windows “Error. failed clean up files after test”. A bug in the tests and implementation that calls Files.walk without try-with-resources. Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8152502/webrev.00/index.html This fix calls Files::walk

Re: RFR (JAXP) 8139585: Typo: "APIi" instead of "API"

Thanks Mandy! Joe On 5/19/2016 3:44 PM, Mandy Chung wrote: On May 19, 2016, at 3:35 PM, huizhe wang wrote: Hi, Replaced the texts with the titles of the documents they are referring to. JBS: https://bugs.openjdk.java.net/browse/JDK-8139585 Webrev:

Re: RFR (JAXP) 8139585: Typo: "APIi" instead of "API"

> On May 19, 2016, at 3:35 PM, huizhe wang wrote: > > Hi, > > Replaced the texts with the titles of the documents they are referring to. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8139585 > Webrev: http://cr.openjdk.java.net/~joehw/jdk9/8139585/webrev/ +1

RFR (JAXP) 8139585: Typo: "APIi" instead of "API"

Hi, Replaced the texts with the titles of the documents they are referring to. JBS: https://bugs.openjdk.java.net/browse/JDK-8139585 Webrev: http://cr.openjdk.java.net/~joehw/jdk9/8139585/webrev/ Thanks, Joe

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

Hi Peter, I would make e.g. the change to Resource an independent change. Below you declare that you throw IOException, but you actually swallow it, which is not good. /** + * Closes cached input stream used for getBytes / getByteBuffer + * @throws IOException + */ +

Re: RFR [9] 8157154: jmod jlink properties file need copyright header

Yes of course. I'll add the year range before pushing. -Chris > On 19 May 2016, at 22:26, Mandy Chung wrote: > > Should the start year be 2015? You can fix up before you push. > > Mandy > >> On May 19, 2016, at 2:20 PM, Chris Hegarty wrote:

Re: RFR [9] 8157154: jmod jlink properties file need copyright header

Should the start year be 2015? You can fix up before you push. Mandy > On May 19, 2016, at 2:20 PM, Chris Hegarty wrote: > > Quite trivially, the copyright headers were omitted from these new > property files. This review request simply adds the standard header > to:

RFR [9] 8157154: jmod jlink properties file need copyright header

Quite trivially, the copyright headers were omitted from these new property files. This review request simply adds the standard header to: jdk/src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage.properties jdk/src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties

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

Peter and Sherman, I'm still quixotic fighting java memory bloat. Caching Inflaters at all is only barely profitable; a one-element Inflater cache is probably fine for those apps that occasionally iterate through the classpath. I don't want ThreadLocal bloat; I want _all_ the Inflaters to go

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

Hi, Mandy. Thank you so much for pushing the changesets [0,1] for this bug. Regards, Iris [0]: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3976fadb091d [1]: http://hg.openjdk.java.net/jdk9/dev/langtools/rev/2a49d47a37d8

Re: Helpers for MethodHandles.byteArrayViewVarHandle VarHandle

> > I meant change the shape of the VarHandle produced by: > > MethodHandles.byteArrayViewVarHandle > MethodHandles.byteBufferViewVarHandle > Aaaha:) I must say, one reason, why I'd like to have it wrapped is that VarHandle.get/set do not have fixed typed signature. Helper.longAt(arr, index)

Re: Review request for JDK-8156575: Add jdeps -addmods, -system, -inverse options

> On May 19, 2016, at 8:20 AM, Daniel Fuchs wrote: > > Hi Mandy, > > I played with that a bit (-I/-addmods) and it looks good. > > 92 main.opt.I=\ > 93 \ -I -inverse Analyzes the dependences per other > given options\n\ > 94 \

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

On 05/19/2016 06:31 PM, Xueming Shen wrote: Martin, Given we now only cache one deflater per Zip/JarFile object, is WeakReference here really necessary? Basically wr is based on the vm heap memory and deflater is a native memory, arguably we are using the wrong measurement to decide

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

Martin, Given we now only cache one deflater per Zip/JarFile object, is WeakReference here really necessary? Basically wr is based on the vm heap memory and deflater is a native memory, arguably we are using the wrong measurement to decide whether or not to give up the deflater's native

Re: Cleaner cleanup

Hi Roger, Here's the same webrev with an example of use of WeakCleanable that I have been thinking to propose later (I have done this in 5 minutes): http://cr.openjdk.java.net/~plevart/jdk9-dev/Cleaner.cleanup/webrev_with_ClassLoader_exmaple/ This example uses WeakCleanable as a lightweight

Re: Helpers for MethodHandles.byteArrayViewVarHandle VarHandle

> On 19 May 2016, at 16:26, Jaroslav Kameník wrote: > > > There certainly is in nio buffer sources (and may be for encoding/decoding in > other areas, i am speculating as i have not looked), but for buffer sources > we can actually remove much if not all of Bits.java via

Re: Review request for JDK-8156575: Add jdeps -addmods, -system, -inverse options

Hi Mandy, I played with that a bit (-I/-addmods) and it looks good. 92 main.opt.I=\ 93 \ -I -inverse Analyzes the dependences per other given options\n\ 94 \and then find all artifacts that directly\n\ 95 \

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

Hi Martin, To make it simpler to compare your and mine changes, here's the diff between your changed ZipFile.java and mine (mostly just removal of code): diff -r 45dcd8ef14a7 src/java.base/share/classes/java/util/zip/ZipFile.java --- a/src/java.base/share/classes/java/util/zip/ZipFile.java

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

On Thu, May 19, 2016 at 7:29 AM, Peter Levart wrote: > But I have reservation for the implementation of one-element global cache of > Inflater. This cache can't be efficient. In order for cache to be efficient, > majority of calls to ZipFile.getInputStream(zipEntry) would

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

Hi Martin, On 05/19/2016 04:27 AM, Martin Buchholz wrote: 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.

Re: Helpers for MethodHandles.byteArrayViewVarHandle VarHandle

> > > There certainly is in nio buffer sources (and may be for encoding/decoding > in other areas, i am speculating as i have not looked), but for buffer > sources we can actually remove much if not all of Bits.java via use of the > internal Unsafe unaligned accessors. > I made some notes when I

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

Thanks Paul and Claes! Hearing no objections for 24 hours now, I have pushed this change. Thanks, -Aleksey On 05/18/2016 03:57 PM, Claes Redestad wrote: > +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

Re: Cleaner cleanup

Hi, I haven't had time to look into this thoroughly, but since the at-most-once semantics have been removed from the Phantom|Weak|SoftCleanable classes and they are not used anywhere, they should be completely removed also, completing the cleanup. The only function being used (except by the

Re: RFR 8156718: Need tests for IsoFields getFrom for unsupported non-Iso Temporal fields

Hi Bhanu, Can you remind me why the value from line: 459 field.rangeRefinedBy(LocalDate.now()); is not checked also? Is looks odd to see a value passed to a test and not have it verified. It would need to use a fixed date (the same), but that is fine for that test. Thanks, Roger On

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

Martin's law of object pools in the presence of finalizers: Resurrecting a pooled object with a finalizer can be disastrous as it can be finalized later while in active use. Returning an object to the pool is a common thing to do in close() methods, and close() methods are reasonable things to

Re: RFR 8156718: Need tests for IsoFields getFrom for unsupported non-Iso Temporal fields

Fine by me Stephen On 19 May 2016 at 11:34, Bhanu Gopularam wrote: > Thank you Nadeesh and Stephen. > > Here is the updated webrev link: > http://cr.openjdk.java.net/~bgopularam/JDK-8156718/webrev.01 > > Please review. > > Bhanu > > -Original Message-

Re: RFR 8156718: Need tests for IsoFields getFrom for unsupported non-Iso Temporal fields

Hi Bhanu, Looking fine to me. Thanks and Regards, Nadeesh On 5/19/2016 4:04 PM, Bhanu Gopularam wrote: Thank you Nadeesh and Stephen. Here is the updated webrev link: http://cr.openjdk.java.net/~bgopularam/JDK-8156718/webrev.01 Please review. Bhanu -Original Message- From:

Re: Cleaner cleanup

Hey Peter, I just realized, there are two mistakes in the Javadoc code example inside the Cleaner Javadoc: private final State; -> private final State state; private final Cleaner.Cleanable cleanable -> private final Cleaner.Cleanable cleanable; Chris > On 16 May 2016, at 00:08, Peter Levart

RE: RFR 8156718: Need tests for IsoFields getFrom for unsupported non-Iso Temporal fields

Thank you Nadeesh and Stephen. Here is the updated webrev link: http://cr.openjdk.java.net/~bgopularam/JDK-8156718/webrev.01 Please review. Bhanu -Original Message- From: Stephen Colebourne [mailto:scolebou...@joda.org] Sent: Tuesday, May 17, 2016 5:11 PM To: core-libs-dev Subject:

Re: RFR 8157239 java/lang/invoke/VarHandles/ tests fail by timeout with -Xcomp with lambda form linkage

Reviewed. Best regards, Vladimir Ivanov On 5/19/16 12:47 PM, Paul Sandoz wrote: Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8157239-vh-tests-xcomp-timeout/webrev/ A recent change

Re: RFR 8130023 API java.util.stream: explicitly specify guaranteed execution of the pipeline

> On 17 May 2016, at 23:15, Claes Redestad wrote: > > Hi, > > the first block in Stream.java bothers me: > > + * A stream implementation is permitted significant latitude in optimizing > + * the computation of the result. For example, a stream implementation is >

RFR 8157239 java/lang/invoke/VarHandles/ tests fail by timeout with -Xcomp with lambda form linkage

Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8157239-vh-tests-xcomp-timeout/webrev/ A recent change modified the VH tests to test the lambda form linkage route:

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

This is described as being to help RSA, etc., but it will be very hard to use for that purpose without an add with carry. There are many ways to do the product, but a simple version of the core is like this: for i=0 to s-1 C := 0 for j=0 to s-1 (C,S) := t[i+j] + a[j]

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

David, The change looks good but you already have enough reviewers. :) Just wanted to thank you for taking steps on this issue. Thanks, Serguei On 5/18/16 21:52, David Holmes wrote: Not sure who really owns this file so cc'ing core-libs and serviceability. bug:

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

Thanks Alan! David On 19/05/2016 3:37 PM, Alan Bateman wrote: 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

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

Thanks Dmitry! David On 19/05/2016 3:01 PM, Dmitry Samersoff wrote: 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.