Re: RFR: Here are some URLClassPath patches

On 21/02/2018 06:08, Martin Buchholz wrote: : 8198482: The URLClassPath field "urls" should be renamed to "unopenedUrls" http://cr.openjdk.java.net/~martin/webrevs/jdk/URLClassPath-rename-urls/

Re: RFR: Here are some URLClassPath patches

On 21/02/2018 06:08, Martin Buchholz wrote: : 8198481: Coding style cleanups for src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java http://cr.openjdk.java.net/~martin/webrevs/jdk/loader-style/

Draft JEP: To use UTF-8 as the default charset for the Java virtual machine.

This draft JEP contains a proposal to use UTF-8 as the default charset for the JVM, so that APIs that depend on the default charset behave consistently cross all platforms. For more details, please see: https://bugs.openjdk.java.net/browse/JDK-8187041 Sherman

Re: [11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit

Hi Mandy, On 21/02/2018 5:57 AM, mandy chung wrote: Hi David, I reworked the change in Shutdown class and uses jdk.internal.misc.VM to maintain the shutdown state, either in progress or shutdown (i.e. all shutdown hooks have been started). What do you think this revised version:

RFR: Here are some URLClassPath patches

At Google I spend a lot of time staring unproductively at classloader code, and it's always hard for me to resist the urge to clean it up. So here are some patches that should be relatively uncontroversial, and may prepare for more radical changes later. 8198480: Improve ClassLoaders static init

Re: RFR Passing 'null' value to lookup param of ConstantBootstraps.invoke does not throw NullPointerException

On 2/20/18 2:47 PM, Paul Sandoz wrote: Hi, Correction to the specification of ConstantBootstraps.invoke [1], the lookup parameter is not used: diff -r b75c9e2e3b1f src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java ---

RFR Passing 'null' value to lookup param of ConstantBootstraps.invoke does not throw NullPointerException

Hi, Correction to the specification of ConstantBootstraps.invoke [1], the lookup parameter is not used: diff -r b75c9e2e3b1f src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java --- a/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java Tue Feb 20 21:47:54

Re: [11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit

Hi David, I reworked the change in Shutdown class and uses jdk.internal.misc.VM to maintain the shutdown state, either in progress or shutdown (i.e. all shutdown hooks have been started). What do you think this revised version:

Re: 8196830: publicLookup().findVirtual should not return method handle to AccessibleObject.setAccessible

Looks good, especially the test. Paul. > On Feb 20, 2018, at 10:21 AM, mandy chung wrote: > > This patch looks good. It's unfortunate that setAccessible was not final > to begin with. I agree that this fix is a good compromise with a simple > fix and low

Re: [11] RFR JDK-8198441: Replace native Runtime::runFinalization0 method with shared secrets

Looks good! On Tue, Feb 20, 2018 at 9:45 AM, mandy chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8198441/webrev.00 > > This is a small cleanup that replaces the native Runtime::runFinalization0 > method with shared secrets to invoke

Re: 8196830: publicLookup().findVirtual should not return method handle to AccessibleObject.setAccessible

This patch looks good.  It's unfortunate that setAccessible was not final to begin with.  I agree that this fix is a good compromise with a simple fix and low incompatibility.   Is there a CSR to review? Mandy On 2/19/18 8:57 AM, Alan Bateman wrote: > AccessibleObject's setAccessible(boolean)

[11] RFR JDK-8198441: Replace native Runtime::runFinalization0 method with shared secrets

Webrev: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8198441/webrev.00 This is a small cleanup that replaces the native Runtime::runFinalization0 method with shared secrets to invoke Finalizer::runFinalization in java. Mandy

Re: [11] RFR: 8198418: Invoke LambdaMetafactory::metafactory exactly from the BootstrapMethodInvoker

Thanks! Pushed. /Claes On 2018-02-20 17:06, Brian Goetz wrote: That’s great. Anyone maintaining this file should see it. On Feb 20, 2018, at 7:46 AM, Claes Redestad wrote: Would injecting this before the LMF::metafactory do? Or should this be an @implNote?

Re: [11] RFR: 8198418: Invoke LambdaMetafactory::metafactory exactly from the BootstrapMethodInvoker

That’s great. Anyone maintaining this file should see it. > On Feb 20, 2018, at 7:46 AM, Claes Redestad wrote: > > Would injecting this before the LMF::metafactory do? Or should this be an > @implNote? > > diff -r d8e1eab41853 >

Re: [11] RFR: 8198418: Invoke LambdaMetafactory::metafactory exactly from the BootstrapMethodInvoker

Would injecting this before the LMF::metafactory do? Or should this be an @implNote? diff -r d8e1eab41853 src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java --- a/src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java Tue Feb 20 14:40:53 2018 +0100 +++

Re: [11] RFR: 8198418: Invoke LambdaMetafactory::metafactory exactly from the BootstrapMethodInvoker

Add a comment to LMF to remember to update the hack if additional sigs are added. Sent from my iPad > On Feb 20, 2018, at 4:27 AM, Claes Redestad wrote: > > You also pointed out that if the params or return types doesn't match, we'd > get a CCE sooner or later,

Re: Fw: [PATCH] ObjectInputStream Reading Performance Optimisation

On 20/02/2018 14:11, Ben Walsh wrote: Still looking for a sponsor for this please ... Hard to know what to do with this. As it stands, the patch isn't really suitable for OpenJDK as it doesn't have the HotSpot changes. In addition, I think we have to very cautious about changing very security

Fw: [PATCH] ObjectInputStream Reading Performance Optimisation

Still looking for a sponsor for this please ... Thanks, Ben Walsh - Forwarded by Ben Walsh/UK/IBM on 20/02/2018 14:04 - From: Ben Walsh/UK/IBM To: core-libs-dev Date: 07/02/2018 14:18 Subject:[PATCH] ObjectInputStream Reading Performance

Re: [11] RFR: 8198418: Invoke LambdaMetafactory::metafactory exactly from the BootstrapMethodInvoker

Looks good ! Rémi - Mail original - > De: "Claes Redestad" > À: "Vladimir Ivanov" , "Remi Forax" > > Cc: "core-libs-dev" > Envoyé: Mardi 20 Février 2018 13:27:43 > Objet: Re:

Re: [11] RFR: 8198418: Invoke LambdaMetafactory::metafactory exactly from the BootstrapMethodInvoker

You also pointed out that if the params or return types doesn't match, we'd get a CCE sooner or later, making the return and argument checks superfluous. This all simplifies into this, then: http://cr.openjdk.java.net/~redestad/8198418/jdk.02/ Thanks! /Claes On 2018-02-20 13:20, Vladimir

Re: [11] RFR: 8198418: Invoke LambdaMetafactory::metafactory exactly from the BootstrapMethodInvoker

No need in MT.equals. Pointer comparison should work as well: MethodType instances are interned and all exact type checks on MethodHandles are implemented using == on their MTs. Best regards, Vladimir Ivanov On 2/20/18 3:07 PM, Claes Redestad wrote: Hi Rémi, sure, MethodType.equals will do

Re: [11] RFR: 8198418: Invoke LambdaMetafactory::metafactory exactly from the BootstrapMethodInvoker

Hi Rémi, sure, MethodType.equals will do a fast == check, but then checks the param types. It sure looks cleaner, though: http://cr.openjdk.java.net/~redestad/8198418/jdk.01/ Thanks! /Claes On 2018-02-20 12:38, Remi Forax wrote: Hi Claes, instead of checking each parameter of the

Re: [11] RFR: 8198418: Invoke LambdaMetafactory::metafactory exactly from the BootstrapMethodInvoker

Hi Claes, instead of checking each parameter of the bsmType(), why not allocating the corresponding MethodType and storing it in a static final, so you can check if the MethodType are equals using equals (as far as i remember MethodType.equals is a == in the OpenJDK implementation). in term of

[11] RFR: 8198418: Invoke LambdaMetafactory::metafactory exactly from the BootstrapMethodInvoker

Hi, a small regression to lambda bootstrapping came in with the recent condy merge, and it took me a while to figure out why. Before condy, the first three parameters of calls from the BSM invoker to the six parameter LambdaMetafactory::metafactory were statically known, so only the fourth