Re: RFR: 8151901: test/tools/pack200/Pack200Test fails on verifying native unpacked JAR

Good. Please change the comment: s/null, no tuple change, force recomputation/null, drop ICs attribute, force CP recomputation/ Reordering BSMs and ICs should work. The BSMs may need extra ICs, but ICs cannot depend on BSMs. I wonder why we did the other order first? I guess because that is

Re: RFR: 8150469: unpack200 fails to compare crc correctly.

Looks good, a clean fix. The negative test should be called "testBadChecksum" or "testBrokenTrailer". — John On Feb 29, 2016, at 8:06 AM, Kumar Srinivasan wrote: > > Hello John, Alex, > > Please review fix for https://bugs.openjdk.java.net/browse/JDK-8150469

Re: RFR:JDK-8148849:Truncating Duration

Hi Nadeesh, An internal reviewer pointed out that Duration does not have 'fields' (it is not a TemporalAccessor) so the description might be clarified by saying: + * Truncating the duration returns a copy of the original with *conceptual *fields + * smaller than the specified unit

Re: RFR: jsr166 jdk9 integration wave 6

We missed Aleksey's changes, which broke our integration. Historically, hotspot was more independent from jdk, and there were no "flag days" that required both to be modified together. In jsr166 CVS we still consistently use sun.misc.Unsafe, because it's ... ummm ... more portable. Our openjdk

Re: RFR JDK 9 (JAXP) 8150969 : DEFER from Features API is taking precedence over defer preference in catalog file.

looks fine joe > On Apr 6, 2016, at 3:33 PM, huizhe wang wrote: > > Hi, > > Fix a typo in the catalog reader where the intention was to set the defer > attribute, but the prefer was set instead. The tests are from the JCK. > > JBS:

RFR JDK 9 (JAXP) 8150969 : DEFER from Features API is taking precedence over defer preference in catalog file.

Hi, Fix a typo in the catalog reader where the intention was to set the defer attribute, but the prefer was set instead. The tests are from the JCK. JBS: https://bugs.openjdk.java.net/browse/JDK-8150969 webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8150969/webrev/ Thanks, Joe

Re: RFR 8153123 : Streamline StackWalker code

On 04/05/2016 10:36 PM, Mandy Chung wrote: Looks good. Nit: can you add a space after “synchronized” in StackFrameInfo.java line 109: 109 synchronized(this) { Yep - changed locally. Thanks, -Brent

RE: RFR(XXS): 8149519: Investigate implementation of java.specification.version

Hi, Volker. Sorry for the delay. I agree that the old implementation isn't quite correct. I can't see us potentially having a JCP MR for a security or patch release (9.0.0.X and 9.0.X respectively). I could see a MR for an very unusual minor release (9.X). If we had an MR there's no

Re: RFR 8153123 : Streamline StackWalker code

On 4/5/16 7:48 PM, Brent Christian wrote: Thanks, Coleen. Coordinating method/function names on "to stack trace element" is a fine thing. I've done so in the updated webrev, and also implemented Claes's suggestion. http://cr.openjdk.java.net/~bchristi/8153123/webrev.01/index.html Thank

Re: [9] RFR JDK-8153564: Add java/nio/Buffer/BasicByte.java to exclude list until JDK-8153563 is fixed

It was late for me, so Amy took over and fixed it Thanks Alejandro On 4/6/2016 1:36 AM, Alan Bateman wrote: On 06/04/2016 06:14, Alejandro Murillo wrote: I'd like to push the changeset below to exclude java/nio/Buffer/BasicByte.java It started failing after the hotspot snapshot was pushed

Re: RFR: 8153293 - Stream API: Preserve SORTED and DISTINCT characteristics for boxed() and asLongStream() operations

> On 4 Apr 2016, at 21:28, Stefan Zobel wrote: > > Hi Tagir, > > good catch! I like the proposal. > Me too. +1. Extra bonus points to test, in addition to the tested characteristics, that the boxed/converted elements remain sorted/distinct :-) >> >> (different

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

So are there any bootstrap issues with VH that would preclude using it in BufferedInputStream? Is that even known at this point? You mentioned that VH was designed to minimize bootstrapping issues, but where's the "minimized" line drawn? On Wed, Apr 6, 2016 at 10:09 AM, Paul Sandoz

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

On 04/06/2016 04:09 PM, Paul Sandoz wrote: small streams become big rivers (i don't know the idiomatic sentence in English, so it's a rough translation from a French idiom), "Death by a thousand cuts" is one of my favorites:). A "flat profile" is another description of a similar thing. I

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

