RFR JDK-8148624: Test failure of ConstructInflaterOutput.java

Hi, Please help review the change for JDK-8148624 Issue: https://bugs.openjdk.java.net/browse/JDK-8148624 Webrev: http://cr.openjdk.java.net/~sherman/8148624/webrev/ The tests are intended to test/verify that the Deflater/Inflater.end() method will not be invoked when they are passed in as the

Re: [9] RFR (S): 8148994: Replacing MH::invokeBasic with a direct call breaks LF customization

Better! You moved some inlining policy out of the VM and into the JDK runtime. Reviewed. Some loose brainstorming here: We are creating MH nodes that provide hints to the JIT inlining policy. The hint must vary over time as the profile evolves. The CMH does this indirectly via generating a @Don

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

Steve, I would assume the difference of the webrev.04 "old" iterator and the webrev.06 "new" iterator that might trigger a performance is how you create the JarFileEntry. The one parameter constructor invokes isMultiRelease(), which might be relatively expensive, when the "mr" is enabled. The

Re: RFR JDK-8149769: Null pointer exception in ZipFileSystemProvider

> What's the issue? The bug description only includes the fix. If the env is > null, shouldn't > it trigger a NPE? > > The java.nio.file.spi package does have the note that "NPE, unless otherwise > noted ..." > The api for FilesystemProvider.newFileSystem(..., env) says "env" can be > empty, me

Re: [9] RFR (S): 8148994: Replacing MH::invokeBasic with a direct call breaks LF customization

Hi, this seems OK to me, and I've verified that this gets octane performance back to 9-b102 levels across a number of platforms. Thanks! /Claes On 2016-02-12 18:15, Vladimir Ivanov wrote: Any reviews, please? Best regards, Vladimir Ivanov On 2/5/16 7:29 PM, Vladimir Ivanov wrote: Thanks, J

Re: RFR 9:8148775 : Spec for j.l.ProcessBuilder.Redirect.DISCARD need to be improved

Still looks good! On Fri, Feb 12, 2016 at 3:08 PM, Roger Riggs wrote: > Thanks, Martin > > Updated in place. > > > > > On 2/12/2016 5:48 PM, Martin Buchholz wrote: > > looks good. > The previous line > > Redirect.DISCARD.file() the filename appropriate for the operating system > 557 *

Re: RFR 9:8148775 : Spec for j.l.ProcessBuilder.Redirect.DISCARD need to be improved

Thanks, Martin Updated in place. On 2/12/2016 5:48 PM, Martin Buchholz wrote: looks good. The previous line Redirect.DISCARD.file() the filename appropriate for the operating system 557 * and may be null && could use the word "is" On Fri, Feb 12, 2016 at 2:42 PM, Roger Riggs w

Re: RFR JDK-8149769: Null pointer exception in ZipFileSystemProvider

Steve, What's the issue? The bug description only includes the fix. If the env is null, shouldn't it trigger a NPE? The java.nio.file.spi package does have the note that "NPE, unless otherwise noted ..." The api for FilesystemProvider.newFileSystem(..., env) says "env" can be empty, means N

Re: RFR 9:8148775 : Spec for j.l.ProcessBuilder.Redirect.DISCARD need to be improved