- Mail original - > De: "Paul Sandoz" > Cc: "core-libs-dev Libs" > Envoyé: Mercredi 6 Avril 2016 16:09:14 > Objet: Re: RFR: 8153334: Replace BufferedInputStreams use of > AtomicReferenceFieldUpdater with Unsafe > > > > On 6

Re: RFR: JDK-8152622: tools/pack200/Pack200Props.java timed out

On 06/04/2016 15:20, Kumar Srinivasan wrote: Alan, http://cr.openjdk.java.net/~ksrini/8152622/webrev.02/ I made the changes as you suggested below, I have retained Files.createDirectories, here is why, changing it to createDirectory will throw FileAlreadyExistsException, which means, that if

Re: RFR: JDK-8152622: tools/pack200/Pack200Props.java timed out

Alan, http://cr.openjdk.java.net/~ksrini/8152622/webrev.02/ I made the changes as you suggested below, I have retained Files.createDirectories, here is why, changing it to createDirectory will throw FileAlreadyExistsException, which means, that if the output zip/jar file exists then an

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

> On 6 Apr 2016, at 15:28, fo...@univ-mlv.fr wrote: > > > > While i fully agree in the general case, in disagree for this specific > > > case, > > > there are few uses of ARFU inside the JDK (or outside) but currently > > > because BufferedInputStream uses an ARFU, each time someone starts a

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Peter, Since the current implementation of the old Cleaner and DirectByteBuffer works well and there is a lot of work piling up against the FC date, I'm in favor of keeping it as it is until the possibilities with Panama settle out. It would best if reclamation was not GC based, except as

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

- Mail original - > De: "Vitaly Davidovich" > À: "Remi Forax" > Cc: "Paul Sandoz" , "core-libs-dev Libs" > > Envoyé: Mercredi 6 Avril 2016 15:04:39 > Objet: Re: RFR: 8153334: Replace

Re: RFR: JDK-8152622: tools/pack200/Pack200Props.java timed out

On 06/04/2016 14:09, Kumar Srinivasan wrote: - Is Files.createDirectories needed? The walk is specified to be depth first so you'll also visit parent directories first. Yes, zipfs does not allow me to create the file without creating the enclosing directory first, so if I were to do

Re: RFR: JDK-8152622: tools/pack200/Pack200Props.java timed out

Alan, Thanks for the review. Please see inline comments. Creating a zip file from the classes in the jrt file system make sense, and should be fast. A few comments on Utils.JrtToZip: - the URI creation in the run() method isn't reliable, could you use this instead: URI uri =

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

On Wednesday, April 6, 2016, Remi Forax wrote: > - Mail original - > > De: "Paul Sandoz" > > > Cc: "core-libs-dev Libs" > > > Envoyé: Mercredi 6 Avril 2016 12:37:50 > > Objet: Re: RFR:

Re: RFR: jsr166 jdk9 integration wave 6

Hi Martin, miscellaneous — You reverted Aleksey’s change s/putOrderedObject/putObjectRelease. The *Ordered* methods are now removed from the “real” jdk.internal.misc.Unsafe. Paul. > On 3 Apr 2016, at 20:29, Martin Buchholz wrote: > > Easy changes to review, up to April

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

- Mail original - > De: "Paul Sandoz" > Cc: "core-libs-dev Libs" > Envoyé: Mercredi 6 Avril 2016 12:37:50 > Objet: Re: RFR: 8153334: Replace BufferedInputStreams use of > AtomicReferenceFieldUpdater with Unsafe > > > > On 6 Apr

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

Hi Steve, My feeling is it’s too premature to introduce a general Memory (region) allocation interface at this moment. What is currently specified can be supported using: IntFunction But i don’t wanna discourage you! this thread has raised some interesting points. Project Panama is gonna

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

> On 6 Apr 2016, at 12:10, Remi Forax wrote: > > - Mail original - >> De: "Paul Sandoz" >> Cc: "core-libs-dev Libs" >> Envoyé: Mercredi 6 Avril 2016 09:37:00 >> Objet: Re: RFR: 8153334: Replace

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