looks good. The previous line Redirect.DISCARD.file() the filename appropriate for the operating system 557 * and may be null && could use the word "is" On Fri, Feb 12, 2016 at 2:42 PM, Roger Riggs wrote: > Please review a minor javadoc cleanup to remove a reference to a method > (app

RFR 9:8148775 : Spec for j.l.ProcessBuilder.Redirect.DISCARD need to be improved

Please review a minor javadoc cleanup to remove a reference to a method (append) of the implementation. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-discard-8148775/ Issue: https://bugs.openjdk.java.net/browse/JDK-8148775 Thanks, Roger

Re: RFR JDK-8149769: Null pointer exception in ZipFileSystemProvider

>> Please review this simple fix to ZipFileSystemProvider. The issue is >> JDK-8149769 . I didn’t do >> a webrev but instead provide the following patch. >> >> > This looks okay. Can one of the existing tests be updated to cover this case? Ye

RE: RFR: 8149601 Update references from "1.9" to "9"

Hi, Kumar. Thank you so much for pushing changesets to fix this bug. Regards, iris -Original Message- From: Iris Clark Sent: Thursday, February 11, 2016 9:13 AM To: [email protected]; [email protected] Cc: Iris Clark; Kumar Srinivasan Subject: RFR: 8149601 Update

Re: RFR JDK-8149769: Null pointer exception in ZipFileSystemProvider

On 12/02/2016 21:11, Steve Drach wrote: Hi, Please review this simple fix to ZipFileSystemProvider. The issue is JDK-8149769 . I didn’t do a webrev but instead provide the following patch. This looks okay. Can one of the existing tests be

Re: RFR JDK-8149769: Null pointer exception in ZipFileSystemProvider

Look fine. Roger On 2/12/16 4:11 PM, Steve Drach wrote: Hi, Please review this simple fix to ZipFileSystemProvider. The issue is JDK-8149769 . I didn’t do a webrev but instead provide the following patch. Thanks Steve diff -r 2d6c2c75f33

RFR JDK-8149769: Null pointer exception in ZipFileSystemProvider

Hi, Please review this simple fix to ZipFileSystemProvider. The issue is JDK-8149769 . I didn’t do a webrev but instead provide the following patch. Thanks Steve diff -r 2d6c2c75f338 src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystemPro

RE: RFR: 8149601 Update references from "1.9" to "9"

Hi, Joe. Thanks for the review. Regards, iris -Original Message- From: huizhe wang Sent: Thursday, February 11, 2016 11:17 AM To: Iris Clark Cc: [email protected]; [email protected] Subject: Re: RFR: 8149601 Update references from "1.9" to "9" Hi Iris, The chang

RFR 9: 8149750 Decouple sun.misc.Signal from the base module

Please review moving the functionality of sun.misc.Signal to jdk.internal.misc and creating a wrapper sun.misc.Signal for existing external uses. +++ This time including the hotspot changes to update the target of the upcalls. A new replacement API will be considered separately. The update i

Re: [9] RFR (S): 8148994: Replacing MH::invokeBasic with a direct call breaks LF customization

Any reviews, please? Best regards, Vladimir Ivanov On 2/5/16 7:29 PM, Vladimir Ivanov wrote: Thanks, John. On 2/4/16 9:52 PM, John Rose wrote: Looks good. Except I don't recall how is_inline interacts, if at all, with customization. It's not clear what is being gated, and which optimizations

RFR 9: 8149750 Decouple sun.misc.Signal from the base module

Please review moving the functionality of sun.misc.Signal to jdk.internal.misc and creating a wrapper sun.misc.Signal for existing external uses. A new replacement API will be considered separately. The update includes a test that passes with or without the changes. (Except for an NPE instead of

Re: RFR [9 ] 8149656: Examine usages of sun.misc.LRUCache

+1 On 2/12/2016 11:30 AM, Claes Redestad wrote: On 2016-02-12 17:26, Chris Hegarty wrote: http://cr.openjdk.java.net/~chegar/8149656.01/ This looks great, thanks! /Claes

Re: RFR [9 ] 8149656: Examine usages of sun.misc.LRUCache

On 2016-02-12 17:26, Chris Hegarty wrote: http://cr.openjdk.java.net/~chegar/8149656.01/ This looks great, thanks! /Claes

Re: RFR [9 ] 8149656: Examine usages of sun.misc.LRUCache

Thanks for the feedback. On 12/02/16 16:05, [email protected] wrote: Since it is only implemented with one anonymous class you could also think about making it a concrete PatternLRUCache On 12/02/16 15:59, Claes Redestad wrote: > +1 > > nits: I guess the class should be made static if ne

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

Hi Steve, This patch has been cooking and re-heated enough times that i think it’s as good as done in terms of being reviewed. We can follow up with further issues for other aspects, such as performance if need be. Paul. > On 10 Feb 2016, at 02:04, Steve Drach wrote: > > Hi, > > Yet anothe

Re: RFR [9 ] 8149656: Examine usages of sun.misc.LRUCache

Since it is only implemented with one anonymous class you could also think about making it a concrete PatternLRUCache -- http://bernd.eckenfels.net -Original Message- From: Chris Hegarty To: Core-Libs-Dev Sent: Fr., 12 Feb. 2016 16:55 Subject: RFR [9 ] 8149656: Examine usages of sun.

Re: RFR [9 ] 8149656: Examine usages of sun.misc.LRUCache

+1 nits: I guess the class should be made static if nested here, or even made concrete to get rid of the anonymous class - that depends on if we think we'll ever reuse this utility for other things. /Claes On 2016-02-12 16:45, Chris Hegarty wrote: sun.misc.LRUCache is a utility class for im

RFR [9 ] 8149656: Examine usages of sun.misc.LRUCache

sun.misc.LRUCache is a utility class for implementing Least Recently Used Caches. It is only used by j.u.Scanner in the JDK. It should be relocated to a more suitable location, possibly an inner class of Scanner. http://cr.openjdk.java.net/~chegar/8149656/ -Chris.

Re: DeserializationPermission Proposal

Things are getting confused (for me anyway) so I'm going to try and spell out each idea separately. Given a class hierarchy H of: C -> B -> A -> NonSerializableClass -> Object where C, B, and A are serializable classes, and protection domain M which is initiating deserialization, I think the