- Mail original - > De: "Paul Sandoz" > Cc: "core-libs-dev Libs" > Envoyé: Mercredi 6 Avril 2016 09:37:00 > Objet: Re: RFR: 8153334: Replace BufferedInputStreams use of > AtomicReferenceFieldUpdater with Unsafe > > > > On 5 Apr

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

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

Re: RFR: JDK-8152622: tools/pack200/Pack200Props.java timed out

On 06/04/2016 04:47, Kumar Srinivasan wrote: Hi, I made some adjustments, based on private feedback. New Webrev: http://cr.openjdk.java.net/~ksrini/8152622/webrev.01/ Changes * Modified ModuleAttributes test to use the new utility method, this also requires a way to filter/select

Re: JDK 9 RFR of JDK-8153563: java/nio/Buffer/Basic.java and CopyDirectMemory.java are failing after JDK-8149469

On 06/04/2016 08:59, Amy Lu wrote: Yes :-) Please review the updated patch: http://cr.openjdk.java.net/~amlu/8153563/webrev.01/ Thanks, Amy Looks fine.

Re: JDK 9 RFR of JDK-8153563: java/nio/Buffer/Basic.java and CopyDirectMemory.java are failing after JDK-8149469

On 4/6/16 3:52 PM, Alan Bateman wrote: On 06/04/2016 08:47, Amy Lu wrote: : * * @build Basic + * @modules java.base/jdk.internal.misc * @run main CopyDirectMemory */ It might be clearer to put it before the @build, otherwise looks okay. Yes :-) Please review the updated patch:

Re: JDK 9 RFR of JDK-8153563: java/nio/Buffer/Basic.java and CopyDirectMemory.java are failing after JDK-8149469

On 06/04/2016 08:47, Amy Lu wrote: : * * @build Basic + * @modules java.base/jdk.internal.misc * @run main CopyDirectMemory */ It might be clearer to put it before the @build, otherwise looks okay. -Alan

JDK 9 RFR of JDK-8153563: java/nio/Buffer/Basic.java and CopyDirectMemory.java are failing after JDK-8149469

With test/java/nio/Buffer/BasicByte.java change in JDK-8149469, test java/nio/Buffer/Basic.java java/nio/Buffer/CopyDirectMemory.java now requires @modules java.base/jdk.internal.misc Please review the patch. bug: https://bugs.openjdk.java.net/browse/JDK-8153563 webrev:

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

> On 5 Apr 2016, at 17:15, Claes Redestad wrote: > > On 04/04/2016 05:45 PM, Martin Buchholz wrote: >>> I think this one is going too far. >>> >>> A*FU/VarHandles should are supposed to act like a go-to replacement for >>> Unsafe throughout the class library, and we

Re: [9] RFR JDK-8153564: Add java/nio/Buffer/BasicByte.java to exclude list until JDK-8153563 is fixed

On 06/04/2016 06:14, Alejandro Murillo wrote: I'd like to push the changeset below to exclude java/nio/Buffer/BasicByte.java It started failing after the hotspot snapshot was pushed to jdk9/dev tonight. https://bugs.openjdk.java.net/browse/JDK-8153563 has been filed for that failure.

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Roger, On 04/05/2016 04:41 PM, Peter Levart wrote: On 04/04/2016 11:50 PM, Roger Riggs wrote: I don't see the need to change Cleaner to an interface to be able to provide an additional method on CleanerImpl or a subclass and a factory method could provide for a clean and very targeted

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

Hello Steve, Thank you for addressing all concerns raised in the discussion. For my points: Using BufferSupplier or similar as the interface name can be mixed with class/constructor names which describe the actual type of memory. However yes I agree that “Memory” has the additional benefit

Re: [9] RFR JDK-8153564: Add java/nio/Buffer/BasicByte.java to exclude list until JDK-8153563 is fixed

I didn't see that one failing on my jprt sanity job I went to check the code CopyDirectMemory.java, and it doesn't use jdk.internal.misc.Unsafe (at least directly), so doesn't look like it's the same issue. where did you see the failure ? Alejandro On 4/5/2016 11:59 PM, Amy Lu wrote:

Re: [9] RFR JDK-8153564: Add java/nio/Buffer/BasicByte.java to exclude list until JDK-8153563 is fixed

java/nio/Buffer/CopyDirectMemory.java run into the same issue, maybe it could be problem listed together in this patch? Thanks, Amy On 4/6/16 1:14 PM, Alejandro Murillo wrote: I'd like to push the changeset below to exclude java/nio/Buffer/BasicByte.java It started failing after the