From mandy.chung at oracle.com Tue Jul 1 00:02:20 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 30 Jun 2014 17:02:20 -0700 Subject: RFR: 8023276: Java SE should include the full DOM API from JAXP In-Reply-To: <53B1D781.2050302@oracle.com> References: <53B1D781.2050302@oracle.com> Message-ID: <53B1FA8C.7060500@oracle.com> On 6/30/14 2:32 PM, huizhe wang wrote: > Hi, > > Three packages are missing from the DOM API documentation in JAXP: > org.w3c.dom.views > org.w3c.dom.ranges > org.w3c.dom.traversal > > We added org.w3c.dom.views in JAXP 1.6 and fixed JDK-8006843. But > since we were too close to the deadline for JAXP 1.6 MR, we left the > other two packages for JDK 9. CCC has been approved for this > addition. Please review. > > http://cr.openjdk.java.net/~joehw/jdk9/8023276/webrev/ > thumbs up. Mandy From coleen.phillimore at oracle.com Tue Jul 1 00:50:15 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 30 Jun 2014 20:50:15 -0400 Subject: RFR 8047737 Move array component mirror to instance of java/lang/Class In-Reply-To: References: <53ADC4D4.4030403@oracle.com> <53B0FBEF.5030607@oracle.com> <53B15B50.6070405@oracle.com> Message-ID: <53B205C7.8070804@oracle.com> On 6/30/14, 3:50 PM, Christian Thalinger wrote: > private Class(ClassLoader loader) { > // Initialize final field for classLoader. The initialization value of non-null > // prevents future JIT optimizations from assuming this final field is null. > classLoader = loader; > + componentType = null; > } > > Are we worried about the same optimization? Hi, I've decided to make them consistent and add another parameter to the Class constructor. http://cr.openjdk.java.net/~coleenp/8047737_jdk_2/ Thanks, Coleen > > + compute_optional_offset(_component_mirror_offset, > + klass_oop, vmSymbols::componentType_name(), > + vmSymbols::class_signature()); > > Is there a followup cleanup to make it non-optional? Or, are you > waiting for JPRT to be able to push hotspot and jdk changes together? > > On Jun 30, 2014, at 5:42 AM, Coleen Phillimore > > > wrote: > >> >> On 6/30/14, 1:55 AM, David Holmes wrote: >>> Hi Coleen, >>> >>> Your webrev links are to internal locations. >> >> Sorry, I cut/pasted the wrong links. They are: >> >> http://cr.openjdk.java.net/~coleenp/8047737_jdk/ >> >> http://cr.openjdk.java.net/~coleenp/8047737_hotspot/ >> >> and the full version >> >> http://cr.openjdk.java.net/~coleenp/8047737_hotspot/ >> >> Thank you for pointing this out David. >> >> Coleen >> >>> >>> David >>> >>> On 28/06/2014 5:24 AM, Coleen Phillimore wrote: >>>> Summary: Add field in java.lang.Class for componentType to simplify oop >>>> processing and intrinsics in JVM >>>> >>>> This is part of ongoing work to clean up oop pointers in the metadata >>>> and simplify the interface between the JDK j.l.C and the JVM. There's a >>>> performance benefit at the end of all of this if we can remove all oop >>>> pointers from metadata. mirror in Klass is the only one left after >>>> this full change. >>>> >>>> See bug https://bugs.openjdk.java.net/browse/JDK-8047737 >>>> >>>> There are a couple steps to this change because Hotspot testing is done >>>> with promoted JDKs. The first step is this webrev: >>>> >>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_jdk/ >>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot/ >>>> >>>> When the JDK is promoted, the code to remove >>>> ArrayKlass::_component_mirror will be changed under a new bug id. >>>> >>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot_full >>>> >>>> Finally, a compatibility request and licensee notification will >>>> occur to >>>> remove the function JVM_GetComponentType. >>>> >>>> Performance testing was done that shows no difference in performance. >>>> The isArray() call is a compiler intrinsic which is now called instead >>>> of getComponentType, which was recognized as a compiler intrinsic. >>>> >>>> JDK jtreg testing, hotspot jtreg testing, hotspot NSK testing and jck8 >>>> tests were performed on both the change requested (1st one) and the >>>> full >>>> change. >>>> >>>> hotspot NSK tests were run on the hotspot-only change with a >>>> promoted JDK. >>>> >>>> Please send your comments. >>>> >>>> Thanks, >>>> Coleen >> > From huizhe.wang at oracle.com Tue Jul 1 01:05:14 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 30 Jun 2014 18:05:14 -0700 Subject: RFR: 8023276: Java SE should include the full DOM API from JAXP In-Reply-To: <53B1FA8C.7060500@oracle.com> References: <53B1D781.2050302@oracle.com> <53B1FA8C.7060500@oracle.com> Message-ID: <53B2094A.4030603@oracle.com> Thanks Mandy, Lance. The changeset is pushed. -Joe On 6/30/2014 5:02 PM, Mandy Chung wrote: > On 6/30/14 2:32 PM, huizhe wang wrote: >> Hi, >> >> Three packages are missing from the DOM API documentation in JAXP: >> org.w3c.dom.views >> org.w3c.dom.ranges >> org.w3c.dom.traversal >> >> We added org.w3c.dom.views in JAXP 1.6 and fixed JDK-8006843. But >> since we were too close to the deadline for JAXP 1.6 MR, we left the >> other two packages for JDK 9. CCC has been approved for this >> addition. Please review. >> >> http://cr.openjdk.java.net/~joehw/jdk9/8023276/webrev/ >> > > thumbs up. > > Mandy From jeremymanson at google.com Tue Jul 1 01:05:30 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Mon, 30 Jun 2014 18:05:30 -0700 Subject: RFR 8048840: File.createTempFile has uninformative failure message Message-ID: Hi folks, We had a couple of complaints about this from our users, and it is a pretty trivial fix, so I'm throwing this out as a potential patch. I filed JDK-8048840: diff --git a/src/share/classes/java/io/File.java b/src/share/classes/java/io/File.java --- a/src/share/classes/java/io/File.java +++ b/src/share/classes/java/io/File.java @@ -1998,7 +1998,8 @@ throws IOException { if (prefix.length() < 3) - throw new IllegalArgumentException("Prefix string too short"); + throw new IllegalArgumentException("Prefix string too short: " + + prefix); if (suffix == null) suffix = ".tmp"; Jeremy From jeremymanson at google.com Tue Jul 1 01:21:21 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Mon, 30 Jun 2014 18:21:21 -0700 Subject: RFR 8048840: File.createTempFile has uninformative failure message In-Reply-To: References: Message-ID: Oops - forgot to run jtreg. Make that: diff --git a/src/share/classes/java/io/File.java b/src/share/classes/java/io/File.java --- a/src/share/classes/java/io/File.java +++ b/src/share/classes/java/io/File.java @@ -1998,7 +1998,8 @@ throws IOException { if (prefix.length() < 3) - throw new IllegalArgumentException("Prefix string too short"); + throw new IllegalArgumentException("Prefix string too short: " + + prefix); if (suffix == null) suffix = ".tmp"; diff --git a/test/java/io/File/NulFile.java b/test/java/io/File/NulFile.java --- a/test/java/io/File/NulFile.java +++ b/test/java/io/File/NulFile.java @@ -602,7 +602,8 @@ try { File.createTempFile(prefix, suffix, directory); } catch (IllegalArgumentException ex) { - if ("Prefix string too short".equals(ex.getMessage())) + String s = ex.getMessage(); + if (s != null && s.startsWith("Prefix string too short")) exceptionThrown = true; } catch (IOException ioe) { System.err.println("IOException happens in testCreateTempFile"); On Mon, Jun 30, 2014 at 6:05 PM, Jeremy Manson wrote: > Hi folks, > > We had a couple of complaints about this from our users, and it is a > pretty trivial fix, so I'm throwing this out as a potential patch. I > filed JDK-8048840: > > diff --git a/src/share/classes/java/io/File.java > b/src/share/classes/java/io/File.java > --- a/src/share/classes/java/io/File.java > +++ b/src/share/classes/java/io/File.java > @@ -1998,7 +1998,8 @@ > throws IOException > { > if (prefix.length() < 3) > - throw new IllegalArgumentException("Prefix string too short"); > + throw new IllegalArgumentException("Prefix string too short: > " + > + prefix); > if (suffix == null) > suffix = ".tmp"; > > Jeremy > From ecki at zusammenkunft.net Tue Jul 1 02:44:36 2014 From: ecki at zusammenkunft.net (Bernd) Date: Tue, 1 Jul 2014 04:44:36 +0200 Subject: RFR 8048840: File.createTempFile has uninformative failure message In-Reply-To: References: Message-ID: Hello, Do you think this fixes the complaints? I can imagine that "" or "~" is used, and including this in the exception does not really help. "Prefix string too short, must be 3 characters" would be my choice, but I wonder if the restriction is very usefull anyway? Bernd Am 01.07.2014 03:17 schrieb "Jeremy Manson" : > Hi folks, > > We had a couple of complaints about this from our users, and it is a pretty > trivial fix, so I'm throwing this out as a potential patch. I > filed JDK-8048840: > > diff --git a/src/share/classes/java/io/File.java > b/src/share/classes/java/io/File.java > --- a/src/share/classes/java/io/File.java > +++ b/src/share/classes/java/io/File.java > @@ -1998,7 +1998,8 @@ > throws IOException > { > if (prefix.length() < 3) > - throw new IllegalArgumentException("Prefix string too short"); > + throw new IllegalArgumentException("Prefix string too short: " > + > + prefix); > if (suffix == null) > suffix = ".tmp"; > > Jeremy > From christian.thalinger at oracle.com Tue Jul 1 04:51:23 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 30 Jun 2014 21:51:23 -0700 Subject: RFR 8047737 Move array component mirror to instance of java/lang/Class In-Reply-To: <53B205C7.8070804@oracle.com> References: <53ADC4D4.4030403@oracle.com> <53B0FBEF.5030607@oracle.com> <53B15B50.6070405@oracle.com> <53B205C7.8070804@oracle.com> Message-ID: On Jun 30, 2014, at 5:50 PM, Coleen Phillimore wrote: > > On 6/30/14, 3:50 PM, Christian Thalinger wrote: >> private Class(ClassLoader loader) { >> // Initialize final field for classLoader. The initialization value of non-null >> // prevents future JIT optimizations from assuming this final field is null. >> classLoader = loader; >> + componentType = null; >> } >> >> Are we worried about the same optimization? > > Hi, I've decided to make them consistent and add another parameter to the Class constructor. > > http://cr.openjdk.java.net/~coleenp/8047737_jdk_2/ Thanks. > > Thanks, > Coleen >> >> + compute_optional_offset(_component_mirror_offset, >> + klass_oop, vmSymbols::componentType_name(), >> + vmSymbols::class_signature()); >> >> Is there a followup cleanup to make it non-optional? Or, are you waiting for JPRT to be able to push hotspot and jdk changes together? >> >> On Jun 30, 2014, at 5:42 AM, Coleen Phillimore > wrote: >> >>> >>> On 6/30/14, 1:55 AM, David Holmes wrote: >>>> Hi Coleen, >>>> >>>> Your webrev links are to internal locations. >>> >>> Sorry, I cut/pasted the wrong links. They are: >>> >>> http://cr.openjdk.java.net/~coleenp/8047737_jdk/ >>> http://cr.openjdk.java.net/~coleenp/8047737_hotspot/ >>> >>> and the full version >>> >>> http://cr.openjdk.java.net/~coleenp/8047737_hotspot/ >>> >>> Thank you for pointing this out David. >>> >>> Coleen >>> >>>> >>>> David >>>> >>>> On 28/06/2014 5:24 AM, Coleen Phillimore wrote: >>>>> Summary: Add field in java.lang.Class for componentType to simplify oop >>>>> processing and intrinsics in JVM >>>>> >>>>> This is part of ongoing work to clean up oop pointers in the metadata >>>>> and simplify the interface between the JDK j.l.C and the JVM. There's a >>>>> performance benefit at the end of all of this if we can remove all oop >>>>> pointers from metadata. mirror in Klass is the only one left after >>>>> this full change. >>>>> >>>>> See bug https://bugs.openjdk.java.net/browse/JDK-8047737 >>>>> >>>>> There are a couple steps to this change because Hotspot testing is done >>>>> with promoted JDKs. The first step is this webrev: >>>>> >>>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_jdk/ >>>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot/ >>>>> >>>>> When the JDK is promoted, the code to remove >>>>> ArrayKlass::_component_mirror will be changed under a new bug id. >>>>> >>>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot_full >>>>> >>>>> Finally, a compatibility request and licensee notification will occur to >>>>> remove the function JVM_GetComponentType. >>>>> >>>>> Performance testing was done that shows no difference in performance. >>>>> The isArray() call is a compiler intrinsic which is now called instead >>>>> of getComponentType, which was recognized as a compiler intrinsic. >>>>> >>>>> JDK jtreg testing, hotspot jtreg testing, hotspot NSK testing and jck8 >>>>> tests were performed on both the change requested (1st one) and the full >>>>> change. >>>>> >>>>> hotspot NSK tests were run on the hotspot-only change with a promoted JDK. >>>>> >>>>> Please send your comments. >>>>> >>>>> Thanks, >>>>> Coleen >>> >> > From Alan.Bateman at oracle.com Tue Jul 1 08:34:43 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 01 Jul 2014 09:34:43 +0100 Subject: RFR 8048840: File.createTempFile has uninformative failure message In-Reply-To: References: Message-ID: <53B272A3.2050508@oracle.com> On 01/07/2014 02:21, Jeremy Manson wrote: > Oops - forgot to run jtreg. Make that: > > diff --git a/src/share/classes/java/io/File.java > b/src/share/classes/java/io/File.java > --- a/src/share/classes/java/io/File.java > +++ b/src/share/classes/java/io/File.java > @@ -1998,7 +1998,8 @@ > throws IOException > { > if (prefix.length() < 3) > - throw new IllegalArgumentException("Prefix string too short"); > + throw new IllegalArgumentException("Prefix string too short: " > + > + prefix); I assume you meant to "+ prefix" here, in which case the change seems okay to me. The update to the NulFile test seems okay too. As a side point then I think the need for a prefix is somewhat legacy now and this API could be re-visited some day. -Alan. From daniel.fuchs at oracle.com Tue Jul 1 09:25:33 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 01 Jul 2014 11:25:33 +0200 Subject: RFR: 8048020 - Regression on java.util.logging.FileHandler In-Reply-To: References: , <53A9C4C6.3060405@oracle.com> Message-ID: <53B27E8D.30405@oracle.com> On 6/25/14 2:34 PM, Jason Mehrens wrote: > Daniel, > > > FileChannel.open(WRITE,APPEND) could throw NoSuchFileException during a startup and shutdown race between two VMs. That case needs to either perform a bounded retry or continue and rotate. Hi Jason, Alan, Here is an updated version of the fix that does a bounded retry (retries once - and if it fails, proceeds with the next name). I have also added NO_FOLLOW_LINKS - for the case where we try to open an existing Lockfile, and suppressed the Files.isWritable check since that will be taken care of by the call to FileChannel.open. http://cr.openjdk.java.net/~dfuchs/webrev_8048020/webrev.01/ I also updated the comments to make it clear that the file could not have been locked by another instance of FileHandler (since that would have been taken care of by our global 'locks' synchronization). best regards, -- daniel > > > Jason > > ---------------------------------------- >> Date: Tue, 24 Jun 2014 20:34:46 +0200 >> From: daniel.fuchs at oracle.com >> To: core-libs-dev at openjdk.java.net >> CC: jason_mehrens at hotmail.com; Alan.Bateman at oracle.com >> Subject: RFR: 8048020 - Regression on java.util.logging.FileHandler >> >> Hi, >> >> Please find below a patch [1] for [2]: >> >> 8048020 - Regression on java.util.logging.FileHandler >> >> This corresponds to the problem that was discussed on this list >> in the following email thread: >> >> "Zombie FileHandler locks can exhaust all available log file locks." >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027296.html >> >> >> [1] http://cr.openjdk.java.net/~dfuchs/webrev_8048020/webrev.00/ >> [2] https://bugs.openjdk.java.net/browse/JDK-8048020 >> >> This patch would be a good candidate for being backported on 8, since >> the issue was introduced in 8. >> >> best regards, >> >> -- daniel From coleen.phillimore at oracle.com Tue Jul 1 11:24:15 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 01 Jul 2014 07:24:15 -0400 Subject: RFR 8047737 Move array component mirror to instance of java/lang/Class In-Reply-To: References: <53ADC4D4.4030403@oracle.com> <53B0FBEF.5030607@oracle.com> <53B15B50.6070405@oracle.com> <53B205C7.8070804@oracle.com> Message-ID: <53B29A5F.6000603@oracle.com> Thank you! Coleen On 7/1/14, 12:51 AM, Christian Thalinger wrote: > On Jun 30, 2014, at 5:50 PM, Coleen Phillimore wrote: > >> On 6/30/14, 3:50 PM, Christian Thalinger wrote: >>> private Class(ClassLoader loader) { >>> // Initialize final field for classLoader. The initialization value of non-null >>> // prevents future JIT optimizations from assuming this final field is null. >>> classLoader = loader; >>> + componentType = null; >>> } >>> >>> Are we worried about the same optimization? >> Hi, I've decided to make them consistent and add another parameter to the Class constructor. >> >> http://cr.openjdk.java.net/~coleenp/8047737_jdk_2/ > Thanks. > >> Thanks, >> Coleen >>> + compute_optional_offset(_component_mirror_offset, >>> + klass_oop, vmSymbols::componentType_name(), >>> + vmSymbols::class_signature()); >>> >>> Is there a followup cleanup to make it non-optional? Or, are you waiting for JPRT to be able to push hotspot and jdk changes together? >>> >>> On Jun 30, 2014, at 5:42 AM, Coleen Phillimore > wrote: >>> >>>> On 6/30/14, 1:55 AM, David Holmes wrote: >>>>> Hi Coleen, >>>>> >>>>> Your webrev links are to internal locations. >>>> Sorry, I cut/pasted the wrong links. They are: >>>> >>>> http://cr.openjdk.java.net/~coleenp/8047737_jdk/ >>>> http://cr.openjdk.java.net/~coleenp/8047737_hotspot/ >>>> >>>> and the full version >>>> >>>> http://cr.openjdk.java.net/~coleenp/8047737_hotspot/ >>>> >>>> Thank you for pointing this out David. >>>> >>>> Coleen >>>> >>>>> David >>>>> >>>>> On 28/06/2014 5:24 AM, Coleen Phillimore wrote: >>>>>> Summary: Add field in java.lang.Class for componentType to simplify oop >>>>>> processing and intrinsics in JVM >>>>>> >>>>>> This is part of ongoing work to clean up oop pointers in the metadata >>>>>> and simplify the interface between the JDK j.l.C and the JVM. There's a >>>>>> performance benefit at the end of all of this if we can remove all oop >>>>>> pointers from metadata. mirror in Klass is the only one left after >>>>>> this full change. >>>>>> >>>>>> See bug https://bugs.openjdk.java.net/browse/JDK-8047737 >>>>>> >>>>>> There are a couple steps to this change because Hotspot testing is done >>>>>> with promoted JDKs. The first step is this webrev: >>>>>> >>>>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_jdk/ >>>>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot/ >>>>>> >>>>>> When the JDK is promoted, the code to remove >>>>>> ArrayKlass::_component_mirror will be changed under a new bug id. >>>>>> >>>>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot_full >>>>>> >>>>>> Finally, a compatibility request and licensee notification will occur to >>>>>> remove the function JVM_GetComponentType. >>>>>> >>>>>> Performance testing was done that shows no difference in performance. >>>>>> The isArray() call is a compiler intrinsic which is now called instead >>>>>> of getComponentType, which was recognized as a compiler intrinsic. >>>>>> >>>>>> JDK jtreg testing, hotspot jtreg testing, hotspot NSK testing and jck8 >>>>>> tests were performed on both the change requested (1st one) and the full >>>>>> change. >>>>>> >>>>>> hotspot NSK tests were run on the hotspot-only change with a promoted JDK. >>>>>> >>>>>> Please send your comments. >>>>>> >>>>>> Thanks, >>>>>> Coleen From mark.sheppard at oracle.com Tue Jul 1 11:41:23 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Tue, 01 Jul 2014 12:41:23 +0100 Subject: RFR : 7095856: OutputStreamHook doesn't handle null values In-Reply-To: <53AD651C.2050304@oracle.com> References: <53AD651C.2050304@oracle.com> Message-ID: <53B29E63.6050001@oracle.com> Hi Sean, fix looks good .. surprised to see that GF has been modified to use HashMap and not the JDK wasn't!! In anycase this should solve a few other interop issues WRT the test, I wonder if it is more appropriate to use the javax.rmi.CORBA.Util class to obtain the ValueHandler rather that instantiating the impl classes (restricted) directly? e.g. import java.net.InetAddress; import javax.rmi.CORBA.Util; import javax.rmi.CORBA.ValueHandler; public class HookPutFieldsTest { public static void main(String[] args ) throws Exception { CustomOutputStream os = new CustomOutputStream(); InetAddress a = InetAddress.getByAddress(null, new byte[] {1,2,3,4}); ValueHandler vh = Util.createValueHandler(); vh.writeValue(os, a); } } regards Mark On 27/06/2014 13:35, Se?n Coffey wrote: > Looking for a review around this CORBA issue. > > bug report : https://bugs.openjdk.java.net/browse/JDK-7095856 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.7095856/ > > Null values cause issue when processed by an IIOPOutputStream and I > can't see a reason why they wouldn't be allowed. Note that the > glassfish code already employs a HashMap to hold such values. I've run > CORBA SQE tests, unit tests and relevant TCK tests. No issues seen. > > regards, > Sean. From pavel.rappo at oracle.com Tue Jul 1 12:39:02 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 1 Jul 2014 13:39:02 +0100 Subject: Character, Byte, Short valueOf instead of new instance In-Reply-To: References: Message-ID: <5D52EF6A-759F-489D-B419-4C97F3070905@oracle.com> Otavio, As with [1], I created an issue to track the progress and also made 2 webrevs. One for the original patch and one for the changes similar to those we discussed in [1]. https://bugs.openjdk.java.net/browse/JDK-8048874 http://cr.openjdk.java.net/~prappo/8048874/webrev.00 http://cr.openjdk.java.net/~prappo/8048874/webrev.01 ----------------------------------------------------------------------- [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027197.html Thanks, -Pavel On 26 Jun 2014, at 16:07, Chris Hegarty wrote: > Otavio, > > I scanner the patches and they mainly look fine to me. Just a minor issue, as per the Long thread. > > diff -r d02b062bc827 src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java > --- a/src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java Fri Jun 13 11:21:30 2014 -0700 > +++ b/src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java Sat Jun 14 13:33:29 2014 -0300 > @@ -379,7 +379,7 @@ > // used for substring comparisons (where proto has "*" wildcards > private boolean substringMatch(String proto, String value) { > // simple case 1: "*" means attribute presence is being tested > - if(proto.equals(new Character(WILDCARD_TOKEN).toString())) { > + if(proto.equals(Character.valueOf(WILDCARD_TOKEN).toString())) { // << Character.toString(WILDCARD_TOKEN) > if(debug) {System.out.println("simple presence assertion");} > return true; > } > > -Chris. > > On 14 Jun 2014, at 17:38, Ot?vio Gon?alves de Santana wrote: > >> Reason: The Character, Byte, Short classes have cache and using it, will >> save memory and will faster than using create new instance. >> >> webrev: >> https://dl.dropboxusercontent.com/u/16109193/open_jdk/byte_short_character_value_of.zip >> >> similar: https://bugs.openjdk.java.net/browse/JDK-8044461 >> >> -- >> Atenciosamente. >> >> Ot?vio Gon?alves de Santana >> >> blog: http://otaviosantana.blogspot.com.br/ >> twitter: http://twitter.com/otaviojava >> site: http://www.otaviojava.com.br >> (11) 98255-3513 >> > From andrej.golovnin at gmail.com Tue Jul 1 12:57:32 2014 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Tue, 1 Jul 2014 14:57:32 +0200 Subject: Character, Byte, Short valueOf instead of new instance In-Reply-To: <5D52EF6A-759F-489D-B419-4C97F3070905@oracle.com> References: <5D52EF6A-759F-489D-B419-4C97F3070905@oracle.com> Message-ID: Hi Pavel, I'm sorry I have totally forgotten to mention it. But I think that changes to the classes in the package "jdk.internal.org.objectweb.asm" should be done directly in the ASM library. In other case you may have conflicts when a new version of the ASM library is integrated into JDK next time. I hope you didn't committed the patch for the Longs yet. There were also changes to the classes in the package "jdk.internal.org.objectweb.asm". Best regards, Andrej Golovnin On Tue, Jul 1, 2014 at 2:39 PM, Pavel Rappo wrote: > Otavio, > > As with [1], I created an issue to track the progress and also made 2 > webrevs. One for the original patch and one for the changes similar to > those we discussed in [1]. > > https://bugs.openjdk.java.net/browse/JDK-8048874 > > http://cr.openjdk.java.net/~prappo/8048874/webrev.00 > http://cr.openjdk.java.net/~prappo/8048874/webrev.01 > > ----------------------------------------------------------------------- > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027197.html > > Thanks, > -Pavel > > On 26 Jun 2014, at 16:07, Chris Hegarty wrote: > > > Otavio, > > > > I scanner the patches and they mainly look fine to me. Just a minor > issue, as per the Long thread. > > > > diff -r d02b062bc827 > src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java > > --- a/src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java > Fri Jun 13 11:21:30 2014 -0700 > > +++ b/src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java > Sat Jun 14 13:33:29 2014 -0300 > > @@ -379,7 +379,7 @@ > > // used for substring comparisons (where proto has "*" wildcards > > private boolean substringMatch(String proto, String value) { > > // simple case 1: "*" means attribute presence is being > tested > > - if(proto.equals(new Character(WILDCARD_TOKEN).toString())) { > > + > if(proto.equals(Character.valueOf(WILDCARD_TOKEN).toString())) { // << > Character.toString(WILDCARD_TOKEN) > > if(debug) {System.out.println("simple presence > assertion");} > > return true; > > } > > > > -Chris. > > > > On 14 Jun 2014, at 17:38, Ot?vio Gon?alves de Santana < > otaviojava at java.net> wrote: > > > >> Reason: The Character, Byte, Short classes have cache and using it, will > >> save memory and will faster than using create new instance. > >> > >> webrev: > >> > https://dl.dropboxusercontent.com/u/16109193/open_jdk/byte_short_character_value_of.zip > >> > >> similar: https://bugs.openjdk.java.net/browse/JDK-8044461 > >> > >> -- > >> Atenciosamente. > >> > >> Ot?vio Gon?alves de Santana > >> > >> blog: http://otaviosantana.blogspot.com.br/ > >> twitter: http://twitter.com/otaviojava > >> site: http://www.otaviojava.com.br > >> (11) 98255-3513 > >> > > > > > From jason_mehrens at hotmail.com Tue Jul 1 13:40:32 2014 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Tue, 1 Jul 2014 08:40:32 -0500 Subject: RFR: 8048020 - Regression on java.util.logging.FileHandler In-Reply-To: <53B27E8D.30405@oracle.com> References: , <53A9C4C6.3060405@oracle.com> , <53B27E8D.30405@oracle.com> Message-ID: Daniel, Looks bullet proof to me. Jason ---------------------------------------- > Date: Tue, 1 Jul 2014 11:25:33 +0200 > From: daniel.fuchs at oracle.com > To: jason_mehrens at hotmail.com; core-libs-dev at openjdk.java.net > CC: alan.bateman at oracle.com > Subject: Re: RFR: 8048020 - Regression on java.util.logging.FileHandler > > On 6/25/14 2:34 PM, Jason Mehrens wrote: >> Daniel, >> >> >> FileChannel.open(WRITE,APPEND) could throw NoSuchFileException during a startup and shutdown race between two VMs. That case needs to either perform a bounded retry or continue and rotate. > > Hi Jason, Alan, > > Here is an updated version of the fix that does a bounded > retry (retries once - and if it fails, proceeds with the next > name). I have also added NO_FOLLOW_LINKS - for the case where > we try to open an existing Lockfile, and suppressed the > Files.isWritable check since that will be taken care of by > the call to FileChannel.open. > > http://cr.openjdk.java.net/~dfuchs/webrev_8048020/webrev.01/ > > I also updated the comments to make it clear that the > file could not have been locked by another instance > of FileHandler (since that would have been taken care > of by our global 'locks' synchronization). > > best regards, > > -- daniel > > >> >> >> Jason >> >> ---------------------------------------- >>> Date: Tue, 24 Jun 2014 20:34:46 +0200 >>> From: daniel.fuchs at oracle.com >>> To: core-libs-dev at openjdk.java.net >>> CC: jason_mehrens at hotmail.com; Alan.Bateman at oracle.com >>> Subject: RFR: 8048020 - Regression on java.util.logging.FileHandler >>> >>> Hi, >>> >>> Please find below a patch [1] for [2]: >>> >>> 8048020 - Regression on java.util.logging.FileHandler >>> >>> This corresponds to the problem that was discussed on this list >>> in the following email thread: >>> >>> "Zombie FileHandler locks can exhaust all available log file locks." >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027296.html >>> >>> >>> [1] http://cr.openjdk.java.net/~dfuchs/webrev_8048020/webrev.00/ >>> [2] https://bugs.openjdk.java.net/browse/JDK-8048020 >>> >>> This patch would be a good candidate for being backported on 8, since >>> the issue was introduced in 8. >>> >>> best regards, >>> >>> -- daniel > From sean.coffey at oracle.com Tue Jul 1 14:03:42 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 01 Jul 2014 15:03:42 +0100 Subject: RFR : 7095856: OutputStreamHook doesn't handle null values In-Reply-To: <53B29E63.6050001@oracle.com> References: <53AD651C.2050304@oracle.com> <53B29E63.6050001@oracle.com> Message-ID: <53B2BFBE.3020703@oracle.com> Hey Mark, thanks for the review. Yes - that's a better way to obtain the valueHandler - will make the change and push shortly. regards, Sean. On 01/07/14 12:41, Mark Sheppard wrote: > Hi Sean, > fix looks good .. surprised to see that GF has been modified to use > HashMap and not the JDK wasn't!! > In anycase this should solve a few other interop issues > > WRT the test, I wonder if it is more appropriate to use the > javax.rmi.CORBA.Util class to obtain the ValueHandler rather that > instantiating the impl classes (restricted) directly? > e.g. > > import java.net.InetAddress; > import javax.rmi.CORBA.Util; > import javax.rmi.CORBA.ValueHandler; > > public class HookPutFieldsTest { > > public static void main(String[] args ) throws Exception { > CustomOutputStream os = new CustomOutputStream(); > InetAddress a = InetAddress.getByAddress(null, new byte[] > {1,2,3,4}); > ValueHandler vh = Util.createValueHandler(); > vh.writeValue(os, a); > } > > } > > regards > Mark > > On 27/06/2014 13:35, Se?n Coffey wrote: >> Looking for a review around this CORBA issue. >> >> bug report : https://bugs.openjdk.java.net/browse/JDK-7095856 >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.7095856/ >> >> Null values cause issue when processed by an IIOPOutputStream and I >> can't see a reason why they wouldn't be allowed. Note that the >> glassfish code already employs a HashMap to hold such values. I've >> run CORBA SQE tests, unit tests and relevant TCK tests. No issues seen. >> >> regards, >> Sean. > From pavel.rappo at oracle.com Tue Jul 1 14:34:50 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 1 Jul 2014 15:34:50 +0100 Subject: Character, Byte, Short valueOf instead of new instance In-Reply-To: References: <5D52EF6A-759F-489D-B419-4C97F3070905@oracle.com> Message-ID: Andrej, Thanks a lot! I've separated out all the changes from the 'jdk.internal.org.objectweb.asm' package. So I'll update both threads with new webrevs. http://cr.openjdk.java.net/~prappo/8048874/webrev.02 -Pavel On 1 Jul 2014, at 13:57, Andrej Golovnin wrote: > Hi Pavel, > > I'm sorry I have totally forgotten to mention it. But I think that changes to the classes in the package "jdk.internal.org.objectweb.asm" should be done directly in the ASM library. In other case you may have conflicts when a new version of the ASM library is integrated into JDK next time. I hope you didn't committed the patch for the Longs yet. There were also changes to the classes in the package "jdk.internal.org.objectweb.asm". > > Best regards, > Andrej Golovnin > > > On Tue, Jul 1, 2014 at 2:39 PM, Pavel Rappo wrote: > Otavio, > > As with [1], I created an issue to track the progress and also made 2 webrevs. One for the original patch and one for the changes similar to those we discussed in [1]. > > https://bugs.openjdk.java.net/browse/JDK-8048874 > > http://cr.openjdk.java.net/~prappo/8048874/webrev.00 > http://cr.openjdk.java.net/~prappo/8048874/webrev.01 > > ----------------------------------------------------------------------- > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027197.html > > Thanks, > -Pavel > > On 26 Jun 2014, at 16:07, Chris Hegarty wrote: > > > Otavio, > > > > I scanner the patches and they mainly look fine to me. Just a minor issue, as per the Long thread. > > > > diff -r d02b062bc827 src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java > > --- a/src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java Fri Jun 13 11:21:30 2014 -0700 > > +++ b/src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java Sat Jun 14 13:33:29 2014 -0300 > > @@ -379,7 +379,7 @@ > > // used for substring comparisons (where proto has "*" wildcards > > private boolean substringMatch(String proto, String value) { > > // simple case 1: "*" means attribute presence is being tested > > - if(proto.equals(new Character(WILDCARD_TOKEN).toString())) { > > + if(proto.equals(Character.valueOf(WILDCARD_TOKEN).toString())) { // << Character.toString(WILDCARD_TOKEN) > > if(debug) {System.out.println("simple presence assertion");} > > return true; > > } > > > > -Chris. > > > > On 14 Jun 2014, at 17:38, Ot?vio Gon?alves de Santana wrote: > > > >> Reason: The Character, Byte, Short classes have cache and using it, will > >> save memory and will faster than using create new instance. > >> > >> webrev: > >> https://dl.dropboxusercontent.com/u/16109193/open_jdk/byte_short_character_value_of.zip > >> > >> similar: https://bugs.openjdk.java.net/browse/JDK-8044461 > >> > >> -- > >> Atenciosamente. > >> > >> Ot?vio Gon?alves de Santana > >> > >> blog: http://otaviosantana.blogspot.com.br/ > >> twitter: http://twitter.com/otaviojava > >> site: http://www.otaviojava.com.br > >> (11) 98255-3513 > >> > > > > From pavel.rappo at oracle.com Tue Jul 1 14:39:11 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 1 Jul 2014 15:39:11 +0100 Subject: Long valueOf instead of new Long In-Reply-To: <03AA424B-4B0B-4A10-8994-022767F3CB0D@oracle.com> References: <7A0B9548-639A-4726-9C3B-5B3CC1F35B96@oracle.com> <846BB379-4FCA-4D76-8E54-714A4E7D6D4D@gmail.com> <552050AC-8FB3-42F5-BA34-D39B136EFE2F@oracle.com> <03AA424B-4B0B-4A10-8994-022767F3CB0D@oracle.com> Message-ID: As per [1] I'm updating this thread with yet another webrev: http://cr.openjdk.java.net/~prappo/8048267/webrev.05 ----------------------------------------------------------------------- [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-July/027487.html -Pavel On 30 Jun 2014, at 13:04, Pavel Rappo wrote: > If a test run finishes fine, I'll push this version (no Unsafe*LongFieldFieldAccessorImpl.java files included): > > http://cr.openjdk.java.net/~prappo/8048267/webrev.04/ > > -Pavel > > On 30 Jun 2014, at 11:31, Andrej Golovnin wrote: > >> Hi Pavel, >> >> http://cr.openjdk.java.net/~prappo/8048267/webrev.03/src/share/classes/sun/reflect/UnsafeLongFieldAccessorImpl.java.sdiff.html >> http://cr.openjdk.java.net/~prappo/8048267/webrev.03/src/share/classes/sun/reflect/UnsafeQualifiedLongFieldAccessorImpl.java.sdiff.html >> http://cr.openjdk.java.net/~prappo/8048267/webrev.03/src/share/classes/sun/reflect/UnsafeQualifiedStaticLongFieldAccessorImpl.java.sdiff.html >> http://cr.openjdk.java.net/~prappo/8048267/webrev.03/src/share/classes/sun/reflect/UnsafeStaticLongFieldAccessorImpl.java.sdiff.html >> >> Please don't change the UnsafeXXXFieldAccessorImpl classes. >> This classes should be changed as a part of the fix of the issue 5043030. >> The patch for this issue has been already submitted, see here: >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027311.html >> >> When Joel is back, he will continue to work on it. >> >> Otherwise it looks good to me. >> >> Best regards, >> Andrej Golovnin > From peter.levart at gmail.com Tue Jul 1 15:16:08 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 01 Jul 2014 17:16:08 +0200 Subject: RFR JDK-7186258: InetAddress$Cache should replace currentTimeMillis with nanoTime (+more) Message-ID: <53B2D0B8.9050403@gmail.com> Hi, I propose a patch for this issue: https://bugs.openjdk.java.net/browse/JDK-7186258 The motivation to re-design caching of InetAddress-es was not this issue though, but a desire to attack synchronization bottlenecks in methods like URL.equals and URL.hashCode which use host name to IP address mapping. I plan to tackle the synchronization in URL in a follow-up proposal, but I wanted to 1st iron-out the "leaves" of the call-tree. Here's the proposed patch: http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/webrev.01/ sun.net.InetAddressCachePolicy: - two static methods (get() and getNegative()) were synchronized. Removed synchronization and made underlying fields volatile. - also added a normalization of negative policy in setNegativeIfNotSet(). The logic in InetAddress doesn't cope with negative values distinct from InetAddressCachePolicy.FOREVER (-1), so this was a straight bug. The setIfNotSet() doesn't need this normalization, because checkValue() throws exception if passed-in value < InetAddressCachePolicy.FOREVER. java.net.InetAddress: - complete redesign of caching. Instead of distinct Positive/Negative caches, there's only one cache - a ConcurrentHashMap. The value in the map knows if it contains positive or negative answer. - the design of this cache is similar but much simpler than java.lang.reflect.WeakCache, since it doesn't have to deal with WeakReferences and keys are simpler (just strings - hostnames). Similarity is in how concurrent requests for the same key (hostname) are synchronized when the entry is not cached yet, but still avoid synchronization when entry is cached. This preserves the behaviour of original InetAddress caching code but simplifies it greatly (100+ lines removed). - I tried to preserve the interaction between InetAddress.getLocalHost() and InetAddress.getByName(). The getLocalHost() caches the local host address for 5 seconds privately. When it expires it performs new name service look-up and "refreshes" the entry in the InetAddress.getByName() cache although it has not expired yet. I think this is meant to prevent surprises when getLocalHost() returns newer address than getByName() which is called after that. - I also fixed the JDK-7186258 as a by-product (but don't know yet how to write a test for this issue - any ideas?) I created a JMH benchmark that tests the following methods: - InetAddress.getLocalHost() - InetAddress.getByName() (with positive and negative answer) Here're the results of running on my 4-core (8-threads) i7/Linux: http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/InetAddress.Cache_bench_results.01.pdf The getByNameNegative() test does not show much improvement in patched vs. original code. That's because by default the policy is to NOT cache negative answers. Requests for same hostname to the NameService(s) are synchronized. If "networkaddress.cache.negative.ttl" system property is set to some positive value, results are similar to those of getByNamePositive() test (the default policy for positive caching is 30 seconds). I ran the jtreg tests in test/java/net and have the same score as with original unpatched code. I have 3 failing tests from original and patched runs: JT Harness : Tests that failed java/net/MulticastSocket/Promiscuous.java: Test for interference when two sockets are bound to the same port but joined to different multicast groups java/net/MulticastSocket/SetLoopbackMode.java: Test MulticastSocket.setLoopbackMode java/net/MulticastSocket/Test.java: IPv4 and IPv6 multicasting broken on Linux And 1 test that had error trying to be run: JT Harness : Tests that had errors java/net/URLPermission/nstest/lookup.sh: Because of: test result: Error. Can't find source file: jdk/testlibrary/*.java in directory-list: /home/peter/work/hg/jdk9-dev/jdk/test/java/net/URLPermission/nstest /home/peter/work/hg/jdk9-dev/jdk/test/lib/testlibrary All other 258 java/net tests pass. So what do you think? Regards, Peter From golovnin at gmx.net Tue Jul 1 20:54:14 2014 From: golovnin at gmx.net (Andrej Golovnin) Date: Tue, 1 Jul 2014 22:54:14 +0200 Subject: Long valueOf instead of new Long In-Reply-To: References: <7A0B9548-639A-4726-9C3B-5B3CC1F35B96@oracle.com> <846BB379-4FCA-4D76-8E54-714A4E7D6D4D@gmail.com> <552050AC-8FB3-42F5-BA34-D39B136EFE2F@oracle.com> <03AA424B-4B0B-4A10-8994-022767F3CB0D@oracle.com> Message-ID: <1CAEB7F5-2D31-4748-8A95-E70ADA4D74DE@gmx.net> Hi Pavel, > As per [1] I'm updating this thread with yet another webrev: > > http://cr.openjdk.java.net/~prappo/8048267/webrev.05 Thanks and looks good. Best regards, Andrej Golovnin From andrej.golovnin at gmail.com Tue Jul 1 21:01:06 2014 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Tue, 1 Jul 2014 23:01:06 +0200 Subject: Character, Byte, Short valueOf instead of new instance In-Reply-To: References: <5D52EF6A-759F-489D-B419-4C97F3070905@oracle.com> Message-ID: Hi Pavel, > Thanks a lot! I've separated out all the changes from the 'jdk.internal.org.objectweb.asm' package. So I'll update both threads with new webrevs. > > http://cr.openjdk.java.net/~prappo/8048874/webrev.02 Looks good to me. @Ot?vio: Could you please submit the ASM related changes to the ASM project [1]? Thanks! Best regards, Andrej Golovnin [1] http://asm.ow2.org/ From ivan.gerasimov at oracle.com Tue Jul 1 21:29:50 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 02 Jul 2014 01:29:50 +0400 Subject: [8u20] Request for approval: 6545422: TEST BUG: NativeErrors.java uses wrong path name in exec In-Reply-To: <530B0DB5.3080500@oracle.com> References: <530B0952.6090305@oracle.com> <530B0AE9.1070307@oracle.com> <530B0DB5.3080500@oracle.com> Message-ID: <53B3284E.80309@oracle.com> Hello! I'm rerequesting an approval to backport this test fix into jdk8u. To address the issue with NoClassDefFoundError I added the implicit @build line to the test (as it was done in JDK-8043520). BUGURL: https://bugs.openjdk.java.net/browse/JDK-6545422 WEBREV: http://cr.openjdk.java.net/~igerasim/6545422/0/webrev/ Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/efeab0eae50f Review: http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-February/014152.html Would you please approve the backport? Sincerely yours, Ivan On 24.02.2014 13:15, Ivan Gerasimov wrote: > > On 24.02.2014 13:03, Alan Bateman wrote: >> On 24/02/2014 08:56, Ivan Gerasimov wrote: >>> Hello! >>> >>> Would you please approve porting back this test bug fix? >>> The fix applies cleanly to jdk8u. >>> >>> Master Bug: https://bugs.openjdk.java.net/browse/JDK-6545422 >>> Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/efeab0eae50f >>> Review: >>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-February/014152.html >> Ivan - would it be possible to hold back on this one for a bit. The >> updated test is dependent on implicit compilation of the classes in >> the @library and this is causing problems for concurrent test runs. >> The same pattern has slipped into 15-20 other tests with the result >> that they all fail intermittently due to NoClassDefFoundError issues. >> I think they should be fixed in jdk9-dev but any of these "improved" >> tests are backported. >> > > Yes, sure! > Actually, I was going to port this fix into jdk6 (the test fails > there), but modified in such a way that it does not depend on > testlibrary. > I can still work on jdk6 port without first integrating it into jdk8u > and jdk7u. > > Sincerely yours, > Ivan > > >> -Alan. >> >> > > > > From ivan.gerasimov at oracle.com Tue Jul 1 21:32:33 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 02 Jul 2014 01:32:33 +0400 Subject: [8u-dev] Request for approval: 6545422: TEST BUG: NativeErrors.java uses wrong path name in exec In-Reply-To: <53B3284E.80309@oracle.com> References: <530B0952.6090305@oracle.com> <530B0AE9.1070307@oracle.com> <530B0DB5.3080500@oracle.com> <53B3284E.80309@oracle.com> Message-ID: <53B328F1.5070501@oracle.com> Corrected the subject line: I'm requesting an approval to push the fix into jdk8u-dev repo, not jdk8u20 On 02.07.2014 1:29, Ivan Gerasimov wrote: > Hello! > > I'm rerequesting an approval to backport this test fix into jdk8u. > To address the issue with NoClassDefFoundError I added the implicit > @build line to the test (as it was done in JDK-8043520). > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-6545422 > WEBREV: http://cr.openjdk.java.net/~igerasim/6545422/0/webrev/ > Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/efeab0eae50f > Review: > http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-February/014152.html > > Would you please approve the backport? > > Sincerely yours, > Ivan > > On 24.02.2014 13:15, Ivan Gerasimov wrote: >> >> On 24.02.2014 13:03, Alan Bateman wrote: >>> On 24/02/2014 08:56, Ivan Gerasimov wrote: >>>> Hello! >>>> >>>> Would you please approve porting back this test bug fix? >>>> The fix applies cleanly to jdk8u. >>>> >>>> Master Bug: https://bugs.openjdk.java.net/browse/JDK-6545422 >>>> Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/efeab0eae50f >>>> Review: >>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-February/014152.html >>> Ivan - would it be possible to hold back on this one for a bit. The >>> updated test is dependent on implicit compilation of the classes in >>> the @library and this is causing problems for concurrent test runs. >>> The same pattern has slipped into 15-20 other tests with the result >>> that they all fail intermittently due to NoClassDefFoundError >>> issues. I think they should be fixed in jdk9-dev but any of these >>> "improved" tests are backported. >>> >> >> Yes, sure! >> Actually, I was going to port this fix into jdk6 (the test fails >> there), but modified in such a way that it does not depend on >> testlibrary. >> I can still work on jdk6 port without first integrating it into jdk8u >> and jdk7u. >> >> Sincerely yours, >> Ivan >> >> >>> -Alan. >>> >>> >> >> >> >> > > > From forax at univ-mlv.fr Tue Jul 1 22:28:59 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 02 Jul 2014 00:28:59 +0200 Subject: Character, Byte, Short valueOf instead of new instance In-Reply-To: References: <5D52EF6A-759F-489D-B419-4C97F3070905@oracle.com> Message-ID: <53B3362B.3000802@univ-mlv.fr> On 07/01/2014 11:01 PM, Andrej Golovnin wrote: > Hi Pavel, > >> Thanks a lot! I've separated out all the changes from the 'jdk.internal.org.objectweb.asm' package. So I'll update both threads with new webrevs. >> >> http://cr.openjdk.java.net/~prappo/8048874/webrev.02 > Looks good to me. > > @Ot?vio: Could you please submit the ASM related changes to the ASM project [1]? Thanks! > > Best regards, > Andrej Golovnin > > [1] http://asm.ow2.org/ Paul Sandoz had already sent the changes related to ASM. I'm currently reviewing them. R?mi From otaviojava at java.net Tue Jul 1 23:07:00 2014 From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Tue, 1 Jul 2014 20:07:00 -0300 Subject: Character, Byte, Short valueOf instead of new instance In-Reply-To: <53B3362B.3000802@univ-mlv.fr> References: <5D52EF6A-759F-489D-B419-4C97F3070905@oracle.com> <53B3362B.3000802@univ-mlv.fr> Message-ID: Thank you Remi. The long[1] also was included? [1]https://bugs.openjdk.java.net/browse/JDK-8048267 On Tue, Jul 1, 2014 at 7:28 PM, Remi Forax wrote: > > On 07/01/2014 11:01 PM, Andrej Golovnin wrote: > >> Hi Pavel, >> >> Thanks a lot! I've separated out all the changes from the >>> 'jdk.internal.org.objectweb.asm' package. So I'll update both threads >>> with new webrevs. >>> >>> http://cr.openjdk.java.net/~prappo/8048874/webrev.02 >>> >> Looks good to me. >> >> @Ot?vio: Could you please submit the ASM related changes to the ASM >> project [1]? Thanks! >> >> Best regards, >> Andrej Golovnin >> >> [1] http://asm.ow2.org/ >> > > Paul Sandoz had already sent the changes related to ASM. > I'm currently reviewing them. > > R?mi > > -- Atenciosamente. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513 From jeremymanson at google.com Tue Jul 1 23:16:42 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 1 Jul 2014 16:16:42 -0700 Subject: RFR 8048840: File.createTempFile has uninformative failure message In-Reply-To: <53B272A3.2050508@oracle.com> References: <53B272A3.2050508@oracle.com> Message-ID: Should I add a message about a three character minimum? Jeremy On Tue, Jul 1, 2014 at 1:34 AM, Alan Bateman wrote: > On 01/07/2014 02:21, Jeremy Manson wrote: > >> Oops - forgot to run jtreg. Make that: >> >> diff --git a/src/share/classes/java/io/File.java >> b/src/share/classes/java/io/File.java >> --- a/src/share/classes/java/io/File.java >> +++ b/src/share/classes/java/io/File.java >> @@ -1998,7 +1998,8 @@ >> throws IOException >> { >> if (prefix.length() < 3) >> - throw new IllegalArgumentException("Prefix string too >> short"); >> + throw new IllegalArgumentException("Prefix string too >> short: " >> + >> + prefix); >> > I assume you meant to "+ prefix" here, in which case the change seems okay > to me. The update to the NulFile test seems okay too. > > As a side point then I think the need for a prefix is somewhat legacy now > and this API could be re-visited some day. > > -Alan. > From stuart.marks at oracle.com Tue Jul 1 23:29:20 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 01 Jul 2014 16:29:20 -0700 Subject: RFR 8048840: File.createTempFile has uninformative failure message In-Reply-To: <53B272A3.2050508@oracle.com> References: <53B272A3.2050508@oracle.com> Message-ID: <53B34450.2080307@oracle.com> On 7/1/14 1:34 AM, Alan Bateman wrote: > On 01/07/2014 02:21, Jeremy Manson wrote: >> diff --git a/src/share/classes/java/io/File.java >> b/src/share/classes/java/io/File.java >> --- a/src/share/classes/java/io/File.java >> +++ b/src/share/classes/java/io/File.java >> @@ -1998,7 +1998,8 @@ >> throws IOException >> { >> if (prefix.length() < 3) >> - throw new IllegalArgumentException("Prefix string too short"); >> + throw new IllegalArgumentException("Prefix string too short: " >> + >> + prefix); > I assume you meant to "+ prefix" here, in which case the change seems okay to > me. The update to the NulFile test seems okay too. Ha! I was wondering about this too. Turns out that the trailing "+" on the "throw new" line was wrapped to the beginning of the next line, making it appear to be the addition of an extra, blank line. > diff --git a/test/java/io/File/NulFile.java b/test/java/io/File/NulFile.java > --- a/test/java/io/File/NulFile.java > +++ b/test/java/io/File/NulFile.java > @@ -602,7 +602,8 @@ > try { > File.createTempFile(prefix, suffix, directory); > } catch (IllegalArgumentException ex) { > - if ("Prefix string too short".equals(ex.getMessage())) > + String s = ex.getMessage(); > + if (s != null && s.startsWith("Prefix string too short")) > exceptionThrown = true; > } catch (IOException ioe) { > System.err.println("IOException happens in > testCreateTempFile"); I'd advocate removing the string-testing logic from this catch-clause. I'm somewhat allergic to tests that make assertions about the contents of things like error messages. It generally doesn't add any value, but it increases maintenance effort -- like in this case. s'marks From martinrb at google.com Tue Jul 1 23:28:33 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 1 Jul 2014 16:28:33 -0700 Subject: RFR(S): JDK-8048990 ZipFile.entries() can't handle empty zip entry names Message-ID: Hi Xueming, I'd like you to do a code review. Webrev: http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ZipEntryEmptyName/ Bug: https://bugs.openjdk.java.net/browse/JDK-8048990 From martinrb at google.com Tue Jul 1 23:33:15 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 1 Jul 2014 16:33:15 -0700 Subject: RFR 8048840: File.createTempFile has uninformative failure message In-Reply-To: References: <53B272A3.2050508@oracle.com> Message-ID: I agree that we should try for a better error message (for our users' debugging happiness, just including the prefix was enough). My suggestion: "Prefix string \"" + prefix + "\" too short: length must be at least 3" On Tue, Jul 1, 2014 at 4:16 PM, Jeremy Manson wrote: > Should I add a message about a three character minimum? > > Jeremy > > > On Tue, Jul 1, 2014 at 1:34 AM, Alan Bateman > wrote: > > > On 01/07/2014 02:21, Jeremy Manson wrote: > > > >> Oops - forgot to run jtreg. Make that: > >> > >> diff --git a/src/share/classes/java/io/File.java > >> b/src/share/classes/java/io/File.java > >> --- a/src/share/classes/java/io/File.java > >> +++ b/src/share/classes/java/io/File.java > >> @@ -1998,7 +1998,8 @@ > >> throws IOException > >> { > >> if (prefix.length() < 3) > >> - throw new IllegalArgumentException("Prefix string too > >> short"); > >> + throw new IllegalArgumentException("Prefix string too > >> short: " > >> + > >> + prefix); > >> > > I assume you meant to "+ prefix" here, in which case the change seems > okay > > to me. The update to the NulFile test seems okay too. > > > > As a side point then I think the need for a prefix is somewhat legacy now > > and this API could be re-visited some day. > > > > -Alan. > > > From jeremymanson at google.com Tue Jul 1 23:39:24 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 1 Jul 2014 16:39:24 -0700 Subject: RFR 8048840: File.createTempFile has uninformative failure message In-Reply-To: References: <53B272A3.2050508@oracle.com> Message-ID: If Martin's happy, I'm happy. Martin, should I regenerate the patch with that wording? Jeremy On Tue, Jul 1, 2014 at 4:33 PM, Martin Buchholz wrote: > I agree that we should try for a better error message (for our users' > debugging happiness, just including the prefix was enough). My suggestion: > > "Prefix string \"" + prefix + "\" too short: length must be at least 3" > > > On Tue, Jul 1, 2014 at 4:16 PM, Jeremy Manson > wrote: > >> Should I add a message about a three character minimum? >> >> Jeremy >> >> >> On Tue, Jul 1, 2014 at 1:34 AM, Alan Bateman >> wrote: >> >> > On 01/07/2014 02:21, Jeremy Manson wrote: >> > >> >> Oops - forgot to run jtreg. Make that: >> >> >> >> diff --git a/src/share/classes/java/io/File.java >> >> b/src/share/classes/java/io/File.java >> >> --- a/src/share/classes/java/io/File.java >> >> +++ b/src/share/classes/java/io/File.java >> >> @@ -1998,7 +1998,8 @@ >> >> throws IOException >> >> { >> >> if (prefix.length() < 3) >> >> - throw new IllegalArgumentException("Prefix string too >> >> short"); >> >> + throw new IllegalArgumentException("Prefix string too >> >> short: " >> >> + >> >> + prefix); >> >> >> > I assume you meant to "+ prefix" here, in which case the change seems >> okay >> > to me. The update to the NulFile test seems okay too. >> > >> > As a side point then I think the need for a prefix is somewhat legacy >> now >> > and this API could be re-visited some day. >> > >> > -Alan. >> > >> > > From martinrb at google.com Tue Jul 1 23:46:11 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 1 Jul 2014 16:46:11 -0700 Subject: RFR 8048840: File.createTempFile has uninformative failure message In-Reply-To: References: <53B272A3.2050508@oracle.com> Message-ID: On Tue, Jul 1, 2014 at 4:39 PM, Jeremy Manson wrote: > If Martin's happy, I'm happy. Martin, should I regenerate the patch with > that wording? > Yeah - I will try to sponsor this change. From jeremymanson at google.com Wed Jul 2 00:02:33 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 1 Jul 2014 17:02:33 -0700 Subject: RFR 8048840: File.createTempFile has uninformative failure message In-Reply-To: References: <53B272A3.2050508@oracle.com> Message-ID: Here you go (far too lazy to generate a webrev for this. :) ) diff --git a/src/share/classes/java/io/File.java b/src/share/classes/java/io/File.java --- a/src/share/classes/java/io/File.java +++ b/src/share/classes/java/io/File.java @@ -1997,8 +1997,10 @@ File directory) throws IOException { - if (prefix.length() < 3) - throw new IllegalArgumentException("Prefix string too short"); + if (prefix.length() < 3) { + throw new IllegalArgumentException("Prefix string \"" + prefix + + "\" too short: length must be at least 3"); + } if (suffix == null) suffix = ".tmp"; diff --git a/test/java/io/File/NulFile.java b/test/java/io/File/NulFile.java --- a/test/java/io/File/NulFile.java +++ b/test/java/io/File/NulFile.java @@ -602,7 +602,10 @@ try { File.createTempFile(prefix, suffix, directory); } catch (IllegalArgumentException ex) { - if ("Prefix string too short".equals(ex.getMessage())) + String actual = ex.getMessage(); + String expected = "Prefix string \"" + prefix + + "\" too short: length must be at least 3"; + if (actual != null && actual.equals(expected)) exceptionThrown = true; } catch (IOException ioe) { System.err.println("IOException happens in testCreateTempFile"); On Tue, Jul 1, 2014 at 4:46 PM, Martin Buchholz wrote: > > > > On Tue, Jul 1, 2014 at 4:39 PM, Jeremy Manson > wrote: > >> If Martin's happy, I'm happy. Martin, should I regenerate the patch with >> that wording? >> > > Yeah - I will try to sponsor this change. > From stuart.marks at oracle.com Wed Jul 2 00:31:38 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 01 Jul 2014 17:31:38 -0700 Subject: RFR: 8047722: @since tag cleanup in corba In-Reply-To: <53B17F71.1040706@oracle.com> References: <53A4A789.6040609@oracle.com> <53B0BDA0.9070004@oracle.com> <53B10F5E.3010005@oracle.com> <53B17F71.1040706@oracle.com> Message-ID: <53B352EA.4060001@oracle.com> On 6/30/14 8:17 AM, Henry Jen wrote: > On 06/30/2014 12:18 AM, Alan Bateman wrote: >> On 30/06/2014 02:30, Henry Jen wrote: >>> On 06/20/2014 02:28 PM, Henry Jen wrote: >>>> Please review a trivial webrev for jdk9/corba that do the same @since >>>> tag normalization as in jdk9/jdk. >>>> >>>> http://cr.openjdk.java.net/~henryjen/jdk9/8047722/0/webrev/ >> There are bunch of @since JDK 1.0 and JDK 1.1.6 that you are changing to >> 1.0 and 1.1.6. AFAIK, CORBA was added in 1.2 and I wonder if we should >> fix this as part of this change. >> > > Thanks for review. You are correct that CORBA was added in 1.2. > > My understadning to those 1.0 to 1.1.6 versions are for override methods, I > guess the author is putting down the version of the origin. > > There are several cases where @since can be ambiguous without a common guideline, > > - An method was private or package access only made public, should @since denote > the API availablity or the implementation? > > - APIs from classed was extracted into a super class or interface in a later > version, what should be the @since? > > - Implementation of interface methods > > - Override methods > > Guess they are actually all the same question, does @since mean API availability > or implementation? > > For prior, interface/override methods should not carry it's own since, for > later, it should have @since as the owner class. There are some strange cases here. But the high order question is API vs implementation, and I think @since really is about API. However, I don't think @since should be inherited. For example, Collection was added in 1.2 and Queue (extends Collection) was added in 1.5. Queue has an add() method that's specified by Collection, but Queue.add() shouldn't have @since 1.2 on it, since Queue.add() didn't exist before 1.5. On the other hand, the addition of an overriding method shouldn't cause @since to change, because the overridden method was available on that class at the point it was introduced even though it was inherited, not overridden. I'd also say that when a private or package-access is made protected or public, it becomes visible in the API at that point, so @since should have the release at which it became visible, not when the implementation was introduced. However, protected => public doesn't change the visibility, so that shouldn't cause @since to change. [1] Pulling up a method into a superclass or superinterface (do we ever do this?) is like introducing an API into that class/interface, so @since should record when that happened. I looked at src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java and there are some odd cases here. First, the class itself is a private implementation class in com.sun, so do we need to track @since tags for it? Second, the class has a @since 1.1.6 tag which seems to conflict with the introduction of CORBA into 1.2. However, IIOPInputStream inherits from ObjectInputStream, which says "@since JDK1.1" so I'm not sure where 1.1.6 might have come from. Third, the readObjectDelegate(), defaultReadObjectDelegate(), and enableResolveObjectDelegate() methods each have *two* @since tags, JDK1.1.6 and JDK1.1. Not sure where these would have come from, since ObjectInputStream has never had such methods. Fourth, CORBA contains *copies* of old versions of some source files, such as ObjectStreamClass_1_3_1.java and IdentityHashTable.java (read the comments for why). Those files have @since tags apparently copied from the originals, 1.1 and even 1.0. If these were API classes I'd say that @since ought to have been adjusted to the actual release of introduction, but they're private implementation classes, so.... * * * Anyway, it looks like all the 1.1.6 references occur in private implementation classes, so they won't be visible in javadoc. Even though these are arguably wrong it probably doesn't matter. Changing "JDK1.1" to "1.1" is probably OK. But maybe we just don't need to worry about fixing things like the presence of "1.1" in a package that was introduced until 1.2, or fixing duplicate @since tags, etc. Aside from this, the additions and fixes in the public API files look fine to me. s'marks [1] http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#@since From stuart.marks at oracle.com Wed Jul 2 00:34:56 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 01 Jul 2014 17:34:56 -0700 Subject: RFR(XS): JDK-8048989 small errors in Collectors examples Message-ID: <53B353B0.2010202@oracle.com> Please review this small patch to fix some errors in the examples in the docs for java.util.stream.Collectors. Thanks to Raoul Urma for pointing these out. s'marks # HG changeset patch # User smarks # Date 1404256293 25200 # Tue Jul 01 16:11:33 2014 -0700 # Node ID 5b6a12d8a26e96052bc1c3ff787e8836fa4d64da # Parent 71012e1b8534c481ba42a38e77fca0b90299628d 8048989: small errors in Collectors examples Reviewed-by: XXX Contributed-by: raoul at urma.com diff -r 71012e1b8534 -r 5b6a12d8a26e src/share/classes/java/util/stream/Collectors.java --- a/src/share/classes/java/util/stream/Collectors.java Mon Jun 16 17:52:21 2014 -0700 +++ b/src/share/classes/java/util/stream/Collectors.java Tue Jul 01 16:11:33 2014 -0700 @@ -729,7 +729,7 @@ * person in each city: *
{@code
       *     Comparator byHeight = Comparator.comparing(Person::getHeight);
-     *     Map tallestByCity
+     *     Map> tallestByCity
       *         = people.stream().collect(groupingBy(Person::getCity, 
reducing(BinaryOperator.maxBy(byHeight))));
       * }
* @@ -784,7 +784,7 @@ * Comparator byLength = Comparator.comparing(String::length); * Map longestLastNameByCity * = people.stream().collect(groupingBy(Person::getCity, - * reducing(Person::getLastName, BinaryOperator.maxBy(byLength)))); + * reducing("", Person::getLastName, BinaryOperator.maxBy(byLength)))); * } * * @param the type of the input elements From joe.darcy at oracle.com Wed Jul 2 00:41:58 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 01 Jul 2014 17:41:58 -0700 Subject: RFR(XS): JDK-8048989 small errors in Collectors examples In-Reply-To: <53B353B0.2010202@oracle.com> References: <53B353B0.2010202@oracle.com> Message-ID: <53B35556.7030208@oracle.com> Looks fine Stuart, -Joe On 07/01/2014 05:34 PM, Stuart Marks wrote: > Please review this small patch to fix some errors in the examples in > the docs for java.util.stream.Collectors. Thanks to Raoul Urma for > pointing these out. > > s'marks > > # HG changeset patch > # User smarks > # Date 1404256293 25200 > # Tue Jul 01 16:11:33 2014 -0700 > # Node ID 5b6a12d8a26e96052bc1c3ff787e8836fa4d64da > # Parent 71012e1b8534c481ba42a38e77fca0b90299628d > 8048989: small errors in Collectors examples > Reviewed-by: XXX > Contributed-by: raoul at urma.com > > diff -r 71012e1b8534 -r 5b6a12d8a26e > src/share/classes/java/util/stream/Collectors.java > --- a/src/share/classes/java/util/stream/Collectors.java Mon Jun 16 > 17:52:21 2014 -0700 > +++ b/src/share/classes/java/util/stream/Collectors.java Tue Jul 01 > 16:11:33 2014 -0700 > @@ -729,7 +729,7 @@ > * person in each city: > *
{@code
>       *     Comparator byHeight = 
> Comparator.comparing(Person::getHeight);
> -     *     Map tallestByCity
> +     *     Map> tallestByCity
>       *         = people.stream().collect(groupingBy(Person::getCity, 
> reducing(BinaryOperator.maxBy(byHeight))));
>       * }
> * > @@ -784,7 +784,7 @@ > * Comparator byLength = > Comparator.comparing(String::length); > * Map longestLastNameByCity > * = people.stream().collect(groupingBy(Person::getCity, > - * reducing(Person::getLastName, BinaryOperator.maxBy(byLength)))); > + * reducing("", > Person::getLastName, BinaryOperator.maxBy(byLength)))); > * } > * > * @param the type of the input elements > From mandy.chung at oracle.com Wed Jul 2 06:26:43 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 01 Jul 2014 23:26:43 -0700 Subject: RFR 8047737 Move array component mirror to instance of java/lang/Class In-Reply-To: References: <53ADC4D4.4030403@oracle.com> <53B0FBEF.5030607@oracle.com> <53B15B50.6070405@oracle.com> <53B205C7.8070804@oracle.com> Message-ID: <53B3A623.1050804@oracle.com> On 6/30/2014 9:51 PM, Christian Thalinger wrote: > On Jun 30, 2014, at 5:50 PM, Coleen Phillimore wrote: > > > On 6/30/14, 3:50 PM, Christian Thalinger wrote: >>> private Class(ClassLoader loader) { >>> // Initialize final field for classLoader. The initialization value of non-null >>> // prevents future JIT optimizations from assuming this final field is null. >>> classLoader = loader; >>> + componentType = null; >>> } >>> >>> Are we worried about the same optimization? >> Hi, I've decided to make them consistent and add another parameter to the Class constructor. >> >> http://cr.openjdk.java.net/~coleenp/8047737_jdk_2/ The jdk change looks okay while I am beginning to think whether we really want to keep expanding this constructor to deal with this future JIT optimization (you will be moving more fields out from the VM to java.lang.Class). There are places in JDK initializing the final fields to null while the final field value is overridden via native/VM - e.g. System.in, System.out, etc. I would prefer reverting the classLoader constructor change to expanding the constructor for any new field being added. Handle it (and other places in JDK) when such JIT optimization comes. Mandy From pavel.rappo at oracle.com Wed Jul 2 07:18:55 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 2 Jul 2014 08:18:55 +0100 Subject: Character, Byte, Short valueOf instead of new instance In-Reply-To: References: <5D52EF6A-759F-489D-B419-4C97F3070905@oracle.com> Message-ID: <7F6A398B-05C5-4781-A80A-266FEEA9C9A2@oracle.com> Andrej, Otavio, No need to do it. We've already done it. -Pavel On 1 Jul 2014, at 22:01, Andrej Golovnin wrote: > Could you please submit the ASM related changes to the ASM project [1]? From paul.sandoz at oracle.com Wed Jul 2 08:25:26 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 2 Jul 2014 10:25:26 +0200 Subject: RFR 8043328 and 8043327: errors in stream docs Message-ID: <6BD5BE4B-3FA1-406F-ADEB-99B0626B7BAC@oracle.com> Hi, Stuarts recent doc fix from Raoul reminded me about a few others: https://bugs.openjdk.java.net/browse/JDK-8043328 Typo in documentation of package java.util.stream https://bugs.openjdk.java.net/browse/JDK-8043327 Collectors.toMap studentToGPA example uses Functions.identity() See below for patch. Stuart, are you planning to back port your doc fix to 8u-dev? If so we could do all three in one go. Paul. diff -r 4623ea09772f src/share/classes/java/util/stream/Collectors.java --- a/src/share/classes/java/util/stream/Collectors.java Wed Jul 02 08:41:59 2014 +0200 +++ b/src/share/classes/java/util/stream/Collectors.java Wed Jul 02 10:23:57 2014 +0200 @@ -1220,7 +1220,7 @@ * students to their grade point average: *
{@code
      *     Map studentToGPA
-     *         students.stream().collect(toMap(Functions.identity(),
+     *         students.stream().collect(toMap(Function.identity(),
      *                                         student -> computeGPA(student)));
      * }
* And the following produces a {@code Map} mapping a unique identifier to @@ -1228,7 +1228,7 @@ *
{@code
      *     Map studentIdToStudent
      *         students.stream().collect(toMap(Student::getId,
-     *                                         Functions.identity());
+     *                                         Function.identity());
      * }
* * @implNote @@ -1390,7 +1390,7 @@ * students to their grade point average: *
{@code
      *     Map studentToGPA
-     *         students.stream().collect(toMap(Functions.identity(),
+     *         students.stream().collect(toMap(Function.identity(),
      *                                         student -> computeGPA(student)));
      * }
* And the following produces a {@code Map} mapping a unique identifier to @@ -1398,7 +1398,7 @@ *
{@code
      *     Map studentIdToStudent
      *         students.stream().collect(toConcurrentMap(Student::getId,
-     *                                                   Functions.identity());
+     *                                                   Function.identity());
      * }
* *

This is a {@link Collector.Characteristics#CONCURRENT concurrent} and diff -r 4623ea09772f src/share/classes/java/util/stream/package-info.java --- a/src/share/classes/java/util/stream/package-info.java Wed Jul 02 08:41:59 2014 +0200 +++ b/src/share/classes/java/util/stream/package-info.java Wed Jul 02 10:23:57 2014 +0200 @@ -468,7 +468,7 @@ *

{@code
  *     int sumOfWeights = widgets.stream()
  *                               .reduce(0,
- *                                       (sum, b) -> sum + b.getWeight())
+ *                                       (sum, b) -> sum + b.getWeight(),
  *                                       Integer::sum);
  * }
* though the explicit map-reduce form is more readable and therefore should From Alan.Bateman at oracle.com Wed Jul 2 09:13:46 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 02 Jul 2014 10:13:46 +0100 Subject: RFR 8043328 and 8043327: errors in stream docs In-Reply-To: <6BD5BE4B-3FA1-406F-ADEB-99B0626B7BAC@oracle.com> References: <6BD5BE4B-3FA1-406F-ADEB-99B0626B7BAC@oracle.com> Message-ID: <53B3CD4A.3000001@oracle.com> On 02/07/2014 09:25, Paul Sandoz wrote: > Hi, > > Stuarts recent doc fix from Raoul reminded me about a few others: > > https://bugs.openjdk.java.net/browse/JDK-8043328 > Typo in documentation of package java.util.stream > > https://bugs.openjdk.java.net/browse/JDK-8043327 > Collectors.toMap studentToGPA example uses Functions.identity() > > See below for patch. > > This looks okay to me. -Alan From paul.sandoz at oracle.com Wed Jul 2 09:21:33 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 2 Jul 2014 11:21:33 +0200 Subject: Some small issues with the stream library In-Reply-To: References: Message-ID: <609AC738-B581-4020-8320-C03C88642429@oracle.com> Hi Kasper, Sorry for the *very* late reply, i forgot about this, but was reminded when trawling through some bugs. On Apr 17, 2014, at 3:13 PM, Kasper Nielsen wrote: > Hi, > > I'm trying to build a small test suite for for a custom stream > implementation I'm making. > And I found a couple of small issues with java.util.stream.Stream. Nothing > major but might be worth fixing > > 1) > There are couple of places where null checks are missing > > *Stream.close > Int/Double/LongStream.flatmap > Int/Double/LongStream.collect(x,y, 3rd) 3rd argument not being checked > > > 2) > These methods does throw NPE but they consume the stream before throwing. > I like to think of null parameter checks as side-effect free. > > Stream.forEach > Stream.forEachOrdered > Stream.sorted > Stream.toArray > I see you logged a bug (thanks for doing that): https://bugs.openjdk.java.net/browse/JDK-8044047 For 1) I presume you mean BaseStream.onClose rather than BaseStream.close? For 2) i am not sure it is worth enforcing, specification-wise. It's hard to envisage how a client would recover and reuse the stream in such scenarios, and even if it were the case it seems a very minor one. Currently the implementation is free to consolidate checks, even if there are side-effects before those checks occur. > 3) > LongStream.Average does not always work as intended with high long values > > Arrays.*asList*(Long.*MAX_VALUE* - 1000L, Long.*MAX_VALUE* - > 1000L).stream().mapToLong(e -> e).average().getAsDouble; return -1001.0 > > Same thing with SummaryStatistics > Right, we don't check for overflow of the sum. That is stated on the *SummaryStatistics class docs, but not in the Int/LongStream.sum/average method. I think we should add an @implNote to those methods. Paul. From lance.andersen at oracle.com Wed Jul 2 10:08:05 2014 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 2 Jul 2014 06:08:05 -0400 Subject: RFR(XS): JDK-8048989 small errors in Collectors examples In-Reply-To: <53B353B0.2010202@oracle.com> References: <53B353B0.2010202@oracle.com> Message-ID: <861A4C07-F2CC-4E43-9378-3F78604F4F30@oracle.com> +1 Best Lance On Jul 1, 2014, at 8:34 PM, Stuart Marks wrote: > Please review this small patch to fix some errors in the examples in the docs for java.util.stream.Collectors. Thanks to Raoul Urma for pointing these out. > > s'marks > > # HG changeset patch > # User smarks > # Date 1404256293 25200 > # Tue Jul 01 16:11:33 2014 -0700 > # Node ID 5b6a12d8a26e96052bc1c3ff787e8836fa4d64da > # Parent 71012e1b8534c481ba42a38e77fca0b90299628d > 8048989: small errors in Collectors examples > Reviewed-by: XXX > Contributed-by: raoul at urma.com > > diff -r 71012e1b8534 -r 5b6a12d8a26e src/share/classes/java/util/stream/Collectors.java > --- a/src/share/classes/java/util/stream/Collectors.java Mon Jun 16 17:52:21 2014 -0700 > +++ b/src/share/classes/java/util/stream/Collectors.java Tue Jul 01 16:11:33 2014 -0700 > @@ -729,7 +729,7 @@ > * person in each city: > *
{@code
>      *     Comparator byHeight = Comparator.comparing(Person::getHeight);
> -     *     Map tallestByCity
> +     *     Map> tallestByCity
>      *         = people.stream().collect(groupingBy(Person::getCity, reducing(BinaryOperator.maxBy(byHeight))));
>      * }
> * > @@ -784,7 +784,7 @@ > * Comparator byLength = Comparator.comparing(String::length); > * Map longestLastNameByCity > * = people.stream().collect(groupingBy(Person::getCity, > - * reducing(Person::getLastName, BinaryOperator.maxBy(byLength)))); > + * reducing("", Person::getLastName, BinaryOperator.maxBy(byLength)))); > * } > * > * @param the type of the input elements > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From lance.andersen at oracle.com Wed Jul 2 10:09:58 2014 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 2 Jul 2014 06:09:58 -0400 Subject: RFR 8043328 and 8043327: errors in stream docs In-Reply-To: <6BD5BE4B-3FA1-406F-ADEB-99B0626B7BAC@oracle.com> References: <6BD5BE4B-3FA1-406F-ADEB-99B0626B7BAC@oracle.com> Message-ID: <13F42981-7C86-427A-87CD-7F45714336D0@oracle.com> +1 On Jul 2, 2014, at 4:25 AM, Paul Sandoz wrote: > Hi, > > Stuarts recent doc fix from Raoul reminded me about a few others: > > https://bugs.openjdk.java.net/browse/JDK-8043328 > Typo in documentation of package java.util.stream > > https://bugs.openjdk.java.net/browse/JDK-8043327 > Collectors.toMap studentToGPA example uses Functions.identity() > > See below for patch. > > Stuart, are you planning to back port your doc fix to 8u-dev? If so we could do all three in one go. > > Paul. > > diff -r 4623ea09772f src/share/classes/java/util/stream/Collectors.java > --- a/src/share/classes/java/util/stream/Collectors.java Wed Jul 02 08:41:59 2014 +0200 > +++ b/src/share/classes/java/util/stream/Collectors.java Wed Jul 02 10:23:57 2014 +0200 > @@ -1220,7 +1220,7 @@ > * students to their grade point average: > *
{@code
>      *     Map studentToGPA
> -     *         students.stream().collect(toMap(Functions.identity(),
> +     *         students.stream().collect(toMap(Function.identity(),
>      *                                         student -> computeGPA(student)));
>      * }
> * And the following produces a {@code Map} mapping a unique identifier to > @@ -1228,7 +1228,7 @@ > *
{@code
>      *     Map studentIdToStudent
>      *         students.stream().collect(toMap(Student::getId,
> -     *                                         Functions.identity());
> +     *                                         Function.identity());
>      * }
> * > * @implNote > @@ -1390,7 +1390,7 @@ > * students to their grade point average: > *
{@code
>      *     Map studentToGPA
> -     *         students.stream().collect(toMap(Functions.identity(),
> +     *         students.stream().collect(toMap(Function.identity(),
>      *                                         student -> computeGPA(student)));
>      * }
> * And the following produces a {@code Map} mapping a unique identifier to > @@ -1398,7 +1398,7 @@ > *
{@code
>      *     Map studentIdToStudent
>      *         students.stream().collect(toConcurrentMap(Student::getId,
> -     *                                                   Functions.identity());
> +     *                                                   Function.identity());
>      * }
> * > *

This is a {@link Collector.Characteristics#CONCURRENT concurrent} and > diff -r 4623ea09772f src/share/classes/java/util/stream/package-info.java > --- a/src/share/classes/java/util/stream/package-info.java Wed Jul 02 08:41:59 2014 +0200 > +++ b/src/share/classes/java/util/stream/package-info.java Wed Jul 02 10:23:57 2014 +0200 > @@ -468,7 +468,7 @@ > *

{@code
>  *     int sumOfWeights = widgets.stream()
>  *                               .reduce(0,
> - *                                       (sum, b) -> sum + b.getWeight())
> + *                                       (sum, b) -> sum + b.getWeight(),
>  *                                       Integer::sum);
>  * }
> * though the explicit map-reduce form is more readable and therefore should Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From peter.levart at gmail.com Wed Jul 2 11:56:39 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 02 Jul 2014 13:56:39 +0200 Subject: RFR JDK-7186258: InetAddress$Cache should replace currentTimeMillis with nanoTime (+more) In-Reply-To: <20140701220621.00005e21.bernd-2014@eckenfels.net> References: <53B2FF8D.5040503@gmail.com> <20140701220621.00005e21.bernd-2014@eckenfels.net> Message-ID: <53B3F377.3090208@gmail.com> Hi, I updated the webrev with first two suggestions from Bernd (expireTime instead of createTime and cacheNanos + only use putIfAbsent instead of get followed by putIfAbsent): http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/webrev.02/ Thanks, Bernd. The id field in CachedAddresses is necessary for compareTo to never return 0 for two different instances (used as element in ConcurrentSkipListSet). For last two suggestions I'm not sure whether they are desired, so I'm currently leaving them as is. Regards, Peter On 07/01/2014 10:06 PM, Bernd Eckenfels wrote: > Looks good, like it, Peter. > > some nits: instead of adding createTime and cacheNanos, only have a > expireAfter? > > L782: is it better to use putIfAbsent unconditionally, instead of > get/putIfAbsent in NameServicdeAddr? > > L732: I am unsure about the id field, isnt it enough to have the > identity equality check for the replacement check and otherwise depend > on equals()? > > L1223: What about moving the cache exiry inside the if (useCache) > > BTW1: might be the wrong RFR, but considering your good performance > numbers for an active cache, would having 100ms or similiar default > negative cache time make sense without impacting (visible) the semantic. > > > > Gruss > Bernd > > > Am Tue, 01 Jul 2014 20:35:57 +0200 > schrieb Peter Levart : > >> Hi, >> >> I propose a patch for this issue: >> >> https://bugs.openjdk.java.net/browse/JDK-7186258 >> >> The motivation to re-design caching of InetAddress-es was not this >> issue though, but a desire to attack synchronization bottlenecks in >> methods like URL.equals and URL.hashCode which use host name to IP >> address mapping. I plan to tackle the synchronization in URL in a >> follow-up proposal, but I wanted to 1st iron-out the "leaves" of the >> call-tree. Here's the proposed patch: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/webrev.01/ >> >> sun.net.InetAddressCachePolicy: >> >> - two static methods (get() and getNegative()) were synchronized. >> Removed synchronization and made underlying fields volatile. >> - also added a normalization of negative policy in >> setNegativeIfNotSet(). The logic in InetAddress doesn't cope with >> negative values distinct from InetAddressCachePolicy.FOREVER (-1), so >> this was a straight bug. The setIfNotSet() doesn't need this >> normalization, because checkValue() throws exception if passed-in >> value < InetAddressCachePolicy.FOREVER. >> >> java.net.InetAddress: >> >> - complete redesign of caching. Instead of distinct Positive/Negative >> caches, there's only one cache - a ConcurrentHashMap. The value in >> the map knows if it contains positive or negative answer. >> - the design of this cache is similar but much simpler than >> java.lang.reflect.WeakCache, since it doesn't have to deal with >> WeakReferences and keys are simpler (just strings - hostnames). >> Similarity is in how concurrent requests for the same key (hostname) >> are synchronized when the entry is not cached yet, but still avoid >> synchronization when entry is cached. This preserves the behaviour of >> original InetAddress caching code but simplifies it greatly (100+ >> lines removed). >> - I tried to preserve the interaction between >> InetAddress.getLocalHost() and InetAddress.getByName(). The >> getLocalHost() caches the local host address for 5 seconds privately. >> When it expires it performs new name service look-up and "refreshes" >> the entry in the InetAddress.getByName() cache although it has not >> expired yet. I think this is meant to prevent surprises when >> getLocalHost() returns newer address than getByName() which is called >> after that. >> - I also fixed the JDK-7186258 as a by-product (but don't know yet >> how to write a test for this issue - any ideas?) >> >> I created a JMH benchmark that tests the following methods: >> >> - InetAddress.getLocalHost() >> - InetAddress.getByName() (with positive and negative answer) >> >> Here're the results of running on my 4-core (8-threads) i7/Linux: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/InetAddress.Cache_bench_results.01.pdf >> >> >> The getByNameNegative() test does not show much improvement in >> patched vs. original code. That's because by default the policy is to >> NOT cache negative answers. Requests for same hostname to the >> NameService(s) are synchronized. If >> "networkaddress.cache.negative.ttl" system property is set to some >> positive value, results are similar to those of getByNamePositive() >> test (the default policy for positive caching is 30 seconds). >> >> I ran the jtreg tests in test/java/net and have the same score as >> with original unpatched code. I have 3 failing tests from original >> and patched runs: >> >> JT Harness : Tests that failed >> java/net/MulticastSocket/Promiscuous.java: Test for interference when >> two sockets are bound to the same port but joined to different >> multicast groups >> java/net/MulticastSocket/SetLoopbackMode.java: Test >> MulticastSocket.setLoopbackMode >> java/net/MulticastSocket/Test.java: IPv4 and IPv6 multicasting broken >> on Linux >> >> And 1 test that had error trying to be run: >> >> JT Harness : Tests that had errors >> java/net/URLPermission/nstest/lookup.sh: >> >> Because of: >> >> test result: Error. Can't find source file: jdk/testlibrary/*.java in >> directory-list: >> /home/peter/work/hg/jdk9-dev/jdk/test/java/net/URLPermission/nstest >> /home/peter/work/hg/jdk9-dev/jdk/test/lib/testlibrary >> >> All other 258 java/net tests pass. >> >> >> >> So what do you think? >> >> >> Regards, Peter >> >> From paul.sandoz at oracle.com Wed Jul 2 12:01:40 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 2 Jul 2014 14:01:40 +0200 Subject: RFR 8044047: Missing null pointer checks for streams Message-ID: Hi, Please review this fix for some missing null-checks in stream code: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8044047-null-checks/webrev/ https://bugs.openjdk.java.net/browse/JDK-8044047 I also boosted some of the primitive summary statistic tests. Unfortunately the refactoring of some test names resulted in disassociation between old and new (not quite sure why in this case), so diffs for renamed tests are below. Paul. jdk/test/java/util/stream/test/org/openjdk/tests/java/util/stream/ExplodeOpTest.java -> jdk/test/java/util/stream/test/org/openjdk/tests/java/util/stream/FlatMapOpTest.java 2c2 < * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights reserved. --- > * Copyright (c) 2012, 2014, Oracle and/or its affiliates. All rights reserved. 33a34 > import static java.util.stream.ThowableHelper.checkNPE; 36c37 < * ExplodeOpTest --- > * FlatMapOpTest 41c42,49 < public class ExplodeOpTest extends OpTestCase { --- > public class FlatMapOpTest extends OpTestCase { > > public void testNullMapper() { > checkNPE(() -> Stream.of(1).flatMap(null)); > checkNPE(() -> IntStream.of(1).flatMap(null)); > checkNPE(() -> LongStream.of(1).flatMap(null)); > checkNPE(() -> DoubleStream.of(1).flatMap(null)); > } jdk/test/java/util/stream/test/org/openjdk/tests/java/util/stream/SummaryStatisticsTest.java -> jdk/test/java/util/stream/test/org/openjdk/tests/java/util/stream/CollectAndSummaryStatisticsTest.java 2c2 < * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights reserved. --- > * Copyright (c) 2012, 2014, Oracle and/or its affiliates. All rights reserved. 24a25,26 > import org.testng.annotations.Test; > 30a33,35 > import java.util.stream.DoubleStream; > import java.util.stream.IntStream; > import java.util.stream.LongStream; 33,34d37 < import org.testng.annotations.Test; < 35a39 > import static java.util.stream.ThowableHelper.checkNPE; 38c42 < * TestSummaryStatistics --- > * CollectAndSummaryStatisticsTest 43c47,84 < public class SummaryStatisticsTest extends OpTestCase { --- > public class CollectAndSummaryStatisticsTest extends OpTestCase { > > public void testIntCollectNull() { > checkNPE(() -> IntStream.of(1).collect(null, > IntSummaryStatistics::accept, > IntSummaryStatistics::combine)); > checkNPE(() -> IntStream.of(1).collect(IntSummaryStatistics::new, > null, > IntSummaryStatistics::combine)); > checkNPE(() -> IntStream.of(1).collect(IntSummaryStatistics::new, > IntSummaryStatistics::accept, > null)); > } > > public void testLongCollectNull() { > checkNPE(() -> LongStream.of(1).collect(null, > LongSummaryStatistics::accept, > LongSummaryStatistics::combine)); > checkNPE(() -> LongStream.of(1).collect(LongSummaryStatistics::new, > null, > LongSummaryStatistics::combine)); > checkNPE(() -> LongStream.of(1).collect(LongSummaryStatistics::new, > LongSummaryStatistics::accept, > null)); > } > > public void testDoubleCollectNull() { > checkNPE(() -> DoubleStream.of(1).collect(null, > DoubleSummaryStatistics::accept, > DoubleSummaryStatistics::combine)); > checkNPE(() -> DoubleStream.of(1).collect(DoubleSummaryStatistics::new, > null, > DoubleSummaryStatistics::combine)); > checkNPE(() -> DoubleStream.of(1).collect(DoubleSummaryStatistics::new, > DoubleSummaryStatistics::accept, > null)); > } > 47a89,91 > instances.add(countTo(1000).stream().mapToInt(i -> i).collect(IntSummaryStatistics::new, > IntSummaryStatistics::accept, > IntSummaryStatistics::combine)); 49a94,96 > instances.add(countTo(1000).parallelStream().mapToInt(i -> i).collect(IntSummaryStatistics::new, > IntSummaryStatistics::accept, > IntSummaryStatistics::combine)); 53a101 > assertEquals(stats.getAverage(), (double) stats.getSum() / stats.getCount()); 58a107 > 62a112,114 > instances.add(countTo(1000).stream().mapToLong(i -> i).collect(LongSummaryStatistics::new, > LongSummaryStatistics::accept, > LongSummaryStatistics::combine)); 64a117,119 > instances.add(countTo(1000).parallelStream().mapToLong(i -> i).collect(LongSummaryStatistics::new, > LongSummaryStatistics::accept, > LongSummaryStatistics::combine)); 68a124 > assertEquals(stats.getAverage(), (double) stats.getSum() / stats.getCount()); 77a134,136 > instances.add(countTo(1000).stream().mapToDouble(i -> i).collect(DoubleSummaryStatistics::new, > DoubleSummaryStatistics::accept, > DoubleSummaryStatistics::combine)); 79a139,141 > instances.add(countTo(1000).parallelStream().mapToDouble(i -> i).collect(DoubleSummaryStatistics::new, > DoubleSummaryStatistics::accept, > DoubleSummaryStatistics::combine)); 83a146 > assertEquals(stats.getAverage(), stats.getSum() / stats.getCount()); From peter.levart at gmail.com Wed Jul 2 12:22:29 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 02 Jul 2014 14:22:29 +0200 Subject: RFR 8047737 Move array component mirror to instance of java/lang/Class In-Reply-To: <53B3A623.1050804@oracle.com> References: <53ADC4D4.4030403@oracle.com> <53B0FBEF.5030607@oracle.com> <53B15B50.6070405@oracle.com> <53B205C7.8070804@oracle.com> <53B3A623.1050804@oracle.com> Message-ID: <53B3F985.9030109@gmail.com> On 07/02/2014 08:26 AM, Mandy Chung wrote: > > On 6/30/2014 9:51 PM, Christian Thalinger wrote: >> On Jun 30, 2014, at 5:50 PM, Coleen Phillimore >> wrote: >> >> >> On 6/30/14, 3:50 PM, Christian Thalinger wrote: >>>> private Class(ClassLoader loader) { >>>> // Initialize final field for classLoader. The >>>> initialization value of non-null >>>> // prevents future JIT optimizations from assuming this >>>> final field is null. >>>> classLoader = loader; >>>> + componentType = null; >>>> } >>>> >>>> Are we worried about the same optimization? >>> Hi, I've decided to make them consistent and add another parameter >>> to the Class constructor. >>> >>> http://cr.openjdk.java.net/~coleenp/8047737_jdk_2/ > > The jdk change looks okay while I am beginning to think whether we > really want to keep expanding this constructor to deal with this > future JIT optimization (you will be moving more fields out from the > VM to java.lang.Class). > > There are places in JDK initializing the final fields to null while > the final field value is overridden via native/VM - e.g. System.in, > System.out, etc. I would prefer reverting the classLoader constructor > change to expanding the constructor for any new field being added. > Handle it (and other places in JDK) when such JIT optimization comes. > > Mandy > What about: private Class() { classLoader = none(); componentType = none(); ... } private T none() { throw new Error(); } I think this should be resistant to future optimizations. Regards, Peter From peter.levart at gmail.com Wed Jul 2 12:38:23 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 02 Jul 2014 14:38:23 +0200 Subject: RFR 8047737 Move array component mirror to instance of java/lang/Class In-Reply-To: <53B3F985.9030109@gmail.com> References: <53ADC4D4.4030403@oracle.com> <53B0FBEF.5030607@oracle.com> <53B15B50.6070405@oracle.com> <53B205C7.8070804@oracle.com> <53B3A623.1050804@oracle.com> <53B3F985.9030109@gmail.com> Message-ID: <53B3FD3F.30901@gmail.com> On 07/02/2014 02:22 PM, Peter Levart wrote: > On 07/02/2014 08:26 AM, Mandy Chung wrote: >> >> On 6/30/2014 9:51 PM, Christian Thalinger wrote: >>> On Jun 30, 2014, at 5:50 PM, Coleen Phillimore >>> wrote: >>> >>> >>> On 6/30/14, 3:50 PM, Christian Thalinger wrote: >>>>> private Class(ClassLoader loader) { >>>>> // Initialize final field for classLoader. The >>>>> initialization value of non-null >>>>> // prevents future JIT optimizations from assuming this >>>>> final field is null. >>>>> classLoader = loader; >>>>> + componentType = null; >>>>> } >>>>> >>>>> Are we worried about the same optimization? >>>> Hi, I've decided to make them consistent and add another parameter >>>> to the Class constructor. >>>> >>>> http://cr.openjdk.java.net/~coleenp/8047737_jdk_2/ >> >> The jdk change looks okay while I am beginning to think whether we >> really want to keep expanding this constructor to deal with this >> future JIT optimization (you will be moving more fields out from the >> VM to java.lang.Class). >> >> There are places in JDK initializing the final fields to null while >> the final field value is overridden via native/VM - e.g. System.in, >> System.out, etc. I would prefer reverting the classLoader >> constructor change to expanding the constructor for any new field >> being added. Handle it (and other places in JDK) when such JIT >> optimization comes. >> >> Mandy >> > > What about: > > > private Class() { > classLoader = none(); > componentType = none(); > ... > } > > private T none() { throw new Error(); } > > > I think this should be resistant to future optimizations. And you could even remove the special-casing in AccessibleObject.setAccessible0() then. Regards, Peter > > Regards, Peter > From peter.levart at gmail.com Wed Jul 2 12:41:22 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 02 Jul 2014 14:41:22 +0200 Subject: RFR 8047737 Move array component mirror to instance of java/lang/Class In-Reply-To: <53B3FD3F.30901@gmail.com> References: <53ADC4D4.4030403@oracle.com> <53B0FBEF.5030607@oracle.com> <53B15B50.6070405@oracle.com> <53B205C7.8070804@oracle.com> <53B3A623.1050804@oracle.com> <53B3F985.9030109@gmail.com> <53B3FD3F.30901@gmail.com> Message-ID: <53B3FDF2.9060708@gmail.com> On 07/02/2014 02:38 PM, Peter Levart wrote: > On 07/02/2014 02:22 PM, Peter Levart wrote: >> On 07/02/2014 08:26 AM, Mandy Chung wrote: >>> >>> On 6/30/2014 9:51 PM, Christian Thalinger wrote: >>>> On Jun 30, 2014, at 5:50 PM, Coleen Phillimore >>>> wrote: >>>> >>>> >>>> On 6/30/14, 3:50 PM, Christian Thalinger wrote: >>>>>> private Class(ClassLoader loader) { >>>>>> // Initialize final field for classLoader. The >>>>>> initialization value of non-null >>>>>> // prevents future JIT optimizations from assuming this >>>>>> final field is null. >>>>>> classLoader = loader; >>>>>> + componentType = null; >>>>>> } >>>>>> >>>>>> Are we worried about the same optimization? >>>>> Hi, I've decided to make them consistent and add another >>>>> parameter to the Class constructor. >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/8047737_jdk_2/ >>> >>> The jdk change looks okay while I am beginning to think whether we >>> really want to keep expanding this constructor to deal with this >>> future JIT optimization (you will be moving more fields out from the >>> VM to java.lang.Class). >>> >>> There are places in JDK initializing the final fields to null while >>> the final field value is overridden via native/VM - e.g. System.in, >>> System.out, etc. I would prefer reverting the classLoader >>> constructor change to expanding the constructor for any new field >>> being added. Handle it (and other places in JDK) when such JIT >>> optimization comes. >>> >>> Mandy >>> >> >> What about: >> >> >> private Class() { >> classLoader = none(); >> componentType = none(); >> ... >> } >> >> private T none() { throw new Error(); } >> >> >> I think this should be resistant to future optimizations. > > And you could even remove the special-casing in > AccessibleObject.setAccessible0() then. > > Regards, Peter I take it back. Such java.lang.Class instance would still be constructed and GC will see it. > >> >> Regards, Peter >> > From coleen.phillimore at oracle.com Wed Jul 2 13:16:29 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 02 Jul 2014 09:16:29 -0400 Subject: RFR 8047737 Move array component mirror to instance of java/lang/Class In-Reply-To: <53B3FDF2.9060708@gmail.com> References: <53ADC4D4.4030403@oracle.com> <53B0FBEF.5030607@oracle.com> <53B15B50.6070405@oracle.com> <53B205C7.8070804@oracle.com> <53B3A623.1050804@oracle.com> <53B3F985.9030109@gmail.com> <53B3FD3F.30901@gmail.com> <53B3FDF2.9060708@gmail.com> Message-ID: <53B4062D.5080203@oracle.com> On 7/2/14, 8:41 AM, Peter Levart wrote: > On 07/02/2014 02:38 PM, Peter Levart wrote: >> On 07/02/2014 02:22 PM, Peter Levart wrote: >>> On 07/02/2014 08:26 AM, Mandy Chung wrote: >>>> >>>> On 6/30/2014 9:51 PM, Christian Thalinger wrote: >>>>> On Jun 30, 2014, at 5:50 PM, Coleen Phillimore >>>>> wrote: >>>>> >>>>> >>>>> On 6/30/14, 3:50 PM, Christian Thalinger wrote: >>>>>>> private Class(ClassLoader loader) { >>>>>>> // Initialize final field for classLoader. The >>>>>>> initialization value of non-null >>>>>>> // prevents future JIT optimizations from assuming >>>>>>> this final field is null. >>>>>>> classLoader = loader; >>>>>>> + componentType = null; >>>>>>> } >>>>>>> >>>>>>> Are we worried about the same optimization? >>>>>> Hi, I've decided to make them consistent and add another >>>>>> parameter to the Class constructor. >>>>>> >>>>>> http://cr.openjdk.java.net/~coleenp/8047737_jdk_2/ >>>> >>>> The jdk change looks okay while I am beginning to think whether we >>>> really want to keep expanding this constructor to deal with this >>>> future JIT optimization (you will be moving more fields out from >>>> the VM to java.lang.Class). >>>> >>>> There are places in JDK initializing the final fields to null while >>>> the final field value is overridden via native/VM - e.g. System.in, >>>> System.out, etc. I would prefer reverting the classLoader >>>> constructor change to expanding the constructor for any new field >>>> being added. Handle it (and other places in JDK) when such JIT >>>> optimization comes. >>>> >>>> Mandy >>>> >>> >>> What about: >>> >>> >>> private Class() { >>> classLoader = none(); >>> componentType = none(); >>> ... >>> } >>> >>> private T none() { throw new Error(); } >>> >>> >>> I think this should be resistant to future optimizations. >> >> And you could even remove the special-casing in >> AccessibleObject.setAccessible0() then. >> >> Regards, Peter > > I take it back. Such java.lang.Class instance would still be > constructed and GC will see it. The setAccessible0 check is still needed because we do other things to the mirror inside the jvm. Coleen > >> >>> >>> Regards, Peter >>> >> > From claes.redestad at oracle.com Wed Jul 2 14:39:51 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 02 Jul 2014 16:39:51 +0200 Subject: RFR JDK-7186258: InetAddress$Cache should replace currentTimeMillis with nanoTime (+more) In-Reply-To: <53B3F377.3090208@gmail.com> References: <53B2FF8D.5040503@gmail.com> <20140701220621.00005e21.bernd-2014@eckenfels.net> <53B3F377.3090208@gmail.com> Message-ID: <53B419B7.1030600@oracle.com> Hi Peter, perhaps the synchronized(this)-block in NameServiceAddresses::get() can be replaced with a ReentrantLock? Applying this on top of your patch, I seem to improve scores on your benchmark for -t 4 by ~33% on my machine: --- a/src/share/classes/java/net/InetAddress.java Wed Jul 02 14:47:40 2014 +0200 +++ b/src/share/classes/java/net/InetAddress.java Wed Jul 02 14:57:24 2014 +0200 @@ -42,6 +42,7 @@ import java.util.concurrent.ConcurrentMap; import java.util.concurrent.ConcurrentSkipListSet; import java.util.concurrent.atomic.AtomicLong; +import java.util.concurrent.locks.ReentrantLock; import sun.security.action.*; import sun.net.InetAddressCachePolicy; @@ -763,6 +764,7 @@ private static final class NameServiceAddresses implements Addresses { private final String host; private final InetAddress reqAddr; + private final ReentrantLock lock = new ReentrantLock(); NameServiceAddresses(String host, InetAddress reqAddr) { this.host = host; @@ -774,7 +776,8 @@ Addresses addresses; // only one thread is doing lookup to name service // for particular host at any time. - synchronized (this) { + lock.lock(); + try { // re-check that we are still us + re-install us if slot empty addresses = cache.putIfAbsent(host, this); if (addresses == null) { @@ -822,10 +825,13 @@ return inetAddresses; } // else addresses != this + + // delegate to different addresses when we are already replaced + // but outside of synchronized block to avoid any chance of dead-locking + return addresses.get(); + } finally { + lock.unlock(); } - // delegate to different addresses when we are already replaced - // but outside of synchronized block to avoid any chance of dead-locking - return addresses.get(); } } nit: line 1258: getAddressesFromNameService made package private but not used outside of InetAddress? Generally I think this looks good, but I'm not a reviewer. :) /Claes On 07/02/2014 01:56 PM, Peter Levart wrote: > Hi, > > I updated the webrev with first two suggestions from Bernd (expireTime > instead of createTime and cacheNanos + only use putIfAbsent instead of > get followed by putIfAbsent): > > http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/webrev.02/ > > Thanks, Bernd. > > The id field in CachedAddresses is necessary for compareTo to never > return 0 for two different instances (used as element in > ConcurrentSkipListSet). > > For last two suggestions I'm not sure whether they are desired, so I'm > currently leaving them as is. > > > Regards, Peter > > On 07/01/2014 10:06 PM, Bernd Eckenfels wrote: >> Looks good, like it, Peter. >> >> some nits: instead of adding createTime and cacheNanos, only have a >> expireAfter? >> >> L782: is it better to use putIfAbsent unconditionally, instead of >> get/putIfAbsent in NameServicdeAddr? >> >> L732: I am unsure about the id field, isnt it enough to have the >> identity equality check for the replacement check and otherwise depend >> on equals()? >> >> L1223: What about moving the cache exiry inside the if (useCache) >> >> BTW1: might be the wrong RFR, but considering your good performance >> numbers for an active cache, would having 100ms or similiar default >> negative cache time make sense without impacting (visible) the semantic. >> >> >> >> Gruss >> Bernd >> >> >> Am Tue, 01 Jul 2014 20:35:57 +0200 >> schrieb Peter Levart : >> >>> Hi, >>> >>> I propose a patch for this issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-7186258 >>> >>> The motivation to re-design caching of InetAddress-es was not this >>> issue though, but a desire to attack synchronization bottlenecks in >>> methods like URL.equals and URL.hashCode which use host name to IP >>> address mapping. I plan to tackle the synchronization in URL in a >>> follow-up proposal, but I wanted to 1st iron-out the "leaves" of the >>> call-tree. Here's the proposed patch: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/webrev.01/ >>> >>> >>> sun.net.InetAddressCachePolicy: >>> >>> - two static methods (get() and getNegative()) were synchronized. >>> Removed synchronization and made underlying fields volatile. >>> - also added a normalization of negative policy in >>> setNegativeIfNotSet(). The logic in InetAddress doesn't cope with >>> negative values distinct from InetAddressCachePolicy.FOREVER (-1), so >>> this was a straight bug. The setIfNotSet() doesn't need this >>> normalization, because checkValue() throws exception if passed-in >>> value < InetAddressCachePolicy.FOREVER. >>> >>> java.net.InetAddress: >>> >>> - complete redesign of caching. Instead of distinct Positive/Negative >>> caches, there's only one cache - a ConcurrentHashMap. The value in >>> the map knows if it contains positive or negative answer. >>> - the design of this cache is similar but much simpler than >>> java.lang.reflect.WeakCache, since it doesn't have to deal with >>> WeakReferences and keys are simpler (just strings - hostnames). >>> Similarity is in how concurrent requests for the same key (hostname) >>> are synchronized when the entry is not cached yet, but still avoid >>> synchronization when entry is cached. This preserves the behaviour of >>> original InetAddress caching code but simplifies it greatly (100+ >>> lines removed). >>> - I tried to preserve the interaction between >>> InetAddress.getLocalHost() and InetAddress.getByName(). The >>> getLocalHost() caches the local host address for 5 seconds privately. >>> When it expires it performs new name service look-up and "refreshes" >>> the entry in the InetAddress.getByName() cache although it has not >>> expired yet. I think this is meant to prevent surprises when >>> getLocalHost() returns newer address than getByName() which is called >>> after that. >>> - I also fixed the JDK-7186258 as a by-product (but don't know yet >>> how to write a test for this issue - any ideas?) >>> >>> I created a JMH benchmark that tests the following methods: >>> >>> - InetAddress.getLocalHost() >>> - InetAddress.getByName() (with positive and negative answer) >>> >>> Here're the results of running on my 4-core (8-threads) i7/Linux: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/InetAddress.Cache_bench_results.01.pdf >>> >>> >>> >>> The getByNameNegative() test does not show much improvement in >>> patched vs. original code. That's because by default the policy is to >>> NOT cache negative answers. Requests for same hostname to the >>> NameService(s) are synchronized. If >>> "networkaddress.cache.negative.ttl" system property is set to some >>> positive value, results are similar to those of getByNamePositive() >>> test (the default policy for positive caching is 30 seconds). >>> >>> I ran the jtreg tests in test/java/net and have the same score as >>> with original unpatched code. I have 3 failing tests from original >>> and patched runs: >>> >>> JT Harness : Tests that failed >>> java/net/MulticastSocket/Promiscuous.java: Test for interference when >>> two sockets are bound to the same port but joined to different >>> multicast groups >>> java/net/MulticastSocket/SetLoopbackMode.java: Test >>> MulticastSocket.setLoopbackMode >>> java/net/MulticastSocket/Test.java: IPv4 and IPv6 multicasting broken >>> on Linux >>> >>> And 1 test that had error trying to be run: >>> >>> JT Harness : Tests that had errors >>> java/net/URLPermission/nstest/lookup.sh: >>> >>> Because of: >>> >>> test result: Error. Can't find source file: jdk/testlibrary/*.java in >>> directory-list: >>> /home/peter/work/hg/jdk9-dev/jdk/test/java/net/URLPermission/nstest >>> /home/peter/work/hg/jdk9-dev/jdk/test/lib/testlibrary >>> >>> All other 258 java/net tests pass. >>> >>> >>> >>> So what do you think? >>> >>> >>> Regards, Peter >>> >>> > From Alan.Bateman at oracle.com Wed Jul 2 14:44:41 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 02 Jul 2014 15:44:41 +0100 Subject: RFR 8048840: File.createTempFile has uninformative failure message In-Reply-To: References: <53B272A3.2050508@oracle.com> Message-ID: <53B41AD9.9000807@oracle.com> On 02/07/2014 01:02, Jeremy Manson wrote: > Here you go (far too lazy to generate a webrev for this. :) ) > > diff --git a/src/share/classes/java/io/File.java > b/src/share/classes/java/io/File.java > --- a/src/share/classes/java/io/File.java > +++ b/src/share/classes/java/io/File.java > @@ -1997,8 +1997,10 @@ > File directory) > throws IOException > { > - if (prefix.length() < 3) > - throw new IllegalArgumentException("Prefix string too > short"); > + if (prefix.length() < 3) { > + throw new IllegalArgumentException("Prefix string \"" + > prefix + > + "\" too short: length must be at least 3"); > + } > if (suffix == null) > suffix = ".tmp"; > This looks okay and I see Martin is going to sponsor this. -Alan From peter.levart at gmail.com Wed Jul 2 15:30:30 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 02 Jul 2014 17:30:30 +0200 Subject: RFR JDK-7186258: InetAddress$Cache should replace currentTimeMillis with nanoTime (+more) In-Reply-To: <53B419B7.1030600@oracle.com> References: <53B2FF8D.5040503@gmail.com> <20140701220621.00005e21.bernd-2014@eckenfels.net> <53B3F377.3090208@gmail.com> <53B419B7.1030600@oracle.com> Message-ID: <53B42596.3080900@gmail.com> Hi Claes, Thank you for looking into this patch. On 07/02/2014 04:39 PM, Claes Redestad wrote: > Hi Peter, > > perhaps the synchronized(this)-block in NameServiceAddresses::get() > can be replaced with a ReentrantLock? Applying this on top of your > patch, I seem to improve scores on your benchmark for -t 4 by ~33% on > my machine: Which test? I would be surprised that this change has any impact but on "getByNameNegative" test which exhibits this lock at each iteration (since negative caching is disabled by default). I'll check this myself too. > > --- a/src/share/classes/java/net/InetAddress.java Wed Jul 02 > 14:47:40 2014 +0200 > +++ b/src/share/classes/java/net/InetAddress.java Wed Jul 02 > 14:57:24 2014 +0200 > @@ -42,6 +42,7 @@ > import java.util.concurrent.ConcurrentMap; > import java.util.concurrent.ConcurrentSkipListSet; > import java.util.concurrent.atomic.AtomicLong; > +import java.util.concurrent.locks.ReentrantLock; > > import sun.security.action.*; > import sun.net.InetAddressCachePolicy; > @@ -763,6 +764,7 @@ > private static final class NameServiceAddresses implements > Addresses { > private final String host; > private final InetAddress reqAddr; > + private final ReentrantLock lock = new ReentrantLock(); > > NameServiceAddresses(String host, InetAddress reqAddr) { > this.host = host; > @@ -774,7 +776,8 @@ > Addresses addresses; > // only one thread is doing lookup to name service > // for particular host at any time. > - synchronized (this) { > + lock.lock(); > + try { > // re-check that we are still us + re-install us if > slot empty > addresses = cache.putIfAbsent(host, this); > if (addresses == null) { > @@ -822,10 +825,13 @@ > return inetAddresses; > } > // else addresses != this > + > + // delegate to different addresses when we are > already replaced > + // but outside of synchronized block to avoid any > chance of dead-locking > + return addresses.get(); > + } finally { > + lock.unlock(); > } > - // delegate to different addresses when we are already > replaced > - // but outside of synchronized block to avoid any chance > of dead-locking > - return addresses.get(); > } > } > > nit: line 1258: getAddressesFromNameService made package private but > not used outside of InetAddress? Good catch. I seem to have inadvertently deleted the "private" keyword. > > Generally I think this looks good, but I'm not a reviewer. :) > > /Claes Regards, Peter > > On 07/02/2014 01:56 PM, Peter Levart wrote: >> Hi, >> >> I updated the webrev with first two suggestions from Bernd >> (expireTime instead of createTime and cacheNanos + only use >> putIfAbsent instead of get followed by putIfAbsent): >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/webrev.02/ >> >> >> Thanks, Bernd. >> >> The id field in CachedAddresses is necessary for compareTo to never >> return 0 for two different instances (used as element in >> ConcurrentSkipListSet). >> >> For last two suggestions I'm not sure whether they are desired, so >> I'm currently leaving them as is. >> >> >> Regards, Peter >> >> On 07/01/2014 10:06 PM, Bernd Eckenfels wrote: >>> Looks good, like it, Peter. >>> >>> some nits: instead of adding createTime and cacheNanos, only have a >>> expireAfter? >>> >>> L782: is it better to use putIfAbsent unconditionally, instead of >>> get/putIfAbsent in NameServicdeAddr? >>> >>> L732: I am unsure about the id field, isnt it enough to have the >>> identity equality check for the replacement check and otherwise depend >>> on equals()? >>> >>> L1223: What about moving the cache exiry inside the if (useCache) >>> >>> BTW1: might be the wrong RFR, but considering your good performance >>> numbers for an active cache, would having 100ms or similiar default >>> negative cache time make sense without impacting (visible) the >>> semantic. >>> >>> >>> >>> Gruss >>> Bernd >>> >>> >>> Am Tue, 01 Jul 2014 20:35:57 +0200 >>> schrieb Peter Levart : >>> >>>> Hi, >>>> >>>> I propose a patch for this issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-7186258 >>>> >>>> The motivation to re-design caching of InetAddress-es was not this >>>> issue though, but a desire to attack synchronization bottlenecks in >>>> methods like URL.equals and URL.hashCode which use host name to IP >>>> address mapping. I plan to tackle the synchronization in URL in a >>>> follow-up proposal, but I wanted to 1st iron-out the "leaves" of the >>>> call-tree. Here's the proposed patch: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/webrev.01/ >>>> >>>> >>>> sun.net.InetAddressCachePolicy: >>>> >>>> - two static methods (get() and getNegative()) were synchronized. >>>> Removed synchronization and made underlying fields volatile. >>>> - also added a normalization of negative policy in >>>> setNegativeIfNotSet(). The logic in InetAddress doesn't cope with >>>> negative values distinct from InetAddressCachePolicy.FOREVER (-1), so >>>> this was a straight bug. The setIfNotSet() doesn't need this >>>> normalization, because checkValue() throws exception if passed-in >>>> value < InetAddressCachePolicy.FOREVER. >>>> >>>> java.net.InetAddress: >>>> >>>> - complete redesign of caching. Instead of distinct Positive/Negative >>>> caches, there's only one cache - a ConcurrentHashMap. The value in >>>> the map knows if it contains positive or negative answer. >>>> - the design of this cache is similar but much simpler than >>>> java.lang.reflect.WeakCache, since it doesn't have to deal with >>>> WeakReferences and keys are simpler (just strings - hostnames). >>>> Similarity is in how concurrent requests for the same key (hostname) >>>> are synchronized when the entry is not cached yet, but still avoid >>>> synchronization when entry is cached. This preserves the behaviour of >>>> original InetAddress caching code but simplifies it greatly (100+ >>>> lines removed). >>>> - I tried to preserve the interaction between >>>> InetAddress.getLocalHost() and InetAddress.getByName(). The >>>> getLocalHost() caches the local host address for 5 seconds privately. >>>> When it expires it performs new name service look-up and "refreshes" >>>> the entry in the InetAddress.getByName() cache although it has not >>>> expired yet. I think this is meant to prevent surprises when >>>> getLocalHost() returns newer address than getByName() which is called >>>> after that. >>>> - I also fixed the JDK-7186258 as a by-product (but don't know yet >>>> how to write a test for this issue - any ideas?) >>>> >>>> I created a JMH benchmark that tests the following methods: >>>> >>>> - InetAddress.getLocalHost() >>>> - InetAddress.getByName() (with positive and negative answer) >>>> >>>> Here're the results of running on my 4-core (8-threads) i7/Linux: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/InetAddress.Cache_bench_results.01.pdf >>>> >>>> >>>> >>>> The getByNameNegative() test does not show much improvement in >>>> patched vs. original code. That's because by default the policy is to >>>> NOT cache negative answers. Requests for same hostname to the >>>> NameService(s) are synchronized. If >>>> "networkaddress.cache.negative.ttl" system property is set to some >>>> positive value, results are similar to those of getByNamePositive() >>>> test (the default policy for positive caching is 30 seconds). >>>> >>>> I ran the jtreg tests in test/java/net and have the same score as >>>> with original unpatched code. I have 3 failing tests from original >>>> and patched runs: >>>> >>>> JT Harness : Tests that failed >>>> java/net/MulticastSocket/Promiscuous.java: Test for interference when >>>> two sockets are bound to the same port but joined to different >>>> multicast groups >>>> java/net/MulticastSocket/SetLoopbackMode.java: Test >>>> MulticastSocket.setLoopbackMode >>>> java/net/MulticastSocket/Test.java: IPv4 and IPv6 multicasting broken >>>> on Linux >>>> >>>> And 1 test that had error trying to be run: >>>> >>>> JT Harness : Tests that had errors >>>> java/net/URLPermission/nstest/lookup.sh: >>>> >>>> Because of: >>>> >>>> test result: Error. Can't find source file: jdk/testlibrary/*.java in >>>> directory-list: >>>> /home/peter/work/hg/jdk9-dev/jdk/test/java/net/URLPermission/nstest >>>> /home/peter/work/hg/jdk9-dev/jdk/test/lib/testlibrary >>>> >>>> All other 258 java/net tests pass. >>>> >>>> >>>> >>>> So what do you think? >>>> >>>> >>>> Regards, Peter >>>> >>>> >> > From claes.redestad at oracle.com Wed Jul 2 15:57:54 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 02 Jul 2014 17:57:54 +0200 Subject: RFR JDK-7186258: InetAddress$Cache should replace currentTimeMillis with nanoTime (+more) In-Reply-To: <53B42596.3080900@gmail.com> References: <53B2FF8D.5040503@gmail.com> <20140701220621.00005e21.bernd-2014@eckenfels.net> <53B3F377.3090208@gmail.com> <53B419B7.1030600@oracle.com> <53B42596.3080900@gmail.com> Message-ID: <53B42C02.4000500@oracle.com> On 07/02/2014 05:30 PM, Peter Levart wrote: > Hi Claes, > > Thank you for looking into this patch. > > On 07/02/2014 04:39 PM, Claes Redestad wrote: >> Hi Peter, >> >> perhaps the synchronized(this)-block in NameServiceAddresses::get() >> can be replaced with a ReentrantLock? Applying this on top of your >> patch, I seem to improve scores on your benchmark for -t 4 by ~33% on >> my machine: > > Which test? I would be surprised that this change has any impact but > on "getByNameNegative" test which exhibits this lock at each iteration > (since negative caching is disabled by default). I'll check this > myself too. Feel free to ignore this. I don't seem to be able to benchmark properly today and was jumping to conclusions: rerunning with just a bit more rigor did not reproduce the improvement. In fact it doesn't even seem to benefit getByNameNegative. Perhaps you'll get different results. Thanks. /Claes > >> >> --- a/src/share/classes/java/net/InetAddress.java Wed Jul 02 >> 14:47:40 2014 +0200 >> +++ b/src/share/classes/java/net/InetAddress.java Wed Jul 02 >> 14:57:24 2014 +0200 >> @@ -42,6 +42,7 @@ >> import java.util.concurrent.ConcurrentMap; >> import java.util.concurrent.ConcurrentSkipListSet; >> import java.util.concurrent.atomic.AtomicLong; >> +import java.util.concurrent.locks.ReentrantLock; >> >> import sun.security.action.*; >> import sun.net.InetAddressCachePolicy; >> @@ -763,6 +764,7 @@ >> private static final class NameServiceAddresses implements >> Addresses { >> private final String host; >> private final InetAddress reqAddr; >> + private final ReentrantLock lock = new ReentrantLock(); >> >> NameServiceAddresses(String host, InetAddress reqAddr) { >> this.host = host; >> @@ -774,7 +776,8 @@ >> Addresses addresses; >> // only one thread is doing lookup to name service >> // for particular host at any time. >> - synchronized (this) { >> + lock.lock(); >> + try { >> // re-check that we are still us + re-install us if >> slot empty >> addresses = cache.putIfAbsent(host, this); >> if (addresses == null) { >> @@ -822,10 +825,13 @@ >> return inetAddresses; >> } >> // else addresses != this >> + >> + // delegate to different addresses when we are >> already replaced >> + // but outside of synchronized block to avoid any >> chance of dead-locking >> + return addresses.get(); >> + } finally { >> + lock.unlock(); >> } >> - // delegate to different addresses when we are already >> replaced >> - // but outside of synchronized block to avoid any chance >> of dead-locking >> - return addresses.get(); >> } >> } >> >> nit: line 1258: getAddressesFromNameService made package private but >> not used outside of InetAddress? > > Good catch. I seem to have inadvertently deleted the "private" keyword. > >> >> Generally I think this looks good, but I'm not a reviewer. :) >> >> /Claes > > Regards, Peter > >> >> On 07/02/2014 01:56 PM, Peter Levart wrote: >>> Hi, >>> >>> I updated the webrev with first two suggestions from Bernd >>> (expireTime instead of createTime and cacheNanos + only use >>> putIfAbsent instead of get followed by putIfAbsent): >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/webrev.02/ >>> >>> >>> Thanks, Bernd. >>> >>> The id field in CachedAddresses is necessary for compareTo to never >>> return 0 for two different instances (used as element in >>> ConcurrentSkipListSet). >>> >>> For last two suggestions I'm not sure whether they are desired, so >>> I'm currently leaving them as is. >>> >>> >>> Regards, Peter >>> >>> On 07/01/2014 10:06 PM, Bernd Eckenfels wrote: >>>> Looks good, like it, Peter. >>>> >>>> some nits: instead of adding createTime and cacheNanos, only have a >>>> expireAfter? >>>> >>>> L782: is it better to use putIfAbsent unconditionally, instead of >>>> get/putIfAbsent in NameServicdeAddr? >>>> >>>> L732: I am unsure about the id field, isnt it enough to have the >>>> identity equality check for the replacement check and otherwise depend >>>> on equals()? >>>> >>>> L1223: What about moving the cache exiry inside the if (useCache) >>>> >>>> BTW1: might be the wrong RFR, but considering your good performance >>>> numbers for an active cache, would having 100ms or similiar default >>>> negative cache time make sense without impacting (visible) the >>>> semantic. >>>> >>>> >>>> >>>> Gruss >>>> Bernd >>>> >>>> >>>> Am Tue, 01 Jul 2014 20:35:57 +0200 >>>> schrieb Peter Levart : >>>> >>>>> Hi, >>>>> >>>>> I propose a patch for this issue: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-7186258 >>>>> >>>>> The motivation to re-design caching of InetAddress-es was not this >>>>> issue though, but a desire to attack synchronization bottlenecks in >>>>> methods like URL.equals and URL.hashCode which use host name to IP >>>>> address mapping. I plan to tackle the synchronization in URL in a >>>>> follow-up proposal, but I wanted to 1st iron-out the "leaves" of the >>>>> call-tree. Here's the proposed patch: >>>>> >>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/webrev.01/ >>>>> >>>>> >>>>> sun.net.InetAddressCachePolicy: >>>>> >>>>> - two static methods (get() and getNegative()) were synchronized. >>>>> Removed synchronization and made underlying fields volatile. >>>>> - also added a normalization of negative policy in >>>>> setNegativeIfNotSet(). The logic in InetAddress doesn't cope with >>>>> negative values distinct from InetAddressCachePolicy.FOREVER (-1), so >>>>> this was a straight bug. The setIfNotSet() doesn't need this >>>>> normalization, because checkValue() throws exception if passed-in >>>>> value < InetAddressCachePolicy.FOREVER. >>>>> >>>>> java.net.InetAddress: >>>>> >>>>> - complete redesign of caching. Instead of distinct Positive/Negative >>>>> caches, there's only one cache - a ConcurrentHashMap. The value in >>>>> the map knows if it contains positive or negative answer. >>>>> - the design of this cache is similar but much simpler than >>>>> java.lang.reflect.WeakCache, since it doesn't have to deal with >>>>> WeakReferences and keys are simpler (just strings - hostnames). >>>>> Similarity is in how concurrent requests for the same key (hostname) >>>>> are synchronized when the entry is not cached yet, but still avoid >>>>> synchronization when entry is cached. This preserves the behaviour of >>>>> original InetAddress caching code but simplifies it greatly (100+ >>>>> lines removed). >>>>> - I tried to preserve the interaction between >>>>> InetAddress.getLocalHost() and InetAddress.getByName(). The >>>>> getLocalHost() caches the local host address for 5 seconds privately. >>>>> When it expires it performs new name service look-up and "refreshes" >>>>> the entry in the InetAddress.getByName() cache although it has not >>>>> expired yet. I think this is meant to prevent surprises when >>>>> getLocalHost() returns newer address than getByName() which is called >>>>> after that. >>>>> - I also fixed the JDK-7186258 as a by-product (but don't know yet >>>>> how to write a test for this issue - any ideas?) >>>>> >>>>> I created a JMH benchmark that tests the following methods: >>>>> >>>>> - InetAddress.getLocalHost() >>>>> - InetAddress.getByName() (with positive and negative answer) >>>>> >>>>> Here're the results of running on my 4-core (8-threads) i7/Linux: >>>>> >>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/InetAddress.Cache_bench_results.01.pdf >>>>> >>>>> >>>>> >>>>> The getByNameNegative() test does not show much improvement in >>>>> patched vs. original code. That's because by default the policy is to >>>>> NOT cache negative answers. Requests for same hostname to the >>>>> NameService(s) are synchronized. If >>>>> "networkaddress.cache.negative.ttl" system property is set to some >>>>> positive value, results are similar to those of getByNamePositive() >>>>> test (the default policy for positive caching is 30 seconds). >>>>> >>>>> I ran the jtreg tests in test/java/net and have the same score as >>>>> with original unpatched code. I have 3 failing tests from original >>>>> and patched runs: >>>>> >>>>> JT Harness : Tests that failed >>>>> java/net/MulticastSocket/Promiscuous.java: Test for interference when >>>>> two sockets are bound to the same port but joined to different >>>>> multicast groups >>>>> java/net/MulticastSocket/SetLoopbackMode.java: Test >>>>> MulticastSocket.setLoopbackMode >>>>> java/net/MulticastSocket/Test.java: IPv4 and IPv6 multicasting broken >>>>> on Linux >>>>> >>>>> And 1 test that had error trying to be run: >>>>> >>>>> JT Harness : Tests that had errors >>>>> java/net/URLPermission/nstest/lookup.sh: >>>>> >>>>> Because of: >>>>> >>>>> test result: Error. Can't find source file: jdk/testlibrary/*.java in >>>>> directory-list: >>>>> /home/peter/work/hg/jdk9-dev/jdk/test/java/net/URLPermission/nstest >>>>> /home/peter/work/hg/jdk9-dev/jdk/test/lib/testlibrary >>>>> >>>>> All other 258 java/net tests pass. >>>>> >>>>> >>>>> >>>>> So what do you think? >>>>> >>>>> >>>>> Regards, Peter >>>>> >>>>> >>> >> > From coleen.phillimore at oracle.com Wed Jul 2 17:05:00 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 02 Jul 2014 13:05:00 -0400 Subject: RFR 8047737 Move array component mirror to instance of java/lang/Class In-Reply-To: <53B3A623.1050804@oracle.com> References: <53ADC4D4.4030403@oracle.com> <53B0FBEF.5030607@oracle.com> <53B15B50.6070405@oracle.com> <53B205C7.8070804@oracle.com> <53B3A623.1050804@oracle.com> Message-ID: <53B43BBC.3030501@oracle.com> Hi Mandy, The componentType field is the last one that I'm planning on moving out for now, so I'd like to keep the code as is. If more are added because of more performance opportunities, I think we can revisit this. I agree with Doug that we don't want any more special code like this in the JVM to disable these optimizations if they are ever implemented. Thank you for reviewing the code. Coleen On 7/2/14, 2:26 AM, Mandy Chung wrote: > > On 6/30/2014 9:51 PM, Christian Thalinger wrote: >> On Jun 30, 2014, at 5:50 PM, Coleen Phillimore >> wrote: >> >> >> On 6/30/14, 3:50 PM, Christian Thalinger wrote: >>>> private Class(ClassLoader loader) { >>>> // Initialize final field for classLoader. The >>>> initialization value of non-null >>>> // prevents future JIT optimizations from assuming this >>>> final field is null. >>>> classLoader = loader; >>>> + componentType = null; >>>> } >>>> >>>> Are we worried about the same optimization? >>> Hi, I've decided to make them consistent and add another parameter >>> to the Class constructor. >>> >>> http://cr.openjdk.java.net/~coleenp/8047737_jdk_2/ > > The jdk change looks okay while I am beginning to think whether we > really want to keep expanding this constructor to deal with this > future JIT optimization (you will be moving more fields out from the > VM to java.lang.Class). > > There are places in JDK initializing the final fields to null while > the final field value is overridden via native/VM - e.g. System.in, > System.out, etc. I would prefer reverting the classLoader constructor > change to expanding the constructor for any new field being added. > Handle it (and other places in JDK) when such JIT optimization comes. > > Mandy > From mandy.chung at oracle.com Wed Jul 2 17:21:33 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 02 Jul 2014 10:21:33 -0700 Subject: RFR 8047737 Move array component mirror to instance of java/lang/Class In-Reply-To: <53B43BBC.3030501@oracle.com> References: <53ADC4D4.4030403@oracle.com> <53B0FBEF.5030607@oracle.com> <53B15B50.6070405@oracle.com> <53B205C7.8070804@oracle.com> <53B3A623.1050804@oracle.com> <53B43BBC.3030501@oracle.com> Message-ID: <53B43F9D.806@oracle.com> I wasn't aware of the VM special case of System.{in,out,err} fields that Doug pointed out (thanks. I should have checked). That's okay with me. Mandy On 7/2/2014 10:05 AM, Coleen Phillimore wrote: > > Hi Mandy, > > The componentType field is the last one that I'm planning on moving > out for now, so I'd like to keep the code as is. If more are added > because of more performance opportunities, I think we can revisit this. > > I agree with Doug that we don't want any more special code like this > in the JVM to disable these optimizations if they are ever implemented. > > Thank you for reviewing the code. > Coleen > > On 7/2/14, 2:26 AM, Mandy Chung wrote: >> >> On 6/30/2014 9:51 PM, Christian Thalinger wrote: >>> On Jun 30, 2014, at 5:50 PM, Coleen Phillimore >>> wrote: >>> >>> >>> On 6/30/14, 3:50 PM, Christian Thalinger wrote: >>>>> private Class(ClassLoader loader) { >>>>> // Initialize final field for classLoader. The >>>>> initialization value of non-null >>>>> // prevents future JIT optimizations from assuming this >>>>> final field is null. >>>>> classLoader = loader; >>>>> + componentType = null; >>>>> } >>>>> >>>>> Are we worried about the same optimization? >>>> Hi, I've decided to make them consistent and add another parameter >>>> to the Class constructor. >>>> >>>> http://cr.openjdk.java.net/~coleenp/8047737_jdk_2/ >> >> The jdk change looks okay while I am beginning to think whether we >> really want to keep expanding this constructor to deal with this >> future JIT optimization (you will be moving more fields out from the >> VM to java.lang.Class). >> >> There are places in JDK initializing the final fields to null while >> the final field value is overridden via native/VM - e.g. System.in, >> System.out, etc. I would prefer reverting the classLoader >> constructor change to expanding the constructor for any new field >> being added. Handle it (and other places in JDK) when such JIT >> optimization comes. >> >> Mandy >> > From stuart.marks at oracle.com Wed Jul 2 19:13:58 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 02 Jul 2014 12:13:58 -0700 Subject: RFR 8043328 and 8043327: errors in stream docs In-Reply-To: <6BD5BE4B-3FA1-406F-ADEB-99B0626B7BAC@oracle.com> References: <6BD5BE4B-3FA1-406F-ADEB-99B0626B7BAC@oracle.com> Message-ID: <53B459F6.4070809@oracle.com> On 7/2/14 1:25 AM, Paul Sandoz wrote: > Stuart, are you planning to back port your doc fix to 8u-dev? If so we could do all three in one go. Hm, it might be a good idea to do so, in case we refresh the published javadoc in one of the 8-updates. That way the corrections will get out there sooner instead of waiting for 9. I seem to recall other small javadoc changes having gone in as well; it might be good to backport those too. Checking.... s'marks From henry.jen at oracle.com Wed Jul 2 21:45:13 2014 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 02 Jul 2014 14:45:13 -0700 Subject: RFR: 8049109: Add @since 1.9 to new packages added in jaxp In-Reply-To: <53B2094A.4030603@oracle.com> References: <53B1D781.2050302@oracle.com> <53B1FA8C.7060500@oracle.com> <53B2094A.4030603@oracle.com> Message-ID: <53B47D69.3010203@oracle.com> Hi, Related to JDK-8023276[1] where we added two packages to JDK 9, we should update @since to have 1.9 value as well. http://cr.openjdk.java.net/~henryjen/jdk9/8049109/0/webrev/ [1] https://bugs.openjdk.java.net/browse/JDK-8023276 Cheers, Henry From joe.darcy at oracle.com Wed Jul 2 22:43:55 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 02 Jul 2014 15:43:55 -0700 Subject: RFR: 8049109: Add @since 1.9 to new packages added in jaxp In-Reply-To: <53B47D69.3010203@oracle.com> References: <53B1D781.2050302@oracle.com> <53B1FA8C.7060500@oracle.com> <53B2094A.4030603@oracle.com> <53B47D69.3010203@oracle.com> Message-ID: <53B48B2B.2070300@oracle.com> Looks good Henry; cheers, -Joe On 07/02/2014 02:45 PM, Henry Jen wrote: > Hi, > > Related to JDK-8023276[1] where we added two packages to JDK 9, we > should update @since to have 1.9 value as well. > > http://cr.openjdk.java.net/~henryjen/jdk9/8049109/0/webrev/ > > [1] https://bugs.openjdk.java.net/browse/JDK-8023276 > > Cheers, > Henry > From huizhe.wang at oracle.com Thu Jul 3 00:12:53 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 02 Jul 2014 17:12:53 -0700 Subject: RFR: 8049109: Add @since 1.9 to new packages added in jaxp In-Reply-To: <53B48B2B.2070300@oracle.com> References: <53B1D781.2050302@oracle.com> <53B1FA8C.7060500@oracle.com> <53B2094A.4030603@oracle.com> <53B47D69.3010203@oracle.com> <53B48B2B.2070300@oracle.com> Message-ID: <53B4A005.70407@oracle.com> These packages were defined in JDK 1.5 / JAXP 1.3 (JSR 206). In that sense, they were in JDK since 1.5. For reasons I don't know, they were excluded from the Java API Documentation. From the tag conventions [1], you may be right since it "Specify the product version when the Java name was added to the API specification". But it can be confusing to users since they've been using them since JDK 1.5 [1] http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#@since -Joe On 7/2/2014 3:43 PM, Joe Darcy wrote: > Looks good Henry; cheers, > > -Joe > > On 07/02/2014 02:45 PM, Henry Jen wrote: >> Hi, >> >> Related to JDK-8023276[1] where we added two packages to JDK 9, we >> should update @since to have 1.9 value as well. >> >> http://cr.openjdk.java.net/~henryjen/jdk9/8049109/0/webrev/ >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8023276 >> >> Cheers, >> Henry >> > From henry.jen at oracle.com Thu Jul 3 01:02:13 2014 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 02 Jul 2014 18:02:13 -0700 Subject: RFR: 8049109: Add @since 1.9 to new packages added in jaxp In-Reply-To: <53B4A005.70407@oracle.com> References: <53B1D781.2050302@oracle.com> <53B1FA8C.7060500@oracle.com> <53B2094A.4030603@oracle.com> <53B47D69.3010203@oracle.com> <53B48B2B.2070300@oracle.com> <53B4A005.70407@oracle.com> Message-ID: <53B4AB95.9020102@oracle.com> I don't have a strong preference in this case, and I hear you that those classes are public and can be accessed in 1.5 even though it's not part of API specification of JDK. Considered DOM Level 2 is still listed as secondary information, and as the document you pointed out, 1.9 is used because that those APIs will become official in JDK 9. Lets give it a couple days before commit this, hopefuly some dicussion(along with other cases brought up in this thread[1]) will occur and lead to a concensus. Sometime I feel we need a supreme court for Java affairs to come out the final ruling on such stuff. :) [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-July/027503.html Cheers, Henry On 07/02/2014 05:12 PM, huizhe wang wrote: > These packages were defined in JDK 1.5 / JAXP 1.3 (JSR 206). In that > sense, they were in JDK since 1.5. > > For reasons I don't know, they were excluded from the Java API > Documentation. From the tag conventions > > [1], you may be right since it "Specify the product version when the > Java name was added to the API specification". But it can be confusing > to users since they've been using them since JDK 1.5 > > [1] > http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#@since > > -Joe > > On 7/2/2014 3:43 PM, Joe Darcy wrote: >> Looks good Henry; cheers, >> >> -Joe >> >> On 07/02/2014 02:45 PM, Henry Jen wrote: >>> Hi, >>> >>> Related to JDK-8023276[1] where we added two packages to JDK 9, we >>> should update @since to have 1.9 value as well. >>> >>> http://cr.openjdk.java.net/~henryjen/jdk9/8049109/0/webrev/ >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8023276 >>> >>> Cheers, >>> Henry >>> >> > From mikael.vidstedt at oracle.com Thu Jul 3 01:24:49 2014 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 02 Jul 2014 18:24:49 -0700 Subject: RFR(XS): 8047154: Testset all fails because of missing jdk_beansX test groups Message-ID: <53B4B0E1.8040802@oracle.com> Please review -- the jdk_beansX targets were removed as part of moving from Makefile logic to jtreg test groups late last year and the "all" testset currently fails because of that. The only remaining beans group is called jdk_beans and this change reflects that change. Bug: https://bugs.openjdk.java.net/browse/JDK-8047154 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8047154/webrev.00/webrev/ Cheers, Mikael From Alan.Bateman at oracle.com Thu Jul 3 06:29:08 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 03 Jul 2014 07:29:08 +0100 Subject: RFR(XS): 8047154: Testset all fails because of missing jdk_beansX test groups In-Reply-To: <53B4B0E1.8040802@oracle.com> References: <53B4B0E1.8040802@oracle.com> Message-ID: <53B4F834.8050607@oracle.com> On 03/07/2014 02:24, Mikael Vidstedt wrote: > > Please review -- the jdk_beansX targets were removed as part of moving > from Makefile logic to jtreg test groups late last year and the "all" > testset currently fails because of that. The only remaining beans > group is called jdk_beans and this change reflects that change. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8047154 > Webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8047154/webrev.00/webrev/ This looks okay, although I'm pretty sure these that the "all" testset is not used. -Alan From paul.sandoz at oracle.com Thu Jul 3 07:14:19 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 3 Jul 2014 09:14:19 +0200 Subject: RFR 8043328 and 8043327: errors in stream docs In-Reply-To: <53B459F6.4070809@oracle.com> References: <6BD5BE4B-3FA1-406F-ADEB-99B0626B7BAC@oracle.com> <53B459F6.4070809@oracle.com> Message-ID: <2409F27E-2172-417E-B58C-93BE87BE35E2@oracle.com> On Jul 2, 2014, at 9:13 PM, Stuart Marks wrote: > On 7/2/14 1:25 AM, Paul Sandoz wrote: >> Stuart, are you planning to back port your doc fix to 8u-dev? If so we could do all three in one go. > > Hm, it might be a good idea to do so, in case we refresh the published javadoc in one of the 8-updates. That way the corrections will get out there sooner instead of waiting for 9. > > I seem to recall other small javadoc changes having gone in as well; Yes, i suspect more often in combination with code fixes (i recall doing that). Paul. > it might be good to backport those too. Checking.... > > s'marks From mike at saxonica.com Thu Jul 3 08:06:56 2014 From: mike at saxonica.com (Michael Kay) Date: Thu, 3 Jul 2014 09:06:56 +0100 Subject: RFR: 8049109: Add @since 1.9 to new packages added in jaxp In-Reply-To: <53B4A005.70407@oracle.com> References: <53B1D781.2050302@oracle.com> <53B1FA8C.7060500@oracle.com> <53B2094A.4030603@oracle.com> <53B47D69.3010203@oracle.com> <53B48B2B.2070300@oracle.com> <53B4A005.70407@oracle.com> Message-ID: <38F2E18C-0570-41F6-A1AF-056B9C1470D9@saxonica.com> But it can be confusing to users since they've been using them since JDK 1.5 >>> >>> Related to JDK-8023276[1] where we added two packages to JDK 9 Speaking of which, has it occurred to anyone that it might be confusing to users that JDK 9 and JDK 1.9 are the same thing? Isn't it time we got rid of this absurdity? Michael Kay Saxonica From peter.levart at gmail.com Thu Jul 3 08:43:59 2014 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 03 Jul 2014 10:43:59 +0200 Subject: RFR 8049220: URL.factory data race Message-ID: <53B517CF.6060006@gmail.com> Hi, I noticed a data race in java.net.URL: https://bugs.openjdk.java.net/browse/JDK-8049220 I propose the following simple patch: http://cr.openjdk.java.net/~plevart/jdk9-dev/URL.factory/webrev.01/ Regards, Peter From pavel.rappo at oracle.com Thu Jul 3 10:07:30 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 3 Jul 2014 11:07:30 +0100 Subject: RFR 8049220: URL.factory data race In-Reply-To: <53B517CF.6060006@gmail.com> References: <53B517CF.6060006@gmail.com> Message-ID: <56914A19-21C1-43D2-8BB9-B2A24968ECCD@oracle.com> Hi Peter, Just a minor subjective issue. I would suggest changing the name of the local variable 'factory' in java.net.URL.getURLStreamHandler method for something different. It's a bit hard to read the code since this variable clashes with the same-name class field. Thanks, -Pavel On 3 Jul 2014, at 09:43, Peter Levart wrote: > Hi, > > I noticed a data race in java.net.URL: > > https://bugs.openjdk.java.net/browse/JDK-8049220 > > I propose the following simple patch: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/URL.factory/webrev.01/ > > > Regards, Peter From ivan.gerasimov at oracle.com Thu Jul 3 11:05:57 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 03 Jul 2014 15:05:57 +0400 Subject: RFR 8043328 and 8043327: errors in stream docs In-Reply-To: <2409F27E-2172-417E-B58C-93BE87BE35E2@oracle.com> References: <6BD5BE4B-3FA1-406F-ADEB-99B0626B7BAC@oracle.com> <53B459F6.4070809@oracle.com> <2409F27E-2172-417E-B58C-93BE87BE35E2@oracle.com> Message-ID: <53B53915.2070505@oracle.com> Paul, would you please include a few more typo fixes, if it's not too late? Sincerely yours, Ivan diff -r 7b662a967f74 src/share/classes/java/util/stream/AbstractPipeline.java --- a/src/share/classes/java/util/stream/AbstractPipeline.java +++ b/src/share/classes/java/util/stream/AbstractPipeline.java @@ -406,7 +406,7 @@ // Clear the short circuit flag for next pipeline stage // This stage encapsulates short-circuiting, the next // stage may not have any short-circuit operations, and - // if so spliterator.forEachRemaining should be be used + // if so spliterator.forEachRemaining should be used // for traversal thisOpFlags = thisOpFlags & ~StreamOpFlag.IS_SHORT_CIRCUIT; } diff -r 7b662a967f74 src/share/classes/java/util/stream/BaseStream.java --- a/src/share/classes/java/util/stream/BaseStream.java +++ b/src/share/classes/java/util/stream/BaseStream.java @@ -53,7 +53,7 @@ * parallelism, which governs the behavior of all stream types. * * @param the type of the stream elements - * @param the type of of the stream implementing {@code BaseStream} + * @param the type of the stream implementing {@code BaseStream} * @since 1.8 * @see Stream * @see IntStream diff -r 7b662a967f74 src/share/classes/java/util/stream/DoubleStream.java --- a/src/share/classes/java/util/stream/DoubleStream.java +++ b/src/share/classes/java/util/stream/DoubleStream.java @@ -768,7 +768,7 @@ * to the element at position {@code n - 1}. * * @param seed the initial element - * @param f a function to be applied to to the previous element to produce + * @param f a function to be applied to the previous element to produce * a new element * @return a new sequential {@code DoubleStream} */ diff -r 7b662a967f74 src/share/classes/java/util/stream/IntStream.java --- a/src/share/classes/java/util/stream/IntStream.java +++ b/src/share/classes/java/util/stream/IntStream.java @@ -734,7 +734,7 @@ * element at position {@code n - 1}. * * @param seed the initial element - * @param f a function to be applied to to the previous element to produce + * @param f a function to be applied to the previous element to produce * a new element * @return A new sequential {@code IntStream} */ diff -r 7b662a967f74 src/share/classes/java/util/stream/LongStream.java --- a/src/share/classes/java/util/stream/LongStream.java +++ b/src/share/classes/java/util/stream/LongStream.java @@ -727,7 +727,7 @@ * element at position {@code n - 1}. * * @param seed the initial element - * @param f a function to be applied to to the previous element to produce + * @param f a function to be applied to the previous element to produce * a new element * @return a new sequential {@code LongStream} */ diff -r 7b662a967f74 src/share/classes/java/util/stream/PipelineHelper.java --- a/src/share/classes/java/util/stream/PipelineHelper.java +++ b/src/share/classes/java/util/stream/PipelineHelper.java @@ -74,7 +74,7 @@ /** * Returns the exact output size of the portion of the output resulting from * applying the pipeline stages described by this {@code PipelineHelper} to - * the the portion of the input described by the provided + * the portion of the input described by the provided * {@code Spliterator}, if known. If not known or known infinite, will * return {@code -1}. * diff -r 7b662a967f74 src/share/classes/java/util/stream/SliceOps.java --- a/src/share/classes/java/util/stream/SliceOps.java +++ b/src/share/classes/java/util/stream/SliceOps.java @@ -693,7 +693,7 @@ * size. * * @param target the target size - * @return return the number of completed elements + * @return the number of completed elements */ private long completedSize(long target) { if (completed) diff -r 7b662a967f74 src/share/classes/java/util/stream/Stream.java --- a/src/share/classes/java/util/stream/Stream.java +++ b/src/share/classes/java/util/stream/Stream.java @@ -1013,7 +1013,7 @@ * * @param the type of stream elements * @param seed the initial element - * @param f a function to be applied to to the previous element to produce + * @param f a function to be applied to the previous element to produce * a new element * @return a new sequential {@code Stream} */ diff -r 7b662a967f74 src/share/classes/java/util/stream/StreamOpFlag.java --- a/src/share/classes/java/util/stream/StreamOpFlag.java +++ b/src/share/classes/java/util/stream/StreamOpFlag.java @@ -115,7 +115,7 @@ * characteristics that stream has; when describing a stream operation, one need * describe whether the operation preserves, injects, or clears that * characteristic. Accordingly, two bits are used for each flag, so as to allow - * representing not only the presence of of a characteristic, but how an + * representing not only the presence of a characteristic, but how an * operation modifies that characteristic. There are two common forms in which * flag bits are combined into an {@code int} bit set. Stream flags * are a unioned bit set constructed by ORing the enum characteristic values of From paul.sandoz at oracle.com Thu Jul 3 12:03:26 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 3 Jul 2014 14:03:26 +0200 Subject: RFR 8043328 and 8043327: errors in stream docs In-Reply-To: <53B53915.2070505@oracle.com> References: <6BD5BE4B-3FA1-406F-ADEB-99B0626B7BAC@oracle.com> <53B459F6.4070809@oracle.com> <2409F27E-2172-417E-B58C-93BE87BE35E2@oracle.com> <53B53915.2070505@oracle.com> Message-ID: <079A9673-F0D8-4385-BE8C-A1F8A4E26899@oracle.com> On Jul 3, 2014, at 1:05 PM, Ivan Gerasimov wrote: > Paul, would you please include a few more typo fixes, if it's not too late? > Thanks for doing this, the changes look good. Unfortunately it's too late for this bug, but i will merge it into the patch for: 8044047: Missing null pointer checks for streams http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-July/027514.html Paul. From david.holmes at oracle.com Thu Jul 3 12:05:46 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 03 Jul 2014 22:05:46 +1000 Subject: RFR(XS): 8047154: Testset all fails because of missing jdk_beansX test groups In-Reply-To: <53B4F834.8050607@oracle.com> References: <53B4B0E1.8040802@oracle.com> <53B4F834.8050607@oracle.com> Message-ID: <53B5471A.5000800@oracle.com> +1 David On 3/07/2014 4:29 PM, Alan Bateman wrote: > On 03/07/2014 02:24, Mikael Vidstedt wrote: >> >> Please review -- the jdk_beansX targets were removed as part of moving >> from Makefile logic to jtreg test groups late last year and the "all" >> testset currently fails because of that. The only remaining beans >> group is called jdk_beans and this change reflects that change. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8047154 >> Webrev: >> http://cr.openjdk.java.net/~mikael/webrevs/8047154/webrev.00/webrev/ > This looks okay, although I'm pretty sure these that the "all" testset > is not used. > > -Alan From joe.darcy at oracle.com Thu Jul 3 15:30:00 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 03 Jul 2014 08:30:00 -0700 Subject: RFR: 8047722: @since tag cleanup in corba In-Reply-To: <53B352EA.4060001@oracle.com> References: <53A4A789.6040609@oracle.com> <53B0BDA0.9070004@oracle.com> <53B10F5E.3010005@oracle.com> <53B17F71.1040706@oracle.com> <53B352EA.4060001@oracle.com> Message-ID: <53B576F8.5060307@oracle.com> On 07/01/2014 05:31 PM, Stuart Marks wrote: > On 6/30/14 8:17 AM, Henry Jen wrote: >> On 06/30/2014 12:18 AM, Alan Bateman wrote: >>> On 30/06/2014 02:30, Henry Jen wrote: >>>> On 06/20/2014 02:28 PM, Henry Jen wrote: >>>>> Please review a trivial webrev for jdk9/corba that do the same @since >>>>> tag normalization as in jdk9/jdk. >>>>> >>>>> http://cr.openjdk.java.net/~henryjen/jdk9/8047722/0/webrev/ >>> There are bunch of @since JDK 1.0 and JDK 1.1.6 that you are >>> changing to >>> 1.0 and 1.1.6. AFAIK, CORBA was added in 1.2 and I wonder if we should >>> fix this as part of this change. >>> >> >> Thanks for review. You are correct that CORBA was added in 1.2. >> >> My understadning to those 1.0 to 1.1.6 versions are for override >> methods, I >> guess the author is putting down the version of the origin. >> >> There are several cases where @since can be ambiguous without a >> common guideline, >> >> - An method was private or package access only made public, should >> @since denote >> the API availablity or the implementation? >> >> - APIs from classed was extracted into a super class or interface in >> a later >> version, what should be the @since? FWIW, when I did that kind of operation moving methods from java.lang.reflect.{Method, Constructor} into the new j.l.r.Executable in JDK 8 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d083644bc615 I defined overriding methods in the subclasses sometimes just for the purpose of creating a location where the semantics of the text could be {@inheritDoc}'ed with a distinct @since value. -Joe From ivan.gerasimov at oracle.com Thu Jul 3 16:00:22 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 03 Jul 2014 20:00:22 +0400 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size Message-ID: <53B57E16.5020802@oracle.com> Hello! IdentityHasMap has a couple of small issues. The first one is a performance issue: If you create a map, specifying 42 as the expected number of element, you'll be able to insert only 41 elements into the preallocated table. Inserting the 42th element will trigger resizing of the storage. Another issue is that resizing occurs only after the element insertion. In the extreme case it can lead to the situation when the element is successfully inserted and then en exception is thrown due the map been unable to grow. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-6904367 WEBREV: http://cr.openjdk.java.net/~igerasim/6904367/0/webrev/ Sincerely yours, Ivan From peter.levart at gmail.com Thu Jul 3 16:01:42 2014 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 03 Jul 2014 18:01:42 +0200 Subject: Gluing together URL.equals Message-ID: <53B57E66.3000908@gmail.com> Hi, We know that URL.equals and hashCode are fundamentally broken. But URL.equals is even more broken than hashCode. Nevertheless, URL.equals is used explicitly in the following places in JDK: java.security.CodeSource.matchLocation java.security.CodeSource.equals java.util.jar.JarVerifier.VerifierCodeSource.equals javax.sql.rowset.serial.SerialDatalink.equals java.lang.Package.isSealed javax.swing.JEditorPane.setPage javax.swing.text.html.FrameView.changedUpdate sun.applet.AppletViewer.getApplet sun.applet.AppletViewer.getApplets And I'm not counting places where it might be used because URLs are Objects (as keys in HashMaps, etc...) I'd like to discuss one of URL.equals pitfalls that might be able to get fixed and whether it is desirable to fix it. javadoc: "The equals method implements an equivalence relation on non-null object references: ... It is consistent: for any non-null reference values x and y, multiple invocations of x.equals(y) consistently return true or consistently return false, provided no information used in equals comparisons on the objects is modified." URL url1 = new URL("http://alias1/"); URL url2 = new URL("http://alias2/"); boolean answer1 = url1.equals(url2); ... boolean answer2 = url1.equals(url2); Can it happen that answer1 != answer2 ? Yes! Suppose that alias1 and alias2 are host names that resolve to the same IP address. Normally, answer1 and answer2 would be "true". But only if the name service that resolves the host names is up and running. If it's not, then the answer is "false". Suppose that while obtaining answer1 the DNS was restarting and while obtaining answer2 it was up and running... Then answer1 would be "false" while answer2 would be "true". The following URLStreamHandler method that is called for both URLs from equals method is responsible for such unstable behaviour: protected synchronized InetAddress getHostAddress(URL u) { if (u.hostAddress != null) return u.hostAddress; String host = u.getHost(); if (host == null || host.equals("")) { return null; } else { try { u.hostAddress = InetAddress.getByName(host); } catch (UnknownHostException ex) { return null; } catch (SecurityException se) { return null; } } return u.hostAddress; } As can be seen, the hostAddress is obtained by InetAddress.getByName() and then cached on the URL.hostAddress field. Leaving aside the fact that although this method is synchronized, caching of hostAddress is not synchronized properly (more on that later), the problem is that negative answer (UnknownHostException or SecurityException) is not cached. UnknownHostException is not cached by InetAddress.getByName() by default and SecurityException is dependent on the caller SecurityContext. Simple fix for this issue would be to cache negative answer on the URL field too. This would make URL.equals "consistent". So what's wrong with synchronization besides being a bottleneck? The problem is that getHostAddress() method is using the URLStreamHandler instance as a lock. Two URLs that are compared in the URL.equals method are passed to the URLStreamHandler.equals(URL u1, URL u2) method of the 1st URL's handler. This handler instance need not be the same as the 2nd URL's handler even though both URLs have same protocol. For example: URL url1 = new URL("http://alias1/"); URL.setURLStreamHandlerFactory(...a custom factory...); URL url2 = new URL("http://alias2/"); The "handler" instances of above two URLs are different, since the handler of 1st URL was created with default URLStreamHandlerFactory and the handler of 2nd URL was created with a custom URLStreamHandlerFactory. Now suppose one thread does: url1.equals(url2); and some other thread does: url2.equals(url1); This translates to, among other things, calling the following URLStreamHandler instance method: protected boolean hostsEqual(URL u1, URL u2) { InetAddress a1 = getHostAddress(u1); InetAddress a2 = getHostAddress(u2); // if we have internet address for both, compare them if (a1 != null && a2 != null) { return a1.equals(a2); // else, if both have host names, compare them } else if (u1.getHost() != null && u2.getHost() != null) return u1.getHost().equalsIgnoreCase(u2.getHost()); else return u1.getHost() == null && u2.getHost() == null; } So the two threads are reading and modifying URL.hostAddress field of both URLs, but each of them is holding a separate lock. You may say that creating URL instances, then changing the URLStreamHandlerFactory and creating some more URL instances and than comparing them among themselves is not happening a lot, but this could be fixed. Why not using the URL instance as a lock when reading/writing it's field? Would this be desirable? It would mean a lot less contention (and even less if caching of URL.hostAddress was implemented in a lock-free way). Because I know that URL.equals compatibility is important, I'm asking here if a fix for this issue is desirable at all. What about synchronization fix only (and keeping the "unstable" equals() behaviour)? Regards, Peter From Alan.Bateman at oracle.com Thu Jul 3 16:33:47 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 03 Jul 2014 17:33:47 +0100 Subject: RFR 8049220: URL.factory data race In-Reply-To: <53B517CF.6060006@gmail.com> References: <53B517CF.6060006@gmail.com> Message-ID: <53B585EB.9060807@oracle.com> On 03/07/2014 09:43, Peter Levart wrote: > Hi, > > I noticed a data race in java.net.URL: > > https://bugs.openjdk.java.net/browse/JDK-8049220 > > I propose the following simple patch: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/URL.factory/webrev.01/ > A good catch and the change looks good to me. I assume it just wasn't noticed because it can only be set once and probably rared used too. -Alan From martinrb at google.com Thu Jul 3 17:12:24 2014 From: martinrb at google.com (Martin Buchholz) Date: Thu, 3 Jul 2014 10:12:24 -0700 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53B57E16.5020802@oracle.com> References: <53B57E16.5020802@oracle.com> Message-ID: Martin's law of expanding capacity: Always grow by using the form newCapacity = oldCapacity + oldCapacity >> n for some suitable constant n. This will be efficient and more overflow resistant than the alternative newCapacity = oldCapacity * (2**n + 1) / (2**n) Here n == 1. On Thu, Jul 3, 2014 at 9:00 AM, Ivan Gerasimov wrote: > Hello! > > IdentityHasMap has a couple of small issues. > The first one is a performance issue: If you create a map, specifying 42 > as the expected number of element, you'll be able to insert only 41 > elements into the preallocated table. Inserting the 42th element will > trigger resizing of the storage. > > Another issue is that resizing occurs only after the element insertion. > In the extreme case it can lead to the situation when the element is > successfully inserted and then en exception is thrown due the map been > unable to grow. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-6904367 > WEBREV: http://cr.openjdk.java.net/~igerasim/6904367/0/webrev/ > > Sincerely yours, > Ivan > > From Alan.Bateman at oracle.com Thu Jul 3 17:16:39 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 03 Jul 2014 18:16:39 +0100 Subject: RFR: 8047722: @since tag cleanup in corba In-Reply-To: <53B352EA.4060001@oracle.com> References: <53A4A789.6040609@oracle.com> <53B0BDA0.9070004@oracle.com> <53B10F5E.3010005@oracle.com> <53B17F71.1040706@oracle.com> <53B352EA.4060001@oracle.com> Message-ID: <53B58FF7.8000905@oracle.com> On 02/07/2014 01:31, Stuart Marks wrote: > > There are some strange cases here. > > But the high order question is API vs implementation, and I think > @since really is about API. I don't know if was a conclusion on what to do with some of these but maybe the simplest is to just remove @since from some of the implementation classes and just eliminate the confusion that they cause. Looking com.sun.corba.se.impl.util.IdentityHashtable then it appears that the code was originally copied from code in what was the JDK1.1.6 workspace at the time. It's not clear to me that having the @since JDK1.0 tags in several methods has anything but negative value here. One of the really odd ones is com.sun.corba.se.impl.io.IIOPInputStream where the readObjectDelegate has both @since JDK 1.1 and @since JDK 1.1.6 :-) -Alan From mikael.vidstedt at oracle.com Thu Jul 3 17:31:43 2014 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 03 Jul 2014 10:31:43 -0700 Subject: RFR(XS): 8047154: Testset all fails because of missing jdk_beansX test groups In-Reply-To: <53B5471A.5000800@oracle.com> References: <53B4B0E1.8040802@oracle.com> <53B4F834.8050607@oracle.com> <53B5471A.5000800@oracle.com> Message-ID: <53B5937F.4020002@oracle.com> Alan, David - thanks for the reviews! Cheers, Mikael On 2014-07-03 05:05, David Holmes wrote: > +1 > > David > > On 3/07/2014 4:29 PM, Alan Bateman wrote: >> On 03/07/2014 02:24, Mikael Vidstedt wrote: >>> >>> Please review -- the jdk_beansX targets were removed as part of moving >>> from Makefile logic to jtreg test groups late last year and the "all" >>> testset currently fails because of that. The only remaining beans >>> group is called jdk_beans and this change reflects that change. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8047154 >>> Webrev: >>> http://cr.openjdk.java.net/~mikael/webrevs/8047154/webrev.00/webrev/ >> This looks okay, although I'm pretty sure these that the "all" testset >> is not used. >> >> -Alan From martinrb at google.com Thu Jul 3 17:59:51 2014 From: martinrb at google.com (Martin Buchholz) Date: Thu, 3 Jul 2014 10:59:51 -0700 Subject: RFR JDK-7186258: InetAddress$Cache should replace currentTimeMillis with nanoTime (+more) In-Reply-To: <53B419B7.1030600@oracle.com> References: <53B2FF8D.5040503@gmail.com> <20140701220621.00005e21.bernd-2014@eckenfels.net> <53B3F377.3090208@gmail.com> <53B419B7.1030600@oracle.com> Message-ID: On Wed, Jul 2, 2014 at 7:39 AM, Claes Redestad wrote: > Hi Peter, > > perhaps the synchronized(this)-block in NameServiceAddresses::get() can > be replaced with a ReentrantLock? Applying this on top of your patch, I > seem to improve scores on your benchmark for -t 4 by ~33% on my machine: > Once upon a time ReentrantLock had some performance advantage over builtin synchronized; but today best practice is to prefer ReentrantLock only for the software engineering advantages like more flexibility or clarity. From claes.redestad at oracle.com Thu Jul 3 18:13:59 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 03 Jul 2014 20:13:59 +0200 Subject: RFR JDK-7186258: InetAddress$Cache should replace currentTimeMillis with nanoTime (+more) In-Reply-To: References: <53B2FF8D.5040503@gmail.com> <20140701220621.00005e21.bernd-2014@eckenfels.net> <53B3F377.3090208@gmail.com> <53B419B7.1030600@oracle.com> Message-ID: <53B59D67.5020706@oracle.com> On 07/03/2014 07:59 PM, Martin Buchholz wrote: > > > > On Wed, Jul 2, 2014 at 7:39 AM, Claes Redestad > > wrote: > > Hi Peter, > > perhaps the synchronized(this)-block in > NameServiceAddresses::get() can be replaced with a ReentrantLock? > Applying this on top of your patch, I seem to improve scores on > your benchmark for -t 4 by ~33% on my machine: > > > Once upon a time ReentrantLock had some performance advantage over > builtin synchronized; but today best practice is to prefer > ReentrantLock only for the software engineering advantages like more > flexibility or clarity. This was my feeling as well, but when I saw the remaining synchronized block in Peter's patch I got curious to see if that notion still held up. Sorry for being sloppy with the benchmarking and throwing a red herring into the mix, though. /Claes From ivan.gerasimov at oracle.com Thu Jul 3 18:29:31 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 03 Jul 2014 22:29:31 +0400 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: References: <53B57E16.5020802@oracle.com> Message-ID: <53B5A10B.5020006@oracle.com> Thanks Martin! On 03.07.2014 21:12, Martin Buchholz wrote: > Martin's law of expanding capacity: > > Always grow by using the form > > newCapacity = oldCapacity + oldCapacity >> n > > for some suitable constant n. This will be efficient and more > overflow resistant than the alternative > > newCapacity = oldCapacity * (2**n + 1) / (2**n) > > Here n == 1. > More precisely here n == 0, because the capacity gets doubled when increased. The formula cap = expSize * 3 / 2 is used to estimate the capacity based on the expected number of the items to be inserted. Sincerely yours, Ivan > > On Thu, Jul 3, 2014 at 9:00 AM, Ivan Gerasimov > > wrote: > > Hello! > > IdentityHasMap has a couple of small issues. > The first one is a performance issue: If you create a map, > specifying 42 as the expected number of element, you'll be able to > insert only 41 elements into the preallocated table. Inserting the > 42th element will trigger resizing of the storage. > > Another issue is that resizing occurs only after the element > insertion. > In the extreme case it can lead to the situation when the element > is successfully inserted and then en exception is thrown due the > map been unable to grow. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-6904367 > WEBREV: http://cr.openjdk.java.net/~igerasim/6904367/0/webrev/ > > > Sincerely yours, > Ivan > > From jeffhain at rocketmail.com Thu Jul 3 19:07:04 2014 From: jeffhain at rocketmail.com (Jeff Hain) Date: Thu, 3 Jul 2014 20:07:04 +0100 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53B57E16.5020802@oracle.com> References: <53B57E16.5020802@oracle.com> Message-ID: <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> Hi. >WEBREV: http://cr.openjdk.java.net/~igerasim/6904367/0/webrev/ The "while" loop in put(...) supposes that there is at least one free slot, which was the case before (that could be added as comment). Now if you try to go past max capacity, instead of getting an IllegalStateException, you get an infinite loop. It's easy to test with a loop of 1000 puts and MAX_CAPACITY = 1<<8 (=256, needs to be larger than DEFAULT_CAPACITY, else it can be "ignored"). With previous version you get IllegalStateException on trying to add 255th mapping (on the resize that occurs when just-after-put-size is 255 >= threshold = 255), and with new version you get infinite loop on trying to add 257th mapping. Solutions I see would be adding a throw if size >= MAX_CAPACITY before the loop, or not adding that overhead and instead throwing when "size >= MAX_CAPACITY-1" instead of when "size >= MAX_CAPACITY". I would also rather use "==" over ">=" for these tests, to underline the fact that size is not supposed to be larger, but there might be some reasons not to. -Jeff From ivan.gerasimov at oracle.com Thu Jul 3 19:38:03 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 03 Jul 2014 23:38:03 +0400 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> Message-ID: <53B5B11B.9030602@oracle.com> Thank you Jeff! On 03.07.2014 23:07, Jeff Hain wrote: > > Hi. > > > >WEBREV: http://cr.openjdk.java.net/~igerasim/6904367/0/webrev/ > > > The "while" loop in put(...) supposes that there is at least one free > slot, > which was the case before (that could be added as comment). > > Now if you try to go past max capacity, instead of getting an > IllegalStateException, > you get an infinite loop. > Yes, you're right! > It's easy to test with a loop of 1000 puts and MAX_CAPACITY = 1<<8 > (=256, needs to be larger than DEFAULT_CAPACITY, else it can be > "ignored"). > With previous version you get IllegalStateException on trying to add > 255th mapping > (on the resize that occurs when just-after-put-size is 255 >= > threshold = 255), > and with new version you get infinite loop on trying to add 257th mapping. > > Solutions I see would be adding a throw if size >= MAX_CAPACITY > before the loop, > This would break the case when an existing key is added to the already full table. Moreover, the full table without a single empty slot could cause an infinite looping in get(), remove(), etc. > or not adding that overhead and instead throwing when > "size >= MAX_CAPACITY-1" instead of when "size >= MAX_CAPACITY". > This seems appropriate. With the current implementation we can only put MAX_CAPACITY-1 elements anyway. > I would also rather use "==" over ">=" for these tests, to underline > the fact > that size is not supposed to be larger, but there might be some > reasons not to. > I think it makes the code a bit more stable from the perspective of the future changes. Here's the updated webrev: http://cr.openjdk.java.net/~igerasim/6904367/1/webrev/ Sincerely yours, Ivan > > -Jeff > > > From joe.darcy at oracle.com Thu Jul 3 19:44:45 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 03 Jul 2014 12:44:45 -0700 Subject: Supplemental code review request for JDK-8043550: Fix raw and unchecked lint warnings in javax.swing.* Message-ID: <53B5B2AD.3040803@oracle.com> Hello, In the course of fixing JDK-8043550: Fix raw and unchecked lint warnings in javax.swing.* http://cr.openjdk.java.net/~darcy/8043550.1/ I encountered a build failure in jconsole due to a conflict between a recent generification in jconsole 8044865: Fix raw and unchecked lint warnings in management-related code http://hg.openjdk.java.net/jdk9/dev/jdk/rev/81e22723ba57 and the newly generified swing. Fortunately, the adjustment in jconsole to be reviewed is simple: --- a/src/share/classes/sun/tools/jconsole/inspector/TableSorter.java Tue Jul 01 23:09:52 2014 +0000 +++ b/src/share/classes/sun/tools/jconsole/inspector/TableSorter.java Thu Jul 03 12:09:44 2014 -0700 @@ -217,17 +217,17 @@ } } - private Vector getRow(int row) { - return (Vector) dataVector.elementAt(row); + private Vector getRow(int row) { + return dataVector.elementAt(row); } @SuppressWarnings("unchecked") - private void setRow(Vector data, int row) { + private void setRow(Vector data, int row) { dataVector.setElementAt(data,row); } private void swap(int i, int j, int column) { - Vector data = getRow(i); + Vector data = getRow(i); setRow(getRow(j),i); setRow(data,j); The protected dataVector field is now declared to be a Vector> so the more precise type can be used in these private methods. Thanks, -Joe From jeffhain at rocketmail.com Thu Jul 3 19:59:42 2014 From: jeffhain at rocketmail.com (Jeff Hain) Date: Thu, 3 Jul 2014 20:59:42 +0100 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53B5B11B.9030602@oracle.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> Message-ID: <1404417582.51503.YahooMailNeo@web172403.mail.ir2.yahoo.com> >http://cr.openjdk.java.net/~igerasim/6904367/1/webrev/ My test now terminates (exception on MAX_CAPACITY-th put). Maybe where MAX_CAPACITY is defined you could indicate that you can actually have at most MAX_CAPACITY-1 mappings, to ensure that the table always contains some null key-spot (I don't see this invariant explicited already). -Jeff From mandy.chung at oracle.com Thu Jul 3 20:20:46 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 03 Jul 2014 13:20:46 -0700 Subject: Supplemental code review request for JDK-8043550: Fix raw and unchecked lint warnings in javax.swing.* In-Reply-To: <53B5B2AD.3040803@oracle.com> References: <53B5B2AD.3040803@oracle.com> Message-ID: <53B5BB1E.5070501@oracle.com> I reviewed the jconsole change that looks okay to me. Mandy On 7/3/14 12:44 PM, Joe Darcy wrote: > Hello, > > In the course of fixing > > JDK-8043550: Fix raw and unchecked lint warnings in javax.swing.* > http://cr.openjdk.java.net/~darcy/8043550.1/ > > I encountered a build failure in jconsole due to a conflict between a > recent generification in jconsole > > 8044865: Fix raw and unchecked lint warnings in management-related > code > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/81e22723ba57 > > and the newly generified swing. Fortunately, the adjustment in > jconsole to be reviewed is simple: > > --- a/src/share/classes/sun/tools/jconsole/inspector/TableSorter.java > Tue Jul 01 23:09:52 2014 +0000 > +++ b/src/share/classes/sun/tools/jconsole/inspector/TableSorter.java > Thu Jul 03 12:09:44 2014 -0700 > @@ -217,17 +217,17 @@ > } > } > > - private Vector getRow(int row) { > - return (Vector) dataVector.elementAt(row); > + private Vector getRow(int row) { > + return dataVector.elementAt(row); > } > > @SuppressWarnings("unchecked") > - private void setRow(Vector data, int row) { > + private void setRow(Vector data, int row) { > dataVector.setElementAt(data,row); > } > > private void swap(int i, int j, int column) { > - Vector data = getRow(i); > + Vector data = getRow(i); > setRow(getRow(j),i); > setRow(data,j); > > > The protected dataVector field is now declared to be a > Vector> so the more precise type can be used in these > private methods. > > Thanks, > > -Joe From stuart.marks at oracle.com Thu Jul 3 21:08:32 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 03 Jul 2014 14:08:32 -0700 Subject: RFR 8043328 and 8043327: errors in stream docs In-Reply-To: <079A9673-F0D8-4385-BE8C-A1F8A4E26899@oracle.com> References: <6BD5BE4B-3FA1-406F-ADEB-99B0626B7BAC@oracle.com> <53B459F6.4070809@oracle.com> <2409F27E-2172-417E-B58C-93BE87BE35E2@oracle.com> <53B53915.2070505@oracle.com> <079A9673-F0D8-4385-BE8C-A1F8A4E26899@oracle.com> Message-ID: <53B5C650.8080204@oracle.com> On 7/3/14 5:03 AM, Paul Sandoz wrote: > > On Jul 3, 2014, at 1:05 PM, Ivan Gerasimov wrote: > >> Paul, would you please include a few more typo fixes, if it's not too late? >> > > Thanks for doing this, the changes look good. > > Unfortunately it's too late for this bug, but i will merge it into the patch for: > > 8044047: Missing null pointer checks for streams > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-July/027514.html Is merging these with 8044047 a good idea? We might want to backport the javadoc changes but not the code changes, and mixing them will make this harder. Ivan, that was a good set of of patches; well spotted. I didn't realize that that there were so many little errors, including repetitions of of words! s'marks From ecki at zusammenkunft.net Fri Jul 4 00:01:02 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 4 Jul 2014 02:01:02 +0200 Subject: AbstractStringBuilder::append less inlined? Message-ID: <20140704020102.00002bb1.ecki@zusammenkunft.net> Hello, in Java7 (U51 in this case) I do some testing with print inlining, and I noticed that all possible executions of AbstractStringBuilder::append had been inlined (hot) in thise tests. Opposed to that I see a lot of too big messages for Java 8. I wonder if this is known/intentional? (The tests do run faster on 8, so its not a real problem). Java7 xxx java.lang.AbstractStringBuilder::append (48 bytes) inline (hot) and for Java8 (U5, 64bit Windows) java.lang.AbstractStringBuilder::append (50 bytes) callee is too large Greetings Bernd From vitalyd at gmail.com Fri Jul 4 00:09:13 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 3 Jul 2014 20:09:13 -0400 Subject: AbstractStringBuilder::append less inlined? In-Reply-To: <20140704020102.00002bb1.ecki@zusammenkunft.net> References: <20140704020102.00002bb1.ecki@zusammenkunft.net> Message-ID: Hi Bernd, Are you testing with tiered compilation on java 8? If so, what happens if you turn it off? Thanks Sent from my phone On Jul 3, 2014 8:01 PM, "Bernd Eckenfels" wrote: > Hello, > > in Java7 (U51 in this case) I do some testing with print inlining, > and I noticed that all possible executions of > AbstractStringBuilder::append had been inlined (hot) in thise tests. > Opposed to that I see a lot of too big messages for Java 8. I wonder if > this is known/intentional? > > (The tests do run faster on 8, so its not a real problem). > > Java7 > > xxx java.lang.AbstractStringBuilder::append (48 bytes) inline (hot) > > and for Java8 (U5, 64bit Windows) > > java.lang.AbstractStringBuilder::append (50 bytes) callee is too large > > Greetings > Bernd > From rednaxelafx at gmail.com Fri Jul 4 00:13:20 2014 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 3 Jul 2014 17:13:20 -0700 Subject: AbstractStringBuilder::append less inlined? In-Reply-To: References: <20140704020102.00002bb1.ecki@zusammenkunft.net> Message-ID: Hi Bernd, I agree with Vitaly. Tiered compilation may well be the reason you're seeing different logging -- in other words, your test is probably too short so that when tiered compilation is turned on, you're only seeing C1's compilation logs, and C2 compilation hasn't happened yet. Try turning on -XX:+TieredCompilation on JDK7u and turning it off on JDK8 for comparison :-) - Kris On Thu, Jul 3, 2014 at 5:09 PM, Vitaly Davidovich wrote: > Hi Bernd, > > Are you testing with tiered compilation on java 8? If so, what happens if > you turn it off? > > Thanks > > Sent from my phone > On Jul 3, 2014 8:01 PM, "Bernd Eckenfels" wrote: > > > Hello, > > > > in Java7 (U51 in this case) I do some testing with print inlining, > > and I noticed that all possible executions of > > AbstractStringBuilder::append had been inlined (hot) in thise tests. > > Opposed to that I see a lot of too big messages for Java 8. I wonder if > > this is known/intentional? > > > > (The tests do run faster on 8, so its not a real problem). > > > > Java7 > > > > xxx java.lang.AbstractStringBuilder::append (48 bytes) inline (hot) > > > > and for Java8 (U5, 64bit Windows) > > > > java.lang.AbstractStringBuilder::append (50 bytes) callee is too large > > > > Greetings > > Bernd > > > From david.holmes at oracle.com Fri Jul 4 04:14:20 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 04 Jul 2014 14:14:20 +1000 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53B5B11B.9030602@oracle.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> Message-ID: <53B62A1C.2040605@oracle.com> Hi Ivan, I find the change to capacity somewhat obfuscating and I can't see what the actual bug was. The recursive call to put after a resize seems very sub-optimal as you will re-search the map for the non-existent key. Can you not just recompute the correct indices and do the store? Alternatively use the original code and if an exception occurs on resize then simply undo the "put". I'm always worried that inverting the behaviour like you will have some unexpected side effect somewhere - this code has been like this for a very, very long time. Cheers, David On 4/07/2014 5:38 AM, Ivan Gerasimov wrote: > Thank you Jeff! > > > On 03.07.2014 23:07, Jeff Hain wrote: >> >> Hi. >> >> >> >WEBREV: http://cr.openjdk.java.net/~igerasim/6904367/0/webrev/ >> >> >> The "while" loop in put(...) supposes that there is at least one free >> slot, >> which was the case before (that could be added as comment). >> >> Now if you try to go past max capacity, instead of getting an >> IllegalStateException, >> you get an infinite loop. >> > Yes, you're right! > >> It's easy to test with a loop of 1000 puts and MAX_CAPACITY = 1<<8 >> (=256, needs to be larger than DEFAULT_CAPACITY, else it can be >> "ignored"). >> With previous version you get IllegalStateException on trying to add >> 255th mapping >> (on the resize that occurs when just-after-put-size is 255 >= >> threshold = 255), >> and with new version you get infinite loop on trying to add 257th >> mapping. >> >> Solutions I see would be adding a throw if size >= MAX_CAPACITY >> before the loop, >> > This would break the case when an existing key is added to the already > full table. > Moreover, the full table without a single empty slot could cause an > infinite looping in get(), remove(), etc. > >> or not adding that overhead and instead throwing when >> "size >= MAX_CAPACITY-1" instead of when "size >= MAX_CAPACITY". >> > > This seems appropriate. > With the current implementation we can only put MAX_CAPACITY-1 elements > anyway. > >> I would also rather use "==" over ">=" for these tests, to underline >> the fact >> that size is not supposed to be larger, but there might be some >> reasons not to. >> > I think it makes the code a bit more stable from the perspective of the > future changes. > > Here's the updated webrev: > http://cr.openjdk.java.net/~igerasim/6904367/1/webrev/ > > Sincerely yours, > Ivan > > >> >> -Jeff >> >> >> > From evgeniya.stepanova at oracle.com Fri Jul 4 07:37:42 2014 From: evgeniya.stepanova at oracle.com (Evgeniya Stepanova) Date: Fri, 04 Jul 2014 11:37:42 +0400 Subject: 8049055: Tests added to the jdk/test/TEST.groups to be run on correct profiles Message-ID: <53B659C6.1030504@oracle.com> Hi all Could you please review fix for 8049055 Problem: java/util/logging/TestLoggingWithMainAppContext.java is designed to use awt,which is in full jre javax/xml/ws/clientjar/TestWsImport.java tests API that is only in full jre Tests were running on compacts and failed. Solution: Both tests are added to the needs_jre test group in jdk/test/TEST.groups Testing: locally,tests excluded as expected In attachements diff against 8udev repo Thank you. Evgeniya Stepanova From paul.sandoz at oracle.com Fri Jul 4 07:39:18 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 4 Jul 2014 09:39:18 +0200 Subject: RFR 8043328 and 8043327: errors in stream docs In-Reply-To: <53B5C650.8080204@oracle.com> References: <6BD5BE4B-3FA1-406F-ADEB-99B0626B7BAC@oracle.com> <53B459F6.4070809@oracle.com> <2409F27E-2172-417E-B58C-93BE87BE35E2@oracle.com> <53B53915.2070505@oracle.com> <079A9673-F0D8-4385-BE8C-A1F8A4E26899@oracle.com> <53B5C650.8080204@oracle.com> Message-ID: On Jul 3, 2014, at 11:08 PM, Stuart Marks wrote: > On 7/3/14 5:03 AM, Paul Sandoz wrote: >> >> On Jul 3, 2014, at 1:05 PM, Ivan Gerasimov wrote: >> >>> Paul, would you please include a few more typo fixes, if it's not too late? >>> >> >> Thanks for doing this, the changes look good. >> >> Unfortunately it's too late for this bug, but i will merge it into the patch for: >> >> 8044047: Missing null pointer checks for streams >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-July/027514.html > > Is merging these with 8044047 a good idea? We might want to backport the javadoc changes but not the code changes, and mixing them will make this harder. > I planned to backport the code changes as well, they are trivial. If you would be so kind to review those changes for 8044047 i can backport that and all the docs bugs rather quickly. > Ivan, that was a good set of of patches; well spotted. I didn't realize that that there were so many little errors, including repetitions of of words! > That was most likely me, i have a terrible habit of of doing that. Paul. From evgeniya.stepanova at oracle.com Fri Jul 4 09:33:42 2014 From: evgeniya.stepanova at oracle.com (Evgeniya Stepanova) Date: Fri, 04 Jul 2014 13:33:42 +0400 Subject: 8049055: Tests added to the jdk/test/TEST.groups to be run on correct profiles In-Reply-To: <53B659C6.1030504@oracle.com> References: <53B659C6.1030504@oracle.com> Message-ID: <53B674F6.3010707@oracle.com> Re-attached lost diff Also, just for sure, diff as plain text (really small) diff -r fafb06b35f05 test/TEST.groups --- a/test/TEST.groups Sun Jun 22 18:50:35 2014 -0400 +++ b/test/TEST.groups Thu Jul 03 16:23:05 2014 +0400 @@ -369,7 +369,9 @@ javax/crypto/Cipher/CipherStreamClose.java \ javax/management/monitor/AttributeArbitraryDataTypeTest.java \ jdk/lambda/vm/InterfaceAccessFlagsTest.java \ - sun/misc/URLClassPath/ClassnameCharTest.java + sun/misc/URLClassPath/ClassnameCharTest.java \ + java/util/logging/TestLoggingWithMainAppContext.java \ + javax/xml/ws/clientjar/TestWsImport.java # Tests dependent on the optional charsets.jar # These are isolated for easy exclusions On 04.07.2014 11:37, Evgeniya Stepanova wrote: > Hi all > > Could you please review fix for 8049055 > > Problem: > java/util/logging/TestLoggingWithMainAppContext.java is designed to > use awt,which is in full jre > javax/xml/ws/clientjar/TestWsImport.java tests API that is only in > full jre > Tests were running on compacts and failed. > Solution: > Both tests are added to the needs_jre test group in jdk/test/TEST.groups > Testing: > locally,tests excluded as expected > > In attachements diff against 8udev repo > > Thank you. > Evgeniya Stepanova -- /Evgeniya Stepanova/ -------------- next part -------------- diff -r fafb06b35f05 test/TEST.groups --- a/test/TEST.groups Sun Jun 22 18:50:35 2014 -0400 +++ b/test/TEST.groups Thu Jul 03 16:23:05 2014 +0400 @@ -369,7 +369,9 @@ javax/crypto/Cipher/CipherStreamClose.java \ javax/management/monitor/AttributeArbitraryDataTypeTest.java \ jdk/lambda/vm/InterfaceAccessFlagsTest.java \ - sun/misc/URLClassPath/ClassnameCharTest.java + sun/misc/URLClassPath/ClassnameCharTest.java \ + java/util/logging/TestLoggingWithMainAppContext.java \ + javax/xml/ws/clientjar/TestWsImport.java # Tests dependent on the optional charsets.jar # These are isolated for easy exclusions From daniel.fuchs at oracle.com Fri Jul 4 09:57:43 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 04 Jul 2014 11:57:43 +0200 Subject: 8049055: Tests added to the jdk/test/TEST.groups to be run on correct profiles In-Reply-To: <53B674F6.3010707@oracle.com> References: <53B659C6.1030504@oracle.com> <53B674F6.3010707@oracle.com> Message-ID: <53B67A97.5090500@oracle.com> Hi Evgeniya, This looks OK for java/util/logging/TestLoggingWithMainAppContext.java, but by looking at javax/xml/ws/clientjar/TestWsImport.java I get the impression that this tests depends on the jdk, rather than on the JRE: public class TestWsImport { public static void main(String[] args) throws IOException { String javaHome = System.getProperty("java.home"); if (javaHome.endsWith("jre")) { javaHome = new File(javaHome).getParent(); } String wsimport = javaHome + File.separator + "bin" + File.separator + "wsimport"; ... } So I wonder whether this one should be added to the needs_jdk list instead? best regards, -- daniel On 7/4/14 11:33 AM, Evgeniya Stepanova wrote: > Re-attached lost diff > > Also, just for sure, diff as plain text (really small) > > diff -r fafb06b35f05 test/TEST.groups > --- a/test/TEST.groups Sun Jun 22 18:50:35 2014 -0400 > +++ b/test/TEST.groups Thu Jul 03 16:23:05 2014 +0400 > @@ -369,7 +369,9 @@ > javax/crypto/Cipher/CipherStreamClose.java \ > javax/management/monitor/AttributeArbitraryDataTypeTest.java \ > jdk/lambda/vm/InterfaceAccessFlagsTest.java \ > - sun/misc/URLClassPath/ClassnameCharTest.java > + sun/misc/URLClassPath/ClassnameCharTest.java \ > + java/util/logging/TestLoggingWithMainAppContext.java \ > + javax/xml/ws/clientjar/TestWsImport.java > > # Tests dependent on the optional charsets.jar > # These are isolated for easy exclusions > > On 04.07.2014 11:37, Evgeniya Stepanova wrote: >> Hi all >> >> Could you please review fix for 8049055 >> >> Problem: >> java/util/logging/TestLoggingWithMainAppContext.java is designed to >> use awt,which is in full jre >> javax/xml/ws/clientjar/TestWsImport.java tests API that is only in >> full jre >> Tests were running on compacts and failed. >> Solution: >> Both tests are added to the needs_jre test group in jdk/test/TEST.groups >> Testing: >> locally,tests excluded as expected >> >> In attachements diff against 8udev repo >> >> Thank you. >> Evgeniya Stepanova > From evgeniya.stepanova at oracle.com Fri Jul 4 10:21:10 2014 From: evgeniya.stepanova at oracle.com (Evgeniya Stepanova) Date: Fri, 04 Jul 2014 14:21:10 +0400 Subject: 8049055: Tests added to the jdk/test/TEST.groups to be run on correct profiles In-Reply-To: <53B67A97.5090500@oracle.com> References: <53B659C6.1030504@oracle.com> <53B674F6.3010707@oracle.com> <53B67A97.5090500@oracle.com> Message-ID: <53B68016.4010106@oracle.com> Daniel, you are right. Test fail on jre Test removed from needs_jre group and added to the needs_jdk one New diff attached Thank you! On 04.07.2014 13:57, Daniel Fuchs wrote: > Hi Evgeniya, > > This looks OK for java/util/logging/TestLoggingWithMainAppContext.java, > but by looking at javax/xml/ws/clientjar/TestWsImport.java I get > the impression that this tests depends on the jdk, rather > than on the JRE: > > public class TestWsImport { > > public static void main(String[] args) throws IOException { > > String javaHome = System.getProperty("java.home"); > if (javaHome.endsWith("jre")) { > javaHome = new File(javaHome).getParent(); > } > String wsimport = javaHome + File.separator + "bin" > + File.separator + "wsimport"; > ... > } > > So I wonder whether this one should be added to the needs_jdk > list instead? > > best regards, > > -- daniel > > > > On 7/4/14 11:33 AM, Evgeniya Stepanova wrote: >> Re-attached lost diff >> >> Also, just for sure, diff as plain text (really small) >> >> diff -r fafb06b35f05 test/TEST.groups >> --- a/test/TEST.groups Sun Jun 22 18:50:35 2014 -0400 >> +++ b/test/TEST.groups Thu Jul 03 16:23:05 2014 +0400 >> @@ -369,7 +369,9 @@ >> javax/crypto/Cipher/CipherStreamClose.java \ >> javax/management/monitor/AttributeArbitraryDataTypeTest.java \ >> jdk/lambda/vm/InterfaceAccessFlagsTest.java \ >> - sun/misc/URLClassPath/ClassnameCharTest.java >> + sun/misc/URLClassPath/ClassnameCharTest.java \ >> + java/util/logging/TestLoggingWithMainAppContext.java \ >> + javax/xml/ws/clientjar/TestWsImport.java >> >> # Tests dependent on the optional charsets.jar >> # These are isolated for easy exclusions >> >> On 04.07.2014 11:37, Evgeniya Stepanova wrote: >>> Hi all >>> >>> Could you please review fix for 8049055 >>> >>> Problem: >>> java/util/logging/TestLoggingWithMainAppContext.java is designed to >>> use awt,which is in full jre >>> javax/xml/ws/clientjar/TestWsImport.java tests API that is only in >>> full jre >>> Tests were running on compacts and failed. >>> Solution: >>> Both tests are added to the needs_jre test group in >>> jdk/test/TEST.groups >>> Testing: >>> locally,tests excluded as expected >>> >>> In attachements diff against 8udev repo >>> >>> Thank you. >>> Evgeniya Stepanova >> > -- /Evgeniya Stepanova/ -------------- next part -------------- diff -r fafb06b35f05 test/TEST.groups --- a/test/TEST.groups Sun Jun 22 18:50:35 2014 -0400 +++ b/test/TEST.groups Fri Jul 04 14:10:10 2014 +0400 @@ -332,7 +332,8 @@ sun/reflect/CallerSensitive/CallerSensitiveFinder.java \ sun/reflect/CallerSensitive/MissingCallerSensitive.java \ sun/security/util/Resources/NewNamesFormat.java \ - vm/verifier/defaultMethods/DefaultMethodRegressionTestsRun.java + vm/verifier/defaultMethods/DefaultMethodRegressionTestsRun.java \ + javax/xml/ws/clientjar/TestWsImport.java # JRE adds further tests to compact3 # @@ -369,7 +370,8 @@ javax/crypto/Cipher/CipherStreamClose.java \ javax/management/monitor/AttributeArbitraryDataTypeTest.java \ jdk/lambda/vm/InterfaceAccessFlagsTest.java \ - sun/misc/URLClassPath/ClassnameCharTest.java + sun/misc/URLClassPath/ClassnameCharTest.java \ + java/util/logging/TestLoggingWithMainAppContext.java # Tests dependent on the optional charsets.jar # These are isolated for easy exclusions From daniel.fuchs at oracle.com Fri Jul 4 10:25:54 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 04 Jul 2014 12:25:54 +0200 Subject: 8049055: Tests added to the jdk/test/TEST.groups to be run on correct profiles In-Reply-To: <53B68016.4010106@oracle.com> References: <53B659C6.1030504@oracle.com> <53B674F6.3010707@oracle.com> <53B67A97.5090500@oracle.com> <53B68016.4010106@oracle.com> Message-ID: <53B68132.5030302@oracle.com> On 7/4/14 12:21 PM, Evgeniya Stepanova wrote: > Daniel, you are right. Test fail on jre > Test removed from needs_jre group and added to the needs_jdk one > New diff attached > Thank you! The new diff looks good! -- daniel > > > > On 04.07.2014 13:57, Daniel Fuchs wrote: >> Hi Evgeniya, >> >> This looks OK for java/util/logging/TestLoggingWithMainAppContext.java, >> but by looking at javax/xml/ws/clientjar/TestWsImport.java I get >> the impression that this tests depends on the jdk, rather >> than on the JRE: >> >> public class TestWsImport { >> >> public static void main(String[] args) throws IOException { >> >> String javaHome = System.getProperty("java.home"); >> if (javaHome.endsWith("jre")) { >> javaHome = new File(javaHome).getParent(); >> } >> String wsimport = javaHome + File.separator + "bin" >> + File.separator + "wsimport"; >> ... >> } >> >> So I wonder whether this one should be added to the needs_jdk >> list instead? >> >> best regards, >> >> -- daniel >> >> >> >> On 7/4/14 11:33 AM, Evgeniya Stepanova wrote: >>> Re-attached lost diff >>> >>> Also, just for sure, diff as plain text (really small) >>> >>> diff -r fafb06b35f05 test/TEST.groups >>> --- a/test/TEST.groups Sun Jun 22 18:50:35 2014 -0400 >>> +++ b/test/TEST.groups Thu Jul 03 16:23:05 2014 +0400 >>> @@ -369,7 +369,9 @@ >>> javax/crypto/Cipher/CipherStreamClose.java \ >>> javax/management/monitor/AttributeArbitraryDataTypeTest.java \ >>> jdk/lambda/vm/InterfaceAccessFlagsTest.java \ >>> - sun/misc/URLClassPath/ClassnameCharTest.java >>> + sun/misc/URLClassPath/ClassnameCharTest.java \ >>> + java/util/logging/TestLoggingWithMainAppContext.java \ >>> + javax/xml/ws/clientjar/TestWsImport.java >>> >>> # Tests dependent on the optional charsets.jar >>> # These are isolated for easy exclusions >>> >>> On 04.07.2014 11:37, Evgeniya Stepanova wrote: >>>> Hi all >>>> >>>> Could you please review fix for 8049055 >>>> >>>> Problem: >>>> java/util/logging/TestLoggingWithMainAppContext.java is designed to >>>> use awt,which is in full jre >>>> javax/xml/ws/clientjar/TestWsImport.java tests API that is only in >>>> full jre >>>> Tests were running on compacts and failed. >>>> Solution: >>>> Both tests are added to the needs_jre test group in >>>> jdk/test/TEST.groups >>>> Testing: >>>> locally,tests excluded as expected >>>> >>>> In attachements diff against 8udev repo >>>> >>>> Thank you. >>>> Evgeniya Stepanova >>> >> > > -- > /Evgeniya Stepanova/ From paul.sandoz at oracle.com Fri Jul 4 14:54:30 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 4 Jul 2014 16:54:30 +0200 Subject: RFR 8049220: URL.factory data race In-Reply-To: <53B585EB.9060807@oracle.com> References: <53B517CF.6060006@gmail.com> <53B585EB.9060807@oracle.com> Message-ID: On Jul 3, 2014, at 6:33 PM, Alan Bateman wrote: > On 03/07/2014 09:43, Peter Levart wrote: >> Hi, >> >> I noticed a data race in java.net.URL: >> >> https://bugs.openjdk.java.net/browse/JDK-8049220 >> >> I propose the following simple patch: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/URL.factory/webrev.01/ >> > A good catch and the change looks good to me. Yes, well spotted. May i suggest that the following comment is updated: 1109 factory = fac; // volatile write to say something about ensuring safe publication of a constructed handle? since it is often quite tricky to reason about why a volatile write is needed (to stamp in, at least, a StoreStore barrier). For JMM v9 we may not need to mark such a ref as volatile. > I assume it just wasn't noticed because it can only be set once and probably rared used too. > Yeah, i wonder whether it would ever get optimized/inlined to the point at which re-ordering could practically happen. Paul. From Alan.Bateman at oracle.com Fri Jul 4 16:35:09 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 04 Jul 2014 17:35:09 +0100 Subject: RFR: 8048020 - Regression on java.util.logging.FileHandler In-Reply-To: <53B27E8D.30405@oracle.com> References: , <53A9C4C6.3060405@oracle.com> <53B27E8D.30405@oracle.com> Message-ID: <53B6D7BD.1040606@oracle.com> On 01/07/2014 10:25, Daniel Fuchs wrote: > > Hi Jason, Alan, > > Here is an updated version of the fix that does a bounded > retry (retries once - and if it fails, proceeds with the next > name). I have also added NO_FOLLOW_LINKS - for the case where > we try to open an existing Lockfile, and suppressed the > Files.isWritable check since that will be taken care of by > the call to FileChannel.open. > > http://cr.openjdk.java.net/~dfuchs/webrev_8048020/webrev.01/ > > I also updated the comments to make it clear that the > file could not have been locked by another instance > of FileHandler (since that would have been taken care > of by our global 'locks' synchronization). > > best regards, > > -- daniel This looks okay to me except for the zombie file case. I think I missed the reason for using APPEND. Also you catch FileNotFoundException (which is not thrown by FileChannel.open) so I wonder if you mean to catch IOException so that you handle all possible I/O exceptions. If you meant IOException to handle any error then the isWritable on the parent directory isn't needed (we can make the isRegularFile check go away too if you want). In the test case then the the use of getAbsolutePath seems redundant. Also just to mention that setup method could use Files.createTempDirectory. -Alan From daniel.fuchs at oracle.com Fri Jul 4 17:25:14 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 04 Jul 2014 19:25:14 +0200 Subject: RFR: 8048020 - Regression on java.util.logging.FileHandler In-Reply-To: <53B6D7BD.1040606@oracle.com> References: , <53A9C4C6.3060405@oracle.com> <53B27E8D.30405@oracle.com> <53B6D7BD.1040606@oracle.com> Message-ID: <53B6E37A.7050506@oracle.com> On 7/4/14 6:35 PM, Alan Bateman wrote: > On 01/07/2014 10:25, Daniel Fuchs wrote: >> >> Hi Jason, Alan, >> >> Here is an updated version of the fix that does a bounded >> retry (retries once - and if it fails, proceeds with the next >> name). I have also added NO_FOLLOW_LINKS - for the case where >> we try to open an existing Lockfile, and suppressed the >> Files.isWritable check since that will be taken care of by >> the call to FileChannel.open. >> >> http://cr.openjdk.java.net/~dfuchs/webrev_8048020/webrev.01/ >> >> I also updated the comments to make it clear that the >> file could not have been locked by another instance >> of FileHandler (since that would have been taken care >> of by our global 'locks' synchronization). >> >> best regards, >> >> -- daniel > This looks okay to me except for the zombie file case. I think I > missed the reason for using APPEND. Given that nothing is going to be written to the file then maybe I don't need APPEND. I just don't want the call to FileChannel.open() to truncate the file. > Also you catch FileNotFoundException (which is not thrown by > FileChannel.open) oh? What will FileChannel.open throw if the file does not exist then? Is there another exception? Or do you mean it's not possible to know why FileChannel.open fails? That would be bad... > so I wonder if you mean to catch IOException so that you handle all > possible I/O exceptions. If you meant IOException to handle any error > then the isWritable on the parent directory isn't needed (we can make > the isRegularFile check go away too if you want). No I just want to catch the case where the file does not exist. > > In the test case then the the use of getAbsolutePath seems redundant. > Also just to mention that setup method could use > Files.createTempDirectory. The test has several @run lines and depends on the lines to be invoked in sequence. In particular this sequence: 32 * @run main/othervm CheckZombieLockTest CLEANUP 33 * @run main/othervm CheckZombieLockTest WRITABLE 34 * @run main/othervm CheckZombieLockTest CREATE_FIRST 35 * @run main/othervm CheckZombieLockTest CREATE_NEXT 36 * @run main/othervm CheckZombieLockTest CREATE_NEXT 37 * @run main/othervm CheckZombieLockTest CLEANUP where it is important that the directory *is not* deleted between two invocations. The CLEANUP action will delete the directory if everything goes well, and the try { } catch { } in main will take care of it if the test fails... -- daniel > > -Alan > From ivan.gerasimov at oracle.com Fri Jul 4 17:33:57 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 04 Jul 2014 21:33:57 +0400 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53B62A1C.2040605@oracle.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> Message-ID: <53B6E585.1090303@oracle.com> Thanks David for looking at the change! On 04.07.2014 8:14, David Holmes wrote: > Hi Ivan, > > I find the change to capacity somewhat obfuscating and I can't see > what the actual bug was. > The bug was in rounding in the expression minCapacity = (3 * expectedMaxSize)/2. Suppose, we want the expected size to be 11, then minCapacity becomes (int)(11 * 3 / 2) == 16. The threshold is calculated later to be (int)(16 * 2 / 3) == 10, which is less than expected size 11. To address the issue I combined the division by 2 with the rounding up to the nearest power of two. I also took a chance to replace a while-loop with a single call to the highestOneBit method, which calculates exactly what we need here. > The recursive call to put after a resize seems very sub-optimal as you > will re-search the map for the non-existent key. Can you not just > recompute the correct indices and do the store? > Okay, I replaced the recursive call with the index recomputation. As was suggested by Jeff, I added a comment to the MAXIMUM_CAPACITY constant. I also reverted some part of the changes to the resize() function, as it turned out that the new code failed to deal correctly with the table of maximum capacity. I wanted to add checking of this behavior to the regression test, but faced an obstacle: I used reflection to make the MAXIMUM_CAPACITY constant smaller, so it wouldn't be needed to insert 2**29 element to fill the table up. The debugger was showing that the constant was changed, but the old value was still used in the conditions. Currently I commented this test out. If anyone could suggest me how I can properly change MAXIMUM_CAPACITY in this situation, it would be very appreciated. Here is the updated webrev: http://cr.openjdk.java.net/~igerasim/6904367/2/webrev/ Would you please help review it? Sincerely yours, Ivan. > Alternatively use the original code and if an exception occurs on > resize then simply undo the "put". I'm always worried that inverting > the behaviour like you will have some unexpected side effect somewhere > - this code has been like this for a very, very long time. > > Cheers, > David > > On 4/07/2014 5:38 AM, Ivan Gerasimov wrote: >> Thank you Jeff! >> >> >> On 03.07.2014 23:07, Jeff Hain wrote: >>> >>> Hi. >>> >>> >>> >WEBREV: http://cr.openjdk.java.net/~igerasim/6904367/0/webrev/ >>> >>> >>> The "while" loop in put(...) supposes that there is at least one free >>> slot, >>> which was the case before (that could be added as comment). >>> >>> Now if you try to go past max capacity, instead of getting an >>> IllegalStateException, >>> you get an infinite loop. >>> >> Yes, you're right! >> >>> It's easy to test with a loop of 1000 puts and MAX_CAPACITY = 1<<8 >>> (=256, needs to be larger than DEFAULT_CAPACITY, else it can be >>> "ignored"). >>> With previous version you get IllegalStateException on trying to add >>> 255th mapping >>> (on the resize that occurs when just-after-put-size is 255 >= >>> threshold = 255), >>> and with new version you get infinite loop on trying to add 257th >>> mapping. >>> >>> Solutions I see would be adding a throw if size >= MAX_CAPACITY >>> before the loop, >>> >> This would break the case when an existing key is added to the already >> full table. >> Moreover, the full table without a single empty slot could cause an >> infinite looping in get(), remove(), etc. >> >>> or not adding that overhead and instead throwing when >>> "size >= MAX_CAPACITY-1" instead of when "size >= MAX_CAPACITY". >>> >> >> This seems appropriate. >> With the current implementation we can only put MAX_CAPACITY-1 elements >> anyway. >> >>> I would also rather use "==" over ">=" for these tests, to underline >>> the fact >>> that size is not supposed to be larger, but there might be some >>> reasons not to. >>> >> I think it makes the code a bit more stable from the perspective of the >> future changes. >> >> Here's the updated webrev: >> http://cr.openjdk.java.net/~igerasim/6904367/1/webrev/ >> >> Sincerely yours, >> Ivan >> >> >>> >>> -Jeff >>> >>> >>> >> > > From Alan.Bateman at oracle.com Fri Jul 4 17:58:46 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 04 Jul 2014 18:58:46 +0100 Subject: RFR: 8048020 - Regression on java.util.logging.FileHandler In-Reply-To: <53B6E37A.7050506@oracle.com> References: , <53A9C4C6.3060405@oracle.com> <53B27E8D.30405@oracle.com> <53B6D7BD.1040606@oracle.com> <53B6E37A.7050506@oracle.com> Message-ID: <53B6EB56.5080408@oracle.com> On 04/07/2014 18:25, Daniel Fuchs wrote: > > Given that nothing is going to be written to the file then maybe I > don't need APPEND. > I just don't want the call to FileChannel.open() to truncate the file. APPEND should be harmless here, just not needed. > >> Also you catch FileNotFoundException (which is not thrown by >> FileChannel.open) > oh? What will FileChannel.open throw if the file does not exist then? > Is there another > exception? Or do you mean it's not possible to know why > FileChannel.open fails? > That would be bad... All the specific file system exceptions are defined in java.nio.file but it's not clear to me that you only want to handle NoSuchFileException. Don't you want to handle cases where the zombie file can't be opened for other reasons (file permission issues for example that would manifest as an AccessDeniedException)? -Alan. From Alan.Bateman at oracle.com Fri Jul 4 18:04:25 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 04 Jul 2014 19:04:25 +0100 Subject: Review request: 8029548 (jdeps) use @jdk.Exported to determine supported vs JDK internal API In-Reply-To: <53AB2F38.7030700@oracle.com> References: <53AB2F38.7030700@oracle.com> Message-ID: <53B6ECA9.8010203@oracle.com> On 25/06/2014 21:21, Mandy Chung wrote: > This patch is also intended to target for 8u40 backport. It fixes > the following issues: > > JDK-8029548 (jdeps) use @jdk.Exported to determine supported vs JDK > internal API > JDK-8039007 jdeps incorrectly reports javax.jnlp as JDK internal APIs > JDK-8031092 jdeps does not recognize --help option. > JDK-8048063 (jdeps) Add filtering capability > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8029548/webrev.00/ > I'm skimmed over this and it mostly looks okay. I'm not sure that I agree that JDK-8039007 is a bug, this is really just that it is missing @jdk.Exported as you noted in PlatformClassPath. The -filter options are useful but at the same time I have a concern that the number of options to jdeps is growing. -Alan. From daniel.fuchs at oracle.com Fri Jul 4 18:10:30 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 04 Jul 2014 20:10:30 +0200 Subject: RFR: 8048020 - Regression on java.util.logging.FileHandler In-Reply-To: <53B6EB56.5080408@oracle.com> References: , <53A9C4C6.3060405@oracle.com> <53B27E8D.30405@oracle.com> <53B6D7BD.1040606@oracle.com> <53B6E37A.7050506@oracle.com> <53B6EB56.5080408@oracle.com> Message-ID: <53B6EE16.3040802@oracle.com> On 7/4/14 7:58 PM, Alan Bateman wrote: > On 04/07/2014 18:25, Daniel Fuchs wrote: >> >> Given that nothing is going to be written to the file then maybe I >> don't need APPEND. >> I just don't want the call to FileChannel.open() to truncate the file. > APPEND should be harmless here, just not needed. > >> >>> Also you catch FileNotFoundException (which is not thrown by >>> FileChannel.open) >> oh? What will FileChannel.open throw if the file does not exist then? >> Is there another >> exception? Or do you mean it's not possible to know why >> FileChannel.open fails? >> That would be bad... > All the specific file system exceptions are defined in java.nio.file Argh. Thanks for pointing that out. I need NoSuchFileException, not FileNotFoundException. > but it's not clear to me that you only want to handle > NoSuchFileException. Don't you want to handle cases where the zombie > file can't be opened for other reasons (file permission issues for > example that would manifest as an AccessDeniedException)? hmmm. yes - you're right. I should catch that to and break the loop in that case. So that would become: 465 } catch (NoSuchFileException x) { 466 // Race condition - retry once, and if that 467 // fails again just try the next name in 468 // the sequence. 469 continue; 470 } catch (IOException x) { // the file may not be writable for us. // try the next name in the sequence break; } Thanks for the feedback Alan! I had missed those cases. -- daniel > > -Alan. From Alan.Bateman at oracle.com Fri Jul 4 18:24:40 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 04 Jul 2014 19:24:40 +0100 Subject: RFR: 8048020 - Regression on java.util.logging.FileHandler In-Reply-To: <53B6EE16.3040802@oracle.com> References: , <53A9C4C6.3060405@oracle.com> <53B27E8D.30405@oracle.com> <53B6D7BD.1040606@oracle.com> <53B6E37A.7050506@oracle.com> <53B6EB56.5080408@oracle.com> <53B6EE16.3040802@oracle.com> Message-ID: <53B6F168.2040604@oracle.com> On 04/07/2014 19:10, Daniel Fuchs wrote: > hmmm. yes - you're right. I should catch that to and break the loop in > that case. > So that would become: > > 465 } catch (NoSuchFileException x) { > 466 // Race condition - retry once, and if that > 467 // fails again just try the next name in > 468 // the sequence. > 469 continue; > 470 } catch (IOException x) { > // the file may not be writable for us. > // try the next name in the sequence > break; > } > > Thanks for the feedback Alan! > I had missed those cases. If that is the final change then I think I'm okay (no need to generate a new webrev). I do think it could be improved a bit more by dropping the isXXX checks but it's not important. -Alan From dl at cs.oswego.edu Fri Jul 4 19:38:34 2014 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 04 Jul 2014 15:38:34 -0400 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53B6E585.1090303@oracle.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> Message-ID: <53B702BA.9030801@cs.oswego.edu> On 07/04/2014 01:33 PM, Ivan Gerasimov wrote: > On 04.07.2014 8:14, David Holmes wrote: >> Hi Ivan, >> >> I find the change to capacity somewhat obfuscating and I can't see what the >> actual bug was. >> > The bug was in rounding in the expression minCapacity = (3 * expectedMaxSize)/2. > Suppose, we want the expected size to be 11, then minCapacity becomes (int)(11 * > 3 / 2) == 16. > The threshold is calculated later to be (int)(16 * 2 / 3) == 10, which is less > than expected size 11. So the bug report was based on someone noticing that with odd-valued sizes, the undocumented 2/3 target load was rounded down, not up, which they didn't like? I don't object to rounding it up and modernizing the size calculations to use highestOneBit, but it's a weak pretense :-) > > To address the issue I combined the division by 2 with the rounding up to the > nearest power of two. > I also took a chance to replace a while-loop with a single call to the > highestOneBit method, which calculates exactly what we need here. > >> The recursive call to put after a resize seems very sub-optimal as you will >> re-search the map for the non-existent key. Can you not just recompute the >> correct indices and do the store? The initial rationale for post-insert-resize was to avoid these issues given the need to preserve at least one empty slot. Which I expect to remain faster than pre-resize even with your modified patch. Please provide systematic performance comparisons before committing! -Doug From jeffhain at rocketmail.com Fri Jul 4 23:59:42 2014 From: jeffhain at rocketmail.com (Jeff Hain) Date: Sat, 5 Jul 2014 00:59:42 +0100 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53B6E585.1090303@oracle.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> Message-ID: <1404518382.86164.YahooMailNeo@web172401.mail.ir2.yahoo.com> >Here is the updated webrev: >http://cr.openjdk.java.net/~igerasim/6904367/2/webrev/ There is another bug with the initial implementation: if put throws, the element is still put (and the size incremented accordingly), and if putting a new mapping after the throwing one, the table gets full and get()/put()/remove() become subject to infinite loop. (and my idea that size was not supposed to go past MAX_CAPACITY was false in that case :-) With the new implementation, if put throws, the map is not modified (not even modCount) so it doesn't get broken. For performance, maybe isolating the code in the "if" in a "int resizeAndPut(Object k, Object item, int len, int i) {...}" method would help, reducing put() bytecode size. Having put() find the last free slots in an almost-full table would most often require a lot of time, so I wonder if anyone would have hit any of these infinite loops in practice. -Jeff From david.holmes at oracle.com Sat Jul 5 03:01:50 2014 From: david.holmes at oracle.com (David Holmes) Date: Sat, 05 Jul 2014 13:01:50 +1000 Subject: 8049055: Tests added to the jdk/test/TEST.groups to be run on correct profiles In-Reply-To: <53B68016.4010106@oracle.com> References: <53B659C6.1030504@oracle.com> <53B674F6.3010707@oracle.com> <53B67A97.5090500@oracle.com> <53B68016.4010106@oracle.com> Message-ID: <53B76A9E.9050407@oracle.com> On 4/07/2014 8:21 PM, Evgeniya Stepanova wrote: > Daniel, you are right. Test fail on jre Yes wsimport is a JDK binary. > Test removed from needs_jre group and added to the needs_jdk one Looks okay to me. I'll sponsor this for into jdk9/dev/jdk and then arrange the backport for 8u. David ----- > New diff attached > Thank you! > > > > On 04.07.2014 13:57, Daniel Fuchs wrote: >> Hi Evgeniya, >> >> This looks OK for java/util/logging/TestLoggingWithMainAppContext.java, >> but by looking at javax/xml/ws/clientjar/TestWsImport.java I get >> the impression that this tests depends on the jdk, rather >> than on the JRE: >> >> public class TestWsImport { >> >> public static void main(String[] args) throws IOException { >> >> String javaHome = System.getProperty("java.home"); >> if (javaHome.endsWith("jre")) { >> javaHome = new File(javaHome).getParent(); >> } >> String wsimport = javaHome + File.separator + "bin" >> + File.separator + "wsimport"; >> ... >> } >> >> So I wonder whether this one should be added to the needs_jdk >> list instead? >> >> best regards, >> >> -- daniel >> >> >> >> On 7/4/14 11:33 AM, Evgeniya Stepanova wrote: >>> Re-attached lost diff >>> >>> Also, just for sure, diff as plain text (really small) >>> >>> diff -r fafb06b35f05 test/TEST.groups >>> --- a/test/TEST.groups Sun Jun 22 18:50:35 2014 -0400 >>> +++ b/test/TEST.groups Thu Jul 03 16:23:05 2014 +0400 >>> @@ -369,7 +369,9 @@ >>> javax/crypto/Cipher/CipherStreamClose.java \ >>> javax/management/monitor/AttributeArbitraryDataTypeTest.java \ >>> jdk/lambda/vm/InterfaceAccessFlagsTest.java \ >>> - sun/misc/URLClassPath/ClassnameCharTest.java >>> + sun/misc/URLClassPath/ClassnameCharTest.java \ >>> + java/util/logging/TestLoggingWithMainAppContext.java \ >>> + javax/xml/ws/clientjar/TestWsImport.java >>> >>> # Tests dependent on the optional charsets.jar >>> # These are isolated for easy exclusions >>> >>> On 04.07.2014 11:37, Evgeniya Stepanova wrote: >>>> Hi all >>>> >>>> Could you please review fix for 8049055 >>>> >>>> Problem: >>>> java/util/logging/TestLoggingWithMainAppContext.java is designed to >>>> use awt,which is in full jre >>>> javax/xml/ws/clientjar/TestWsImport.java tests API that is only in >>>> full jre >>>> Tests were running on compacts and failed. >>>> Solution: >>>> Both tests are added to the needs_jre test group in >>>> jdk/test/TEST.groups >>>> Testing: >>>> locally,tests excluded as expected >>>> >>>> In attachements diff against 8udev repo >>>> >>>> Thank you. >>>> Evgeniya Stepanova >>> >> > From david.holmes at oracle.com Sat Jul 5 03:19:07 2014 From: david.holmes at oracle.com (David Holmes) Date: Sat, 05 Jul 2014 13:19:07 +1000 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53B6E585.1090303@oracle.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> Message-ID: <53B76EAB.3070108@oracle.com> Ivan, Fields like MAXIMUM_CAPACITY are compile-time constants. Their values are placed directly into the code that uses them - there is no associated getField to load it. Hence changing the field via reflection has no affect on any existing code that references the field. I'm still uncomfortable about the scope of the changes - and Doug rightly mentions doing detailed performance runs before submitting this. I still think recovering from a post-put resize failure might be better than resizing first. David On 5/07/2014 3:33 AM, Ivan Gerasimov wrote: > Thanks David for looking at the change! > > On 04.07.2014 8:14, David Holmes wrote: >> Hi Ivan, >> >> I find the change to capacity somewhat obfuscating and I can't see >> what the actual bug was. >> > The bug was in rounding in the expression minCapacity = (3 * > expectedMaxSize)/2. > Suppose, we want the expected size to be 11, then minCapacity becomes > (int)(11 * 3 / 2) == 16. > The threshold is calculated later to be (int)(16 * 2 / 3) == 10, which > is less than expected size 11. > > To address the issue I combined the division by 2 with the rounding up > to the nearest power of two. > I also took a chance to replace a while-loop with a single call to the > highestOneBit method, which calculates exactly what we need here. > >> The recursive call to put after a resize seems very sub-optimal as you >> will re-search the map for the non-existent key. Can you not just >> recompute the correct indices and do the store? >> > Okay, I replaced the recursive call with the index recomputation. > > As was suggested by Jeff, I added a comment to the MAXIMUM_CAPACITY > constant. > > I also reverted some part of the changes to the resize() function, as it > turned out that the new code failed to deal correctly with the table of > maximum capacity. > > I wanted to add checking of this behavior to the regression test, but > faced an obstacle: I used reflection to make the MAXIMUM_CAPACITY > constant smaller, so it wouldn't be needed to insert 2**29 element to > fill the table up. The debugger was showing that the constant was > changed, but the old value was still used in the conditions. > > Currently I commented this test out. If anyone could suggest me how I > can properly change MAXIMUM_CAPACITY in this situation, it would be very > appreciated. > > Here is the updated webrev: > http://cr.openjdk.java.net/~igerasim/6904367/2/webrev/ > > Would you please help review it? > > Sincerely yours, > Ivan. > >> Alternatively use the original code and if an exception occurs on >> resize then simply undo the "put". I'm always worried that inverting >> the behaviour like you will have some unexpected side effect somewhere >> - this code has been like this for a very, very long time. >> >> Cheers, >> David >> >> On 4/07/2014 5:38 AM, Ivan Gerasimov wrote: >>> Thank you Jeff! >>> >>> >>> On 03.07.2014 23:07, Jeff Hain wrote: >>>> >>>> Hi. >>>> >>>> >>>> >WEBREV: http://cr.openjdk.java.net/~igerasim/6904367/0/webrev/ >>>> >>>> >>>> The "while" loop in put(...) supposes that there is at least one free >>>> slot, >>>> which was the case before (that could be added as comment). >>>> >>>> Now if you try to go past max capacity, instead of getting an >>>> IllegalStateException, >>>> you get an infinite loop. >>>> >>> Yes, you're right! >>> >>>> It's easy to test with a loop of 1000 puts and MAX_CAPACITY = 1<<8 >>>> (=256, needs to be larger than DEFAULT_CAPACITY, else it can be >>>> "ignored"). >>>> With previous version you get IllegalStateException on trying to add >>>> 255th mapping >>>> (on the resize that occurs when just-after-put-size is 255 >= >>>> threshold = 255), >>>> and with new version you get infinite loop on trying to add 257th >>>> mapping. >>>> >>>> Solutions I see would be adding a throw if size >= MAX_CAPACITY >>>> before the loop, >>>> >>> This would break the case when an existing key is added to the already >>> full table. >>> Moreover, the full table without a single empty slot could cause an >>> infinite looping in get(), remove(), etc. >>> >>>> or not adding that overhead and instead throwing when >>>> "size >= MAX_CAPACITY-1" instead of when "size >= MAX_CAPACITY". >>>> >>> >>> This seems appropriate. >>> With the current implementation we can only put MAX_CAPACITY-1 elements >>> anyway. >>> >>>> I would also rather use "==" over ">=" for these tests, to underline >>>> the fact >>>> that size is not supposed to be larger, but there might be some >>>> reasons not to. >>>> >>> I think it makes the code a bit more stable from the perspective of the >>> future changes. >>> >>> Here's the updated webrev: >>> http://cr.openjdk.java.net/~igerasim/6904367/1/webrev/ >>> >>> Sincerely yours, >>> Ivan >>> >>> >>>> >>>> -Jeff >>>> >>>> >>>> >>> >> >> > From ivan.gerasimov at oracle.com Sun Jul 6 03:50:26 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sun, 06 Jul 2014 07:50:26 +0400 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53B702BA.9030801@cs.oswego.edu> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> Message-ID: <53B8C782.1060009@oracle.com> Thank you Doug for your comment! On 04.07.2014 23:38, Doug Lea wrote: > On 07/04/2014 01:33 PM, Ivan Gerasimov wrote: >> On 04.07.2014 8:14, David Holmes wrote: >>> Hi Ivan, >>> >>> I find the change to capacity somewhat obfuscating and I can't see >>> what the >>> actual bug was. >>> >> The bug was in rounding in the expression minCapacity = (3 * >> expectedMaxSize)/2. >> Suppose, we want the expected size to be 11, then minCapacity becomes >> (int)(11 * >> 3 / 2) == 16. >> The threshold is calculated later to be (int)(16 * 2 / 3) == 10, >> which is less >> than expected size 11. > > So the bug report was based on someone noticing that with > odd-valued sizes, the undocumented 2/3 target load was > rounded down, not up, which they didn't like? > Not quite. There are two small issues that I'm trying to address here: 1) The wrong capacity is calculated based on the expected size due to rounding error. This is only noticeable for the expected sizes 11, 43, 171, 683 and a few others. This leads to a redundant table resize when inserting the expected number of elements. 2) The wrong capacity due to overflow error. For numbers N larger or equal to 1431655765, the expression (int)(N * 3) / 2 produces non-negative small numbers. Frankly speaking, this is also true for my last proposed fix, so the updated webrev will follow. 3) In put() the table gets resized as soon as the threshold is reached. This is wrong for expected sizes 2, 3, 5, 10, 21, 42, and some others. 4) If put() was unsuccessful, the map gets corrupt. > I don't object to rounding it up and modernizing the size > calculations to use highestOneBit, but it's a weak pretense :-) > Simple rounding the minimum capacity up as minCapacity = (3 * expectedMaxSize + 1)/2 would produce the same result of course. I just took a chance to replace the while loop with a single function call. In the last webrev I also modified the check to address the issue #2 from the list above. >> >> To address the issue I combined the division by 2 with the rounding >> up to the >> nearest power of two. >> I also took a chance to replace a while-loop with a single call to the >> highestOneBit method, which calculates exactly what we need here. >> >>> The recursive call to put after a resize seems very sub-optimal as >>> you will >>> re-search the map for the non-existent key. Can you not just >>> recompute the >>> correct indices and do the store? > > The initial rationale for post-insert-resize was to avoid these issues > given the need to preserve at least one empty slot. Which I > expect to remain faster than pre-resize even with your modified patch. > Please provide systematic performance comparisons before committing! > > -Doug Yes, you are right. Microbenchmark showed more than 20% slowdown of a single put operation. So, I reverted this change to the original code, but added a single check of the current table size before doing any modifications to the map. This is to address the issue #4, and this doesn't seem to introduce any significant penalty. Would you please help review the updated webrev: http://cr.openjdk.java.net/~igerasim/6904367/3/webrev/ Sincerely yours, Ivan From jeffhain at rocketmail.com Sun Jul 6 11:13:26 2014 From: jeffhain at rocketmail.com (Jeff Hain) Date: Sun, 6 Jul 2014 12:13:26 +0100 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53B8C782.1060009@oracle.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> Message-ID: <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> >So, I reverted this change to the original code, but added a single >check of the current table size before doing any modifications to the map. >This is to address the issue #4, and this doesn't seem to introduce any >significant penalty. > >Would you please help review the updated webrev: > >http://cr.openjdk.java.net/~igerasim/6904367/3/webrev/ > >Sincerely yours, > >Ivan It's possible to avoid the capacity test for the general case: put { ??? ...while loop... ??? if (size < threshold) { ? ? ??? modCount++; ? ? ? ? tab[i] = k; ??? ? ? tab[i + 1] = value; ??????? ++size; ??? } else { ??????? putAndResize(k, value, i); ??? } ??? return null; } private void putAndResize(Object k, Object value, int i) { ??? if (size == MAXIMUM_CAPACITY - 1) ??????? throw new IllegalStateException("Capacity exhausted."); ??? modCount++; ??? Object[] tab = table; ??? tab[i] = k; ??? tab[i + 1] = value; ??? ++size; ??? resize(tab.length); // len == 2 * current capacity. } It seems faster more often than not, but it adds more (and copied) code: not sure it's worth it. -Jeff From ivan.gerasimov at oracle.com Sun Jul 6 15:12:59 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sun, 06 Jul 2014 19:12:59 +0400 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> Message-ID: <53B9677B.6060806@oracle.com> Thanks for suggestion Jeff! I've tried it, but it doesn't seem to make a difference on my machine. Here are the numbers. I measured the time of a single put in nanoseconds. ----------- | vanila | fix1 | fix2 client | 8292 | 8220 | 8304 server | 8197 | 8198 | 8221 interpreter | 13980 | 14478 | 14152 fix1 - the fix from webrev #3 fix2 - the fix with your suggestion Sincerely yours, Ivan On 06.07.2014 15:13, Jeff Hain wrote: > > > >So, I reverted this change to the original code, but added a single > >check of the current table size before doing any modifications to the > map. > >This is to address the issue #4, and this doesn't seem to introduce any > >significant penalty. > > > >Would you please help review the updated webrev: > > > >http://cr.openjdk.java.net/~igerasim/6904367/3/webrev/ > > > > >Sincerely yours, > > > >Ivan > > It's possible to avoid the capacity test for the general case: > put { > ...while loop... > > if (size < threshold) { > modCount++; > tab[i] = k; > tab[i + 1] = value; > ++size; > } else { > putAndResize(k, value, i); > } > return null; > } > private void putAndResize(Object k, Object value, int i) { > if (size == MAXIMUM_CAPACITY - 1) > throw new IllegalStateException("Capacity exhausted."); > modCount++; > Object[] tab = table; > tab[i] = k; > tab[i + 1] = value; > ++size; > resize(tab.length); // len == 2 * current capacity. > } > > It seems faster more often than not, but it adds more (and copied) code: > not sure it's worth it. > > -Jeff > > From sean.coffey at oracle.com Mon Jul 7 09:49:49 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Mon, 07 Jul 2014 10:49:49 +0100 Subject: [8u-dev] Request for approval: 6545422: TEST BUG: NativeErrors.java uses wrong path name in exec In-Reply-To: <53B328F1.5070501@oracle.com> References: <530B0952.6090305@oracle.com> <530B0AE9.1070307@oracle.com> <530B0DB5.3080500@oracle.com> <53B3284E.80309@oracle.com> <53B328F1.5070501@oracle.com> Message-ID: <53BA6D3D.6060001@oracle.com> Approved. regards, Sean. On 01/07/14 22:32, Ivan Gerasimov wrote: > Corrected the subject line: I'm requesting an approval to push the fix > into jdk8u-dev repo, not jdk8u20 > > On 02.07.2014 1:29, Ivan Gerasimov wrote: >> Hello! >> >> I'm rerequesting an approval to backport this test fix into jdk8u. >> To address the issue with NoClassDefFoundError I added the implicit >> @build line to the test (as it was done in JDK-8043520). >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-6545422 >> WEBREV: http://cr.openjdk.java.net/~igerasim/6545422/0/webrev/ >> Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/efeab0eae50f >> Review: >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-February/014152.html >> >> Would you please approve the backport? >> >> Sincerely yours, >> Ivan >> >> On 24.02.2014 13:15, Ivan Gerasimov wrote: >>> >>> On 24.02.2014 13:03, Alan Bateman wrote: >>>> On 24/02/2014 08:56, Ivan Gerasimov wrote: >>>>> Hello! >>>>> >>>>> Would you please approve porting back this test bug fix? >>>>> The fix applies cleanly to jdk8u. >>>>> >>>>> Master Bug: https://bugs.openjdk.java.net/browse/JDK-6545422 >>>>> Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/efeab0eae50f >>>>> Review: >>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-February/014152.html >>>> Ivan - would it be possible to hold back on this one for a bit. The >>>> updated test is dependent on implicit compilation of the classes in >>>> the @library and this is causing problems for concurrent test runs. >>>> The same pattern has slipped into 15-20 other tests with the result >>>> that they all fail intermittently due to NoClassDefFoundError >>>> issues. I think they should be fixed in jdk9-dev but any of these >>>> "improved" tests are backported. >>>> >>> >>> Yes, sure! >>> Actually, I was going to port this fix into jdk6 (the test fails >>> there), but modified in such a way that it does not depend on >>> testlibrary. >>> I can still work on jdk6 port without first integrating it into >>> jdk8u and jdk7u. >>> >>> Sincerely yours, >>> Ivan >>> >>> >>>> -Alan. >>>> >>>> >>> >>> >>> >>> >> >> >> > From ivan.gerasimov at oracle.com Mon Jul 7 10:23:48 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 07 Jul 2014 14:23:48 +0400 Subject: [8u-dev] Request for approval: 6545422: TEST BUG: NativeErrors.java uses wrong path name in exec In-Reply-To: <53BA6D3D.6060001@oracle.com> References: <530B0952.6090305@oracle.com> <530B0AE9.1070307@oracle.com> <530B0DB5.3080500@oracle.com> <53B3284E.80309@oracle.com> <53B328F1.5070501@oracle.com> <53BA6D3D.6060001@oracle.com> Message-ID: <53BA7534.4060408@oracle.com> Thanks Se?n! On 07.07.2014 13:49, Se?n Coffey wrote: > Approved. > > regards, > Sean. > > On 01/07/14 22:32, Ivan Gerasimov wrote: >> Corrected the subject line: I'm requesting an approval to push the >> fix into jdk8u-dev repo, not jdk8u20 >> >> On 02.07.2014 1:29, Ivan Gerasimov wrote: >>> Hello! >>> >>> I'm rerequesting an approval to backport this test fix into jdk8u. >>> To address the issue with NoClassDefFoundError I added the implicit >>> @build line to the test (as it was done in JDK-8043520). >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-6545422 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/6545422/0/webrev/ >>> Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/efeab0eae50f >>> Review: >>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-February/014152.html >>> >>> Would you please approve the backport? >>> >>> Sincerely yours, >>> Ivan >>> >>> On 24.02.2014 13:15, Ivan Gerasimov wrote: >>>> >>>> On 24.02.2014 13:03, Alan Bateman wrote: >>>>> On 24/02/2014 08:56, Ivan Gerasimov wrote: >>>>>> Hello! >>>>>> >>>>>> Would you please approve porting back this test bug fix? >>>>>> The fix applies cleanly to jdk8u. >>>>>> >>>>>> Master Bug: https://bugs.openjdk.java.net/browse/JDK-6545422 >>>>>> Jdk9 change: >>>>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/efeab0eae50f >>>>>> Review: >>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-February/014152.html >>>>> Ivan - would it be possible to hold back on this one for a bit. >>>>> The updated test is dependent on implicit compilation of the >>>>> classes in the @library and this is causing problems for >>>>> concurrent test runs. The same pattern has slipped into 15-20 >>>>> other tests with the result that they all fail intermittently due >>>>> to NoClassDefFoundError issues. I think they should be fixed in >>>>> jdk9-dev but any of these "improved" tests are backported. >>>>> >>>> >>>> Yes, sure! >>>> Actually, I was going to port this fix into jdk6 (the test fails >>>> there), but modified in such a way that it does not depend on >>>> testlibrary. >>>> I can still work on jdk6 port without first integrating it into >>>> jdk8u and jdk7u. >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> >>>>> -Alan. >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> > > > From peter.levart at gmail.com Mon Jul 7 11:07:27 2014 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 07 Jul 2014 13:07:27 +0200 Subject: RFR 8049220: URL.factory data race In-Reply-To: References: <53B517CF.6060006@gmail.com> <53B585EB.9060807@oracle.com> Message-ID: <53BA7F6F.9040506@gmail.com> Hi Pavel, Alan and Paul, Thanks for reviewing. I accepted the suggestions from Pavel and Paul and created webrev.02: http://cr.openjdk.java.net/~plevart/jdk9-dev/URL.factory/webrev.02/ Is this good to go into jdk9-dev? Regards, Peter On 07/04/2014 04:54 PM, Paul Sandoz wrote: > On Jul 3, 2014, at 6:33 PM, Alan Bateman wrote: >> On 03/07/2014 09:43, Peter Levart wrote: >>> Hi, >>> >>> I noticed a data race in java.net.URL: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8049220 >>> >>> I propose the following simple patch: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/URL.factory/webrev.01/ >>> >> A good catch and the change looks good to me. > Yes, well spotted. May i suggest that the following comment is updated: > > 1109 factory = fac; // volatile write > > to say something about ensuring safe publication of a constructed handle? since it is often quite tricky to reason about why a volatile write is needed (to stamp in, at least, a StoreStore barrier). > > For JMM v9 we may not need to mark such a ref as volatile. > > >> I assume it just wasn't noticed because it can only be set once and probably rared used too. >> > Yeah, i wonder whether it would ever get optimized/inlined to the point at which re-ordering could practically happen. > > Paul. > From daniel.fuchs at oracle.com Mon Jul 7 13:05:36 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 07 Jul 2014 15:05:36 +0200 Subject: RFR: 8048020 - Regression on java.util.logging.FileHandler In-Reply-To: <53B6F168.2040604@oracle.com> References: , <53A9C4C6.3060405@oracle.com> <53B27E8D.30405@oracle.com> <53B6D7BD.1040606@oracle.com> <53B6E37A.7050506@oracle.com> <53B6EB56.5080408@oracle.com> <53B6EE16.3040802@oracle.com> <53B6F168.2040604@oracle.com> Message-ID: <53BA9B20.1040201@oracle.com> Thanks Alan! Just for the record the 'final' webrev is here: http://cr.openjdk.java.net/~dfuchs/webrev_8048020/webrev.02 I will push this shortly... -- daniel On 7/4/14 8:24 PM, Alan Bateman wrote: > On 04/07/2014 19:10, Daniel Fuchs wrote: >> hmmm. yes - you're right. I should catch that to and break the loop in >> that case. >> So that would become: >> >> 465 } catch (NoSuchFileException x) { >> 466 // Race condition - retry once, and if that >> 467 // fails again just try the next name in >> 468 // the sequence. >> 469 continue; >> 470 } catch (IOException x) { >> // the file may not be writable for us. >> // try the next name in the sequence >> break; >> } >> >> Thanks for the feedback Alan! >> I had missed those cases. > If that is the final change then I think I'm okay (no need to generate a > new webrev). I do think it could be improved a bit more by dropping the > isXXX checks but it's not important. > > -Alan From Alan.Bateman at oracle.com Mon Jul 7 14:19:03 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 07 Jul 2014 15:19:03 +0100 Subject: RFR 8049220: URL.factory data race In-Reply-To: <53BA7F6F.9040506@gmail.com> References: <53B517CF.6060006@gmail.com> <53B585EB.9060807@oracle.com> <53BA7F6F.9040506@gmail.com> Message-ID: <53BAAC57.5010904@oracle.com> On 07/07/2014 12:07, Peter Levart wrote: > Hi Pavel, Alan and Paul, > > Thanks for reviewing. I accepted the suggestions from Pavel and Paul > and created webrev.02: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/URL.factory/webrev.02/ > > Is this good to go into jdk9-dev? The comments looks okay to me (and it clear). So I think this is okay to push to jdk9/dev. -Alan From paul.sandoz at oracle.com Mon Jul 7 15:04:48 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 7 Jul 2014 17:04:48 +0200 Subject: RFR 8049220: URL.factory data race In-Reply-To: <53BA7F6F.9040506@gmail.com> References: <53B517CF.6060006@gmail.com> <53B585EB.9060807@oracle.com> <53BA7F6F.9040506@gmail.com> Message-ID: On Jul 7, 2014, at 1:07 PM, Peter Levart wrote: > Hi Pavel, Alan and Paul, > > Thanks for reviewing. I accepted the suggestions from Pavel and Paul and created webrev.02: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/URL.factory/webrev.02/ > > Is this good to go into jdk9-dev? > Looks ok. Paul. From martinrb at google.com Mon Jul 7 16:41:22 2014 From: martinrb at google.com (Martin Buchholz) Date: Mon, 7 Jul 2014 09:41:22 -0700 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53B9677B.6060806@oracle.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> Message-ID: I'd like to offer an alternative version of this change. webrev coming soon. On Sun, Jul 6, 2014 at 8:12 AM, Ivan Gerasimov wrote: > Thanks for suggestion Jeff! > > I've tried it, but it doesn't seem to make a difference on my machine. > Here are the numbers. I measured the time of a single put in nanoseconds. > > > ----------- | vanila | fix1 | fix2 > client | 8292 | 8220 | 8304 > server | 8197 | 8198 | 8221 > interpreter | 13980 | 14478 | 14152 > > > fix1 - the fix from webrev #3 > fix2 - the fix with your suggestion > > Sincerely yours, > Ivan > > > > On 06.07.2014 15:13, Jeff Hain wrote: > >> >> >> >So, I reverted this change to the original code, but added a single >> >check of the current table size before doing any modifications to the >> map. >> >This is to address the issue #4, and this doesn't seem to introduce any >> >significant penalty. >> > >> >Would you please help review the updated webrev: >> > >> >http://cr.openjdk.java.net/~igerasim/6904367/3/webrev/ < >> http://cr.openjdk.java.net/%7Eigerasim/6904367/3/webrev/> >> >> > >> >Sincerely yours, >> > >> >Ivan >> >> It's possible to avoid the capacity test for the general case: >> put { >> ...while loop... >> >> if (size < threshold) { >> modCount++; >> tab[i] = k; >> tab[i + 1] = value; >> ++size; >> } else { >> putAndResize(k, value, i); >> } >> return null; >> } >> private void putAndResize(Object k, Object value, int i) { >> if (size == MAXIMUM_CAPACITY - 1) >> throw new IllegalStateException("Capacity exhausted."); >> modCount++; >> Object[] tab = table; >> tab[i] = k; >> tab[i + 1] = value; >> ++size; >> resize(tab.length); // len == 2 * current capacity. >> } >> >> It seems faster more often than not, but it adds more (and copied) code: >> not sure it's worth it. >> >> -Jeff >> >> >> > From jeremymanson at google.com Mon Jul 7 16:55:49 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Mon, 7 Jul 2014 09:55:49 -0700 Subject: Draft JEP: Efficient Stack Walking API In-Reply-To: <5338A27B.1010309@oracle.com> References: <5338A27B.1010309@oracle.com> Message-ID: Hey folks, I don't know if Mandy's draft JEP has gotten any love, but this is something that has (in the past) been a major CPU cycle consumer for us, and we've had to invent / reinvent many wheels to fix it internally, so we'd love to see a principled solution. A couple of notes: - A large percentage of the time, you just want to find one of: 1) The direct caller of the method, 2) The first caller outside a given package. We added a CallerFinder API that basically looks like this: // Finds the caller of the invoking method in the current stack that isn't in one of the excluded classes public static StackTraceElement findCaller(Class... excludedClasses); // Finds the first caller of a given class public static StackTraceElement findCallerOf(Class... classesToFind); This isn't the ideal API (it is more the one that happened to be convenient when we threw together the class), but it gets the vast majority of use cases. 2) Even with a super-efficient stack walker, anyone who uses the java.util.logging framework pervasively is going to see a lot of CPU cycles consumed by determining the caller. We've had a lot of luck minimizing this by using a bytecode rewriter to change callers of log(msg) to log(sourceClass, sourceMethod, msg). This is almost certainly something that could be done (even in a principled way!) by the VM; improvements to CPU usage in such apps have been dramatic. Jeremy On Sun, Mar 30, 2014 at 4:02 PM, Mandy Chung wrote: > Below is a draft JEP we are considering submitting for JDK 9. > > Mandy > > ---------------------------- > Title: Efficient API for Stack Walking > > Goal > ---- > > Define a standard API for stack walking that will be efficient and > performant. > > Non-goal > -------- > > It is not a goal for this API be easy to use via Reflection for example > use in code that is compiled for an older JDK. > > Motivation > ---------- > > There is no standard API to obtain information about the caller's class > and traverse the execution stack in a performant way. Existing libraries > and frameworks such as Log4j and Groovy have to resort to using the > JDK internal API `sun.reflect.Reflection.getCallerClass(int depth)`. > > This JEP proposes to define a standard API for stack walking that will > be efficient and performant and also enable the implementation up > level the stack walk machinery from the VM to Java and replaces > the current mechanism of `Throwable.fillInStackTrace. > > Description > ----------- > > There is no standard API to traverse certain frames on the execution > stack efficiently and access the Class instance of each frame. > > There are APIs that allow to access the stack trace information: > - `Throwable.getStackTrace()` and `Thread.getStackTrace()` that returns > an array of `StackTraceElement` which contains the classname > and method name of a stack trace. > - `SecurityManager.getClassContext()` which is a protected method > such that only `SecurityManager` subclass can access the class > context. > > These APIs require the VM to eagerly capture a snapshot of the entire > stack trace and returns the information representing the entire stack. > There is no other way to avoid the cost to examine all frames if > the caller is only interested in the top few frames on the stack. > Both `Throwable.getStackTrace()` and `Thread.getStackTrace()` methods > return an array of `StackTraceElement` that contains the classname and > method name of a stack frame but the `Class` instance. > > In fact, for applications interested in the entire stack, the specification > allows VM implementation to omit some frames in the stack for performance. > In other words, `Thread.getStackTrace()` may return a partial stack trace. > > These APIs do not satisfy the use cases that currently depend on > the `getCallerClass(int depth)` method or its performance overhead > is intolerable. The use cases include: > > - JDK caller-sensitive APIs look up its immediate caller's class > which will be used to determine the behavior of the API. For example > `Class.forName(String classname)` and > `ResourceBundle.getBundle(String rbname)` methods use the immediate > caller's class loader to load a class and a resource bundle > respectively. > `Class.getMethod` etc will use the immediate caller's class loader > to determine the security checks to be performed. > > - `java.util.logging`, Log4j and Groovy runtime filter the intermediary > stack frames (typically implementation-specific and reflection frames) > and find the caller's class to be used by the runtime of such library > or framework. > > - Traverse the entire stack trace or the stack trace of a `Throwbale` > and obtain additional information about classes for enhanced > diagnosibility in addition to the class and method name. > > This JEP will define a stack walk API that allows laziness, frame > filtering, > supports short reaches to stop at a frame matching some criteria > as well as long reaches to traverse the entire stack trace. This would > need the JVM to provide a flexible mechanism to traverse and materialize > the specific stack frame information to be used and allow efficient > lazy access to additional stack frames when required. > Native JVM transitions should be minimzed. > > The API will define how it works when running with a security manager > that allows access to a `Class` instance > of any frame ensuring that the security is not compromised. > > An example API to walk the stack can be like: > Thread.walkStack(Consumer action, int depthLimit) > > that takes a callback to be invoked for each frame traversed. A variant > of the walkStack method will take a predicate for stack frame filtering. > > Thread.getCaller(Function function) > Thread.findCaller(Predicate predicate, > Function function) > > finds the caller frame with or without filtering. > > Testing > ------- > > Unit tests and JCK tests for the new SE API will need to be developed. > In addition, the performance of the new API for different use cases > will be assessed. > > > Impact > ------ > > - Performance/scalability: performance measurement shall be performed > using micro-benchmarks as well as real world usage of `getCallerClass` > replaced with the new API. > > - TCK: New JCK test cases shall be developed. > > From ivan.gerasimov at oracle.com Mon Jul 7 17:07:10 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 07 Jul 2014 21:07:10 +0400 Subject: RFR [8035975] Pattern.compile(String, int) fails to throw IllegalArgumentException Message-ID: <53BAD3BE.3040609@oracle.com> Hello! The javadoc says that Pattern.compile(String regex, int flag) will throw IllegalArgumentException, if flag contains an invalid bit set. However, it fails to do so. Would you please help review the simple fix for that? Alternatively, we could just remove the corresponding @throws part, but that would change the spec. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8035975 WEBREV: http://cr.openjdk.java.net/~igerasim/8035975/0/webrev/ Sincerely yours, Ivan From xueming.shen at oracle.com Mon Jul 7 17:38:37 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 07 Jul 2014 10:38:37 -0700 Subject: RFR [8035975] Pattern.compile(String, int) fails to throw IllegalArgumentException In-Reply-To: <53BAD3BE.3040609@oracle.com> References: <53BAD3BE.3040609@oracle.com> Message-ID: <53BADB1D.1000008@oracle.com> On 07/07/2014 10:07 AM, Ivan Gerasimov wrote: > Hello! > > The javadoc says that Pattern.compile(String regex, int flag) will throw IllegalArgumentException, if flag contains an invalid bit set. > However, it fails to do so. > > Would you please help review the simple fix for that? > Alternatively, we could just remove the corresponding @throws part, but that would change the spec. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8035975 > WEBREV: http://cr.openjdk.java.net/~igerasim/8035975/0/webrev/ > > Sincerely yours, > Ivan Looks fine. But given it's a behavior change, you probably still need a CCC for it. thanks! -Sherman From mandy.chung at oracle.com Mon Jul 7 18:03:00 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 07 Jul 2014 11:03:00 -0700 Subject: Review request: 8029548 (jdeps) use @jdk.Exported to determine supported vs JDK internal API In-Reply-To: <53B6ECA9.8010203@oracle.com> References: <53AB2F38.7030700@oracle.com> <53B6ECA9.8010203@oracle.com> Message-ID: <53BAE0D4.2010001@oracle.com> On 7/4/14 11:04 AM, Alan Bateman wrote: > On 25/06/2014 21:21, Mandy Chung wrote: >> This patch is also intended to target for 8u40 backport. It fixes >> the following issues: >> >> JDK-8029548 (jdeps) use @jdk.Exported to determine supported vs JDK >> internal API >> JDK-8039007 jdeps incorrectly reports javax.jnlp as JDK internal APIs >> JDK-8031092 jdeps does not recognize --help option. >> JDK-8048063 (jdeps) Add filtering capability >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8029548/webrev.00/ >> > I'm skimmed over this and it mostly looks okay. I'm not sure that I > agree that JDK-8039007 is a bug, this is really just that it is > missing @jdk.Exported as you noted in PlatformClassPath. I think the right way to do is to add @jdk.Exported in javax.jnlp. I'll follow up with deploy and check if they can annotate the exported APIs in 8u40; if so, I can take this special case out from jdeps. > The -filter options are useful but at the same time I have a concern > that the number of options to jdeps is growing. I shared the same concern. I had the -filter option in my first version of jdeps but I didn't include it in the first push to jdeps. Currently jdeps doesn't provide an easy way to find all package-level dependencies as it always excludes the dependencies from the same JAR/archive. Both cases are useful for developers in order to understand what APIs a library/app is using. I think -filter option provides a convenient way to specify what to be filtered rather than listing the packages in -p or -e options. Do you have any other suggestion to avoid adding -filter option? Mandy From ivan.gerasimov at oracle.com Mon Jul 7 19:25:32 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 07 Jul 2014 23:25:32 +0400 Subject: RFR [8035975] Pattern.compile(String, int) fails to throw IllegalArgumentException In-Reply-To: <53BADB1D.1000008@oracle.com> References: <53BAD3BE.3040609@oracle.com> <53BADB1D.1000008@oracle.com> Message-ID: <53BAF42C.6050008@oracle.com> Thanks you Sherman for review! On 07.07.2014 21:38, Xueming Shen wrote: > On 07/07/2014 10:07 AM, Ivan Gerasimov wrote: >> Hello! >> >> The javadoc says that Pattern.compile(String regex, int flag) will >> throw IllegalArgumentException, if flag contains an invalid bit set. >> However, it fails to do so. >> >> Would you please help review the simple fix for that? >> Alternatively, we could just remove the corresponding @throws part, >> but that would change the spec. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8035975 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8035975/0/webrev/ >> >> Sincerely yours, >> Ivan > > Looks fine. But given it's a behavior change, you probably still need > a CCC for it. > Okay, just filed one. Sincerely yours, Ivan > thanks! > -Sherman > > From huizhe.wang at oracle.com Mon Jul 7 23:02:06 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 07 Jul 2014 16:02:06 -0700 Subject: RFR: 8044656: Update JAX-WS RI integration to latest version In-Reply-To: <53B18EE1.1080502@oracle.com> References: <53B18EE1.1080502@oracle.com> Message-ID: <53BB26EE.2090704@oracle.com> Hi Miran, In class src/share/jaxws_classes/com/sun/tools/internal/xjc/Options.java: + // hack to force initialization so catalog manager system properties take effect + staticManager.getVerbosity(); Is that necessary? I thought the next call to getCatalog would initialize the properties from the CatalogManager property file. Using ServiceLoader in class src/share/jaxws_classes/javax/xml/ws/spi/Provider.java: Would you need to give the process privilege? Or maybe the method is already called in a privileged block? Thanks, Joe On 6/30/2014 9:22 AM, Miroslav Kos wrote: > Hi, > there is a bulk update of JAX-B/WS from upstream projects - > webrev: http://cr.openjdk.java.net/~mkos/8044656/jaxws.00/ > more details in issue desc: > https://bugs.openjdk.java.net/browse/JDK-8044656 > > Could I ask for a review/approval? > > Thanks > Miran From martinrb at google.com Tue Jul 8 00:44:44 2014 From: martinrb at google.com (Martin Buchholz) Date: Mon, 7 Jul 2014 17:44:44 -0700 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> Message-ID: On Mon, Jul 7, 2014 at 9:41 AM, Martin Buchholz wrote: > I'd like to offer an alternative version of this change. webrev coming > soon. > Here's the promised webrev. http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity/ - Fixes a typo in the javadoc. - removes the "threshold" field (WAT, a cache to avoid multiplying by 3?) - optimizes 3*x into x + x << 1 - adds more test assertions - removes the unusual 4/3 slack space for expansion on deserialization. TODO: the test should be testng-ified, I think. From martinrb at google.com Tue Jul 8 00:47:04 2014 From: martinrb at google.com (Martin Buchholz) Date: Mon, 7 Jul 2014 17:47:04 -0700 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53B8C782.1060009@oracle.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> Message-ID: I think this code has an off-by-factor-of-2 bug. + if (expectedMaxSize > MAXIMUM_CAPACITY / 3) + return MAXIMUM_CAPACITY; From ivan.gerasimov at oracle.com Tue Jul 8 01:12:37 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 08 Jul 2014 05:12:37 +0400 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> Message-ID: <53BB4585.8020208@oracle.com> On 08.07.2014 4:47, Martin Buchholz wrote: > I think this code has an off-by-factor-of-2 bug. > > + if (expectedMaxSize > MAXIMUM_CAPACITY / 3) > + return MAXIMUM_CAPACITY; > No, even though it looks like a bug. (MAXIMUM_CAPACITY / 3) * (3 / 2) == MAXIMUM_CAPACITY / 2. if expected size > MAXIMUM_CAPACITY / 3, then the minimum capacity must be > MAXIMUM_CAPACITY / 2 then the minimum capacity == MAXIMUM_CAPACITY. From ivan.gerasimov at oracle.com Tue Jul 8 01:54:12 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 08 Jul 2014 05:54:12 +0400 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> Message-ID: <53BB4F44.5040205@oracle.com> Thank you Martin for the enhancement! It's a good idea to get rid of threshold variable! When the table grows large, it will start to try to resize the table on every single put(). Though it shouldn't matter much, as in such situation everything is already slow. On 08.07.2014 4:44, Martin Buchholz wrote: > > On Mon, Jul 7, 2014 at 9:41 AM, Martin Buchholz > wrote: > > I'd like to offer an alternative version of this change. webrev > coming soon. > > > Here's the promised webrev. > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity/ > > > - Fixes a typo in the javadoc. > - removes the "threshold" field (WAT, a cache to avoid multiplying by 3?) > - optimizes 3*x into x + x << 1 Unfortunately, x + x << 1 causes the same overflow bug as 3*x: (int)(1431655766 + 1431655766 << 1) == 2 this can happen in capacity() and, theoretically, in putAll(). I propose to leave the check if (expectedMaxSize > MAXIMUM_CAPACITY / 3) return MAXIMUM_CAPACITY; which is overflow resistant. In putAll, I guess, something like this can be used: int len = table.length; if (n > len || n > len - n || n > len - (n << 1)) resize(capacity(n)); > - adds more test assertions > - removes the unusual 4/3 slack space for expansion on deserialization. > TODO: the test should be testng-ified, I think. > > From mandy.chung at oracle.com Tue Jul 8 03:06:55 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 07 Jul 2014 20:06:55 -0700 Subject: Draft JEP: Efficient Stack Walking API In-Reply-To: References: <5338A27B.1010309@oracle.com> Message-ID: <53BB604F.9020500@oracle.com> Hi Jeremy, Thanks for the feedback and the CallerFinder API you have. On 7/7/2014 9:55 AM, Jeremy Manson wrote: > Hey folks, > > I don't know if Mandy's draft JEP has gotten any love, The JEP process is in transition to 2.0 version. Hope this JEP will come out soon. > but this is something that has (in the past) been a major CPU cycle > consumer for us, and we've had to invent / reinvent many wheels to fix > it internally, so we'd love to see a principled solution. > > A couple of notes: > > - A large percentage of the time, you just want to find one of: > 1) The direct caller of the method, > 2) The first caller outside a given package. > The current thinking is to allow you to find the direct caller as well as express the predicate for filtering that will cover these cases. > We added a CallerFinder API that basically looks like this: > > // Finds the caller of the invoking method in the current stack that > isn't in one of the excluded classes > public static StackTraceElement findCaller(Class... excludedClasses); > > // Finds the first caller of a given class > public static StackTraceElement findCallerOf(Class... classesToFind); > > This isn't the ideal API (it is more the one that happened to be > convenient when we threw together the class), but it gets the vast > majority of use cases. > Does it use Thread.getStackTrace() to implement this CallerFinder API? Thread.getStackTrace or Throwable.getStackTrace both eagerly capture the entire stack trace that is expensive. We want to have the VM to be able to only capture the stack frames that the client needs and the implementation as efficient as possible. > 2) Even with a super-efficient stack walker, anyone who uses the > java.util.logging framework pervasively is going to see a lot of CPU > cycles consumed by determining the caller. The current LogRecord implementation calls new Throwable that has to pay the cost of capturing the entire stack. > We've had a lot of luck minimizing this by using a bytecode rewriter > to change callers of log(msg) to log(sourceClass, sourceMethod, msg). > This is almost certainly something that could be done (even in a > principled way!) by the VM; improvements to CPU usage in such apps > have been dramatic. > Thanks. I'll make sure to measure and compare the performance with java.util.logging using the new stack walk API and also may ask your help to determine if you observe the performance difference comparing the rewritten bytecode vs the java.util.logging using the new API. Mandy > Jeremy > > > > On Sun, Mar 30, 2014 at 4:02 PM, Mandy Chung > wrote: > > Below is a draft JEP we are considering submitting for JDK 9. > > Mandy > > ---------------------------- > Title: Efficient API for Stack Walking > > Goal > ---- > > Define a standard API for stack walking that will be efficient and > performant. > > Non-goal > -------- > > It is not a goal for this API be easy to use via Reflection for > example > use in code that is compiled for an older JDK. > > Motivation > ---------- > > There is no standard API to obtain information about the caller's > class > and traverse the execution stack in a performant way. Existing > libraries > and frameworks such as Log4j and Groovy have to resort to using the > JDK internal API `sun.reflect.Reflection.getCallerClass(int depth)`. > > This JEP proposes to define a standard API for stack walking that will > be efficient and performant and also enable the implementation up > level the stack walk machinery from the VM to Java and replaces > the current mechanism of `Throwable.fillInStackTrace. > > Description > ----------- > > There is no standard API to traverse certain frames on the execution > stack efficiently and access the Class instance of each frame. > > There are APIs that allow to access the stack trace information: > - `Throwable.getStackTrace()` and `Thread.getStackTrace()` that > returns > an array of `StackTraceElement` which contains the classname > and method name of a stack trace. > - `SecurityManager.getClassContext()` which is a protected method > such that only `SecurityManager` subclass can access the class > context. > > These APIs require the VM to eagerly capture a snapshot of the entire > stack trace and returns the information representing the entire stack. > There is no other way to avoid the cost to examine all frames if > the caller is only interested in the top few frames on the stack. > Both `Throwable.getStackTrace()` and `Thread.getStackTrace()` methods > return an array of `StackTraceElement` that contains the classname and > method name of a stack frame but the `Class` instance. > > In fact, for applications interested in the entire stack, the > specification > allows VM implementation to omit some frames in the stack for > performance. > In other words, `Thread.getStackTrace()` may return a partial > stack trace. > > These APIs do not satisfy the use cases that currently depend on > the `getCallerClass(int depth)` method or its performance overhead > is intolerable. The use cases include: > > - JDK caller-sensitive APIs look up its immediate caller's class > which will be used to determine the behavior of the API. For > example > `Class.forName(String classname)` and > `ResourceBundle.getBundle(String rbname)` methods use the > immediate > caller's class loader to load a class and a resource bundle > respectively. > `Class.getMethod` etc will use the immediate caller's class loader > to determine the security checks to be performed. > > - `java.util.logging`, Log4j and Groovy runtime filter the > intermediary > stack frames (typically implementation-specific and reflection > frames) > and find the caller's class to be used by the runtime of such > library > or framework. > > - Traverse the entire stack trace or the stack trace of a > `Throwbale` > and obtain additional information about classes for enhanced > diagnosibility in addition to the class and method name. > > This JEP will define a stack walk API that allows laziness, frame > filtering, > supports short reaches to stop at a frame matching some criteria > as well as long reaches to traverse the entire stack trace. This > would > need the JVM to provide a flexible mechanism to traverse and > materialize > the specific stack frame information to be used and allow efficient > lazy access to additional stack frames when required. > Native JVM transitions should be minimzed. > > The API will define how it works when running with a security manager > that allows access to a `Class` instance > of any frame ensuring that the security is not compromised. > > An example API to walk the stack can be like: > Thread.walkStack(Consumer action, int depthLimit) > > that takes a callback to be invoked for each frame traversed. A > variant > of the walkStack method will take a predicate for stack frame > filtering. > > Thread.getCaller(Function function) > Thread.findCaller(Predicate predicate, > Function function) > > finds the caller frame with or without filtering. > > Testing > ------- > > Unit tests and JCK tests for the new SE API will need to be developed. > In addition, the performance of the new API for different use cases > will be assessed. > > > Impact > ------ > > - Performance/scalability: performance measurement shall be > performed > using micro-benchmarks as well as real world usage of > `getCallerClass` > replaced with the new API. > > - TCK: New JCK test cases shall be developed. > > From martinrb at google.com Tue Jul 8 07:27:09 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 8 Jul 2014 00:27:09 -0700 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53BB4585.8020208@oracle.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <53BB4585.8020208@oracle.com> Message-ID: Ah, yes, now I see. My latest attempt at this method looks like: private static int capacity(int expectedMaxSize) { // assert expectedMaxSize >= 0; return (expectedMaxSize > MAXIMUM_CAPACITY / 3) ? MAXIMUM_CAPACITY : (expectedMaxSize <= 2 * MINIMUM_CAPACITY / 3) ? MINIMUM_CAPACITY : Integer.highestOneBit(expectedMaxSize + (expectedMaxSize << 1)); } On Mon, Jul 7, 2014 at 6:12 PM, Ivan Gerasimov wrote: > > On 08.07.2014 4:47, Martin Buchholz wrote: > >> I think this code has an off-by-factor-of-2 bug. >> >> + if (expectedMaxSize > MAXIMUM_CAPACITY / 3) >> + return MAXIMUM_CAPACITY; >> >> > No, even though it looks like a bug. > > (MAXIMUM_CAPACITY / 3) * (3 / 2) == MAXIMUM_CAPACITY / 2. > > if expected size > MAXIMUM_CAPACITY / 3, > then the minimum capacity must be > MAXIMUM_CAPACITY / 2 > then the minimum capacity == MAXIMUM_CAPACITY. > > > From martinrb at google.com Tue Jul 8 07:33:49 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 8 Jul 2014 00:33:49 -0700 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53BB4F44.5040205@oracle.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> Message-ID: I've updated the webrev http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity/ It now has all my TODOs done. The test case has been testng-ified. On Mon, Jul 7, 2014 at 6:54 PM, Ivan Gerasimov wrote: > > Unfortunately, x + x << 1 causes the same overflow bug as 3*x: > x + (x << 1) is merely supposed to be possibly more efficient than 3*x. > (int)(1431655766 + 1431655766 << 1) == 2 > OK, I think my latest version doesn't have any overflow bugs. From martinrb at google.com Tue Jul 8 07:42:47 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 8 Jul 2014 00:42:47 -0700 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> Message-ID: I can't say I'm very happy with the massive slowdown behavior as we get close to MAX_CAPACITY. When size == MAX_CAPACITY - 1, linear probing will end up retrying 1<<28 times on average. It might be better for users to fail hard when you get to MAX_CAPACITY * 2/3 ... but not in production (!?). I don't have a good answer. From vladimir.x.ivanov at oracle.com Tue Jul 8 10:09:04 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 08 Jul 2014 14:09:04 +0400 Subject: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms In-Reply-To: <53305E52.2060001@oracle.com> References: <5322EBF2.7030209@oracle.com> <5322F3D7.9010103@oracle.com> <94F61B19-8904-42FA-9E16-CC0A6B30FD79@oracle.com> <53230184.9090007@oracle.com> <2FCC64E3-3753-4CE0-9CC6-849FF737BFB5@oracle.com> <53232FF3.9020803@oracle.com> <53305E52.2060001@oracle.com> Message-ID: <53BBC340.7040509@oracle.com> I'd like to revive this review thread. Updated version: http://cr.openjdk.java.net/~vlivanov/8037209/webrev.04/ Paul, I'd like to address your case (if possible) separately. Right now, I don't see any way to avoid null check you see with your tests. Best regards, Vladimir Ivanov On 3/24/14 8:33 PM, Vladimir Ivanov wrote: > Updated version: > http://cr.openjdk.java.net/~vlivanov/8037209/webrev.01/ > > Changes: > - rebased to enum-based BasicType; > - decided to integrate changes for typed array getters/setters > separately; > > Best regards, > Vladimir Ivanov > > On 3/14/14 8:36 PM, Vladimir Ivanov wrote: >>> Doh! crossed webrevs, thanks. >>> >>> Just had a quick look, this looks like a really nice improvement to >>> the array setter/getter support, definitely simplified. IIUC the >>> mh.viewAsType will now handle the appropriate casting. I believe it >>> might reduce the "ceremony" for array setter/getter MHs [1]. >>> >>> I see there is a PROFILE_LEVEL option, by default set to 0, that >>> results in casts not being emitted: >>> >>> + if (VerifyType.isNullConversion(Object.class, pclass, >>> false)) { >>> + if (PROFILE_LEVEL > 0) >>> + emitReferenceCast(Object.class, arg); >>> + return; >>> + } >>> ... >>> + mv.visitLdcInsn(constantPlaceholder(cls)); >>> + mv.visitTypeInsn(Opcodes.CHECKCAST, CLS); >>> + mv.visitInsn(Opcodes.SWAP); >>> + mv.visitMethodInsn(Opcodes.INVOKESTATIC, MHI, >>> "castReference", CLL_SIG, false); >>> + if (Object[].class.isAssignableFrom(cls)) >>> + mv.visitTypeInsn(Opcodes.CHECKCAST, OBJARY); >>> + else if (PROFILE_LEVEL > 0) >>> + mv.visitTypeInsn(Opcodes.CHECKCAST, OBJ); >>> >>> Can you explain a bit the rational for that? >> These casts are redundant - they aren't required for bytecode >> correctness. The idea behind PROFILE_LEVEL is to provide more type >> information to JIT-compiler. Right now, type profiling occurs on every >> checkcast instruction. So, having these additional instructions we can >> feed C2 with more accurate information about types. >> >> Consider this as a hack to overcome some of the limitations of current >> profiling implementation in VM. >> >> Best regards, >> Vladimir Ivanov >> >>> Paul. >>> >>> [1] Below is an inlining trace for an array getter MH in the current >>> code i obtained a few weeks ago when investigating CAS-based MHs for >>> arrays: >>> >>> Inlining _isInstance on constant Class java/lang/Class >>> Inlining _isInstance on constant Class [Ljava/lang/Object; >>> Inlining _isInstance on constant Class [Ljava/lang/String; >>> Inlining _isInstance on constant Class java/lang/String >>> @ 12 unsafe.ArrayMHTest::get_mh_orig >>> (19 bytes) inline (hot) >>> @ 12 >>> java.lang.invoke.LambdaForm$MH/924874137::invokeExact_MT (15 bytes) >>> inline (hot) >>> @ 2 >>> java.lang.invoke.Invokers::checkExactType (30 bytes) inline (hot) >>> @ 11 >>> java.lang.invoke.MethodHandle::type (5 bytes) accessor >>> @ 11 >>> java.lang.invoke.LambdaForm$MH/1980556943::convert (21 bytes) inline >>> (hot) >>> @ 7 >>> java.lang.invoke.LambdaForm$MH/1892887290::getElement (20 bytes) >>> inline (hot) >>> @ 16 >>> java.lang.invoke.LambdaForm$MH/816943783::convert (37 bytes) inline >>> (hot) >>> @ 6 >>> java.lang.invoke.LambdaForm$BMH/1350345087::reinvoke (26 bytes) >>> inline (hot) >>> @ 12 >>> java.lang.invoke.BoundMethodHandle$Species_LL::reinvokerTarget (8 >>> bytes) inline (hot) >>> @ 22 >>> java.lang.invoke.LambdaForm$DMH/1162873666::invokeStatic_LL_L (15 >>> bytes) inline (hot) >>> @ 1 >>> java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes) >>> inline (hot) >>> @ 11 >>> sun.invoke.util.ValueConversions::castReference (20 bytes) inline >>> (hot) >>> @ 6 >>> java.lang.Class::isInstance (0 bytes) (intrinsic) >>> @ 17 >>> java.lang.invoke.LambdaForm$BMH/1350345087::reinvoke (26 bytes) >>> inline (hot) >>> @ 12 >>> java.lang.invoke.BoundMethodHandle$Species_LL::reinvokerTarget (8 >>> bytes) inline (hot) >>> @ 22 >>> java.lang.invoke.LambdaForm$DMH/1162873666::invokeStatic_LL_L (15 >>> bytes) inline (hot) >>> @ 1 >>> java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes) >>> inline (hot) >>> @ 11 >>> sun.invoke.util.ValueConversions::castReference (20 bytes) inline >>> (hot) >>> @ 6 >>> java.lang.Class::isInstance (0 bytes) (intrinsic) >>> @ 33 >>> java.lang.invoke.MethodHandleImpl$ArrayAccessor::getElementL (10 >>> bytes) inline (hot) >>> @ 2 java.lang.Class::cast >>> (27 bytes) inline (hot) >>> @ 6 >>> java.lang.Class::isInstance (0 bytes) (intrinsic) >>> @ 17 >>> java.lang.invoke.LambdaForm$MH/91466391::convert (23 bytes) inline >>> (hot) >>> @ 6 >>> java.lang.invoke.LambdaForm$BMH/1350345087::reinvoke (26 bytes) >>> inline (hot) >>> @ 12 >>> java.lang.invoke.BoundMethodHandle$Species_LL::reinvokerTarget (8 >>> bytes) inline (hot) >>> @ 22 >>> java.lang.invoke.LambdaForm$DMH/1162873666::invokeStatic_LL_L (15 >>> bytes) inline (hot) >>> @ 1 >>> java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes) >>> inline (hot) >>> @ 11 >>> sun.invoke.util.ValueConversions::castReference (20 bytes) inline >>> (hot) >>> @ 6 >>> java.lang.Class::isInstance (0 bytes) (intrinsic) >>> @ 19 >>> java.lang.invoke.LambdaForm$MH/349834280::identity (10 bytes) inline >>> (hot) >>> @ 6 >>> java.lang.invoke.LambdaForm$DMH/1357006072::invokeStatic_L_L (14 >>> bytes) inline (hot) >>> @ 1 >>> java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes) >>> inline (hot) >>> @ 10 >>> sun.invoke.util.ValueConversions::identity (2 bytes) inline (hot) >>> From vladimir.x.ivanov at oracle.com Tue Jul 8 10:09:46 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 08 Jul 2014 14:09:46 +0400 Subject: [9] RFR (S): 8038261: JSR292: cache and reuse typed array accessors In-Reply-To: <5330752C.3010700@oracle.com> References: <5330752C.3010700@oracle.com> Message-ID: <53BBC36A.8040601@oracle.com> I'd like to revive review this review thread. Updated version: http://cr.openjdk.java.net/~vlivanov/8038261/webrev.03/ Thanks! Best regards, Vladimir Ivanov On 3/24/14 10:10 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8038261/webrev.00 > https://bugs.openjdk.java.net/browse/JDK-8038261 > 56 lines changed: 26 ins; 14 del; 16 mod > > Cache typed array element getters/setters and reuse them. > Initially, it was part of 8037209, but I decided to integrate it > separately. > > Contributed-by: john.r.rose at oracle.com > > Testing: jdk/java/{lang/invoke,util}, vm.mlvm.testlist, nashorn, jruby > > Configs: -ea -esa -Xverify:all -D...COMPILE_THRESHOLD={0,30} > > Best regards, > Vladimir Ivanov From peter.levart at gmail.com Tue Jul 8 10:12:30 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 08 Jul 2014 12:12:30 +0200 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> Message-ID: <53BBC40E.6050305@gmail.com> On 07/08/2014 09:33 AM, Martin Buchholz wrote: > I've updated the webrev > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity/ > It now has all my TODOs done. > The test case has been testng-ified. Hi Martin, What happened to the desire that when OOME is thrown on resizing, IHM is left unchanged? Regards, Peter > > On Mon, Jul 7, 2014 at 6:54 PM, Ivan Gerasimov > wrote: > >> Unfortunately, x + x << 1 causes the same overflow bug as 3*x: >> > x + (x << 1) is merely supposed to be possibly more efficient than 3*x. > > >> (int)(1431655766 + 1431655766 << 1) == 2 >> > OK, I think my latest version doesn't have any overflow bugs. From paul.sandoz at oracle.com Tue Jul 8 10:40:44 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 8 Jul 2014 12:40:44 +0200 Subject: [9] RFR (S): 8038261: JSR292: cache and reuse typed array accessors In-Reply-To: <53BBC36A.8040601@oracle.com> References: <5330752C.3010700@oracle.com> <53BBC36A.8040601@oracle.com> Message-ID: <4B791832-ACBC-422E-A13A-77300B658279@oracle.com> On Jul 8, 2014, at 12:09 PM, Vladimir Ivanov wrote: > I'd like to revive review this review thread. > > Updated version: > http://cr.openjdk.java.net/~vlivanov/8038261/webrev.03/ > +1 Paul. From peter.levart at gmail.com Tue Jul 8 10:41:37 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 08 Jul 2014 12:41:37 +0200 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53BBC40E.6050305@gmail.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> Message-ID: <53BBCAE1.7050702@gmail.com> On 07/08/2014 12:12 PM, Peter Levart wrote: > On 07/08/2014 09:33 AM, Martin Buchholz wrote: >> I've updated the webrev >> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity/ >> >> It now has all my TODOs done. >> The test case has been testng-ified. > > Hi Martin, > > What happened to the desire that when OOME is thrown on resizing, IHM > is left unchanged? > > Regards, Peter Hi Martin, I took your latest version of the patch and modified it a little: http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.01/ Here's a diff to your version: *** src/share/classes/java/util/IdentityHashMap.java.mb 2014-07-08 12:37:57.267916926 +0200 --- src/share/classes/java/util/IdentityHashMap.java 2014-07-08 12:34:25.739767669 +0200 *************** *** 437,449 **** if (size == MAXIMUM_CAPACITY - 1) throw new IllegalStateException("Capacity exhausted."); ! modCount++; ! tab[i] = k; ! tab[i + 1] = value; ! size++; ! int x = size + (size << 1); // Optimized form of 3 * size ! if (x > len) ! resize(len); // len == 2 * current capacity. return null; } --- 437,457 ---- if (size == MAXIMUM_CAPACITY - 1) throw new IllegalStateException("Capacity exhausted."); ! ! int x = size + (size << 1) + 3; // Optimized form of 3 * (size + 1) ! if (x > len) { ! if (resize(len)) { // len == 2 * current capacity. ! tab = table; ! len = tab.length; ! i = hash(key, len); ! while (tab[i] != null) ! i = nextKeyIndex(i, len); ! } ! modCount++; ! tab[i] = k; ! tab[i + 1] = value; ! size++; ! } return null; } *************** *** 452,468 **** * * @param newCapacity the new capacity, must be a power of two. */ ! private void resize(int newCapacity) { // assert (newCapacity & -newCapacity) == newCapacity; // power of 2 int newLength = newCapacity * 2; Object[] oldTable = table; int oldLength = oldTable.length; if (oldLength == 2 * MAXIMUM_CAPACITY) { // can't expand any further ! return; } if (oldLength >= newLength) ! return; Object[] newTable = new Object[newLength]; --- 460,476 ---- * * @param newCapacity the new capacity, must be a power of two. */ ! private boolean resize(int newCapacity) { // assert (newCapacity & -newCapacity) == newCapacity; // power of 2 int newLength = newCapacity * 2; Object[] oldTable = table; int oldLength = oldTable.length; if (oldLength == 2 * MAXIMUM_CAPACITY) { // can't expand any further ! return false; } if (oldLength >= newLength) ! return false; Object[] newTable = new Object[newLength]; *************** *** 480,485 **** --- 488,494 ---- } } table = newTable; + return true; } /** Regards, Peter > >> >> On Mon, Jul 7, 2014 at 6:54 PM, Ivan Gerasimov >> >> wrote: >> >>> Unfortunately, x + x << 1 causes the same overflow bug as 3*x: >>> >> x + (x << 1) is merely supposed to be possibly more efficient than 3*x. >> >> >>> (int)(1431655766 + 1431655766 << 1) == 2 >>> >> OK, I think my latest version doesn't have any overflow bugs. > From paul.sandoz at oracle.com Tue Jul 8 11:20:07 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 8 Jul 2014 13:20:07 +0200 Subject: [9] RFR (S): 8038261: JSR292: cache and reuse typed array accessors In-Reply-To: <4B791832-ACBC-422E-A13A-77300B658279@oracle.com> References: <5330752C.3010700@oracle.com> <53BBC36A.8040601@oracle.com> <4B791832-ACBC-422E-A13A-77300B658279@oracle.com> Message-ID: <1B69B64C-8B1D-4BC6-B215-0997AC694086@oracle.com> On Jul 8, 2014, at 12:40 PM, Paul Sandoz wrote: > > On Jul 8, 2014, at 12:09 PM, Vladimir Ivanov wrote: > >> I'd like to revive review this review thread. >> >> Updated version: >> http://cr.openjdk.java.net/~vlivanov/8038261/webrev.03/ >> > > +1 > A v. minor point. There is one newly added method InvokerBytecodeGenerator.match that is not used by this patch or the other one for 8037209. I dunno if it will be used later or not by a future patch. Paul. From paul.sandoz at oracle.com Tue Jul 8 11:22:55 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 8 Jul 2014 13:22:55 +0200 Subject: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms In-Reply-To: <53BBC340.7040509@oracle.com> References: <5322EBF2.7030209@oracle.com> <5322F3D7.9010103@oracle.com> <94F61B19-8904-42FA-9E16-CC0A6B30FD79@oracle.com> <53230184.9090007@oracle.com> <2FCC64E3-3753-4CE0-9CC6-849FF737BFB5@oracle.com> <53232FF3.9020803@oracle.com> <53305E52.2060001@oracle.com> <53BBC340.7040509@oracle.com> Message-ID: <7C610895-447C-41CD-87F8-D48A6C077744@oracle.com> On Jul 8, 2014, at 12:09 PM, Vladimir Ivanov wrote: > I'd like to revive this review thread. > > Updated version: > http://cr.openjdk.java.net/~vlivanov/8037209/webrev.04/ > Seems ok. I don't claim to be knowledgable enough in the finer points of conversion/casting/verification but i could see anything obviously wrong with the code. > Paul, I'd like to address your case (if possible) separately. Right now, I don't see any way to avoid null check you see with your tests. > Ok, thanks. I was naively pondering whether it would be worth while replacing the cast with an intrinsic Unsafe.typeProfile(Class c, Object o, boolean isNullInteresting), then that could be called with (c, instance, false), although dunno if that would be any easier to solve. Paul. From peter.levart at gmail.com Tue Jul 8 11:25:18 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 08 Jul 2014 13:25:18 +0200 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53BBCAE1.7050702@gmail.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> Message-ID: <53BBD51E.8030005@gmail.com> Hi again, Here's a version with (3*size > len) replaced with (size > len/3) as suggested by Ivan Gerasimov to avoid overflow and also fixed if block if put() that enclosed too much code (in my changed version of Martin's latest webrev): http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.02/ I don't think there's a danger of overflow in capacity() since (expectedMaxSize + (expectedMaxSize << 1)) is evaluated only if expectedMaxSize <= MAXIMUM_CAPACITY / 3; Here's a diff to latest Martin's version: *** src/share/classes/java/util/IdentityHashMap.java.mb 2014-07-08 12:37:57.267916926 +0200 --- src/share/classes/java/util/IdentityHashMap.java 2014-07-08 13:05:46.351810826 +0200 *************** *** 437,449 **** if (size == MAXIMUM_CAPACITY - 1) throw new IllegalStateException("Capacity exhausted."); modCount++; tab[i] = k; tab[i + 1] = value; size++; - int x = size + (size << 1); // Optimized form of 3 * size - if (x > len) - resize(len); // len == 2 * current capacity. return null; } --- 437,454 ---- if (size == MAXIMUM_CAPACITY - 1) throw new IllegalStateException("Capacity exhausted."); + + if (size >= len / 3 && resize(len)) { // len == 2 * current capacity. + tab = table; + len = tab.length; + i = hash(key, len); + while (tab[i] != null) + i = nextKeyIndex(i, len); + } modCount++; tab[i] = k; tab[i + 1] = value; size++; return null; } *************** *** 452,468 **** * * @param newCapacity the new capacity, must be a power of two. */ ! private void resize(int newCapacity) { // assert (newCapacity & -newCapacity) == newCapacity; // power of 2 int newLength = newCapacity * 2; Object[] oldTable = table; int oldLength = oldTable.length; if (oldLength == 2 * MAXIMUM_CAPACITY) { // can't expand any further ! return; } if (oldLength >= newLength) ! return; Object[] newTable = new Object[newLength]; --- 457,473 ---- * * @param newCapacity the new capacity, must be a power of two. */ ! private boolean resize(int newCapacity) { // assert (newCapacity & -newCapacity) == newCapacity; // power of 2 int newLength = newCapacity * 2; Object[] oldTable = table; int oldLength = oldTable.length; if (oldLength == 2 * MAXIMUM_CAPACITY) { // can't expand any further ! return false; } if (oldLength >= newLength) ! return false; Object[] newTable = new Object[newLength]; *************** *** 480,485 **** --- 485,491 ---- } } table = newTable; + return true; } /** *************** *** 494,500 **** int n = m.size(); if (n == 0) return; ! if (n + (n << 1) > table.length) // conservatively pre-expand resize(capacity(n)); for (Entry e : m.entrySet()) --- 500,506 ---- int n = m.size(); if (n == 0) return; ! if (n > table.length / 3) // conservatively pre-expand resize(capacity(n)); for (Entry e : m.entrySet()) Regards, Peter On 07/08/2014 12:41 PM, Peter Levart wrote: > On 07/08/2014 12:12 PM, Peter Levart wrote: >> On 07/08/2014 09:33 AM, Martin Buchholz wrote: >>> I've updated the webrev >>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity/ >>> >>> It now has all my TODOs done. >>> The test case has been testng-ified. >> >> Hi Martin, >> >> What happened to the desire that when OOME is thrown on resizing, IHM >> is left unchanged? >> >> Regards, Peter > > Hi Martin, > > I took your latest version of the patch and modified it a little: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.01/ > > Here's a diff to your version: > > *** src/share/classes/java/util/IdentityHashMap.java.mb 2014-07-08 > 12:37:57.267916926 +0200 > --- src/share/classes/java/util/IdentityHashMap.java 2014-07-08 > 12:34:25.739767669 +0200 > *************** > *** 437,449 **** > > if (size == MAXIMUM_CAPACITY - 1) > throw new IllegalStateException("Capacity exhausted."); > ! modCount++; > ! tab[i] = k; > ! tab[i + 1] = value; > ! size++; > ! int x = size + (size << 1); // Optimized form of 3 * size > ! if (x > len) > ! resize(len); // len == 2 * current capacity. > return null; > } > > --- 437,457 ---- > > if (size == MAXIMUM_CAPACITY - 1) > throw new IllegalStateException("Capacity exhausted."); > ! > ! int x = size + (size << 1) + 3; // Optimized form of 3 * > (size + 1) > ! if (x > len) { > ! if (resize(len)) { // len == 2 * current capacity. > ! tab = table; > ! len = tab.length; > ! i = hash(key, len); > ! while (tab[i] != null) > ! i = nextKeyIndex(i, len); > ! } > ! modCount++; > ! tab[i] = k; > ! tab[i + 1] = value; > ! size++; > ! } > return null; > } > > *************** > *** 452,468 **** > * > * @param newCapacity the new capacity, must be a power of two. > */ > ! private void resize(int newCapacity) { > // assert (newCapacity & -newCapacity) == newCapacity; // > power of 2 > int newLength = newCapacity * 2; > > Object[] oldTable = table; > int oldLength = oldTable.length; > if (oldLength == 2 * MAXIMUM_CAPACITY) { // can't expand any > further > ! return; > } > if (oldLength >= newLength) > ! return; > > Object[] newTable = new Object[newLength]; > > --- 460,476 ---- > * > * @param newCapacity the new capacity, must be a power of two. > */ > ! private boolean resize(int newCapacity) { > // assert (newCapacity & -newCapacity) == newCapacity; // > power of 2 > int newLength = newCapacity * 2; > > Object[] oldTable = table; > int oldLength = oldTable.length; > if (oldLength == 2 * MAXIMUM_CAPACITY) { // can't expand any > further > ! return false; > } > if (oldLength >= newLength) > ! return false; > > Object[] newTable = new Object[newLength]; > > *************** > *** 480,485 **** > --- 488,494 ---- > } > } > table = newTable; > + return true; > } > > /** > > > Regards, Peter > >> >>> >>> On Mon, Jul 7, 2014 at 6:54 PM, Ivan Gerasimov >>> >>> wrote: >>> >>>> Unfortunately, x + x << 1 causes the same overflow bug as 3*x: >>>> >>> x + (x << 1) is merely supposed to be possibly more efficient than 3*x. >>> >>> >>>> (int)(1431655766 + 1431655766 << 1) == 2 >>>> >>> OK, I think my latest version doesn't have any overflow bugs. >> > From vladimir.x.ivanov at oracle.com Tue Jul 8 11:35:02 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 08 Jul 2014 15:35:02 +0400 Subject: [9] RFR (S): 8038261: JSR292: cache and reuse typed array accessors In-Reply-To: <1B69B64C-8B1D-4BC6-B215-0997AC694086@oracle.com> References: <5330752C.3010700@oracle.com> <53BBC36A.8040601@oracle.com> <4B791832-ACBC-422E-A13A-77300B658279@oracle.com> <1B69B64C-8B1D-4BC6-B215-0997AC694086@oracle.com> Message-ID: <53BBD766.50400@oracle.com> >>> I'd like to revive review this review thread. >>> >>> Updated version: >>> http://cr.openjdk.java.net/~vlivanov/8038261/webrev.03/ >> +1 > A v. minor point. There is one newly added method InvokerBytecodeGenerator.match that is not used by this patch or the other one for 8037209. I dunno if it will be used later or not by a future patch. Good catch! It's a leftover from one of recent cleanups I did. Will remove it. Thanks for the prompt review! Best regards, Vladimir Ivanov From ivan.gerasimov at oracle.com Tue Jul 8 11:53:02 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 08 Jul 2014 15:53:02 +0400 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53BBD51E.8030005@gmail.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBD51E.8030005@gmail.com> Message-ID: <53BBDB9E.5080109@oracle.com> On 08.07.2014 15:25, Peter Levart wrote: > Hi again, > > Here's a version with (3*size > len) replaced with (size > len/3) as > suggested by Ivan Gerasimov to avoid overflow and also fixed if block > if put() that enclosed too much code (in my changed version of > Martin's latest webrev): > It shouldn't be needed, since size < MAXIMUM_CAPACITY-1 at this point. > http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.02/ > > I don't think there's a danger of overflow in capacity() since > (expectedMaxSize + (expectedMaxSize << 1)) is evaluated only if > expectedMaxSize <= MAXIMUM_CAPACITY / 3; > > Here's a diff to latest Martin's version: > > *** src/share/classes/java/util/IdentityHashMap.java.mb 2014-07-08 > 12:37:57.267916926 +0200 > --- src/share/classes/java/util/IdentityHashMap.java 2014-07-08 > 13:05:46.351810826 +0200 > *************** > *** 437,449 **** > > if (size == MAXIMUM_CAPACITY - 1) > throw new IllegalStateException("Capacity exhausted."); > modCount++; > tab[i] = k; > tab[i + 1] = value; > size++; > - int x = size + (size << 1); // Optimized form of 3 * size > - if (x > len) > - resize(len); // len == 2 * current capacity. > return null; > } > > --- 437,454 ---- > > if (size == MAXIMUM_CAPACITY - 1) > throw new IllegalStateException("Capacity exhausted."); > + > + if (size >= len / 3 && resize(len)) { // len == 2 * current > capacity. > + tab = table; > + len = tab.length; > + i = hash(key, len); > + while (tab[i] != null) > + i = nextKeyIndex(i, len); > + } > modCount++; > tab[i] = k; > tab[i + 1] = value; > size++; > return null; > } > > *************** > *** 452,468 **** > * > * @param newCapacity the new capacity, must be a power of two. > */ > ! private void resize(int newCapacity) { > // assert (newCapacity & -newCapacity) == newCapacity; // > power of 2 > int newLength = newCapacity * 2; > > Object[] oldTable = table; > int oldLength = oldTable.length; > if (oldLength == 2 * MAXIMUM_CAPACITY) { // can't expand any > further > ! return; > } > if (oldLength >= newLength) > ! return; > > Object[] newTable = new Object[newLength]; > > --- 457,473 ---- > * > * @param newCapacity the new capacity, must be a power of two. > */ > ! private boolean resize(int newCapacity) { > // assert (newCapacity & -newCapacity) == newCapacity; // > power of 2 > int newLength = newCapacity * 2; > > Object[] oldTable = table; > int oldLength = oldTable.length; > if (oldLength == 2 * MAXIMUM_CAPACITY) { // can't expand any > further > ! return false; > } > if (oldLength >= newLength) > ! return false; > > Object[] newTable = new Object[newLength]; > > *************** > *** 480,485 **** > --- 485,491 ---- > } > } > table = newTable; > + return true; > } > > /** > *************** > *** 494,500 **** > int n = m.size(); > if (n == 0) > return; > ! if (n + (n << 1) > table.length) // conservatively pre-expand > resize(capacity(n)); > > for (Entry e : m.entrySet()) > --- 500,506 ---- > int n = m.size(); > if (n == 0) > return; > ! if (n > table.length / 3) // conservatively pre-expand > resize(capacity(n)); > > for (Entry e : m.entrySet()) > > > Regards, Peter > > On 07/08/2014 12:41 PM, Peter Levart wrote: >> On 07/08/2014 12:12 PM, Peter Levart wrote: >>> On 07/08/2014 09:33 AM, Martin Buchholz wrote: >>>> I've updated the webrev >>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity/ >>>> >>>> It now has all my TODOs done. >>>> The test case has been testng-ified. >>> >>> Hi Martin, >>> >>> What happened to the desire that when OOME is thrown on resizing, >>> IHM is left unchanged? >>> >>> Regards, Peter >> >> Hi Martin, >> >> I took your latest version of the patch and modified it a little: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.01/ >> >> Here's a diff to your version: >> >> *** src/share/classes/java/util/IdentityHashMap.java.mb 2014-07-08 >> 12:37:57.267916926 +0200 >> --- src/share/classes/java/util/IdentityHashMap.java 2014-07-08 >> 12:34:25.739767669 +0200 >> *************** >> *** 437,449 **** >> >> if (size == MAXIMUM_CAPACITY - 1) >> throw new IllegalStateException("Capacity exhausted."); >> ! modCount++; >> ! tab[i] = k; >> ! tab[i + 1] = value; >> ! size++; >> ! int x = size + (size << 1); // Optimized form of 3 * size >> ! if (x > len) >> ! resize(len); // len == 2 * current capacity. >> return null; >> } >> >> --- 437,457 ---- >> >> if (size == MAXIMUM_CAPACITY - 1) >> throw new IllegalStateException("Capacity exhausted."); >> ! >> ! int x = size + (size << 1) + 3; // Optimized form of 3 * >> (size + 1) >> ! if (x > len) { >> ! if (resize(len)) { // len == 2 * current capacity. >> ! tab = table; >> ! len = tab.length; >> ! i = hash(key, len); >> ! while (tab[i] != null) >> ! i = nextKeyIndex(i, len); >> ! } >> ! modCount++; >> ! tab[i] = k; >> ! tab[i + 1] = value; >> ! size++; >> ! } >> return null; >> } >> >> *************** >> *** 452,468 **** >> * >> * @param newCapacity the new capacity, must be a power of two. >> */ >> ! private void resize(int newCapacity) { >> // assert (newCapacity & -newCapacity) == newCapacity; // >> power of 2 >> int newLength = newCapacity * 2; >> >> Object[] oldTable = table; >> int oldLength = oldTable.length; >> if (oldLength == 2 * MAXIMUM_CAPACITY) { // can't expand >> any further >> ! return; >> } >> if (oldLength >= newLength) >> ! return; >> >> Object[] newTable = new Object[newLength]; >> >> --- 460,476 ---- >> * >> * @param newCapacity the new capacity, must be a power of two. >> */ >> ! private boolean resize(int newCapacity) { >> // assert (newCapacity & -newCapacity) == newCapacity; // >> power of 2 >> int newLength = newCapacity * 2; >> >> Object[] oldTable = table; >> int oldLength = oldTable.length; >> if (oldLength == 2 * MAXIMUM_CAPACITY) { // can't expand >> any further >> ! return false; >> } >> if (oldLength >= newLength) >> ! return false; >> >> Object[] newTable = new Object[newLength]; >> >> *************** >> *** 480,485 **** >> --- 488,494 ---- >> } >> } >> table = newTable; >> + return true; >> } >> >> /** >> >> >> Regards, Peter >> >>> >>>> >>>> On Mon, Jul 7, 2014 at 6:54 PM, Ivan Gerasimov >>>> >>>> wrote: >>>> >>>>> Unfortunately, x + x << 1 causes the same overflow bug as 3*x: >>>>> >>>> x + (x << 1) is merely supposed to be possibly more efficient than >>>> 3*x. >>>> >>>> >>>>> (int)(1431655766 + 1431655766 << 1) == 2 >>>>> >>>> OK, I think my latest version doesn't have any overflow bugs. >>> >> > > > From peter.levart at gmail.com Tue Jul 8 12:20:10 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 08 Jul 2014 14:20:10 +0200 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53BBDB9E.5080109@oracle.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBD51E.8030005@gmail.com> <53BBDB9E.5080109@oracle.com> Message-ID: <53BBE1FA.9020807@gmail.com> On 07/08/2014 01:53 PM, Ivan Gerasimov wrote: > On 08.07.2014 15:25, Peter Levart wrote: >> Hi again, >> >> Here's a version with (3*size > len) replaced with (size > len/3) as >> suggested by Ivan Gerasimov to avoid overflow and also fixed if block >> if put() that enclosed too much code (in my changed version of >> Martin's latest webrev): >> > It shouldn't be needed, since size < MAXIMUM_CAPACITY-1 at this point. That's right. Not in put(). But in putAll() it can overflow, since the argument Map can be of any size that fits in int... So here's my 3rd variation of Martin's latest version: http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.03/ And a diff to Martin's latest version: *** src/share/classes/java/util/IdentityHashMap.java.mb 2014-07-08 12:37:57.267916926 +0200 --- src/share/classes/java/util/IdentityHashMap.java 2014-07-08 14:07:57.782843612 +0200 *************** *** 437,449 **** if (size == MAXIMUM_CAPACITY - 1) throw new IllegalStateException("Capacity exhausted."); modCount++; tab[i] = k; tab[i + 1] = value; size++; - int x = size + (size << 1); // Optimized form of 3 * size - if (x > len) - resize(len); // len == 2 * current capacity. return null; } --- 437,455 ---- if (size == MAXIMUM_CAPACITY - 1) throw new IllegalStateException("Capacity exhausted."); + + int x = size + (size << 1) + 3; // Optimized form of 3 * (size + 1) + if (x > len && resize(len)) { // len == 2 * current capacity. + tab = table; + len = tab.length; + i = hash(key, len); + while (tab[i] != null) + i = nextKeyIndex(i, len); + } modCount++; tab[i] = k; tab[i + 1] = value; size++; return null; } *************** *** 452,468 **** * * @param newCapacity the new capacity, must be a power of two. */ ! private void resize(int newCapacity) { // assert (newCapacity & -newCapacity) == newCapacity; // power of 2 - int newLength = newCapacity * 2; Object[] oldTable = table; int oldLength = oldTable.length; if (oldLength == 2 * MAXIMUM_CAPACITY) { // can't expand any further ! return; } if (oldLength >= newLength) ! return; Object[] newTable = new Object[newLength]; --- 458,474 ---- * * @param newCapacity the new capacity, must be a power of two. */ ! private boolean resize(int newCapacity) { // assert (newCapacity & -newCapacity) == newCapacity; // power of 2 Object[] oldTable = table; int oldLength = oldTable.length; if (oldLength == 2 * MAXIMUM_CAPACITY) { // can't expand any further ! return false; } + int newLength = newCapacity * 2; if (oldLength >= newLength) ! return false; Object[] newTable = new Object[newLength]; *************** *** 480,485 **** --- 486,492 ---- } } table = newTable; + return true; } /** *************** *** 494,500 **** int n = m.size(); if (n == 0) return; ! if (n + (n << 1) > table.length) // conservatively pre-expand resize(capacity(n)); for (Entry e : m.entrySet()) --- 501,507 ---- int n = m.size(); if (n == 0) return; ! if (n > table.length / 3) // conservatively pre-expand resize(capacity(n)); for (Entry e : m.entrySet()) From david.holmes at oracle.com Tue Jul 8 12:25:52 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 08 Jul 2014 22:25:52 +1000 Subject: RFR [8035975] Pattern.compile(String, int) fails to throw IllegalArgumentException In-Reply-To: <53BAF42C.6050008@oracle.com> References: <53BAD3BE.3040609@oracle.com> <53BADB1D.1000008@oracle.com> <53BAF42C.6050008@oracle.com> Message-ID: <53BBE350.5060605@oracle.com> On 8/07/2014 5:25 AM, Ivan Gerasimov wrote: > Thanks you Sherman for review! > > On 07.07.2014 21:38, Xueming Shen wrote: >> On 07/07/2014 10:07 AM, Ivan Gerasimov wrote: >>> Hello! >>> >>> The javadoc says that Pattern.compile(String regex, int flag) will >>> throw IllegalArgumentException, if flag contains an invalid bit set. >>> However, it fails to do so. >>> >>> Would you please help review the simple fix for that? >>> Alternatively, we could just remove the corresponding @throws part, >>> but that would change the spec. >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8035975 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8035975/0/webrev/ >>> >>> Sincerely yours, >>> Ivan >> >> Looks fine. But given it's a behavior change, you probably still need >> a CCC for it. >> > Okay, just filed one. Complying with the spec probably doesn't need a CCC but this seems to be a long standing non-compliance so I agree it is worthwhile. Arguably this may introduce an incompatibility that we don't want to introduce after all this time - so it might be better to relax the spec to allow and exception to be thrown, but not require it. I'm surprised this is no JCK test that covers this. David ----- > Sincerely yours, > Ivan > >> thanks! >> -Sherman >> >> > From peter.levart at gmail.com Tue Jul 8 12:30:51 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 08 Jul 2014 14:30:51 +0200 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53BBE1FA.9020807@gmail.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBD51E.8030005@gmail.com> <53BBDB9E.5080109@oracle.com> <53BBE1FA.9020807@gmail.com> Message-ID: <53BBE47B.5020003@gmail.com> On 07/08/2014 02:20 PM, Peter Levart wrote: > That's right. Not in put(). But in putAll() it can overflow, since the > argument Map can be of any size that fits in int... So here's my 3rd > variation of Martin's latest version: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.03/ > Another bug in my part 8-( I should've used the null-masked 'k' instead of 'key' in the index re-compute block: http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.04/ And diff to Martin's patch: *** src/share/classes/java/util/IdentityHashMap.java.mb 2014-07-08 12:37:57.267916926 +0200 --- src/share/classes/java/util/IdentityHashMap.java 2014-07-08 14:23:25.141249319 +0200 *************** *** 437,449 **** if (size == MAXIMUM_CAPACITY - 1) throw new IllegalStateException("Capacity exhausted."); modCount++; tab[i] = k; tab[i + 1] = value; size++; - int x = size + (size << 1); // Optimized form of 3 * size - if (x > len) - resize(len); // len == 2 * current capacity. return null; } --- 437,455 ---- if (size == MAXIMUM_CAPACITY - 1) throw new IllegalStateException("Capacity exhausted."); + + int x = size + (size << 1) + 3; // Optimized form of 3 * (size + 1) + if (x > len && resize(len)) { // len == 2 * current capacity. + tab = table; + len = tab.length; + i = hash(k, len); + while (tab[i] != null) + i = nextKeyIndex(i, len); + } modCount++; tab[i] = k; tab[i + 1] = value; size++; return null; } *************** *** 452,468 **** * * @param newCapacity the new capacity, must be a power of two. */ ! private void resize(int newCapacity) { // assert (newCapacity & -newCapacity) == newCapacity; // power of 2 - int newLength = newCapacity * 2; Object[] oldTable = table; int oldLength = oldTable.length; if (oldLength == 2 * MAXIMUM_CAPACITY) { // can't expand any further ! return; } if (oldLength >= newLength) ! return; Object[] newTable = new Object[newLength]; --- 458,474 ---- * * @param newCapacity the new capacity, must be a power of two. */ ! private boolean resize(int newCapacity) { // assert (newCapacity & -newCapacity) == newCapacity; // power of 2 Object[] oldTable = table; int oldLength = oldTable.length; if (oldLength == 2 * MAXIMUM_CAPACITY) { // can't expand any further ! return false; } + int newLength = newCapacity * 2; if (oldLength >= newLength) ! return false; Object[] newTable = new Object[newLength]; *************** *** 480,485 **** --- 486,492 ---- } } table = newTable; + return true; } /** *************** *** 494,500 **** int n = m.size(); if (n == 0) return; ! if (n + (n << 1) > table.length) // conservatively pre-expand resize(capacity(n)); for (Entry e : m.entrySet()) --- 501,507 ---- int n = m.size(); if (n == 0) return; ! if (n > table.length / 3) // conservatively pre-expand resize(capacity(n)); for (Entry e : m.entrySet()) Regards, Peter From daniel.fuchs at oracle.com Tue Jul 8 12:58:26 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 08 Jul 2014 14:58:26 +0200 Subject: RFR: 8048913: java/util/logging/LoggingDeadlock2.java times out Message-ID: <53BBEAF2.7030000@oracle.com> Hi, Please find below a fix for 8048913: java/util/logging/LoggingDeadlock2.java times out http://cr.openjdk.java.net/~dfuchs/webrev_8048913/webrev.00/ jdk/test/java/util/logging/LoggingDeadlock2.java has been seen failing in timeout in some of our internal nightly builds. java/util/logging/LoggingDeadlock2.java StatusError Program `...' interrupted! (timed out?) As far as I could see this mostly happened with fastdebug builds, and the log I was able to examine showed that -Xcomp was also used. I believe that the issue here is that: 1. jdk/test/java/util/logging/LoggingDeadlock2.java starts a JVM subprocess 2. the @run command line defines /timeout=15 My suggestion is thus simply to remove the /timeout=15 from the @run command line, relying on the default jtreg timeout instead, which hopefully will have been tuned for the global configuration (fastdebug + -Xcomp) in which the testsuite is running. best regards, -- daniel From ivan.gerasimov at oracle.com Tue Jul 8 13:00:30 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 08 Jul 2014 17:00:30 +0400 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53BBCAE1.7050702@gmail.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> Message-ID: <53BBEB6E.7050207@oracle.com> On 08.07.2014 14:41, Peter Levart wrote: > On 07/08/2014 12:12 PM, Peter Levart wrote: >> On 07/08/2014 09:33 AM, Martin Buchholz wrote: >>> I've updated the webrev >>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity/ >>> >>> It now has all my TODOs done. >>> The test case has been testng-ified. >> >> Hi Martin, >> >> What happened to the desire that when OOME is thrown on resizing, IHM >> is left unchanged? >> >> Regards, Peter > > Hi Martin, > > I took your latest version of the patch and modified it a little: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.01/ > But isn't it post-insert-resize vs pre-insert-resize problem Doug mentioned above? I've tested a similar fix and it showed slow down of the put() operation. > Here's a diff to your version: > > *** src/share/classes/java/util/IdentityHashMap.java.mb 2014-07-08 > 12:37:57.267916926 +0200 > --- src/share/classes/java/util/IdentityHashMap.java 2014-07-08 > 12:34:25.739767669 +0200 > *************** > *** 437,449 **** > > if (size == MAXIMUM_CAPACITY - 1) > throw new IllegalStateException("Capacity exhausted."); > ! modCount++; > ! tab[i] = k; > ! tab[i + 1] = value; > ! size++; > ! int x = size + (size << 1); // Optimized form of 3 * size > ! if (x > len) > ! resize(len); // len == 2 * current capacity. > return null; > } > > --- 437,457 ---- > > if (size == MAXIMUM_CAPACITY - 1) > throw new IllegalStateException("Capacity exhausted."); > ! > ! int x = size + (size << 1) + 3; // Optimized form of 3 * > (size + 1) > ! if (x > len) { > ! if (resize(len)) { // len == 2 * current capacity. > ! tab = table; > ! len = tab.length; > ! i = hash(key, len); > ! while (tab[i] != null) > ! i = nextKeyIndex(i, len); > ! } > ! modCount++; > ! tab[i] = k; > ! tab[i + 1] = value; > ! size++; > ! } > return null; > } > > *************** > *** 452,468 **** > * > * @param newCapacity the new capacity, must be a power of two. > */ > ! private void resize(int newCapacity) { > // assert (newCapacity & -newCapacity) == newCapacity; // > power of 2 > int newLength = newCapacity * 2; > > Object[] oldTable = table; > int oldLength = oldTable.length; > if (oldLength == 2 * MAXIMUM_CAPACITY) { // can't expand any > further > ! return; > } > if (oldLength >= newLength) > ! return; > > Object[] newTable = new Object[newLength]; > > --- 460,476 ---- > * > * @param newCapacity the new capacity, must be a power of two. > */ > ! private boolean resize(int newCapacity) { > // assert (newCapacity & -newCapacity) == newCapacity; // > power of 2 > int newLength = newCapacity * 2; > > Object[] oldTable = table; > int oldLength = oldTable.length; > if (oldLength == 2 * MAXIMUM_CAPACITY) { // can't expand any > further > ! return false; > } > if (oldLength >= newLength) > ! return false; > > Object[] newTable = new Object[newLength]; > > *************** > *** 480,485 **** > --- 488,494 ---- > } > } > table = newTable; > + return true; > } > > /** > > > Regards, Peter > >> >>> >>> On Mon, Jul 7, 2014 at 6:54 PM, Ivan Gerasimov >>> >>> wrote: >>> >>>> Unfortunately, x + x << 1 causes the same overflow bug as 3*x: >>>> >>> x + (x << 1) is merely supposed to be possibly more efficient than 3*x. >>> >>> >>>> (int)(1431655766 + 1431655766 << 1) == 2 >>>> >>> OK, I think my latest version doesn't have any overflow bugs. >> > > > From martinrb at google.com Tue Jul 8 13:19:24 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 8 Jul 2014 06:19:24 -0700 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53BBC40E.6050305@gmail.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> Message-ID: On Tue, Jul 8, 2014 at 3:12 AM, Peter Levart wrote: > On 07/08/2014 09:33 AM, Martin Buchholz wrote: > >> I've updated the webrev >> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ >> IdentityHashMap-capacity/ >> It now has all my TODOs done. >> The test case has been testng-ified. >> > > Hi Martin, > > What happened to the desire that when OOME is thrown on resizing, IHM is > left unchanged? > Hi Peter, That's a fine goal but not one I've been worrying about. From martinrb at google.com Tue Jul 8 13:56:16 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 8 Jul 2014 06:56:16 -0700 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53BBE47B.5020003@gmail.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBD51E.8030005@gmail.com> <53BBDB9E.5080109@oracle.com> <53BBE1FA.9020807@gmail.com> <53BBE47B.5020003@gmail.com> Message-ID: On Tue, Jul 8, 2014 at 5:30 AM, Peter Levart wrote: > On 07/08/2014 02:20 PM, Peter Levart wrote: > >> That's right. Not in put(). But in putAll() it can overflow, since the >> argument Map can be of any size that fits in int... > > I took another look at putAll. I think we can do more simply, relying on the checks in capacity and resize: int n = m.size(); if (n == 0) return; - if (n > threshold) // conservatively pre-expand - resize(capacity(n)); + if (n > size) + resize(capacity(n)); // conservatively pre-expand for (Entry e : m.entrySet()) put(e.getKey(), e.getValue()); Also, note I'm trying to avoid (relatively expensive) integer division, except at compile time. From ivan.gerasimov at oracle.com Tue Jul 8 14:01:32 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 08 Jul 2014 18:01:32 +0400 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> Message-ID: <53BBF9BC.50808@oracle.com> On 08.07.2014 4:44, Martin Buchholz wrote: > > > > On Mon, Jul 7, 2014 at 9:41 AM, Martin Buchholz > wrote: > > I'd like to offer an alternative version of this change. webrev > coming soon. > > > Here's the promised webrev. > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity/ > > > - Fixes a typo in the javadoc. > - removes the "threshold" field (WAT, a cache to avoid multiplying by 3?) > - optimizes 3*x into x + x << 1 My personal preference would be x + x + x, but I thought JIT can do this kind of optimizations itself. Out of curiosity I've created a microbenchmark: Benchmark Mode Samples Score Score error Units o.s.MyBenchmark.testMethod_01_X3 avgt 200 5.900 0.041 ns/op o.s.MyBenchmark.testMethod_02_PPP avgt 200 6.029 0.035 ns/op o.s.MyBenchmark.testMethod_03_PSH avgt 200 5.907 0.071 ns/op On my machine 3*x and x + (x<<1) appear to be of the same speed (#1 and #3 above). x + x + x (case #2) happens to be ~2% slower. Given the optimization doesn't introduce any speedup, wouldn't it be better to use 3*x for its clarity? Sincerely yours, Ivan > - adds more test assertions > - removes the unusual 4/3 slack space for expansion on deserialization. > > TODO: the test should be testng-ified, I think. > > From mandy.chung at oracle.com Tue Jul 8 14:59:39 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 08 Jul 2014 07:59:39 -0700 Subject: Review request: 8029548 (jdeps) use @jdk.Exported to determine supported vs JDK internal API In-Reply-To: <53AB2F38.7030700@oracle.com> References: <53AB2F38.7030700@oracle.com> Message-ID: <53BC075B.5040603@oracle.com> I took out the special case for javax.jnlp and follow up the change in deploy to use @jdk.Exported to indicate its supportedness. I also added a new test case to check the dot file output: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8029548/webrev.01 thanks Mandy On 6/25/14 1:21 PM, Mandy Chung wrote: > This patch is also intended to target for 8u40 backport. It fixes > the following issues: > > JDK-8029548 (jdeps) use @jdk.Exported to determine supported vs JDK > internal API > JDK-8039007 jdeps incorrectly reports javax.jnlp as JDK internal APIs > JDK-8031092 jdeps does not recognize --help option. > JDK-8048063 (jdeps) Add filtering capability > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8029548/webrev.00/ > > jdeps will determine if it's a JDK internal API by checking the > @jdk.Exported. > It also reads tools.jar and flags if they are non-exported. javax.jnlp is > supported API but not annotated with @jdk.Exported and so we special case > it as a workaround. A new -filter option is added to provide an easy > way to do filtering e.g. -filter java.lang.*, -filter:archive to filter > out all dependences from the same archive (i.e the input JAR file or > directory). The default is changed to filter out the dependences > within the same package. I also have cleaned up and refactored some code > between JdepsTask and Analyzer to prepare for source restructuring > and modularization work. > > thanks > Mandy > From peter.levart at gmail.com Tue Jul 8 15:06:02 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 08 Jul 2014 17:06:02 +0200 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53BBEB6E.7050207@oracle.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> Message-ID: <53BC08DA.4020007@gmail.com> On 07/08/2014 03:00 PM, Ivan Gerasimov wrote: >> I took your latest version of the patch and modified it a little: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.01/ >> > > But isn't it post-insert-resize vs pre-insert-resize problem Doug > mentioned above? > I've tested a similar fix and it showed slow down of the put() operation. Hi Ivan, Might be that it has to do with # of bytecodes in the method and in-lining threshold. I modified it once more, to make put() method as short as possible: http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.05/ With this, I ran the following JMH benchmark: @State(Scope.Thread) public class IHMBench { Map map = new IdentityHashMap(); @Benchmark public void putNewObject(Blackhole bh) { Object o = new Object(); bh.consume(map.put(o, o)); if (map.size() > 100000) { map = new IdentityHashMap(); } } } I get the following results on my i7/Linux using: java -Xmx4G -Xms4G -XX:+UseParallelGC -jar benchmarks.jar -f 0 -i 10 -wi 8 -gc 1 -t 1 Original: Benchmark Mode Samples Score Score error Units j.t.IHMBench.putNewObject thrpt 10 13088296.198 403446.449 ops/s Patched: Benchmark Mode Samples Score Score error Units j.t.IHMBench.putNewObject thrpt 10 13180594.537 282047.154 ops/s Can you run your test with webrev.05 and see what you get ? Regards, Peter From peter.levart at gmail.com Tue Jul 8 15:08:03 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 08 Jul 2014 17:08:03 +0200 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBD51E.8030005@gmail.com> <53BBDB9E.5080109@oracle.com> <53BBE1FA.9020807@gmail.com> <53BBE47B.5020003@gmail.com> Message-ID: <53BC0953.6000304@gmail.com> On 07/08/2014 03:56 PM, Martin Buchholz wrote: > On Tue, Jul 8, 2014 at 5:30 AM, Peter Levart wrote: > >> On 07/08/2014 02:20 PM, Peter Levart wrote: >> >>> That's right. Not in put(). But in putAll() it can overflow, since the >>> argument Map can be of any size that fits in int... >> > I took another look at putAll. I think we can do more simply, relying on > the checks in capacity and resize: > > int n = m.size(); > if (n == 0) > return; > - if (n > threshold) // conservatively pre-expand > - resize(capacity(n)); > + if (n > size) > + resize(capacity(n)); // conservatively pre-expand > > for (Entry e : m.entrySet()) > put(e.getKey(), e.getValue()); > > Also, note I'm trying to avoid (relatively expensive) integer division, > except at compile time. > Nice. Peter From martinrb at google.com Tue Jul 8 15:14:04 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 8 Jul 2014 08:14:04 -0700 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53BBF9BC.50808@oracle.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BBF9BC.50808@oracle.com> Message-ID: So ... using 3*x is never wrong, and optimizing to x + (x << 1) is at best only going to save a couple of cycles, so 3*x is the right choice except for the most performance sensitive code. In java.util, we tend to go further and write optimal code even when hotspot is likely to make the same optimizations, partly under Doug Lea's performance-obsessed influence. Also, microbenchmarking is notoriously difficult. If you've written a microbenchmark, it would be good to check it in somewhere. I don't know what current openjdk practice is for that... On Tue, Jul 8, 2014 at 7:01 AM, Ivan Gerasimov wrote: > > On 08.07.2014 4:44, Martin Buchholz wrote: > > > > > On Mon, Jul 7, 2014 at 9:41 AM, Martin Buchholz > wrote: > >> I'd like to offer an alternative version of this change. webrev coming >> soon. >> > > Here's the promised webrev. > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity/ > > - Fixes a typo in the javadoc. > - removes the "threshold" field (WAT, a cache to avoid multiplying by 3?) > - optimizes 3*x into x + x << 1 > > > My personal preference would be x + x + x, but I thought JIT can do this > kind of optimizations itself. > Out of curiosity I've created a microbenchmark: > > Benchmark Mode Samples Score Score > error Units > o.s.MyBenchmark.testMethod_01_X3 avgt 200 5.900 > 0.041 ns/op > o.s.MyBenchmark.testMethod_02_PPP avgt 200 6.029 > 0.035 ns/op > o.s.MyBenchmark.testMethod_03_PSH avgt 200 5.907 > 0.071 ns/op > > On my machine 3*x and x + (x<<1) appear to be of the same speed (#1 and #3 > above). > x + x + x (case #2) happens to be ~2% slower. > > Given the optimization doesn't introduce any speedup, wouldn't it be > better to use 3*x for its clarity? > > Sincerely yours, > Ivan > > > > - adds more test assertions > - removes the unusual 4/3 slack space for expansion on deserialization. > > TODO: the test should be testng-ified, I think. > > > > From daniel.fuchs at oracle.com Tue Jul 8 15:21:26 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 08 Jul 2014 17:21:26 +0200 Subject: Review request: 8029548 (jdeps) use @jdk.Exported to determine supported vs JDK internal API In-Reply-To: <53BC075B.5040603@oracle.com> References: <53AB2F38.7030700@oracle.com> <53BC075B.5040603@oracle.com> Message-ID: <53BC0C76.8070208@oracle.com> Hi Mandy, On 7/8/14 4:59 PM, Mandy Chung wrote: > I took out the special case for javax.jnlp and follow up the change in > deploy to use @jdk.Exported to indicate its supportedness. I also added > a new test case to check the dot file output: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8029548/webrev.01 I installed the new patch and played with it, and I find the behavior of jdeps -R much clearer than in your first version. Thanks for clarifying the help messages too! Otherwise - I browsed through the changes and didn't see anything obviously wrong. best regards, -- daniel > > thanks > Mandy > > On 6/25/14 1:21 PM, Mandy Chung wrote: >> This patch is also intended to target for 8u40 backport. It fixes >> the following issues: >> >> JDK-8029548 (jdeps) use @jdk.Exported to determine supported vs JDK >> internal API >> JDK-8039007 jdeps incorrectly reports javax.jnlp as JDK internal APIs >> JDK-8031092 jdeps does not recognize --help option. >> JDK-8048063 (jdeps) Add filtering capability >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8029548/webrev.00/ >> >> jdeps will determine if it's a JDK internal API by checking the >> @jdk.Exported. >> It also reads tools.jar and flags if they are non-exported. javax.jnlp is >> supported API but not annotated with @jdk.Exported and so we special case >> it as a workaround. A new -filter option is added to provide an easy >> way to do filtering e.g. -filter java.lang.*, -filter:archive to filter >> out all dependences from the same archive (i.e the input JAR file or >> directory). The default is changed to filter out the dependences >> within the same package. I also have cleaned up and refactored some code >> between JdepsTask and Analyzer to prepare for source restructuring >> and modularization work. >> >> thanks >> Mandy >> > From lance.andersen at oracle.com Tue Jul 8 15:33:13 2014 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 8 Jul 2014 11:33:13 -0400 Subject: timing out on an hg pull: error: pretxnchangegroup hook raised an exception: Message-ID: <8CB9415B-216C-48B4-946D-05AC5B838169@oracle.com> Is anyone else seeing the following timeout? I had this issue last week and thought it might have been a hiccup on the systems but trying again today and the same error: hg pull pulling from http://hg.openjdk.java.net/jdk9/dev/jdk searching for changes adding changesets adding manifests adding file changes added 327 changesets with 2611 changes to 2210 files error: pretxnchangegroup hook raised an exception: transaction abort! rollback completed abort: error: Operation timed out Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From joe.darcy at oracle.com Tue Jul 8 16:24:33 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 08 Jul 2014 09:24:33 -0700 Subject: RFR [8035975] Pattern.compile(String, int) fails to throw IllegalArgumentException In-Reply-To: <53BBE350.5060605@oracle.com> References: <53BAD3BE.3040609@oracle.com> <53BADB1D.1000008@oracle.com> <53BAF42C.6050008@oracle.com> <53BBE350.5060605@oracle.com> Message-ID: <53BC1B41.8070608@oracle.com> Hello, A comment on a ccc request for this kind of change below... On 07/08/2014 05:25 AM, David Holmes wrote: > On 8/07/2014 5:25 AM, Ivan Gerasimov wrote: >> Thanks you Sherman for review! >> >> On 07.07.2014 21:38, Xueming Shen wrote: >>> On 07/07/2014 10:07 AM, Ivan Gerasimov wrote: >>>> Hello! >>>> >>>> The javadoc says that Pattern.compile(String regex, int flag) will >>>> throw IllegalArgumentException, if flag contains an invalid bit set. >>>> However, it fails to do so. >>>> >>>> Would you please help review the simple fix for that? >>>> Alternatively, we could just remove the corresponding @throws part, >>>> but that would change the spec. >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8035975 >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8035975/0/webrev/ >>>> >>>> Sincerely yours, >>>> Ivan >>> >>> Looks fine. But given it's a behavior change, you probably still need >>> a CCC for it. >>> >> Okay, just filed one. > > Complying with the spec probably doesn't need a CCC but this seems to > be a long standing non-compliance so I agree it is worthwhile. > Arguably this may introduce an incompatibility that we don't want to > introduce after all this time - so it might be better to relax the > spec to allow and exception to be thrown, but not require it. > > I'm surprised this is no JCK test that covers this. > On those rare occasions when it comes to our intention that the long-standing behavior of a method differs from its long-standing specification, the default resolution is to change the specification to match the implementation. Developers can and do rely on what the implementation actually does and we estimate change the specification has a lower compatibility impact overall. There are certainly also times when the implementation is changed to match the specification instead; sorted out those trade-offs is part of the ccc process. -Joe From joe.darcy at oracle.com Tue Jul 8 16:43:01 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 08 Jul 2014 09:43:01 -0700 Subject: Review request: 8029548 (jdeps) use @jdk.Exported to determine supported vs JDK internal API In-Reply-To: <53BC075B.5040603@oracle.com> References: <53AB2F38.7030700@oracle.com> <53BC075B.5040603@oracle.com> Message-ID: <53BC1F95.3090607@oracle.com> A note on the intended use of jdk.Exported; that annotation is intended for use on JDK-specific classes and *not* on classes that are part of a Java SE API: "This annotation should only be applied to types and packages /outside/ of the Java SE namespaces of |java.*| and |javax.*| packages." http://docs.oracle.com/javase/jp/8/jdk/api/javac/tree/jdk/Exported.html So while javax.jnlp is not part of the Java SE platform API, I think it is a stretch to apply jdk.Exported to it. Cheers, -Joe On 07/08/2014 07:59 AM, Mandy Chung wrote: > I took out the special case for javax.jnlp and follow up the change in > deploy to use @jdk.Exported to indicate its supportedness. I also > added a new test case to check the dot file output: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8029548/webrev.01 > > thanks > Mandy > > On 6/25/14 1:21 PM, Mandy Chung wrote: >> This patch is also intended to target for 8u40 backport. It fixes >> the following issues: >> >> JDK-8029548 (jdeps) use @jdk.Exported to determine supported vs JDK >> internal API >> JDK-8039007 jdeps incorrectly reports javax.jnlp as JDK internal APIs >> JDK-8031092 jdeps does not recognize --help option. >> JDK-8048063 (jdeps) Add filtering capability >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8029548/webrev.00/ >> >> jdeps will determine if it's a JDK internal API by checking the >> @jdk.Exported. >> It also reads tools.jar and flags if they are non-exported. >> javax.jnlp is >> supported API but not annotated with @jdk.Exported and so we special >> case >> it as a workaround. A new -filter option is added to provide an easy >> way to do filtering e.g. -filter java.lang.*, -filter:archive to filter >> out all dependences from the same archive (i.e the input JAR file or >> directory). The default is changed to filter out the dependences >> within the same package. I also have cleaned up and refactored some >> code >> between JdepsTask and Analyzer to prepare for source restructuring >> and modularization work. >> >> thanks >> Mandy >> > From mandy.chung at oracle.com Tue Jul 8 17:45:09 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 08 Jul 2014 10:45:09 -0700 Subject: Review request: 8029548 (jdeps) use @jdk.Exported to determine supported vs JDK internal API In-Reply-To: <53BC1F95.3090607@oracle.com> References: <53AB2F38.7030700@oracle.com> <53BC075B.5040603@oracle.com> <53BC1F95.3090607@oracle.com> Message-ID: <53BC2E25.6000202@oracle.com> On 7/8/14 9:43 AM, Joe Darcy wrote: > A note on the intended use of jdk.Exported; that annotation is > intended for use on JDK-specific classes and *not* on classes that are > part of a Java SE API: > > "This annotation should only be applied to types and packages > /outside/ of the Java SE namespaces of |java.*| and |javax.*| packages." > http://docs.oracle.com/javase/jp/8/jdk/api/javac/tree/jdk/Exported.html > > So while javax.jnlp is not part of the Java SE platform API, I think > it is a stretch to apply jdk.Exported to it. > Agree it's kind of a stretch. This is an interim solution to help transition to modules that may be ok to live it? Mandy > Cheers, > > -Joe > > On 07/08/2014 07:59 AM, Mandy Chung wrote: >> I took out the special case for javax.jnlp and follow up the change >> in deploy to use @jdk.Exported to indicate its supportedness. I also >> added a new test case to check the dot file output: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8029548/webrev.01 >> >> thanks >> Mandy >> >> On 6/25/14 1:21 PM, Mandy Chung wrote: >>> This patch is also intended to target for 8u40 backport. It fixes >>> the following issues: >>> >>> JDK-8029548 (jdeps) use @jdk.Exported to determine supported vs JDK >>> internal API >>> JDK-8039007 jdeps incorrectly reports javax.jnlp as JDK internal APIs >>> JDK-8031092 jdeps does not recognize --help option. >>> JDK-8048063 (jdeps) Add filtering capability >>> >>> Webrev at: >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8029548/webrev.00/ >>> >>> jdeps will determine if it's a JDK internal API by checking the >>> @jdk.Exported. >>> It also reads tools.jar and flags if they are non-exported. >>> javax.jnlp is >>> supported API but not annotated with @jdk.Exported and so we special >>> case >>> it as a workaround. A new -filter option is added to provide an easy >>> way to do filtering e.g. -filter java.lang.*, -filter:archive to filter >>> out all dependences from the same archive (i.e the input JAR file or >>> directory). The default is changed to filter out the dependences >>> within the same package. I also have cleaned up and refactored some >>> code >>> between JdepsTask and Analyzer to prepare for source restructuring >>> and modularization work. >>> >>> thanks >>> Mandy >>> >> > From mandy.chung at oracle.com Tue Jul 8 18:09:23 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 08 Jul 2014 11:09:23 -0700 Subject: Review request: 8029548 (jdeps) use @jdk.Exported to determine supported vs JDK internal API In-Reply-To: <53BC0C76.8070208@oracle.com> References: <53AB2F38.7030700@oracle.com> <53BC075B.5040603@oracle.com> <53BC0C76.8070208@oracle.com> Message-ID: <53BC33D3.3040905@oracle.com> Thanks Daniel. Mandy On 7/8/14 8:21 AM, Daniel Fuchs wrote: > Hi Mandy, > > On 7/8/14 4:59 PM, Mandy Chung wrote: >> I took out the special case for javax.jnlp and follow up the change in >> deploy to use @jdk.Exported to indicate its supportedness. I also added >> a new test case to check the dot file output: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8029548/webrev.01 > > I installed the new patch and played with it, and I find the behavior > of jdeps -R much clearer than in your first version. > > Thanks for clarifying the help messages too! > > Otherwise - I browsed through the changes and didn't see anything > obviously wrong. > > best regards, > > -- daniel > >> >> thanks >> Mandy >> >> On 6/25/14 1:21 PM, Mandy Chung wrote: >>> This patch is also intended to target for 8u40 backport. It fixes >>> the following issues: >>> >>> JDK-8029548 (jdeps) use @jdk.Exported to determine supported vs JDK >>> internal API >>> JDK-8039007 jdeps incorrectly reports javax.jnlp as JDK internal APIs >>> JDK-8031092 jdeps does not recognize --help option. >>> JDK-8048063 (jdeps) Add filtering capability >>> >>> Webrev at: >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8029548/webrev.00/ >>> >>> jdeps will determine if it's a JDK internal API by checking the >>> @jdk.Exported. >>> It also reads tools.jar and flags if they are non-exported. >>> javax.jnlp is >>> supported API but not annotated with @jdk.Exported and so we special >>> case >>> it as a workaround. A new -filter option is added to provide an easy >>> way to do filtering e.g. -filter java.lang.*, -filter:archive to filter >>> out all dependences from the same archive (i.e the input JAR file or >>> directory). The default is changed to filter out the dependences >>> within the same package. I also have cleaned up and refactored some >>> code >>> between JdepsTask and Analyzer to prepare for source restructuring >>> and modularization work. >>> >>> thanks >>> Mandy >>> >> > From ivan.gerasimov at oracle.com Tue Jul 8 18:43:54 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 08 Jul 2014 22:43:54 +0400 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BBF9BC.50808@oracle.com> Message-ID: <53BC3BEA.3080300@oracle.com> Given the table size if a power of two, another possible optimization would be private static int nextKeyIndex(int i, int len) { - return (i + 2 < len ? i + 2 : 0); + return (i + 2) & (len - 1); } Or even + int m = len - 1; while ( (item = tab[i]) != null) { ... - i = nextKeyIndex(i, len); + i = (i + 2) & m; } where ever applicable. On 08.07.2014 19:14, Martin Buchholz wrote: > So ... using 3*x is never wrong, and optimizing to x + (x << 1) is at > best only going to save a couple of cycles, so 3*x is the right choice > except for the most performance sensitive code. > > In java.util, we tend to go further and write optimal code even when > hotspot is likely to make the same optimizations, partly under Doug > Lea's performance-obsessed influence. > > Also, microbenchmarking is notoriously difficult. > > If you've written a microbenchmark, it would be good to check it in > somewhere. I don't know what current openjdk practice is for that... > > > On Tue, Jul 8, 2014 at 7:01 AM, Ivan Gerasimov > > wrote: > > > On 08.07.2014 4:44, Martin Buchholz wrote: >> >> >> >> On Mon, Jul 7, 2014 at 9:41 AM, Martin Buchholz >> > wrote: >> >> I'd like to offer an alternative version of this change. >> webrev coming soon. >> >> >> Here's the promised webrev. >> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity/ >> >> >> - Fixes a typo in the javadoc. >> - removes the "threshold" field (WAT, a cache to avoid >> multiplying by 3?) >> - optimizes 3*x into x + x << 1 > > My personal preference would be x + x + x, but I thought JIT can > do this kind of optimizations itself. > Out of curiosity I've created a microbenchmark: > > Benchmark Mode Samples Score > Score error Units > o.s.MyBenchmark.testMethod_01_X3 avgt 200 5.900 > 0.041 ns/op > o.s.MyBenchmark.testMethod_02_PPP avgt 200 6.029 > 0.035 ns/op > o.s.MyBenchmark.testMethod_03_PSH avgt 200 5.907 > 0.071 ns/op > > On my machine 3*x and x + (x<<1) appear to be of the same speed > (#1 and #3 above). > x + x + x (case #2) happens to be ~2% slower. > > Given the optimization doesn't introduce any speedup, wouldn't it > be better to use 3*x for its clarity? > > Sincerely yours, > Ivan > > > >> - adds more test assertions >> - removes the unusual 4/3 slack space for expansion on >> deserialization. >> >> TODO: the test should be testng-ified, I think. >> >> > > From john.r.rose at oracle.com Tue Jul 8 19:09:10 2014 From: john.r.rose at oracle.com (John Rose) Date: Tue, 8 Jul 2014 12:09:10 -0700 Subject: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms In-Reply-To: <53BBC340.7040509@oracle.com> References: <5322EBF2.7030209@oracle.com> <5322F3D7.9010103@oracle.com> <94F61B19-8904-42FA-9E16-CC0A6B30FD79@oracle.com> <53230184.9090007@oracle.com> <2FCC64E3-3753-4CE0-9CC6-849FF737BFB5@oracle.com> <53232FF3.9020803@oracle.com> <53305E52.2060001@oracle.com> <53BBC340.7040509@oracle.com> Message-ID: <7FAEB94F-EB98-49A9-A4B0-9B4A6B730CA9@oracle.com> Regarding the extra cast in accessor logic that Paul picked up on: That may be a left-over from obsolete versions of the code, or it may cover for some corner cases, or it could possibly be a re-assurance to the JIT. Generally speaking, we lean heavily on MH types to guarantee a priori correctness of argument types. Paul is right that the stored value type is already validated and (except for corner cases we may be neglecting) does not need re-validation via a cast. It might be an interesting experiment to replace the cast with an assert. Sometimes corner cases bite you. For example, an array store check is necessary, if the type is an interface, because interfaces are weakly checked all the way up to aastore or invokeinterface. Sometimes the JIT cannot see the type assurances implicit in a MH type, and so (when choosing internal MH code shapes) we must choose between handing the JIT code that is not locally verifiable, or adding "reassurance" casts to repair the local verifiability of the code. If the JIT thinks it sees badly-typed code, it might bail out.Note that "locality" of verifiability is a fluid concept, depending sometime on vagaries of inlining decisions. This is the reason for some awkward looking "belt and suspenders" MH internals, such as the free use of casts in LF bytecode rendering. Usually, redundant type verifications (including casts and signatures of incoming arguments) are eliminated, but they can cause (as noted) an extra null check. In theory, that should fold up also, if the null value is replaced by "another" null, as (p == null ? null : identityFunction(p)). ? John On Jul 8, 2014, at 3:09 AM, Vladimir Ivanov wrote: > I'd like to revive this review thread. > > Updated version: > http://cr.openjdk.java.net/~vlivanov/8037209/webrev.04/ > > Paul, I'd like to address your case (if possible) separately. Right now, I don't see any way to avoid null check you see with your tests. On Apr 1, 2014, at 8:29 AM, Paul Sandoz wrote: > On Apr 1, 2014, at 4:10 PM, Vladimir Ivanov wrote: > >> Paul, >> >> Unfortunately, additional profiling doesn't work for Accessor.checkCast case. The problem is Accessor.checkCast is called from multiple places, so type profile is very likely to be polluted. And it kills the benefits. >> > > So is there any point in doing such a cast in this case? > > The type performing the cast is the field type declared as a parameter in the MethodType of the MethodHandle and also held by the Accessor. > > IIUC the Invokers.checkExactType should ensure no "unsavoury" instances of the wrong type gets through? (the holder instance is only checked for null, via checkBase). From brent.christian at oracle.com Tue Jul 8 19:15:08 2014 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 08 Jul 2014 12:15:08 -0700 Subject: RFR (8u) 8049373 : All compact profiles builds fail following JDK-8044473 Message-ID: <53BC433C.5080001@oracle.com> Please review the fix for JDK-8049373. It applies only to 8u. The JBS issue is not public, but the general problem is that some closed changes related to JDK-8044473 incorrectly ended up being added to the compact 1 profile. The changes in question depend on the management APIs, which are only available in the compact 3 profile, hence the build failure. The diff below corrects the compact profile contents: diff -r 27f517db4207 make/profile-rtjar-includes.txt --- a/make/profile-rtjar-includes.txt Wed Jun 25 12:36:03 2014 -0700 +++ b/make/profile-rtjar-includes.txt Tue Jul 08 11:51:38 2014 -0700 @@ -117,6 +117,8 @@ com/sun/security/ntlm \ com/sun/security/sasl \ com/sun/tracing \ + jdk/management \ + jdk/internal/cmm \ java/lang/instrument \ java/lang/management \ java/security/acl \ With this change, the profiles build succeeds. Thanks, -Brent From forax at univ-mlv.fr Tue Jul 8 19:49:03 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 08 Jul 2014 21:49:03 +0200 Subject: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms In-Reply-To: <7FAEB94F-EB98-49A9-A4B0-9B4A6B730CA9@oracle.com> References: <5322EBF2.7030209@oracle.com> <5322F3D7.9010103@oracle.com> <94F61B19-8904-42FA-9E16-CC0A6B30FD79@oracle.com> <53230184.9090007@oracle.com> <2FCC64E3-3753-4CE0-9CC6-849FF737BFB5@oracle.com> <53232FF3.9020803@oracle.com> <53305E52.2060001@oracle.com> <53BBC340.7040509@oracle.com> <7FAEB94F-EB98-49A9-A4B0-9B4A6B730CA9@oracle.com> Message-ID: <53BC4B2F.5030507@univ-mlv.fr> In my opinion, there are two issues here, the first one is the extra Class.cast which is inserted and as John said it should be interesting to try to remove them. the second one is why when there is a Class.cast, the cast is effectively removed but a null check stay. regards, R?mi On 07/08/2014 09:09 PM, John Rose wrote: > Regarding the extra cast in accessor logic that Paul picked up on: > That may be a left-over from obsolete versions of the code, or it may > cover for some corner cases, or it could possibly be a re-assurance > to the JIT. > > Generally speaking, we lean heavily on MH types to guarantee a priori > correctness of argument types. Paul is right that the stored value > type is already validated and (except for corner cases we may be > neglecting) does not need re-validation via a cast. > > It might be an interesting experiment to replace the cast with an assert. > > Sometimes corner cases bite you. For example, an array store check is > necessary, if the type is an interface, because interfaces are weakly > checked all the way up to aastore or invokeinterface. > > Sometimes the JIT cannot see the type assurances implicit in a MH > type, and so (when choosing internal MH code shapes) we must choose > between handing the JIT code that is not locally verifiable, or adding > "reassurance" casts to repair the local verifiability of the code. If > the JIT thinks it sees badly-typed code, it might bail out.Note that > "locality" of verifiability is a fluid concept, depending sometime on > vagaries of inlining decisions. This is the reason for some awkward > looking "belt and suspenders" MH internals, such as the free use of > casts in LF bytecode rendering. > > Usually, redundant type verifications (including casts and signatures > of incoming arguments) are eliminated, but they can cause (as noted) > an extra null check. In theory, that should fold up also, if the null > value is replaced by "another" null, as (p == null ? null : > identityFunction(p)). > > --- John > > On Jul 8, 2014, at 3:09 AM, Vladimir Ivanov > > > wrote: > >> I'd like to revive this review thread. >> >> Updated version: >> http://cr.openjdk.java.net/~vlivanov/8037209/webrev.04/ >> >> >> Paul, I'd like to address your case (if possible) separately. Right >> now, I don't see any way to avoid null check you see with your tests. > > > On Apr 1, 2014, at 8:29 AM, Paul Sandoz > wrote: > >> On Apr 1, 2014, at 4:10 PM, Vladimir Ivanov >> > >> wrote: >> >>> Paul, >>> >>> Unfortunately, additional profiling doesn't work for >>> Accessor.checkCast case. The problem is Accessor.checkCast is called >>> from multiple places, so type profile is very likely to be polluted. >>> And it kills the benefits. >>> >> >> So is there any point in doing such a cast in this case? >> >> The type performing the cast is the field type declared as a >> parameter in the MethodType of the MethodHandle and also held by the >> Accessor. >> >> IIUC the Invokers.checkExactType should ensure no "unsavoury" >> instances of the wrong type gets through? (the holder instance is >> only checked for null, via checkBase). > > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From martinrb at google.com Tue Jul 8 19:52:32 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 8 Jul 2014 12:52:32 -0700 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53BC3BEA.3080300@oracle.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BBF9BC.50808@oracle.com> <53BC3BEA.3080300@oracle.com> Message-ID: Branch-free masking might be very slightly better, although hardware branch prediction will work well on nextKeyIndex. But let's leave that to a future change. This one is already busy. On Tue, Jul 8, 2014 at 11:43 AM, Ivan Gerasimov wrote: > Given the table size if a power of two, another possible optimization > would be > private static int nextKeyIndex(int i, int len) { > - return (i + 2 < len ? i + 2 : 0); > + return (i + 2) & (len - 1); > } > > Or even > + int m = len - 1; > while ( (item = tab[i]) != null) { > ... > - i = nextKeyIndex(i, len); > + i = (i + 2) & m; > } > where ever applicable. > > > On 08.07.2014 19:14, Martin Buchholz wrote: > > So ... using 3*x is never wrong, and optimizing to x + (x << 1) is at best > only going to save a couple of cycles, so 3*x is the right choice except > for the most performance sensitive code. > > In java.util, we tend to go further and write optimal code even when > hotspot is likely to make the same optimizations, partly under Doug Lea's > performance-obsessed influence. > > Also, microbenchmarking is notoriously difficult. > > If you've written a microbenchmark, it would be good to check it in > somewhere. I don't know what current openjdk practice is for that... > > > On Tue, Jul 8, 2014 at 7:01 AM, Ivan Gerasimov > wrote: > >> >> On 08.07.2014 4:44, Martin Buchholz wrote: >> >> >> >> >> On Mon, Jul 7, 2014 at 9:41 AM, Martin Buchholz >> wrote: >> >>> I'd like to offer an alternative version of this change. webrev coming >>> soon. >>> >> >> Here's the promised webrev. >> >> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity/ >> >> - Fixes a typo in the javadoc. >> - removes the "threshold" field (WAT, a cache to avoid multiplying by 3?) >> - optimizes 3*x into x + x << 1 >> >> >> My personal preference would be x + x + x, but I thought JIT can do this >> kind of optimizations itself. >> Out of curiosity I've created a microbenchmark: >> >> Benchmark Mode Samples Score Score >> error Units >> o.s.MyBenchmark.testMethod_01_X3 avgt 200 5.900 >> 0.041 ns/op >> o.s.MyBenchmark.testMethod_02_PPP avgt 200 6.029 >> 0.035 ns/op >> o.s.MyBenchmark.testMethod_03_PSH avgt 200 5.907 >> 0.071 ns/op >> >> On my machine 3*x and x + (x<<1) appear to be of the same speed (#1 and >> #3 above). >> x + x + x (case #2) happens to be ~2% slower. >> >> Given the optimization doesn't introduce any speedup, wouldn't it be >> better to use 3*x for its clarity? >> >> Sincerely yours, >> Ivan >> >> >> >> - adds more test assertions >> - removes the unusual 4/3 slack space for expansion on deserialization. >> >> TODO: the test should be testng-ified, I think. >> >> >> >> > > From mandy.chung at oracle.com Tue Jul 8 19:59:11 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 08 Jul 2014 12:59:11 -0700 Subject: RFR (8u) 8049373 : All compact profiles builds fail following JDK-8044473 In-Reply-To: <53BC433C.5080001@oracle.com> References: <53BC433C.5080001@oracle.com> Message-ID: <53BC4D8F.7020600@oracle.com> Looks okay. Mandy On 7/8/14 12:15 PM, Brent Christian wrote: > Please review the fix for JDK-8049373. It applies only to 8u. > > The JBS issue is not public, but the general problem is that some > closed changes related to JDK-8044473 incorrectly ended up being added > to the compact 1 profile. The changes in question depend on the > management APIs, which are only available in the compact 3 profile, > hence the build failure. > > The diff below corrects the compact profile contents: > > diff -r 27f517db4207 make/profile-rtjar-includes.txt > --- a/make/profile-rtjar-includes.txt Wed Jun 25 12:36:03 2014 -0700 > +++ b/make/profile-rtjar-includes.txt Tue Jul 08 11:51:38 2014 -0700 > @@ -117,6 +117,8 @@ > com/sun/security/ntlm \ > com/sun/security/sasl \ > com/sun/tracing \ > + jdk/management \ > + jdk/internal/cmm \ > java/lang/instrument \ > java/lang/management \ > java/security/acl \ > > > With this change, the profiles build succeeds. > > Thanks, > -Brent From martinrb at google.com Tue Jul 8 20:07:38 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 8 Jul 2014 13:07:38 -0700 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53BC08DA.4020007@gmail.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> Message-ID: I updated my webrev and it is again "feature-complete". http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity/ (old webrev at http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity.0/ ) This incorporates Peter's idea of making resize return a boolean, keeps the map unchanged if resize throws, moves the check for capacity exceeded into resize, and minimizes bytecode in put(). I'm happy with this (except for degraded behavior near MAX_CAPACITY). On Tue, Jul 8, 2014 at 8:06 AM, Peter Levart wrote: > On 07/08/2014 03:00 PM, Ivan Gerasimov wrote: > >> I took your latest version of the patch and modified it a little: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.01/ >>> >>> >> But isn't it post-insert-resize vs pre-insert-resize problem Doug >> mentioned above? >> I've tested a similar fix and it showed slow down of the put() operation. >> > Hi Ivan, > > Might be that it has to do with # of bytecodes in the method and in-lining > threshold. I modified it once more, to make put() method as short as > possible: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.05/ > > With this, I ran the following JMH benchmark: > > @State(Scope.Thread) > public class IHMBench { > > Map map = new IdentityHashMap(); > > @Benchmark > public void putNewObject(Blackhole bh) { > Object o = new Object(); > bh.consume(map.put(o, o)); > if (map.size() > 100000) { > map = new IdentityHashMap(); > } > } > } > > I get the following results on my i7/Linux using: > > java -Xmx4G -Xms4G -XX:+UseParallelGC -jar benchmarks.jar -f 0 -i 10 -wi 8 > -gc 1 -t 1 > > Original: > > Benchmark Mode Samples Score Score error > Units > j.t.IHMBench.putNewObject thrpt 10 13088296.198 403446.449 > ops/s > > Patched: > > Benchmark Mode Samples Score Score error > Units > j.t.IHMBench.putNewObject thrpt 10 13180594.537 282047.154 > ops/s > > > Can you run your test with webrev.05 and see what you get ? > > Regards, Peter > > From peter.levart at gmail.com Tue Jul 8 21:15:59 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 08 Jul 2014 23:15:59 +0200 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> Message-ID: <53BC5F8F.2060103@gmail.com> On 07/08/2014 10:07 PM, Martin Buchholz wrote: > I updated my webrev and it is again "feature-complete". > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity/ > > (old webrev at > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity.0/ > > ) > > This incorporates Peter's idea of making resize return a boolean, > keeps the map unchanged if resize throws, moves the check for capacity > exceeded into resize, and minimizes bytecode in put(). I'm happy with > this (except for degraded behavior near MAX_CAPACITY). Nice solution. I hope that resize: 458 private boolean resize(int newCapacity) { 459 // assert (newCapacity & -newCapacity) == newCapacity; // power of 2 460 int newLength = newCapacity * 2; 461 462 Object[] oldTable = table; 463 int oldLength = oldTable.length; 464 if (oldLength == 2 * MAXIMUM_CAPACITY) { // can't expand any further 465 if (size == MAXIMUM_CAPACITY - 1) 466 throw new IllegalStateException("Capacity exhausted."); 467 return false; 468 } 469 if (oldLength >= newLength) 470 return false; ... is never (going to be) called in context that would make oldLength >= newLength && oldLength == 2 * MAXIMUM_CAPACITY && size == MAXIMUM_CAPACITY - 1 ... In that case it would be better to return false than to throw IllegalStateException, since no re-sizing was actually requested. if statement (L469,470) could be moved just after newLength assignment (L460) to make resize() more robust to possible future changes of calling code. I wonder what the benchmarks will say. Regards, Peter > > > On Tue, Jul 8, 2014 at 8:06 AM, Peter Levart > wrote: > > On 07/08/2014 03:00 PM, Ivan Gerasimov wrote: > > I took your latest version of the patch and modified it a > little: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.01/ > > > > But isn't it post-insert-resize vs pre-insert-resize problem > Doug mentioned above? > I've tested a similar fix and it showed slow down of the put() > operation. > > Hi Ivan, > > Might be that it has to do with # of bytecodes in the method and > in-lining threshold. I modified it once more, to make put() method > as short as possible: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.05/ > > > With this, I ran the following JMH benchmark: > > @State(Scope.Thread) > public class IHMBench { > > Map map = new IdentityHashMap(); > > @Benchmark > public void putNewObject(Blackhole bh) { > Object o = new Object(); > bh.consume(map.put(o, o)); > if (map.size() > 100000) { > map = new IdentityHashMap(); > } > } > } > > I get the following results on my i7/Linux using: > > java -Xmx4G -Xms4G -XX:+UseParallelGC -jar benchmarks.jar -f 0 -i > 10 -wi 8 -gc 1 -t 1 > > Original: > > Benchmark Mode Samples Score Score > error Units > j.t.IHMBench.putNewObject thrpt 10 13088296.198 > 403446.449 ops/s > > Patched: > > Benchmark Mode Samples Score Score > error Units > j.t.IHMBench.putNewObject thrpt 10 13180594.537 > 282047.154 ops/s > > > Can you run your test with webrev.05 and see what you get ? > > Regards, Peter > > From martinrb at google.com Tue Jul 8 21:30:46 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 8 Jul 2014 14:30:46 -0700 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53BC5F8F.2060103@gmail.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC5F8F.2060103@gmail.com> Message-ID: If size == MAXIMUM_CAPACITY - 1 and you're in resize, presumably you're about to fill that last empty slot after returning, so you want to throw instead of returning false? Benchmarks welcome. On Tue, Jul 8, 2014 at 2:15 PM, Peter Levart wrote: > > On 07/08/2014 10:07 PM, Martin Buchholz wrote: > > I updated my webrev and it is again "feature-complete". > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity/ > (old webrev at > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity.0/ > ) > > This incorporates Peter's idea of making resize return a boolean, keeps > the map unchanged if resize throws, moves the check for capacity exceeded > into resize, and minimizes bytecode in put(). I'm happy with this (except > for degraded behavior near MAX_CAPACITY). > > > Nice solution. I hope that resize: > > 458 private boolean resize(int newCapacity) { > 459 // assert (newCapacity & -newCapacity) == newCapacity; // power of 2 > 460 int newLength = newCapacity * 2; > 461 > 462 Object[] oldTable = table; > 463 int oldLength = oldTable.length; > 464 if (oldLength == 2 * MAXIMUM_CAPACITY) { // can't expand any further > 465 if (size == MAXIMUM_CAPACITY - 1) > 466 throw new IllegalStateException("Capacity exhausted."); > 467 return false; > 468 } > 469 if (oldLength >= newLength) > 470 return false; > > ... is never (going to be) called in context that would make oldLength >= > newLength && oldLength == 2 * MAXIMUM_CAPACITY && size == MAXIMUM_CAPACITY > - 1 ... > > In that case it would be better to return false than to throw > IllegalStateException, since no re-sizing was actually requested. if > statement (L469,470) could be moved just after newLength assignment (L460) > to make resize() more robust to possible future changes of calling code. > > I wonder what the benchmarks will say. > > Regards, Peter > > > > > On Tue, Jul 8, 2014 at 8:06 AM, Peter Levart > wrote: > >> On 07/08/2014 03:00 PM, Ivan Gerasimov wrote: >> >>> I took your latest version of the patch and modified it a little: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.01/ >>>> >>>> >>> But isn't it post-insert-resize vs pre-insert-resize problem Doug >>> mentioned above? >>> I've tested a similar fix and it showed slow down of the put() >>> operation. >>> >> Hi Ivan, >> >> Might be that it has to do with # of bytecodes in the method and >> in-lining threshold. I modified it once more, to make put() method as short >> as possible: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.05/ >> >> With this, I ran the following JMH benchmark: >> >> @State(Scope.Thread) >> public class IHMBench { >> >> Map map = new IdentityHashMap(); >> >> @Benchmark >> public void putNewObject(Blackhole bh) { >> Object o = new Object(); >> bh.consume(map.put(o, o)); >> if (map.size() > 100000) { >> map = new IdentityHashMap(); >> } >> } >> } >> >> I get the following results on my i7/Linux using: >> >> java -Xmx4G -Xms4G -XX:+UseParallelGC -jar benchmarks.jar -f 0 -i 10 -wi >> 8 -gc 1 -t 1 >> >> Original: >> >> Benchmark Mode Samples Score Score error >> Units >> j.t.IHMBench.putNewObject thrpt 10 13088296.198 403446.449 >> ops/s >> >> Patched: >> >> Benchmark Mode Samples Score Score error >> Units >> j.t.IHMBench.putNewObject thrpt 10 13180594.537 282047.154 >> ops/s >> >> >> Can you run your test with webrev.05 and see what you get ? >> >> Regards, Peter >> >> > > From ivan.gerasimov at oracle.com Tue Jul 8 21:39:18 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 09 Jul 2014 01:39:18 +0400 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> Message-ID: <53BC6506.3060308@oracle.com> Might be worth to add modCount++ before this line: 487 table = newTable; 488 return true; On 09.07.2014 0:07, Martin Buchholz wrote: > I updated my webrev and it is again "feature-complete". > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity/ > > (old webrev at > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity.0/ > > ) > > This incorporates Peter's idea of making resize return a boolean, > keeps the map unchanged if resize throws, moves the check for capacity > exceeded into resize, and minimizes bytecode in put(). I'm happy with > this (except for degraded behavior near MAX_CAPACITY). > > > > > On Tue, Jul 8, 2014 at 8:06 AM, Peter Levart > wrote: > > On 07/08/2014 03:00 PM, Ivan Gerasimov wrote: > > I took your latest version of the patch and modified it a > little: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.01/ > > > > But isn't it post-insert-resize vs pre-insert-resize problem > Doug mentioned above? > I've tested a similar fix and it showed slow down of the put() > operation. > > Hi Ivan, > > Might be that it has to do with # of bytecodes in the method and > in-lining threshold. I modified it once more, to make put() method > as short as possible: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.05/ > > > With this, I ran the following JMH benchmark: > > @State(Scope.Thread) > public class IHMBench { > > Map map = new IdentityHashMap(); > > @Benchmark > public void putNewObject(Blackhole bh) { > Object o = new Object(); > bh.consume(map.put(o, o)); > if (map.size() > 100000) { > map = new IdentityHashMap(); > } > } > } > > I get the following results on my i7/Linux using: > > java -Xmx4G -Xms4G -XX:+UseParallelGC -jar benchmarks.jar -f 0 -i > 10 -wi 8 -gc 1 -t 1 > > Original: > > Benchmark Mode Samples Score Score > error Units > j.t.IHMBench.putNewObject thrpt 10 13088296.198 > 403446.449 ops/s > > Patched: > > Benchmark Mode Samples Score Score > error Units > j.t.IHMBench.putNewObject thrpt 10 13180594.537 > 282047.154 ops/s > > > Can you run your test with webrev.05 and see what you get ? > > Regards, Peter > > From peter.levart at gmail.com Tue Jul 8 21:44:32 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 08 Jul 2014 23:44:32 +0200 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53BC6506.3060308@oracle.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC6506.3060308@oracle.com> Message-ID: <53BC6640.9020508@gmail.com> On 07/08/2014 11:39 PM, Ivan Gerasimov wrote: > Might be worth to add modCount++ before this line: > > 487 table = newTable; > 488 return true; > Not quite, I think. The map has just been resized, but it's contents has not changed yet logically. Regards, Peter > On 09.07.2014 0:07, Martin Buchholz wrote: >> I updated my webrev and it is again "feature-complete". >> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity/ >> >> (old webrev at >> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity.0/ >> >> ) >> >> This incorporates Peter's idea of making resize return a boolean, >> keeps the map unchanged if resize throws, moves the check for >> capacity exceeded into resize, and minimizes bytecode in put(). I'm >> happy with this (except for degraded behavior near MAX_CAPACITY). >> >> >> >> >> On Tue, Jul 8, 2014 at 8:06 AM, Peter Levart > > wrote: >> >> On 07/08/2014 03:00 PM, Ivan Gerasimov wrote: >> >> I took your latest version of the patch and modified it a >> little: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.01/ >> >> >> >> But isn't it post-insert-resize vs pre-insert-resize problem >> Doug mentioned above? >> I've tested a similar fix and it showed slow down of the >> put() operation. >> >> Hi Ivan, >> >> Might be that it has to do with # of bytecodes in the method and >> in-lining threshold. I modified it once more, to make put() >> method as short as possible: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.05/ >> >> >> With this, I ran the following JMH benchmark: >> >> @State(Scope.Thread) >> public class IHMBench { >> >> Map map = new IdentityHashMap(); >> >> @Benchmark >> public void putNewObject(Blackhole bh) { >> Object o = new Object(); >> bh.consume(map.put(o, o)); >> if (map.size() > 100000) { >> map = new IdentityHashMap(); >> } >> } >> } >> >> I get the following results on my i7/Linux using: >> >> java -Xmx4G -Xms4G -XX:+UseParallelGC -jar benchmarks.jar -f 0 -i >> 10 -wi 8 -gc 1 -t 1 >> >> Original: >> >> Benchmark Mode Samples Score Score error >> Units >> j.t.IHMBench.putNewObject thrpt 10 13088296.198 >> 403446.449 ops/s >> >> Patched: >> >> Benchmark Mode Samples Score Score error >> Units >> j.t.IHMBench.putNewObject thrpt 10 13180594.537 >> 282047.154 ops/s >> >> >> Can you run your test with webrev.05 and see what you get ? >> >> Regards, Peter >> >> > From mike.duigou at oracle.com Tue Jul 8 21:46:37 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 8 Jul 2014 14:46:37 -0700 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> Message-ID: Looks pretty good. I like the additional comments as well. Could you document the return conditions of resize()? A "since we're there already" suggestion for readObject: if (size < 0) throw new InvalidObjectException("Illegal mappings count: " + size); Mike On Jul 8 2014, at 13:07 , Martin Buchholz wrote: > I updated my webrev and it is again "feature-complete". > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity/ > (old webrev at > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity.0/ > ) > > This incorporates Peter's idea of making resize return a boolean, keeps the > map unchanged if resize throws, moves the check for capacity exceeded into > resize, and minimizes bytecode in put(). I'm happy with this (except for > degraded behavior near MAX_CAPACITY). > > > > > On Tue, Jul 8, 2014 at 8:06 AM, Peter Levart wrote: > >> On 07/08/2014 03:00 PM, Ivan Gerasimov wrote: >> >>> I took your latest version of the patch and modified it a little: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.01/ >>>> >>>> >>> But isn't it post-insert-resize vs pre-insert-resize problem Doug >>> mentioned above? >>> I've tested a similar fix and it showed slow down of the put() operation. >>> >> Hi Ivan, >> >> Might be that it has to do with # of bytecodes in the method and in-lining >> threshold. I modified it once more, to make put() method as short as >> possible: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.05/ >> >> With this, I ran the following JMH benchmark: >> >> @State(Scope.Thread) >> public class IHMBench { >> >> Map map = new IdentityHashMap(); >> >> @Benchmark >> public void putNewObject(Blackhole bh) { >> Object o = new Object(); >> bh.consume(map.put(o, o)); >> if (map.size() > 100000) { >> map = new IdentityHashMap(); >> } >> } >> } >> >> I get the following results on my i7/Linux using: >> >> java -Xmx4G -Xms4G -XX:+UseParallelGC -jar benchmarks.jar -f 0 -i 10 -wi 8 >> -gc 1 -t 1 >> >> Original: >> >> Benchmark Mode Samples Score Score error >> Units >> j.t.IHMBench.putNewObject thrpt 10 13088296.198 403446.449 >> ops/s >> >> Patched: >> >> Benchmark Mode Samples Score Score error >> Units >> j.t.IHMBench.putNewObject thrpt 10 13180594.537 282047.154 >> ops/s >> >> >> Can you run your test with webrev.05 and see what you get ? >> >> Regards, Peter >> >> From ivan.gerasimov at oracle.com Tue Jul 8 22:06:39 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 09 Jul 2014 02:06:39 +0400 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53BC6640.9020508@gmail.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC6506.3060308@oracle.com> <53BC6640.9020508@gmail.com> Message-ID: <53BC6B6F.6000709@oracle.com> On 09.07.2014 1:44, Peter Levart wrote: > > On 07/08/2014 11:39 PM, Ivan Gerasimov wrote: >> Might be worth to add modCount++ before this line: >> >> 487 table = newTable; >> 488 return true; >> > Not quite, I think. The map has just been resized, but it's contents > has not changed yet logically. > IdentityHashMapIterator's methods assume that if modCount didn't change, then the indices calculated earlier remain valid, and this is wrong in the case of resize. Sincerely yours, Ivan > Regards, Peter > >> On 09.07.2014 0:07, Martin Buchholz wrote: >>> I updated my webrev and it is again "feature-complete". >>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity/ >>> >>> (old webrev at >>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity.0/ >>> >>> ) >>> >>> This incorporates Peter's idea of making resize return a boolean, >>> keeps the map unchanged if resize throws, moves the check for >>> capacity exceeded into resize, and minimizes bytecode in put(). I'm >>> happy with this (except for degraded behavior near MAX_CAPACITY). >>> >>> >>> >>> >>> On Tue, Jul 8, 2014 at 8:06 AM, Peter Levart >> > wrote: >>> >>> On 07/08/2014 03:00 PM, Ivan Gerasimov wrote: >>> >>> I took your latest version of the patch and modified it >>> a little: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.01/ >>> >>> >>> >>> But isn't it post-insert-resize vs pre-insert-resize problem >>> Doug mentioned above? >>> I've tested a similar fix and it showed slow down of the >>> put() operation. >>> >>> Hi Ivan, >>> >>> Might be that it has to do with # of bytecodes in the method and >>> in-lining threshold. I modified it once more, to make put() >>> method as short as possible: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.05/ >>> >>> >>> With this, I ran the following JMH benchmark: >>> >>> @State(Scope.Thread) >>> public class IHMBench { >>> >>> Map map = new IdentityHashMap(); >>> >>> @Benchmark >>> public void putNewObject(Blackhole bh) { >>> Object o = new Object(); >>> bh.consume(map.put(o, o)); >>> if (map.size() > 100000) { >>> map = new IdentityHashMap(); >>> } >>> } >>> } >>> >>> I get the following results on my i7/Linux using: >>> >>> java -Xmx4G -Xms4G -XX:+UseParallelGC -jar benchmarks.jar -f 0 >>> -i 10 -wi 8 -gc 1 -t 1 >>> >>> Original: >>> >>> Benchmark Mode Samples Score Score error >>> Units >>> j.t.IHMBench.putNewObject thrpt 10 13088296.198 >>> 403446.449 ops/s >>> >>> Patched: >>> >>> Benchmark Mode Samples Score Score error >>> Units >>> j.t.IHMBench.putNewObject thrpt 10 13180594.537 >>> 282047.154 ops/s >>> >>> >>> Can you run your test with webrev.05 and see what you get ? >>> >>> Regards, Peter >>> >>> >> > From peter.levart at gmail.com Tue Jul 8 22:42:31 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 09 Jul 2014 00:42:31 +0200 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53BC6B6F.6000709@oracle.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC6506.3060308@oracle.com> <53BC6640.9020508@gmail.com> <53BC6B6F.6000709@oracle.com> Message-ID: <53BC73D7.7020900@gmail.com> On 07/09/2014 12:06 AM, Ivan Gerasimov wrote: > > On 09.07.2014 1:44, Peter Levart wrote: >> >> On 07/08/2014 11:39 PM, Ivan Gerasimov wrote: >>> Might be worth to add modCount++ before this line: >>> >>> 487 table = newTable; >>> 488 return true; >>> >> Not quite, I think. The map has just been resized, but it's contents >> has not changed yet logically. >> > IdentityHashMapIterator's methods assume that if modCount didn't > change, then the indices calculated earlier remain valid, and this is > wrong in the case of resize. > > Sincerely yours, > Ivan IdentityHashMapIterator: 713 private abstract class IdentityHashMapIterator implements Iterator { 714 int index = (size != 0 ? 0 : table.length); // current slot. 715 int expectedModCount = modCount; // to support fast-fail 716 int lastReturnedIndex = -1; // to allow remove() 717 boolean indexValid; // To avoid unnecessary next computation 718 Object[] traversalTable = table; // reference to main table or copy ...takes a snap-shot of reference to current table when created, so indexes would still be valid ... ...but resize() also clears old table as it copies elements to new table: 478 oldTable[j] = null; 479 oldTable[j+1] = null; So it would appear that modCount should be incremented even before the copying loop. But as it seems, no user call-backs are possible during resize() in same thread and normal writes are not ordered anyway for other threads and after each "successful" resize() at least one new key will be added to the map so modCount will be incremented before control is returned to user code anyway. Regards, Peter > > >> Regards, Peter >> >>> On 09.07.2014 0:07, Martin Buchholz wrote: >>>> I updated my webrev and it is again "feature-complete". >>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity/ >>>> >>>> (old webrev at >>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity.0/ >>>> >>>> ) >>>> >>>> This incorporates Peter's idea of making resize return a boolean, >>>> keeps the map unchanged if resize throws, moves the check for >>>> capacity exceeded into resize, and minimizes bytecode in put(). >>>> I'm happy with this (except for degraded behavior near MAX_CAPACITY). >>>> >>>> >>>> >>>> >>>> On Tue, Jul 8, 2014 at 8:06 AM, Peter Levart >>>> > wrote: >>>> >>>> On 07/08/2014 03:00 PM, Ivan Gerasimov wrote: >>>> >>>> I took your latest version of the patch and modified it >>>> a little: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.01/ >>>> >>>> >>>> >>>> But isn't it post-insert-resize vs pre-insert-resize >>>> problem Doug mentioned above? >>>> I've tested a similar fix and it showed slow down of the >>>> put() operation. >>>> >>>> Hi Ivan, >>>> >>>> Might be that it has to do with # of bytecodes in the method >>>> and in-lining threshold. I modified it once more, to make put() >>>> method as short as possible: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.05/ >>>> >>>> >>>> With this, I ran the following JMH benchmark: >>>> >>>> @State(Scope.Thread) >>>> public class IHMBench { >>>> >>>> Map map = new IdentityHashMap>>> Object>(); >>>> >>>> @Benchmark >>>> public void putNewObject(Blackhole bh) { >>>> Object o = new Object(); >>>> bh.consume(map.put(o, o)); >>>> if (map.size() > 100000) { >>>> map = new IdentityHashMap(); >>>> } >>>> } >>>> } >>>> >>>> I get the following results on my i7/Linux using: >>>> >>>> java -Xmx4G -Xms4G -XX:+UseParallelGC -jar benchmarks.jar -f 0 >>>> -i 10 -wi 8 -gc 1 -t 1 >>>> >>>> Original: >>>> >>>> Benchmark Mode Samples Score Score >>>> error Units >>>> j.t.IHMBench.putNewObject thrpt 10 13088296.198 >>>> 403446.449 ops/s >>>> >>>> Patched: >>>> >>>> Benchmark Mode Samples Score Score >>>> error Units >>>> j.t.IHMBench.putNewObject thrpt 10 13180594.537 >>>> 282047.154 ops/s >>>> >>>> >>>> Can you run your test with webrev.05 and see what you get ? >>>> >>>> Regards, Peter >>>> >>>> >>> >> > From martinrb at google.com Tue Jul 8 23:16:42 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 8 Jul 2014 16:16:42 -0700 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> Message-ID: On Tue, Jul 8, 2014 at 2:46 PM, Mike Duigou wrote: > Looks pretty good. I like the additional comments as well. > > Could you document the return conditions of resize()? > Done. > > A "since we're there already" suggestion for readObject: > > if (size < 0) > throw new InvalidObjectException("Illegal mappings count: " + size); > > Done, but I used StreamCorruptedException as was already done in the existing code. Mike > > On Jul 8 2014, at 13:07 , Martin Buchholz wrote: > > > I updated my webrev and it is again "feature-complete". > > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity/ > > (old webrev at > > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity.0/ > > ) > > > > This incorporates Peter's idea of making resize return a boolean, keeps > the > > map unchanged if resize throws, moves the check for capacity exceeded > into > > resize, and minimizes bytecode in put(). I'm happy with this (except for > > degraded behavior near MAX_CAPACITY). > > > > > > > > > > On Tue, Jul 8, 2014 at 8:06 AM, Peter Levart > wrote: > > > >> On 07/08/2014 03:00 PM, Ivan Gerasimov wrote: > >> > >>> I took your latest version of the patch and modified it a little: > >>>> > >>>> > http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.01/ > >>>> > >>>> > >>> But isn't it post-insert-resize vs pre-insert-resize problem Doug > >>> mentioned above? > >>> I've tested a similar fix and it showed slow down of the put() > operation. > >>> > >> Hi Ivan, > >> > >> Might be that it has to do with # of bytecodes in the method and > in-lining > >> threshold. I modified it once more, to make put() method as short as > >> possible: > >> > >> http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.05/ > >> > >> With this, I ran the following JMH benchmark: > >> > >> @State(Scope.Thread) > >> public class IHMBench { > >> > >> Map map = new IdentityHashMap(); > >> > >> @Benchmark > >> public void putNewObject(Blackhole bh) { > >> Object o = new Object(); > >> bh.consume(map.put(o, o)); > >> if (map.size() > 100000) { > >> map = new IdentityHashMap(); > >> } > >> } > >> } > >> > >> I get the following results on my i7/Linux using: > >> > >> java -Xmx4G -Xms4G -XX:+UseParallelGC -jar benchmarks.jar -f 0 -i 10 > -wi 8 > >> -gc 1 -t 1 > >> > >> Original: > >> > >> Benchmark Mode Samples Score Score error > >> Units > >> j.t.IHMBench.putNewObject thrpt 10 13088296.198 403446.449 > >> ops/s > >> > >> Patched: > >> > >> Benchmark Mode Samples Score Score error > >> Units > >> j.t.IHMBench.putNewObject thrpt 10 13180594.537 282047.154 > >> ops/s > >> > >> > >> Can you run your test with webrev.05 and see what you get ? > >> > >> Regards, Peter > >> > >> > > From martinrb at google.com Tue Jul 8 23:20:05 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 8 Jul 2014 16:20:05 -0700 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53BC73D7.7020900@gmail.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC6506.3060308@oracle.com> <53BC6640.9020508@gmail.com> <53BC6B6F.6000709@oracle.com> <53BC73D7.7020900@gmail.com> Message-ID: I agree with Peter that we do not need to increment modCount on resize. My latest webrev is again "done". Ivan, feel free to take over. From ivan.gerasimov at oracle.com Wed Jul 9 00:05:47 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 09 Jul 2014 04:05:47 +0400 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53BC73D7.7020900@gmail.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC6506.3060308@oracle.com> <53BC6640.9020508@gmail.com> <53BC6B6F.6000709@oracle.com> <53BC73D7.7020900@gmail.com> Message-ID: <53BC875B.7060304@oracle.com> Ah, yes, sure. I overlooked the reference to the table :-) On 09.07.2014 2:42, Peter Levart wrote: > > On 07/09/2014 12:06 AM, Ivan Gerasimov wrote: >> >> On 09.07.2014 1:44, Peter Levart wrote: >>> >>> On 07/08/2014 11:39 PM, Ivan Gerasimov wrote: >>>> Might be worth to add modCount++ before this line: >>>> >>>> 487 table = newTable; >>>> 488 return true; >>>> >>> Not quite, I think. The map has just been resized, but it's contents >>> has not changed yet logically. >>> >> IdentityHashMapIterator's methods assume that if modCount didn't >> change, then the indices calculated earlier remain valid, and this is >> wrong in the case of resize. >> >> Sincerely yours, >> Ivan > > IdentityHashMapIterator: > > 713 private abstract class IdentityHashMapIterator implements Iterator { > 714 int index = (size != 0 ? 0 : table.length); // current slot. > 715 int expectedModCount = modCount; // to support fast-fail > 716 int lastReturnedIndex = -1; // to allow remove() > 717 boolean indexValid; // To avoid unnecessary next computation > 718 Object[] traversalTable = table; // reference to main table or copy > > ...takes a snap-shot of reference to current table when created, so > indexes would still be valid ... > > ...but resize() also clears old table as it copies elements to new table: > > 478 oldTable[j] = null; > 479 oldTable[j+1] = null; > > So it would appear that modCount should be incremented even before the > copying loop. > > But as it seems, no user call-backs are possible during resize() in > same thread and normal writes are not ordered anyway for other threads > and after each "successful" resize() at least one new key will be > added to the map so modCount will be incremented before control is > returned to user code anyway. > > Regards, Peter > >> >> >>> Regards, Peter >>> >>>> On 09.07.2014 0:07, Martin Buchholz wrote: >>>>> I updated my webrev and it is again "feature-complete". >>>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity/ >>>>> >>>>> (old webrev at >>>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity.0/ >>>>> >>>>> ) >>>>> >>>>> This incorporates Peter's idea of making resize return a boolean, >>>>> keeps the map unchanged if resize throws, moves the check for >>>>> capacity exceeded into resize, and minimizes bytecode in put(). >>>>> I'm happy with this (except for degraded behavior near MAX_CAPACITY). >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Jul 8, 2014 at 8:06 AM, Peter Levart >>>>> > wrote: >>>>> >>>>> On 07/08/2014 03:00 PM, Ivan Gerasimov wrote: >>>>> >>>>> I took your latest version of the patch and modified >>>>> it a little: >>>>> >>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.01/ >>>>> >>>>> >>>>> >>>>> But isn't it post-insert-resize vs pre-insert-resize >>>>> problem Doug mentioned above? >>>>> I've tested a similar fix and it showed slow down of the >>>>> put() operation. >>>>> >>>>> Hi Ivan, >>>>> >>>>> Might be that it has to do with # of bytecodes in the method >>>>> and in-lining threshold. I modified it once more, to make >>>>> put() method as short as possible: >>>>> >>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.05/ >>>>> >>>>> >>>>> With this, I ran the following JMH benchmark: >>>>> >>>>> @State(Scope.Thread) >>>>> public class IHMBench { >>>>> >>>>> Map map = new IdentityHashMap>>>> Object>(); >>>>> >>>>> @Benchmark >>>>> public void putNewObject(Blackhole bh) { >>>>> Object o = new Object(); >>>>> bh.consume(map.put(o, o)); >>>>> if (map.size() > 100000) { >>>>> map = new IdentityHashMap(); >>>>> } >>>>> } >>>>> } >>>>> >>>>> I get the following results on my i7/Linux using: >>>>> >>>>> java -Xmx4G -Xms4G -XX:+UseParallelGC -jar benchmarks.jar -f 0 >>>>> -i 10 -wi 8 -gc 1 -t 1 >>>>> >>>>> Original: >>>>> >>>>> Benchmark Mode Samples Score Score >>>>> error Units >>>>> j.t.IHMBench.putNewObject thrpt 10 13088296.198 >>>>> 403446.449 ops/s >>>>> >>>>> Patched: >>>>> >>>>> Benchmark Mode Samples Score Score >>>>> error Units >>>>> j.t.IHMBench.putNewObject thrpt 10 13180594.537 >>>>> 282047.154 ops/s >>>>> >>>>> >>>>> Can you run your test with webrev.05 and see what you get ? >>>>> >>>>> Regards, Peter >>>>> >>>>> >>>> >>> >> > From ivan.gerasimov at oracle.com Wed Jul 9 00:25:20 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 09 Jul 2014 04:25:20 +0400 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC6506.3060308@oracle.com> <53BC6640.9020508@gmail.com> <53BC6B6F.6000709@oracle.com> <53BC73D7.7020900@gmail.com> Message-ID: <53BC8BF0.7000601@oracle.com> On 09.07.2014 3:20, Martin Buchholz wrote: > I agree with Peter that we do not need to increment modCount on resize. > > My latest webrev is again "done". > > Ivan, feel free to take over. Yes, thanks! The fix is much much better now. I think I see yet another very minor glitch, though. If the table is already of size 2 * MAXIMUM_CAPACITY, and we're merging in another map, which has more elements with putAll(), resize() will be called and it will throw, even though all the elements could fit into the map due to the key duplicates. To avoid this the following check should be done first in resize(): 469 if (oldLength >= newLength) 470 return false; Sincerely yours, Ivan From martinrb at google.com Wed Jul 9 00:46:23 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 8 Jul 2014 17:46:23 -0700 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53BC8BF0.7000601@oracle.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC6506.3060308@oracle.com> <53BC6640.9020508@gmail.com> <53BC6B6F.6000709@oracle.com> <53BC73D7.7020900@gmail.com> <53BC8BF0.7000601@oracle.com> Message-ID: Let me understand - you're worried that when size is MAX_CAPACITY - 1, then a call to putAll that does not actually add any elements might throw? Well, I'm having a hard time considering that corner case a bug, given how unusable the map is at this point. Your suggested fix of returning immediately in case of no resize would cause put to succeed and reach size == MAX_CAPACITY, which you were trying to prevent. On Tue, Jul 8, 2014 at 5:25 PM, Ivan Gerasimov wrote: > > On 09.07.2014 3:20, Martin Buchholz wrote: > > I agree with Peter that we do not need to increment modCount on resize. > > My latest webrev is again "done". > > Ivan, feel free to take over. > > > Yes, thanks! The fix is much much better now. > > I think I see yet another very minor glitch, though. > If the table is already of size 2 * MAXIMUM_CAPACITY, and we're merging in > another map, which has more elements with putAll(), resize() will be called > and it will throw, even though all the elements could fit into the map due > to the key duplicates. > > To avoid this the following check should be done first in resize(): > > 469 if (oldLength >= newLength) 470 return false; > > Sincerely yours, > Ivan > From ivan.gerasimov at oracle.com Wed Jul 9 00:46:52 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 09 Jul 2014 04:46:52 +0400 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53BC8BF0.7000601@oracle.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC6506.3060308@oracle.com> <53BC6640.9020508@gmail.com> <53BC6B6F.6000709@oracle.com> <53BC73D7.7020900@gmail.com> <53BC8BF0.7000601@oracle.com> Message-ID: <53BC90FC.7090300@oracle.com> Here's the same final webrev by Martin. I only shortened the comment before capacity() and moved the check in resize() upper. http://cr.openjdk.java.net/~igerasim/6904367/4/webrev/ Sincerely yours, Ivan On 09.07.2014 4:25, Ivan Gerasimov wrote: > > On 09.07.2014 3:20, Martin Buchholz wrote: >> I agree with Peter that we do not need to increment modCount on resize. >> >> My latest webrev is again "done". >> >> Ivan, feel free to take over. > > Yes, thanks! The fix is much much better now. > > I think I see yet another very minor glitch, though. > If the table is already of size 2 * MAXIMUM_CAPACITY, and we're > merging in another map, which has more elements with putAll(), > resize() will be called and it will throw, even though all the > elements could fit into the map due to the key duplicates. > > To avoid this the following check should be done first in resize(): > > 469 if (oldLength >= newLength) > 470 return false; > > > Sincerely yours, > Ivan > > From ivan.gerasimov at oracle.com Wed Jul 9 00:49:30 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 09 Jul 2014 04:49:30 +0400 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: References: <53B57E16.5020802@oracle.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC6506.3060308@oracle.com> <53BC6640.9020508@gmail.com> <53BC6B6F.6000709@oracle.com> <53BC73D7.7020900@gmail.com> <53BC8BF0.7000601@oracle.com> Message-ID: <53BC919A.5050904@oracle.com> On 09.07.2014 4:46, Martin Buchholz wrote: > Let me understand - you're worried that when size is MAX_CAPACITY - 1, > then a call to putAll that does not actually add any elements might > throw? Well, I'm having a hard time considering that corner case a > bug, given how unusable the map is at this point. > > Your suggested fix of returning immediately in case of no resize would > cause put to succeed and reach size == MAX_CAPACITY, which you were > trying to prevent. > Ah, yes. It's almost 5 AM here, I guess I need to have some sleep before trying to fix anything else :-) > > On Tue, Jul 8, 2014 at 5:25 PM, Ivan Gerasimov > > wrote: > > > On 09.07.2014 3:20, Martin Buchholz wrote: >> I agree with Peter that we do not need to increment modCount on >> resize. >> >> My latest webrev is again "done". >> >> Ivan, feel free to take over. > > Yes, thanks! The fix is much much better now. > > I think I see yet another very minor glitch, though. > If the table is already of size 2 * MAXIMUM_CAPACITY, and we're > merging in another map, which has more elements with putAll(), > resize() will be called and it will throw, even though all the > elements could fit into the map due to the key duplicates. > > To avoid this the following check should be done first in resize(): > > 469 if (oldLength >= newLength) > 470 return false; > > > Sincerely yours, > Ivan > > From henry.jen at oracle.com Wed Jul 9 02:41:19 2014 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 08 Jul 2014 19:41:19 -0700 Subject: RFR: 8042872: Fix raw and unchecked warnings in sun.applet In-Reply-To: <53A8CE7F.4030302@oracle.com> References: <53A8C6FA.2000801@oracle.com> <53A8CE7F.4030302@oracle.com> Message-ID: <53BCABCF.3070108@oracle.com> Thanks Joe for the review. Would someone from deploy team have a quick look so we can push this? Cheers, Henry On 06/23/2014 06:03 PM, Joe Darcy wrote: > Hi Henry, > > The changes look good to me; thanks, > > -Joe > > On 06/23/2014 05:31 PM, Henry Jen wrote: >> Hi, >> >> Please review another webrev to clean up rawtypes and unchecked >> warning, this time for sun.applet. >> >> The webrev applied to both jdk9/dev and jdk9/client cleanly, I am not >> sure which repo should the webrev go once pass review. >> >> Webrev can be found at >> http://cr.openjdk.java.net/~henryjen/jdk9/8042872/0/webrev/ >> >> Please also let me know any particular test I should do other than >> regular jprt. >> >> Cheers, >> Henry > From henry.jen at oracle.com Wed Jul 9 03:30:47 2014 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 08 Jul 2014 20:30:47 -0700 Subject: RFR: 8044862: Fix raw and unchecked lint warnings in macosx specific code In-Reply-To: <53ADE96B.8070904@oracle.com> References: <53ADE5FD.20305@oracle.com> <53ADE96B.8070904@oracle.com> Message-ID: <53BCB767.4090107@oracle.com> Hi, Would someone from swing team care to take a look at this? The change of src/macosx/classes/sun/font/CFontConfiguration.java will be dropped as it had been fixed in JDK-8048980. Cheers, Henry On 06/27/2014 03:00 PM, Joe Darcy wrote: > Hi Henry, > > Your changes look good to me (I assume there was an issue using > wildcards in AquaComboBoxButton.java). > > Thanks, > > -Joe > > On 06/27/2014 02:45 PM, Henry Jen wrote: >> Hi, >> >> Please review a webrev for fixing rawtypes and unchecked lint warning >> for macosx specific java code, this webrev is depending on >> JDK-8043548[1] where some of the override methods are defined, >> >> Also as the src/macosx/classes/apple/launcher/JavaAppLauncher.java to >> be removed from JDK-8048337, the webrev omits that file. >> >> The webrev can be found at, >> http://cr.openjdk.java.net/~henryjen/jdk9/8044862/0/webrev/ >> >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8043548 >> >> Cheers, >> Henry > From mandy.chung at oracle.com Wed Jul 9 03:46:03 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 08 Jul 2014 20:46:03 -0700 Subject: RFR: 8048913: java/util/logging/LoggingDeadlock2.java times out In-Reply-To: <53BBEAF2.7030000@oracle.com> References: <53BBEAF2.7030000@oracle.com> Message-ID: <53BCBAFB.7090203@oracle.com> On 7/8/2014 5:58 AM, Daniel Fuchs wrote: > Hi, > > > Please find below a fix for > > 8048913: java/util/logging/LoggingDeadlock2.java times out > > http://cr.openjdk.java.net/~dfuchs/webrev_8048913/webrev.00/ > > .... > > My suggestion is thus simply to remove the /timeout=15 from the > @run command line, relying on the default jtreg timeout instead, > which hopefully will have been tuned for the global configuration > (fastdebug + -Xcomp) in which the testsuite is running. Do you know if the test was run with -timeoutFactor? Or does it use the default timeout? Are you able to run the test with the same configuration (on same test machine) to see how long it takes? Mandy From david.holmes at oracle.com Wed Jul 9 03:47:38 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 09 Jul 2014 13:47:38 +1000 Subject: RFR: 8048913: java/util/logging/LoggingDeadlock2.java times out In-Reply-To: <53BBEAF2.7030000@oracle.com> References: <53BBEAF2.7030000@oracle.com> Message-ID: <53BCBB5A.4010400@oracle.com> On 8/07/2014 10:58 PM, Daniel Fuchs wrote: > Hi, > > > Please find below a fix for > > 8048913: java/util/logging/LoggingDeadlock2.java times out > > http://cr.openjdk.java.net/~dfuchs/webrev_8048913/webrev.00/ > > jdk/test/java/util/logging/LoggingDeadlock2.java has been seen failing > in timeout in some of our internal nightly builds. > > java/util/logging/LoggingDeadlock2.java StatusError Program `...' > interrupted! (timed out?) > > As far as I could see this mostly happened with fastdebug builds, and > the log I was able to examine showed that -Xcomp was also used. > I believe that the issue here is that: > > 1. jdk/test/java/util/logging/LoggingDeadlock2.java > starts a JVM subprocess > 2. the @run command line defines /timeout=15 > > My suggestion is thus simply to remove the /timeout=15 from the > @run command line, relying on the default jtreg timeout instead, Not unreasonable but how long does the test actually take to run on the problematic systems? > which hopefully will have been tuned for the global configuration > (fastdebug + -Xcomp) in which the testsuite is running. Hmm, well, no, not really. Xcomp + fastdebug + slow/small machines still leads to timeouts in places. We will just have to see how this one goes. David > best regards, > > -- daniel From jeremymanson at google.com Wed Jul 9 05:25:37 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 8 Jul 2014 22:25:37 -0700 Subject: Draft JEP: Efficient Stack Walking API In-Reply-To: <53BB604F.9020500@oracle.com> References: <5338A27B.1010309@oracle.com> <53BB604F.9020500@oracle.com> Message-ID: Thanks for the response, Mandy. I'm looking forward to seeing the final version. For CallerFinder, we use reflective goop to get at sun.misc.JavaLangAccess.getStackTraceElement. It requires us to build a Throwable (with associated stacktrace), but not to generate all of those StackTraceElement[] strings. This saves a lot of CPU cycles over something like Thread.getStackTrace(), but in this case, cheaper is better, and we'd definitely prefer a better solution. Functions like Java_java_lang_Throwable_fillInStackTrace are still big cycle consumers. Jeremy On Mon, Jul 7, 2014 at 8:06 PM, Mandy Chung wrote: > Hi Jeremy, > > Thanks for the feedback and the CallerFinder API you have. > > > On 7/7/2014 9:55 AM, Jeremy Manson wrote: > > Hey folks, > > I don't know if Mandy's draft JEP has gotten any love, > > > The JEP process is in transition to 2.0 version. Hope this JEP will come > out soon. > > > but this is something that has (in the past) been a major CPU cycle > consumer for us, and we've had to invent / reinvent many wheels to fix it > internally, so we'd love to see a principled solution. > > A couple of notes: > > - A large percentage of the time, you just want to find one of: > 1) The direct caller of the method, > 2) The first caller outside a given package. > > > The current thinking is to allow you to find the direct caller as well as > express the predicate for filtering that will cover these cases. > > > We added a CallerFinder API that basically looks like this: > > // Finds the caller of the invoking method in the current stack that > isn't in one of the excluded classes > public static StackTraceElement findCaller(Class... excludedClasses); > > // Finds the first caller of a given class > public static StackTraceElement findCallerOf(Class... classesToFind); > > This isn't the ideal API (it is more the one that happened to be > convenient when we threw together the class), but it gets the vast majority > of use cases. > > > Does it use Thread.getStackTrace() to implement this CallerFinder API? > Thread.getStackTrace or Throwable.getStackTrace both eagerly capture the > entire stack trace that is expensive. We want to have the VM to be able to > only capture the stack frames that the client needs and the implementation > as efficient as possible. > > > 2) Even with a super-efficient stack walker, anyone who uses the > java.util.logging framework pervasively is going to see a lot of CPU cycles > consumed by determining the caller. > > > The current LogRecord implementation calls new Throwable that has to pay > the cost of capturing the entire stack. > > > We've had a lot of luck minimizing this by using a bytecode rewriter to > change callers of log(msg) to log(sourceClass, sourceMethod, msg). This is > almost certainly something that could be done (even in a principled way!) > by the VM; improvements to CPU usage in such apps have been dramatic. > > > Thanks. I'll make sure to measure and compare the performance with > java.util.logging using the new stack walk API and also may ask your help > to determine if you observe the performance difference comparing the > rewritten bytecode vs the java.util.logging using the new API. > > Mandy > > > Jeremy > > > > On Sun, Mar 30, 2014 at 4:02 PM, Mandy Chung > wrote: > >> Below is a draft JEP we are considering submitting for JDK 9. >> >> Mandy >> >> ---------------------------- >> Title: Efficient API for Stack Walking >> >> Goal >> ---- >> >> Define a standard API for stack walking that will be efficient and >> performant. >> >> Non-goal >> -------- >> >> It is not a goal for this API be easy to use via Reflection for example >> use in code that is compiled for an older JDK. >> >> Motivation >> ---------- >> >> There is no standard API to obtain information about the caller's class >> and traverse the execution stack in a performant way. Existing libraries >> and frameworks such as Log4j and Groovy have to resort to using the >> JDK internal API `sun.reflect.Reflection.getCallerClass(int depth)`. >> >> This JEP proposes to define a standard API for stack walking that will >> be efficient and performant and also enable the implementation up >> level the stack walk machinery from the VM to Java and replaces >> the current mechanism of `Throwable.fillInStackTrace. >> >> Description >> ----------- >> >> There is no standard API to traverse certain frames on the execution >> stack efficiently and access the Class instance of each frame. >> >> There are APIs that allow to access the stack trace information: >> - `Throwable.getStackTrace()` and `Thread.getStackTrace()` that returns >> an array of `StackTraceElement` which contains the classname >> and method name of a stack trace. >> - `SecurityManager.getClassContext()` which is a protected method >> such that only `SecurityManager` subclass can access the class >> context. >> >> These APIs require the VM to eagerly capture a snapshot of the entire >> stack trace and returns the information representing the entire stack. >> There is no other way to avoid the cost to examine all frames if >> the caller is only interested in the top few frames on the stack. >> Both `Throwable.getStackTrace()` and `Thread.getStackTrace()` methods >> return an array of `StackTraceElement` that contains the classname and >> method name of a stack frame but the `Class` instance. >> >> In fact, for applications interested in the entire stack, the >> specification >> allows VM implementation to omit some frames in the stack for performance. >> In other words, `Thread.getStackTrace()` may return a partial stack trace. >> >> These APIs do not satisfy the use cases that currently depend on >> the `getCallerClass(int depth)` method or its performance overhead >> is intolerable. The use cases include: >> >> - JDK caller-sensitive APIs look up its immediate caller's class >> which will be used to determine the behavior of the API. For example >> `Class.forName(String classname)` and >> `ResourceBundle.getBundle(String rbname)` methods use the immediate >> caller's class loader to load a class and a resource bundle >> respectively. >> `Class.getMethod` etc will use the immediate caller's class loader >> to determine the security checks to be performed. >> >> - `java.util.logging`, Log4j and Groovy runtime filter the intermediary >> stack frames (typically implementation-specific and reflection frames) >> and find the caller's class to be used by the runtime of such library >> or framework. >> >> - Traverse the entire stack trace or the stack trace of a `Throwbale` >> and obtain additional information about classes for enhanced >> diagnosibility in addition to the class and method name. >> >> This JEP will define a stack walk API that allows laziness, frame >> filtering, >> supports short reaches to stop at a frame matching some criteria >> as well as long reaches to traverse the entire stack trace. This would >> need the JVM to provide a flexible mechanism to traverse and materialize >> the specific stack frame information to be used and allow efficient >> lazy access to additional stack frames when required. >> Native JVM transitions should be minimzed. >> >> The API will define how it works when running with a security manager >> that allows access to a `Class` instance >> of any frame ensuring that the security is not compromised. >> >> An example API to walk the stack can be like: >> Thread.walkStack(Consumer action, int depthLimit) >> >> that takes a callback to be invoked for each frame traversed. A variant >> of the walkStack method will take a predicate for stack frame filtering. >> >> Thread.getCaller(Function function) >> Thread.findCaller(Predicate predicate, >> Function function) >> >> finds the caller frame with or without filtering. >> >> Testing >> ------- >> >> Unit tests and JCK tests for the new SE API will need to be developed. >> In addition, the performance of the new API for different use cases >> will be assessed. >> >> >> Impact >> ------ >> >> - Performance/scalability: performance measurement shall be performed >> using micro-benchmarks as well as real world usage of `getCallerClass` >> replaced with the new API. >> >> - TCK: New JCK test cases shall be developed. >> >> > > From peter.levart at gmail.com Wed Jul 9 07:23:00 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 09 Jul 2014 09:23:00 +0200 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: References: <53B57E16.5020802@oracle.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC6506.3060308@oracle.com> <53BC6640.9020508@gmail.com> <53BC6B6F.6000709@oracle.com> <53BC73D7.7020900@gmail.com> <53BC8BF0.7000601@oracle.com> Message-ID: <53BCEDD4.6010906@gmail.com> On 07/09/2014 02:46 AM, Martin Buchholz wrote: > Let me understand - you're worried that when size is MAX_CAPACITY - 1, > then a call to putAll that does not actually add any elements might > throw? This is not possible, because resize() is only called from putAll(map) if argument map.size() > this.size. At least one element will be added to the map and it's correct to throw if current size == MAX_CAPACITY - 1. > Well, I'm having a hard time considering that corner case a bug, > given how unusable the map is at this point. It seems even this corner case is not present. > > Your suggested fix of returning immediately in case of no resize would > cause put to succeed and reach size == MAX_CAPACITY, which you were > trying to prevent. That's not possible either, since resize() is always called from put() with current table.length, which makes newLength == 2 * oldLength, therefore (oldLength >= newLength) will never succeed in this case. Peter > > > On Tue, Jul 8, 2014 at 5:25 PM, Ivan Gerasimov > > wrote: > > > On 09.07.2014 3:20, Martin Buchholz wrote: >> I agree with Peter that we do not need to increment modCount on >> resize. >> >> My latest webrev is again "done". >> >> Ivan, feel free to take over. > > Yes, thanks! The fix is much much better now. > > I think I see yet another very minor glitch, though. > If the table is already of size 2 * MAXIMUM_CAPACITY, and we're > merging in another map, which has more elements with putAll(), > resize() will be called and it will throw, even though all the > elements could fit into the map due to the key duplicates. > > To avoid this the following check should be done first in resize(): > > 469 if (oldLength >= newLength) > 470 return false; > > > Sincerely yours, > Ivan > > From peter.levart at gmail.com Wed Jul 9 07:33:29 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 09 Jul 2014 09:33:29 +0200 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53BCEDD4.6010906@gmail.com> References: <53B57E16.5020802@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC6506.3060308@oracle.com> <53BC6640.9020508@gmail.com> <53BC6B6F.6000709@oracle.com> <53BC73D7.7020900@gmail.com> <53BC8BF0.7000601@oracle.com> <53BCEDD4.6010906@gmail.com> Message-ID: <53BCF049.8090303@gmail.com> On 07/09/2014 09:23 AM, Peter Levart wrote: > > On 07/09/2014 02:46 AM, Martin Buchholz wrote: >> Let me understand - you're worried that when size is MAX_CAPACITY - >> 1, then a call to putAll that does not actually add any elements >> might throw? > > This is not possible, because resize() is only called from putAll(map) > if argument map.size() > this.size. At least one element will be added > to the map and it's correct to throw if current size == MAX_CAPACITY - 1. ...at least if the argument map obeys the rules of Map contract. Even if it's a HashMap or another IdentityHashMap, it should not contain the same INSTANCE of the key in two or more mappings, should not "overshoot" reporting it's size() and should be stable during the whole putAll() operation... So calling IHM.addAll() with a live changing ConcurrentHashMap is not advisable. Even then, addAll() could only throw, because at some point the argument's size indicated that IHM could reach it's max. capacity. Peter > >> Well, I'm having a hard time considering that corner case a bug, >> given how unusable the map is at this point. > > It seems even this corner case is not present. > >> >> Your suggested fix of returning immediately in case of no resize >> would cause put to succeed and reach size == MAX_CAPACITY, which you >> were trying to prevent. > > That's not possible either, since resize() is always called from put() > with current table.length, which makes newLength == 2 * oldLength, > therefore (oldLength >= newLength) will never succeed in this case. > > Peter > >> >> >> On Tue, Jul 8, 2014 at 5:25 PM, Ivan Gerasimov >> > wrote: >> >> >> On 09.07.2014 3:20, Martin Buchholz wrote: >>> I agree with Peter that we do not need to increment modCount on >>> resize. >>> >>> My latest webrev is again "done". >>> >>> Ivan, feel free to take over. >> >> Yes, thanks! The fix is much much better now. >> >> I think I see yet another very minor glitch, though. >> If the table is already of size 2 * MAXIMUM_CAPACITY, and we're >> merging in another map, which has more elements with putAll(), >> resize() will be called and it will throw, even though all the >> elements could fit into the map due to the key duplicates. >> >> To avoid this the following check should be done first in resize(): >> >> 469 if (oldLength >= newLength) >> 470 return false; >> >> >> Sincerely yours, >> Ivan >> >> > From petr.pchelko at oracle.com Wed Jul 9 08:07:45 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 9 Jul 2014 12:07:45 +0400 Subject: RFR: 8044862: Fix raw and unchecked lint warnings in macosx specific code In-Reply-To: <53BCB767.4090107@oracle.com> References: <53ADE5FD.20305@oracle.com> <53ADE96B.8070904@oracle.com> <53BCB767.4090107@oracle.com> Message-ID: Hello, Henry. AquaComboBoxRendererInternal : why and not just ? AquaComboBoxUI:427, 510, 530 - you can replace JComboBox with JComboBox and avoid a @SupressWarning annotation. AquaFileChooserUI.createDirectoryComboBoxRenderer actually returns a ListCellRenderer, DirectoryComboBoxModel is a model, and a combobox contains only Files. I suggest to try to genereficate this correctly and look where it brings us. Also I didn't look at the KeychainStore.java as I know nothing about this code. With best regards. Petr. On 09 ???? 2014 ?., at 7:30, Henry Jen wrote: > Hi, > > Would someone from swing team care to take a look at this? > > The change of src/macosx/classes/sun/font/CFontConfiguration.java will be dropped as it had been fixed in JDK-8048980. > > Cheers, > Henry > > > On 06/27/2014 03:00 PM, Joe Darcy wrote: >> Hi Henry, >> >> Your changes look good to me (I assume there was an issue using >> wildcards in AquaComboBoxButton.java). >> >> Thanks, >> >> -Joe >> >> On 06/27/2014 02:45 PM, Henry Jen wrote: >>> Hi, >>> >>> Please review a webrev for fixing rawtypes and unchecked lint warning >>> for macosx specific java code, this webrev is depending on >>> JDK-8043548[1] where some of the override methods are defined, >>> >>> Also as the src/macosx/classes/apple/launcher/JavaAppLauncher.java to >>> be removed from JDK-8048337, the webrev omits that file. >>> >>> The webrev can be found at, >>> http://cr.openjdk.java.net/~henryjen/jdk9/8044862/0/webrev/ >>> >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8043548 >>> >>> Cheers, >>> Henry >> From daniel.fuchs at oracle.com Wed Jul 9 09:32:16 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 09 Jul 2014 11:32:16 +0200 Subject: RFR: 8048913: java/util/logging/LoggingDeadlock2.java times out In-Reply-To: <53BCBAFB.7090203@oracle.com> References: <53BBEAF2.7030000@oracle.com> <53BCBAFB.7090203@oracle.com> Message-ID: <53BD0C20.6040206@oracle.com> On 7/9/14 5:46 AM, Mandy Chung wrote: > > On 7/8/2014 5:58 AM, Daniel Fuchs wrote: >> Hi, >> >> >> Please find below a fix for >> >> 8048913: java/util/logging/LoggingDeadlock2.java times out >> >> http://cr.openjdk.java.net/~dfuchs/webrev_8048913/webrev.00/ >> >> .... >> >> My suggestion is thus simply to remove the /timeout=15 from the >> @run command line, relying on the default jtreg timeout instead, >> which hopefully will have been tuned for the global configuration >> (fastdebug + -Xcomp) in which the testsuite is running. > > Do you know if the test was run with -timeoutFactor? Or does it use > the default timeout? Are you able to run the test with the same > configuration (on same test machine) to see how long it takes? I don't know. The machine that holds the log I had examined appears to be down. But I found another log on another machine where the test failed too - and I see it was called with -timeoutFactor=16.0 the test was killed after 240s, which looks like 16*15 if I'm not mistaken. What I can see also is that on my machine (which is not slow), and a product build, the test (with jtreg) reports 0.484 secs of execution without -Xcomp and 8.075 with it - which makes a factor of 16.68 - but that's not counting the 'fastdebug' effect (and I'm not sure we can assume a linear scale anyway). My own experience however tells me that attempting to specify timeouts directly in the test is a source of instability - and that leaving it up to jtreg is usually a better alternative. So I'd suggest trying to remove the timeout first and see how it goes. The fact that the test starts a subprocess doesn't help - as it makes it difficult to get debug information in case of timeout (but it's a deadlock test so we might not want to change the dynamics of the subprocess by adding too many debug traces). I'm not inclined to investigate too much as long as I can suspect the /timeout=15 parameter... -- daniel > > Mandy > From paul.sandoz at oracle.com Wed Jul 9 10:14:24 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 9 Jul 2014 12:14:24 +0200 Subject: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms In-Reply-To: <7FAEB94F-EB98-49A9-A4B0-9B4A6B730CA9@oracle.com> References: <5322EBF2.7030209@oracle.com> <5322F3D7.9010103@oracle.com> <94F61B19-8904-42FA-9E16-CC0A6B30FD79@oracle.com> <53230184.9090007@oracle.com> <2FCC64E3-3753-4CE0-9CC6-849FF737BFB5@oracle.com> <53232FF3.9020803@oracle.com> <53305E52.2060001@oracle.com> <53BBC340.7040509@oracle.com> <7FAEB94F-EB98-49A9-A4B0-9B4A6B730CA9@oracle.com> Message-ID: On Jul 8, 2014, at 9:09 PM, John Rose wrote: > Regarding the extra cast in accessor logic that Paul picked up on: That may be a left-over from obsolete versions of the code, or it may cover for some corner cases, or it could possibly be a re-assurance to the JIT. > > Generally speaking, we lean heavily on MH types to guarantee a priori correctness of argument types. Paul is right that the stored value type is already validated and (except for corner cases we may be neglecting) does not need re-validation via a cast. > > It might be an interesting experiment to replace the cast with an assert. > I did briefly look at that a few months ago, i would need to systematically revisit. My memory is hazy, I seem to recall removing casts perturbed the compilation process more than i expected. > Sometimes corner cases bite you. For example, an array store check is necessary, if the type is an interface, because interfaces are weakly checked all the way up to aastore or invokeinterface. > > Sometimes the JIT cannot see the type assurances implicit in a MH type, and so (when choosing internal MH code shapes) we must choose between handing the JIT code that is not locally verifiable, or adding "reassurance" casts to repair the local verifiability of the code. If the JIT thinks it sees badly-typed code, it might bail out.Note that "locality" of verifiability is a fluid concept, depending sometime on vagaries of inlining decisions. This is the reason for some awkward looking "belt and suspenders" MH internals, such as the free use of casts in LF bytecode rendering. > > Usually, redundant type verifications (including casts and signatures of incoming arguments) are eliminated, but they can cause (as noted) an extra null check. In theory, that should fold up also, if the null value is replaced by "another" null, as (p == null ? null : identityFunction(p)). > I quickly verified the fold up does as you expect. Also, if i do the following the null check goes away: public class A { volatile String a = "A"; volatile String snull = null; public volatile String b; static final MethodHandle b_setter; static { try { b_setter = MethodHandles.lookup().findSetter(A.class, "b", String.class); } catch (Exception e) { throw new Error(e); } } public static void main(String[] args) { A a = new A(); a.testLoop(); } void testLoop() { for (int i = 0; i < 1000000; i++) { testLoopOne(a); testLoopOne(snull); } } void testLoopOne(String s) { try { b_setter.invokeExact(this, s); } catch (Throwable t) { throw new Error(t); } } } I am probably obsessing too much over some micro/nano-benchmarks, but i am wondering if this could cause some unwanted de-opt/recompilation effects when all is good with no null values then suddenly a null triggers de-optimization. Paul. From Alan.Bateman at oracle.com Wed Jul 9 11:10:13 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 09 Jul 2014 12:10:13 +0100 Subject: [concurrency-interest] URI + RFC3986 compliance In-Reply-To: <53BD1BC0.4070109@zeus.net.au> References: <1404006830.14661.4.camel@Nokia-N900> <53AFDC5E.5070702@gmail.com> <53B135B6.1030105@zeus.net.au> <53B15DD2.8020200@oracle.com> <53B3B072.6030406@zeus.net.au> <53B3E29F.9010901@oracle.com> <53BD1BC0.4070109@zeus.net.au> Message-ID: <53BD2315.4080300@oracle.com> On 09/07/2014 11:38, Peter Firmstone wrote: > I've had some time to think about how to make java.net.URI comply with > RFC3986 as well as retain the existing implementation for backward > compatibility: > > 1. Strip out the existing URI class and Parser, create an abstract > private delegate, move URI's implementation into a concrete > delegate. Create a new delgate for RFC3986. > 2. Use a system property to determine whether URI uses the existing > implementation or RFC3986. > 3. Retain existing Serial form, represented by a String. > 4. Use one transient volatile field to refer to the delgate, remove > all other fields from the encapsulating URI class, the delegates > are not Serializable. Alternatively we may make all fields final > by reworking Serializable code to ensure only the String field is > written and read from the stream and by updating the delegate > final field reference during deserialization. > 5. Make the delegate implementations final and immutable, don't > lazily initialize. > 6. All methods refer to the delegate, the implementation of which is > determined by the system property and instantiated at construction > and during deserialization. The OpenJDK net-dev list would be the best to start a new thread on this. At a high-level then I don't think system-wide configuration (#2) to toggle between RFC 2396 and 3986 is really feasible, particularly when you have an application that is built from libraries coming from many places. Also what would this mean for specification, particularly opaque URIs and specification dealing with the scheme specific part. Also think testing, is an implementation required to support both and does it mean running tests with both settings? For the discussion on net-dev then I think it would be good to get into the major differences between the two RFCs and also the history and the previous attempt to rev java.net.URI. There have been a number of suggestions since then on what APIs might need to be added. My gut feel is that the overall effort is not going to be trivial and will likely need a JEP. -Alan From miroslav.kos at oracle.com Wed Jul 9 11:13:12 2014 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Wed, 09 Jul 2014 13:13:12 +0200 Subject: RFR: 8044656: Update JAX-WS RI integration to latest version In-Reply-To: <53BB26EE.2090704@oracle.com> References: <53B18EE1.1080502@oracle.com> <53BB26EE.2090704@oracle.com> Message-ID: <53BD23C8.8070303@oracle.com> Hi Joe, thanks for comments - see inline: On 08/07/14 01:02, huizhe wang wrote: > Hi Miran, > > In class src/share/jaxws_classes/com/sun/tools/internal/xjc/Options.java: > + // hack to force initialization so catalog manager system > properties take effect > + staticManager.getVerbosity(); According to Iaroslav (JAXB lead), the initilization is necessary. It looks like system property is used only if initialization performed via getter. > > Is that necessary? I thought the next call to getCatalog would > initialize the properties from the CatalogManager property file. > > Using ServiceLoader in class > src/share/jaxws_classes/javax/xml/ws/spi/Provider.java: > Would you need to give the process privilege? Or maybe the method is > already called in a privileged block? I think it doesn't - the previous version was exactly same, the only difference was that it was called via reflection. M. > > Thanks, > Joe > > On 6/30/2014 9:22 AM, Miroslav Kos wrote: >> Hi, >> there is a bulk update of JAX-B/WS from upstream projects - >> webrev: http://cr.openjdk.java.net/~mkos/8044656/jaxws.00/ >> more details in issue desc: >> https://bugs.openjdk.java.net/browse/JDK-8044656 >> >> Could I ask for a review/approval? >> >> Thanks >> Miran > From david.lloyd at redhat.com Wed Jul 9 13:42:42 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 09 Jul 2014 08:42:42 -0500 Subject: Draft JEP: Efficient Stack Walking API In-Reply-To: References: <5338A27B.1010309@oracle.com> <53BB604F.9020500@oracle.com> Message-ID: <53BD46D2.2010405@redhat.com> Just want to say that I am also looking forward to progress on this. On 07/09/2014 12:25 AM, Jeremy Manson wrote: > Thanks for the response, Mandy. I'm looking forward to seeing the final > version. > > For CallerFinder, we use reflective goop to get at > sun.misc.JavaLangAccess.getStackTraceElement. It requires us to build a > Throwable (with associated stacktrace), but not to generate all of those > StackTraceElement[] strings. This saves a lot of CPU cycles over something > like Thread.getStackTrace(), but in this case, cheaper is better, and we'd > definitely prefer a better solution. Functions like > Java_java_lang_Throwable_fillInStackTrace are still big cycle consumers. > > Jeremy > > > On Mon, Jul 7, 2014 at 8:06 PM, Mandy Chung wrote: > >> Hi Jeremy, >> >> Thanks for the feedback and the CallerFinder API you have. >> >> >> On 7/7/2014 9:55 AM, Jeremy Manson wrote: >> >> Hey folks, >> >> I don't know if Mandy's draft JEP has gotten any love, >> >> >> The JEP process is in transition to 2.0 version. Hope this JEP will come >> out soon. >> >> >> but this is something that has (in the past) been a major CPU cycle >> consumer for us, and we've had to invent / reinvent many wheels to fix it >> internally, so we'd love to see a principled solution. >> >> A couple of notes: >> >> - A large percentage of the time, you just want to find one of: >> 1) The direct caller of the method, >> 2) The first caller outside a given package. >> >> >> The current thinking is to allow you to find the direct caller as well as >> express the predicate for filtering that will cover these cases. >> >> >> We added a CallerFinder API that basically looks like this: >> >> // Finds the caller of the invoking method in the current stack that >> isn't in one of the excluded classes >> public static StackTraceElement findCaller(Class... excludedClasses); >> >> // Finds the first caller of a given class >> public static StackTraceElement findCallerOf(Class... classesToFind); >> >> This isn't the ideal API (it is more the one that happened to be >> convenient when we threw together the class), but it gets the vast majority >> of use cases. >> >> >> Does it use Thread.getStackTrace() to implement this CallerFinder API? >> Thread.getStackTrace or Throwable.getStackTrace both eagerly capture the >> entire stack trace that is expensive. We want to have the VM to be able to >> only capture the stack frames that the client needs and the implementation >> as efficient as possible. >> >> >> 2) Even with a super-efficient stack walker, anyone who uses the >> java.util.logging framework pervasively is going to see a lot of CPU cycles >> consumed by determining the caller. >> >> >> The current LogRecord implementation calls new Throwable that has to pay >> the cost of capturing the entire stack. >> >> >> We've had a lot of luck minimizing this by using a bytecode rewriter to >> change callers of log(msg) to log(sourceClass, sourceMethod, msg). This is >> almost certainly something that could be done (even in a principled way!) >> by the VM; improvements to CPU usage in such apps have been dramatic. >> >> >> Thanks. I'll make sure to measure and compare the performance with >> java.util.logging using the new stack walk API and also may ask your help >> to determine if you observe the performance difference comparing the >> rewritten bytecode vs the java.util.logging using the new API. >> >> Mandy >> >> >> Jeremy >> >> >> >> On Sun, Mar 30, 2014 at 4:02 PM, Mandy Chung >> wrote: >> >>> Below is a draft JEP we are considering submitting for JDK 9. >>> >>> Mandy >>> >>> ---------------------------- >>> Title: Efficient API for Stack Walking >>> >>> Goal >>> ---- >>> >>> Define a standard API for stack walking that will be efficient and >>> performant. >>> >>> Non-goal >>> -------- >>> >>> It is not a goal for this API be easy to use via Reflection for example >>> use in code that is compiled for an older JDK. >>> >>> Motivation >>> ---------- >>> >>> There is no standard API to obtain information about the caller's class >>> and traverse the execution stack in a performant way. Existing libraries >>> and frameworks such as Log4j and Groovy have to resort to using the >>> JDK internal API `sun.reflect.Reflection.getCallerClass(int depth)`. >>> >>> This JEP proposes to define a standard API for stack walking that will >>> be efficient and performant and also enable the implementation up >>> level the stack walk machinery from the VM to Java and replaces >>> the current mechanism of `Throwable.fillInStackTrace. >>> >>> Description >>> ----------- >>> >>> There is no standard API to traverse certain frames on the execution >>> stack efficiently and access the Class instance of each frame. >>> >>> There are APIs that allow to access the stack trace information: >>> - `Throwable.getStackTrace()` and `Thread.getStackTrace()` that returns >>> an array of `StackTraceElement` which contains the classname >>> and method name of a stack trace. >>> - `SecurityManager.getClassContext()` which is a protected method >>> such that only `SecurityManager` subclass can access the class >>> context. >>> >>> These APIs require the VM to eagerly capture a snapshot of the entire >>> stack trace and returns the information representing the entire stack. >>> There is no other way to avoid the cost to examine all frames if >>> the caller is only interested in the top few frames on the stack. >>> Both `Throwable.getStackTrace()` and `Thread.getStackTrace()` methods >>> return an array of `StackTraceElement` that contains the classname and >>> method name of a stack frame but the `Class` instance. >>> >>> In fact, for applications interested in the entire stack, the >>> specification >>> allows VM implementation to omit some frames in the stack for performance. >>> In other words, `Thread.getStackTrace()` may return a partial stack trace. >>> >>> These APIs do not satisfy the use cases that currently depend on >>> the `getCallerClass(int depth)` method or its performance overhead >>> is intolerable. The use cases include: >>> >>> - JDK caller-sensitive APIs look up its immediate caller's class >>> which will be used to determine the behavior of the API. For example >>> `Class.forName(String classname)` and >>> `ResourceBundle.getBundle(String rbname)` methods use the immediate >>> caller's class loader to load a class and a resource bundle >>> respectively. >>> `Class.getMethod` etc will use the immediate caller's class loader >>> to determine the security checks to be performed. >>> >>> - `java.util.logging`, Log4j and Groovy runtime filter the intermediary >>> stack frames (typically implementation-specific and reflection frames) >>> and find the caller's class to be used by the runtime of such library >>> or framework. >>> >>> - Traverse the entire stack trace or the stack trace of a `Throwbale` >>> and obtain additional information about classes for enhanced >>> diagnosibility in addition to the class and method name. >>> >>> This JEP will define a stack walk API that allows laziness, frame >>> filtering, >>> supports short reaches to stop at a frame matching some criteria >>> as well as long reaches to traverse the entire stack trace. This would >>> need the JVM to provide a flexible mechanism to traverse and materialize >>> the specific stack frame information to be used and allow efficient >>> lazy access to additional stack frames when required. >>> Native JVM transitions should be minimzed. >>> >>> The API will define how it works when running with a security manager >>> that allows access to a `Class` instance >>> of any frame ensuring that the security is not compromised. >>> >>> An example API to walk the stack can be like: >>> Thread.walkStack(Consumer action, int depthLimit) >>> >>> that takes a callback to be invoked for each frame traversed. A variant >>> of the walkStack method will take a predicate for stack frame filtering. >>> >>> Thread.getCaller(Function function) >>> Thread.findCaller(Predicate predicate, >>> Function function) >>> >>> finds the caller frame with or without filtering. >>> >>> Testing >>> ------- >>> >>> Unit tests and JCK tests for the new SE API will need to be developed. >>> In addition, the performance of the new API for different use cases >>> will be assessed. >>> >>> >>> Impact >>> ------ >>> >>> - Performance/scalability: performance measurement shall be performed >>> using micro-benchmarks as well as real world usage of `getCallerClass` >>> replaced with the new API. >>> >>> - TCK: New JCK test cases shall be developed. >>> >>> >> >> -- - DML From mike at saxonica.com Wed Jul 9 13:48:25 2014 From: mike at saxonica.com (Michael Kay) Date: Wed, 9 Jul 2014 14:48:25 +0100 Subject: [concurrency-interest] URI + RFC3986 compliance In-Reply-To: <53BD2315.4080300@oracle.com> References: <1404006830.14661.4.camel@Nokia-N900> <53AFDC5E.5070702@gmail.com> <53B135B6.1030105@zeus.net.au> <53B15DD2.8020200@oracle.com> <53B3B072.6030406@zeus.net.au> <53B3E29F.9010901@oracle.com> <53BD1BC0.4070109@zeus.net.au> <53BD2315.4080300@oracle.com> Message-ID: <8E483A7C-F92A-478D-B578-E961B92DDA0A@saxonica.com> +1. As the author of a library that uses the URI class, I need control over how it is behaving, and I cannot assume that other libraries in the same VM want the same options as I do. Michael Kay Saxonica mike at saxonica.com +44 (0118) 946 5893 On 9 Jul 2014, at 12:10, Alan Bateman wrote: > On 09/07/2014 11:38, Peter Firmstone wrote: >> I've had some time to think about how to make java.net.URI comply with RFC3986 as well as retain the existing implementation for backward compatibility: >> >> 1. Strip out the existing URI class and Parser, create an abstract >> private delegate, move URI's implementation into a concrete >> delegate. Create a new delgate for RFC3986. >> 2. Use a system property to determine whether URI uses the existing >> implementation or RFC3986. >> 3. Retain existing Serial form, represented by a String. >> 4. Use one transient volatile field to refer to the delgate, remove >> all other fields from the encapsulating URI class, the delegates >> are not Serializable. Alternatively we may make all fields final >> by reworking Serializable code to ensure only the String field is >> written and read from the stream and by updating the delegate >> final field reference during deserialization. >> 5. Make the delegate implementations final and immutable, don't >> lazily initialize. >> 6. All methods refer to the delegate, the implementation of which is >> determined by the system property and instantiated at construction >> and during deserialization. > The OpenJDK net-dev list would be the best to start a new thread on this. > > At a high-level then I don't think system-wide configuration (#2) to toggle between RFC 2396 and 3986 is really feasible, particularly when you have an application that is built from libraries coming from many places. Also what would this mean for specification, particularly opaque URIs and specification dealing with the scheme specific part. Also think testing, is an implementation required to support both and does it mean running tests with both settings? > > For the discussion on net-dev then I think it would be good to get into the major differences between the two RFCs and also the history and the previous attempt to rev java.net.URI. There have been a number of suggestions since then on what APIs might need to be added. My gut feel is that the overall effort is not going to be trivial and will likely need a JEP. > > -Alan > From mandy.chung at oracle.com Wed Jul 9 13:57:22 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 09 Jul 2014 06:57:22 -0700 Subject: RFR: 8048913: java/util/logging/LoggingDeadlock2.java times out In-Reply-To: <53BD0C20.6040206@oracle.com> References: <53BBEAF2.7030000@oracle.com> <53BCBAFB.7090203@oracle.com> <53BD0C20.6040206@oracle.com> Message-ID: <53BD4A42.7060301@oracle.com> On 7/9/2014 2:32 AM, Daniel Fuchs wrote: > On 7/9/14 5:46 AM, Mandy Chung wrote: >> >> Do you know if the test was run with -timeoutFactor? Or does it use >> the default timeout? Are you able to run the test with the same >> configuration (on same test machine) to see how long it takes? > > ... > > What I can see also is that on my machine (which is not slow), > and a product build, the test (with jtreg) reports 0.484 secs of > execution without -Xcomp and 8.075 with it - which makes a factor > of 16.68 - but that's not counting the 'fastdebug' effect > (and I'm not sure we can assume a linear scale anyway). > > ... > > With fastdebug + -Xcomp still on my machine it takes 41.931 secs. > If the slowdown were linear it would need a timeoutFactor of ~ 86.63 ~42 secs and VM nightly may want to exclude this kind of tests. Thanks for the numbers. Your fix is good to go. Mandy From forax at univ-mlv.fr Wed Jul 9 14:11:30 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 09 Jul 2014 16:11:30 +0200 Subject: Draft JEP: Efficient Stack Walking API In-Reply-To: <53BD46D2.2010405@redhat.com> References: <5338A27B.1010309@oracle.com> <53BB604F.9020500@oracle.com> <53BD46D2.2010405@redhat.com> Message-ID: <53BD4D92.9010004@univ-mlv.fr> On 07/09/2014 03:42 PM, David M. Lloyd wrote: > Just want to say that I am also looking forward to progress on this. so am i :) R?mi > > On 07/09/2014 12:25 AM, Jeremy Manson wrote: >> Thanks for the response, Mandy. I'm looking forward to seeing the final >> version. >> >> For CallerFinder, we use reflective goop to get at >> sun.misc.JavaLangAccess.getStackTraceElement. It requires us to build a >> Throwable (with associated stacktrace), but not to generate all of those >> StackTraceElement[] strings. This saves a lot of CPU cycles over >> something >> like Thread.getStackTrace(), but in this case, cheaper is better, and >> we'd >> definitely prefer a better solution. Functions like >> Java_java_lang_Throwable_fillInStackTrace are still big cycle consumers. >> >> Jeremy >> >> >> On Mon, Jul 7, 2014 at 8:06 PM, Mandy Chung >> wrote: >> >>> Hi Jeremy, >>> >>> Thanks for the feedback and the CallerFinder API you have. >>> >>> >>> On 7/7/2014 9:55 AM, Jeremy Manson wrote: >>> >>> Hey folks, >>> >>> I don't know if Mandy's draft JEP has gotten any love, >>> >>> >>> The JEP process is in transition to 2.0 version. Hope this JEP will >>> come >>> out soon. >>> >>> >>> but this is something that has (in the past) been a major CPU cycle >>> consumer for us, and we've had to invent / reinvent many wheels to >>> fix it >>> internally, so we'd love to see a principled solution. >>> >>> A couple of notes: >>> >>> - A large percentage of the time, you just want to find one of: >>> 1) The direct caller of the method, >>> 2) The first caller outside a given package. >>> >>> >>> The current thinking is to allow you to find the direct caller as >>> well as >>> express the predicate for filtering that will cover these cases. >>> >>> >>> We added a CallerFinder API that basically looks like this: >>> >>> // Finds the caller of the invoking method in the current stack that >>> isn't in one of the excluded classes >>> public static StackTraceElement findCaller(Class... >>> excludedClasses); >>> >>> // Finds the first caller of a given class >>> public static StackTraceElement findCallerOf(Class... >>> classesToFind); >>> >>> This isn't the ideal API (it is more the one that happened to be >>> convenient when we threw together the class), but it gets the vast >>> majority >>> of use cases. >>> >>> >>> Does it use Thread.getStackTrace() to implement this CallerFinder API? >>> Thread.getStackTrace or Throwable.getStackTrace both eagerly capture >>> the >>> entire stack trace that is expensive. We want to have the VM to be >>> able to >>> only capture the stack frames that the client needs and the >>> implementation >>> as efficient as possible. >>> >>> >>> 2) Even with a super-efficient stack walker, anyone who uses the >>> java.util.logging framework pervasively is going to see a lot of CPU >>> cycles >>> consumed by determining the caller. >>> >>> >>> The current LogRecord implementation calls new Throwable that has to >>> pay >>> the cost of capturing the entire stack. >>> >>> >>> We've had a lot of luck minimizing this by using a bytecode >>> rewriter to >>> change callers of log(msg) to log(sourceClass, sourceMethod, msg). >>> This is >>> almost certainly something that could be done (even in a principled >>> way!) >>> by the VM; improvements to CPU usage in such apps have been dramatic. >>> >>> >>> Thanks. I'll make sure to measure and compare the performance with >>> java.util.logging using the new stack walk API and also may ask your >>> help >>> to determine if you observe the performance difference comparing the >>> rewritten bytecode vs the java.util.logging using the new API. >>> >>> Mandy >>> >>> >>> Jeremy >>> >>> >>> >>> On Sun, Mar 30, 2014 at 4:02 PM, Mandy Chung >>> wrote: >>> >>>> Below is a draft JEP we are considering submitting for JDK 9. >>>> >>>> Mandy >>>> >>>> ---------------------------- >>>> Title: Efficient API for Stack Walking >>>> >>>> Goal >>>> ---- >>>> >>>> Define a standard API for stack walking that will be efficient and >>>> performant. >>>> >>>> Non-goal >>>> -------- >>>> >>>> It is not a goal for this API be easy to use via Reflection for >>>> example >>>> use in code that is compiled for an older JDK. >>>> >>>> Motivation >>>> ---------- >>>> >>>> There is no standard API to obtain information about the caller's >>>> class >>>> and traverse the execution stack in a performant way. Existing >>>> libraries >>>> and frameworks such as Log4j and Groovy have to resort to using the >>>> JDK internal API `sun.reflect.Reflection.getCallerClass(int depth)`. >>>> >>>> This JEP proposes to define a standard API for stack walking that will >>>> be efficient and performant and also enable the implementation up >>>> level the stack walk machinery from the VM to Java and replaces >>>> the current mechanism of `Throwable.fillInStackTrace. >>>> >>>> Description >>>> ----------- >>>> >>>> There is no standard API to traverse certain frames on the execution >>>> stack efficiently and access the Class instance of each frame. >>>> >>>> There are APIs that allow to access the stack trace information: >>>> - `Throwable.getStackTrace()` and `Thread.getStackTrace()` that >>>> returns >>>> an array of `StackTraceElement` which contains the classname >>>> and method name of a stack trace. >>>> - `SecurityManager.getClassContext()` which is a protected method >>>> such that only `SecurityManager` subclass can access the class >>>> context. >>>> >>>> These APIs require the VM to eagerly capture a snapshot of the entire >>>> stack trace and returns the information representing the entire stack. >>>> There is no other way to avoid the cost to examine all frames if >>>> the caller is only interested in the top few frames on the stack. >>>> Both `Throwable.getStackTrace()` and `Thread.getStackTrace()` methods >>>> return an array of `StackTraceElement` that contains the classname and >>>> method name of a stack frame but the `Class` instance. >>>> >>>> In fact, for applications interested in the entire stack, the >>>> specification >>>> allows VM implementation to omit some frames in the stack for >>>> performance. >>>> In other words, `Thread.getStackTrace()` may return a partial stack >>>> trace. >>>> >>>> These APIs do not satisfy the use cases that currently depend on >>>> the `getCallerClass(int depth)` method or its performance overhead >>>> is intolerable. The use cases include: >>>> >>>> - JDK caller-sensitive APIs look up its immediate caller's class >>>> which will be used to determine the behavior of the API. For >>>> example >>>> `Class.forName(String classname)` and >>>> `ResourceBundle.getBundle(String rbname)` methods use the >>>> immediate >>>> caller's class loader to load a class and a resource bundle >>>> respectively. >>>> `Class.getMethod` etc will use the immediate caller's class >>>> loader >>>> to determine the security checks to be performed. >>>> >>>> - `java.util.logging`, Log4j and Groovy runtime filter the >>>> intermediary >>>> stack frames (typically implementation-specific and reflection >>>> frames) >>>> and find the caller's class to be used by the runtime of such >>>> library >>>> or framework. >>>> >>>> - Traverse the entire stack trace or the stack trace of a >>>> `Throwbale` >>>> and obtain additional information about classes for enhanced >>>> diagnosibility in addition to the class and method name. >>>> >>>> This JEP will define a stack walk API that allows laziness, frame >>>> filtering, >>>> supports short reaches to stop at a frame matching some criteria >>>> as well as long reaches to traverse the entire stack trace. This would >>>> need the JVM to provide a flexible mechanism to traverse and >>>> materialize >>>> the specific stack frame information to be used and allow efficient >>>> lazy access to additional stack frames when required. >>>> Native JVM transitions should be minimzed. >>>> >>>> The API will define how it works when running with a security manager >>>> that allows access to a `Class` instance >>>> of any frame ensuring that the security is not compromised. >>>> >>>> An example API to walk the stack can be like: >>>> Thread.walkStack(Consumer action, int depthLimit) >>>> >>>> that takes a callback to be invoked for each frame traversed. A >>>> variant >>>> of the walkStack method will take a predicate for stack frame >>>> filtering. >>>> >>>> Thread.getCaller(Function function) >>>> Thread.findCaller(Predicate predicate, >>>> Function function) >>>> >>>> finds the caller frame with or without filtering. >>>> >>>> Testing >>>> ------- >>>> >>>> Unit tests and JCK tests for the new SE API will need to be developed. >>>> In addition, the performance of the new API for different use cases >>>> will be assessed. >>>> >>>> >>>> Impact >>>> ------ >>>> >>>> - Performance/scalability: performance measurement shall be >>>> performed >>>> using micro-benchmarks as well as real world usage of >>>> `getCallerClass` >>>> replaced with the new API. >>>> >>>> - TCK: New JCK test cases shall be developed. >>>> >>>> >>> >>> > From martinrb at google.com Wed Jul 9 16:36:53 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 9 Jul 2014 09:36:53 -0700 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53BCF049.8090303@gmail.com> References: <53B57E16.5020802@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC6506.3060308@oracle.com> <53BC6640.9020508@gmail.com> <53BC6B6F.6000709@oracle.com> <53BC73D7.7020900@gmail.com> <53BC8BF0.7000601@oracle.com> <53BCEDD4.6010906@gmail.com> <53BCF049.8090303@gmail.com> Message-ID: OK, I think we're down to the smallest possible bug: if size == MAX_CAPACITY - 1 and we putAll a concurrent map with greater size, but the concurrent map shrinks while we're adding it, and no actual elements get added to the IHM (but each element put takes ~ 2**28 probes), then an ISE is thrown when it was not strictly necessary. Meanwhile, I'm actually wishing we could throw at something like 80% full... Relatedly: It occurs to me that it's traditional in java.util to throw OOME instead of ISE for capacity exceeded. On Wed, Jul 9, 2014 at 12:33 AM, Peter Levart wrote: > > On 07/09/2014 09:23 AM, Peter Levart wrote: > > > On 07/09/2014 02:46 AM, Martin Buchholz wrote: > > Let me understand - you're worried that when size is MAX_CAPACITY - 1, > then a call to putAll that does not actually add any elements might throw? > > > This is not possible, because resize() is only called from putAll(map) if > argument map.size() > this.size. At least one element will be added to the > map and it's correct to throw if current size == MAX_CAPACITY - 1. > > > ...at least if the argument map obeys the rules of Map contract. Even if > it's a HashMap or another IdentityHashMap, it should not contain the same > INSTANCE of the key in two or more mappings, should not "overshoot" > reporting it's size() and should be stable during the whole putAll() > operation... So calling IHM.addAll() with a live changing ConcurrentHashMap > is not advisable. Even then, addAll() could only throw, because at some > point the argument's size indicated that IHM could reach it's max. capacity. > > Peter > > > > Well, I'm having a hard time considering that corner case a bug, given > how unusable the map is at this point. > > > It seems even this corner case is not present. > > > Your suggested fix of returning immediately in case of no resize would > cause put to succeed and reach size == MAX_CAPACITY, which you were trying > to prevent. > > > That's not possible either, since resize() is always called from put() > with current table.length, which makes newLength == 2 * oldLength, > therefore (oldLength >= newLength) will never succeed in this case. > > Peter > > > > On Tue, Jul 8, 2014 at 5:25 PM, Ivan Gerasimov > wrote: > >> >> On 09.07.2014 3:20, Martin Buchholz wrote: >> >> I agree with Peter that we do not need to increment modCount on resize. >> >> My latest webrev is again "done". >> >> Ivan, feel free to take over. >> >> >> Yes, thanks! The fix is much much better now. >> >> I think I see yet another very minor glitch, though. >> If the table is already of size 2 * MAXIMUM_CAPACITY, and we're merging >> in another map, which has more elements with putAll(), resize() will be >> called and it will throw, even though all the elements could fit into the >> map due to the key duplicates. >> >> To avoid this the following check should be done first in resize(): >> >> 469 if (oldLength >= newLength) 470 return false; >> >> Sincerely yours, >> Ivan >> > > > > From bernd-2014 at eckenfels.net Wed Jul 2 21:13:19 2014 From: bernd-2014 at eckenfels.net (Bernd Eckenfels) Date: Wed, 2 Jul 2014 23:13:19 +0200 Subject: RFR JDK-7186258: InetAddress$Cache should replace currentTimeMillis with nanoTime (+more) In-Reply-To: <53B3F377.3090208@gmail.com> References: <53B2FF8D.5040503@gmail.com> <20140701220621.00005e21.bernd-2014@eckenfels.net> <53B3F377.3090208@gmail.com> Message-ID: <20140702231319.000053e8.bernd-2014@eckenfels.net> Hello Peter, I think the comments in compareTo() are now superflucious ("with 0"). Greetings Bernd Am Wed, 02 Jul 2014 13:56:39 +0200 schrieb Peter Levart : > Hi, > > I updated the webrev with first two suggestions from Bernd > (expireTime instead of createTime and cacheNanos + only use > putIfAbsent instead of get followed by putIfAbsent): > > http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/webrev.02/ From huizhe.wang at oracle.com Wed Jul 9 17:09:15 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 09 Jul 2014 10:09:15 -0700 Subject: RFR: 8044656: Update JAX-WS RI integration to latest version In-Reply-To: <53BD23C8.8070303@oracle.com> References: <53B18EE1.1080502@oracle.com> <53BB26EE.2090704@oracle.com> <53BD23C8.8070303@oracle.com> Message-ID: <53BD773B.50306@oracle.com> On 7/9/2014 4:13 AM, Miroslav Kos wrote: > Hi Joe, > > thanks for comments - see inline: > > On 08/07/14 01:02, huizhe wang wrote: >> Hi Miran, >> >> In class >> src/share/jaxws_classes/com/sun/tools/internal/xjc/Options.java: >> + // hack to force initialization so catalog manager >> system properties take effect >> + staticManager.getVerbosity(); > According to Iaroslav (JAXB lead), the initilization is necessary. It > looks like system property is used only if initialization performed > via getter. Initialization is performed when a CatalogResolver is constructed, where initializeCatalogs is called that in turn calls CatalogManager.getCatalog, here's what's on the stack: CatalogManager.readProperties <-- read properties in CatalogManager.properties CatalogManager.queryUseStaticCatalog CatalogManager.getUseStaticCatalog CatalogManager.getCatalog CatalogManager.initalizeCatalogs CatalogManager. It doesn't hurt to call the getter since CatalogManager.properties will be read once, but it doesn't seem necessary to me. The reason I asked was that if CatalogResolver had not been initialized properly, there would be a problem with the Catalog impl that we could file a bug and get it fixed. >> >> Is that necessary? I thought the next call to getCatalog would >> initialize the properties from the CatalogManager property file. >> >> Using ServiceLoader in class >> src/share/jaxws_classes/javax/xml/ws/spi/Provider.java: >> Would you need to give the process privilege? Or maybe the method is >> already called in a privileged block? > I think it doesn't - the previous version was exactly same, the only > difference was that it was called via reflection. It's a use pattern that we use in other places so that when Security Manager is present, ServiceLoader works as expected. -Joe > > M. > >> >> Thanks, >> Joe >> >> On 6/30/2014 9:22 AM, Miroslav Kos wrote: >>> Hi, >>> there is a bulk update of JAX-B/WS from upstream projects - >>> webrev: http://cr.openjdk.java.net/~mkos/8044656/jaxws.00/ >>> more details in issue desc: >>> https://bugs.openjdk.java.net/browse/JDK-8044656 >>> >>> Could I ask for a review/approval? >>> >>> Thanks >>> Miran >> > From john.r.rose at oracle.com Wed Jul 9 18:04:55 2014 From: john.r.rose at oracle.com (John Rose) Date: Wed, 9 Jul 2014 11:04:55 -0700 Subject: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms In-Reply-To: References: <5322EBF2.7030209@oracle.com> <5322F3D7.9010103@oracle.com> <94F61B19-8904-42FA-9E16-CC0A6B30FD79@oracle.com> <53230184.9090007@oracle.com> <2FCC64E3-3753-4CE0-9CC6-849FF737BFB5@oracle.com> <53232FF3.9020803@oracle.com> <53305E52.2060001@oracle.com> <53BBC340.7040509@oracle.com> <7FAEB94F-EB98-49A9-A4B0-9B4A6B730CA9@oracle.com> Message-ID: On Jul 9, 2014, at 3:14 AM, Paul Sandoz wrote: > > I quickly verified the fold up does as you expect. Also, if i do the following the null check goes away: > > ... > > void testLoop() { > for (int i = 0; i < 1000000; i++) { > testLoopOne(a); > testLoopOne(snull); > } > } Good observation. So rather than missing a null-case fold-up (good it's not!), the optimizer is speculating not-nullness (based on profile) and adding a test. (Either the test is being used for a downstream optimization, or else the test is not being detected as useless and removed?which would be bad!.) > I am probably obsessing too much over some micro/nano-benchmarks, (Hi, I'm John and I'm a micro-obsess-aholic.) > but i am wondering if this could cause some unwanted de-opt/recompilation effects when all is good with no null values then suddenly a null triggers de-optimization. Besides jumping after the micro-benchmark and chewing on the optimizer until the code shrinks, there are two other things we can do: 1. Mentally file the issue and watch real benchmarks for evidence of the problem. (This works pretty well, provided enough time and focus, and provided enough people have some consciousness of the optimizer's workings.) 2. Create a self-test and check it into the test base. It could be either a unit test of assertion. In this case, I don't see an easy way to do it, but creating clever permanent tests almost always pays off much better than cleverly pounding on the micro-benchmark of the moment. ? John From xueming.shen at oracle.com Wed Jul 9 20:04:38 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 09 Jul 2014 13:04:38 -0700 Subject: RFR: JDK-8042589: String.toLowerCase do not work for some concatenated strings Message-ID: <53BDA056.8050305@oracle.com> Hi, Please help review the change for JDK-8042589. Issue: https://bugs.openjdk.java.net/browse/JDK-8042589 webrev: http://cr.openjdk.java.net/~sherman/8042589/webrev/ This is a regression caused by the following change for #JDK-8032012, issue: https://bugs.openjdk.java.net/browse/JDK-8032012 webrev: http://cr.openjdk.java.net/~sherman/8032012/ discussion: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/024862.html It appears the last optimization for the surrogates we pushed in is incomplete. We still need to check isSurrogate() in the optimized non-surrogate loop, as the "first" (checked at the very beginning) might be triggered by a non-surrogate-upper/lowercase char. Thanks! -Sherman From peter.levart at gmail.com Wed Jul 9 22:17:56 2014 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 10 Jul 2014 00:17:56 +0200 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: References: <53B57E16.5020802@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC6506.3060308@oracle.com> <53BC6640.9020508@gmail.com> <53BC6B6F.6000709@oracle.com> <53BC73D7.7020900@gmail.com> <53BC8BF0.7000601@oracle.com> <53BCEDD4.6010906@gmail.com> <53BCF049.8090303@gmail.com> Message-ID: <53BDBF94.7040208@gmail.com> On 07/09/2014 06:36 PM, Martin Buchholz wrote: > OK, I think we're down to the smallest possible bug: I wouldn't call it a bug, since it's not present. > > if size == MAX_CAPACITY - 1 and we putAll a concurrent map with > greater size, but the concurrent map shrinks while we're adding it, > and no actual elements get added to the IHM (but each element put > takes ~ 2**28 probes), then an ISE is thrown when it was not strictly > necessary. We won't be adding any elements if resize() throws "capacity exceeded", so this is just hypothetical thinking what would happen if we didn't call resize() and just started adding elements from the argument map. We might hit the ceiling or we might not. > > Meanwhile, I'm actually wishing we could throw at something like 80% > full... I created a little simulation: public class IMHSimulation { static final int MAXIMUM_CAPACITY = 1 << 29; static final int MASK = MAXIMUM_CAPACITY - 1; static int hash(Object x) { int h = System.identityHashCode(x); // Multiply by -127 to use least bit as part of hash return (h - (h << 7)) & MASK; } static int add(BitSet bs, Object o) { int i = hash(o); int probes = 0; while (bs.get(i)) { i = (i + 1) & MASK; probes++; } bs.set(i); return probes; } public static void main(String[] args) { BitSet bs = new BitSet(MAXIMUM_CAPACITY); long totalProbes = 0; int maxProbes = 0; int percent = 10; int nextReportAt = (int) ((long) percent * MAXIMUM_CAPACITY / 100); for (int i = 0; i < MAXIMUM_CAPACITY; i++) { int probes = add(bs, new Object()); totalProbes += probes; maxProbes = Math.max(maxProbes, probes); if (i == nextReportAt) { System.out.printf( "%3d%% full, avg. %4.1f, max. %6d probes\n", percent, (double) totalProbes / i, maxProbes ); if (percent < 60) percent += 10; else if (percent < 90) percent += 5; else percent++; nextReportAt = (int) ((long) percent * MAXIMUM_CAPACITY / 100); } } } Which produces the following: 10% full, avg. 0.1, max. 9 probes 20% full, avg. 0.1, max. 15 probes 30% full, avg. 0.2, max. 25 probes 40% full, avg. 0.3, max. 38 probes 50% full, avg. 0.5, max. 64 probes 60% full, avg. 0.7, max. 93 probes 65% full, avg. 0.9, max. 147 probes 70% full, avg. 1.2, max. 224 probes 75% full, avg. 1.5, max. 354 probes 80% full, avg. 2.0, max. 441 probes 85% full, avg. 2.8, max. 789 probes 90% full, avg. 4.5, max. 1869 probes 91% full, avg. 5.1, max. 2377 probes 92% full, avg. 5.7, max. 3409 probes 93% full, avg. 6.6, max. 3804 probes 94% full, avg. 7.8, max. 5824 probes 95% full, avg. 9.5, max. 7021 probes 96% full, avg. 12.0, max. 12607 probes 97% full, avg. 16.2, max. 17643 probes 98% full, avg. 24.5, max. 34561 probes 99% full, avg. 49.6, max. 131371 probes IMH resizing is arranged so that the table is always 33% ... 66% full (if nothing is ever removed from it) except when capacity reaches 2**29, then it can be filled up to the top. avg. # of probes can be taken as a rough estimation of average slow-down, max. # of probes can be taken as a rough estimation of worst-case-operation slow-down. So where to draw the line? Regards, Peter > > Relatedly: It occurs to me that it's traditional in java.util to throw > OOME instead of ISE for capacity exceeded. > > > On Wed, Jul 9, 2014 at 12:33 AM, Peter Levart > wrote: > > > On 07/09/2014 09:23 AM, Peter Levart wrote: >> >> On 07/09/2014 02:46 AM, Martin Buchholz wrote: >>> Let me understand - you're worried that when size is >>> MAX_CAPACITY - 1, then a call to putAll that does not actually >>> add any elements might throw? >> >> This is not possible, because resize() is only called from >> putAll(map) if argument map.size() > this.size. At least one >> element will be added to the map and it's correct to throw if >> current size == MAX_CAPACITY - 1. > > ...at least if the argument map obeys the rules of Map contract. > Even if it's a HashMap or another IdentityHashMap, it should not > contain the same INSTANCE of the key in two or more mappings, > should not "overshoot" reporting it's size() and should be stable > during the whole putAll() operation... So calling IHM.addAll() > with a live changing ConcurrentHashMap is not advisable. Even > then, addAll() could only throw, because at some point the > argument's size indicated that IHM could reach it's max. capacity. > > Peter > > >> >>> Well, I'm having a hard time considering that corner case a >>> bug, given how unusable the map is at this point. >> >> It seems even this corner case is not present. >> >>> >>> Your suggested fix of returning immediately in case of no resize >>> would cause put to succeed and reach size == MAX_CAPACITY, which >>> you were trying to prevent. >> >> That's not possible either, since resize() is always called from >> put() with current table.length, which makes newLength == 2 * >> oldLength, therefore (oldLength >= newLength) will never succeed >> in this case. >> >> Peter >> >>> >>> >>> On Tue, Jul 8, 2014 at 5:25 PM, Ivan Gerasimov >>> > >>> wrote: >>> >>> >>> On 09.07.2014 3:20, Martin Buchholz wrote: >>>> I agree with Peter that we do not need to increment >>>> modCount on resize. >>>> >>>> My latest webrev is again "done". >>>> >>>> Ivan, feel free to take over. >>> >>> Yes, thanks! The fix is much much better now. >>> >>> I think I see yet another very minor glitch, though. >>> If the table is already of size 2 * MAXIMUM_CAPACITY, and >>> we're merging in another map, which has more elements with >>> putAll(), resize() will be called and it will throw, even >>> though all the elements could fit into the map due to the >>> key duplicates. >>> >>> To avoid this the following check should be done first in >>> resize(): >>> >>> 469 if (oldLength >= newLength) >>> 470 return false; >>> >>> >>> Sincerely yours, >>> Ivan >>> >>> >> > > From henry.jen at oracle.com Thu Jul 10 00:51:18 2014 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 09 Jul 2014 17:51:18 -0700 Subject: RFR: 8044862: Fix raw and unchecked lint warnings in macosx specific code In-Reply-To: References: <53ADE5FD.20305@oracle.com> <53ADE96B.8070904@oracle.com> <53BCB767.4090107@oracle.com> Message-ID: <53BDE386.7020800@oracle.com> Thanks, Petr. I worked out AquaFileChooserUI and updated the webrev to adapt comments from both you and Joe. The updated webrev is at, http://cr.openjdk.java.net/~henryjen/jdk9/8044862/1/webrev/ Cheers, Henry On 07/09/2014 01:07 AM, Petr Pchelko wrote: > Hello, Henry. > > AquaComboBoxRendererInternal : why and not just ? > > AquaComboBoxUI:427, 510, 530 - you can replace JComboBox with JComboBox and avoid a @SupressWarning annotation. > > AquaFileChooserUI.createDirectoryComboBoxRenderer actually returns a ListCellRenderer, > DirectoryComboBoxModel is a model, and a combobox contains only Files. I suggest to try > to genereficate this correctly and look where it brings us. > > Also I didn't look at the KeychainStore.java as I know nothing about this code. > > With best regards. Petr. > > On 09 ???? 2014 ?., at 7:30, Henry Jen wrote: > >> Hi, >> >> Would someone from swing team care to take a look at this? >> >> The change of src/macosx/classes/sun/font/CFontConfiguration.java will be dropped as it had been fixed in JDK-8048980. >> >> Cheers, >> Henry >> >> >> On 06/27/2014 03:00 PM, Joe Darcy wrote: >>> Hi Henry, >>> >>> Your changes look good to me (I assume there was an issue using >>> wildcards in AquaComboBoxButton.java). >>> >>> Thanks, >>> >>> -Joe >>> >>> On 06/27/2014 02:45 PM, Henry Jen wrote: >>>> Hi, >>>> >>>> Please review a webrev for fixing rawtypes and unchecked lint warning >>>> for macosx specific java code, this webrev is depending on >>>> JDK-8043548[1] where some of the override methods are defined, >>>> >>>> Also as the src/macosx/classes/apple/launcher/JavaAppLauncher.java to >>>> be removed from JDK-8048337, the webrev omits that file. >>>> >>>> The webrev can be found at, >>>> http://cr.openjdk.java.net/~henryjen/jdk9/8044862/0/webrev/ >>>> >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8043548 >>>> >>>> Cheers, >>>> Henry >>> > From petr.pchelko at oracle.com Thu Jul 10 04:13:59 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Thu, 10 Jul 2014 08:13:59 +0400 Subject: RFR: 8044862: Fix raw and unchecked lint warnings in macosx specific code In-Reply-To: <53BDE386.7020800@oracle.com> References: <53ADE5FD.20305@oracle.com> <53ADE96B.8070904@oracle.com> <53BCB767.4090107@oracle.com> <53BDE386.7020800@oracle.com> Message-ID: Hello, Henry. The new version of the fix looks good to me. With best regards. Petr. > On Jul 10, 2014, at 4:51 AM, Henry Jen wrote: > > Thanks, Petr. > > I worked out AquaFileChooserUI and updated the webrev to adapt comments from both you and Joe. > > The updated webrev is at, > http://cr.openjdk.java.net/~henryjen/jdk9/8044862/1/webrev/ > > Cheers, > Henry > > > On 07/09/2014 01:07 AM, Petr Pchelko wrote: >> Hello, Henry. >> >> AquaComboBoxRendererInternal : why and not just ? >> >> AquaComboBoxUI:427, 510, 530 - you can replace JComboBox with JComboBox and avoid a @SupressWarning annotation. >> >> AquaFileChooserUI.createDirectoryComboBoxRenderer actually returns a ListCellRenderer, >> DirectoryComboBoxModel is a model, and a combobox contains only Files. I suggest to try >> to genereficate this correctly and look where it brings us. >> >> Also I didn't look at the KeychainStore.java as I know nothing about this code. >> >> With best regards. Petr. >> >> On 09 ???? 2014 ?., at 7:30, Henry Jen wrote: >> >>> Hi, >>> >>> Would someone from swing team care to take a look at this? >>> >>> The change of src/macosx/classes/sun/font/CFontConfiguration.java will be dropped as it had been fixed in JDK-8048980. >>> >>> Cheers, >>> Henry >>> >>> >>> On 06/27/2014 03:00 PM, Joe Darcy wrote: >>>> Hi Henry, >>>> >>>> Your changes look good to me (I assume there was an issue using >>>> wildcards in AquaComboBoxButton.java). >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> On 06/27/2014 02:45 PM, Henry Jen wrote: >>>>> Hi, >>>>> >>>>> Please review a webrev for fixing rawtypes and unchecked lint warning >>>>> for macosx specific java code, this webrev is depending on >>>>> JDK-8043548[1] where some of the override methods are defined, >>>>> >>>>> Also as the src/macosx/classes/apple/launcher/JavaAppLauncher.java to >>>>> be removed from JDK-8048337, the webrev omits that file. >>>>> >>>>> The webrev can be found at, >>>>> http://cr.openjdk.java.net/~henryjen/jdk9/8044862/0/webrev/ >>>>> >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8043548 >>>>> >>>>> Cheers, >>>>> Henry >>>> >> From joe.darcy at oracle.com Thu Jul 10 04:28:58 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 09 Jul 2014 21:28:58 -0700 Subject: RFR: 8044862: Fix raw and unchecked lint warnings in macosx specific code In-Reply-To: References: <53ADE5FD.20305@oracle.com> <53ADE96B.8070904@oracle.com> <53BCB767.4090107@oracle.com> <53BDE386.7020800@oracle.com> Message-ID: <53BE168A.90302@oracle.com> Looks fine to me too; thanks, -Joe On 07/09/2014 09:13 PM, Petr Pchelko wrote: > Hello, Henry. > > The new version of the fix looks good to me. > > With best regards. Petr. > >> On Jul 10, 2014, at 4:51 AM, Henry Jen wrote: >> >> Thanks, Petr. >> >> I worked out AquaFileChooserUI and updated the webrev to adapt comments from both you and Joe. >> >> The updated webrev is at, >> http://cr.openjdk.java.net/~henryjen/jdk9/8044862/1/webrev/ >> >> Cheers, >> Henry >> >> >> On 07/09/2014 01:07 AM, Petr Pchelko wrote: >>> Hello, Henry. >>> >>> AquaComboBoxRendererInternal : why and not just ? >>> >>> AquaComboBoxUI:427, 510, 530 - you can replace JComboBox with JComboBox and avoid a @SupressWarning annotation. >>> >>> AquaFileChooserUI.createDirectoryComboBoxRenderer actually returns a ListCellRenderer, >>> DirectoryComboBoxModel is a model, and a combobox contains only Files. I suggest to try >>> to genereficate this correctly and look where it brings us. >>> >>> Also I didn't look at the KeychainStore.java as I know nothing about this code. >>> >>> With best regards. Petr. >>> >>> On 09 ???? 2014 ?., at 7:30, Henry Jen wrote: >>> >>>> Hi, >>>> >>>> Would someone from swing team care to take a look at this? >>>> >>>> The change of src/macosx/classes/sun/font/CFontConfiguration.java will be dropped as it had been fixed in JDK-8048980. >>>> >>>> Cheers, >>>> Henry >>>> >>>> >>>> On 06/27/2014 03:00 PM, Joe Darcy wrote: >>>>> Hi Henry, >>>>> >>>>> Your changes look good to me (I assume there was an issue using >>>>> wildcards in AquaComboBoxButton.java). >>>>> >>>>> Thanks, >>>>> >>>>> -Joe >>>>> >>>>> On 06/27/2014 02:45 PM, Henry Jen wrote: >>>>>> Hi, >>>>>> >>>>>> Please review a webrev for fixing rawtypes and unchecked lint warning >>>>>> for macosx specific java code, this webrev is depending on >>>>>> JDK-8043548[1] where some of the override methods are defined, >>>>>> >>>>>> Also as the src/macosx/classes/apple/launcher/JavaAppLauncher.java to >>>>>> be removed from JDK-8048337, the webrev omits that file. >>>>>> >>>>>> The webrev can be found at, >>>>>> http://cr.openjdk.java.net/~henryjen/jdk9/8044862/0/webrev/ >>>>>> >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8043548 >>>>>> >>>>>> Cheers, >>>>>> Henry From peter.firmstone at zeus.net.au Thu Jul 10 08:01:33 2014 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 10 Jul 2014 18:01:33 +1000 Subject: JEP 187 Message-ID: <53BE485D.3070606@zeus.net.au> The attached code shares the same motivations as JEP 187 and may help establish a baseline. One more thing we're looking into (for a later release) is trusted class lists to avoid deserialization attacks. https://issues.apache.org/jira/browse/RIVER-362 http://www.ibm.com/developerworks/java/library/se-lookahead/index.html Regards, Peter. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Portable.java URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: PortableFactory.java URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: PortableObjectInputStream.java URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: PortableObjectOutputStream.java URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: PortablePermission.java URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: PortableObject.java URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: PortableFactoryTest.java URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: PortableObjectOutputStreamTest.java URL: From vladimir.x.ivanov at oracle.com Thu Jul 10 11:57:05 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 10 Jul 2014 15:57:05 +0400 Subject: [9] RFR (M): 8049555: Move varargsArray from sun.invoke.util package to java.lang.invoke Message-ID: <53BE7F91.1010706@oracle.com> http://cr.openjdk.java.net/~vlivanov/8049555/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8049555 Code cleanup: - moved varargsArray(Class,int) & varargsArray(int) from sun.invoke.util.ValueConversions to java.lang.invoke.MethodHandleImpl; - removed unused varargsList(int); - extracted relevant tests from ValueConversionsTest to VarargsArrayTest. Testing: regression tests (jdk/java/lang/invoke, jdk/java/util/streams), nashorn, octane. Thanks! Best regards, Vladimir Ivanov From peter.levart at gmail.com Thu Jul 10 12:49:01 2014 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 10 Jul 2014 14:49:01 +0200 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC5F8F.2060103@gmail.com> Message-ID: <53BE8BBD.7080708@gmail.com> On 07/08/2014 11:30 PM, Martin Buchholz wrote: > Benchmarks welcome. I have run your latest webrev with the following benchamrk: @State(Scope.Thread) public class IHMBench { Map map = new IdentityHashMap(); @Benchmark public void putNewObject(Blackhole bh) { Object o = new Object(); bh.consume(map.put(o, o)); if (map.size() > 100000) { map = new IdentityHashMap(); } } } Using: java -Xmx4G -Xms4G -jar benchmarks.jar -f 0 -i 30 -wi 10 -t 1 -gc 1 ...and results are: Original: Benchmark Mode Samples Score Score error Units j.t.IHMBench.putNewObject thrpt 30 13305370.384 80122.977 ops/s Patched: Benchmark Mode Samples Score Score error Units j.t.IHMBench.putNewObject thrpt 30 13364374.454 124491.206 ops/s Seems performance is the same. Regards, Peter From paul.sandoz at oracle.com Thu Jul 10 14:14:20 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 10 Jul 2014 16:14:20 +0200 Subject: [9] RFR (M): 8049555: Move varargsArray from sun.invoke.util package to java.lang.invoke In-Reply-To: <53BE7F91.1010706@oracle.com> References: <53BE7F91.1010706@oracle.com> Message-ID: <781D8B86-B0CD-4102-B7F8-C3AC252E4BF3@oracle.com> On Jul 10, 2014, at 1:57 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8049555/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8049555 > > Code cleanup: > - moved varargsArray(Class,int) & varargsArray(int) from sun.invoke.util.ValueConversions to java.lang.invoke.MethodHandleImpl; > - removed unused varargsList(int); MethodHandleImpl.convertArrayElements (copied over from sun.invoke.util.ValueConversions) is also not used, do you wanna keep then one? > - extracted relevant tests from ValueConversionsTest to VarargsArrayTest. > That's an interesting trick to get things working on the bootclasspath: 36 * @run main ClassFileInstaller java.lang.invoke.VarargsArrayTest 37 * java.lang.invoke.VarargsArrayTest$1 Where does "java.lang.invoke.VarargsArrayTest$1" comes from? If it does not exist i would presume an NPE would occur causing the test to fail on setup? Paul. > Testing: regression tests (jdk/java/lang/invoke, jdk/java/util/streams), nashorn, octane. > > Thanks! > > Best regards, > Vladimir Ivanov > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From paul.sandoz at oracle.com Thu Jul 10 16:10:11 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 10 Jul 2014 18:10:11 +0200 Subject: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms In-Reply-To: References: <5322EBF2.7030209@oracle.com> <5322F3D7.9010103@oracle.com> <94F61B19-8904-42FA-9E16-CC0A6B30FD79@oracle.com> <53230184.9090007@oracle.com> <2FCC64E3-3753-4CE0-9CC6-849FF737BFB5@oracle.com> <53232FF3.9020803@oracle.com> <53305E52.2060001@oracle.com> <53BBC340.7040509@oracle.com> <7FAEB94F-EB98-49A9-A4B0-9B4A6B730CA9@oracle.com> Message-ID: On Jul 9, 2014, at 8:04 PM, John Rose wrote: > On Jul 9, 2014, at 3:14 AM, Paul Sandoz wrote: > >> >> I quickly verified the fold up does as you expect. Also, if i do the following the null check goes away: >> >> ... >> >> void testLoop() { >> for (int i = 0; i < 1000000; i++) { >> testLoopOne(a); >> testLoopOne(snull); >> } >> } > > Good observation. So rather than missing a null-case fold-up (good it's not!), the optimizer is speculating not-nullness (based on profile) and adding a test. (Either the test is being used for a downstream optimization, or else the test is not being detected as useless and removed?which would be bad!.) > I guess it's the pesky null check in the class cast causing issues: public T cast(Object obj) { if (obj != null && !isInstance(obj)) throw new ClassCastException(cannotCastMsg(obj)); return (T) obj; } >> I am probably obsessing too much over some micro/nano-benchmarks, > > (Hi, I'm John and I'm a micro-obsess-aholic.) > :-) >> but i am wondering if this could cause some unwanted de-opt/recompilation effects when all is good with no null values then suddenly a null triggers de-optimization. > > Besides jumping after the micro-benchmark and chewing on the optimizer until the code shrinks, there are two other things we can do: > > 1. Mentally file the issue and watch real benchmarks for evidence of the problem. (This works pretty well, provided enough time and focus, and provided enough people have some consciousness of the optimizer's workings.) > > 2. Create a self-test and check it into the test base. It could be either a unit test of assertion. In this case, I don't see an easy way to do it, but creating clever permanent tests almost always pays off much better than cleverly pounding on the micro-benchmark of the moment. > How about the a variant of following? public class NullCheckDroppingsTest { volatile String svalue = "A"; volatile String snull = null; String ssink; public static void main(String[] args) { NullCheckDroppingsTest t = new NullCheckDroppingsTest(); t.testLoop(); } void testLoop() { // Ensure testLoopOne is compiled and does not // see a null value for (int i = 0; i < 1000000; i++) { testLoopOne(svalue); // Uncomment the following and the call outside // the loop should not result in any deoptimization // testLoopOne(snull); } // Sleep just to create delay in the compilation log try { Thread.currentThread().sleep(1000); } catch (Exception e) {} // This should cause a de-optimisation // if testLoopOne is compiled with a null-check testLoopOne(snull); } void testLoopOne(String s) { try { ssink = String.class.cast(s); } catch (Throwable t) { throw new Error(t); } } } $ java -XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompilation NullCheckDroppingsTest 64 1 java.lang.String::hashCode (55 bytes) 69 2 java.lang.String::indexOf (70 bytes) 81 3 ! NullCheckDroppingsTest::testLoopOne (27 bytes) 81 5 n java.lang.Class::isInstance (native) 81 4 java.lang.Class::cast (27 bytes) 82 6 % ! NullCheckDroppingsTest::testLoop @ 2 (45 bytes) 85 6 % ! NullCheckDroppingsTest::testLoop @ -2 (45 bytes) made not entrant 1086 3 ! NullCheckDroppingsTest::testLoopOne (27 bytes) made not entrant The log can be searched to see of a deopt ("made not entrant") occurred or not. Paul. From otaviopolianasantana at gmail.com Fri Jul 11 01:36:03 2014 From: otaviopolianasantana at gmail.com (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Thu, 10 Jul 2014 22:36:03 -0300 Subject: RFR: 8049892: Replace uses of 'new Integer()' with appropriate alternative across core classes Message-ID: https://bugs.openjdk.java.net/browse/JDK-8049892 http://cr.openjdk.java.net/~prr/8049892/ -- Cheers!. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: *http://about.me/otaviojava * 55 (11) 98255-3513 From andrej.golovnin at gmail.com Fri Jul 11 06:41:14 2014 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Fri, 11 Jul 2014 08:41:14 +0200 Subject: RFR: 8049892: Replace uses of 'new Integer()' with appropriate alternative across core classes In-Reply-To: References: Message-ID: Hi Ot?vio, changes to the classes in the package "jdk.internal.org.objectweb.asm" should be done directly in the ASM library. Please exclude following classes from the patch: src/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java src/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java src/share/classes/jdk/internal/org/objectweb/asm/commons/GeneratorAdapter.java src/share/classes/jdk/internal/org/objectweb/asm/commons/InstructionAdapter.java src/share/classes/jdk/internal/org/objectweb/asm/tree/LookupSwitchInsnNode.java src/share/classes/jdk/internal/org/objectweb/asm/util/CheckMethodAdapter.java src/share/classes/jdk/internal/org/objectweb/asm/util/Textifier.java And please exclude following classes from the patch too: src/share/classes/sun/reflect/UnsafeIntegerFieldAccessorImpl.java src/share/classes/sun/reflect/UnsafeQualifiedIntegerFieldAccessorImpl.java src/share/classes/sun/reflect/UnsafeQualifiedStaticIntegerFieldAccessorImpl.java src/share/classes/sun/reflect/UnsafeStaticIntegerFieldAccessorImpl.java This classes will be fixed by the patch for the issue 5043030. Otherwise it looks good. Best regards, Andrej Golovnin On Fri, Jul 11, 2014 at 3:36 AM, Ot?vio Gon?alves de Santana < otaviopolianasantana at gmail.com> wrote: > https://bugs.openjdk.java.net/browse/JDK-8049892 > http://cr.openjdk.java.net/~prr/8049892/ > > -- > Cheers!. > > Ot?vio Gon?alves de Santana > > blog: http://otaviosantana.blogspot.com.br/ > twitter: http://twitter.com/otaviojava > site: *http://about.me/otaviojava * > 55 (11) 98255-3513 > From pavel.rappo at oracle.com Fri Jul 11 09:41:59 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 11 Jul 2014 10:41:59 +0100 Subject: RFR: 8049892: Replace uses of 'new Integer()' with appropriate alternative across core classes In-Reply-To: References: Message-ID: <81766990-91E6-49F4-8EF5-37295275BE15@oracle.com> Hi Otavio, Other than things already spotted by Andrej, the change looks good to me. Thank you for doing this. -Pavel On 11 Jul 2014, at 02:36, Ot?vio Gon?alves de Santana wrote: > https://bugs.openjdk.java.net/browse/JDK-8049892 > http://cr.openjdk.java.net/~prr/8049892/ > > -- > Cheers!. > > Ot?vio Gon?alves de Santana > > blog: http://otaviosantana.blogspot.com.br/ > twitter: http://twitter.com/otaviojava > site: *http://about.me/otaviojava * > 55 (11) 98255-3513 From vladimir.x.ivanov at oracle.com Fri Jul 11 10:34:18 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 11 Jul 2014 14:34:18 +0400 Subject: [9] RFR (M): 8049555: Move varargsArray from sun.invoke.util package to java.lang.invoke In-Reply-To: <781D8B86-B0CD-4102-B7F8-C3AC252E4BF3@oracle.com> References: <53BE7F91.1010706@oracle.com> <781D8B86-B0CD-4102-B7F8-C3AC252E4BF3@oracle.com> Message-ID: <53BFBDAA.4070004@oracle.com> >> http://cr.openjdk.java.net/~vlivanov/8049555/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8049555 >> >> Code cleanup: >> - moved varargsArray(Class,int) & varargsArray(int) from sun.invoke.util.ValueConversions to java.lang.invoke.MethodHandleImpl; >> - removed unused varargsList(int); > > MethodHandleImpl.convertArrayElements (copied over from sun.invoke.util.ValueConversions) is also not used, do you wanna keep then one? Good catch I have it removed in the very next patch, but I'll move it here. > >> - extracted relevant tests from ValueConversionsTest to VarargsArrayTest. >> > > That's an interesting trick to get things working on the bootclasspath: > > 36 * @run main ClassFileInstaller java.lang.invoke.VarargsArrayTest > 37 * java.lang.invoke.VarargsArrayTest$1 > > Where does "java.lang.invoke.VarargsArrayTest$1" comes from? If it does not exist i would presume an NPE would occur causing the test to fail on setup? VarargsArrayTest$1 is generated for switch over Wrapper enum in toArrayString. Best regards, Vladimir Ivanov From igor.ignatyev at oracle.com Fri Jul 11 11:56:57 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 11 Jul 2014 15:56:57 +0400 Subject: [9] RFR (M): 8049555: Move varargsArray from sun.invoke.util package to java.lang.invoke In-Reply-To: <53BFBDAA.4070004@oracle.com> References: <53BE7F91.1010706@oracle.com> <781D8B86-B0CD-4102-B7F8-C3AC252E4BF3@oracle.com> <53BFBDAA.4070004@oracle.com> Message-ID: <53BFD109.7080502@oracle.com> Vladimir, instead of the trick w/ 'ClassFileInstaller', you can use 'bootclasspath' option[1] which adds all paths to the bootclasspath: > * @run main/bootclasspath java.lang.invoke.VarargsArrayTest > * @run main/bootclasspath > * -DVarargsArrayTest.MAX_ARITY=255 -DVarargsArrayTest.START_ARITY=250 > * java.lang.invoke.VarargsArrayTest [1] http://hg.openjdk.java.net/code-tools/jtreg/file/jtreg4.1-b07/src/share/classes/com/sun/javatest/regtest/MainAction.java#l131 [2] http://hg.openjdk.java.net/code-tools/jtreg/file/jtreg4.1-b07/src/share/classes/com/sun/javatest/regtest/MainAction.java#l343 Igor On 07/11/2014 02:34 PM, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vlivanov/8049555/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8049555 >>> >>> Code cleanup: >>> - moved varargsArray(Class,int) & varargsArray(int) from >>> sun.invoke.util.ValueConversions to java.lang.invoke.MethodHandleImpl; >>> - removed unused varargsList(int); >> >> MethodHandleImpl.convertArrayElements (copied over from >> sun.invoke.util.ValueConversions) is also not used, do you wanna keep >> then one? > Good catch I have it removed in the very next patch, but I'll move it here. > >> >>> - extracted relevant tests from ValueConversionsTest to >>> VarargsArrayTest. >>> >> >> That's an interesting trick to get things working on the bootclasspath: >> >> 36 * @run main ClassFileInstaller java.lang.invoke.VarargsArrayTest >> 37 * java.lang.invoke.VarargsArrayTest$1 >> >> Where does "java.lang.invoke.VarargsArrayTest$1" comes from? If it >> does not exist i would presume an NPE would occur causing the test to >> fail on setup? > VarargsArrayTest$1 is generated for switch over Wrapper enum in > toArrayString. > > Best regards, > Vladimir Ivanov > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From vladimir.x.ivanov at oracle.com Fri Jul 11 12:21:01 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 11 Jul 2014 16:21:01 +0400 Subject: [9] RFR (M): 8049555: Move varargsArray from sun.invoke.util package to java.lang.invoke In-Reply-To: <53BFD109.7080502@oracle.com> References: <53BE7F91.1010706@oracle.com> <781D8B86-B0CD-4102-B7F8-C3AC252E4BF3@oracle.com> <53BFBDAA.4070004@oracle.com> <53BFD109.7080502@oracle.com> Message-ID: <53BFD6AD.8070305@oracle.com> Igor, thanks for the hint! Updated version: http://cr.openjdk.java.net/~vlivanov/8049555/webrev.01/ Best regards, Vladimir Ivanov On 7/11/14 3:56 PM, Igor Ignatyev wrote: > Vladimir, > > instead of the trick w/ 'ClassFileInstaller', you can use > 'bootclasspath' option[1] which adds all paths to the bootclasspath: > >> * @run main/bootclasspath java.lang.invoke.VarargsArrayTest >> * @run main/bootclasspath >> * -DVarargsArrayTest.MAX_ARITY=255 >> -DVarargsArrayTest.START_ARITY=250 >> * java.lang.invoke.VarargsArrayTest > > [1] > http://hg.openjdk.java.net/code-tools/jtreg/file/jtreg4.1-b07/src/share/classes/com/sun/javatest/regtest/MainAction.java#l131 > > [2] > http://hg.openjdk.java.net/code-tools/jtreg/file/jtreg4.1-b07/src/share/classes/com/sun/javatest/regtest/MainAction.java#l343 > > > > Igor > > On 07/11/2014 02:34 PM, Vladimir Ivanov wrote: >> >> http://cr.openjdk.java.net/~vlivanov/8049555/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8049555 >>>> >>>> Code cleanup: >>>> - moved varargsArray(Class,int) & varargsArray(int) from >>>> sun.invoke.util.ValueConversions to java.lang.invoke.MethodHandleImpl; >>>> - removed unused varargsList(int); >>> >>> MethodHandleImpl.convertArrayElements (copied over from >>> sun.invoke.util.ValueConversions) is also not used, do you wanna keep >>> then one? >> Good catch I have it removed in the very next patch, but I'll move it >> here. >> >>> >>>> - extracted relevant tests from ValueConversionsTest to >>>> VarargsArrayTest. >>>> >>> >>> That's an interesting trick to get things working on the bootclasspath: >>> >>> 36 * @run main ClassFileInstaller java.lang.invoke.VarargsArrayTest >>> 37 * >>> java.lang.invoke.VarargsArrayTest$1 >>> >>> Where does "java.lang.invoke.VarargsArrayTest$1" comes from? If it >>> does not exist i would presume an NPE would occur causing the test to >>> fail on setup? >> VarargsArrayTest$1 is generated for switch over Wrapper enum in >> toArrayString. >> >> Best regards, >> Vladimir Ivanov >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From paul.sandoz at oracle.com Fri Jul 11 12:24:53 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 11 Jul 2014 14:24:53 +0200 Subject: [9] RFR (M): 8049555: Move varargsArray from sun.invoke.util package to java.lang.invoke In-Reply-To: <53BFD6AD.8070305@oracle.com> References: <53BE7F91.1010706@oracle.com> <781D8B86-B0CD-4102-B7F8-C3AC252E4BF3@oracle.com> <53BFBDAA.4070004@oracle.com> <53BFD109.7080502@oracle.com> <53BFD6AD.8070305@oracle.com> Message-ID: <8D8621AE-3E36-430F-BD61-C1DD27FE9ABA@oracle.com> On Jul 11, 2014, at 2:21 PM, Vladimir Ivanov wrote: > Igor, thanks for the hint! Yes, much better. > Updated version: > http://cr.openjdk.java.net/~vlivanov/8049555/webrev.01/ > +1 Paul. From pavel.rappo at oracle.com Fri Jul 11 13:59:40 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 11 Jul 2014 14:59:40 +0100 Subject: RFR JDK-8049884: Reduce possible timing noise in com/sun/jndi/ldap/LdapTimeoutTest.java In-Reply-To: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> Message-ID: <5E28614E-CBB2-4C43-BF31-24EFD337A20B@oracle.com> Hi everyone, Could you please review my change for JDK-8049884? http://cr.openjdk.java.net/~prappo/8049884/webrev.00/ Thanks -Pavel From vincent.x.ryan at oracle.com Fri Jul 11 14:13:22 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 11 Jul 2014 15:13:22 +0100 Subject: RFR JDK-8049884: Reduce possible timing noise in com/sun/jndi/ldap/LdapTimeoutTest.java In-Reply-To: <5E28614E-CBB2-4C43-BF31-24EFD337A20B@oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> <5E28614E-CBB2-4C43-BF31-24EFD337A20B@oracle.com> Message-ID: <3148CD00-A58A-4ECB-9150-499783622D47@oracle.com> This change looks fine Pavel and eliminates another intermittent test failure. Thanks. On 11 Jul 2014, at 14:59, Pavel Rappo wrote: > Hi everyone, > > Could you please review my change for JDK-8049884? > > http://cr.openjdk.java.net/~prappo/8049884/webrev.00/ > > Thanks > -Pavel From peter.levart at gmail.com Fri Jul 11 15:11:15 2014 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 11 Jul 2014 17:11:15 +0200 Subject: URL constructor/equals/hashCode/sameFile/openConnection synchronization issues Message-ID: <53BFFE93.9010103@gmail.com> Hi, java.net.URL is supposed to behave as an immutable object, so URL instances can be shared among threads and among parts of code without fear that they will be modified. URL class has an unusual way to achieve this (or at least it tries to). Partly because of the design which uses: - URL constructor(s) that take a 'spec' String to be parsed into URL object - parsing is delegated to various URLStreamHandler(s) which are chosen in the URL constructor (depending on the protocol used in URL string to be parsed) An unitialized URL instance (this) is passed from constructor to the chosen URLStreamHandler which has the responsibility to parse the string and set back the fields that hold various parts of URL object being constructed. Consequently, these fields can not be declared as final, as definite assignment analysis doesn't cross method borders. It is therefore illegal to unsafely publish URL instances (via data races) to non-constructing threads because they can appear not fully initialized. Nevertheless URL, with the help of various URLStreamHandler implementations, tries hard to make URL appear stable at least where it is required to be stable. For example: URL.hashCode() is (almost) stable even if URL instance is unsafely published. This is achieved by making hashCode() synchronized and cache the result. At least one way of constructing URLs - constructors that take 'spec' String to be parsed - is also making sure that hashCode is computed from fully initialized fields, as parsing is delegated to URLStreamHandler which uses package-private URL.set() method to set back the parsed fields and the set() method is also synchronized. But making URL appear stable even though it is published unsafely doesn't seem to be the primary concern of URL synchronization. Other public URL constructors that take individual URL parts and don't delegate parsing to URLStreamHandler but set fields directly (not via set() method), are not synchronized. Primary concern of synchronization in URL appears to be driven from the fact that some URL operations like hasCode(), equals(), sameFile() and openConnection() read multiple URL fields and URL.set() which can be called from custom URLStreamHandler at any time (although this is not it's purpose - it should only call-back while parsing/constructing the URL) can set those fields. And those multi-field operations would like to see a "snapshot" of field values that is consistent. But synchronization that is performed to achieve that is questionable. Might be that in Java 1.0 times the JVM implementation assumptions were different and synchronization was correct, but nowadays Java memory model makes them invalid. URL.hasCode() apears to be the only method properly synchronized which makes it almost stable (doesn't return different results over time) but even hashCode() has a subtle bug or two. The initializer for hashCode field sets it to value -1 which represents "not yet computed" state. If URL is published unsafely, hashCode() method could see the "default" value of 0, which would be returned. A later call to hashCode() would see value -1 which would trigger computation and a different value would be returned. The other subtle bug is a relatively improbable event that hashCode computation results in value -1 which means "not yet computed". This can be seen as performance glitch (as hashCode will never be cached for such URL instance) or an issue which makes hashCode unstable for one of the reasons why equals() is unstable too (see below). If URL.hasCode() method is almost stable (doesn't return different results over time) and at least one way of URL construction makes sure that hashCode is also calculated from fully initialized parts, then URL.equals() and other methods that delegate to URLStreamHandler are a special story. URL.equals() can't be synchronized on URL instance, because it would have to be synchronized on both URL instances that are being compared and this is prone do dead-locks. Imagine: thread1: url1.equals(url2) thread2: url2.equals(url1) So equals() chooses to not be synchronized and therefore risks not being stable if URL instances are published unsafely. But it nevertheless uses synchronization. equals() delegates it's work to the 1st URL's URLStreamHandler which synchronizes on itself when calculating and caching the InetAddress of each individual URL's host name. InetAddress (if resolvable) is used in preference to host name for comparison (and also in hashCode()). URL.equals() risks not being stable for the following reasons: - URL instances published unsafely can appear not fully initialized to equals() even though they were constructed with constructors that delegate parsing to URLStreamHandler(s) which use synchronized URL.set() to set the fields, because URL.equals() is not synchronized. - URL.hostAddress that is calculated on demand and then cached on the URL instance should help make equals() stable in the presence of dynamic changes to host name -> IP address mapping, but caching is not performed for unsuccessful resolving. Temporary name service outage can make URL.equals() unstable. - URL.hostAddress caching is using the URLStreamHandler instance of the 1st URL as a lock for synchronizing read/write of hostAddress of both URLs being compared by equals(). But URLStreamHandler(s) of the two URL instances need not be the same instance even though they are for the same protocol. Imagine: URL url1 = new URL(null, "http://www.google.com/", handler1); URL url2 = new URL(null, "http://www.google.com/", handler2); ... thread1: url1.equals(url2); thread2: url2.equals(url1); Each thread could be using different instance of URLStreamHandler for synchronization and could overwrite each other the cached hostAddress on individual URLs. These hostAddress values could be different in the presence of dynamic changes to host name -> IP address mapping and could therefore make URL.equals() unstable. This is admittedly a very unlikely scenario, but is theoretically possible. URL.sameHost() has exactly the same issues as URL.equals() as it only makes one field comparison less. URL.openConnection() is a question in itself. It is delegated to URLStreamHandler. Some URLStreamHandlers make it synchronized and others not. Those that make it synchronized (on the URLStreamHandler instance) do this for no apparent reason. This synchronization can't help make URL fields stable for the time of openConnection() call since URL.set() is using a different lock (the URL instance itself). It only makes things worse since access to opening the connection to the resources is serialized and this presents a bottleneck. I tried to fix all these issues and came up with the following patch which I'm proposing: http://cr.openjdk.java.net/~plevart/jdk9-dev/URL.synchronization/webrev.01/ New JDK8 synchronization primitive: StampedLock is a perfect tool for solving these issues as synchronization in URL is only necessary to establish visibility of initialized state which doesn't change afterwards or changes at most once (when computing hashCode). StampedLock's tryOptimisticRead/validate is perfect for such situations as it only presents a negligible overhead of two volatile reads. The presented patch also contains an unrelated change which replaces usage of Hashtable with ConcurrentHashMap for holding the mapping from protocol to individual URLStreamhandler which makes for better scallability of URL constructors. Combined with synchronization scallability enhancements of InetAddress caching presented in an earlier proposal, the net result is much better scalability of URL constructor/equals/hashCode (executed by a JMH test on a 4-core i7/Linux box): http://cr.openjdk.java.net/~plevart/jdk9-dev/URL.synchronization/URL.synchronization_bench_results.pdf So with this patch java.net.URL could be treated as an unsafe-publication-tolerable class (like String). Well, not entirely, since getters for individual fields are still just unguarded normal reads. But those reads are usually performed under guard of a StampedLock when URL equals/hashCode/sameFile/openConnection/toExternalForm() operations are delegated to URLStreamHandler and therefore don't suffer from (in)visibility of published state. Fields could be made volatile to fix this if desired. I'm not entirely sure about why openConnection() in file: and mailto: URLStreamHandlers is synchronized. I don't see a reason, so I removed the synchronization. If there is a reason, please bring it forward. I ran the java/net jtreg tests with unpatched recent jdk9-dev and patched (combined changes of URL and InetAddress caching) and get the same score. Only the following 3 tests fail in both ocasions: JT Harness : Tests that failed java/net/MulticastSocket/Promiscuous.java: Test for interference when two sockets are bound to the same port but joined to different multicast groups java/net/MulticastSocket/SetLoopbackMode.java: Test MulticastSocket.setLoopbackMode java/net/MulticastSocket/Test.java: IPv4 and IPv6 multicasting broken on Linux They seem to not like my multicast configuration or something. All other 258 tests pass. So what do you think? Regards, Peter From vladimir.x.ivanov at oracle.com Fri Jul 11 16:18:42 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 11 Jul 2014 20:18:42 +0400 Subject: [9] RFR (M): 8050052: Small cleanups in java.lang.invoke code Message-ID: <53C00E62.20703@oracle.com> http://cr.openjdk.java.net/~vlivanov/8050052/webrev.00 https://bugs.openjdk.java.net/browse/JDK-8050052 Numerous small code cleanups in java.lang.invoke package. Testing: jtreg, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}. Reviewed-by: vlivanov, ? Contributed-by: john.r.rose at oracle.com Thanks! Best regards, Vladimir Ivanov From forax at univ-mlv.fr Fri Jul 11 16:30:32 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 11 Jul 2014 18:30:32 +0200 Subject: Character, Byte, Short valueOf instead of new instance In-Reply-To: References: <5D52EF6A-759F-489D-B419-4C97F3070905@oracle.com> <53B3362B.3000802@univ-mlv.fr> Message-ID: <53C01128.9010602@univ-mlv.fr> On 07/02/2014 01:07 AM, Ot?vio Gon?alves de Santana wrote: > Thank you Remi. > The long[1] also was included? > [1]https://bugs.openjdk.java.net/browse/JDK-8048267 yes, I've included all the patches (I hope) http://websvn.ow2.org/revision.php?repname=asm&path=%2Ftrunk%2F&rev=1759 There were just one place were we have though that it was better to use new Integer() instead of Integer.valueOf for debugging (the identity is guaranteed to be different from an Integer that comes from user code). Thanks again for the patches :) regards, R?mi > > > On Tue, Jul 1, 2014 at 7:28 PM, Remi Forax > wrote: > > > On 07/01/2014 11:01 PM, Andrej Golovnin wrote: > > Hi Pavel, > > Thanks a lot! I've separated out all the changes from the > 'jdk.internal.org.objectweb.asm' package. So I'll update > both threads with new webrevs. > > http://cr.openjdk.java.net/~prappo/8048874/webrev.02 > > > Looks good to me. > > @Ot?vio: Could you please submit the ASM related changes to > the ASM project [1]? Thanks! > > Best regards, > Andrej Golovnin > > [1] http://asm.ow2.org/ > > > Paul Sandoz had already sent the changes related to ASM. > I'm currently reviewing them. > > R?mi > > > > > -- > Atenciosamente. > > Ot?vio Gon?alves de Santana > > blog: http://otaviosantana.blogspot.com.br/ > twitter: http://twitter.com/otaviojava > site: http://www.otaviojava.com.br > (11) 98255-3513 > From vladimir.x.ivanov at oracle.com Fri Jul 11 16:35:30 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 11 Jul 2014 20:35:30 +0400 Subject: [9] RFR (M): 8050053: Improve caching of different invokers Message-ID: <53C01252.4070302@oracle.com> http://cr.openjdk.java.net/~vlivanov/8050053/webrev.00 https://bugs.openjdk.java.net/browse/JDK-8050053 Improve sharing of different invokers: basic, generic & exact invokers, uninitialized call site invoker and NamedFunction invoker are changed. Testing: jdk/java/lang/invoke, nashorn, octane w/ "-ea -esa". Reviewed-by: vlivanov, ? Contributed-by: john.r.rose at oracle.com Thanks! Best regards, Vladimir Ivanov From forax at univ-mlv.fr Fri Jul 11 17:56:04 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 11 Jul 2014 19:56:04 +0200 Subject: [9] RFR (M): 8050052: Small cleanups in java.lang.invoke code In-Reply-To: <53C00E62.20703@oracle.com> References: <53C00E62.20703@oracle.com> Message-ID: <53C02534.2040000@univ-mlv.fr> On 07/11/2014 06:18 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8050052/webrev.00 > https://bugs.openjdk.java.net/browse/JDK-8050052 I've found myself writing the very same code as MethodHandleStatics.uncaughException several times and I wonder if it should not be an instance method of Throwable. Something like: public E rethrow(Function uncaughtHandler) { if (this instanceof RuntimeException) { throw (RuntimeException)this; } if (this instanceof Error) { throw (Error)this; } return uncaughtHandler.apply(this); } in that case, throw uncaughtException(ex) can be replaced by throw ex.rethrow(::newInternalError); cheers, R?mi > > Numerous small code cleanups in java.lang.invoke package. > > Testing: jtreg, nashorn, octane w/ "-ea -esa" and > COMPILE_THRESHOLD={0,30}. > > Reviewed-by: vlivanov, ? > Contributed-by: john.r.rose at oracle.com > > Thanks! > > Best regards, > Vladimir Ivanov > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From paul.sandoz at oracle.com Fri Jul 11 18:16:27 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 11 Jul 2014 20:16:27 +0200 Subject: [9] RFR (M): 8050052: Small cleanups in java.lang.invoke code In-Reply-To: <53C02534.2040000@univ-mlv.fr> References: <53C00E62.20703@oracle.com> <53C02534.2040000@univ-mlv.fr> Message-ID: <86E04807-508F-4543-971A-5BD29187059C@oracle.com> On Jul 11, 2014, at 7:56 PM, Remi Forax wrote: > On 07/11/2014 06:18 PM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8050052/webrev.00 >> https://bugs.openjdk.java.net/browse/JDK-8050052 > > I've found myself writing the very same code as MethodHandleStatics.uncaughException several times > and I wonder if it should not be an instance method of Throwable. > Something like: > > public E rethrow(Function uncaughtHandler) { > if (this instanceof RuntimeException) { > throw (RuntimeException)this; > } > if (this instanceof Error) { > throw (Error)this; > } > return uncaughtHandler.apply(this); > } > > in that case, throw uncaughtException(ex) can be replaced by throw ex.rethrow(::newInternalError); > I suspect there could be a risk of some bootstrap/initialization issues using a method ref in such code. Paul. From forax at univ-mlv.fr Fri Jul 11 18:53:23 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 11 Jul 2014 20:53:23 +0200 Subject: [9] RFR (M): 8050052: Small cleanups in java.lang.invoke code In-Reply-To: <86E04807-508F-4543-971A-5BD29187059C@oracle.com> References: <53C00E62.20703@oracle.com> <53C02534.2040000@univ-mlv.fr> <86E04807-508F-4543-971A-5BD29187059C@oracle.com> Message-ID: <53C032A3.1000207@univ-mlv.fr> On 07/11/2014 08:16 PM, Paul Sandoz wrote: > On Jul 11, 2014, at 7:56 PM, Remi Forax wrote: >> On 07/11/2014 06:18 PM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8050052/webrev.00 >>> https://bugs.openjdk.java.net/browse/JDK-8050052 >> I've found myself writing the very same code as MethodHandleStatics.uncaughException several times >> and I wonder if it should not be an instance method of Throwable. >> Something like: >> >> public E rethrow(Function uncaughtHandler) { >> if (this instanceof RuntimeException) { >> throw (RuntimeException)this; >> } >> if (this instanceof Error) { >> throw (Error)this; >> } >> return uncaughtHandler.apply(this); >> } >> >> in that case, throw uncaughtException(ex) can be replaced by throw ex.rethrow(::newInternalError); >> > I suspect there could be a risk of some bootstrap/initialization issues using a method ref in such code. > > Paul. yes, right, using invokedynamic in java.lang.invoke is not a good idea. R?mi From martinrb at google.com Fri Jul 11 19:00:24 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 11 Jul 2014 12:00:24 -0700 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53BDBF94.7040208@gmail.com> References: <53B57E16.5020802@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC6506.3060308@oracle.com> <53BC6640.9020508@gmail.com> <53BC6B6F.6000709@oracle.com> <53BC73D7.7020900@gmail.com> <53BC8BF0.7000601@oracle.com> <53BCEDD4.6010906@gmail.com> <53BCF049.8090303@gmail.com> <53BDBF94.7040208@gmail.com> Message-ID: On Wed, Jul 9, 2014 at 3:17 PM, Peter Levart wrote: > > IMH resizing is arranged so that the table is always 33% ... 66% full (if > nothing is ever removed from it) except when capacity reaches 2**29, then > it can be filled up to the top. > > avg. # of probes can be taken as a rough estimation of average slow-down, > max. # of probes can be taken as a rough estimation of worst-case-operation > slow-down. > > So where to draw the line? > Linear probing has long been known to be prone to long worst-case probes, but with recent computer architectures this is offset by its extreme cache friendliness. I support a line-drawing more reasonable than the current MAX_CAPACITY - 1, but we can leave that to another change, since it seems controversial. From martinrb at google.com Fri Jul 11 19:07:36 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 11 Jul 2014 12:07:36 -0700 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53BC90FC.7090300@oracle.com> References: <53B57E16.5020802@oracle.com> <1404414424.14127.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B5B11B.9030602@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC6506.3060308@oracle.com> <53BC6640.9020508@gmail.com> <53BC6B6F.6000709@oracle.com> <53BC73D7.7020900@gmail.com> <53BC8BF0.7000601@oracle.com> <53BC90FC.7090300@oracle.com> Message-ID: Ivan, feel free to submit your latest webrev. We have consensus that changes being made are progress. On Tue, Jul 8, 2014 at 5:46 PM, Ivan Gerasimov wrote: > Here's the same final webrev by Martin. > I only shortened the comment before capacity() and moved the check in > resize() upper. > > http://cr.openjdk.java.net/~igerasim/6904367/4/webrev/ > > Sincerely yours, > Ivan > > > On 09.07.2014 4:25, Ivan Gerasimov wrote: > >> >> On 09.07.2014 3:20, Martin Buchholz wrote: >> >>> I agree with Peter that we do not need to increment modCount on resize. >>> >>> My latest webrev is again "done". >>> >>> Ivan, feel free to take over. >>> >> >> Yes, thanks! The fix is much much better now. >> >> I think I see yet another very minor glitch, though. >> If the table is already of size 2 * MAXIMUM_CAPACITY, and we're merging >> in another map, which has more elements with putAll(), resize() will be >> called and it will throw, even though all the elements could fit into the >> map due to the key duplicates. >> >> To avoid this the following check should be done first in resize(): >> >> 469 if (oldLength >= newLength) >> 470 return false; >> >> >> Sincerely yours, >> Ivan >> >> >> > From dl at cs.oswego.edu Fri Jul 11 19:08:53 2014 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 11 Jul 2014 15:08:53 -0400 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: References: <53B57E16.5020802@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC6506.3060308@oracle.com> <53BC6640.9020508@gmail.com> <53BC6B6F.6000709@oracle.com> <53BC73D7.7020900@gmail.com> <53BC8BF0.7000601@oracle.com> <53BCEDD4.6010906@gmail.com> <53BCF049.8090303@gmail.com> <53BDBF94.7040208@gmail.com> Message-ID: <53C03645.6090900@cs.oswego.edu> I've been content to just observe Martin and Peter's nice efforts on this, but one note: On 07/11/2014 03:00 PM, Martin Buchholz wrote: > On Wed, Jul 9, 2014 at 3:17 PM, Peter Levart wrote: > >> >> IMH resizing is arranged so that the table is always 33% ... 66% full (if >> nothing is ever removed from it) except when capacity reaches 2**29, then >> it can be filled up to the top. >> >> avg. # of probes can be taken as a rough estimation of average slow-down, >> max. # of probes can be taken as a rough estimation of worst-case-operation >> slow-down. >> >> So where to draw the line? >> > > Linear probing has long been known to be prone to long worst-case probes, > but with recent computer architectures this is offset by its extreme cache > friendliness. Bear in mind that the number of bits of identityHashCode is less than 32 on all JVMs I know. It can be as low as 23, which means that you are sure to see a lot of exact collisions on IHMs with only tens of millions of elements, and there's nothing much you can do that will help. -Doug From ivan.gerasimov at oracle.com Fri Jul 11 19:27:27 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 11 Jul 2014 23:27:27 +0400 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: References: <53B57E16.5020802@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC6506.3060308@oracle.com> <53BC6640.9020508@gmail.com> <53BC6B6F.6000709@oracle.com> <53BC73D7.7020900@gmail.com> <53BC8BF0.7000601@oracle.com> <53BC90FC.7090300@oracle.com> Message-ID: <53C03A9F.8080409@oracle.com> On 11.07.2014 23:07, Martin Buchholz wrote: > Ivan, feel free to submit your latest webrev. We have consensus that > changes being made are progress. > > Yes, I was going to do that during the weekend after control rebuild. What is the right way to form the commit message here? Would it be ok if the same person is in both Reviewed-by and Contributed-by lines? Reviewed-by: plevart, martin Contributed-by: igerasim, martin I didn't find Jeff Hain on the census page, so I could not specify him as a reviewer. Sincerely yours, Ivan > On Tue, Jul 8, 2014 at 5:46 PM, Ivan Gerasimov > > wrote: > > Here's the same final webrev by Martin. > I only shortened the comment before capacity() and moved the check > in resize() upper. > > http://cr.openjdk.java.net/~igerasim/6904367/4/webrev/ > > > Sincerely yours, > Ivan > > > On 09.07.2014 4:25, Ivan Gerasimov wrote: > > > On 09.07.2014 3:20, Martin Buchholz wrote: > > I agree with Peter that we do not need to increment > modCount on resize. > > My latest webrev is again "done". > > Ivan, feel free to take over. > > > Yes, thanks! The fix is much much better now. > > I think I see yet another very minor glitch, though. > If the table is already of size 2 * MAXIMUM_CAPACITY, and > we're merging in another map, which has more elements with > putAll(), resize() will be called and it will throw, even > though all the elements could fit into the map due to the key > duplicates. > > To avoid this the following check should be done first in > resize(): > > 469 if (oldLength >= newLength) > 470 return false; > > > Sincerely yours, > Ivan > > > > From martinrb at google.com Fri Jul 11 19:32:30 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 11 Jul 2014 12:32:30 -0700 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53C03A9F.8080409@oracle.com> References: <53B57E16.5020802@oracle.com> <53B62A1C.2040605@oracle.com> <53B6E585.1090303@oracle.com> <53B702BA.9030801@cs.oswego.edu> <53B8C782.1060009@oracle.com> <1404645206.60152.YahooMailNeo@web172404.mail.ir2.yahoo.com> <53B9677B.6060806@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC6506.3060308@oracle.com> <53BC6640.9020508@gmail.com> <53BC6B6F.6000709@oracle.com> <53BC73D7.7020900@gmail.com> <53BC8BF0.7000601@oracle.com> <53BC90FC.7090300@oracle.com> <53C03A9F.8080409@oracle.com> Message-ID: I don't care how you split up attributions. Just put those of us who have openjdk user names in the reviewed-by. Contributed-by is generally for those who don't have an openjdk user name. On Fri, Jul 11, 2014 at 12:27 PM, Ivan Gerasimov wrote: > > On 11.07.2014 23:07, Martin Buchholz wrote: > > Ivan, feel free to submit your latest webrev. We have consensus that > changes being made are progress. > > > Yes, I was going to do that during the weekend after control rebuild. > > What is the right way to form the commit message here? > Would it be ok if the same person is in both Reviewed-by and > Contributed-by lines? > > Reviewed-by: plevart, martin > Contributed-by: igerasim, martin > > I didn't find Jeff Hain on the census page, so I could not specify him as > a reviewer. > > Sincerely yours, > Ivan > > > On Tue, Jul 8, 2014 at 5:46 PM, Ivan Gerasimov > wrote: > >> Here's the same final webrev by Martin. >> I only shortened the comment before capacity() and moved the check in >> resize() upper. >> >> http://cr.openjdk.java.net/~igerasim/6904367/4/webrev/ >> >> Sincerely yours, >> Ivan >> >> >> On 09.07.2014 4:25, Ivan Gerasimov wrote: >> >>> >>> On 09.07.2014 3:20, Martin Buchholz wrote: >>> >>>> I agree with Peter that we do not need to increment modCount on resize. >>>> >>>> My latest webrev is again "done". >>>> >>>> Ivan, feel free to take over. >>>> >>> >>> Yes, thanks! The fix is much much better now. >>> >>> I think I see yet another very minor glitch, though. >>> If the table is already of size 2 * MAXIMUM_CAPACITY, and we're merging >>> in another map, which has more elements with putAll(), resize() will be >>> called and it will throw, even though all the elements could fit into the >>> map due to the key duplicates. >>> >>> To avoid this the following check should be done first in resize(): >>> >>> 469 if (oldLength >= newLength) >>> 470 return false; >>> >>> >>> Sincerely yours, >>> Ivan >>> >>> >>> >> > > From joe.darcy at oracle.com Fri Jul 11 20:01:09 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 11 Jul 2014 13:01:09 -0700 Subject: JDK 9 RFR of 8050051: Remove unneeded/obsolete -source/-target options in shell tests Message-ID: <53C04285.8050501@oracle.com> Hello, The purge of old -source and -target values in the JDK regression tests missed a few items. Please review the patch below which fixes two of them. Thanks, -Joe diff -r d5404a4e4fac test/java/lang/Class/forName/NonJavaNames.sh --- a/test/java/lang/Class/forName/NonJavaNames.sh Fri Jul 11 14:53:55 2014 +0100 +++ b/test/java/lang/Class/forName/NonJavaNames.sh Fri Jul 11 12:58:18 2014 -0700 @@ -25,19 +25,17 @@ # @bug 4952558 # @summary Verify names that aren't legal Java names are accepted by forName. # @author Joseph D. Darcy -# @compile -source 1.5 -target 1.5 NonJavaNames.java +# @compile NonJavaNames.java # @run shell NonJavaNames.sh # This test uses hand-generated class files stored in the ./classes # directory. After the renaming done below, those class files have -# single character names that are legal class names under class file -# version 49 but *not* legal Java language identifiers; e.g. "3" and -# "+". First, Z.java is compiled to Z.class using "-target 1.5." -# Next, to create a test class file, the appropriate name structures -# within the class files are updated, as is the "Hello world" string -# the class's main method prints out. If the definition of the -# semantics of "-target 1.5" changes, the test class files should be -# regenerated. +# single character names that are legal class names under in the class +# file but *not* legal Java language identifiers; e.g. "3" and "+". +# First, Z.java is compiled to Z.class. Next, to create a test class +# file, the appropriate name structures within the class files are +# updated, as is the "Hello world" string the class's main method +# prints out. # Verify directory context variables are set if [ "${TESTJAVA}" = "" ] diff -r d5404a4e4fac test/tools/pack200/PackageVersionTest.java --- a/test/tools/pack200/PackageVersionTest.java Fri Jul 11 14:53:55 2014 +0100 +++ b/test/tools/pack200/PackageVersionTest.java Fri Jul 11 12:58:18 2014 -0700 @@ -59,13 +59,10 @@ } File out = new File("test.pack"); - createClassFile("Test5"); createClassFile("Test6"); createClassFile("Test7"); verify6991164(); - verifyPack("Test5.class", JAVA5_PACKAGE_MAJOR_VERSION, - JAVA5_PACKAGE_MINOR_VERSION); verifyPack("Test6.class", JAVA6_PACKAGE_MAJOR_VERSION, JAVA6_PACKAGE_MINOR_VERSION); @@ -98,7 +95,7 @@ String target = name.substring(name.length() - 1); String javacCmds[] = { "-source", - "5", + "6", "-target", name.substring(name.length() - 1), name + ".java" From Alan.Bateman at oracle.com Fri Jul 11 20:48:53 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 11 Jul 2014 21:48:53 +0100 Subject: JDK 9 RFR of 8050051: Remove unneeded/obsolete -source/-target options in shell tests In-Reply-To: <53C04285.8050501@oracle.com> References: <53C04285.8050501@oracle.com> Message-ID: <53C04DB5.5030908@oracle.com> On 11/07/2014 21:01, Joe Darcy wrote: > Hello, > > The purge of old -source and -target values in the JDK regression > tests missed a few items. Please review the patch below which fixes > two of them. > > Thanks, > > -Joe > This seems fine. -Alan From mike.duigou at oracle.com Fri Jul 11 22:55:56 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 11 Jul 2014 15:55:56 -0700 Subject: RFR [9] 8041972: Add improved parse/format methods for Long/Integer In-Reply-To: <53ADBFE3.50702@oracle.com> References: <539CCE6D.6040207@oracle.com> <539D8821.3070808@univ-mlv.fr> <539D91A0.9050901@oracle.com> <539E1CB4.2050502@oracle.com> <539F4A6A.5020002@oracle.com> <539F4FCE.9080903@oracle.com> <53A04EE7.6090309@oracle.com> <53A06224.1040600@oracle.com> <53A32043.7070008@oracle.com> <39373F79-DC28-4A51-B617-680C6C508538@oracle.com> <53AC5007.30603@oracle.com> <167AB3E2-253B-41B5-B8DF-B6C7C7F7C16B@oracle.com> <53ADBFE3.50702@oracle.com> Message-ID: Some comments: - The NumberFormatException.forInputString for some CharSequence is probably misleading since it doesn't consider the begin-end range which was in effect for the parsing. Rather than extracting the substring just for the error message perhaps include the index at which the error occurred. ie. add a NumberFormatException.forCharSequence(s, idx) static method - Long.java: Why not throw new NumberFormatException("Empty input") or call throw NumberFormatException.forInputString(""); - declaration of and assignment to multmin could be combined. declaration of "result" could also be moved later. - Since it's not part of the public API I recommend moving the System/JavaLangAccess changes to a separate RFE. (and it needs a test). On Jun 27 2014, at 12:02 , Claes Redestad wrote: > Hi, > > updated webrev:http://cr.openjdk.java.net/~redestad/8041972/webrev.11 > > Changes: > - Remove use of IllegalArgumentException in favor of IndexOutOfBoundsException/NumberFormatException, making the new methods behave in line with how String.substring wouldat some edge cases: "100".substring(3)equals "", thus Integer.parseInt("100", 10, 3) now throw NumberFormatException, while Integer.parseInt("100", 10, 4)/"100".substring(4) will throw IOOB. > - For performance reasons the old and new methodshave been split apart. This introduces some code duplication, but removes the need to add special checks in some places. > - Added more tests > > /Claes > > On 06/27/2014 10:54 AM, Paul Sandoz wrote: >> On Jun 26, 2014, at 6:53 PM, Claes Redestad wrote: >> >>> On 06/25/2014 06:43 PM, Paul Sandoz wrote: >>>> On Jun 19, 2014, at 7:39 PM, Claes Redestad wrote: >>>>> Hi, >>>>> >>>>> an updated webrev with reworked, public methods is available here: >>>>> http://cr.openjdk.java.net/~redestad/8041972/webrev.8/ >>>>> >>>>> Reviews are yet again appreciated! >>>>> >>>> I think "if (s == null)" or "Objects.requireNonNull(s)" is preferable to s.getClass(). (I am informed by those more knowledgeable than i that the latter also has poorer performance in the client compiler.) >>> Agreed. Using s.getClass() was necessitated to retain performance using default compiler (-XX:+TieredCompilation) in the microbenchmarks I've been using, and going back to testing with C1 (via means of -XX:TieredStartAtLevel=1-3), it's apparent that the patch can cause a regression with the client compiler that I hadn't checked.It even looks like C2 alone (-XX:-TieredCompilation) suffers slightly. >>> >>> Changing to Objects.requireNonNull doesn't seem to make things better, though. Rather the regression seem to be due to C1 (and in some ways even C2) not dealing very well with the increased degrees of freedoms in the new methods, so I'm currently considering splitting apart the implementations to keep the old implementations of parseX(String[, int]) untouched while duplicating some code to build the new methods. Ugly, but I guess it's anecessary evil here. >>> >> Ok. Perhaps it might be possible to place the specifics of constraint checking in public methods, but they defer to a general private method that can assume it's arguments are safe (or such arguments are checked by other method calls e.g. CS.charAt) >> >> >>>> Related to the above, it might be preferable to retain the existing semantics of throwing NumberFormatException on a null string value, since someone might switch between parseInt(String ) and parseInt(String, int, int, int) and the null will then slip through the catch of NumberFormatException. >>> Consider Integer.parseInt(s.substring(1)) and Integer.parseInt(s, 10, 1): the first would throw NullPointerException currently if s == null, while the latter instead would start throwing NumberFormatException. I think we should favor throwing a NPE here. I'd argue that the risk that someone changes to any of the range-based alternatives when they aren't replacing a call to substring or similar are slim to none. >>> >> A good point. >> >> >>>> You could just use IndexOutOfBoundsException for the case of beginIndex < 0 and beginIndex >= endIndex and endIndex > s.length(), as is similarly the case for String.substring. Again, like previously, switching between parseInt(String, int, int) parseInt(String, int, int, int) requires no additional catching. You might want to add a comment in the code that some IndexOutOfBoundsException exceptions are implicit via calls to s.charAt (i did a double take before realizing :-) ). >>> Fair points. I could argue String.substring(int, int), StringBuilder.append(CharSequence, int, int)etc are wrong, but I guess that might be a losing battle. :-) >>> >> Right, if we were starting again it might be different but i think consistency is important. >> >> >>>> Integer.requireNonEmpty could be a static package private method on String (or perhaps even static public, it seems useful), plus i would not bother with the static import in this case. >>> The requireNonEmpty throws NumberFormatException to keep compatibility with the old methods, so it wouldn't make much sense to add that to String. >> Doh! what was i thinking. If it stays perhaps place it as a package private method on Number. >> >> >>> If I split the parseX(String... and parseX(CharSequence... implementations as I intend to, this method will be redundant though. >>> >> Ok. >> >> Paul. > From martinrb at google.com Fri Jul 11 23:33:37 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 11 Jul 2014 16:33:37 -0700 Subject: ThreadLocalRandom clinit troubles In-Reply-To: <53AB09E5.9070303@gmail.com> References: <53A29DC5.1030605@oracle.com> <53A3FA72.3060706@gmail.com> <53A418F2.3080201@gmail.com> <53A43055.5070803@oracle.com> <53A43EF3.8000206@gmail.com> <53A44C3A.6000607@oracle.com> <53A98525.9080908@gmail.com> <53A9EF29.7030208@gmail.com> <53AB09E5.9070303@gmail.com> Message-ID: Thanks to Peter for digging into the secure seed generator classes and coming up with a patch. Openjdk security folks, please review. I confess to getting lost whenever I try to orient myself in the twisty maze of seed generator implementation files. Anyways, it seems important to have prngs like ThreadLocalRandom be able to get a few bits of seed entropy without loading hundreds of classes and without occupying any file descriptors permanently. Perhaps at Google we will go back to writing some simple non-portable startup code to read /dev/urandom until openjdk security team comes up with a more principled solution (but one that doesn't drag in too much machinery). From claes.redestad at oracle.com Sat Jul 12 00:24:49 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 12 Jul 2014 02:24:49 +0200 Subject: RFR [9] 8041972: Add improved parse/format methods for Long/Integer In-Reply-To: References: <539CCE6D.6040207@oracle.com> <539D8821.3070808@univ-mlv.fr> <539D91A0.9050901@oracle.com> <539E1CB4.2050502@oracle.com> <539F4A6A.5020002@oracle.com> <539F4FCE.9080903@oracle.com> <53A04EE7.6090309@oracle.com> <53A06224.1040600@oracle.com> <53A32043.7070008@oracle.com> <39373F79-DC28-4A51-B617-680C6C508538@oracle.com> <53AC5007.30603@oracle.com> <167AB3E2-253B-41B5-B8DF-B6C7C7F7C16B@oracle.com> <53ADBFE3.50702@oracle.com> Message-ID: <53C08051.8010203@oracle.com> Thank you for looking at this, Mike! New webrev: http://cr.openjdk.java.net/~redestad/8041972/webrev.12 On 2014-07-12 00:55, Mike Duigou wrote: > Some comments: > > - The NumberFormatException.forInputString for some CharSequence is probably misleading since it doesn't consider the begin-end range which was in effect for the parsing. Rather than extracting the substring just for the error message perhaps include the index at which the error occurred. ie. add a NumberFormatException.forCharSequence(s, idx) static method I think not extracting the actual substring for error messages will quickly become awkward for cases where the sequence is representing something really large and/or noisy, so I think it's safer to only output the subsequence being parsed. In line with your other suggestions, I've added a forCharSequence which takes the sequence, beginIndex, endIndex and the index at which the error was generated to produce NFEs with messages in the style of 'Error at index 5 in: "-1234S"' > > - Long.java: Why not throw new NumberFormatException("Empty input") or call throw NumberFormatException.forInputString(""); Fixed! > > - declaration of and assignment to multmin could be combined. declaration of "result" could also be moved later. Fixed. I did the same for digit and narrowed the scoping of these vars. > > - Since it's not part of the public API I recommend moving the System/JavaLangAccess changes to a separate RFE. (and it needs a test). I've broken out those changes and will file a separate RFE for the formatUnsigned additions to JLS. Do you think we need to drop the "/format" from the name of this RFE? Thanks! /Claes > > > On Jun 27 2014, at 12:02 , Claes Redestad wrote: > >> Hi, >> >> updated webrev:http://cr.openjdk.java.net/~redestad/8041972/webrev.11 >> >> Changes: >> - Remove use of IllegalArgumentException in favor of IndexOutOfBoundsException/NumberFormatException, making the new methods behave in line with how String.substring wouldat some edge cases: "100".substring(3)equals "", thus Integer.parseInt("100", 10, 3) now throw NumberFormatException, while Integer.parseInt("100", 10, 4)/"100".substring(4) will throw IOOB. >> - For performance reasons the old and new methodshave been split apart. This introduces some code duplication, but removes the need to add special checks in some places. >> - Added more tests >> >> /Claes >> >> On 06/27/2014 10:54 AM, Paul Sandoz wrote: >>> On Jun 26, 2014, at 6:53 PM, Claes Redestad wrote: >>> >>>> On 06/25/2014 06:43 PM, Paul Sandoz wrote: >>>>> On Jun 19, 2014, at 7:39 PM, Claes Redestad wrote: >>>>>> Hi, >>>>>> >>>>>> an updated webrev with reworked, public methods is available here: >>>>>> http://cr.openjdk.java.net/~redestad/8041972/webrev.8/ >>>>>> >>>>>> Reviews are yet again appreciated! >>>>>> >>>>> I think "if (s == null)" or "Objects.requireNonNull(s)" is preferable to s.getClass(). (I am informed by those more knowledgeable than i that the latter also has poorer performance in the client compiler.) >>>> Agreed. Using s.getClass() was necessitated to retain performance using default compiler (-XX:+TieredCompilation) in the microbenchmarks I've been using, and going back to testing with C1 (via means of -XX:TieredStartAtLevel=1-3), it's apparent that the patch can cause a regression with the client compiler that I hadn't checked.It even looks like C2 alone (-XX:-TieredCompilation) suffers slightly. >>>> >>>> Changing to Objects.requireNonNull doesn't seem to make things better, though. Rather the regression seem to be due to C1 (and in some ways even C2) not dealing very well with the increased degrees of freedoms in the new methods, so I'm currently considering splitting apart the implementations to keep the old implementations of parseX(String[, int]) untouched while duplicating some code to build the new methods. Ugly, but I guess it's anecessary evil here. >>>> >>> Ok. Perhaps it might be possible to place the specifics of constraint checking in public methods, but they defer to a general private method that can assume it's arguments are safe (or such arguments are checked by other method calls e.g. CS.charAt) >>> >>> >>>>> Related to the above, it might be preferable to retain the existing semantics of throwing NumberFormatException on a null string value, since someone might switch between parseInt(String ) and parseInt(String, int, int, int) and the null will then slip through the catch of NumberFormatException. >>>> Consider Integer.parseInt(s.substring(1)) and Integer.parseInt(s, 10, 1): the first would throw NullPointerException currently if s == null, while the latter instead would start throwing NumberFormatException. I think we should favor throwing a NPE here. I'd argue that the risk that someone changes to any of the range-based alternatives when they aren't replacing a call to substring or similar are slim to none. >>>> >>> A good point. >>> >>> >>>>> You could just use IndexOutOfBoundsException for the case of beginIndex < 0 and beginIndex >= endIndex and endIndex > s.length(), as is similarly the case for String.substring. Again, like previously, switching between parseInt(String, int, int) parseInt(String, int, int, int) requires no additional catching. You might want to add a comment in the code that some IndexOutOfBoundsException exceptions are implicit via calls to s.charAt (i did a double take before realizing :-) ). >>>> Fair points. I could argue String.substring(int, int), StringBuilder.append(CharSequence, int, int)etc are wrong, but I guess that might be a losing battle. :-) >>>> >>> Right, if we were starting again it might be different but i think consistency is important. >>> >>> >>>>> Integer.requireNonEmpty could be a static package private method on String (or perhaps even static public, it seems useful), plus i would not bother with the static import in this case. >>>> The requireNonEmpty throws NumberFormatException to keep compatibility with the old methods, so it wouldn't make much sense to add that to String. >>> Doh! what was i thinking. If it stays perhaps place it as a package private method on Number. >>> >>> >>>> If I split the parseX(String... and parseX(CharSequence... implementations as I intend to, this method will be redundant though. >>>> >>> Ok. >>> >>> Paul. From stuart.marks at oracle.com Sat Jul 12 01:11:46 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 11 Jul 2014 18:11:46 -0700 Subject: RFR (XS): 8050105: test sun/rmi/rmic/minimizeWrapperInstances/run.sh fails Message-ID: <53C08B52.50306@oracle.com> Hi all, Please review this small patch to fix one of the old RMI tests that has started failing. This simply removes a couple test cases that use the (hidden, unsupported) -Xnew option of rmic, which relies on support for old -source and -target values that were recently removed from javac by the fix for JDK-8011044. For a full explanation, see my comments in the bug report: https://bugs.openjdk.java.net/browse/JDK-8050105 Thanks, s'marks # HG changeset patch # User smarks # Date 1405126872 25200 # Fri Jul 11 18:01:12 2014 -0700 # Node ID 5a8d01866745c116cfe6d676cb1b52b5d46bc96f # Parent 9d1e46cc39727fc19d9fea9217e20edfcd7289a1 8050105: test sun/rmi/rmic/minimizeWrapperInstances/run.sh fails Reviewed-by: XXX diff -r 9d1e46cc3972 -r 5a8d01866745 test/sun/rmi/rmic/minimizeWrapperInstances/run.sh --- a/test/sun/rmi/rmic/minimizeWrapperInstances/run.sh Fri Jul 11 14:06:42 2014 -0700 +++ b/test/sun/rmi/rmic/minimizeWrapperInstances/run.sh Fri Jul 11 18:01:12 2014 -0700 @@ -45,9 +45,3 @@ ${TESTJAVA}/bin/rmic -classpath ${TESTCLASSES:-.} -d ${TESTCLASSES:-.} -vcompat PImpl ${TESTJAVA}/bin/java ${TESTVMOPTS} -classpath ${TESTCLASSES:-.} Test - -${TESTJAVA}/bin/rmic -Xnew -classpath ${TESTCLASSES:-.} -d ${TESTCLASSES:-.} PImpl -${TESTJAVA}/bin/java ${TESTVMOPTS} -classpath ${TESTCLASSES:-.} Test - -${TESTJAVA}/bin/rmic -Xnew -classpath ${TESTCLASSES:-.} -d ${TESTCLASSES:-.} -vcompat PImpl -${TESTJAVA}/bin/java ${TESTVMOPTS} -classpath ${TESTCLASSES:-.} Test From lance.andersen at oracle.com Sat Jul 12 01:58:57 2014 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 11 Jul 2014 21:58:57 -0400 Subject: RFR (XS): 8050105: test sun/rmi/rmic/minimizeWrapperInstances/run.sh fails In-Reply-To: <53C08B52.50306@oracle.com> References: <53C08B52.50306@oracle.com> Message-ID: +1 On Jul 11, 2014, at 9:11 PM, Stuart Marks wrote: > Hi all, > > Please review this small patch to fix one of the old RMI tests that has started failing. This simply removes a couple test cases that use the (hidden, unsupported) -Xnew option of rmic, which relies on support for old -source and -target values that were recently removed from javac by the fix for JDK-8011044. > > For a full explanation, see my comments in the bug report: > > https://bugs.openjdk.java.net/browse/JDK-8050105 > > Thanks, > > s'marks > > > > > # HG changeset patch > # User smarks > # Date 1405126872 25200 > # Fri Jul 11 18:01:12 2014 -0700 > # Node ID 5a8d01866745c116cfe6d676cb1b52b5d46bc96f > # Parent 9d1e46cc39727fc19d9fea9217e20edfcd7289a1 > 8050105: test sun/rmi/rmic/minimizeWrapperInstances/run.sh fails > Reviewed-by: XXX > > diff -r 9d1e46cc3972 -r 5a8d01866745 test/sun/rmi/rmic/minimizeWrapperInstances/run.sh > --- a/test/sun/rmi/rmic/minimizeWrapperInstances/run.sh Fri Jul 11 14:06:42 2014 -0700 > +++ b/test/sun/rmi/rmic/minimizeWrapperInstances/run.sh Fri Jul 11 18:01:12 2014 -0700 > @@ -45,9 +45,3 @@ > > ${TESTJAVA}/bin/rmic -classpath ${TESTCLASSES:-.} -d ${TESTCLASSES:-.} -vcompat PImpl > ${TESTJAVA}/bin/java ${TESTVMOPTS} -classpath ${TESTCLASSES:-.} Test > - > -${TESTJAVA}/bin/rmic -Xnew -classpath ${TESTCLASSES:-.} -d ${TESTCLASSES:-.} PImpl > -${TESTJAVA}/bin/java ${TESTVMOPTS} -classpath ${TESTCLASSES:-.} Test > - > -${TESTJAVA}/bin/rmic -Xnew -classpath ${TESTCLASSES:-.} -d ${TESTCLASSES:-.} -vcompat PImpl > -${TESTJAVA}/bin/java ${TESTVMOPTS} -classpath ${TESTCLASSES:-.} Test > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mike.duigou at oracle.com Sat Jul 12 02:05:19 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 11 Jul 2014 19:05:19 -0700 Subject: RFR (XS): 8050105: test sun/rmi/rmic/minimizeWrapperInstances/run.sh fails In-Reply-To: <53C08B52.50306@oracle.com> References: <53C08B52.50306@oracle.com> Message-ID: Looks fine. On Jul 11 2014, at 18:11 , Stuart Marks wrote: > Hi all, > > Please review this small patch to fix one of the old RMI tests that has started failing. This simply removes a couple test cases that use the (hidden, unsupported) -Xnew option of rmic, which relies on support for old -source and -target values that were recently removed from javac by the fix for JDK-8011044. > > For a full explanation, see my comments in the bug report: > > https://bugs.openjdk.java.net/browse/JDK-8050105 > > Thanks, > > s'marks > > > > > # HG changeset patch > # User smarks > # Date 1405126872 25200 > # Fri Jul 11 18:01:12 2014 -0700 > # Node ID 5a8d01866745c116cfe6d676cb1b52b5d46bc96f > # Parent 9d1e46cc39727fc19d9fea9217e20edfcd7289a1 > 8050105: test sun/rmi/rmic/minimizeWrapperInstances/run.sh fails > Reviewed-by: XXX > > diff -r 9d1e46cc3972 -r 5a8d01866745 test/sun/rmi/rmic/minimizeWrapperInstances/run.sh > --- a/test/sun/rmi/rmic/minimizeWrapperInstances/run.sh Fri Jul 11 14:06:42 2014 -0700 > +++ b/test/sun/rmi/rmic/minimizeWrapperInstances/run.sh Fri Jul 11 18:01:12 2014 -0700 > @@ -45,9 +45,3 @@ > > ${TESTJAVA}/bin/rmic -classpath ${TESTCLASSES:-.} -d ${TESTCLASSES:-.} -vcompat PImpl > ${TESTJAVA}/bin/java ${TESTVMOPTS} -classpath ${TESTCLASSES:-.} Test > - > -${TESTJAVA}/bin/rmic -Xnew -classpath ${TESTCLASSES:-.} -d ${TESTCLASSES:-.} PImpl > -${TESTJAVA}/bin/java ${TESTVMOPTS} -classpath ${TESTCLASSES:-.} Test > - > -${TESTJAVA}/bin/rmic -Xnew -classpath ${TESTCLASSES:-.} -d ${TESTCLASSES:-.} -vcompat PImpl > -${TESTJAVA}/bin/java ${TESTVMOPTS} -classpath ${TESTCLASSES:-.} Test > From joe.darcy at oracle.com Sat Jul 12 02:57:10 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 11 Jul 2014 19:57:10 -0700 Subject: RFR (XS): 8050105: test sun/rmi/rmic/minimizeWrapperInstances/run.sh fails In-Reply-To: References: <53C08B52.50306@oracle.com> Message-ID: <53C0A406.2060408@oracle.com> Looks good to me too; thanks Stuart, -Joe On 07/11/2014 07:05 PM, Mike Duigou wrote: > Looks fine. > > On Jul 11 2014, at 18:11 , Stuart Marks wrote: > >> Hi all, >> >> Please review this small patch to fix one of the old RMI tests that has started failing. This simply removes a couple test cases that use the (hidden, unsupported) -Xnew option of rmic, which relies on support for old -source and -target values that were recently removed from javac by the fix for JDK-8011044. >> >> For a full explanation, see my comments in the bug report: >> >> https://bugs.openjdk.java.net/browse/JDK-8050105 >> >> Thanks, >> >> s'marks >> >> >> >> >> # HG changeset patch >> # User smarks >> # Date 1405126872 25200 >> # Fri Jul 11 18:01:12 2014 -0700 >> # Node ID 5a8d01866745c116cfe6d676cb1b52b5d46bc96f >> # Parent 9d1e46cc39727fc19d9fea9217e20edfcd7289a1 >> 8050105: test sun/rmi/rmic/minimizeWrapperInstances/run.sh fails >> Reviewed-by: XXX >> >> diff -r 9d1e46cc3972 -r 5a8d01866745 test/sun/rmi/rmic/minimizeWrapperInstances/run.sh >> --- a/test/sun/rmi/rmic/minimizeWrapperInstances/run.sh Fri Jul 11 14:06:42 2014 -0700 >> +++ b/test/sun/rmi/rmic/minimizeWrapperInstances/run.sh Fri Jul 11 18:01:12 2014 -0700 >> @@ -45,9 +45,3 @@ >> >> ${TESTJAVA}/bin/rmic -classpath ${TESTCLASSES:-.} -d ${TESTCLASSES:-.} -vcompat PImpl >> ${TESTJAVA}/bin/java ${TESTVMOPTS} -classpath ${TESTCLASSES:-.} Test >> - >> -${TESTJAVA}/bin/rmic -Xnew -classpath ${TESTCLASSES:-.} -d ${TESTCLASSES:-.} PImpl >> -${TESTJAVA}/bin/java ${TESTVMOPTS} -classpath ${TESTCLASSES:-.} Test >> - >> -${TESTJAVA}/bin/rmic -Xnew -classpath ${TESTCLASSES:-.} -d ${TESTCLASSES:-.} -vcompat PImpl >> -${TESTJAVA}/bin/java ${TESTVMOPTS} -classpath ${TESTCLASSES:-.} Test >> From forax at univ-mlv.fr Sat Jul 12 14:05:10 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 12 Jul 2014 16:05:10 +0200 Subject: Loopy CallSite Message-ID: <53C14096.9090409@univ-mlv.fr> It seems that the JIT is lost with whe there is a loopy callsite and never stabilize (or the steady state is after the program ends). import java.lang.invoke.MethodHandle; import java.lang.invoke.MethodHandles; import java.lang.invoke.MethodType; import java.lang.invoke.MutableCallSite; public class Loop { static class LoopyCS extends MutableCallSite { public LoopyCS() { super(MethodType.methodType(void.class, int.class)); MethodHandle target = dynamicInvoker(); target = MethodHandles.filterArguments(target, 0, FOO); target = MethodHandles.guardWithTest(ZERO, target, MethodHandles.dropArguments(MethodHandles.constant(int.class, 0).asType(MethodType.methodType(void.class)), 0, int.class)); setTarget(target); } } static final MethodHandle FOO, ZERO; static { try { FOO = MethodHandles.lookup().findStatic(Loop.class, "foo", MethodType.methodType(int.class, int.class)); ZERO = MethodHandles.lookup().findStatic(Loop.class, "zero", MethodType.methodType(boolean.class, int.class)); } catch (NoSuchMethodException | IllegalAccessException e) { throw new AssertionError(e); } } private static boolean zero(int i) { return i != 0; } private static int foo(int i) { COUNTER++; return i - 1; } private static int COUNTER = 0; public static void main(String[] args) throws Throwable { for(int i=0; i<100_000; i++) { new LoopyCS().getTarget().invokeExact(1_000); } System.out.println(COUNTER); } } cheers, R?mi From otaviojava at java.net Sat Jul 12 14:38:25 2014 From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Sat, 12 Jul 2014 11:38:25 -0300 Subject: RFR: 8049892: Replace uses of 'new Integer()' with appropriate alternative across core classes In-Reply-To: <81766990-91E6-49F4-8EF5-37295275BE15@oracle.com> References: <81766990-91E6-49F4-8EF5-37295275BE15@oracle.com> Message-ID: http://cr.openjdk.java.net/~prr/8049892.1/ On Fri, Jul 11, 2014 at 6:41 AM, Pavel Rappo wrote: > Hi Otavio, > > Other than things already spotted by Andrej, the change looks good to me. > Thank you for doing this. > > -Pavel > > On 11 Jul 2014, at 02:36, Ot?vio Gon?alves de Santana < > otaviopolianasantana at gmail.com> wrote: > > > https://bugs.openjdk.java.net/browse/JDK-8049892 > > http://cr.openjdk.java.net/~prr/8049892/ > > > > -- > > Cheers!. > > > > Ot?vio Gon?alves de Santana > > > > blog: http://otaviosantana.blogspot.com.br/ > > twitter: http://twitter.com/otaviojava > > site: *http://about.me/otaviojava * > > 55 (11) 98255-3513 > > -- Atenciosamente. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513 From forax at univ-mlv.fr Sat Jul 12 15:41:13 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 12 Jul 2014 17:41:13 +0200 Subject: Stream.concat Message-ID: <53C15719.6070105@univ-mlv.fr> I was not able to find the answer to my question in the archive, why Stream.concat is not implemented like this ? @SafeVarargs public static Stream concat(Stream... streams) { return Arrays.stream(streams).flatMap(Function.identity()); } R?mi From peter.levart at gmail.com Sat Jul 12 15:47:34 2014 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 12 Jul 2014 17:47:34 +0200 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53C03645.6090900@cs.oswego.edu> References: <53B57E16.5020802@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC6506.3060308@oracle.com> <53BC6640.9020508@gmail.com> <53BC6B6F.6000709@oracle.com> <53BC73D7.7020900@gmail.com> <53BC8BF0.7000601@oracle.com> <53BCEDD4.6010906@gmail.com> <53BCF049.8090303@gmail.com> <53BDBF94.7040208@gmail.com> <53C03645.6090900@cs.oswego.edu> Message-ID: <53C15896.9070001@gmail.com> On 07/11/2014 09:08 PM, Doug Lea wrote: > > I've been content to just observe Martin and Peter's nice efforts > on this, but one note: > > On 07/11/2014 03:00 PM, Martin Buchholz wrote: >> On Wed, Jul 9, 2014 at 3:17 PM, Peter Levart >> wrote: >> >>> >>> IMH resizing is arranged so that the table is always 33% ... 66% >>> full (if >>> nothing is ever removed from it) except when capacity reaches 2**29, >>> then >>> it can be filled up to the top. >>> >>> avg. # of probes can be taken as a rough estimation of average >>> slow-down, >>> max. # of probes can be taken as a rough estimation of >>> worst-case-operation >>> slow-down. >>> >>> So where to draw the line? >>> >> >> Linear probing has long been known to be prone to long worst-case >> probes, >> but with recent computer architectures this is offset by its extreme >> cache >> friendliness. > > Bear in mind that the number of bits of identityHashCode is less > than 32 on all JVMs I know. It can be as low as 23, which means that > you are sure to see a lot of exact collisions on IHMs with only > tens of millions of elements, and there's nothing much you can > do that will help. > > -Doug > > We have max. size = 2^29 - 1. This can not change because of serialization backwards compatibility. It could be a little less, but not much. Experiment shows that it is possible to fill IHM up to 99% with not too much CPU effort. If such IHM is serialized, we must be able to deserialize it... But why do we have to limit table length to 2^30 ? Because it has to be power of 2 and 2^31 is already a negative number... What would happen if max. table length was 2^30 + 2^29 ... Here's what we get now: // max. size = 2^29 - 1 // table length = 2^30 10% max. size, probes: 0.1 avg., 9 max. 20% max. size, probes: 0.1 avg., 15 max. 30% max. size, probes: 0.2 avg., 25 max. 40% max. size, probes: 0.3 avg., 38 max. 50% max. size, probes: 0.5 avg., 64 max. 60% max. size, probes: 0.7 avg., 93 max. 65% max. size, probes: 0.9 avg., 147 max. 70% max. size, probes: 1.2 avg., 224 max. 75% max. size, probes: 1.5 avg., 354 max. 80% max. size, probes: 2.0 avg., 441 max. 85% max. size, probes: 2.8 avg., 789 max. 90% max. size, probes: 4.5 avg., 1869 max. 91% max. size, probes: 5.1 avg., 2377 max. 92% max. size, probes: 5.7 avg., 3409 max. 93% max. size, probes: 6.6 avg., 3804 max. 94% max. size, probes: 7.8 avg., 5824 max. 95% max. size, probes: 9.5 avg., 7021 max. 96% max. size, probes: 12.0 avg., 12607 max. 97% max. size, probes: 16.2 avg., 17643 max. 98% max. size, probes: 24.5 avg., 34561 max. 99% max. size, probes: 49.6 avg., 131371 max. 100% ... haven't waited long enough.... If table length was 2^30 + 2^29, we would only fill it up to 66% like always and there would be no slow-down: // max. size = 2^29 - 1 // table length = 2^30 + 2^29 10% max. size, probes: 0.0 avg., 7 max. 20% max. size, probes: 0.1 avg., 11 max. 30% max. size, probes: 0.1 avg., 13 max. 40% max. size, probes: 0.2 avg., 20 max. 50% max. size, probes: 0.3 avg., 28 max. 60% max. size, probes: 0.4 avg., 40 max. 65% max. size, probes: 0.4 avg., 42 max. 70% max. size, probes: 0.5 avg., 52 max. 75% max. size, probes: 0.5 avg., 65 max. 80% max. size, probes: 0.6 avg., 87 max. 85% max. size, probes: 0.7 avg., 87 max. 90% max. size, probes: 0.8 avg., 128 max. 91% max. size, probes: 0.8 avg., 128 max. 92% max. size, probes: 0.8 avg., 128 max. 93% max. size, probes: 0.8 avg., 129 max. 94% max. size, probes: 0.9 avg., 129 max. 95% max. size, probes: 0.9 avg., 131 max. 96% max. size, probes: 0.9 avg., 150 max. 97% max. size, probes: 0.9 avg., 150 max. 98% max. size, probes: 1.0 avg., 159 max. 99% max. size, probes: 1.0 avg., 159 max. 100% max. size, probes: 1.0 avg., 159 max. If we're willing to pay the price of special-casing the non-power-of-2 MAX_CAPACITY = (1 << 29) + (1 << 28), which amounts to approx. 4% of performance: Original code: Benchmark Mode Samples Score Score error Units j.t.IHMBench.ihm0Put thrpt 30 25217087.593 50117.867 ops/s j.t.IHMBench.ihm1Get thrpt 30 43017677.457 230902.599 ops/s Patched code: Benchmark Mode Samples Score Score error Units j.t.IHMBench.ihm0Put thrpt 30 24213091.899 122980.408 ops/s j.t.IHMBench.ihm1Get thrpt 30 40754537.027 936380.022 ops/s Using JMH benchmark: @State(Scope.Thread) public class IHMBench { static final Object[] keys = new Object[1000_000]; static { for (int i = 0; i < keys.length; i++) { keys[i] = new Object(); } } static final Object value = new Object(); final Map map = new IdentityHashMap(keys.length); int i = 0; @Benchmark public void ihm0Put(Blackhole bh) { bh.consume(map.put(keys[i], value)); int j = i + 1; i = j < keys.length ? j : 0; } @Benchmark public void ihm1Get(Blackhole bh) { bh.consume(map.get(keys[i])); int j = i + 1; i = j < keys.length ? j : 0; } } Then here's a possible solution: http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.06/ Is it worth it? Regards, Peter From headius at headius.com Sat Jul 12 18:08:58 2014 From: headius at headius.com (Charles Oliver Nutter) Date: Sat, 12 Jul 2014 18:08:58 +0000 Subject: Loopy CallSite In-Reply-To: <53C14096.9090409@univ-mlv.fr> References: <53C14096.9090409@univ-mlv.fr> Message-ID: I played with this some years ago. Doesn't it just become recursive, because it won't inline through the dynamicInvoker? - Charlie (mobile) On Jul 12, 2014 9:36 AM, "Remi Forax" wrote: > It seems that the JIT is lost with whe there is a loopy callsite and never > stabilize (or the steady state is after the program ends). > > import java.lang.invoke.MethodHandle; > import java.lang.invoke.MethodHandles; > import java.lang.invoke.MethodType; > import java.lang.invoke.MutableCallSite; > > public class Loop { > static class LoopyCS extends MutableCallSite { > public LoopyCS() { > super(MethodType.methodType(void.class, int.class)); > > MethodHandle target = dynamicInvoker(); > target = MethodHandles.filterArguments(target, 0, FOO); > target = MethodHandles.guardWithTest(ZERO, > target, > MethodHandles.dropArguments(MethodHandles.constant(int.class, > 0).asType(MethodType.methodType(void.class)), 0, int.class)); > setTarget(target); > } > } > > static final MethodHandle FOO, ZERO; > static { > try { > FOO = MethodHandles.lookup().findStatic(Loop.class, "foo", > MethodType.methodType(int.class, int.class)); > ZERO = MethodHandles.lookup().findStatic(Loop.class, "zero", > MethodType.methodType(boolean.class, int.class)); > } catch (NoSuchMethodException | IllegalAccessException e) { > throw new AssertionError(e); > } > } > > private static boolean zero(int i) { > return i != 0; > } > > private static int foo(int i) { > COUNTER++; > return i - 1; > } > > private static int COUNTER = 0; > > public static void main(String[] args) throws Throwable { > for(int i=0; i<100_000; i++) { > new LoopyCS().getTarget().invokeExact(1_000); > } > System.out.println(COUNTER); > } > } > > cheers, > R?mi > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From peter.levart at gmail.com Sat Jul 12 18:12:17 2014 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 12 Jul 2014 20:12:17 +0200 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53C15896.9070001@gmail.com> References: <53B57E16.5020802@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC6506.3060308@oracle.com> <53BC6640.9020508@gmail.com> <53BC6B6F.6000709@oracle.com> <53BC73D7.7020900@gmail.com> <53BC8BF0.7000601@oracle.com> <53BCEDD4.6010906@gmail.com> <53BCF049.8090303@gmail.com> <53BDBF94.7040208@gmail.com> <53C03645.6090900@cs.oswego.edu> <53C15896.9070001@gmail.com> Message-ID: <53C17A81.2000200@gmail.com> On 07/12/2014 05:47 PM, Peter Levart wrote: > If we're willing to pay the price of special-casing the non-power-of-2 > MAX_CAPACITY = (1 << 29) + (1 << 28), which amounts to approx. 4% of > performance, > > Then here's a possible solution: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.06/ > Two fixes: http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.07/ One is a fix for possible overflow in resize() + rearrangement (which is specific to my proposal) and the other is replacement of condition that triggers resize in put() from (3*size > length) to (3*size >= length). The later should be applied to Martin's latest version too, I think, if it is decided that my proposal is inadequate. Why is (3*size >= length) more appropriate condition to trigger resize? Because it is more aligned with capacity(size) function which is basically a clamped Integer.highestOneBit(3 * size). Map preallocation makes a table with length = 2 * capacity(expectedMaxSize) (3 * size < 2 * highestOneBit(3*size)) is true for any size, so IHM will never be resized if filled with size elements and table was preallocated with length = 2 * highestOneBit(3*size) even if condition for resizing is changed from (3*size > length) to (3*size >= length). Current condition sometimes resizes a little to late when preallocation would already create a bigger table. Now if we change that, my proposed webrev.07 does not need MAXIMUM_SIZE constant any more. Attempt to insert the 2^29-th element (when size is about to become 2^29) triggers resize since at that time length == 2 * MAXIMUM_CAPACITY which is exactly 3 * 2^29 and this alone can be used as a trigger to throw OOME in resize()... Regards, Peter From peter.levart at gmail.com Sat Jul 12 18:25:07 2014 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 12 Jul 2014 20:25:07 +0200 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53C17A81.2000200@gmail.com> References: <53B57E16.5020802@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC6506.3060308@oracle.com> <53BC6640.9020508@gmail.com> <53BC6B6F.6000709@oracle.com> <53BC73D7.7020900@gmail.com> <53BC8BF0.7000601@oracle.com> <53BCEDD4.6010906@gmail.com> <53BCF049.8090303@gmail.com> <53BDBF94.7040208@gmail.com> <53C03645.6090900@cs.oswego.edu> <53C15896.9070001@gmail.com> <53C17A81.2000200@gmail.com> Message-ID: <53C17D83.50608@gmail.com> On 07/12/2014 08:12 PM, Peter Levart wrote: > If we're willing to pay the price of special-casing the non-power-of-2 > MAX_CAPACITY = (1 << 29) + (1 << 28), which amounts to approx. 4% of > performance, The cause of performance drop is of course the conditional in: 297 private static int hash(Object x, int length) { 298 int h = System.identityHashCode(x); 299 // multiply by -127 300 h -= h << 7; 301 if (length < MAXIMUM_CAPACITY * 2) { // length is 2^n 302 // left-shift to use least bit as part of hash 303 return (h << 1) & (length - 1); 304 } 305 // assert length == MAXIMUM_CAPACITY * 2 306 // clamp 307 h &= (MAXIMUM_CAPACITY / 3 * 4 - 1); 308 // Multiply by 3/2 and reset 0th bit 309 return (h + (h >> 1)) & ~1; 310 } If I change it to: 297 private static int hash(Object x, int length) { 298 int h = System.identityHashCode(x); 299 // multiply by -127 300 h -= h << 7; 302 // left-shift to use least bit as part of hash 303 return (h << 1) & (length - 1); 310 } ...performance is restored, but then of course it only works until table is resized to 2*MAX_CAPACITY. Does anybody have any idea how to make it faster? Regards, Peter From peter.levart at gmail.com Sat Jul 12 19:20:06 2014 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 12 Jul 2014 21:20:06 +0200 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53C17A81.2000200@gmail.com> References: <53B57E16.5020802@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC6506.3060308@oracle.com> <53BC6640.9020508@gmail.com> <53BC6B6F.6000709@oracle.com> <53BC73D7.7020900@gmail.com> <53BC8BF0.7000601@oracle.com> <53BCEDD4.6010906@gmail.com> <53BCF049.8090303@gmail.com> <53BDBF94.7040208@gmail.com> <53C03645.6090900@cs.oswego.edu> <53C15896.9070001@gmail.com> <53C17A81.2000200@gmail.com> Message-ID: <53C18A66.6080909@gmail.com> On 07/12/2014 08:12 PM, Peter Levart wrote: > (3 * size < 2 * highestOneBit(3*size)) is true for any size, so IHM > will never be resized if filled with size elements and table was > preallocated with length = > 2 * highestOneBit(3*size) even if condition for resizing is changed > from (3*size > length) to (3*size >= length). Current condition > sometimes resizes a little to late when preallocation would already > create a bigger table. May latest statement is of course false. If length is a power of two, then it can never be equal 3*size. For power of two lengths, both conditions are equivalent. But for my purpose the >= is better... Peter From ivan.gerasimov at oracle.com Sat Jul 12 20:46:20 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sun, 13 Jul 2014 00:46:20 +0400 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53C17A81.2000200@gmail.com> References: <53B57E16.5020802@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC6506.3060308@oracle.com> <53BC6640.9020508@gmail.com> <53BC6B6F.6000709@oracle.com> <53BC73D7.7020900@gmail.com> <53BC8BF0.7000601@oracle.com> <53BCEDD4.6010906@gmail.com> <53BCF049.8090303@gmail.com> <53BDBF94.7040208@gmail.com> <53C03645.6090900@cs.oswego.edu> <53C15896.9070001@gmail.com> <53C17A81.2000200@gm! ail.com> Message-ID: <53C19E9C.7070306@oracle.com> Peter, seems you need to fix capacity(): int capacity = Integer.highestOneBit(expectedMaxSize + (expectedMaxSize << 1)); does not necessarily produces a negative number in the case of overflow. Why don't you want to use the variant that from the latest Martin's webrev? It seems to work correctly with your proposal too. Sincerely yours, Ivan On 12.07.2014 22:12, Peter Levart wrote: > > On 07/12/2014 05:47 PM, Peter Levart wrote: >> If we're willing to pay the price of special-casing the >> non-power-of-2 MAX_CAPACITY = (1 << 29) + (1 << 28), which amounts to >> approx. 4% of performance, >> >> Then here's a possible solution: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.06/ >> > > Two fixes: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.07/ > > One is a fix for possible overflow in resize() + rearrangement (which > is specific to my proposal) and the other is replacement of condition > that triggers resize in put() from (3*size > length) to (3*size >= > length). The later should be applied to Martin's latest version too, I > think, if it is decided that my proposal is inadequate. > > Why is (3*size >= length) more appropriate condition to trigger > resize? Because it is more aligned with capacity(size) function which > is basically a clamped Integer.highestOneBit(3 * size). > > Map preallocation makes a table with length = 2 * > capacity(expectedMaxSize) > > (3 * size < 2 * highestOneBit(3*size)) is true for any size, so IHM > will never be resized if filled with size elements and table was > preallocated with length = > 2 * highestOneBit(3*size) even if condition for resizing is changed > from (3*size > length) to (3*size >= length). Current condition > sometimes resizes a little to late when preallocation would already > create a bigger table. > > Now if we change that, my proposed webrev.07 does not need > MAXIMUM_SIZE constant any more. Attempt to insert the 2^29-th element > (when size is about to become 2^29) triggers resize since at that time > length == 2 * MAXIMUM_CAPACITY which is exactly 3 * 2^29 and this > alone can be used as a trigger to throw OOME in resize()... > > Regards, Peter > From claes.redestad at oracle.com Sat Jul 12 22:26:58 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 13 Jul 2014 00:26:58 +0200 Subject: RFR (S): 8050114: Expose Integer/Long formatUnsigned methods internally Message-ID: <53C1B632.5080404@oracle.com> Hi, please review this patch to expose formatUnsignedInt/-Long through JavaLangAccess. webrev: http://cr.openjdk.java.net/~redestad/8050114/webrev.1/ bug: https://bugs.openjdk.java.net/browse/JDK-8050114 The behavior of the methods have been adjusted to be zero-padding in case the number formatted is shorter than the specified length, since that simplifies use cases for which this utility is exposed internally, e.g., JDK-8006627 . Microbenchmarks show that this does not adversely affect performance of current uses through toHexString, toOctalString etc. Thanks! /Claes From peter.levart at gmail.com Sat Jul 12 22:41:11 2014 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 13 Jul 2014 00:41:11 +0200 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53C19E9C.7070306@oracle.com> References: <53B57E16.5020802@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC6506.3060308@oracle.com> <53BC6640.9020508@gmail.com> <53BC6B6F.6000709@oracle.com> <53BC73D7.7020900@gmail.com> <53BC8BF0.7000601@oracle.com> <53BCEDD4.6010906@gmail.com> <53BCF049.8090303@gmail.com> <53BDBF94.7040208@gmail.com> <53C03645.6090900@cs.oswego.edu> <53C15896.9070001@gmail.com> <53C17A81.2000200@gm! ail.com> <53C19E9C.7070306@oracle.com> Message-ID: <53C1B987.6030609@gmail.com> On 07/12/2014 10:46 PM, Ivan Gerasimov wrote: > Peter, seems you need to fix capacity(): > int capacity = Integer.highestOneBit(expectedMaxSize + (expectedMaxSize << 1)); > does not necessarily produces a negative number in the case of overflow. Good catch. You're right. > > Why don't you want to use the variant that from the latest Martin's > webrev? > It seems to work correctly with your proposal too. Not quite. Martin's version is: return (expectedMaxSize > MAXIMUM_CAPACITY / 3) ? MAXIMUM_CAPACITY : (expectedMaxSize <= 2 * MINIMUM_CAPACITY / 3) ? MINIMUM_CAPACITY : Integer.highestOneBit(expectedMaxSize + (expectedMaxSize << 1)); My MAXIMUM_CAPACITY is not power of two, but: 3 << 28; If, for example, expectedMaxSize = (1 << 28) + 1, then Martin's capacity() would return MAXIMUM_CAPACITY, but I would like it to return 2 ^ 29, since expectedMaxSize is only just past 50% of such capacity. So here's a better variant: return Math.min( MAXIMUM_CAPACITY, Math.max( MINIMUM_CAPACITY, expectedMaxSize > Integer.MAX_VALUE / 3 ? MAXIMUM_CAPACITY // 3 * expectedMaxSize would overflow : Integer.highestOneBit(expectedMaxSize + (expectedMaxSize << 1)) ) ); I'll put this and another simplification into a new webrev tomorow. Regards, Peter > > Sincerely yours, > Ivan > > > On 12.07.2014 22:12, Peter Levart wrote: >> >> On 07/12/2014 05:47 PM, Peter Levart wrote: >>> If we're willing to pay the price of special-casing the >>> non-power-of-2 MAX_CAPACITY = (1 << 29) + (1 << 28), which amounts >>> to approx. 4% of performance, >>> >>> Then here's a possible solution: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.06/ >>> >> >> Two fixes: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.07/ >> >> One is a fix for possible overflow in resize() + rearrangement (which >> is specific to my proposal) and the other is replacement of condition >> that triggers resize in put() from (3*size > length) to (3*size >= >> length). The later should be applied to Martin's latest version too, >> I think, if it is decided that my proposal is inadequate. >> >> Why is (3*size >= length) more appropriate condition to trigger >> resize? Because it is more aligned with capacity(size) function which >> is basically a clamped Integer.highestOneBit(3 * size). >> >> Map preallocation makes a table with length = 2 * >> capacity(expectedMaxSize) >> >> (3 * size < 2 * highestOneBit(3*size)) is true for any size, so IHM >> will never be resized if filled with size elements and table was >> preallocated with length = >> 2 * highestOneBit(3*size) even if condition for resizing is changed >> from (3*size > length) to (3*size >= length). Current condition >> sometimes resizes a little to late when preallocation would already >> create a bigger table. >> >> Now if we change that, my proposed webrev.07 does not need >> MAXIMUM_SIZE constant any more. Attempt to insert the 2^29-th element >> (when size is about to become 2^29) triggers resize since at that >> time length == 2 * MAXIMUM_CAPACITY which is exactly 3 * 2^29 and >> this alone can be used as a trigger to throw OOME in resize()... >> >> Regards, Peter >> > From jeffhain at rocketmail.com Sun Jul 13 11:24:37 2014 From: jeffhain at rocketmail.com (Jeff Hain) Date: Sun, 13 Jul 2014 12:24:37 +0100 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53C1B987.6030609@gmail.com> References: <53B57E16.5020802@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC6506.3060308@oracle.com> <53BC6640.9020508@gmail.com> <53BC6B6F.6000709@oracle.com> <53BC73D7.7020900@gmail.com> <53BC8BF0.7000601@oracle.com> <53BCEDD4.6010906@gmail.com> <53BCF049.8090303@gmail.com> <53BDBF94.7040208@gmail.com> <53C03645.6090900@cs.oswego.edu> <53C15896.9070001@gmail.com> <53C17A81.2000200@gm! ail.com> <53C19E9C.7070306@oracle.com> <53C1B987.6030609@gmail.com> Message-ID: <1405250677.3551.YahooMailNeo@web172402.mail.ir2.yahoo.com> On 07/08/2014 10:07 PM, Martin Buchholz wrote: > I updated my webrev and it is again "feature-complete". > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity/ > > (old webrev at > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity.0/ > > ) The additional loop hurts in my benchmarks (10-15 percents slower). If removing it and adding a specific putAfterResize() method (without the "item == k" test), replacing "continue" with "return putAfterResize(k, value)", it's much better. NB: In one bench I clear the map each time it hits 1000 mappings, so that it always fit in some cache, which is about 4 times faster than going up to 1000*1000 mappings (clear() cost included), and make put internals costs variations more obvious (hopefully). -Jeff From forax at univ-mlv.fr Sun Jul 13 12:15:38 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 13 Jul 2014 14:15:38 +0200 Subject: Serializable lambda and bytecode rewriters Message-ID: <53C2786A.5080609@univ-mlv.fr> Hi guys, there is, i think, a serious issue in the way the deserialization of lambda is done by javac (or ecj which uses the same scheme), exactly in the code of the generated method $deserializeLambda$. Bytecode rewriting tools like jarjar or proguard works by rewriting all reference to types in class files so they need to distinguish if a reference is let say a String of a method descriptor. The actual code of $deserializeLambda$ generated by javac breaks that assumption, all parameters of a deserialized lambda are checked as String thus are not rewritten correctly by the bytecode rewriters. So currently, it's no possible to use a bytecode rewriting tools with the jdk8 if there is a serializable lambda somewhere in the code. My bad on that, I should have figure out that before the release of 8. To fix this issue, the parameters that reference a lambda inside $deserializeLambda$ should be typed as constant method handles and constant method types but given that the serializable form a lambda is a bunch of strings, doing the mapping between the two forms is not that obvious. Moreover, there is maybe a performance problem because - the switch on the String that represent the name of the implementation method can not be used because it encodes the hashCode of a name that should be rewritten by the static tools. - constant method handles and constant method types are not required to be interned by the VM thus may be re-created each time $deserializeLambda$ is called if the code use ldc. The invokedynamic evangelist in me think that $deserializeLambda$ can be implemented as a unique invokedynamic call taking a SerializedLambda as parameter with all the parameters of all the serializable lambdas declared in the current class as bootstrap arguments. The bootstrap method will create a HashMap of a all methods names, and at runtime check if a serialized lambda is valid or not. Something like: static class LambdaParameters { ... public boolean verify(SerializedLambda serializedLambda) { // check all parameters } } public static CallSite deserializeLambda(Lookup lookup, String name, MethodType type, Object[] lambdaParameters) { HashMap map = new HashMap<>(); for(int i=0; i < lambdaParameters.length; i+=3) { ... MethodHandle mh = (MethodHandle) lambdaParameters[i + 1]; String name = lookup.revealDirect(mh).getName(); ... map.put(name, new LambdaParameters(...)); } return new ConstantCallSite(CHECK.bindTo(map)); } private static final MethodHandle = ::check; private static boolean check(HashMap map, SerializedLambda serializedLambda) { LambdaParameters parameters = map.get(serializedLambda.getImplMethodName()); return parameters != null && parameters.verify(serializedLambda); } A bootstrap method can not have more than 252 arguments, so you can not encode more than 84 (252 / 3) serializable lambdas, but I think that current scheme because it generated a lot of bytecodes will hit the 65 535 bytecodes near that number too. Anyway, if there is more than 84 serializable lambdas, $deserializableLambda$ can call more than one invokedynamic in chain. As you can see, the solution seems complex but may be somebody has a better solution :) regards, R?mi From peter.levart at gmail.com Sun Jul 13 15:25:31 2014 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 13 Jul 2014 17:25:31 +0200 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <1405250677.3551.YahooMailNeo@web172402.mail.ir2.yahoo.com> References: <53B57E16.5020802@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC6506.3060308@oracle.com> <53BC6640.9020508@gmail.com> <53BC6B6F.6000709@oracle.com> <53BC73D7.7020900@gmail.com> <53BC8BF0.7000601@oracle.com> <53BCEDD4.6010906@gmail.com> <53BCF049.8090303@gmail.com> <53BDBF94.7040208@gmail.com> <53C03645.6090900@cs.oswego.edu> <53C15896.9070001@gmail.com> <53C17A81.2000200@gm! ail.com> <53C19E9C.7070306@oracle.com> <53C1B987.6030609@gmail.com> <1405250677.3551.YahooMailNeo@web172402.mail.ir2.yahoo.com> Message-ID: <53C2A4EB.4000204@gmail.com> On 07/13/2014 01:24 PM, Jeff Hain wrote: > On 07/08/2014 10:07 PM, Martin Buchholz wrote: >> I updated my webrev and it is again "feature-complete". >> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity/ >> >> (old webrev at >> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity.0/ >> >> ) > The additional loop hurts in my benchmarks (10-15 percents slower). > If removing it and adding a specific putAfterResize() method (without the > "item == k" test), replacing "continue" with "return putAfterResize(k, value)", > it's much better. > > NB: In one bench I clear the map each time it hits 1000 mappings, > so that it always fit in some cache, which is about 4 times faster > than going up to 1000*1000 mappings (clear() cost included), and > make put internals costs variations more obvious (hopefully). > > -Jeff Can you post the benchmark source? Thanks, Peter From peter.levart at gmail.com Sun Jul 13 22:10:16 2014 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 14 Jul 2014 00:10:16 +0200 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53C1B987.6030609@gmail.com> References: <53B57E16.5020802@oracle.com> <53BB4F44.5040205@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC6506.3060308@oracle.com> <53BC6640.9020508@gmail.com> <53BC6B6F.6000709@oracle.com> <53BC73D7.7020900@gmail.com> <53BC8BF0.7000601@oracle.com> <53BCEDD4.6010906@gmail.com> <53BCF049.8090303@gmail.com> <53BDBF94.7040208@gmail.com> <53C03645.6090900@cs.oswego.edu> <53C15896.9070001@gmail.com> <53C17A81.2000200@gm! ail.com> <53C19E9C.7070306@oracle.com> <53C1B987.6030609@gmail.com> Message-ID: <53C303C8.7080809@gmail.com> On 07/13/2014 12:41 AM, Peter Levart wrote: > > On 07/12/2014 10:46 PM, Ivan Gerasimov wrote: >> Peter, seems you need to fix capacity(): >> int capacity = Integer.highestOneBit(expectedMaxSize + (expectedMaxSize << 1)); >> does not necessarily produces a negative number in the case of overflow. > > Good catch. You're right. > > So here's a better variant: > > return Math.min( > MAXIMUM_CAPACITY, > Math.max( > MINIMUM_CAPACITY, > expectedMaxSize > Integer.MAX_VALUE / 3 > ? MAXIMUM_CAPACITY // 3 * expectedMaxSize would > overflow > : Integer.highestOneBit(expectedMaxSize + > (expectedMaxSize << 1)) > ) > ); > > > Incorporated in new webrev: http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.08/ Also in this webrev: changing the condition by which putAll() decides to call resize() makes a boolean return from resize() unnecessary again, since it's only called when resize is actually needed (from put() when 3*size reaches 2*capacity, from putAll(), when capacity calculated from argument map's size is greater than current capacity). Retry loop in put() can be simplified consequently. Regards, Peter > > >> >> Sincerely yours, >> Ivan >> >> >> On 12.07.2014 22:12, Peter Levart wrote: >>> >>> On 07/12/2014 05:47 PM, Peter Levart wrote: >>>> If we're willing to pay the price of special-casing the >>>> non-power-of-2 MAX_CAPACITY = (1 << 29) + (1 << 28), which amounts >>>> to approx. 4% of performance, >>>> >>>> Then here's a possible solution: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.06/ >>>> >>> >>> Two fixes: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.07/ >>> >>> One is a fix for possible overflow in resize() + rearrangement >>> (which is specific to my proposal) and the other is replacement of >>> condition that triggers resize in put() from (3*size > length) to >>> (3*size >= length). The later should be applied to Martin's latest >>> version too, I think, if it is decided that my proposal is inadequate. >>> >>> Why is (3*size >= length) more appropriate condition to trigger >>> resize? Because it is more aligned with capacity(size) function >>> which is basically a clamped Integer.highestOneBit(3 * size). >>> >>> Map preallocation makes a table with length = 2 * >>> capacity(expectedMaxSize) >>> >>> (3 * size < 2 * highestOneBit(3*size)) is true for any size, so IHM >>> will never be resized if filled with size elements and table was >>> preallocated with length = >>> 2 * highestOneBit(3*size) even if condition for resizing is changed >>> from (3*size > length) to (3*size >= length). Current condition >>> sometimes resizes a little to late when preallocation would already >>> create a bigger table. >>> >>> Now if we change that, my proposed webrev.07 does not need >>> MAXIMUM_SIZE constant any more. Attempt to insert the 2^29-th >>> element (when size is about to become 2^29) triggers resize since at >>> that time length == 2 * MAXIMUM_CAPACITY which is exactly 3 * 2^29 >>> and this alone can be used as a trigger to throw OOME in resize()... >>> >>> Regards, Peter >>> >> > From jeffhain at rocketmail.com Mon Jul 14 00:24:46 2014 From: jeffhain at rocketmail.com (Jeff Hain) Date: Mon, 14 Jul 2014 01:24:46 +0100 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53C2A4EB.4000204@gmail.com> References: <53B57E16.5020802@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC6506.3060308@oracle.com> <53BC6640.9020508@gmail.com> <53BC6B6F.6000709@oracle.com> <53BC73D7.7020900@gmail.com> <53BC8BF0.7000601@oracle.com> <53BCEDD4.6010906@gmail.com> <53BCF049.8090303@gmail.com> <53BDBF94.7040208@gmail.com> <53C03645.6090900@cs.oswego.edu> <53C15896.9070001@gmail.com> <53C17A81.2000200@gm! ail.com> <53C19E9C.7070306@oracle.com> <53C1B987.6030609@gmail.com> <1405250677.3551.YahooMailNeo@web172402.mail.ir2.yahoo.com> <53C2A4EB.4000204@gmail.com> Message-ID: <1405297486.34865.YahooMailNeo@web172405.mail.ir2.yahoo.com> >Can you post the benchmark source? Before the source, here are the time ranges runs were stabilizing in for lucky executions (using 1.7 for compiler compliance level, and win7 / core i7) : ???????? | original | peter7?? | peter7?? | peter8?? | peter8?? | ???????? |????????? |????????? | no loop? |????????? | no loop? | ---------+----------+----------+----------+----------+----------+ jdk7u51? | 0.56-59s | 0.66-68s | 0.62-64s | 0.60-63s | 0.70-74s | jdk8u20? | 0.54-58s | 0.64-66s | 0.58-60s | 0.58-61s | 0.73-76s | jdk9???? | 0.59-61s | 0.65-67s | 0.73-75s | 0.60-63s | 0.76-78s | => The no-loop version seems only better for jdk <= 8 and your webrev 07, ???? and for webrev 08, it seems actually (much) worse whatever the jdk. => jdk 8 looks faster than 7, but for some reason also faster than 9. public class IdentityHashMapPerf { ??? private static final int MAX_NBR_OF_MAPPINGS = 1*1000; ??? private static final int MAX_NBR_OF_CALLS = 100*1000*1000; ??? private static final int NBR_OF_RUNS = 10; ??? ??? public static void main(String[] args) { ??????? System.out.println(IdentityHashMapPerf.class.getSimpleName()+"..."); ??????? for (int k=0;k(), maxNbrOfCalls); ??????????? //bench_put(new IdentityHashMapPeter7(), maxNbrOfCalls); ??????????? //bench_put(new IdentityHashMapPeter7NoLoop(), maxNbrOfCalls); ??????????? //bench_put(new IdentityHashMapPeter8(), maxNbrOfCalls); ??????????? //bench_put(new IdentityHashMapPeter8NoLoop(), maxNbrOfCalls); ??????? } ??????? System.out.println("..."+IdentityHashMapPerf.class.getSimpleName()); ??? } ??? ??? private static void bench_put(Map map, int maxNbrOfCalls) { ??????? for (int k=0;k<2;k++) { ??????????? final Integer[] keys = newKeys(MAX_NBR_OF_MAPPINGS); ??????????? final int nbrOfClearAndPuts = maxNbrOfCalls/MAX_NBR_OF_MAPPINGS; ??????????? long a = System.nanoTime(); ??????????? { ??????????????? for (int cap=0;cap References: <53C00E62.20703@oracle.com> <53C02534.2040000@univ-mlv.fr> Message-ID: <53C364A6.5000600@oracle.com> On 12/07/2014 3:56 AM, Remi Forax wrote: > > On 07/11/2014 06:18 PM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8050052/webrev.00 >> https://bugs.openjdk.java.net/browse/JDK-8050052 > > I've found myself writing the very same code as > MethodHandleStatics.uncaughException several times > and I wonder if it should not be an instance method of Throwable. > Something like: > > public E rethrow(Function extends E> uncaughtHandler) { > if (this instanceof RuntimeException) { > throw (RuntimeException)this; > } > if (this instanceof Error) { > throw (Error)this; > } > return uncaughtHandler.apply(this); Rethrowing is one thing but what is this uncaughtHandler supposed to be doing? At this level you expect all these exceptions to be "uncaught" and propagate up. David ----- > } > > in that case, throw uncaughtException(ex) can be replaced by throw > ex.rethrow(::newInternalError); > > cheers, > R?mi > >> >> Numerous small code cleanups in java.lang.invoke package. >> >> Testing: jtreg, nashorn, octane w/ "-ea -esa" and >> COMPILE_THRESHOLD={0,30}. >> >> Reviewed-by: vlivanov, ? >> Contributed-by: john.r.rose at oracle.com >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From vladimir.x.ivanov at oracle.com Mon Jul 14 08:36:47 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 14 Jul 2014 12:36:47 +0400 Subject: [9] RFR (M): 8049555: Move varargsArray from sun.invoke.util package to java.lang.invoke In-Reply-To: <8D8621AE-3E36-430F-BD61-C1DD27FE9ABA@oracle.com> References: <53BE7F91.1010706@oracle.com> <781D8B86-B0CD-4102-B7F8-C3AC252E4BF3@oracle.com> <53BFBDAA.4070004@oracle.com> <53BFD109.7080502@oracle.com> <53BFD6AD.8070305@oracle.com> <8D8621AE-3E36-430F-BD61-C1DD27FE9ABA@oracle.com> Message-ID: <53C3969F.50804@oracle.com> Paul, Igor, thanks for review. Best regards, Vladimir Ivanov On 7/11/14 4:24 PM, Paul Sandoz wrote: > On Jul 11, 2014, at 2:21 PM, Vladimir Ivanov wrote: >> Igor, thanks for the hint! > > Yes, much better. > > >> Updated version: >> http://cr.openjdk.java.net/~vlivanov/8049555/webrev.01/ >> > > +1 > > Paul. From forax at univ-mlv.fr Mon Jul 14 08:39:53 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 14 Jul 2014 10:39:53 +0200 Subject: [9] RFR (M): 8050052: Small cleanups in java.lang.invoke code In-Reply-To: <53C364A6.5000600@oracle.com> References: <53C00E62.20703@oracle.com> <53C02534.2040000@univ-mlv.fr> <53C364A6.5000600@oracle.com> Message-ID: <53C39759.5080105@univ-mlv.fr> On 07/14/2014 07:03 AM, David Holmes wrote: > On 12/07/2014 3:56 AM, Remi Forax wrote: >> >> On 07/11/2014 06:18 PM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8050052/webrev.00 >>> https://bugs.openjdk.java.net/browse/JDK-8050052 >> >> I've found myself writing the very same code as >> MethodHandleStatics.uncaughException several times >> and I wonder if it should not be an instance method of Throwable. >> Something like: >> >> public E rethrow(Function> extends E> uncaughtHandler) { >> if (this instanceof RuntimeException) { >> throw (RuntimeException)this; >> } >> if (this instanceof Error) { >> throw (Error)this; >> } >> return uncaughtHandler.apply(this); > > Rethrowing is one thing but what is this uncaughtHandler supposed to > be doing? Sometimes there is a catch(Exception) or a catch(Throwable) that was already done in the code of an API you use so the exception kind you get is too broad, by example, using the reflection: try { return method.invoke(...); } catch(InvocationTargetException e) { throw e.getCause().rethrow(...); // here e.getCause() can store any Throwable } rethrow cleanly separate the checked exception from the unchecked ones, so the user can manage exceptions correctly. > > At this level you expect all these exceptions to be "uncaught" and > propagate up. I expect that either there is a dedicated exception, like SAXException for an XML parser, UndeclaredThrowableException for a reflect.Proxy, that can tunnel checked exceptions in the signature of the method that calls rethrow or that the user want to suppress the checked exception using by example an IOError to wrap an IOException. so I expect the code to be something like throw e.rethrow(SAXException::new); or throw e.rethrow(IOError::new); > > David > ----- R?mi > > >> } >> >> in that case, throw uncaughtException(ex) can be replaced by throw >> ex.rethrow(::newInternalError); >> >> cheers, >> R?mi >> >>> >>> Numerous small code cleanups in java.lang.invoke package. >>> >>> Testing: jtreg, nashorn, octane w/ "-ea -esa" and >>> COMPILE_THRESHOLD={0,30}. >>> >>> Reviewed-by: vlivanov, ? >>> Contributed-by: john.r.rose at oracle.com >>> >>> Thanks! >>> >>> Best regards, >>> Vladimir Ivanov >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> From claes.redestad at oracle.com Mon Jul 14 10:07:38 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 14 Jul 2014 12:07:38 +0200 Subject: RFR [9]: 8050142: Optimize java.util.Formatter Message-ID: <53C3ABEA.9080009@oracle.com> Hi, please review this patch which optimizes away some allocations from java.util.Formatter and achieve 1.1-1.3x speedups of micros targetting String.format. See bug for more details. webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.0 bug: https://bugs.openjdk.java.net/browse/JDK-8050142 Testing: JPRT, jtreg (java/lang/String, java/util/Formatter), SPECjbb2013 and microbenchmarks Thanks! /Claes From paul.sandoz at oracle.com Mon Jul 14 10:51:26 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 14 Jul 2014 12:51:26 +0200 Subject: Stream.concat In-Reply-To: <53C15719.6070105@univ-mlv.fr> References: <53C15719.6070105@univ-mlv.fr> Message-ID: On Jul 12, 2014, at 5:41 PM, Remi Forax wrote: > I was not able to find the answer to my question in the archive, > why Stream.concat is not implemented like this ? > > @SafeVarargs > public static Stream concat(Stream... streams) { > return Arrays.stream(streams).flatMap(Function.identity()); > } > Because the capabilities and characteristics of the streams are then lost e.g. in this case the splitting is governed by the number of streams passed in. The current implementation retains the splitting capabilities and merges characteristics from both streams. We kept it simpler for now with just two streams, but it should be possible to extend support with some additional complexity to say: concat(Stream a, Stream b, Stream... rest) A really simple layered implementation would be: return Stream.concat( Stream.concat(a, b), Stream.of(rest).reduce(Stream.empty(), Stream::concat)); If too many streams are concatenated then the stack can blow up when operating on the result. See: https://bugs.openjdk.java.net/browse/JDK-8025523 Paul. From forax at univ-mlv.fr Mon Jul 14 10:57:41 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 14 Jul 2014 12:57:41 +0200 Subject: Stream.concat In-Reply-To: References: <53C15719.6070105@univ-mlv.fr> Message-ID: <53C3B7A5.9000504@univ-mlv.fr> On 07/14/2014 12:51 PM, Paul Sandoz wrote: > On Jul 12, 2014, at 5:41 PM, Remi Forax wrote: > >> I was not able to find the answer to my question in the archive, >> why Stream.concat is not implemented like this ? >> >> @SafeVarargs >> public static Stream concat(Stream... streams) { >> return Arrays.stream(streams).flatMap(Function.identity()); >> } >> > Because the capabilities and characteristics of the streams are then lost e.g. in this case the splitting is governed by the number of streams passed in. it seems to be a limitation of flatMap in that case, no ? R?mi > > The current implementation retains the splitting capabilities and merges characteristics from both streams. We kept it simpler for now with just two streams, but it should be possible to extend support with some additional complexity to say: > > concat(Stream a, Stream b, Stream... rest) > > A really simple layered implementation would be: > > return Stream.concat( > Stream.concat(a, b), > Stream.of(rest).reduce(Stream.empty(), Stream::concat)); > > If too many streams are concatenated then the stack can blow up when operating on the result. See: > > https://bugs.openjdk.java.net/browse/JDK-8025523 > > Paul. From andrej.golovnin at gmail.com Mon Jul 14 11:08:14 2014 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Mon, 14 Jul 2014 13:08:14 +0200 Subject: RFR [9]: 8050142: Optimize java.util.Formatter In-Reply-To: <53C3ABEA.9080009@oracle.com> References: <53C3ABEA.9080009@oracle.com> Message-ID: Hi Claes, in the method Formatter$FormatSpecifier#justify(String) you can pre-calculate the capacity of the StringBuilder to avoid array copying, e.g. instead of 2931 StringBuilder sb = new StringBuilder(); use this one: 2931 StringBuilder sb = new StringBuilder(s.length() + sp); And in the method Formatter$FormatSpecifier#justify(StringBuilder) you can avoid creation of the StringBuilder object in the line 2956, e.g. instead of: 2956 StringBuilder tmp = new StringBuilder(sp); 2957 for (int i = 0; i < sp; i++) { 2958 tmp.append(' '); 2959 } 2960 sb.insert(0, tmp); you can write this: 2956 char[] tmp = new char[sp]; 2957 Arrays.fill(tmp, ' '); 2958 sb.insert(0, tmp); It's not a big improvement but maybe you can change the line 3781 exp.append("0").append(len - 1); to use the character-based API to append a single character. Best regards, Andrej Golovnin On Mon, Jul 14, 2014 at 12:07 PM, Claes Redestad wrote: > Hi, > > please review this patch which optimizes away some allocations from > java.util.Formatter and achieve 1.1-1.3x speedups of micros targetting > String.format. See bug for more details. > > webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.0 > bug: https://bugs.openjdk.java.net/browse/JDK-8050142 > > Testing: JPRT, jtreg (java/lang/String, java/util/Formatter), SPECjbb2013 > and microbenchmarks > > Thanks! > > /Claes > From peter.levart at gmail.com Mon Jul 14 11:25:10 2014 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 14 Jul 2014 13:25:10 +0200 Subject: RFR [9]: 8050142: Optimize java.util.Formatter In-Reply-To: <53C3ABEA.9080009@oracle.com> References: <53C3ABEA.9080009@oracle.com> Message-ID: <53C3BE16.3040300@gmail.com> On 07/14/2014 12:07 PM, Claes Redestad wrote: > Hi, > > please review this patch which optimizes away some allocations from > java.util.Formatter and achieve 1.1-1.3x speedups of micros targetting > String.format. See bug for more details. > > webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.0 > bug: https://bugs.openjdk.java.net/browse/JDK-8050142 > > Testing: JPRT, jtreg (java/lang/String, java/util/Formatter), > SPECjbb2013 and microbenchmarks > > Thanks! > > /Claes Hi Claes, Since justify() result is always appended to the resulting Appendable, you could merge the functionality and eliminate constructing intermediary StringBuilder altogether: http://cr.openjdk.java.net/~plevart/jdk9-dev/Formatter/webrev.01/ Regards, Peter From claes.redestad at oracle.com Mon Jul 14 11:26:59 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 14 Jul 2014 13:26:59 +0200 Subject: RFR [9]: 8050142: Optimize java.util.Formatter In-Reply-To: References: <53C3ABEA.9080009@oracle.com> Message-ID: <53C3BE83.4050605@oracle.com> Hi, good suggestions, I'll incorporate them. /Claes On 2014-07-14 13:08, Andrej Golovnin wrote: > Hi Claes, > > in the method Formatter$FormatSpecifier#justify(String) you can > pre-calculate the capacity of the StringBuilder to avoid array > copying, e.g. instead of > > 2931 StringBuilder sb = new StringBuilder(); > > use this one: > > 2931 StringBuilder sb = new StringBuilder(s.length() + sp); > > And in the method Formatter$FormatSpecifier#justify(StringBuilder) you > can avoid creation of the StringBuilder object in the line 2956, e.g. > instead of: > > 2956 StringBuilder tmp = new StringBuilder(sp); > 2957 for (int i = 0; i < sp; i++) { > 2958 tmp.append(' '); > 2959 } > 2960 sb.insert(0, tmp); > > you can write this: > > 2956 char[] tmp = new char[sp]; > 2957 Arrays.fill(tmp, ' '); > 2958 sb.insert(0, tmp); > > It's not a big improvement but maybe you can change the line > > 3781 exp.append("0").append(len - 1); > > to use the character-based API to append a single character. > > Best regards, > Andrej Golovnin > > On Mon, Jul 14, 2014 at 12:07 PM, Claes Redestad > > wrote: > > Hi, > > please review this patch which optimizes away some allocations > from java.util.Formatter and achieve 1.1-1.3x speedups of micros > targetting String.format. See bug for more details. > > webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.0 > > bug: https://bugs.openjdk.java.net/browse/JDK-8050142 > > Testing: JPRT, jtreg (java/lang/String, java/util/Formatter), > SPECjbb2013 and microbenchmarks > > Thanks! > > /Claes > > From claes.redestad at oracle.com Mon Jul 14 11:29:55 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 14 Jul 2014 13:29:55 +0200 Subject: RFR [9]: 8050142: Optimize java.util.Formatter In-Reply-To: <53C3BE16.3040300@gmail.com> References: <53C3ABEA.9080009@oracle.com> <53C3BE16.3040300@gmail.com> Message-ID: <53C3BF33.7020403@oracle.com> Hi Peter, On 2014-07-14 13:25, Peter Levart wrote: > On 07/14/2014 12:07 PM, Claes Redestad wrote: >> Hi, >> >> please review this patch which optimizes away some allocations from >> java.util.Formatter and achieve 1.1-1.3x speedups of micros >> targetting String.format. See bug for more details. >> >> webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.0 >> bug: https://bugs.openjdk.java.net/browse/JDK-8050142 >> >> Testing: JPRT, jtreg (java/lang/String, java/util/Formatter), >> SPECjbb2013 and microbenchmarks >> >> Thanks! >> >> /Claes > > Hi Claes, > > Since justify() result is always appended to the resulting Appendable, > you could merge the functionality and eliminate constructing > intermediary StringBuilder altogether: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/Formatter/webrev.01/ > Looks good, especially eliminating the need for two different append methods. I'll update based on this and other suggestions. /Claes > Regards, Peter From paul.sandoz at oracle.com Mon Jul 14 11:37:56 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 14 Jul 2014 13:37:56 +0200 Subject: Stream.concat In-Reply-To: <53C3B7A5.9000504@univ-mlv.fr> References: <53C15719.6070105@univ-mlv.fr> <53C3B7A5.9000504@univ-mlv.fr> Message-ID: On Jul 14, 2014, at 12:57 PM, Remi Forax wrote: > > On 07/14/2014 12:51 PM, Paul Sandoz wrote: >> On Jul 12, 2014, at 5:41 PM, Remi Forax wrote: >> >>> I was not able to find the answer to my question in the archive, >>> why Stream.concat is not implemented like this ? >>> >>> @SafeVarargs >>> public static Stream concat(Stream... streams) { >>> return Arrays.stream(streams).flatMap(Function.identity()); >>> } >>> >> Because the capabilities and characteristics of the streams are then lost e.g. in this case the splitting is governed by the number of streams passed in. > > it seems to be a limitation of flatMap in that case, no ? > That would be much harder to optimise since each element gets mapped to a Stream of 0 or more elements when the pipeline is executed. The operation has no "global" view of all the streams to concatenate as all it knows is a mapping function. At the moment flatMap is quite a simple and efficient stateless operation and i think it best it stays that way. e.g. imagine the case of streaming over the lines of a file and flatMapping each line to one or more words. Paul. From pavel.rappo at oracle.com Mon Jul 14 11:43:50 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Mon, 14 Jul 2014 12:43:50 +0100 Subject: RFR JDK-8048175: Remove redundant use of reflection on core classes from JNDI In-Reply-To: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> Message-ID: Hi everyone, Could you please review my change for JDK-8048175? http://cr.openjdk.java.net/~prappo/8048175/webrev.00/ Summary 1. com.sun.jndi.ldap.Connection imports both java.net.InetSocketAddress and javax.net.SocketFactory which are available since 1.4 2. com.sun.jndi.toolkit.corba.CorbaUtils defines 3 imports from java.rmi and java.rmi.CORBA. Justification: CorbaUtils is used by the com.sun.jndi.cosnaming package which resides in CORBA module. Which in turn has a dependency on RMI module. 3. com.sun.jndi.cosnaming.RemoteToCorba.getStateToBind method doesn't handle ClassNotFoundException internally. There's no need for that now (see 2). 4. com.sun.jndi.ldap.VersionHelper instantiates only the com.sun.jndi.ldap.VersionHelper12. Justification: the rudimentary test for jdk version is no longer needed as JNDI is a part of the platform and com.sun.jndi.ldap.VersionHelper11 is no longer available (at least since 1.3). All corresponding reflection usages have been removed. Thanks -Pavel From peter.levart at gmail.com Mon Jul 14 12:05:08 2014 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 14 Jul 2014 14:05:08 +0200 Subject: RFR [9]: 8050142: Optimize java.util.Formatter In-Reply-To: <53C3BF33.7020403@oracle.com> References: <53C3ABEA.9080009@oracle.com> <53C3BE16.3040300@gmail.com> <53C3BF33.7020403@oracle.com> Message-ID: <53C3C774.2020204@gmail.com> On 07/14/2014 01:29 PM, Claes Redestad wrote: > Hi Peter, > > On 2014-07-14 13:25, Peter Levart wrote: >> On 07/14/2014 12:07 PM, Claes Redestad wrote: >>> Hi, >>> >>> please review this patch which optimizes away some allocations from >>> java.util.Formatter and achieve 1.1-1.3x speedups of micros >>> targetting String.format. See bug for more details. >>> >>> webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.0 >>> bug: https://bugs.openjdk.java.net/browse/JDK-8050142 >>> >>> Testing: JPRT, jtreg (java/lang/String, java/util/Formatter), >>> SPECjbb2013 and microbenchmarks >>> >>> Thanks! >>> >>> /Claes >> >> Hi Claes, >> >> Since justify() result is always appended to the resulting >> Appendable, you could merge the functionality and eliminate >> constructing intermediary StringBuilder altogether: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/Formatter/webrev.01/ >> > Looks good, especially eliminating the need for two different append > methods. I'll update based on this and other suggestions. > > /Claes >> Regards, Peter > Hi Claes, If you're in a really hyper-optimizing mood, you could also eliminate construction of ArrayList in parse(): http://cr.openjdk.java.net/~plevart/jdk9-dev/Formatter/webrev.02/ Regards, Peter From pdoubleya at gmail.com Mon Jul 14 12:12:07 2014 From: pdoubleya at gmail.com (Patrick Wright) Date: Mon, 14 Jul 2014 14:12:07 +0200 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <1405297486.34865.YahooMailNeo@web172405.mail.ir2.yahoo.com> References: <53B57E16.5020802@oracle.com> <53BBC40E.6050305@gmail.com> <53BBCAE1.7050702@gmail.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC6506.3060308@oracle.com> <53BC6640.9020508@gmail.com> <53BC6B6F.6000709@oracle.com> <53BC73D7.7020900@gmail.com> <53BC8BF0.7000601@oracle.com> <53BCEDD4.6010906@gmail.com> <53BCF049.8090303@gmail.com> <53BDBF94.7040208@gmail.com> <53C03645.6090900@cs.oswego.edu> <53C15896.9070001@gmail.com> <53C19E9C.7070306@oracle.com> <53C1B987.6030609@gmail.com> <1405250677.3551.YahooMailNeo@web172402.mail.ir2.yahoo.com> <53C2A4EB.4000204@gmail.com> <1405297486.34865.YahooMailNeo@web172405.mail.ir2.yahoo.com> Message-ID: Hi been watching this fascinating discussion - seeing Jeff's benchmark today, was wondering if there isn't already at least one benchmark written with JMH? Wouldn't it make sense to make that part of the submission, as a standard practice in refactoring like this? Regards, Patrick On Mon, Jul 14, 2014 at 2:24 AM, Jeff Hain wrote: > > > >Can you post the benchmark source? > > Before the source, here are the time ranges runs were stabilizing in > for lucky executions (using 1.7 for compiler compliance level, and > win7 / core i7) : > > | original | peter7 | peter7 | peter8 | peter8 | > | | | no loop | | no loop | > ---------+----------+----------+----------+----------+----------+ > jdk7u51 | 0.56-59s | 0.66-68s | 0.62-64s | 0.60-63s | 0.70-74s | > jdk8u20 | 0.54-58s | 0.64-66s | 0.58-60s | 0.58-61s | 0.73-76s | > jdk9 | 0.59-61s | 0.65-67s | 0.73-75s | 0.60-63s | 0.76-78s | > > => The no-loop version seems only better for jdk <= 8 and your webrev 07, > and for webrev 08, it seems actually (much) worse whatever the jdk. > => jdk 8 looks faster than 7, but for some reason also faster than 9. > > > public class IdentityHashMapPerf { > private static final int MAX_NBR_OF_MAPPINGS = 1*1000; > private static final int MAX_NBR_OF_CALLS = 100*1000*1000; > private static final int NBR_OF_RUNS = 10; > > public static void main(String[] args) { > > System.out.println(IdentityHashMapPerf.class.getSimpleName()+"..."); > for (int k=0;k // Quick run for code discovery for k = 0. > final int maxNbrOfCalls = (k == 0) ? MAX_NBR_OF_MAPPINGS > : MAX_NBR_OF_CALLS; > bench_put(new IdentityHashMap(), > maxNbrOfCalls); > //bench_put(new IdentityHashMapPeter7(), > maxNbrOfCalls); > //bench_put(new IdentityHashMapPeter7NoLoop Integer>(), maxNbrOfCalls); > //bench_put(new IdentityHashMapPeter8(), > maxNbrOfCalls); > //bench_put(new IdentityHashMapPeter8NoLoop Integer>(), maxNbrOfCalls); > } > > System.out.println("..."+IdentityHashMapPerf.class.getSimpleName()); > } > > private static void bench_put(Map map, int > maxNbrOfCalls) { > for (int k=0;k<2;k++) { > final Integer[] keys = newKeys(MAX_NBR_OF_MAPPINGS); > final int nbrOfClearAndPuts = > maxNbrOfCalls/MAX_NBR_OF_MAPPINGS; > long a = System.nanoTime(); > { > for (int cap=0;cap map.clear(); > for (int i=0;i final Integer kv = keys[i]; > map.put(kv, kv); > } > if (map.size() != MAX_NBR_OF_MAPPINGS) { > throw new AssertionError("anti optim"); > } > } > } > long b = System.nanoTime(); > System.out.println(nbrOfClearAndPuts+" * "+MAX_NBR_OF_MAPPINGS > +" "+map.getClass().getSimpleName()+".put(,) took > "+((b-a)/1e9)+" s"); > } > } > > private static Integer[] newKeys(int size) { > final Integer[] keys = new Integer[size]; > for (int i=0;i keys[i] = i; > } > return keys; > > } > } > > > -Jeff > From claes.redestad at oracle.com Mon Jul 14 12:17:16 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 14 Jul 2014 14:17:16 +0200 Subject: RFR [9]: 8050142: Optimize java.util.Formatter In-Reply-To: <53C3C774.2020204@gmail.com> References: <53C3ABEA.9080009@oracle.com> <53C3BE16.3040300@gmail.com> <53C3BF33.7020403@oracle.com> <53C3C774.2020204@gmail.com> Message-ID: <53C3CA4C.4010903@oracle.com> Hi Peter, On 2014-07-14 14:05, Peter Levart wrote: > On 07/14/2014 01:29 PM, Claes Redestad wrote: >> Hi Peter, >> >> On 2014-07-14 13:25, Peter Levart wrote: >>> On 07/14/2014 12:07 PM, Claes Redestad wrote: >>>> Hi, >>>> >>>> please review this patch which optimizes away some allocations >>>> from java.util.Formatter and achieve 1.1-1.3x speedups of micros >>>> targetting String.format. See bug for more details. >>>> >>>> webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.0 >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8050142 >>>> >>>> Testing: JPRT, jtreg (java/lang/String, java/util/Formatter), >>>> SPECjbb2013 and microbenchmarks >>>> >>>> Thanks! >>>> >>>> /Claes >>> >>> Hi Claes, >>> >>> Since justify() result is always appended to the resulting >>> Appendable, you could merge the functionality and eliminate >>> constructing intermediary StringBuilder altogether: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Formatter/webrev.01/ >>> >> Looks good, especially eliminating the need for two different append >> methods. I'll update based on this and other suggestions. >> >> /Claes >>> Regards, Peter >> > Hi Claes, > > If you're in a really hyper-optimizing mood, you could also eliminate > construction of ArrayList in parse(): > > http://cr.openjdk.java.net/~plevart/jdk9-dev/Formatter/webrev.02/ > Have you measured this to have a real effect? I'm not convinced it would matter enough to warrant the extra complexity of turning FormatString into a linked list. I feel this patch is already a bit saturated with different small optimizations - maybe should deal with this in a new RFE? /Claes > Regards, Peter > From claes.redestad at oracle.com Mon Jul 14 12:23:13 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 14 Jul 2014 14:23:13 +0200 Subject: RFR [9]: 8050142: Optimize java.util.Formatter In-Reply-To: <53C3BF33.7020403@oracle.com> References: <53C3ABEA.9080009@oracle.com> <53C3BE16.3040300@gmail.com> <53C3BF33.7020403@oracle.com> Message-ID: <53C3CBB1.9070305@oracle.com> Hi again, updated webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.1 changes: - specify capacity on line 2931 as suggested by Andrej Golovnin - exp.append("0") -> exp.append('0') on line 3781 - merged append+justify into appendJustified as suggested by Peter Levart - replaced the reoccuring pattern of appending a number of zeros into a call to trailingZeros performance difference seemingly at noise levels in micros, but bonus to readability and Formatter*.class-files are now a total of 246 bytes smaller /Claes On 2014-07-14 13:29, Claes Redestad wrote: > Hi Peter, > > On 2014-07-14 13:25, Peter Levart wrote: >> On 07/14/2014 12:07 PM, Claes Redestad wrote: >>> Hi, >>> >>> please review this patch which optimizes away some allocations from >>> java.util.Formatter and achieve 1.1-1.3x speedups of micros >>> targetting String.format. See bug for more details. >>> >>> webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.0 >>> bug: https://bugs.openjdk.java.net/browse/JDK-8050142 >>> >>> Testing: JPRT, jtreg (java/lang/String, java/util/Formatter), >>> SPECjbb2013 and microbenchmarks >>> >>> Thanks! >>> >>> /Claes >> >> Hi Claes, >> >> Since justify() result is always appended to the resulting >> Appendable, you could merge the functionality and eliminate >> constructing intermediary StringBuilder altogether: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/Formatter/webrev.01/ >> > Looks good, especially eliminating the need for two different append > methods. I'll update based on this and other suggestions. > > /Claes >> Regards, Peter > From peter.levart at gmail.com Mon Jul 14 12:44:48 2014 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 14 Jul 2014 14:44:48 +0200 Subject: RFR [9]: 8050142: Optimize java.util.Formatter In-Reply-To: <53C3CA4C.4010903@oracle.com> References: <53C3ABEA.9080009@oracle.com> <53C3BE16.3040300@gmail.com> <53C3BF33.7020403@oracle.com> <53C3C774.2020204@gmail.com> <53C3CA4C.4010903@oracle.com> Message-ID: <53C3D0C0.6030005@gmail.com> On 07/14/2014 02:17 PM, Claes Redestad wrote: >> If you're in a really hyper-optimizing mood, you could also eliminate >> construction of ArrayList in parse(): >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/Formatter/webrev.02/ >> > > Have you measured this to have a real effect? I'm not convinced it > would matter enough to warrant the extra complexity of turning > FormatString into a linked list. I feel this patch is already a bit > saturated with different small optimizations - maybe should deal with > this in a new RFE? > > /Claes You may be right. I agree that it's already pretty saturated patch. Maybe later if benchmarks show it's worth it. Regards, Peter From paul.sandoz at oracle.com Mon Jul 14 12:57:54 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 14 Jul 2014 14:57:54 +0200 Subject: [9] RFR (M): 8050052: Small cleanups in java.lang.invoke code In-Reply-To: <53C00E62.20703@oracle.com> References: <53C00E62.20703@oracle.com> Message-ID: On Jul 11, 2014, at 6:18 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8050052/webrev.00 > https://bugs.openjdk.java.net/browse/JDK-8050052 > > Numerous small code cleanups in java.lang.invoke package. > > Testing: jtreg, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}. > > Reviewed-by: vlivanov, ? > Contributed-by: john.r.rose at oracle.com > Looks ok, could not find anything obviously wrong. Paul. From ivan.gerasimov at oracle.com Mon Jul 14 13:02:15 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 14 Jul 2014 17:02:15 +0400 Subject: RFR [9]: 8050142: Optimize java.util.Formatter In-Reply-To: <53C3CBB1.9070305@oracle.com> References: <53C3ABEA.9080009@oracle.com> <53C3BE16.3040300@gmail.com> <53C3BF33.7020403@oracle.com> <53C3CBB1.9070305@oracle.com> Message-ID: <53C3D4D7.3040204@oracle.com> A very minor one: 2704 if (Character.isUpperCase(conv)) 2705 f.add(Flags.UPPERCASE); 2706 c = Character.toLowerCase(conv); maybe 2704 if (Character.isUpperCase(conv)) { 2705 f.add(Flags.UPPERCASE); 2706 c = Character.toLowerCase(conv); } Sincerely yours, Ivan On 14.07.2014 16:23, Claes Redestad wrote: > Hi again, > > updated webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.1 > > changes: > - specify capacity on line 2931 as suggested by Andrej Golovnin > - exp.append("0") -> exp.append('0') on line 3781 > - merged append+justify into appendJustified as suggested by Peter > Levart > - replaced the reoccuring pattern of appending a number of zeros into > a call to trailingZeros > > performance difference seemingly at noise levels in micros, but bonus > to readability and Formatter*.class-files are now a total of 246 bytes > smaller > > /Claes > > On 2014-07-14 13:29, Claes Redestad wrote: >> Hi Peter, >> >> On 2014-07-14 13:25, Peter Levart wrote: >>> On 07/14/2014 12:07 PM, Claes Redestad wrote: >>>> Hi, >>>> >>>> please review this patch which optimizes away some allocations >>>> from java.util.Formatter and achieve 1.1-1.3x speedups of micros >>>> targetting String.format. See bug for more details. >>>> >>>> webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.0 >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8050142 >>>> >>>> Testing: JPRT, jtreg (java/lang/String, java/util/Formatter), >>>> SPECjbb2013 and microbenchmarks >>>> >>>> Thanks! >>>> >>>> /Claes >>> >>> Hi Claes, >>> >>> Since justify() result is always appended to the resulting >>> Appendable, you could merge the functionality and eliminate >>> constructing intermediary StringBuilder altogether: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Formatter/webrev.01/ >>> >> Looks good, especially eliminating the need for two different append >> methods. I'll update based on this and other suggestions. >> >> /Claes >>> Regards, Peter >> > > > From andrej.golovnin at gmail.com Mon Jul 14 13:09:07 2014 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Mon, 14 Jul 2014 15:09:07 +0200 Subject: RFR [9]: 8050142: Optimize java.util.Formatter In-Reply-To: <53C3CBB1.9070305@oracle.com> References: <53C3ABEA.9080009@oracle.com> <53C3BE16.3040300@gmail.com> <53C3BF33.7020403@oracle.com> <53C3CBB1.9070305@oracle.com> Message-ID: Hi Claes, it looks good. And I have one minor improvement. Take look at the following lines of the method FormatSpecifier#hexDouble(double, int): 3532 // Get exponent and append at the end. 3533 String exp = res.substring(idx + 1); 3534 int iexp = Integer.parseInt(exp) -54; 3535 return res.substring(0, idx) + "p" 3536 + Integer.toString(iexp); The lines 3535-3536 are translated by the compiler to: new StringBuilder().append(res.substring(0, idx)).append("p").append(Integer.toString(iexp)).toString(); If we rewrite it to use StringBuilder, we can avoid creation of intermediate String objects, e.g.: 3535 return new StringBuilder().append(res, 0, idx).append('p') 3536 .append(iexp).toString(); But I'm not sure how common is the usage of #hexDouble-method. Maybe this change is not worth it. Best regards, Andrej Golovnin On Mon, Jul 14, 2014 at 2:23 PM, Claes Redestad wrote: > Hi again, > > updated webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.1 > > changes: > - specify capacity on line 2931 as suggested by Andrej Golovnin > - exp.append("0") -> exp.append('0') on line 3781 > - merged append+justify into appendJustified as suggested by Peter Levart > - replaced the reoccuring pattern of appending a number of zeros into a > call to trailingZeros > > performance difference seemingly at noise levels in micros, but bonus to > readability and Formatter*.class-files are now a total of 246 bytes smaller > > /Claes > > > On 2014-07-14 13:29, Claes Redestad wrote: > >> Hi Peter, >> >> On 2014-07-14 13:25, Peter Levart wrote: >> >>> On 07/14/2014 12:07 PM, Claes Redestad wrote: >>> >>>> Hi, >>>> >>>> please review this patch which optimizes away some allocations from >>>> java.util.Formatter and achieve 1.1-1.3x speedups of micros targetting >>>> String.format. See bug for more details. >>>> >>>> webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.0 >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8050142 >>>> >>>> Testing: JPRT, jtreg (java/lang/String, java/util/Formatter), >>>> SPECjbb2013 and microbenchmarks >>>> >>>> Thanks! >>>> >>>> /Claes >>>> >>> >>> Hi Claes, >>> >>> Since justify() result is always appended to the resulting Appendable, >>> you could merge the functionality and eliminate constructing intermediary >>> StringBuilder altogether: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Formatter/webrev.01/ >>> >>> Looks good, especially eliminating the need for two different append >> methods. I'll update based on this and other suggestions. >> >> /Claes >> >>> Regards, Peter >>> >> >> > From peter.levart at gmail.com Mon Jul 14 13:14:46 2014 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 14 Jul 2014 15:14:46 +0200 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <1405297486.34865.YahooMailNeo@web172405.mail.ir2.yahoo.com> References: <53B57E16.5020802@oracle.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC6506.3060308@oracle.com> <53BC6640.9020508@gmail.com> <53BC6B6F.6000709@oracle.com> <53BC73D7.7020900@gmail.com> <53BC8BF0.7000601@oracle.com> <53BCEDD4.6010906@gmail.com> <53BCF049.8090303@gmail.com> <53BDBF94.7040208@gmail.com> <53C03645.6090900@cs.oswego.edu> <53C15896.9070001@gmail.com> <53C17A81.2000200@gm! ail.com> <53C19E9C.7070306@oracle.com> <53C1B987.6030609@gmail.com> <1405250677.3551.YahooMailNeo@web172402.mail.ir2.yahoo.com> <53C2A4EB.4000204@gmail.com> <1405297486.34865.YahooMailNeo@web172405.mail.ir2.yahoo.com> Message-ID: <53C3D7C6.1080205@gmail.com> Hi Jeff, Home grown loops are not the best way of micro-benchmarking (have done it myself and learned it). JIT can sometimes optimize the code so aggressively that performance differences you obtain from such benchmarks just show that your concrete program can be optimized better and not that an average program using some function you are trying to measure can run faster too. I suggest you try to express your benchmark in a tried framework like JMH: http://openjdk.java.net/projects/code-tools/jmh/ In particular I suggest studying included samples. Regards, Peter On 07/14/2014 02:24 AM, Jeff Hain wrote: > >> Can you post the benchmark source? > Before the source, here are the time ranges runs were stabilizing in > for lucky executions (using 1.7 for compiler compliance level, and > win7 / core i7) : > > | original | peter7 | peter7 | peter8 | peter8 | > | | | no loop | | no loop | > ---------+----------+----------+----------+----------+----------+ > jdk7u51 | 0.56-59s | 0.66-68s | 0.62-64s | 0.60-63s | 0.70-74s | > jdk8u20 | 0.54-58s | 0.64-66s | 0.58-60s | 0.58-61s | 0.73-76s | > jdk9 | 0.59-61s | 0.65-67s | 0.73-75s | 0.60-63s | 0.76-78s | > > => The no-loop version seems only better for jdk <= 8 and your webrev 07, > and for webrev 08, it seems actually (much) worse whatever the jdk. > => jdk 8 looks faster than 7, but for some reason also faster than 9. > > > public class IdentityHashMapPerf { > private static final int MAX_NBR_OF_MAPPINGS = 1*1000; > private static final int MAX_NBR_OF_CALLS = 100*1000*1000; > private static final int NBR_OF_RUNS = 10; > > public static void main(String[] args) { > System.out.println(IdentityHashMapPerf.class.getSimpleName()+"..."); > for (int k=0;k // Quick run for code discovery for k = 0. > final int maxNbrOfCalls = (k == 0) ? MAX_NBR_OF_MAPPINGS > : MAX_NBR_OF_CALLS; > bench_put(new IdentityHashMap(), maxNbrOfCalls); > //bench_put(new IdentityHashMapPeter7(), maxNbrOfCalls); > //bench_put(new IdentityHashMapPeter7NoLoop(), maxNbrOfCalls); > //bench_put(new IdentityHashMapPeter8(), maxNbrOfCalls); > //bench_put(new IdentityHashMapPeter8NoLoop(), maxNbrOfCalls); > } > System.out.println("..."+IdentityHashMapPerf.class.getSimpleName()); > } > > private static void bench_put(Map map, int maxNbrOfCalls) { > for (int k=0;k<2;k++) { > final Integer[] keys = newKeys(MAX_NBR_OF_MAPPINGS); > final int nbrOfClearAndPuts = maxNbrOfCalls/MAX_NBR_OF_MAPPINGS; > long a = System.nanoTime(); > { > for (int cap=0;cap map.clear(); > for (int i=0;i final Integer kv = keys[i]; > map.put(kv, kv); > } > if (map.size() != MAX_NBR_OF_MAPPINGS) { > throw new AssertionError("anti optim"); > } > } > } > long b = System.nanoTime(); > System.out.println(nbrOfClearAndPuts+" * "+MAX_NBR_OF_MAPPINGS > +" "+map.getClass().getSimpleName()+".put(,) took "+((b-a)/1e9)+" s"); > } > } > > private static Integer[] newKeys(int size) { > final Integer[] keys = new Integer[size]; > for (int i=0;i keys[i] = i; > } > return keys; > > } > } > > > -Jeff From paul.sandoz at oracle.com Mon Jul 14 13:34:07 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 14 Jul 2014 15:34:07 +0200 Subject: [9] RFR (M): 8050053: Improve caching of different invokers In-Reply-To: <53C01252.4070302@oracle.com> References: <53C01252.4070302@oracle.com> Message-ID: On Jul 11, 2014, at 6:35 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8050053/webrev.00 > https://bugs.openjdk.java.net/browse/JDK-8050053 > > Improve sharing of different invokers: basic, generic & exact invokers, uninitialized call site invoker and NamedFunction invoker are changed. > > Testing: jdk/java/lang/invoke, nashorn, octane w/ "-ea -esa". > > Reviewed-by: vlivanov, ? > Contributed-by: john.r.rose at oracle.com > Looks ok, Paul. From vladimir.x.ivanov at oracle.com Mon Jul 14 13:40:17 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 14 Jul 2014 17:40:17 +0400 Subject: [9] RFR (M): 8050052: Small cleanups in java.lang.invoke code In-Reply-To: References: <53C00E62.20703@oracle.com> Message-ID: <53C3DDC1.4090307@oracle.com> Paul, thanks! Small update: http://cr.openjdk.java.net/~vlivanov/8050052/prepared_forms/ Updated version: http://cr.openjdk.java.net/~vlivanov/8050052//webrev.01/ Best regards, Vladimir Ivanov On 7/14/14 4:57 PM, Paul Sandoz wrote: > > On Jul 11, 2014, at 6:18 PM, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vlivanov/8050052/webrev.00 >> https://bugs.openjdk.java.net/browse/JDK-8050052 >> >> Numerous small code cleanups in java.lang.invoke package. >> >> Testing: jtreg, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}. >> >> Reviewed-by: vlivanov, ? >> Contributed-by: john.r.rose at oracle.com >> > > Looks ok, could not find anything obviously wrong. > > Paul. > From vladimir.x.ivanov at oracle.com Mon Jul 14 13:43:06 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 14 Jul 2014 17:43:06 +0400 Subject: [9] RFR (M): 8050053: Improve caching of different invokers In-Reply-To: References: <53C01252.4070302@oracle.com> Message-ID: <53C3DE6A.6010204@oracle.com> Thank you, Paul. Best regards, Vladimir Ivanov On 7/14/14 5:34 PM, Paul Sandoz wrote: > On Jul 11, 2014, at 6:35 PM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8050053/webrev.00 >> https://bugs.openjdk.java.net/browse/JDK-8050053 >> >> Improve sharing of different invokers: basic, generic & exact invokers, uninitialized call site invoker and NamedFunction invoker are changed. >> >> Testing: jdk/java/lang/invoke, nashorn, octane w/ "-ea -esa". >> >> Reviewed-by: vlivanov, ? >> Contributed-by: john.r.rose at oracle.com >> > > Looks ok, > Paul. > > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From claes.redestad at oracle.com Mon Jul 14 13:58:53 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 14 Jul 2014 15:58:53 +0200 Subject: RFR [9]: 8050142: Optimize java.util.Formatter In-Reply-To: References: <53C3ABEA.9080009@oracle.com> <53C3BE16.3040300@gmail.com> <53C3BF33.7020403@oracle.com> <53C3CBB1.9070305@oracle.com> Message-ID: <53C3E21D.9010404@oracle.com> Hi Andrej, while the change seems reasonable, I can't find any usage of %a/%A in the JDK and haven't even covered it in my micros. :-) Also, it could be further improved with 8041972 to turn: 3533 String exp = res.substring(idx + 1); 3534 int iexp = Integer.parseInt(exp) -54; 3533 int exp = Integer.parseInt(res, 10, idx + 1); I've planned to file a follow-on RFE to incorporate improvements made possible by 8041972 (like the one above); maybe we should roll this suggestion into that follow-up and add some micros to measure that we're actually improving? /Claes On 07/14/2014 03:09 PM, Andrej Golovnin wrote: > Hi Claes, > > it looks good. And I have one minor improvement. Take look at the > following lines of the method FormatSpecifier#hexDouble(double, int): > > 3532 // Get exponent and append at the end. > 3533 String exp = res.substring(idx + 1); > 3534 int iexp = Integer.parseInt(exp) -54; > 3535 return res.substring(0, idx) + "p" > 3536 + Integer.toString(iexp); > > The lines 3535-3536 are translated by the compiler to: > > new StringBuilder().append(res.substring(0, > idx)).append("p").append(Integer.toString(iexp)).toString(); > > If we rewrite it to use StringBuilder, we can avoid creation of > intermediate String objects, e.g.: > > 3535 return new > StringBuilder().append(res, 0, idx).append('p') > 3536 .append(iexp).toString(); > > But I'm not sure how common is the usage of #hexDouble-method. Maybe > this change is not worth it. > > Best regards, > Andrej Golovnin > > > > On Mon, Jul 14, 2014 at 2:23 PM, Claes Redestad > > wrote: > > Hi again, > > updated webrev: > http://cr.openjdk.java.net/~redestad/8050142/webrev.1 > > > changes: > - specify capacity on line 2931 as suggested by Andrej Golovnin > - exp.append("0") -> exp.append('0') on line 3781 > - merged append+justify into appendJustified as suggested by > Peter Levart > - replaced the reoccuring pattern of appending a number of zeros > into a call to trailingZeros > > performance difference seemingly at noise levels in micros, but > bonus to readability and Formatter*.class-files are now a total of > 246 bytes smaller > > /Claes > > > On 2014-07-14 13:29, Claes Redestad wrote: > > Hi Peter, > > On 2014-07-14 13:25, Peter Levart wrote: > > On 07/14/2014 12:07 PM, Claes Redestad wrote: > > Hi, > > please review this patch which optimizes away some > allocations from java.util.Formatter and achieve > 1.1-1.3x speedups of micros targetting String.format. > See bug for more details. > > webrev: > http://cr.openjdk.java.net/~redestad/8050142/webrev.0 > > bug: https://bugs.openjdk.java.net/browse/JDK-8050142 > > Testing: JPRT, jtreg (java/lang/String, > java/util/Formatter), SPECjbb2013 and microbenchmarks > > Thanks! > > /Claes > > > Hi Claes, > > Since justify() result is always appended to the resulting > Appendable, you could merge the functionality and > eliminate constructing intermediary StringBuilder altogether: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/Formatter/webrev.01/ > > > Looks good, especially eliminating the need for two different > append methods. I'll update based on this and other suggestions. > > /Claes > > Regards, Peter > > > > From vladimir.x.ivanov at oracle.com Mon Jul 14 14:04:39 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 14 Jul 2014 18:04:39 +0400 Subject: [9] RFR (M): 8050166: Get rid of some package-private methods on arguments in j.l.i.MethodHandle Message-ID: <53C3E377.3050603@oracle.com> http://cr.openjdk.java.net/~vlivanov/8050166/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8050166 Get rid of the following methods in j.l.i.MethodHandle: * convertArguments(MethodType newType) * bindArgument(int pos, BasicType basicType, Object value) * bindReceiver(Object receiver) * dropArguments(MethodType srcType, int pos, int drops) * permuteArguments(MethodType newType, int[] reorder) Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}. Thanks! Best regards, Vladimir Ivanov From claes.redestad at oracle.com Mon Jul 14 14:21:03 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 14 Jul 2014 16:21:03 +0200 Subject: RFR [9]: 8050142: Optimize java.util.Formatter In-Reply-To: <53C3D4D7.3040204@oracle.com> References: <53C3ABEA.9080009@oracle.com> <53C3BE16.3040300@gmail.com> <53C3BF33.7020403@oracle.com> <53C3CBB1.9070305@oracle.com> <53C3D4D7.3040204@oracle.com> Message-ID: <53C3E74F.8010900@oracle.com> Yes, might be worth addressing just for correctness/readability. /Claes On 07/14/2014 03:02 PM, Ivan Gerasimov wrote: > A very minor one: > 2704 if (Character.isUpperCase(conv)) > 2705 f.add(Flags.UPPERCASE); > 2706 c = Character.toLowerCase(conv); > > maybe > > 2704 if (Character.isUpperCase(conv)) { > 2705 f.add(Flags.UPPERCASE); > 2706 c = Character.toLowerCase(conv); > } > > Sincerely yours, > Ivan > > > On 14.07.2014 16:23, Claes Redestad wrote: >> Hi again, >> >> updated webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.1 >> >> changes: >> - specify capacity on line 2931 as suggested by Andrej Golovnin >> - exp.append("0") -> exp.append('0') on line 3781 >> - merged append+justify into appendJustified as suggested by Peter >> Levart >> - replaced the reoccuring pattern of appending a number of zeros >> into a call to trailingZeros >> >> performance difference seemingly at noise levels in micros, but >> bonus to readability and Formatter*.class-files are now a total of >> 246 bytes smaller >> >> /Claes >> >> On 2014-07-14 13:29, Claes Redestad wrote: >>> Hi Peter, >>> >>> On 2014-07-14 13:25, Peter Levart wrote: >>>> On 07/14/2014 12:07 PM, Claes Redestad wrote: >>>>> Hi, >>>>> >>>>> please review this patch which optimizes away some allocations >>>>> from java.util.Formatter and achieve 1.1-1.3x speedups of micros >>>>> targetting String.format. See bug for more details. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.0 >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8050142 >>>>> >>>>> Testing: JPRT, jtreg (java/lang/String, java/util/Formatter), >>>>> SPECjbb2013 and microbenchmarks >>>>> >>>>> Thanks! >>>>> >>>>> /Claes >>>> >>>> Hi Claes, >>>> >>>> Since justify() result is always appended to the resulting >>>> Appendable, you could merge the functionality and eliminate >>>> constructing intermediary StringBuilder altogether: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Formatter/webrev.01/ >>>> >>> Looks good, especially eliminating the need for two different append >>> methods. I'll update based on this and other suggestions. >>> >>> /Claes >>>> Regards, Peter >>> >> >> >> > From vladimir.x.ivanov at oracle.com Mon Jul 14 14:37:47 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 14 Jul 2014 18:37:47 +0400 Subject: [9] RFR (S) 8050173: Generalize BMH.copyWith API to all method handles Message-ID: <53C3EB3B.8080103@oracle.com> http://cr.openjdk.java.net/~vlivanov/8050173/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8050173 Added j.l.i.MethodHandle.copyWith(MethodType, LambdaForm) and provided implementation for all subclasses. Also, some cleanups: * rewrote MH.viewAsType on top of MH.copyWith; * extended MH.viewAsType to do strict checks w/ assertions turned on (new parameter: boolean strict); * extended MT.isViewableAs to accept both interface preserving and interface erasing conversions (new parameter: boolean keepInterfaces). Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}. Reviewed-by: vlivanov, ? Contributed-by: john.r.rose at oracle.com Thanks! Best regards, Vladimir Ivanov From sean.mullan at oracle.com Mon Jul 14 14:44:18 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 14 Jul 2014 10:44:18 -0400 Subject: ThreadLocalRandom clinit troubles In-Reply-To: References: <53A29DC5.1030605@oracle.com> <53A3FA72.3060706@gmail.com> <53A418F2.3080201@gmail.com> <53A43055.5070803@oracle.com> <53A43EF3.8000206@gmail.com> <53A44C3A.6000607@oracle.com> <53A98525.9080908@gmail.com> <53A9EF29.7030208@gmail.com> <53AB09E5.9070303@gmail.com> Message-ID: <53C3ECC2.8040202@oracle.com> I don't see a pointer to the webrev/patch -- did you forget to include it? --Sean On 07/11/2014 07:33 PM, Martin Buchholz wrote: > Thanks to Peter for digging into the secure seed generator classes and > coming up with a patch. Openjdk security folks, please review. I confess > to getting lost whenever I try to orient myself in the twisty maze of seed > generator implementation files. > > Anyways, it seems important to have prngs like ThreadLocalRandom be able to > get a few bits of seed entropy without loading hundreds of classes and > without occupying any file descriptors permanently. Perhaps at Google we > will go back to writing some simple non-portable startup code to read > /dev/urandom until openjdk security team comes up with a more principled > solution (but one that doesn't drag in too much machinery). > From vladimir.x.ivanov at oracle.com Mon Jul 14 14:47:23 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 14 Jul 2014 18:47:23 +0400 Subject: [9] RFR (XS): 8050174: Support overriding of isInvokeSpecial flag in WrappedMember Message-ID: <53C3ED7B.6070702@oracle.com> http://cr.openjdk.java.net/~vlivanov/8050174/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8050174 Support overriding of isInvokeSpecial flag in WrappedMember. Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}. Reviewed-by: vlivanov, ? Contributed-by: john.r.rose at oracle.com Thanks! Best regards, Vladimir Ivanov From forax at univ-mlv.fr Mon Jul 14 15:00:32 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 14 Jul 2014 17:00:32 +0200 Subject: Stream.concat In-Reply-To: References: <53C15719.6070105@univ-mlv.fr> <53C3B7A5.9000504@univ-mlv.fr> Message-ID: <53C3F090.90306@univ-mlv.fr> On 07/14/2014 01:37 PM, Paul Sandoz wrote: > On Jul 14, 2014, at 12:57 PM, Remi Forax wrote: > >> On 07/14/2014 12:51 PM, Paul Sandoz wrote: >>> On Jul 12, 2014, at 5:41 PM, Remi Forax wrote: >>> >>>> I was not able to find the answer to my question in the archive, >>>> why Stream.concat is not implemented like this ? >>>> >>>> @SafeVarargs >>>> public static Stream concat(Stream... streams) { >>>> return Arrays.stream(streams).flatMap(Function.identity()); >>>> } >>>> >>> Because the capabilities and characteristics of the streams are then lost e.g. in this case the splitting is governed by the number of streams passed in. >> it seems to be a limitation of flatMap in that case, no ? >> > That would be much harder to optimise since each element gets mapped to a Stream of 0 or more elements when the pipeline is executed. The operation has no "global" view of all the streams to concatenate as all it knows is a mapping function. At the moment flatMap is quite a simple and efficient stateless operation and i think it best it stays that way. > > e.g. imagine the case of streaming over the lines of a file and flatMapping each line to one or more words. > > Paul. > and imagine the case where you know the size of a stream returned by flatMap, in that case, you may want to split before pumping the values of the stream. R?mi From vladimir.x.ivanov at oracle.com Mon Jul 14 15:17:08 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 14 Jul 2014 19:17:08 +0400 Subject: [9] RFR (M): 8050057: Improve caching of MethodHandle reinvokers Message-ID: <53C3F474.4070708@oracle.com> http://cr.openjdk.java.net/~vlivanov/8050057/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8050057 Cache MethodHandle reinvokers per basic type. For BoundMethodHandles, rebinding is no-op unless underlying LF is too complex (see BMH::tooComplex() for details). Also, introduced DelegatingMethodHandle whose invocation behavior is determined by a target MethodHandle. The delegating MH itself can hold extra "intentions" beyond the simple behavior. AsVarargsCollector and WrappedMember are made subclasses of DelegatingMethodHandle. Also, SimpleMethodHandle extends BoundMethodHandle now. Rebinding and delegation share same logic and LF shape, but have different caches (LF_REBIND vs LF_DELEGATE). The only difference is their name. They could be consolidated in the future. Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}. Reviewed-by: vlivanov, ? Contributed-by: john.r.rose at oracle.com Thanks! Best regards, Vladimir Ivanov From claes.redestad at oracle.com Mon Jul 14 15:40:41 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 14 Jul 2014 17:40:41 +0200 Subject: RFR [9]: 8050142: Optimize java.util.Formatter In-Reply-To: <53C3E74F.8010900@oracle.com> References: <53C3ABEA.9080009@oracle.com> <53C3BE16.3040300@gmail.com> <53C3BF33.7020403@oracle.com> <53C3CBB1.9070305@oracle.com> <53C3D4D7.3040204@oracle.com> <53C3E74F.8010900@oracle.com> Message-ID: <53C3F9F9.3060903@oracle.com> Hi, final(?) webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.2 Thanks in advance for reviews. I also need a volunteer to sponsor this. :-) /Claes On 07/14/2014 04:21 PM, Claes Redestad wrote: > Yes, might be worth addressing just for correctness/readability. > > /Claes > > On 07/14/2014 03:02 PM, Ivan Gerasimov wrote: >> A very minor one: >> 2704 if (Character.isUpperCase(conv)) >> 2705 f.add(Flags.UPPERCASE); >> 2706 c = Character.toLowerCase(conv); >> >> maybe >> >> 2704 if (Character.isUpperCase(conv)) { >> 2705 f.add(Flags.UPPERCASE); >> 2706 c = Character.toLowerCase(conv); >> } >> >> Sincerely yours, >> Ivan >> >> >> On 14.07.2014 16:23, Claes Redestad wrote: >>> Hi again, >>> >>> updated webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.1 >>> >>> changes: >>> - specify capacity on line 2931 as suggested by Andrej Golovnin >>> - exp.append("0") -> exp.append('0') on line 3781 >>> - merged append+justify into appendJustified as suggested by Peter >>> Levart >>> - replaced the reoccuring pattern of appending a number of zeros >>> into a call to trailingZeros >>> >>> performance difference seemingly at noise levels in micros, but >>> bonus to readability and Formatter*.class-files are now a total of >>> 246 bytes smaller >>> >>> /Claes >>> >>> On 2014-07-14 13:29, Claes Redestad wrote: >>>> Hi Peter, >>>> >>>> On 2014-07-14 13:25, Peter Levart wrote: >>>>> On 07/14/2014 12:07 PM, Claes Redestad wrote: >>>>>> Hi, >>>>>> >>>>>> please review this patch which optimizes away some allocations >>>>>> from java.util.Formatter and achieve 1.1-1.3x speedups of micros >>>>>> targetting String.format. See bug for more details. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.0 >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8050142 >>>>>> >>>>>> Testing: JPRT, jtreg (java/lang/String, java/util/Formatter), >>>>>> SPECjbb2013 and microbenchmarks >>>>>> >>>>>> Thanks! >>>>>> >>>>>> /Claes >>>>> >>>>> Hi Claes, >>>>> >>>>> Since justify() result is always appended to the resulting >>>>> Appendable, you could merge the functionality and eliminate >>>>> constructing intermediary StringBuilder altogether: >>>>> >>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Formatter/webrev.01/ >>>>> >>>> Looks good, especially eliminating the need for two different >>>> append methods. I'll update based on this and other suggestions. >>>> >>>> /Claes >>>>> Regards, Peter >>>> >>> >>> >>> >> > From philip.race at oracle.com Mon Jul 14 16:58:09 2014 From: philip.race at oracle.com (Phil Race) Date: Mon, 14 Jul 2014 09:58:09 -0700 Subject: RFR: 8049892: Replace uses of 'new Integer()' with appropriate alternative across core classes In-Reply-To: References: <81766990-91E6-49F4-8EF5-37295275BE15@oracle.com> Message-ID: <53C40C21.9030905@oracle.com> I haven't seen any one with jdk9 reviewer status comment on this And although it looks OK to me I'm not responsible for any of the areas it covers, so it does need an official nod .. -phil. On 7/12/2014 7:38 AM, Ot?vio Gon?alves de Santana wrote: > http://cr.openjdk.java.net/~prr/8049892.1/ > > > On Fri, Jul 11, 2014 at 6:41 AM, Pavel Rappo wrote: > >> Hi Otavio, >> >> Other than things already spotted by Andrej, the change looks good to me. >> Thank you for doing this. >> >> -Pavel >> >> On 11 Jul 2014, at 02:36, Ot?vio Gon?alves de Santana < >> otaviopolianasantana at gmail.com> wrote: >> >>> https://bugs.openjdk.java.net/browse/JDK-8049892 >>> http://cr.openjdk.java.net/~prr/8049892/ >>> >>> -- >>> Cheers!. >>> >>> Ot?vio Gon?alves de Santana >>> >>> blog: http://otaviosantana.blogspot.com.br/ >>> twitter: http://twitter.com/otaviojava >>> site: *http://about.me/otaviojava * >>> 55 (11) 98255-3513 >> > From peter.levart at gmail.com Mon Jul 14 16:59:03 2014 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 14 Jul 2014 18:59:03 +0200 Subject: ThreadLocalRandom clinit troubles In-Reply-To: <53C3ECC2.8040202@oracle.com> References: <53A29DC5.1030605@oracle.com> <53A3FA72.3060706@gmail.com> <53A418F2.3080201@gmail.com> <53A43055.5070803@oracle.com> <53A43EF3.8000206@gmail.com> <53A44C3A.6000607@oracle.com> <53A98525.9080908@gmail.com> <53A9EF29.7030208@gmail.com> <53AB09E5.9070303@gmail.com> <53C3ECC2.8040202@oracle.com> Message-ID: <53C40C57.2000606@gmail.com> Hi Sean, Alex Here's a sum-up post: http://mail.openjdk.java.net/pipermail/security-dev/2014-June/010700.html Regards, Peter On 07/14/2014 04:44 PM, Sean Mullan wrote: > I don't see a pointer to the webrev/patch -- did you forget to include > it? > > --Sean > > On 07/11/2014 07:33 PM, Martin Buchholz wrote: >> Thanks to Peter for digging into the secure seed generator classes and >> coming up with a patch. Openjdk security folks, please review. I >> confess >> to getting lost whenever I try to orient myself in the twisty maze of >> seed >> generator implementation files. >> >> Anyways, it seems important to have prngs like ThreadLocalRandom be >> able to >> get a few bits of seed entropy without loading hundreds of classes and >> without occupying any file descriptors permanently. Perhaps at >> Google we >> will go back to writing some simple non-portable startup code to read >> /dev/urandom until openjdk security team comes up with a more principled >> solution (but one that doesn't drag in too much machinery). >> From vladimir.x.ivanov at oracle.com Mon Jul 14 17:10:18 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 14 Jul 2014 21:10:18 +0400 Subject: [9] RFR (M): 8050200: Make LambdaForm intrinsics detection more robust Message-ID: <53C40EFA.2050305@oracle.com> http://cr.openjdk.java.net/~vlivanov/8050200/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8050200 Replace pattern matching sequences of LambdaForm names during compilation with explicit marks on MethodHandles. Intrinsic ID is associated with a method handle using DelegatingMethodHandle. Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}. Reviewed-by: vlivanov, ? Contributed-by: john.r.rose at oracle.com Thanks! Best regards, Vladimir Ivanov From paul.sandoz at oracle.com Mon Jul 14 17:29:18 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 14 Jul 2014 19:29:18 +0200 Subject: Stream.concat In-Reply-To: <53C3F090.90306@univ-mlv.fr> References: <53C15719.6070105@univ-mlv.fr> <53C3B7A5.9000504@univ-mlv.fr> <53C3F090.90306@univ-mlv.fr> Message-ID: <34E9D1F2-7AB3-43B2-AD80-18A88AF8FEC3@oracle.com> On Jul 14, 2014, at 5:00 PM, Remi Forax wrote: > and imagine the case where you know the size of a stream returned by flatMap, in that case, > you may want to split before pumping the values of the stream. > Since you don't know the characteristics of the flat mapped streams until you get them (i.e. traversing) any global optimizations (such as that related to exact size, or even sorted or distrinct) cannot be applied *unless* you turn flatMap into a stateful barrier. It's much easier to optimize concatenation when one explicitly knows upfront the characteristics of what is to be concatenated. FWIW I did ponder how in general flatMap could be modified for parallel computation e.g. with a flatMap wrapping spliterator, but i am a very skeptical of it's benefits. It's probably only of questionable benefit for small source streams where the size is less than the parallelism of the common pool and each upstream element is mapped to large number of downstream elements or the flat mapping cost is high (to overcome the cost of wrapping). Paul. From jason_mehrens at hotmail.com Mon Jul 14 18:05:43 2014 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Mon, 14 Jul 2014 13:05:43 -0500 Subject: RFR [9]: 8050142: Optimize java.util.Formatter In-Reply-To: <53C3F9F9.3060903@oracle.com> References: <53C3ABEA.9080009@oracle.com> <53C3BE16.3040300@gmail.com> <53C3BF33.7020403@oracle.com> <53C3CBB1.9070305@oracle.com>,<53C3D4D7.3040204@oracle.com> <53C3E74F.8010900@oracle.com>,<53C3F9F9.3060903@oracle.com> Message-ID: Claes, Maybe change (or not): -throw new UnknownFormatConversionException(String.valueOf(c)); +throw new UnknownFormatConversionException(String.valueOf(conv)); I haven't examined it too deeply but it seems odd that some of those print methods don't use the given locale when converting case. That is probably not a change for this issue. Jason ---------------------------------------- > Date: Mon, 14 Jul 2014 17:40:41 +0200 > From: claes.redestad at oracle.com > To: core-libs-dev at openjdk.java.net > Subject: Re: RFR [9]: 8050142: Optimize java.util.Formatter > > Hi, > > final(?) webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.2 > > Thanks in advance for reviews. I also need a volunteer to sponsor > this. :-) > > /Claes > > On 07/14/2014 04:21 PM, Claes Redestad wrote: >> Yes, might be worth addressing just for correctness/readability. >> >> /Claes >> >> On 07/14/2014 03:02 PM, Ivan Gerasimov wrote: >>> A very minor one: >>> 2704 if (Character.isUpperCase(conv)) >>> 2705 f.add(Flags.UPPERCASE); >>> 2706 c = Character.toLowerCase(conv); >>> >>> maybe >>> >>> 2704 if (Character.isUpperCase(conv)) { >>> 2705 f.add(Flags.UPPERCASE); >>> 2706 c = Character.toLowerCase(conv); >>> } >>> >>> Sincerely yours, >>> Ivan >>> >>> >>> On 14.07.2014 16:23, Claes Redestad wrote: >>>> Hi again, >>>> >>>> updated webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.1 >>>> >>>> changes: >>>> - specify capacity on line 2931 as suggested by Andrej Golovnin >>>> - exp.append("0") -> exp.append('0') on line 3781 >>>> - merged append+justify into appendJustified as suggested by Peter >>>> Levart >>>> - replaced the reoccuring pattern of appending a number of zeros >>>> into a call to trailingZeros >>>> >>>> performance difference seemingly at noise levels in micros, but >>>> bonus to readability and Formatter*.class-files are now a total of >>>> 246 bytes smaller >>>> >>>> /Claes >>>> >>>> On 2014-07-14 13:29, Claes Redestad wrote: >>>>> Hi Peter, >>>>> >>>>> On 2014-07-14 13:25, Peter Levart wrote: >>>>>> On 07/14/2014 12:07 PM, Claes Redestad wrote: >>>>>>> Hi, >>>>>>> >>>>>>> please review this patch which optimizes away some allocations >>>>>>> from java.util.Formatter and achieve 1.1-1.3x speedups of micros >>>>>>> targetting String.format. See bug for more details. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.0 >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8050142 >>>>>>> >>>>>>> Testing: JPRT, jtreg (java/lang/String, java/util/Formatter), >>>>>>> SPECjbb2013 and microbenchmarks >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> /Claes >>>>>> >>>>>> Hi Claes, >>>>>> >>>>>> Since justify() result is always appended to the resulting >>>>>> Appendable, you could merge the functionality and eliminate >>>>>> constructing intermediary StringBuilder altogether: >>>>>> >>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Formatter/webrev.01/ >>>>>> >>>>> Looks good, especially eliminating the need for two different >>>>> append methods. I'll update based on this and other suggestions. >>>>> >>>>> /Claes >>>>>> Regards, Peter >>>>> >>>> >>>> >>>> >>> >> > From ecki at zusammenkunft.net Mon Jul 14 20:54:46 2014 From: ecki at zusammenkunft.net (Bernd) Date: Mon, 14 Jul 2014 22:54:46 +0200 Subject: [concurrency-interest] ThreadLocalRandom clinit troubles In-Reply-To: <53C3F4D0.5090407@oracle.com> References: <53A29DC5.1030605@oracle.com> <53A3FA72.3060706@gmail.com> <53A418F2.3080201@gmail.com> <53A43055.5070803@oracle.com> <53A43EF3.8000206@gmail.com> <53A44C3A.6000607@oracle.com> <53A98525.9080908@gmail.com> <53A9EF29.7030208@gmail.com> <53AB09E5.9070303@gmail.com> <53C3F4D0.5090407@oracle.com> Message-ID: SecureRandom is unfortunatelly pretty complex. It is interpreting the seed url in some way (the configuration you mentioned behave very special since Java 6) , it is mixing seed and continues data and it reorders the implementations used. JEP 123 intended to clear things, but getInstanceStrong() (which nobody uses?!) did not improve things IMHO. Bernd PS: I think the webrev changed since then, but the mail from Brad describes the problem well: http://mail.openjdk.java.net/pipermail/security-dev/2013-January/006288.html Am 14.07.2014 21:05 schrieb "Oleksandr Otenko" : > Can someone summarize what happened? > > SecureRandom used to get entropy from /dev/random, which is configurable > through a policy file to /dev/urandom. Has this changed? > > Alex > > On 12/07/2014 00:33, Martin Buchholz wrote: > > Thanks to Peter for digging into the secure seed generator classes and > coming up with a patch. Openjdk security folks, please review. I confess > to getting lost whenever I try to orient myself in the twisty maze of seed > generator implementation files. > > Anyways, it seems important to have prngs like ThreadLocalRandom be able > to get a few bits of seed entropy without loading hundreds of classes and > without occupying any file descriptors permanently. Perhaps at Google we > will go back to writing some simple non-portable startup code to read > /dev/urandom until openjdk security team comes up with a more principled > solution (but one that doesn't drag in too much machinery). > > > _______________________________________________ > Concurrency-interest mailing listConcurrency-interest at cs.oswego.eduhttp://cs.oswego.edu/mailman/listinfo/concurrency-interest > > > From claes.redestad at oracle.com Mon Jul 14 22:41:12 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 15 Jul 2014 00:41:12 +0200 Subject: RFR [9]: 8050142: Optimize java.util.Formatter In-Reply-To: References: <53C3ABEA.9080009@oracle.com> <53C3BE16.3040300@gmail.com> <53C3BF33.7020403@oracle.com> <53C3CBB1.9070305@oracle.com>, <53C3D4D7.3040204@oracle.com> <53C3E74F.8010900@oracle.com>, <53C3F9F9.3060903@oracle.com> Message-ID: <53C45C88.3090000@oracle.com> Sorry about that; maybe I should've renamed the field c to conv instead, but I think I need to be conservative now and will revert the name changes. New webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.3 Changing usage of given locale or any semantic change is really out-of-scope here. There seems to be a few ancient bugs hanging around which maybe someone should take a look at, e.g., https://bugs.openjdk.java.net/browse/JDK-5063466 /Claes On 2014-07-14 20:05, Jason Mehrens wrote: > Claes, > > > Maybe change (or not): > > > -throw new UnknownFormatConversionException(String.valueOf(c)); > > +throw new UnknownFormatConversionException(String.valueOf(conv)); > > > > I haven't examined it too deeply but it seems odd that some of those print methods don't use the given locale when converting case. That is probably not a change for this issue. > > > Jason > > > > > ---------------------------------------- >> Date: Mon, 14 Jul 2014 17:40:41 +0200 >> From: claes.redestad at oracle.com >> To: core-libs-dev at openjdk.java.net >> Subject: Re: RFR [9]: 8050142: Optimize java.util.Formatter >> >> Hi, >> >> final(?) webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.2 >> >> Thanks in advance for reviews. I also need a volunteer to sponsor >> this. :-) >> >> /Claes >> >> On 07/14/2014 04:21 PM, Claes Redestad wrote: >>> Yes, might be worth addressing just for correctness/readability. >>> >>> /Claes >>> >>> On 07/14/2014 03:02 PM, Ivan Gerasimov wrote: >>>> A very minor one: >>>> 2704 if (Character.isUpperCase(conv)) >>>> 2705 f.add(Flags.UPPERCASE); >>>> 2706 c = Character.toLowerCase(conv); >>>> >>>> maybe >>>> >>>> 2704 if (Character.isUpperCase(conv)) { >>>> 2705 f.add(Flags.UPPERCASE); >>>> 2706 c = Character.toLowerCase(conv); >>>> } >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> >>>> On 14.07.2014 16:23, Claes Redestad wrote: >>>>> Hi again, >>>>> >>>>> updated webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.1 >>>>> >>>>> changes: >>>>> - specify capacity on line 2931 as suggested by Andrej Golovnin >>>>> - exp.append("0") -> exp.append('0') on line 3781 >>>>> - merged append+justify into appendJustified as suggested by Peter >>>>> Levart >>>>> - replaced the reoccuring pattern of appending a number of zeros >>>>> into a call to trailingZeros >>>>> >>>>> performance difference seemingly at noise levels in micros, but >>>>> bonus to readability and Formatter*.class-files are now a total of >>>>> 246 bytes smaller >>>>> >>>>> /Claes >>>>> >>>>> On 2014-07-14 13:29, Claes Redestad wrote: >>>>>> Hi Peter, >>>>>> >>>>>> On 2014-07-14 13:25, Peter Levart wrote: >>>>>>> On 07/14/2014 12:07 PM, Claes Redestad wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> please review this patch which optimizes away some allocations >>>>>>>> from java.util.Formatter and achieve 1.1-1.3x speedups of micros >>>>>>>> targetting String.format. See bug for more details. >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.0 >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8050142 >>>>>>>> >>>>>>>> Testing: JPRT, jtreg (java/lang/String, java/util/Formatter), >>>>>>>> SPECjbb2013 and microbenchmarks >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> /Claes >>>>>>> Hi Claes, >>>>>>> >>>>>>> Since justify() result is always appended to the resulting >>>>>>> Appendable, you could merge the functionality and eliminate >>>>>>> constructing intermediary StringBuilder altogether: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Formatter/webrev.01/ >>>>>>> >>>>>> Looks good, especially eliminating the need for two different >>>>>> append methods. I'll update based on this and other suggestions. >>>>>> >>>>>> /Claes >>>>>>> Regards, Peter >>>>> >>>>> >> From paul.sandoz at oracle.com Tue Jul 15 07:35:31 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 15 Jul 2014 09:35:31 +0200 Subject: RFR 8044047: Missing null pointer checks for streams In-Reply-To: References: Message-ID: Ping.. http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-July/027508.html Paul. On Jul 2, 2014, at 2:01 PM, Paul Sandoz wrote: > Hi, > > Please review this fix for some missing null-checks in stream code: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8044047-null-checks/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8044047 > > I also boosted some of the primitive summary statistic tests. > > Unfortunately the refactoring of some test names resulted in disassociation between old and new (not quite sure why in this case), so diffs for renamed tests are below. > > Paul. From daniel.fuchs at oracle.com Tue Jul 15 10:38:19 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 15 Jul 2014 12:38:19 +0200 Subject: RFR 8044047: Missing null pointer checks for streams In-Reply-To: References: Message-ID: <53C5049B.2070807@oracle.com> On 7/15/14 9:35 AM, Paul Sandoz wrote: > Ping.. > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-July/027508.html > > Paul. Hi Paul, This is not my area of expertise - but I haven't seen anything wrong. However - I applied your patch and ran the tests locally on my machine, and I saw that jdk/test/java/util/stream/test/org/openjdk/tests/java/util/stream/FlatMapOpTest.java was intermittently failing in timeout (e.g. while I was compiling another JDK in another workspace). So I wonder whether something should be done for this test to reduce the risk of seeing it timing out on slow machines? best regards, -- daniel > > On Jul 2, 2014, at 2:01 PM, Paul Sandoz wrote: > >> Hi, >> >> Please review this fix for some missing null-checks in stream code: >> >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8044047-null-checks/webrev/ >> https://bugs.openjdk.java.net/browse/JDK-8044047 >> >> I also boosted some of the primitive summary statistic tests. >> >> Unfortunately the refactoring of some test names resulted in disassociation between old and new (not quite sure why in this case), so diffs for renamed tests are below. >> >> Paul. From paul.sandoz at oracle.com Tue Jul 15 11:44:37 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 15 Jul 2014 13:44:37 +0200 Subject: RFR 8044047: Missing null pointer checks for streams In-Reply-To: <53C5049B.2070807@oracle.com> References: <53C5049B.2070807@oracle.com> Message-ID: <755BEC0F-FA99-4FA0-A62C-B6F7A16AC98B@oracle.com> On Jul 15, 2014, at 12:38 PM, Daniel Fuchs wrote: > On 7/15/14 9:35 AM, Paul Sandoz wrote: >> Ping.. >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-July/027508.html >> >> Paul. > > Hi Paul, > > This is not my area of expertise - but I haven't seen anything wrong. > Thanks. > However - I applied your patch and ran the tests locally on my > machine, and I saw that > jdk/test/java/util/stream/test/org/openjdk/tests/java/util/stream/FlatMapOpTest.java > was intermittently failing in timeout (e.g. while I was compiling > another JDK in another workspace). > > So I wonder whether something should be done for this test to reduce > the risk of seeing it timing out on slow machines? > This test is not usually problematic in time outs AFAIK re. execution on the test infrastructure, usually other tests are problematic IIRC. It runs under 30s on my laptop, more often < 15s for 182 tests (it's actually more because there is the cross-produt of streaming strategies not reflected in TestNG reporting). If you use -Xcomp then it is a different matter. There is the timeout factor that can be used to adjust the time out when using arguments that result in slower execution or for slower machines. I don't think we should be having to update tests that run under 30s (at least 4x of the default timeout) on a two year old laptop. Instead we should be taking a good long hard look at our test infrastructure and the way we execute (e.g. run each test method separately) Paul. From vladimir.x.ivanov at oracle.com Tue Jul 15 13:42:47 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 15 Jul 2014 17:42:47 +0400 Subject: [9] RFR (M): 8050052: Small cleanups in java.lang.invoke code In-Reply-To: <53C3DDC1.4090307@oracle.com> References: <53C00E62.20703@oracle.com> <53C3DDC1.4090307@oracle.com> Message-ID: <53C52FD7.8030601@oracle.com> Another update: http://cr.openjdk.java.net/~vlivanov/8050052//webrev.01/ Tentative diff: http://cr.openjdk.java.net/~vlivanov/8050052/webrev.diff.01-02/ Best regards, Vladimir Ivanov On 7/14/14 5:40 PM, Vladimir Ivanov wrote: > Paul, thanks! > > Small update: > http://cr.openjdk.java.net/~vlivanov/8050052/prepared_forms/ > > Updated version: > http://cr.openjdk.java.net/~vlivanov/8050052//webrev.01/ > > Best regards, > Vladimir Ivanov > > On 7/14/14 4:57 PM, Paul Sandoz wrote: >> >> On Jul 11, 2014, at 6:18 PM, Vladimir Ivanov >> wrote: >> >>> http://cr.openjdk.java.net/~vlivanov/8050052/webrev.00 >>> https://bugs.openjdk.java.net/browse/JDK-8050052 >>> >>> Numerous small code cleanups in java.lang.invoke package. >>> >>> Testing: jtreg, nashorn, octane w/ "-ea -esa" and >>> COMPILE_THRESHOLD={0,30}. >>> >>> Reviewed-by: vlivanov, ? >>> Contributed-by: john.r.rose at oracle.com >>> >> >> Looks ok, could not find anything obviously wrong. >> >> Paul. >> From vladimir.x.ivanov at oracle.com Tue Jul 15 13:48:15 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 15 Jul 2014 17:48:15 +0400 Subject: [9] RFR (M): 8050053: Improve caching of different invokers In-Reply-To: <53C01252.4070302@oracle.com> References: <53C01252.4070302@oracle.com> Message-ID: <53C5311F.8020202@oracle.com> Update: http://cr.openjdk.java.net/~vlivanov/8050053/webrev.01 Diff: http://cr.openjdk.java.net/~vlivanov/8050053/webrev.diff.00-01/ Got rid of varargs & spread invokers. Best regards, Vladimir Ivanov On 7/11/14 8:35 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8050053/webrev.00 > https://bugs.openjdk.java.net/browse/JDK-8050053 > > Improve sharing of different invokers: basic, generic & exact invokers, > uninitialized call site invoker and NamedFunction invoker are changed. > > Testing: jdk/java/lang/invoke, nashorn, octane w/ "-ea -esa". > > Reviewed-by: vlivanov, ? > Contributed-by: john.r.rose at oracle.com > > Thanks! > > Best regards, > Vladimir Ivanov > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From mark.sheppard at oracle.com Tue Jul 15 14:07:31 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Tue, 15 Jul 2014 15:07:31 +0100 Subject: RFR JDK-8048175: Remove redundant use of reflection on core classes from JNDI In-Reply-To: References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> Message-ID: <53C535A3.3040108@oracle.com> Hi Pavel, the changes look ok .... I've run some relevant jck tests (naming management rmi) and the CORBA regression suite for the changeset, with no perceptible issues regards Mark On 14/07/2014 12:43, Pavel Rappo wrote: > Hi everyone, > > Could you please review my change for JDK-8048175? > > http://cr.openjdk.java.net/~prappo/8048175/webrev.00/ > > Summary > > 1. com.sun.jndi.ldap.Connection imports both java.net.InetSocketAddress and javax.net.SocketFactory which are available since 1.4 > 2. com.sun.jndi.toolkit.corba.CorbaUtils defines 3 imports from java.rmi and java.rmi.CORBA. Justification: CorbaUtils is used by the com.sun.jndi.cosnaming package which resides in CORBA module. Which in turn has a dependency on RMI module. > 3. com.sun.jndi.cosnaming.RemoteToCorba.getStateToBind method doesn't handle ClassNotFoundException internally. There's no need for that now (see 2). > 4. com.sun.jndi.ldap.VersionHelper instantiates only the com.sun.jndi.ldap.VersionHelper12. Justification: the rudimentary test for jdk version is no longer needed as JNDI is a part of the platform and com.sun.jndi.ldap.VersionHelper11 is no longer available (at least since 1.3). > > All corresponding reflection usages have been removed. > > Thanks > -Pavel From vincent.x.ryan at oracle.com Tue Jul 15 14:41:34 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 15 Jul 2014 15:41:34 +0100 Subject: RFR JDK-8048175: Remove redundant use of reflection on core classes from JNDI In-Reply-To: <53C535A3.3040108@oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> <53C535A3.3040108@oracle.com> Message-ID: <5E8B5572-C902-4ED7-8F58-A63E3A82D784@oracle.com> The LDAP changes look fine to me. Thanks. On 15 Jul 2014, at 15:07, Mark Sheppard wrote: > Hi Pavel, > the changes look ok .... I've run some relevant jck tests (naming management rmi) and the CORBA regression suite > for the changeset, with no perceptible issues > > regards > Mark > > On 14/07/2014 12:43, Pavel Rappo wrote: >> Hi everyone, >> >> Could you please review my change for JDK-8048175? >> >> http://cr.openjdk.java.net/~prappo/8048175/webrev.00/ >> >> Summary >> >> 1. com.sun.jndi.ldap.Connection imports both java.net.InetSocketAddress and javax.net.SocketFactory which are available since 1.4 >> 2. com.sun.jndi.toolkit.corba.CorbaUtils defines 3 imports from java.rmi and java.rmi.CORBA. Justification: CorbaUtils is used by the com.sun.jndi.cosnaming package which resides in CORBA module. Which in turn has a dependency on RMI module. >> 3. com.sun.jndi.cosnaming.RemoteToCorba.getStateToBind method doesn't handle ClassNotFoundException internally. There's no need for that now (see 2). >> 4. com.sun.jndi.ldap.VersionHelper instantiates only the com.sun.jndi.ldap.VersionHelper12. Justification: the rudimentary test for jdk version is no longer needed as JNDI is a part of the platform and com.sun.jndi.ldap.VersionHelper11 is no longer available (at least since 1.3). >> >> All corresponding reflection usages have been removed. >> >> Thanks >> -Pavel > From pavel.rappo at oracle.com Tue Jul 15 15:00:21 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 15 Jul 2014 16:00:21 +0100 Subject: RFR JDK-8048175: Remove redundant use of reflection on core classes from JNDI In-Reply-To: <5E8B5572-C902-4ED7-8F58-A63E3A82D784@oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> <53C535A3.3040108@oracle.com> <5E8B5572-C902-4ED7-8F58-A63E3A82D784@oracle.com> Message-ID: <1EFD4C00-042F-41B1-A642-269412F31F07@oracle.com> Thanks! -Pavel On 15 Jul 2014, at 15:41, Vincent Ryan wrote: > The LDAP changes look fine to me. > Thanks. > > On 15 Jul 2014, at 15:07, Mark Sheppard wrote: > >> Hi Pavel, >> the changes look ok .... I've run some relevant jck tests (naming management rmi) and the CORBA regression suite >> for the changeset, with no perceptible issues >> >> regards >> Mark >> >> On 14/07/2014 12:43, Pavel Rappo wrote: >>> Hi everyone, >>> >>> Could you please review my change for JDK-8048175? >>> >>> http://cr.openjdk.java.net/~prappo/8048175/webrev.00/ >>> >>> Summary >>> >>> 1. com.sun.jndi.ldap.Connection imports both java.net.InetSocketAddress and javax.net.SocketFactory which are available since 1.4 >>> 2. com.sun.jndi.toolkit.corba.CorbaUtils defines 3 imports from java.rmi and java.rmi.CORBA. Justification: CorbaUtils is used by the com.sun.jndi.cosnaming package which resides in CORBA module. Which in turn has a dependency on RMI module. >>> 3. com.sun.jndi.cosnaming.RemoteToCorba.getStateToBind method doesn't handle ClassNotFoundException internally. There's no need for that now (see 2). >>> 4. com.sun.jndi.ldap.VersionHelper instantiates only the com.sun.jndi.ldap.VersionHelper12. Justification: the rudimentary test for jdk version is no longer needed as JNDI is a part of the platform and com.sun.jndi.ldap.VersionHelper11 is no longer available (at least since 1.3). >>> >>> All corresponding reflection usages have been removed. >>> >>> Thanks >>> -Pavel >> > From paul.sandoz at oracle.com Tue Jul 15 16:08:34 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 15 Jul 2014 18:08:34 +0200 Subject: RFR: 8049892: Replace uses of 'new Integer()' with appropriate alternative across core classes In-Reply-To: <53C40C21.9030905@oracle.com> References: <81766990-91E6-49F4-8EF5-37295275BE15@oracle.com> <53C40C21.9030905@oracle.com> Message-ID: <5B18F30D-A456-4E6A-92A0-8B187FA5AE4B@oracle.com> On Jul 14, 2014, at 6:58 PM, Phil Race wrote: > I haven't seen any one with jdk9 reviewer status comment on this > And although it looks OK to me I'm not responsible for any of the areas > it covers, so it does need an official nod .. > Thanks Phil, this patch looks OK to me too. Paul. From rob.mckenna at oracle.com Tue Jul 15 17:27:23 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 15 Jul 2014 18:27:23 +0100 Subject: RFR: 7130985: Four helper classes missing in Sun JDK Message-ID: <53C5647B.5000001@oracle.com> Hi folks, Looking for a review for the following: bug: https://bugs.openjdk.java.net/browse/JDK-7130985 webrev: http://cr.openjdk.java.net/~robm/7130985/webrev.01/ As per the bug report: The IDLtoJava spec clearly specifies the need of the helper class (not the Holder) for these files. But these are absent in the JDK. So, if we try to send any of these classes across in a client-server rmi-iiop model, it will throw an error complaining about the absence of the helper class. -Rob From rob.mckenna at oracle.com Tue Jul 15 17:46:57 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 15 Jul 2014 18:46:57 +0100 Subject: 8050044: (process) Increase reaper thread native stack size by a factor of 2 Message-ID: <53C56911.7060209@oracle.com> Hi folks, A very simple change suggested by Martin a while back in another review. I'm just getting around to it now: bug: https://bugs.openjdk.java.net/browse/JDK-8050044 webrev: http://cr.openjdk.java.net/~robm/8050044/webrev.01/ Martins comments: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-March/025943.html -Rob From martinrb at google.com Tue Jul 15 17:48:08 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 15 Jul 2014 10:48:08 -0700 Subject: 8050044: (process) Increase reaper thread native stack size by a factor of 2 In-Reply-To: <53C56911.7060209@oracle.com> References: <53C56911.7060209@oracle.com> Message-ID: Looks good to me! On Tue, Jul 15, 2014 at 10:46 AM, Rob McKenna wrote: > Hi folks, > > A very simple change suggested by Martin a while back in another review. > I'm just getting around to it now: > > bug: https://bugs.openjdk.java.net/browse/JDK-8050044 > webrev: http://cr.openjdk.java.net/~robm/8050044/webrev.01/ > > Martins comments: http://mail.openjdk.java.net/ > pipermail/core-libs-dev/2014-March/025943.html > > -Rob > > From roger.riggs at oracle.com Tue Jul 15 17:51:20 2014 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 15 Jul 2014 13:51:20 -0400 Subject: 8050044: (process) Increase reaper thread native stack size by a factor of 2 In-Reply-To: <53C56911.7060209@oracle.com> References: <53C56911.7060209@oracle.com> Message-ID: <53C56A18.2080107@oracle.com> Hi Rob, Is there any evidence that needs more space? Is there any way to tell how much of the existing 32k is being used? The reaper has very limited processing to do and there is one thread for every process spawned. Roger On 7/15/2014 1:46 PM, Rob McKenna wrote: > Hi folks, > > A very simple change suggested by Martin a while back in another > review. I'm just getting around to it now: > > bug: https://bugs.openjdk.java.net/browse/JDK-8050044 > webrev: http://cr.openjdk.java.net/~robm/8050044/webrev.01/ > > Martins comments: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-March/025943.html > > -Rob > From rob.mckenna at oracle.com Tue Jul 15 17:52:05 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 15 Jul 2014 18:52:05 +0100 Subject: RFR: 8050044: (process) Increase reaper thread native stack size by a factor of 2 In-Reply-To: References: <53C56911.7060209@oracle.com> Message-ID: <53C56A45.7020002@oracle.com> And as in that review you have managed to intercept me before I made a small correction. In this case to the subject. I'm beginning to suspect you're a highly sophisticated bot. -Rob On 15/07/14 18:48, Martin Buchholz wrote: > Looks good to me! > > > On Tue, Jul 15, 2014 at 10:46 AM, Rob McKenna > wrote: > > Hi folks, > > A very simple change suggested by Martin a while back in another > review. I'm just getting around to it now: > > bug: https://bugs.openjdk.java.net/browse/JDK-8050044 > webrev: http://cr.openjdk.java.net/~robm/8050044/webrev.01/ > > > Martins comments: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-March/025943.html > > -Rob > > From roger.riggs at oracle.com Tue Jul 15 17:53:26 2014 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 15 Jul 2014 13:53:26 -0400 Subject: 8050044: (process) Increase reaper thread native stack size by a factor of 2 In-Reply-To: References: <53C56911.7060209@oracle.com> Message-ID: <53C56A96.50906@oracle.com> Hi Martin, Wait a minute, can you provide more motivation, observation. etc. it really does not seem necessary and just because everything is bigger is pretty weak. Thanks, Roger On 7/15/2014 1:48 PM, Martin Buchholz wrote: > Looks good to me! > > > On Tue, Jul 15, 2014 at 10:46 AM, Rob McKenna > wrote: > >> Hi folks, >> >> A very simple change suggested by Martin a while back in another review. >> I'm just getting around to it now: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8050044 >> webrev: http://cr.openjdk.java.net/~robm/8050044/webrev.01/ >> >> Martins comments: http://mail.openjdk.java.net/ >> pipermail/core-libs-dev/2014-March/025943.html >> >> -Rob >> >> From rob.mckenna at oracle.com Tue Jul 15 17:55:09 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 15 Jul 2014 18:55:09 +0100 Subject: RFR: 8050044: (process) Increase reaper thread native stack size by a factor of 2 In-Reply-To: <53C56A18.2080107@oracle.com> References: <53C56911.7060209@oracle.com> <53C56A18.2080107@oracle.com> Message-ID: <53C56AFD.1070006@oracle.com> I have not made any empirical measurements. I was following up on Martins suggestion. I'll try to put some time aside for testing later this week though. -Rob On 15/07/14 18:51, roger riggs wrote: > Hi Rob, > > Is there any evidence that needs more space? Is there any way to tell > how much of > the existing 32k is being used? > The reaper has very limited processing to do and there is one thread > for every process spawned. > > Roger > > > On 7/15/2014 1:46 PM, Rob McKenna wrote: >> Hi folks, >> >> A very simple change suggested by Martin a while back in another >> review. I'm just getting around to it now: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8050044 >> webrev: http://cr.openjdk.java.net/~robm/8050044/webrev.01/ >> >> Martins comments: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-March/025943.html >> >> -Rob >> > From martinrb at google.com Tue Jul 15 17:58:22 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 15 Jul 2014 10:58:22 -0700 Subject: 8050044: (process) Increase reaper thread native stack size by a factor of 2 In-Reply-To: <53C56A18.2080107@oracle.com> References: <53C56911.7060209@oracle.com> <53C56A18.2080107@oracle.com> Message-ID: The fear is that stack sizes and alignments have grown over time, and thread stacks are acquiring things like guard pages, and those pages may (incorrectly) end up getting included in the stack size. I'm particularly afraid of the hotspot guard page code. It may be worthwhile seeing how low you can make the stack size on popular platforms before the jtreg tests for process fall over, then multiply by 10 at least. We are approaching the 64-bit only era, when address space restrictions won't be a problem (for a while) On Tue, Jul 15, 2014 at 10:51 AM, roger riggs wrote: > Hi Rob, > > Is there any evidence that needs more space? Is there any way to tell how > much of > the existing 32k is being used? > The reaper has very limited processing to do and there is one thread for > every process spawned. > > Roger > > > > On 7/15/2014 1:46 PM, Rob McKenna wrote: > >> Hi folks, >> >> A very simple change suggested by Martin a while back in another review. >> I'm just getting around to it now: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8050044 >> webrev: http://cr.openjdk.java.net/~robm/8050044/webrev.01/ >> >> Martins comments: http://mail.openjdk.java.net/ >> pipermail/core-libs-dev/2014-March/025943.html >> >> -Rob >> >> > From Alan.Bateman at oracle.com Tue Jul 15 19:34:28 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Jul 2014 20:34:28 +0100 Subject: RFR: 7130985: Four helper classes missing in Sun JDK In-Reply-To: <53C5647B.5000001@oracle.com> References: <53C5647B.5000001@oracle.com> Message-ID: <53C58244.3010409@oracle.com> On 15/07/2014 18:27, Rob McKenna wrote: > Hi folks, > > Looking for a review for the following: > > bug: https://bugs.openjdk.java.net/browse/JDK-7130985 > webrev: http://cr.openjdk.java.net/~robm/7130985/webrev.01/ > > As per the bug report: The IDLtoJava spec clearly specifies the need > of the helper class (not the Holder) for these files. But these are > absent in the JDK. So, if we try to send any of these classes across > in a client-server rmi-iiop model, it will throw an error complaining > about the absence of the helper class. There is clearly a lot of history and would be useful to get confirmation that these are required for OMG complication. As this is generated code then I'm curious where the original source is. Just wondering if it would make sense to check-in the original CORBA_TypeCode.idl. Do we have any standalone tests that can be used to exercise these classes? -Alan From john.r.rose at oracle.com Tue Jul 15 19:51:22 2014 From: john.r.rose at oracle.com (John Rose) Date: Tue, 15 Jul 2014 12:51:22 -0700 Subject: [9] RFR (M): 8050052: Small cleanups in java.lang.invoke code In-Reply-To: <53C02534.2040000@univ-mlv.fr> References: <53C00E62.20703@oracle.com> <53C02534.2040000@univ-mlv.fr> Message-ID: <96C06C20-2479-47A2-94F9-49C987AE58A9@oracle.com> On Jul 11, 2014, at 10:56 AM, Remi Forax wrote: > > On 07/11/2014 06:18 PM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8050052/webrev.00 >> https://bugs.openjdk.java.net/browse/JDK-8050052 > > I've found myself writing the very same code as MethodHandleStatics.uncaughException several times > and I wonder if it should not be an instance method of Throwable. > Something like: > > public E rethrow(Function uncaughtHandler) { > if (this instanceof RuntimeException) { > throw (RuntimeException)this; > } > if (this instanceof Error) { > throw (Error)this; > } > return uncaughtHandler.apply(this); > } > > in that case, throw uncaughtException(ex) can be replaced by throw ex.rethrow(::newInternalError); That's not a bad idea, but (odd for me to say this) it is too easy to use. Occasionally there are reasons for *locally* subverting static checking of exceptions, usually because we are writing a framework (like jli) that is polymorphic across exception types. The checking is suppressed in one place so it can be reasserted elsewhere, usually with some concerted wrapping and unwrapped (aka exception tunnelling). An API which assists in doing this would be helpful, but it should be highly specific. In effect it should say "I am temporarily suppressing all checked exceptions except the locally checked ones X, Y, Z, and tunnelling the rest through a wrapper W." A secondary point is that the wrapper should generally not be something really general like "Error"; perhaps "InternalError" or "AssertionError" would be more helpful. But sometimes it needs to be a single *checked* exception. I guess I'm saying the API needs careful definition. Time for a JEP (but not mine!). It's an esthetic point, but "rethrow" is too breezy and quick to fully communicate valid intentions (as sketched above), and too ready to ease subversion of checks. Imagine the stack overflow articles saying, "hate Java exception checks? just type the following to get rid of them all!" Don't. Want. ? John From mandy.chung at oracle.com Tue Jul 15 23:35:51 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 15 Jul 2014 16:35:51 -0700 Subject: Review request for 8050804: (jdeps) Recommend supported API to replace use of JDK internal API Message-ID: <53C5BAD7.1040202@oracle.com> jdeps -jdkinternals flags use of JDK internal APIs. We have created a wiki page to keep track of the JDK internal APIs and its replacement: https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool While this page will be updated when we identify any new ones worthnoting, it'd still be useful for jdeps to suggest the replacement APIs of the known ones. webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8050804/webrev.00/ Mandy From joe.darcy at oracle.com Wed Jul 16 00:29:46 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 15 Jul 2014 17:29:46 -0700 Subject: JDK 9 RFR of JDK-8030942: Explicitly state floating-point summation requirements on non-finite inputs Message-ID: <53C5C77A.5040500@oracle.com> Hello, Please review my changes to address: JDK-8030942: Explicitly state floating-point summation requirements on non-finite inputs http://cr.openjdk.java.net/~darcy/8030942.0/ Patch below. Thanks, -Joe --- old/src/share/classes/java/util/DoubleSummaryStatistics.java 2014-07-15 17:26:41.000000000 -0700 +++ new/src/share/classes/java/util/DoubleSummaryStatistics.java 2014-07-15 17:26:41.000000000 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -129,9 +129,6 @@ * Returns the sum of values recorded, or zero if no values have been * recorded. * - * If any recorded value is a NaN or the sum is at any point a NaN - * then the sum will be NaN. - * *

The value of a floating-point sum is a function both of the * input values as well as the order of addition operations. The * order of addition operations of this method is intentionally @@ -143,6 +140,23 @@ * numerical sum compared to a simple summation of {@code double} * values. * + *

If any recorded value is a NaN or the intermediate sum is at + * any point a NaN, then the final sum will be NaN. + * + * If the recorded values contain infinities of opposite sign, the + * final sum will be NaN. + * + * It is possible for intermediate sums of finite values to + * overflow into opposite-signed infinities; if that occurs, the + * final sum will be NaN even if the recorded values are all + * finite. + * + * If the exact sum is infinite, a properly-signed infinity is + * returned. + * + * If all the recorded values are zero, the sign of zero is + * not guaranteed to be preserved in the final sum. + * * @apiNote Values sorted by increasing absolute magnitude tend to yield * more accurate results. * @@ -193,9 +207,6 @@ * Returns the arithmetic mean of values recorded, or zero if no * values have been recorded. * - * If any recorded value is a NaN or the sum is at any point a NaN - * then the average will be code NaN. - * *

The average returned can vary depending upon the order in * which values are recorded. * @@ -203,6 +214,10 @@ * other technique to reduce the error bound in the {@link #getSum * numerical sum} used to compute the average. * + *

This method can return a NaN or infinite result in the same + * kind of numerical situations as {@linkplain #getSum() the sum} + * can be NaN or infinite, respectively. + * * @apiNote Values sorted by increasing absolute magnitude tend to yield * more accurate results. * --- old/src/share/classes/java/util/stream/DoubleStream.java 2014-07-15 17:26:42.000000000 -0700 +++ new/src/share/classes/java/util/stream/DoubleStream.java 2014-07-15 17:26:42.000000000 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -470,10 +470,7 @@ * code is not necessarily equivalent to the summation computation * done by this method. * - *

If any stream element is a NaN or the sum is at any point a NaN - * then the sum will be NaN. - * - * The value of a floating-point sum is a function both + *

The value of a floating-point sum is a function both * of the input values as well as the order of addition * operations. The order of addition operations of this method is * intentionally not defined to allow for implementation @@ -485,6 +482,23 @@ * numerical sum compared to a simple summation of {@code double} * values. * + *

If any stream element is a NaN or the intermediate sum is at + * any point a NaN, then the final sum will be NaN. + * + * If the stream elements contain infinities of opposite sign, the + * final sum will be NaN. + * + * It is possible for intermediate sums of finite values to + * overflow into opposite-signed infinities; if that occurs, the + * final sum will be NaN even if the stream elements are all + * finite. + * + * If the exact sum is infinite, a properly-signed infinity is + * returned. + * + * If all the stream elements are zero, the sign of zero is + * not guaranteed to be preserved in the final sum. + * *

This is a terminal * operation. * @@ -555,9 +569,6 @@ * mean of elements of this stream, or an empty optional if this * stream is empty. * - * If any recorded value is a NaN or the sum is at any point a NaN - * then the average will be NaN. - * *

The average returned can vary depending upon the order in * which values are recorded. * @@ -565,6 +576,10 @@ * other technique to reduce the error bound in the {@link #sum * numerical sum} used to compute the average. * + *

This method can return a NaN or infinite result in the same + * kind of numerical situations as {@linkplain #sum() the sum} can + * be NaN or infinite, respectively. + * *

The average is a special case of a reduction. * From mikael.vidstedt at oracle.com Wed Jul 16 02:48:59 2014 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 15 Jul 2014 19:48:59 -0700 Subject: RFR(XS): 8050825: Support running regression tests using jtreg_tests+TESTDIRS from top level Message-ID: <53C5E81B.7080309@oracle.com> Please review the below change which adds support for running jtreg tests from the top level test/ directory using the 'make TESTDIRS= jtreg_tests' syntax. The TESTDIRS syntax is already used in files like hotspot/test/Makefile and jdk/test/Makefile and allows for selecting which jtreg tests to run by providing a directory/path filter. The change enables doing the same type of invocation from the top level; something like this: cd test && make TESTDIRS=../hotspot/test/runtime jtreg_tests cd test && make TESTDIRS=../jdk/test/javax jtreg_tests The implementation logic simply extracts the component (hotspot, jdk etc.) from the value of TESTDIRS and delegates to the respective component's test/Makefile, removing the ..//test from TESTDIRS in the process. Thanks, Mikael From mikael.vidstedt at oracle.com Wed Jul 16 02:51:05 2014 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 15 Jul 2014 19:51:05 -0700 Subject: RFR(XS): 8050825: Support running regression tests using jtreg_tests+TESTDIRS from top level In-Reply-To: <53C5E81B.7080309@oracle.com> References: <53C5E81B.7080309@oracle.com> Message-ID: <53C5E899.3010604@oracle.com> I suppose a webrev helps: http://cr.openjdk.java.net/~mikael/webrevs/8050825/webrev.00/webrev/ Sorry 'bout that. Cheers, Mikael On 2014-07-15 19:48, Mikael Vidstedt wrote: > > Please review the below change which adds support for running jtreg > tests from the top level test/ directory using the 'make > TESTDIRS= jtreg_tests' syntax. The TESTDIRS syntax is already > used in files like hotspot/test/Makefile and jdk/test/Makefile and > allows for selecting which jtreg tests to run by providing a > directory/path filter. The change enables doing the same type of > invocation from the top level; something like this: > > cd test && make TESTDIRS=../hotspot/test/runtime jtreg_tests > cd test && make TESTDIRS=../jdk/test/javax jtreg_tests > > The implementation logic simply extracts the component (hotspot, jdk > etc.) from the value of TESTDIRS and delegates to the respective > component's test/Makefile, removing the ..//test from > TESTDIRS in the process. > > Thanks, > Mikael > From mike.duigou at oracle.com Wed Jul 16 03:04:39 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 15 Jul 2014 20:04:39 -0700 Subject: RFR(XS): 8050825: Support running regression tests using jtreg_tests+TESTDIRS from top level In-Reply-To: <53C5E899.3010604@oracle.com> References: <53C5E81B.7080309@oracle.com> <53C5E899.3010604@oracle.com> Message-ID: This looks like a nice improvement and provides a good way to execute specific sub-sets that are smaller than the TEST.groups definitions. I'd like to hook it up to the top level make as an alternative to the current recipe. make test TEST="jdk_core" Perhaps adjust the top level make test target so that it invokes the test makefile with both the contents of TEST and TESTDIRS as two separate executions? Mike On Jul 15 2014, at 19:51 , Mikael Vidstedt wrote: > > I suppose a webrev helps: > > http://cr.openjdk.java.net/~mikael/webrevs/8050825/webrev.00/webrev/ > > Sorry 'bout that. > > Cheers, > Mikael > > On 2014-07-15 19:48, Mikael Vidstedt wrote: >> >> Please review the below change which adds support for running jtreg tests from the top level test/ directory using the 'make TESTDIRS= jtreg_tests' syntax. The TESTDIRS syntax is already used in files like hotspot/test/Makefile and jdk/test/Makefile and allows for selecting which jtreg tests to run by providing a directory/path filter. The change enables doing the same type of invocation from the top level; something like this: >> >> cd test && make TESTDIRS=../hotspot/test/runtime jtreg_tests >> cd test && make TESTDIRS=../jdk/test/javax jtreg_tests >> >> The implementation logic simply extracts the component (hotspot, jdk etc.) from the value of TESTDIRS and delegates to the respective component's test/Makefile, removing the ..//test from TESTDIRS in the process. >> >> Thanks, >> Mikael >> > From david.holmes at oracle.com Wed Jul 16 03:15:23 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Jul 2014 13:15:23 +1000 Subject: RFR(XS): 8050825: Support running regression tests using jtreg_tests+TESTDIRS from top level In-Reply-To: <53C5E899.3010604@oracle.com> References: <53C5E81B.7080309@oracle.com> <53C5E899.3010604@oracle.com> Message-ID: <53C5EE4B.8050004@oracle.com> Looks okay to me. To be clear, the format of the "path" is not flexible but must have the form ..//test/... David On 16/07/2014 12:51 PM, Mikael Vidstedt wrote: > > I suppose a webrev helps: > > http://cr.openjdk.java.net/~mikael/webrevs/8050825/webrev.00/webrev/ > > Sorry 'bout that. > > Cheers, > Mikael > > On 2014-07-15 19:48, Mikael Vidstedt wrote: >> >> Please review the below change which adds support for running jtreg >> tests from the top level test/ directory using the 'make >> TESTDIRS= jtreg_tests' syntax. The TESTDIRS syntax is already >> used in files like hotspot/test/Makefile and jdk/test/Makefile and >> allows for selecting which jtreg tests to run by providing a >> directory/path filter. The change enables doing the same type of >> invocation from the top level; something like this: >> >> cd test && make TESTDIRS=../hotspot/test/runtime jtreg_tests >> cd test && make TESTDIRS=../jdk/test/javax jtreg_tests >> >> The implementation logic simply extracts the component (hotspot, jdk >> etc.) from the value of TESTDIRS and delegates to the respective >> component's test/Makefile, removing the ..//test from >> TESTDIRS in the process. >> >> Thanks, >> Mikael >> > From mikael.vidstedt at oracle.com Wed Jul 16 03:22:31 2014 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 15 Jul 2014 20:22:31 -0700 Subject: RFR(XS): 8050825: Support running regression tests using jtreg_tests+TESTDIRS from top level In-Reply-To: References: <53C5E81B.7080309@oracle.com> <53C5E899.3010604@oracle.com> Message-ID: <53C5EFF7.9030909@oracle.com> On 2014-07-15 20:04, Mike Duigou wrote: > This looks like a nice improvement and provides a good way to execute specific sub-sets that are smaller than the TEST.groups definitions. > > I'd like to hook it up to the top level make as an alternative to the current recipe. > > make test TEST="jdk_core" > > Perhaps adjust the top level make test target so that it invokes the test makefile with both the contents of TEST and TESTDIRS as two separate executions? This sounds like a very reasonable follow-up! Thanks for the review. Cheers, Mikael > > Mike > > On Jul 15 2014, at 19:51 , Mikael Vidstedt wrote: > >> I suppose a webrev helps: >> >> http://cr.openjdk.java.net/~mikael/webrevs/8050825/webrev.00/webrev/ >> >> Sorry 'bout that. >> >> Cheers, >> Mikael >> >> On 2014-07-15 19:48, Mikael Vidstedt wrote: >>> Please review the below change which adds support for running jtreg tests from the top level test/ directory using the 'make TESTDIRS= jtreg_tests' syntax. The TESTDIRS syntax is already used in files like hotspot/test/Makefile and jdk/test/Makefile and allows for selecting which jtreg tests to run by providing a directory/path filter. The change enables doing the same type of invocation from the top level; something like this: >>> >>> cd test && make TESTDIRS=../hotspot/test/runtime jtreg_tests >>> cd test && make TESTDIRS=../jdk/test/javax jtreg_tests >>> >>> The implementation logic simply extracts the component (hotspot, jdk etc.) from the value of TESTDIRS and delegates to the respective component's test/Makefile, removing the ..//test from TESTDIRS in the process. >>> >>> Thanks, >>> Mikael >>> From mikael.vidstedt at oracle.com Wed Jul 16 03:23:29 2014 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 15 Jul 2014 20:23:29 -0700 Subject: RFR(XS): 8050825: Support running regression tests using jtreg_tests+TESTDIRS from top level In-Reply-To: <53C5EE4B.8050004@oracle.com> References: <53C5E81B.7080309@oracle.com> <53C5E899.3010604@oracle.com> <53C5EE4B.8050004@oracle.com> Message-ID: <53C5F031.4010200@oracle.com> Correct, the path needs to be on that format! Thanks for the review! Thanks, Mikael On 2014-07-15 20:15, David Holmes wrote: > Looks okay to me. > > To be clear, the format of the "path" is not flexible but must have > the form ..//test/... > > David > > On 16/07/2014 12:51 PM, Mikael Vidstedt wrote: >> >> I suppose a webrev helps: >> >> http://cr.openjdk.java.net/~mikael/webrevs/8050825/webrev.00/webrev/ >> >> Sorry 'bout that. >> >> Cheers, >> Mikael >> >> On 2014-07-15 19:48, Mikael Vidstedt wrote: >>> >>> Please review the below change which adds support for running jtreg >>> tests from the top level test/ directory using the 'make >>> TESTDIRS= jtreg_tests' syntax. The TESTDIRS syntax is already >>> used in files like hotspot/test/Makefile and jdk/test/Makefile and >>> allows for selecting which jtreg tests to run by providing a >>> directory/path filter. The change enables doing the same type of >>> invocation from the top level; something like this: >>> >>> cd test && make TESTDIRS=../hotspot/test/runtime jtreg_tests >>> cd test && make TESTDIRS=../jdk/test/javax jtreg_tests >>> >>> The implementation logic simply extracts the component (hotspot, jdk >>> etc.) from the value of TESTDIRS and delegates to the respective >>> component's test/Makefile, removing the ..//test from >>> TESTDIRS in the process. >>> >>> Thanks, >>> Mikael >>> >> From mike.duigou at oracle.com Wed Jul 16 03:45:25 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 15 Jul 2014 20:45:25 -0700 Subject: RFR(XS): 8050825: Support running regression tests using jtreg_tests+TESTDIRS from top level In-Reply-To: <53C5F031.4010200@oracle.com> References: <53C5E81B.7080309@oracle.com> <53C5E899.3010604@oracle.com> <53C5EE4B.8050004@oracle.com> <53C5F031.4010200@oracle.com> Message-ID: <8A33F00F-E039-47AA-ABD7-BFBC9CBBFB55@oracle.com> I will probably try to fix that eventually. I had some shell code which re-resolved a path relative to another path. In particular, for top level make execution the "../" portion would be incorrect. Anyway, this seems good enough for now. We can make it more flexible later. Mike On Jul 15 2014, at 20:23 , Mikael Vidstedt wrote: > > Correct, the path needs to be on that format! > > Thanks for the review! > > Thanks, > Mikael > > On 2014-07-15 20:15, David Holmes wrote: >> Looks okay to me. >> >> To be clear, the format of the "path" is not flexible but must have the form ..//test/... >> >> David >> >> On 16/07/2014 12:51 PM, Mikael Vidstedt wrote: >>> >>> I suppose a webrev helps: >>> >>> http://cr.openjdk.java.net/~mikael/webrevs/8050825/webrev.00/webrev/ >>> >>> Sorry 'bout that. >>> >>> Cheers, >>> Mikael >>> >>> On 2014-07-15 19:48, Mikael Vidstedt wrote: >>>> >>>> Please review the below change which adds support for running jtreg >>>> tests from the top level test/ directory using the 'make >>>> TESTDIRS= jtreg_tests' syntax. The TESTDIRS syntax is already >>>> used in files like hotspot/test/Makefile and jdk/test/Makefile and >>>> allows for selecting which jtreg tests to run by providing a >>>> directory/path filter. The change enables doing the same type of >>>> invocation from the top level; something like this: >>>> >>>> cd test && make TESTDIRS=../hotspot/test/runtime jtreg_tests >>>> cd test && make TESTDIRS=../jdk/test/javax jtreg_tests >>>> >>>> The implementation logic simply extracts the component (hotspot, jdk >>>> etc.) from the value of TESTDIRS and delegates to the respective >>>> component's test/Makefile, removing the ..//test from >>>> TESTDIRS in the process. >>>> >>>> Thanks, >>>> Mikael >>>> >>> > From Alan.Bateman at oracle.com Wed Jul 16 06:44:09 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Jul 2014 07:44:09 +0100 Subject: RFR(XS): 8050825: Support running regression tests using jtreg_tests+TESTDIRS from top level In-Reply-To: <53C5E81B.7080309@oracle.com> References: <53C5E81B.7080309@oracle.com> Message-ID: <53C61F39.8060006@oracle.com> On 16/07/2014 03:48, Mikael Vidstedt wrote: > > Please review the below change which adds support for running jtreg > tests from the top level test/ directory using the 'make > TESTDIRS= jtreg_tests' syntax. The TESTDIRS syntax is already > used in files like hotspot/test/Makefile and jdk/test/Makefile and > allows for selecting which jtreg tests to run by providing a > directory/path filter. The change enables doing the same type of > invocation from the top level; something like this: > > cd test && make TESTDIRS=../hotspot/test/runtime jtreg_tests > cd test && make TESTDIRS=../jdk/test/javax jtreg_tests > > The implementation logic simply extracts the component (hotspot, jdk > etc.) from the value of TESTDIRS and delegates to the respective > component's test/Makefile, removing the ..//test from > TESTDIRS in the process. This looks okay to me but we mostly use test groups in the jdk repo now (because tests for components are separate across multiple trees). So maybe it would be better not to use TESTDIRS but instead pick another name that we could use to specify groups too. -Alan From paul.sandoz at oracle.com Wed Jul 16 07:28:51 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 16 Jul 2014 09:28:51 +0200 Subject: [9] RFR (M): 8050053: Improve caching of different invokers In-Reply-To: <53C5311F.8020202@oracle.com> References: <53C01252.4070302@oracle.com> <53C5311F.8020202@oracle.com> Message-ID: On Jul 15, 2014, at 3:48 PM, Vladimir Ivanov wrote: > Update: http://cr.openjdk.java.net/~vlivanov/8050053/webrev.01 > Diff: http://cr.openjdk.java.net/~vlivanov/8050053/webrev.diff.00-01/ > > Got rid of varargs & spread invokers. > +1 Paul. From paul.sandoz at oracle.com Wed Jul 16 07:35:29 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 16 Jul 2014 09:35:29 +0200 Subject: [9] RFR (M): 8050052: Small cleanups in java.lang.invoke code In-Reply-To: <53C52FD7.8030601@oracle.com> References: <53C00E62.20703@oracle.com> <53C3DDC1.4090307@oracle.com> <53C52FD7.8030601@oracle.com> Message-ID: On Jul 15, 2014, at 3:42 PM, Vladimir Ivanov wrote: > Another update: > http://cr.openjdk.java.net/~vlivanov/8050052//webrev.01/ > > Tentative diff: > http://cr.openjdk.java.net/~vlivanov/8050052/webrev.diff.01-02/ > +1 Paul. From vladimir.x.ivanov at oracle.com Wed Jul 16 07:50:26 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 16 Jul 2014 11:50:26 +0400 Subject: [9] RFR (M): 8050053: Improve caching of different invokers In-Reply-To: References: <53C01252.4070302@oracle.com> <53C5311F.8020202@oracle.com> Message-ID: <53C62EC2.9090601@oracle.com> Thank you, Paul. Best regards, Vladimir Ivanov On 7/16/14 11:28 AM, Paul Sandoz wrote: > > On Jul 15, 2014, at 3:48 PM, Vladimir Ivanov wrote: > >> Update: http://cr.openjdk.java.net/~vlivanov/8050053/webrev.01 >> Diff: http://cr.openjdk.java.net/~vlivanov/8050053/webrev.diff.00-01/ >> >> Got rid of varargs & spread invokers. >> > > +1 > > Paul. > > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From vladimir.x.ivanov at oracle.com Wed Jul 16 07:50:49 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 16 Jul 2014 11:50:49 +0400 Subject: [9] RFR (M): 8050052: Small cleanups in java.lang.invoke code In-Reply-To: References: <53C00E62.20703@oracle.com> <53C3DDC1.4090307@oracle.com> <53C52FD7.8030601@oracle.com> Message-ID: <53C62ED9.1060400@oracle.com> Thank you, Paul. Best regards, Vladimir Ivanov On 7/16/14 11:35 AM, Paul Sandoz wrote: > > On Jul 15, 2014, at 3:42 PM, Vladimir Ivanov wrote: > >> Another update: >> http://cr.openjdk.java.net/~vlivanov/8050052//webrev.01/ >> >> Tentative diff: >> http://cr.openjdk.java.net/~vlivanov/8050052/webrev.diff.01-02/ >> > > +1 > > Paul. > From mark.sheppard at oracle.com Wed Jul 16 08:09:09 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Wed, 16 Jul 2014 09:09:09 +0100 Subject: RFR: 7130985: Four helper classes missing in Sun JDK In-Reply-To: <53C58244.3010409@oracle.com> References: <53C5647B.5000001@oracle.com> <53C58244.3010409@oracle.com> Message-ID: <53C63325.4080407@oracle.com> Hi Alan, we retrieved the IDL from the OMG web site http://www.omg.org/spec/CORBAe/20080201/CORBA_TypeCode.idl to regenerate the Helper classes ... this didn't compile properly and had to be manipulated to get the relevant exceptions required IvalidName is defined in http://www.omg.org/spec/CORBAe/20080201/CORBA_ORB.idl again we extracted the necessary exception and place it in a CORBA module to regenerated the Helper classes the definition for the exception Bounds at the top level CORBA module couldn't be found so it was hand crafted. other IDL located at http://www.omg.org/spec/CORBAe/20080201/ I've placed a reference, in the bug, to record the IDL locations. The OMG also provides a jar, or zip, file containing these generated classes, all of which will throw a not implemented exception in the associated methods of the provided classes. But these form a reference of what is required for a compliant implementation. Furthermore, if we look at the IDL to Java language mapping specifications, the following can be found, which alludes to the inclusion of the referenced helper classes for a compliant implementation: 4.19.2 Certain Exceptions The standard CORBA PIDL uses several exceptions, Bounds, BadKind, and InvalidName. No holder classes are defined for these exceptions, nor are they in the interface repository. However, so that users can treat them as ?normal exceptions? for programming purposes, they are otherwise mapped as normal user exceptions, including the generation of helper classes. They are defined within the scopes that they are used. A Bounds and BadKind exception are defined in the TypeCodePackage for use by TypeCode. A Bounds exception is defined in the standard CORBA module for use by NVList, ExceptionList, and ContextList. An InvalidName exception is defined in the ORBPackage for use by ORB. // Java package org.omg.CORBA; final public class Bounds extends org.omg.CORBA.UserException { public Bounds() {...} } package org.omg.CORBA.TypeCodePackage; final public class Bounds extends org.omg.CORBA.UserException { public Bounds() {...} IDL to Java Language Mapping, v1.3 65 } final public class BadKind extends org.omg.CORBA.UserException { public BadKind() {...} } package org.omg.CORBA.ORBPackage; final public class InvalidName extends org.omg.CORBA.UserException { public InvalidName() {...} } regards Mark On 15/07/2014 20:34, Alan Bateman wrote: > On 15/07/2014 18:27, Rob McKenna wrote: >> Hi folks, >> >> Looking for a review for the following: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-7130985 >> webrev: http://cr.openjdk.java.net/~robm/7130985/webrev.01/ >> >> As per the bug report: The IDLtoJava spec clearly specifies the need >> of the helper class (not the Holder) for these files. But these are >> absent in the JDK. So, if we try to send any of these classes across >> in a client-server rmi-iiop model, it will throw an error complaining >> about the absence of the helper class. > There is clearly a lot of history and would be useful to get > confirmation that these are required for OMG complication. > > As this is generated code then I'm curious where the original source > is. Just wondering if it would make sense to check-in the original > CORBA_TypeCode.idl. > > Do we have any standalone tests that can be used to exercise these > classes? > > -Alan From paul.sandoz at oracle.com Wed Jul 16 08:34:16 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 16 Jul 2014 10:34:16 +0200 Subject: [9] RFR (M): 8050166: Get rid of some package-private methods on arguments in j.l.i.MethodHandle In-Reply-To: <53C3E377.3050603@oracle.com> References: <53C3E377.3050603@oracle.com> Message-ID: On Jul 14, 2014, at 4:04 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8050166/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8050166 > > Get rid of the following methods in j.l.i.MethodHandle: > * convertArguments(MethodType newType) > * bindArgument(int pos, BasicType basicType, Object value) > * bindReceiver(Object receiver) > * dropArguments(MethodType srcType, int pos, int drops) > * permuteArguments(MethodType newType, int[] reorder) > > Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}. > Looks good. Minor points, take it or leave it: MethodHandles. permuteArgumentChecks Might be more preferable for permuteArgumentChecks to return true or false and do the "throw newIllegalArgumentException" on a false return. Then if would play better with it's use in the assert, since it can throw an assertion error. assert target == originalTarget; assert permuteArgumentChecks(reorder, newType, target.type()) : "bad reorder array: "+Arrays.toString(reorder) MethodHandles.insertArgumentPrimitive Might be more consistent to always use a return value in the switch: 2258 switch (w) { 2259 default: intValue = ValueConversions.widenSubword(value); break; 2260 case INT: intValue = (int)value; break; default: return result.bindArgumentI(pos, ValueConversions.widenSubword(value)); case INT: return result.bindArgumentI(pos, (int)value); Paul. From paul.sandoz at oracle.com Wed Jul 16 08:50:59 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 16 Jul 2014 10:50:59 +0200 Subject: [9] RFR (S) 8050173: Generalize BMH.copyWith API to all method handles In-Reply-To: <53C3EB3B.8080103@oracle.com> References: <53C3EB3B.8080103@oracle.com> Message-ID: <5D69CF8C-01C8-43BC-9D9D-60063484899B@oracle.com> On Jul 14, 2014, at 4:37 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8050173/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8050173 > > Added j.l.i.MethodHandle.copyWith(MethodType, LambdaForm) and provided implementation for all subclasses. > > Also, some cleanups: > * rewrote MH.viewAsType on top of MH.copyWith; > * extended MH.viewAsType to do strict checks w/ assertions turned on (new parameter: boolean strict); > * extended MT.isViewableAs to accept both interface preserving and interface erasing conversions (new parameter: boolean keepInterfaces). > > Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}. > > Reviewed-by: vlivanov, ? > Contributed-by: john.r.rose at oracle.com > Looks good, just one comment. MethodHandles.restrictReceiver This method has: 1578 private MethodHandle restrictReceiver(MemberName method, MethodHandle mh, Class caller) throws IllegalAccessException { ... 1589 assert(mh instanceof DirectMethodHandle); // DirectMethodHandle.copyWith Why not make the second parameter be "DirectMethodHandle mh" ? Paul. From paul.sandoz at oracle.com Wed Jul 16 08:57:37 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 16 Jul 2014 10:57:37 +0200 Subject: [9] RFR (XS): 8050174: Support overriding of isInvokeSpecial flag in WrappedMember In-Reply-To: <53C3ED7B.6070702@oracle.com> References: <53C3ED7B.6070702@oracle.com> Message-ID: On Jul 14, 2014, at 4:47 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8050174/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8050174 > > Support overriding of isInvokeSpecial flag in WrappedMember. > > Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}. > > Reviewed-by: vlivanov, ? > Contributed-by: john.r.rose at oracle.com > +1 Paul. From paul.sandoz at oracle.com Wed Jul 16 09:33:23 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 16 Jul 2014 11:33:23 +0200 Subject: [9] RFR (M): 8050057: Improve caching of MethodHandle reinvokers In-Reply-To: <53C3F474.4070708@oracle.com> References: <53C3F474.4070708@oracle.com> Message-ID: On Jul 14, 2014, at 5:17 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8050057/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8050057 > > Cache MethodHandle reinvokers per basic type. > For BoundMethodHandles, rebinding is no-op unless underlying LF is too complex (see BMH::tooComplex() for details). > > Also, introduced DelegatingMethodHandle whose invocation behavior is determined by a target MethodHandle. The delegating MH itself can hold extra "intentions" beyond the simple behavior. > > AsVarargsCollector and WrappedMember are made subclasses of DelegatingMethodHandle. Also, SimpleMethodHandle extends BoundMethodHandle now. > > Rebinding and delegation share same logic and LF shape, but have different caches (LF_REBIND vs LF_DELEGATE). The only difference is their name. They could be consolidated in the future. > > Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}. > > Reviewed-by: vlivanov, ? > Contributed-by: john.r.rose at oracle.com > Looks good. Juste one comment. BoundMethodHandle The following fields can be made final: 132 private static int FIELD_COUNT_THRESHOLD = 12; // largest convenient BMH field count 133 private static int FORM_EXPRESSION_THRESHOLD = 24; // largest convenient BMH expression count Paul. From paul.sandoz at oracle.com Wed Jul 16 10:01:58 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 16 Jul 2014 12:01:58 +0200 Subject: [9] RFR (M): 8050200: Make LambdaForm intrinsics detection more robust In-Reply-To: <53C40EFA.2050305@oracle.com> References: <53C40EFA.2050305@oracle.com> Message-ID: <287BC0A6-9960-4C0D-AEA4-B157E46A6424@oracle.com> On Jul 14, 2014, at 7:10 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8050200/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8050200 > > Replace pattern matching sequences of LambdaForm names during compilation with explicit marks on MethodHandles. Intrinsic ID is associated with a method handle using DelegatingMethodHandle. > > Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}. > > Reviewed-by: vlivanov, ? > Contributed-by: john.r.rose at oracle.com > Looks good. I don't see any usages of the three arg MethodHandleImpl.makeIntrinsic, but i AFAICT such usages will occur further later patches. Paul. From vladimir.x.ivanov at oracle.com Wed Jul 16 10:25:59 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 16 Jul 2014 14:25:59 +0400 Subject: [9] RFR (M): 8050057: Improve caching of MethodHandle reinvokers In-Reply-To: References: <53C3F474.4070708@oracle.com> Message-ID: <53C65337.4020401@oracle.com> Thank you, Paul. > Looks good. Juste one comment. > > BoundMethodHandle > > The following fields can be made final: > 132 private static int FIELD_COUNT_THRESHOLD = 12; // largest convenient BMH field count > 133 private static int FORM_EXPRESSION_THRESHOLD = 24; // largest convenient BMH expression count Agree. Fixed. Best regards, Vladimir Ivanov From vladimir.x.ivanov at oracle.com Wed Jul 16 10:53:36 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 16 Jul 2014 14:53:36 +0400 Subject: [9] RFR (M): 8050166: Get rid of some package-private methods on arguments in j.l.i.MethodHandle In-Reply-To: References: <53C3E377.3050603@oracle.com> Message-ID: <53C659B0.7010507@oracle.com> Paul, thanks for review. On 7/16/14 12:34 PM, Paul Sandoz wrote: > > On Jul 14, 2014, at 4:04 PM, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vlivanov/8050166/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8050166 >> >> Get rid of the following methods in j.l.i.MethodHandle: >> * convertArguments(MethodType newType) >> * bindArgument(int pos, BasicType basicType, Object value) >> * bindReceiver(Object receiver) >> * dropArguments(MethodType srcType, int pos, int drops) >> * permuteArguments(MethodType newType, int[] reorder) >> >> Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}. >> > > Looks good. Minor points, take it or leave it: > > MethodHandles. permuteArgumentChecks > > Might be more preferable for permuteArgumentChecks to return true or false and do the "throw newIllegalArgumentException" on a false return. Then if would play better with it's use in the assert, since it can throw an assertion error. > > assert target == originalTarget; > assert permuteArgumentChecks(reorder, newType, target.type()) : "bad reorder array: "+Arrays.toString(reorder) It's incorrect to split the assert. It's either target & reorder are unchanged or new values pass all checks. And if exception is thrown outside permuteArgumentChecks, we lose detailed error message. So, I'd leave this code as is. > MethodHandles.insertArgumentPrimitive > > Might be more consistent to always use a return value in the switch: > > 2258 switch (w) { > 2259 default: intValue = ValueConversions.widenSubword(value); break; > 2260 case INT: intValue = (int)value; break; > > default: return result.bindArgumentI(pos, ValueConversions.widenSubword(value)); > case INT: return result.bindArgumentI(pos, (int)value); Agree. Fixed. Best regards, Vladimir Ivanov From vladimir.x.ivanov at oracle.com Wed Jul 16 10:57:49 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 16 Jul 2014 14:57:49 +0400 Subject: [9] RFR (M): 8050200: Make LambdaForm intrinsics detection more robust In-Reply-To: <287BC0A6-9960-4C0D-AEA4-B157E46A6424@oracle.com> References: <53C40EFA.2050305@oracle.com> <287BC0A6-9960-4C0D-AEA4-B157E46A6424@oracle.com> Message-ID: <53C65AAD.5070809@oracle.com> Paul, thanks for review. >> http://cr.openjdk.java.net/~vlivanov/8050200/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8050200 >> >> Replace pattern matching sequences of LambdaForm names during compilation with explicit marks on MethodHandles. Intrinsic ID is associated with a method handle using DelegatingMethodHandle. >> >> Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}. >> >> Reviewed-by: vlivanov, ? >> Contributed-by: john.r.rose at oracle.com >> > > Looks good. > > I don't see any usages of the three arg MethodHandleImpl.makeIntrinsic, but i AFAICT such usages will occur further later patches. Yes, it is used for identity [1] and zero [2] intrinics. Best regards, Vladimir Ivanov [1] http://cr.openjdk.java.net/~vlivanov/lfc/patches.latest/12.identity [2] http://cr.openjdk.java.net/~vlivanov/lfc/patches.latest/13.zero From paul.sandoz at oracle.com Wed Jul 16 11:12:18 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 16 Jul 2014 13:12:18 +0200 Subject: [9] RFR (M): 8050166: Get rid of some package-private methods on arguments in j.l.i.MethodHandle In-Reply-To: <53C659B0.7010507@oracle.com> References: <53C3E377.3050603@oracle.com> <53C659B0.7010507@oracle.com> Message-ID: On Jul 16, 2014, at 12:53 PM, Vladimir Ivanov wrote: > Paul, thanks for review. > > On 7/16/14 12:34 PM, Paul Sandoz wrote: >> >> On Jul 14, 2014, at 4:04 PM, Vladimir Ivanov wrote: >> >>> http://cr.openjdk.java.net/~vlivanov/8050166/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8050166 >>> >>> Get rid of the following methods in j.l.i.MethodHandle: >>> * convertArguments(MethodType newType) >>> * bindArgument(int pos, BasicType basicType, Object value) >>> * bindReceiver(Object receiver) >>> * dropArguments(MethodType srcType, int pos, int drops) >>> * permuteArguments(MethodType newType, int[] reorder) >>> >>> Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}. >>> >> >> Looks good. Minor points, take it or leave it: >> >> MethodHandles. permuteArgumentChecks >> >> Might be more preferable for permuteArgumentChecks to return true or false and do the "throw newIllegalArgumentException" on a false return. Then if would play better with it's use in the assert, since it can throw an assertion error. >> >> assert target == originalTarget; >> assert permuteArgumentChecks(reorder, newType, target.type()) : "bad reorder array: "+Arrays.toString(reorder) > It's incorrect to split the assert. It's either target & reorder are unchanged or new values pass all checks. Doh! right it's "||" not "&&". > And if exception is thrown outside permuteArgumentChecks, we lose detailed error message. > > So, I'd leave this code as is. > Fair enough, what i proposed only solves one possible source of IllegalArgumentException,i dunno how fastidious one should be about ensuring asserts throw AssertionError rather than another runtime exception or error that could potentially be handled differently, or be misconstrued as a bug in the assertion code itself. Paul. From forax at univ-mlv.fr Wed Jul 16 11:25:50 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 16 Jul 2014 13:25:50 +0200 Subject: Review request for 8050804: (jdeps) Recommend supported API to replace use of JDK internal API In-Reply-To: <53C5BAD7.1040202@oracle.com> References: <53C5BAD7.1040202@oracle.com> Message-ID: <53C6613E.4090604@univ-mlv.fr> On 07/16/2014 01:35 AM, Mandy Chung wrote: > jdeps -jdkinternals flags use of JDK internal APIs. We have created a > wiki page to keep track of the JDK internal APIs and its replacement: > https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool not sure to understand why Shenandoah is listed in the list related to sun.misc.unsafe, (yes, setting the value of a field or an array location may require to update some GC data structure but it seems far fetched) > > While this page will be updated when we identify any new ones > worthnoting, it'd still be useful for jdeps to suggest the replacement > APIs of the known ones. > > webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8050804/webrev.00/ > > Mandy R?mi From paul.sandoz at oracle.com Wed Jul 16 11:34:31 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 16 Jul 2014 13:34:31 +0200 Subject: Review request for 8050804: (jdeps) Recommend supported API to replace use of JDK internal API In-Reply-To: <53C6613E.4090604@univ-mlv.fr> References: <53C5BAD7.1040202@oracle.com> <53C6613E.4090604@univ-mlv.fr> Message-ID: <8909CD97-8525-4916-BB7E-771E85ACDD47@oracle.com> On Jul 16, 2014, at 1:25 PM, Remi Forax wrote: > > On 07/16/2014 01:35 AM, Mandy Chung wrote: >> jdeps -jdkinternals flags use of JDK internal APIs. We have created a wiki page to keep track of the JDK internal APIs and its replacement: >> https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool > > not sure to understand why Shenandoah is listed in the list related to sun.misc.unsafe, > (yes, setting the value of a field or an array location may require to update some GC data structure but it seems far fetched) > As far as i am aware one use-case for Unsafe is to manage some memory off-heap to reduce GC pause times. Paul. From peter.firmstone at zeus.net.au Wed Jul 16 12:56:46 2014 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 16 Jul 2014 22:56:46 +1000 Subject: Policy Provider and Extensible RMI Performance. Message-ID: <53C6768E.5000504@zeus.net.au> Who said security and RMI had to be performance dogs? Anyone ever notice it's native code that uses all the CPU? 100% CPU Utilisation 0% monitor Peak live threads 99 Test run time 2 minutes. 4891 Remote Object Invocations, includes remote code downloading and class loading (thread confined). Hot Spots - Method Self time [%] Self time Self time (CPU) java.net.SocketInputStream.socketRead0[native]() 37.509655 434975.725 ms 434975.725 ms java.net.DualStackPlainSocketImpl.accept0[native]() 25.825586 299482.984 ms 299482.984 ms java.net.TwoStacksPlainDatagramSocketImpl.socketNativeSetOption[native]() 15.138092 175546.873 ms 175546.873 ms sun.management.ThreadImpl.dumpThreads0[native]() 9.167401 106308.549 ms 106308.549 ms java.net.TwoStacksPlainDatagramSocketImpl.peekData[native]() 7.8661814 91219.129 ms 91219.129 ms java.net.SocketOutputStream.socketWrite0[native]() 1.8873161 21886.01 ms 21886.01 ms Impact of Security (thread confined PermissionCollection's created on demand in optimum order, discarded in CPU cache): java.security.AccessController.doPrivileged[native]() 0.2687941 3117.035 ms 3117.035 ms java.security.AccessController.getStackAccessControlContext[native]() 0.14554662 1687.812 ms 1687.812 ms java.security.AccessControlContext.checkPermission() 0 0.0 ms 0.0 ms com.sun.jini.start.AggregatePolicyProvider$AggregateSecurityContext.setCCL() 0 0.0 ms 0.0 ms org.apache.river.api.security.CombinerSecurityManager$DelegateProtectionDomain.implies() 0 0.0 ms 0.0 ms org.apache.river.api.net.RFC3986URLClassLoader.findClassImpl() 0 0.0 ms 0.0 ms com.sun.proxy.$Proxy5.prepareAndCommit() 0 0.0 ms 0.0 ms com.sun.jini.start.AggregatePolicyProvider.getCurrentSubPolicy() 0 0.0 ms 0.0 ms java.io.ObjectOutputStream.writeProxyDesc() 0 0.0 ms 0.0 ms java.lang.Class.forName() 0 0.0 ms 0.0 ms java.security.ProtectionDomain.implies() 0 0.0 ms 0.0 ms sun.reflect.GeneratedMethodAccessor25.invoke() 0 0.0 ms 0.0 ms com.sun.jini.start.AggregatePolicyProvider.implies() 0 0.0 ms 0.0 ms com.sun.jini.start.AggregatePolicyProvider$AggregateSecurityContext.access$500() 0 0.0 ms 0.0 ms org.apache.river.api.net.RFC3986URLClassLoader.findClass() 0 0.0 ms 0.0 ms net.jini.loader.pref.PreferredClassLoader.loadClass() 0 0.0 ms 0.0 ms java.security.AccessController.getContext() 0 0.0 ms 0.0 ms java.security.AccessController.doPrivileged() 0 0.0 ms 0.0 ms Thread confined classloading (1 Thread per child ClassLoader). java.lang.Class.forName0[native]() 0.030607257 354.933 ms 354.933 ms ant -f C:\\Users\\peter\\Documents\\NetBeansProjects\\peterConcurrentPolicy qa.run-tests qa.run-tests: qa.james-brown: Deleting directory C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa\soul Created dir: C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa\soul Creating C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa\soul\soul.201407162226006985 qa.run-tests: ----------------------------------------- CONFIGURATION FILE: C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa\src\com\sun\jini\test\resources\qaHarness.prop ----------------------------------------- SETTING UP THE TEST LIST: Adding test: com/sun/jini/test/impl/mahalo/RandomStressTest.td ----------------------------------------- GENERAL HARNESS CONFIGURATION INFORMATION: Date started: Wed Jul 16 22:26:08 EST 2014 Installation directory of the JSK: com.sun.jini.jsk.home=C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy Installation directory of the harness: com.sun.jini.qa.home=C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa Categories being tested: categories=No Categories ----------------------------------------- ENVIRONMENT PROPERTIES: JVM information: Java HotSpot(TM) Client VM, 25.0-b70, 32 bit VM mode Oracle Corporation OS information: Windows 7, 6.1, x86 ----------------------------------------- STARTING TO RUN THE TESTS Running com/sun/jini/test/impl/mahalo/RandomStressTest.td Time is Wed Jul 16 22:26:08 EST 2014 Starting test in separate process with command: 'C:\Program Files\Java\jdk1.8.0\jre\bin\java' -Djava.security.manager=org.apache.river.api.security.CombinerSecurityManager -Djava.security.policy=file:/C:/Users/peter/Documents/NetBeansProjects/peterConcurrentPolicy/qa/harness/policy/defaulttest.policy '-Djava.rmi.server.codebase=http://medusa:9082/qa1-share-dl.jar http://medusa:9082/qa1-mahalo-dl.jar' -cp C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa\lib\jiniharness.jar;C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa\lib\jinitests.jar;C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\lib\jsk-platform.jar;C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\lib\jsk-lib.jar;C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\lib\high-scale-lib.jar;C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\lib\custard-apple-1.0.3.jar -ea -esa '-Djava.ext.dirs=C:\Program Files\Java\jdk1.8.0\jre\lib\ext;C:\windows\Sun\Java\lib\ext;C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa\lib-ext;C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\lib-ext' -Dcom.sun.jini.jsk.port=9080 -Dcom.sun.jini.qa.port=9081 -Dcom.sun.jini.jsk.home=C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy -Dcom.sun.jini.qa.home=C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa -Dcom.sun.jini.qa.harness.harnessJar=C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa\lib\jiniharness.jar -Dcom.sun.jini.qa.harness.testJar=C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa\lib\jinitests.jar -Dcom.sun.jini.qa.harness.runjiniserver=true -Dcom.sun.jini.qa.harness.runkitserver=true -Djava.security.properties=file:/C:/Users/peter/Documents/NetBeansProjects/peterConcurrentPolicy/qa/harness/trust/dynamic-policy.properties -Dcom.sun.jini.qa.harness.testhosts= -Djava.util.logging.config.file=C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa\src\com\sun\jini\test\resources\qa1.logging -Djava.rmi.server.useCodebaseOnly=false -Dnet.jini.core.lookup.ServiceRegistrar.portAbitraryIfInUse=true -Dcom.sun.jini.test.home=C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa -Dcom.sun.jini.test.port=9082 -Dcom.sun.jini.qa.harness.policies=file:/C:/Users/peter/Documents/NetBeansProjects/peterConcurrentPolicy/qa/src/com/sun/jini/test/resources/jinitest.policy '-Djava.ext.dirs=C:\Program Files\Java\jdk1.8.0\jre\lib\ext;C:\windows\Sun\Java\lib\ext;C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa\lib-ext;C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\lib-ext' com.sun.jini.qa.harness.MasterTest com/sun/jini/test/impl/mahalo/RandomStressTest.td TIME: 10:26:09 PM MasterTest.doTest INFO: ============================== CALLING CONSTRUCT() ============================== Jul 16, 2014 10:26:09 PM com.sun.jini.tool.ClassServer run INFO: ClassServer started [[C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa\lib\], port 9081] MasterTest.doTest INFO: =============================== CALLING RUN() =============================== RandomStressTest.run INFO: RandomStressTest: To repeat the test, note down the seed RandomStressTest.run INFO: RandomStressTest: seed = 1405513570013 RandomStressTest.run INFO: TEST NOT FINISHED UNTIL I SAY DONE Jul 16, 2014 10:26:10 PM com.sun.jini.tool.ClassServer run INFO: ClassServer started [[C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa\lib\], port 9082] Jul 16, 2014 10:26:10 PM com.sun.jini.tool.ClassServer run INFO: ClassServer started [[C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\lib-dl\], port 9080] NonActGrp-out: Profiler Agent: Waiting for connection on port 5140 (Protocol version: 13) NonActGrp-out: Profiler Agent: Established connection with the tool NonActGrp-out: Profiler Agent: Local accelerated session NonActGrp-out: java.lang.ClassNotFoundException: java/util/LinkedHashMap$KeyIterator NonActGrp-out: at java.lang.Class.forName0(Native Method) NonActGrp-out: at java.lang.Class.forName(Class.java:259) NonActGrp-out: at org.netbeans.lib.profiler.server.ProfilerInterface$InitiateProfilingThread.initiateInstrumentation(ProfilerInterface.java:138) NonActGrp-out: at org.netbeans.lib.profiler.server.ProfilerInterface$InitiateProfilingThread.run(ProfilerInterface.java:100) TIME: 10:27:36 PM RandomStressTest.run INFO: Wait about 15 sec. TIME: 10:27:51 PM RandomStressTest.run INFO: TEST DONE MasterTest.doTest INFO: ============================ CALLING TEARDOWN() ============================= NonActGrp-out: Profiler Agent: Connection with agent closed NonActGrp-out: Profiler Agent: Connection with agent closed NonActGrp-out: Profiler Agent: JNI OnLoad Initializing... NonActGrp-out: Profiler Agent: JNI OnLoad Initialized successfully NonActGrp-out: Profiler Agent: 250 classes cached. Jul 16, 2014 10:27:58 PM com.sun.jini.tool.ClassServer terminate INFO: ClassServer terminated [port 9081] Jul 16, 2014 10:27:58 PM com.sun.jini.tool.ClassServer terminate INFO: ClassServer terminated [port 9081] Jul 16, 2014 10:27:58 PM com.sun.jini.tool.ClassServer terminate INFO: ClassServer terminated [port 9082] Jul 16, 2014 10:27:58 PM com.sun.jini.tool.ClassServer terminate INFO: ClassServer terminated [port 9082] Jul 16, 2014 10:27:58 PM com.sun.jini.tool.ClassServer terminate INFO: ClassServer terminated [port 9080] Jul 16, 2014 10:27:58 PM com.sun.jini.tool.ClassServer terminate INFO: ClassServer terminated [port 9080] TIME: 10:28:03 PM Test process was destroyed and returned code 0 com/sun/jini/test/impl/mahalo/RandomStressTest.td Test Passed: OK ----------------------------------------- SUMMARY ================================= com/sun/jini/test/impl/mahalo/RandomStressTest.td Test Passed: OK ----------------------------------------- # of tests started = 1 # of tests completed = 1 # of tests passed = 1 # of tests failed = 0 ----------------------------------------- Date finished: Wed Jul 16 22:28:08 EST 2014 Time elapsed: 119 seconds qa.collect-result: BUILD SUCCESSFUL (total time: 2 minutes 1 second) From paul.sandoz at oracle.com Wed Jul 16 12:58:25 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 16 Jul 2014 14:58:25 +0200 Subject: Covariant overrides on the Buffer Hierarchy redux Message-ID: <3D27B84B-20F1-486C-954F-E908DD443DA9@oracle.com> Hi, There was discussion here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-April/026458.html https://bugs.openjdk.java.net/browse/JDK-4774077 http://cr.openjdk.java.net/~rwarburton/buffer-overrides-1/ The patch looks good. I have just one comment: can you check the tests to see if there are any redundant casts? After that i will run a JPRT test and then will push for you. Thanks, Paul. From daniel.fuchs at oracle.com Wed Jul 16 13:10:14 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 16 Jul 2014 15:10:14 +0200 Subject: Review request for 8050804: (jdeps) Recommend supported API to replace use of JDK internal API In-Reply-To: <53C5BAD7.1040202@oracle.com> References: <53C5BAD7.1040202@oracle.com> Message-ID: <53C679B6.2050206@oracle.com> Hi Mandy, here is a typical output - with names mangled to save space: s.u.l.p.LPA (rt.jar) -> s.s.a.GP JDK internal API (Use j.s.PA @since 1.1) -> s.u.c.CLDRLPA JDK internal API (rt.jar) In the first dependency line, the archive name has been replaced by the 'Use ...' message. I wonder whether it would be better to keep the archive name and print the use message as additional information, in order to be 'script friendly' so that you could use things like | grep 'rt.jar' on the output. best regards, -- daniel On 7/16/14 1:35 AM, Mandy Chung wrote: > jdeps -jdkinternals flags use of JDK internal APIs. We have created a > wiki page to keep track of the JDK internal APIs and its replacement: > https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool > > While this page will be updated when we identify any new ones > worthnoting, it'd still be useful for jdeps to suggest the replacement > APIs of the known ones. > > webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8050804/webrev.00/ > > Mandy From Alan.Bateman at oracle.com Wed Jul 16 13:42:49 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Jul 2014 14:42:49 +0100 Subject: Covariant overrides on the Buffer Hierarchy redux In-Reply-To: <3D27B84B-20F1-486C-954F-E908DD443DA9@oracle.com> References: <3D27B84B-20F1-486C-954F-E908DD443DA9@oracle.com> Message-ID: <53C68159.5050003@oracle.com> On 16/07/2014 13:58, Paul Sandoz wrote: > Hi, > > There was discussion here: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-April/026458.html > > https://bugs.openjdk.java.net/browse/JDK-4774077 > > http://cr.openjdk.java.net/~rwarburton/buffer-overrides-1/ > > > The patch looks good. > Looks good okay to me too except that @inheritDoc doesn't inherit the runtime exceptions so I assume that @throws will need to be added to ensure that the javadoc is complete. -Alan. From paul.sandoz at oracle.com Wed Jul 16 14:46:23 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 16 Jul 2014 16:46:23 +0200 Subject: JDK 9 RFR of JDK-8030942: Explicitly state floating-point summation requirements on non-finite inputs In-Reply-To: <53C5C77A.5040500@oracle.com> References: <53C5C77A.5040500@oracle.com> Message-ID: <190C8696-2B06-4544-B3C2-562640E44643@oracle.com> On Jul 16, 2014, at 2:29 AM, Joe Darcy wrote: > Hello, > > Please review my changes to address: > > JDK-8030942: Explicitly state floating-point summation requirements on non-finite inputs > http://cr.openjdk.java.net/~darcy/8030942.0/ > > Patch below. > That looks a reasonable description of the constraints. Do those constraints also hold for reduce(0, Double::sum)? I think they might, but want to double check. -- In hindsight i wish that sum was specified to be equivalent to reduce(0, Double::sum). Many developers will be surprised at the performance difference (~4x) between a compensated and uncompensated sum and i do wonder how much importance they place on the former. FWIW i tried to improve the performance, but failed (should take another swing at it): https://bugs.openjdk.java.net/browse/JDK-8035561 I was contemplating making the sum() implement uncompensated and adding a new method compensatedSum(). I suspect you would prefer that to be the other way around with the even more verbose uncompensatedSum() method :-) My motivation for the question above is whether the specification updates will impact which way to go. Paul. From mandy.chung at oracle.com Wed Jul 16 15:09:09 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 16 Jul 2014 08:09:09 -0700 Subject: Review request for 8050804: (jdeps) Recommend supported API to replace use of JDK internal API In-Reply-To: <53C679B6.2050206@oracle.com> References: <53C5BAD7.1040202@oracle.com> <53C679B6.2050206@oracle.com> Message-ID: <53C69595.60000@oracle.com> My first version prints a separate table of the replacements following the new warning message at the end of the jdeps output. I like the first version better than this version replacing rt.jar with "Use..." message. I might be too anxious getting developers to take action using the supported APIs when there is one and hence this version. I'll update the webrev to print as a separate table. thanks Mandy On 7/16/2014 6:10 AM, Daniel Fuchs wrote: > Hi Mandy, > > here is a typical output - with names mangled to save > space: > > s.u.l.p.LPA (rt.jar) > -> s.s.a.GP JDK internal API (Use j.s.PA @since 1.1) > -> s.u.c.CLDRLPA JDK internal API (rt.jar) > > In the first dependency line, the archive name has been replaced > by the 'Use ...' message. > > I wonder whether it would be better to keep the archive name > and print the use message as additional information, in order > to be 'script friendly' so that you could use things like > | grep 'rt.jar' on the output. > > best regards, > > -- daniel > > On 7/16/14 1:35 AM, Mandy Chung wrote: >> jdeps -jdkinternals flags use of JDK internal APIs. We have created a >> wiki page to keep track of the JDK internal APIs and its replacement: >> https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool >> >> While this page will be updated when we identify any new ones >> worthnoting, it'd still be useful for jdeps to suggest the replacement >> APIs of the known ones. >> >> webrev at: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8050804/webrev.00/ >> >> Mandy > From peter.levart at gmail.com Wed Jul 16 15:14:18 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 16 Jul 2014 17:14:18 +0200 Subject: [9] RFR (M): 8050052: Small cleanups in java.lang.invoke code In-Reply-To: <96C06C20-2479-47A2-94F9-49C987AE58A9@oracle.com> References: <53C00E62.20703@oracle.com> <53C02534.2040000@univ-mlv.fr> <96C06C20-2479-47A2-94F9-49C987AE58A9@oracle.com> Message-ID: <53C696CA.3040908@gmail.com> On 07/15/2014 09:51 PM, John Rose wrote: > On Jul 11, 2014, at 10:56 AM, Remi Forax wrote: > >> On 07/11/2014 06:18 PM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8050052/webrev.00 >>> https://bugs.openjdk.java.net/browse/JDK-8050052 >> I've found myself writing the very same code as MethodHandleStatics.uncaughException several times >> and I wonder if it should not be an instance method of Throwable. >> Something like: >> >> public E rethrow(Function uncaughtHandler) { >> if (this instanceof RuntimeException) { >> throw (RuntimeException)this; >> } >> if (this instanceof Error) { >> throw (Error)this; >> } >> return uncaughtHandler.apply(this); >> } >> >> in that case, throw uncaughtException(ex) can be replaced by throw ex.rethrow(::newInternalError); > That's not a bad idea, but (odd for me to say this) it is too easy to use. > > Occasionally there are reasons for *locally* subverting static checking of exceptions, usually because we are writing a framework (like jli) that is polymorphic across exception types. The checking is suppressed in one place so it can be reasserted elsewhere, usually with some concerted wrapping and unwrapped (aka exception tunnelling). An API which assists in doing this would be helpful, but it should be highly specific. In effect it should say "I am temporarily suppressing all checked exceptions except the locally checked ones X, Y, Z, and tunnelling the rest through a wrapper W." try { ... } catch (X | Y | Z e) { throw e; } catch (Throwable t) { throw new W(t); } Could it be written more concise and with same flexibility using an API trick? Or do you have some language trick in mind which would take into account the list of declared exception types on the method like: void m() throws X, Y, Z, W { try { ... } catch (@NotDeclared Throwable t) { // meaning: Throwable & !(X | Y | Z| W) throw new W(t); } } or even: void m() throws X, Y, Z, @WrapRestWith W { ... } Regards, Peter > > A secondary point is that the wrapper should generally not be something really general like "Error"; perhaps "InternalError" or "AssertionError" would be more helpful. But sometimes it needs to be a single *checked* exception. I guess I'm saying the API needs careful definition. Time for a JEP (but not mine!). > > It's an esthetic point, but "rethrow" is too breezy and quick to fully communicate valid intentions (as sketched above), and too ready to ease subversion of checks. Imagine the stack overflow articles saying, "hate Java exception checks? just type the following to get rid of them all!" Don't. Want. > > ? John From joe.darcy at oracle.com Wed Jul 16 15:39:34 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 16 Jul 2014 08:39:34 -0700 Subject: JDK 9 RFR of JDK-8030942: Explicitly state floating-point summation requirements on non-finite inputs In-Reply-To: <190C8696-2B06-4544-B3C2-562640E44643@oracle.com> References: <53C5C77A.5040500@oracle.com> <190C8696-2B06-4544-B3C2-562640E44643@oracle.com> Message-ID: <53C69CB6.4020905@oracle.com> Hi Paul, On 07/16/2014 07:46 AM, Paul Sandoz wrote: > On Jul 16, 2014, at 2:29 AM, Joe Darcy wrote: > >> Hello, >> >> Please review my changes to address: >> >> JDK-8030942: Explicitly state floating-point summation requirements on non-finite inputs >> http://cr.openjdk.java.net/~darcy/8030942.0/ >> >> Patch below. >> > That looks a reasonable description of the constraints. Do those constraints also hold for reduce(0, Double::sum)? I think they might, but want to double check. Yes, those constraints are also true for a simple summation. > > -- > > In hindsight i wish that sum was specified to be equivalent to reduce(0, Double::sum). Many developers will be surprised at the performance difference (~4x) between a compensated and uncompensated sum and i do wonder how much importance they place on the former. FWIW i tried to improve the performance, but failed (should take another swing at it): > > https://bugs.openjdk.java.net/browse/JDK-8035561 > > I was contemplating making the sum() implement uncompensated and adding a new method compensatedSum(). I suspect you would prefer that to be the other way around with the even more verbose uncompensatedSum() method :-) Your suspicion is correct :-) > My motivation for the question above is whether the specification updates will impact which way to go. > > Paul. There is often a tension between safety and speed; floating-point summation is one of those cases. Simple summation is "dangerous" since it is easy to find cases where the result is arbitrarily far from the true result. If you don't care what is computed, why do you care how fast it is computed? ;-) I have more faith that Java developers who are frustrated at the slower performance of sum() will figure out how to do reduce(0, Double::sum) than I have that developers will first, be aware of a floating-point rounding problem and second, code up compensated summation to fix it. That said, I don't oppose including a "quickSum" method to these classes. Thanks,g -Joe From forax at univ-mlv.fr Wed Jul 16 15:39:38 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 16 Jul 2014 17:39:38 +0200 Subject: [9] RFR (M): 8050052: Small cleanups in java.lang.invoke code In-Reply-To: <96C06C20-2479-47A2-94F9-49C987AE58A9@oracle.com> References: <53C00E62.20703@oracle.com> <53C02534.2040000@univ-mlv.fr> <96C06C20-2479-47A2-94F9-49C987AE58A9@oracle.com> Message-ID: <53C69CBA.1050903@univ-mlv.fr> On 07/15/2014 09:51 PM, John Rose wrote: > On Jul 11, 2014, at 10:56 AM, Remi Forax wrote: > >> On 07/11/2014 06:18 PM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8050052/webrev.00 >>> https://bugs.openjdk.java.net/browse/JDK-8050052 >> I've found myself writing the very same code as MethodHandleStatics.uncaughException several times >> and I wonder if it should not be an instance method of Throwable. >> Something like: >> >> public E rethrow(Function uncaughtHandler) { >> if (this instanceof RuntimeException) { >> throw (RuntimeException)this; >> } >> if (this instanceof Error) { >> throw (Error)this; >> } >> return uncaughtHandler.apply(this); >> } >> >> in that case, throw uncaughtException(ex) can be replaced by throw ex.rethrow(::newInternalError); > That's not a bad idea, but (odd for me to say this) it is too easy to use. Maybe, but compared to the code people write now when they have to manage a Throwable or an Exception, i think it's still a win (checked exceptions and unchecked exceptions flows are rarely separated :( ). I agree that the name should be changed because it convey a wrong message (see below). Anyway, if IDEs still propose "throws" instead of "try/catch" as their first quickfix, the Java world will not sink. > Occasionally there are reasons for *locally* subverting static checking of exceptions, usually because we are writing a framework (like jli) that is polymorphic across exception types. Not only when writing framework, you need this method in user code too when you use an API that wrap all exceptions in an exception (usually checked) try { return methodHandle.invokeExact(...); } catch(Throwable t) { // what I'm expected to write here } or try { return future.get(); } catch(ExecutionException e) { // what I'm expected to write here } and you can also use it to tunnel a checked exception into another checked exception. > The checking is suppressed in one place so it can be reasserted elsewhere, usually with some concerted wrapping and unwrapped (aka exception tunnelling). An API which assists in doing this would be helpful, but it should be highly specific. In effect it should say "I am temporarily suppressing all checked exceptions except the locally checked ones X, Y, Z, and tunnelling the rest through a wrapper W." The API doesn't have to manage checked exception X, Y, Z because most of the time you will use this method in a catch block, so you can have more catch blocks on top of the catch block that use the method. > > A secondary point is that the wrapper should generally not be something really general like "Error"; perhaps "InternalError" or "AssertionError" would be more helpful. But sometimes it needs to be a single *checked* exception. I guess I'm saying the API needs careful definition. Time for a JEP (but not mine!). yes, the wrapper exception is different for each use case, that why the method takes a java.util.function.Function as parameter, to ask the user to specify the wrapper exception. > > It's an esthetic point, but "rethrow" is too breezy and quick to fully communicate valid intentions (as sketched above), and too ready to ease subversion of checks. I agree, "tunnel" is maybe better, at least it's meaning is darker :) anyway, I'm not good at name, I'm sure someone can come with a better name. > Imagine the stack overflow articles saying, "hate Java exception checks? just type the following to get rid of them all!" Don't. Want. SO question/answers are usually more balanced from my opinion (if people don't stop reading after the first answer). And as I said, it will be better than letting people to write their own code. BTW, it occurs to me that instead of using several instanceof, the method "tunnel" can have several overrides, ones for Throwable, RuntimeException and Error. > > ? John R?mi From pavel.rappo at oracle.com Wed Jul 16 15:41:40 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 16 Jul 2014 16:41:40 +0100 Subject: RFR JDK-8050869: Convert runtime dependency to Applet to a static dependency in cosnaming In-Reply-To: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> Message-ID: Hi everyone, Could you please review my change for JDK-8050869? http://cr.openjdk.java.net/~prappo/8050869/webrev.00/ Thanks -Pavel From huizhe.wang at oracle.com Wed Jul 16 15:47:07 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 16 Jul 2014 08:47:07 -0700 Subject: RFR (JAXP): 8049514: FEATURE_SECURE_PROCESSING can not be turned off on a validator through SchemaFactory Message-ID: <53C69E7B.0@oracle.com> Hi, JAXP SecurityManager was re-designed to XMLSecurityManager to manage jaxp related limits or restrictions. Previously, the existence of a SecurityManager was equivalent to setting FEATURE_SECURE_PROCESSING to true. After the change, secure processing became a property of XMLSecurityManager, thus needs to be queried in order to determine the status of secure processing. Since secure processing is true by default, this bug made it impossible to turn off secure processing on a validator through the factory when there is no Java Security Manager. Please review: http://cr.openjdk.java.net/~joehw/jdk9/8049514/webrev/ Thanks, Joe From chris.hegarty at oracle.com Wed Jul 16 15:59:25 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 16 Jul 2014 16:59:25 +0100 Subject: RFR JDK-8050869: Convert runtime dependency to Applet to a static dependency in cosnaming In-Reply-To: References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> Message-ID: <53C6A15D.1050707@oracle.com> This looks like a reasonable reversal of 6898747 [1], so good for me. -Chris. [1] http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/a368ebcfeeb6 On 16/07/14 16:41, Pavel Rappo wrote: > Hi everyone, > > Could you please review my change for JDK-8050869? > > http://cr.openjdk.java.net/~prappo/8050869/webrev.00/ > > Thanks > -Pavel > From Alan.Bateman at oracle.com Wed Jul 16 15:59:15 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Jul 2014 16:59:15 +0100 Subject: RFR JDK-8050869: Convert runtime dependency to Applet to a static dependency in cosnaming In-Reply-To: References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> Message-ID: <53C6A153.2040809@oracle.com> On 16/07/2014 16:41, Pavel Rappo wrote: > Hi everyone, > > Could you please review my change for JDK-8050869? > > http://cr.openjdk.java.net/~prappo/8050869/webrev.00/ > This looks okay to me too. As we've since established, this dependency is no longer an issue. -Alan From paul.sandoz at oracle.com Wed Jul 16 16:05:33 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 16 Jul 2014 18:05:33 +0200 Subject: JDK 9 RFR of JDK-8030942: Explicitly state floating-point summation requirements on non-finite inputs In-Reply-To: <53C69CB6.4020905@oracle.com> References: <53C5C77A.5040500@oracle.com> <190C8696-2B06-4544-B3C2-562640E44643@oracle.com> <53C69CB6.4020905@oracle.com> Message-ID: <45AEBA50-86E8-4D36-84C5-764F6FD1648C@oracle.com> On Jul 16, 2014, at 5:39 PM, Joe Darcy wrote: > Hi Paul, > > On 07/16/2014 07:46 AM, Paul Sandoz wrote: >> On Jul 16, 2014, at 2:29 AM, Joe Darcy wrote: >> >>> Hello, >>> >>> Please review my changes to address: >>> >>> JDK-8030942: Explicitly state floating-point summation requirements on non-finite inputs >>> http://cr.openjdk.java.net/~darcy/8030942.0/ >>> >>> Patch below. >>> >> That looks a reasonable description of the constraints. Do those constraints also hold for reduce(0, Double::sum)? I think they might, but want to double check. > > Yes, those constraints are also true for a simple summation. > Ok. +1 from me for the review. > There is often a tension between safety and speed; floating-point summation is one of those cases. Simple summation is "dangerous" since it is easy to find cases where the result is arbitrarily far from the true result. If you don't care what is computed, why do you care how fast it is computed? ;-) Certainly if sum() always returned 0.0 that would be a problem. I think in reality it is more nuanced regarding the interval of which the actual sum would be within. (As an aside i wish we had support interval arithmetic.) > I have more faith that Java developers who are frustrated at the slower performance of sum() will figure out how to do reduce(0, Double::sum) than I have that developers will first, be aware of a floating-point rounding problem and second, code up compensated summation to fix it. > That's a fair point, but i don't have a sense of how problematic an uncompensated sum is for developers. Perhaps we can add an apiNote to the sum method mentioning performance? > That said, I don't oppose including a "quickSum" method to these classes. > OK, or even "basicSum". Pail. From vladimir.x.ivanov at oracle.com Wed Jul 16 16:28:26 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 16 Jul 2014 20:28:26 +0400 Subject: [9] RFR (M): 8050877: Improve code for pairwise argument conversions and value boxing/unboxing Message-ID: <53C6A82A.8060501@oracle.com> http://cr.openjdk.java.net/~vlivanov/8050877/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8050877 Improved MethodHandleImpl.makePairwiseConvert & ValueConversions.unbox and small cleanups in related code. Also, improved method handle caching in ValueConversions. MethodHandleImpl.makePairwiseConvert: - * @param level which strength of conversion is allowed + * @param strict if true, only asType conversions are allowed; if false, explicitCastArguments conversions allowed + * @param monobox if true, unboxing conversions are assumed to be exactly typed (Integer to int only, not long or double) ValueConversions.unbox: - private static MethodHandle unbox(Wrapper wrap, boolean cast) { + private static MethodHandle unbox(Wrapper wrap, int kind) { + // kind 0 -> strongly typed with NPE + // kind 1 -> strongly typed but zero for null, + // kind 2 -> asType rules: accept multiple box types but only widening conversions with NPE + // kind 3 -> explicitCastArguments rules: allow narrowing conversions, zero for null + WrapperCache cache = UNBOX_CONVERSIONS[kind]; Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}. Reviewed-by: vlivanov, ? Contributed-by: john.r.rose at oracle.com Thanks! Best regards, Vladimir Ivanov From vladimir.x.ivanov at oracle.com Wed Jul 16 16:44:46 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 16 Jul 2014 20:44:46 +0400 Subject: [9] RFR (M): 8050884: Intrinsify ValueConversions.identity() functions Message-ID: <53C6ABFE.2040004@oracle.com> http://cr.openjdk.java.net/~vlivanov/8050884/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8050884 Replace ValueConversions.identity() functions with intrinsics. Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}. Reviewed-by: vlivanov, ? Contributed-by: john.r.rose at oracle.com Thanks! Best regards, Vladimir Ivanov From vladimir.x.ivanov at oracle.com Wed Jul 16 16:57:11 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 16 Jul 2014 20:57:11 +0400 Subject: [9] RFR (S): 8050887: Intrinsify constants for default values Message-ID: <53C6AEE7.8090306@oracle.com> http://cr.openjdk.java.net/~vlivanov/8050887/webrev.00 https://bugs.openjdk.java.net/browse/JDK-8050887 Intrinsify MethodHandles.constant() for default values. Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}. Reviewed-by: vlivanov, ? Contributed-by: john.r.rose at oracle.com Thanks! Best regards, Vladimir Ivanov From mandy.chung at oracle.com Wed Jul 16 17:08:03 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 16 Jul 2014 10:08:03 -0700 Subject: RFR JDK-8050869: Convert runtime dependency to Applet to a static dependency in cosnaming In-Reply-To: <53C6A15D.1050707@oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> <53C6A15D.1050707@oracle.com> Message-ID: <53C6B173.2050900@oracle.com> On 7/16/14 8:59 AM, Chris Hegarty wrote: > This looks like a reasonable reversal of 6898747 [1], so good for me. Yes this dependency is no longer an issue. It looks okay to keep the static reference. Mandy > > -Chris. > > [1] http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/a368ebcfeeb6 > > > > On 16/07/14 16:41, Pavel Rappo wrote: >> Hi everyone, >> >> Could you please review my change for JDK-8050869? >> >> http://cr.openjdk.java.net/~prappo/8050869/webrev.00/ >> >> Thanks >> -Pavel >> From peter.levart at gmail.com Wed Jul 16 18:20:40 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 16 Jul 2014 20:20:40 +0200 Subject: [9] RFR (M): 8050052: Small cleanups in java.lang.invoke code In-Reply-To: <53C696CA.3040908@gmail.com> References: <53C00E62.20703@oracle.com> <53C02534.2040000@univ-mlv.fr> <96C06C20-2479-47A2-94F9-49C987AE58A9@oracle.com> <53C696CA.3040908@gmail.com> Message-ID: <53C6C278.4060505@gmail.com> On 07/16/2014 05:14 PM, Peter Levart wrote: > On 07/15/2014 09:51 PM, John Rose wrote: >> On Jul 11, 2014, at 10:56 AM, Remi Forax wrote: >> >>> On 07/11/2014 06:18 PM, Vladimir Ivanov wrote: >>>> http://cr.openjdk.java.net/~vlivanov/8050052/webrev.00 >>>> https://bugs.openjdk.java.net/browse/JDK-8050052 >>> I've found myself writing the very same code as >>> MethodHandleStatics.uncaughException several times >>> and I wonder if it should not be an instance method of Throwable. >>> Something like: >>> >>> public E rethrow(Function>> extends E> uncaughtHandler) { >>> if (this instanceof RuntimeException) { >>> throw (RuntimeException)this; >>> } >>> if (this instanceof Error) { >>> throw (Error)this; >>> } >>> return uncaughtHandler.apply(this); >>> } >>> >>> in that case, throw uncaughtException(ex) can be replaced by throw >>> ex.rethrow(::newInternalError); >> That's not a bad idea, but (odd for me to say this) it is too easy to >> use. >> >> Occasionally there are reasons for *locally* subverting static >> checking of exceptions, usually because we are writing a framework >> (like jli) that is polymorphic across exception types. The checking >> is suppressed in one place so it can be reasserted elsewhere, usually >> with some concerted wrapping and unwrapped (aka exception >> tunnelling). An API which assists in doing this would be helpful, >> but it should be highly specific. In effect it should say "I am >> temporarily suppressing all checked exceptions except the locally >> checked ones X, Y, Z, and tunnelling the rest through a wrapper W." > > try { > ... > } catch (X | Y | Z e) { > throw e; > } catch (Throwable t) { > throw new W(t); > } Ops, it should be: try { ... } catch (X | Y | Z | RuntimeException | Error e) { throw e; } catch (Throwable t) { throw new W(t); } ... and it's not so concise any more. And it's easy to make a mistake ;-). But Remi is right when he says that an API does not have to be concerned about managing locally checked X, Y, Z since they can be handled by normal catch block(s) before the last catch (Throwable). About the name of such Throwable instance method (using Stream terminology): mapIfChecked(Function); // ElseThrow is implicit An alternative could be: public Throwable throwIfUnchecked() { if (this instanceof RuntimeException) throw (RuntimeException) this; if (this instanceof Error) throw (Error) this; return this; } Then use it like: try { ... } catch (Throwable t) { throw new WrapperException(t.throwIfUnchecked()); } Regards, Peter From jeffhain at rocketmail.com Wed Jul 16 20:31:25 2014 From: jeffhain at rocketmail.com (Jeff Hain) Date: Wed, 16 Jul 2014 21:31:25 +0100 Subject: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size In-Reply-To: <53C3D7C6.1080205@gmail.com> References: <53B57E16.5020802@oracle.com> <53BBEB6E.7050207@oracle.com> <53BC08DA.4020007@gmail.com> <53BC6506.3060308@oracle.com> <53BC6640.9020508@gmail.com> <53BC6B6F.6000709@oracle.com> <53BC73D7.7020900@gmail.com> <53BC8BF0.7000601@oracle.com> <53BCEDD4.6010906@gmail.com> <53BCF049.8090303@gmail.com> <53BDBF94.7040208@gmail.com> <53C03645.6090900@cs.oswego.edu> <53C15896.9070001@gmail.com> <53C17A81.2000200@gm! ail.com> <53C19E9C.7070306@oracle.com> <53C1B987.6030609@gmail.com> <1405250677.3551.YahooMailNeo@web172402.mail.ir2.yahoo.com> <53C2A4EB.4000204@gmail.com> <1405297486.34865.YahooMailNeo@web172405.mail.ir2.yahoo.com> <53C3D7C6.1080205@gmail.com> Message-ID: <1405542685.49039.YahooMailNeo@web172406.mail.ir2.yahoo.com> Hi, took me some time to setup Maven/JMH and learn the basics. (two tools in a day, phew, that's more than I usually do in a year! :) >JIT can sometimes optimize the code so aggressively I was trying to bench this aggressively optimized version of the code, with the idea that: - If the JVM thinks this code is not to be optimized, ? it should not slow down the program too much, and ? having clean code should suffice. - If it decides to optimize it, then the optimized ? version must be the fastest possible, not to slow ? down the whole program. ? In particular, I've once "seen" some optimization actually ? slow things down (a cast from double to int, that was ? intentionally duplicated, got factored in common path, ? assuming that it was necessarily fast, but it wasn't... ? so I replaced one of the "(int)x" with "-(int)-x" and ? the awful perfs went away). But I agree I have no clue whether the optimization would be similar in another program. >I suggest you try to express your benchmark in a tried framework like JMH: > > ? ?http://openjdk.java.net/projects/code-tools/jmh/ > >In particular I suggest studying included samples. > >Regards, Peter Below the JMH version of my neanderthalian bench :) followed by some results (with 1.7 bytecode, win7, core i7), then a bench similar to the one you posted (http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-July/027681.html), and results again. @State(Scope.Thread) public class JmhIHMBench { ? ? private static final int MAX_NBR_OF_MAPPINGS = 1*1000; ? ?? ? ? final Map map_original = new IdentityHashMap(); ? ? // etc. ? ? final Map map_peter8noloop = new IdentityHashMapPeter8NoLoop(); ? ? Object[] keys; ? ? int i; ? ? private static Object[] newKeys(int size) { ? ? ? ? final Object[] keys = new Object[size]; ? ? ? ? for (int i=0;i map) { ? ? ? ? if (map.size() == MAX_NBR_OF_MAPPINGS) { ? ? ? ? ? ? map.clear(); ? ? ? ? ? ? i = 0; ? ? ? ? } ? ? ? ? final Object kv = keys[i++]; ? ? ? ? bh.consume(map.put(kv, kv)); ? ? } ? ?? ? ? public static void main(String[] args) throws RunnerException { ? ? ? ? Options opt = new OptionsBuilder() ? ? ? ? ? ? ? ? .include(".*" + JmhIHMBench.class.getSimpleName() + ".*") ? ? ? ? ? ? ? ? .warmupIterations(8) ? ? ? ? ? ? ? ? .measurementIterations(10) ? ? ? ? ? ? ? ? .threads(1) ? ? ? ? ? ? ? ? .forks(1) ? ? ? ? ? ? ? ? .shouldDoGC(false) ? ? ? ? ? ? ? ? .build(); ? ? ? ? new Runner(opt).run(); ? ? } } ? ? /* ? ? ?* jdk7u51 (run 1): Benchmark ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Mode ? Samples ? ? ? ?Score ?Score error ? ?Units r.JmhIHMBench.bench_put_original ? ? ? ?thrpt ? ? ? ?10 84087111,944 ?6033159,942 ? ?ops/s r.JmhIHMBench.bench_put_peter7 ? ? ? ? ?thrpt ? ? ? ?10 68893501,546 ?1375694,507 ? ?ops/s r.JmhIHMBench.bench_put_peter7noloop ? ?thrpt ? ? ? ?10 79900659,706 ?6637125,685 ? ?ops/s r.JmhIHMBench.bench_put_peter8 ? ? ? ? ?thrpt ? ? ? ?10 79062559,130 ?1392057,456 ? ?ops/s r.JmhIHMBench.bench_put_peter8noloop ? ?thrpt ? ? ? ?10 89184331,506 ?2380981,771 ? ?ops/s ? ? ?*/ ? ? /* ? ? ?* jdk7u51 (run 2): Benchmark ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Mode ? Samples ? ? ? ?Score ?Score error ? ?Units r.JmhIHMBench.bench_put_original ? ? ? ?thrpt ? ? ? ?10 90430298,285 ?1749471,171 ? ?ops/s r.JmhIHMBench.bench_put_peter7 ? ? ? ? ?thrpt ? ? ? ?10 77895700,268 ?1118205,815 ? ?ops/s r.JmhIHMBench.bench_put_peter7noloop ? ?thrpt ? ? ? ?10 87449460,422 ?2241899,330 ? ?ops/s r.JmhIHMBench.bench_put_peter8 ? ? ? ? ?thrpt ? ? ? ?10 79993955,944 ?1799749,550 ? ?ops/s r.JmhIHMBench.bench_put_peter8noloop ? ?thrpt ? ? ? ?10 89818256,344 ? 886977,083 ? ?ops/s ? ? ?*/ ? ? /* ? ? ?* jdk8u20 (run 1): Benchmark ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Mode ? Samples ? ? ? ?Score ?Score error ? ?Units r.JmhIHMBench.bench_put_original ? ? ? ?thrpt ? ? ? ?10 108675548,411 ?7130886,988 ? ?ops/s r.JmhIHMBench.bench_put_peter7 ? ? ? ? ?thrpt ? ? ? ?10 94452557,383 ?4030609,636 ? ?ops/s r.JmhIHMBench.bench_put_peter7noloop ? ?thrpt ? ? ? ?10 99070373,936 ?2204912,685 ? ?ops/s r.JmhIHMBench.bench_put_peter8 ? ? ? ? ?thrpt ? ? ? ?10 106865766,992 ?6248051,431 ? ?ops/s r.JmhIHMBench.bench_put_peter8noloop ? ?thrpt ? ? ? ?10 114880028,516 ?1176180,414 ? ?ops/s ? ? ?*/ ? ? /* ? ? ?* jdk8u20 (run 2): Benchmark ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Mode ? Samples ? ? ? ?Score ?Score error ? ?Units r.JmhIHMBench.bench_put_original ? ? ? ?thrpt ? ? ? ?10 117513077,228 ?2011080,121 ? ?ops/s r.JmhIHMBench.bench_put_peter7 ? ? ? ? ?thrpt ? ? ? ?10 108988770,194 ?1468043,321 ? ?ops/s r.JmhIHMBench.bench_put_peter7noloop ? ?thrpt ? ? ? ?10 84796057,588 ?2641680,027 ? ?ops/s r.JmhIHMBench.bench_put_peter8 ? ? ? ? ?thrpt ? ? ? ?10 106910134,068 ?1880471,925 ? ?ops/s r.JmhIHMBench.bench_put_peter8noloop ? ?thrpt ? ? ? ?10 116141855,333 ?3003362,217 ? ?ops/s ? ? ?*/ ? ? /* jdk9 (run 1): Benchmark ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Mode ? Samples ? ? ? ?Score ?Score error ? ?Units r.JmhIHMBench.bench_put_original ? ? ? ?thrpt ? ? ? ?10 99263492,210 ?2022006,733 ? ?ops/s r.JmhIHMBench.bench_put_peter7 ? ? ? ? ?thrpt ? ? ? ?10 92134658,090 ?1614673,726 ? ?ops/s r.JmhIHMBench.bench_put_peter7noloop ? ?thrpt ? ? ? ?10 114824216,039 13609878,167 ? ?ops/s r.JmhIHMBench.bench_put_peter8 ? ? ? ? ?thrpt ? ? ? ?10 105875616,712 ?2756803,410 ? ?ops/s r.JmhIHMBench.bench_put_peter8noloop ? ?thrpt ? ? ? ?10 115453779,958 ?2121710,424 ? ?ops/s ? ? ?*/ ? ? /* jdk9 (run 2): Benchmark ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Mode ? Samples ? ? ? ?Score ?Score error ? ?Units r.JmhIHMBench.bench_put_original ? ? ? ?thrpt ? ? ? ?10 124206227,820 ?5152351,422 ? ?ops/s r.JmhIHMBench.bench_put_peter7 ? ? ? ? ?thrpt ? ? ? ?10 106268224,078 ?2613094,225 ? ?ops/s r.JmhIHMBench.bench_put_peter7noloop ? ?thrpt ? ? ? ?10 119525275,412 11532080,356 ? ?ops/s r.JmhIHMBench.bench_put_peter8 ? ? ? ? ?thrpt ? ? ? ?10 111851070,168 ?3486096,205 ? ?ops/s r.JmhIHMBench.bench_put_peter8noloop ? ?thrpt ? ? ? ?10 112861864,414 ?1780180,439 ? ?ops/s ? ? ?*/ @State(Scope.Thread) public class PeterIHMBench { ? ? private static final int MAX_SIZE = 100*1000; ? ?? ? ? Map map_original = new IdentityHashMap(); ? ? // etc. ? ? Map map_peter8noloop = new IdentityHashMapPeter8NoLoop(); ? ? @Benchmark ? ? public void putNewObject_original(Blackhole bh) { ? ? ? ? Object o = new Object(); ? ? ? ? bh.consume(map_original.put(o, o)); ? ? ? ? if (map_original.size() == MAX_SIZE) { ? ? ? ? ? ? map_original = new IdentityHashMap(); ? ? ? ? } ? ? } ? ? // etc. ? ? @Benchmark ? ? public void putNewObject_peter8noloop(Blackhole bh) { ? ? ? ? Object o = new Object(); ? ? ? ? bh.consume(map_peter8noloop.put(o, o)); ? ? ? ? if (map_peter8noloop.size() == MAX_SIZE) { ? ? ? ? ? ? map_peter8noloop = new IdentityHashMapPeter8NoLoop(); ? ? ? ? } ? ? } ? ? public static void main(String[] args) throws RunnerException { ? ? ? ? Options opt = new OptionsBuilder() ? ? ? ? ? ? ? ? .include(".*" + PeterIHMBench.class.getSimpleName() + ".*") ? ? ? ? ? ? ? ? .warmupIterations(8) ? ? ? ? ? ? ? ? .measurementIterations(10) ? ? ? ? ? ? ? ? .threads(1) ? ? ? ? ? ? ? ? .forks(1) ? ? ? ? ? ? ? ? .shouldDoGC(true) ? ? ? ? ? ? ? ? .build(); ? ? ? ? new Runner(opt).run(); ? ? } } ? ? /* ? ? ?* jdk7u51 (run 1): Benchmark ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Mode ? Samples ? ? ? ?Score ?Score error ? ?Units r.PeterIHMBench.putNewObject_original ? ? ? ?thrpt ? ? ? ?10 10004525,783 ? 462787,537 ? ?ops/s r.PeterIHMBench.putNewObject_peter7 ? ? ? ? ?thrpt ? ? ? ?10 ?9892505,005 ? 214656,134 ? ?ops/s r.PeterIHMBench.putNewObject_peter7noloop ? ?thrpt ? ? ? ?10 11604018,473 ? 254339,445 ? ?ops/s r.PeterIHMBench.putNewObject_peter8 ? ? ? ? ?thrpt ? ? ? ?10 11498803,030 ? 294423,574 ? ?ops/s r.PeterIHMBench.putNewObject_peter8noloop ? ?thrpt ? ? ? ?10 11507933,087 ? 194513,444 ? ?ops/s ? ? ?*/ ? ? /* ? ? ?* jdk7u51 (run 2): Benchmark ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Mode ? Samples ? ? ? ?Score ?Score error ? ?Units r.PeterIHMBench.putNewObject_original ? ? ? ?thrpt ? ? ? ?10 11697308,687 ? 193861,487 ? ?ops/s r.PeterIHMBench.putNewObject_peter7 ? ? ? ? ?thrpt ? ? ? ?10 11560736,048 ? 277497,212 ? ?ops/s r.PeterIHMBench.putNewObject_peter7noloop ? ?thrpt ? ? ? ?10 11797755,781 ? 271441,458 ? ?ops/s r.PeterIHMBench.putNewObject_peter8 ? ? ? ? ?thrpt ? ? ? ?10 11467002,211 ? 152606,682 ? ?ops/s r.PeterIHMBench.putNewObject_peter8noloop ? ?thrpt ? ? ? ?10 11359696,213 ? 109906,982 ? ?ops/s ? ? ?*/ ? ? /* ? ? ?* jdk8u20 (run 1): Benchmark ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Mode ? Samples ? ? ? ?Score ?Score error ? ?Units r.PeterIHMBench.putNewObject_original ? ? ? ?thrpt ? ? ? ?10 10556637,295 ? 543838,781 ? ?ops/s r.PeterIHMBench.putNewObject_peter7 ? ? ? ? ?thrpt ? ? ? ?10 10442158,366 ? 157466,040 ? ?ops/s r.PeterIHMBench.putNewObject_peter7noloop ? ?thrpt ? ? ? ?10 11626264,545 ? 196058,218 ? ?ops/s r.PeterIHMBench.putNewObject_peter8 ? ? ? ? ?thrpt ? ? ? ?10 11340692,293 ? 147050,945 ? ?ops/s r.PeterIHMBench.putNewObject_peter8noloop ? ?thrpt ? ? ? ?10 11227256,662 ? 248432,999 ? ?ops/s ? ? ?*/ ? ? /* ? ? ?* jdk8u20 (run 2): Benchmark ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Mode ? Samples ? ? ? ?Score ?Score error ? ?Units r.PeterIHMBench.putNewObject_original ? ? ? ?thrpt ? ? ? ?10 11685284,152 ? 273100,180 ? ?ops/s r.PeterIHMBench.putNewObject_peter7 ? ? ? ? ?thrpt ? ? ? ?10 11816196,692 ? 204855,265 ? ?ops/s r.PeterIHMBench.putNewObject_peter7noloop ? ?thrpt ? ? ? ?10 11869428,586 ? 245642,096 ? ?ops/s r.PeterIHMBench.putNewObject_peter8 ? ? ? ? ?thrpt ? ? ? ?10 11451236,836 ? 167196,443 ? ?ops/s r.PeterIHMBench.putNewObject_peter8noloop ? ?thrpt ? ? ? ?10 11220115,248 ? 479475,990 ? ?ops/s ? ? ?*/ ? ? /* ? ? ?* jdk9 (run 1): Benchmark ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Mode ? Samples ? ? ? ?Score ?Score error ? ?Units r.PeterIHMBench.putNewObject_original ? ? ? ?thrpt ? ? ? ?10 10225815,691 ? 327563,053 ? ?ops/s r.PeterIHMBench.putNewObject_peter7 ? ? ? ? ?thrpt ? ? ? ?10 10419083,948 ? 300111,842 ? ?ops/s r.PeterIHMBench.putNewObject_peter7noloop ? ?thrpt ? ? ? ?10 11530842,399 ? 195856,714 ? ?ops/s r.PeterIHMBench.putNewObject_peter8 ? ? ? ? ?thrpt ? ? ? ?10 11465396,343 ? 181196,117 ? ?ops/s r.PeterIHMBench.putNewObject_peter8noloop ? ?thrpt ? ? ? ?10 11808154,989 ? 193408,009 ? ?ops/s ? ? ?*/ ? ? /* ? ? ?* jdk9 (run 2): Benchmark ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Mode ? Samples ? ? ? ?Score ?Score error ? ?Units r.PeterIHMBench.putNewObject_original ? ? ? ?thrpt ? ? ? ?10 11215457,172 ? 277124,889 ? ?ops/s r.PeterIHMBench.putNewObject_peter7 ? ? ? ? ?thrpt ? ? ? ?10 11288888,493 ? 227178,822 ? ?ops/s r.PeterIHMBench.putNewObject_peter7noloop ? ?thrpt ? ? ? ?10 11737293,594 ? 193035,121 ? ?ops/s r.PeterIHMBench.putNewObject_peter8 ? ? ? ? ?thrpt ? ? ? ?10 11526357,378 ? 141718,661 ? ?ops/s r.PeterIHMBench.putNewObject_peter8noloop ? ?thrpt ? ? ? ?10 11756835,220 ? 276815,538 ? ?ops/s ? ? ?*/ -Jeff From mandy.chung at oracle.com Wed Jul 16 22:39:34 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 16 Jul 2014 15:39:34 -0700 Subject: Review request for 8050804: (jdeps) Recommend supported API to replace use of JDK internal API In-Reply-To: <53C69595.60000@oracle.com> References: <53C5BAD7.1040202@oracle.com> <53C679B6.2050206@oracle.com> <53C69595.60000@oracle.com> Message-ID: <53C6FF26.6030000@oracle.com> Updated webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8050804/webrev.01/ I plan to backport this to 8u40. Mandy On 7/16/14 8:09 AM, Mandy Chung wrote: > My first version prints a separate table of the replacements following > the new warning message at the end of the jdeps output. I like the > first version better than this version replacing rt.jar with "Use..." > message. I might be too anxious getting developers to take action > using the supported APIs when there is one and hence this version. > > I'll update the webrev to print as a separate table. > > thanks > Mandy > > On 7/16/2014 6:10 AM, Daniel Fuchs wrote: >> Hi Mandy, >> >> here is a typical output - with names mangled to save >> space: >> >> s.u.l.p.LPA (rt.jar) >> -> s.s.a.GP JDK internal API (Use j.s.PA @since 1.1) >> -> s.u.c.CLDRLPA JDK internal API (rt.jar) >> >> In the first dependency line, the archive name has been replaced >> by the 'Use ...' message. >> >> I wonder whether it would be better to keep the archive name >> and print the use message as additional information, in order >> to be 'script friendly' so that you could use things like >> | grep 'rt.jar' on the output. >> >> best regards, >> >> -- daniel >> >> On 7/16/14 1:35 AM, Mandy Chung wrote: >>> jdeps -jdkinternals flags use of JDK internal APIs. We have created a >>> wiki page to keep track of the JDK internal APIs and its replacement: >>> https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool >>> >>> >>> While this page will be updated when we identify any new ones >>> worthnoting, it'd still be useful for jdeps to suggest the replacement >>> APIs of the known ones. >>> >>> webrev at: >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8050804/webrev.00/ >>> >>> Mandy >> > From xueming.shen at oracle.com Wed Jul 16 22:55:36 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 16 Jul 2014 15:55:36 -0700 Subject: RFR: JDK-8042589: String.toLowerCase do not work for some concatenated strings In-Reply-To: <53BDA056.8050305@oracle.com> References: <53BDA056.8050305@oracle.com> Message-ID: <53C702E8.8060709@oracle.com> Still need a reviewer. On 07/09/2014 01:04 PM, Xueming Shen wrote: > Hi, > > Please help review the change for JDK-8042589. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8042589 > webrev: http://cr.openjdk.java.net/~sherman/8042589/webrev/ > > This is a regression caused by the following change for #JDK-8032012, > > issue: https://bugs.openjdk.java.net/browse/JDK-8032012 > webrev: http://cr.openjdk.java.net/~sherman/8032012/ > discussion: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/024862.html > > It appears the last optimization for the surrogates we pushed in is > incomplete. We still need to check isSurrogate() in the optimized > non-surrogate loop, as the "first" (checked at the very beginning) might > be triggered by a non-surrogate-upper/lowercase char. > > Thanks! > -Sherman From Lance.Andersen at oracle.com Wed Jul 16 23:21:40 2014 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Wed, 16 Jul 2014 19:21:40 -0400 Subject: RFR (JAXP): 8049514: FEATURE_SECURE_PROCESSING can not be turned off on a validator through SchemaFactory In-Reply-To: <53C69E7B.0@oracle.com> References: <53C69E7B.0@oracle.com> Message-ID: Seems fine Joe? On Jul 16, 2014, at 11:47 AM, huizhe wang wrote: > Hi, > > JAXP SecurityManager was re-designed to XMLSecurityManager to manage jaxp related limits or restrictions. Previously, the existence of a SecurityManager was equivalent to setting FEATURE_SECURE_PROCESSING to true. After the change, secure processing became a property of XMLSecurityManager, thus needs to be queried in order to determine the status of secure processing. > > Since secure processing is true by default, this bug made it impossible to turn off secure processing on a validator through the factory when there is no Java Security Manager. > > Please review: > http://cr.openjdk.java.net/~joehw/jdk9/8049514/webrev/ > > Thanks, > Joe Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mike.duigou at oracle.com Thu Jul 17 00:09:29 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 16 Jul 2014 17:09:29 -0700 Subject: FYC: 7197183 : Provide CharSequence.subSequenceView which allows for sub-sequence views of character sequences. Message-ID: <715CA12A-461A-4BF2-AC83-06AD953E91F7@oracle.com> Hello all; In Java 7u6 there was a significant change in the implementation of java.lang.String (JDK-6924259). This was done to reduce the size of String instances and it has been generally regarded as a positive change. As with almost any significant change to a class as core to Java as String there have also been applications negatively impacted. Most of the problems involve applications which make heavy use of String.substring() as sub-string instances now involve creation of their own copies of the backing characters. There have been previous discussions of mitigations to the 6924259 change in String.substring() behaviour. These discussions haven't come to positive conclusions mostly because they generally require too many changes to the specification or behaviour of String. So here's another proposal (enclosed) that doesn't change the behaviour of any existing classes. It adds two new methods to CharSequence to create sub-sequence views of character sequences. The size of sub-sequence instances very closely matches the size of pre-6924259 String instances and indeed the implementation has the same pre-6924259 limitations, namely that the entire source CharSequence remains alive as long as the sub-sequence is referenced. Unlike pre-6924259 the CharSubSequenceView can not be reliably compared via equals() to String instances and it is unsuitable for use as a hash map key. With these benefits and caveats in mind, would you use this? Mike diff -r 66f582158e1c src/share/classes/java/lang/CharSequence.java --- a/src/share/classes/java/lang/CharSequence.java Wed Jul 16 20:43:53 2014 +0100 +++ b/src/share/classes/java/lang/CharSequence.java Wed Jul 16 16:58:52 2014 -0700 @@ -25,11 +25,14 @@ package java.lang; +import java.io.Serializable; import java.util.NoSuchElementException; +import java.util.Objects; import java.util.PrimitiveIterator; import java.util.Spliterator; import java.util.Spliterators; import java.util.function.IntConsumer; +import java.util.function.IntSupplier; import java.util.stream.IntStream; import java.util.stream.StreamSupport; @@ -231,4 +234,114 @@ Spliterator.ORDERED, false); } + + /** + * Provides a sub-sequence view on a character sequence. Changes in the + * source will be reflected in the sub-sequence. The sub-sequence must, at + * all times, be a proper sub-sequence of the source character sequence. + * + * @since 1.9 + */ + static final class CharSubSequenceView implements CharSequence, Serializable { + + private final CharSequence source; + private final int fromInclusive; + private final IntSupplier toExclusive; + + CharSubSequenceView(CharSequence source, int fromInclusive, int toExclusive) { + this(source, fromInclusive, () -> toExclusive); + } + + CharSubSequenceView(CharSequence source, int fromInclusive, IntSupplier toExclusive) { + this.source = Objects.requireNonNull(source); + if(fromInclusive < 0 || fromInclusive >= source.length() || + toExclusive.getAsInt() < fromInclusive || toExclusive.getAsInt() > source.length()) { + throw new IllegalArgumentException("Invalid index"); + } + this.fromInclusive = fromInclusive; + this.toExclusive = toExclusive; + } + + @Override + public int length() { + return toExclusive.getAsInt() - fromInclusive; + } + + @Override + public char charAt(int index) { + if(index >= length()) { + throw new IllegalArgumentException("Invalid Index"); + } + // + return source.charAt(fromInclusive + index); + } + + @Override + public CharSequence subSequence(int start, int end) { + if (end > length()) { + throw new IllegalArgumentException("Invalid Index"); + } + return source.subSequence(fromInclusive + start, fromInclusive + end); + } + + @Override + public String toString() { + int len = length(); + char[] chars = new char[len]; + for(int each = 0; each < len; each++) { + chars[each] = charAt(each); + } + return new String(chars, true); + } + } + + /** + * Returns as a character sequence the specified sub-sequence view of the + * provided source character sequence. Changes in the source will be + * reflected in the sub-sequence. The sub-sequence must, at all times, be + * a proper sub-sequence of the source character sequence. + * + * @param source The character sequence from which the sub-sequence is + * derived. + * @param startInclusive The index of the character in the source character + * sequence which will be the first character in the sub-sequence. + * @param endExclusive The index after the last the character in the source + * character sequence which will be the last character in the sub-sequence + * @return the character sub-sequence. + * @since 1.9 + */ + static CharSequence subSequenceView(CharSequence source, int startInclusive, int endExclusive) { + return new CharSubSequenceView(source, startInclusive, endExclusive); + } + + /** + * Returns as a character sequence the specified sub-sequence view of the + * provided source character sequence. Changes in the source will be + * reflected in the sub-sequence. The sub-sequence must, at all times, be + * a proper sub-sequence of the source character sequence. This variation + * allows for the size of the sub-sequence to vary, usually to follow the + * size of a growing character sequence. + * + * @apiNote The most common usage of this subSequence is to follow changes + * in the size of the source. + * {@code + * StringBuilder source = new StringBuilder("prefix:"); + * CharSeqence toEnd = CharSequence.subSequence(source, 7, source::length); + * } + * In this example the value of {@code toEnd} will always be a sub-sequence + * of {@code source} but will omit the first 7 characters. + * + * @param source The character sequence from which the sub-sequence is + * derived. + * @param startInclusive The index of the character in the source character + * sequence which will be the first character in the sub-sequence. + * @param endExclusive A supplier which returns the index after the last the + * character in the source character sequence which will be the last + * character in the sub-sequence + * @return the character sub-sequence. + * @since 1.9 + */ + static CharSequence subSequenceView(CharSequence source, int startInclusive, IntSupplier endExclusive) { + return new CharSubSequenceView(source, startInclusive, endExclusive); + } } From lowasser at google.com Thu Jul 17 00:12:47 2014 From: lowasser at google.com (Louis Wasserman) Date: Wed, 16 Jul 2014 17:12:47 -0700 Subject: FYC: 7197183 : Provide CharSequence.subSequenceView which allows for sub-sequence views of character sequences. In-Reply-To: <715CA12A-461A-4BF2-AC83-06AD953E91F7@oracle.com> References: <715CA12A-461A-4BF2-AC83-06AD953E91F7@oracle.com> Message-ID: If I recall correctly, CharBuffer.wrap(charSequence).subSequence(from, to) has equivalent semantics without requiring a new implementation, even if the implementation is fairly simple. On Wed, Jul 16, 2014 at 5:09 PM, Mike Duigou wrote: > Hello all; > > In Java 7u6 there was a significant change in the implementation of > java.lang.String (JDK-6924259). This was done to reduce the size of String > instances and it has been generally regarded as a positive change. As with > almost any significant change to a class as core to Java as String there > have also been applications negatively impacted. Most of the problems > involve applications which make heavy use of String.substring() as > sub-string instances now involve creation of their own copies of the > backing characters. > > There have been previous discussions of mitigations to the 6924259 change > in String.substring() behaviour. These discussions haven't come to positive > conclusions mostly because they generally require too many changes to the > specification or behaviour of String. So here's another proposal (enclosed) > that doesn't change the behaviour of any existing classes. It adds two new > methods to CharSequence to create sub-sequence views of character > sequences. The size of sub-sequence instances very closely matches the size > of pre-6924259 String instances and indeed the implementation has the same > pre-6924259 limitations, namely that the entire source CharSequence remains > alive as long as the sub-sequence is referenced. > > Unlike pre-6924259 the CharSubSequenceView can not be reliably compared > via equals() to String instances and it is unsuitable for use as a hash map > key. > > With these benefits and caveats in mind, would you use this? > > Mike > > diff -r 66f582158e1c src/share/classes/java/lang/CharSequence.java > --- a/src/share/classes/java/lang/CharSequence.java Wed Jul 16 > 20:43:53 2014 +0100 > +++ b/src/share/classes/java/lang/CharSequence.java Wed Jul 16 > 16:58:52 2014 -0700 > @@ -25,11 +25,14 @@ > > package java.lang; > > +import java.io.Serializable; > import java.util.NoSuchElementException; > +import java.util.Objects; > import java.util.PrimitiveIterator; > import java.util.Spliterator; > import java.util.Spliterators; > import java.util.function.IntConsumer; > +import java.util.function.IntSupplier; > import java.util.stream.IntStream; > import java.util.stream.StreamSupport; > > @@ -231,4 +234,114 @@ > Spliterator.ORDERED, > false); > } > + > + /** > + * Provides a sub-sequence view on a character sequence. Changes in > the > + * source will be reflected in the sub-sequence. The sub-sequence > must, at > + * all times, be a proper sub-sequence of the source character > sequence. > + * > + * @since 1.9 > + */ > + static final class CharSubSequenceView implements CharSequence, > Serializable { > + > + private final CharSequence source; > + private final int fromInclusive; > + private final IntSupplier toExclusive; > + > + CharSubSequenceView(CharSequence source, int fromInclusive, int > toExclusive) { > + this(source, fromInclusive, () -> toExclusive); > + } > + > + CharSubSequenceView(CharSequence source, int fromInclusive, > IntSupplier toExclusive) { > + this.source = Objects.requireNonNull(source); > + if(fromInclusive < 0 || fromInclusive >= source.length() || > + toExclusive.getAsInt() < fromInclusive || > toExclusive.getAsInt() > source.length()) { > + throw new IllegalArgumentException("Invalid index"); > + } > + this.fromInclusive = fromInclusive; > + this.toExclusive = toExclusive; > + } > + > + @Override > + public int length() { > + return toExclusive.getAsInt() - fromInclusive; > + } > + > + @Override > + public char charAt(int index) { > + if(index >= length()) { > + throw new IllegalArgumentException("Invalid Index"); > + } > + // > + return source.charAt(fromInclusive + index); > + } > + > + @Override > + public CharSequence subSequence(int start, int end) { > + if (end > length()) { > + throw new IllegalArgumentException("Invalid Index"); > + } > + return source.subSequence(fromInclusive + start, fromInclusive > + end); > + } > + > + @Override > + public String toString() { > + int len = length(); > + char[] chars = new char[len]; > + for(int each = 0; each < len; each++) { > + chars[each] = charAt(each); > + } > + return new String(chars, true); > + } > + } > + > + /** > + * Returns as a character sequence the specified sub-sequence view of > the > + * provided source character sequence. Changes in the source will be > + * reflected in the sub-sequence. The sub-sequence must, at all > times, be > + * a proper sub-sequence of the source character sequence. > + * > + * @param source The character sequence from which the sub-sequence is > + * derived. > + * @param startInclusive The index of the character in the source > character > + * sequence which will be the first character in the sub-sequence. > + * @param endExclusive The index after the last the character in the > source > + * character sequence which will be the last character in the > sub-sequence > + * @return the character sub-sequence. > + * @since 1.9 > + */ > + static CharSequence subSequenceView(CharSequence source, int > startInclusive, int endExclusive) { > + return new CharSubSequenceView(source, startInclusive, > endExclusive); > + } > + > + /** > + * Returns as a character sequence the specified sub-sequence view of > the > + * provided source character sequence. Changes in the source will be > + * reflected in the sub-sequence. The sub-sequence must, at all > times, be > + * a proper sub-sequence of the source character sequence. This > variation > + * allows for the size of the sub-sequence to vary, usually to follow > the > + * size of a growing character sequence. > + * > + * @apiNote The most common usage of this subSequence is to follow > changes > + * in the size of the source. > + * {@code > + * StringBuilder source = new StringBuilder("prefix:"); > + * CharSeqence toEnd = CharSequence.subSequence(source, 7, > source::length); > + * } > + * In this example the value of {@code toEnd} will always be a > sub-sequence > + * of {@code source} but will omit the first 7 characters. > + * > + * @param source The character sequence from which the sub-sequence is > + * derived. > + * @param startInclusive The index of the character in the source > character > + * sequence which will be the first character in the sub-sequence. > + * @param endExclusive A supplier which returns the index after the > last the > + * character in the source character sequence which will be the last > + * character in the sub-sequence > + * @return the character sub-sequence. > + * @since 1.9 > + */ > + static CharSequence subSequenceView(CharSequence source, int > startInclusive, IntSupplier endExclusive) { > + return new CharSubSequenceView(source, startInclusive, > endExclusive); > + } > } > > -- Louis Wasserman From joe.darcy at oracle.com Thu Jul 17 00:24:42 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 16 Jul 2014 17:24:42 -0700 Subject: JDK 9 RFR of JDK-8050798: New unchecked warning introduced in com.sun.jndi.ldap.Connection Message-ID: <53C717CA.1050506@oracle.com> Hello, Please review the patch below for JDK-8050798: New unchecked warning introduced in com.sun.jndi.ldap.Connection which addresses a newly-introduced unchecked warning in core libs. Thanks, -Joe diff -r e4a6f3779797 src/share/classes/com/sun/jndi/ldap/Connection.java --- a/src/share/classes/com/sun/jndi/ldap/Connection.java Tue Jul 15 11:22:14 2014 -0700 +++ b/src/share/classes/com/sun/jndi/ldap/Connection.java Wed Jul 16 17:22:37 2014 -0700 @@ -258,9 +258,9 @@ // create the factory + @SuppressWarnings("unchecked") Class socketFactoryClass = - (Class) Obj.helper.loadClass - (socketFactory); + (Class)Obj.helper.loadClass(socketFactory); Method getDefault = socketFactoryClass.getMethod("getDefault", new Class[]{}); SocketFactory factory = (SocketFactory) getDefault.invoke(null, new Object[]{}); From Lance.Andersen at oracle.com Thu Jul 17 00:27:04 2014 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Wed, 16 Jul 2014 20:27:04 -0400 Subject: JDK 9 RFR of JDK-8050798: New unchecked warning introduced in com.sun.jndi.ldap.Connection In-Reply-To: <53C717CA.1050506@oracle.com> References: <53C717CA.1050506@oracle.com> Message-ID: +1 On Jul 16, 2014, at 8:24 PM, Joe Darcy wrote: > Hello, > > Please review the patch below for > > JDK-8050798: New unchecked warning introduced in com.sun.jndi.ldap.Connection > > which addresses a newly-introduced unchecked warning in core libs. > > Thanks, > > -Joe > > diff -r e4a6f3779797 src/share/classes/com/sun/jndi/ldap/Connection.java > --- a/src/share/classes/com/sun/jndi/ldap/Connection.java Tue Jul 15 11:22:14 2014 -0700 > +++ b/src/share/classes/com/sun/jndi/ldap/Connection.java Wed Jul 16 17:22:37 2014 -0700 > @@ -258,9 +258,9 @@ > > // create the factory > > + @SuppressWarnings("unchecked") > Class socketFactoryClass = > - (Class) Obj.helper.loadClass > - (socketFactory); > + (Class)Obj.helper.loadClass(socketFactory); > Method getDefault = > socketFactoryClass.getMethod("getDefault", new Class[]{}); > SocketFactory factory = (SocketFactory) getDefault.invoke(null, new Object[]{}); > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From stuart.marks at oracle.com Thu Jul 17 00:46:52 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 16 Jul 2014 17:46:52 -0700 Subject: please review draft JEP: Convenience Factory Methods for Collections Message-ID: <53C71CFC.8020903@oracle.com> Hi all, Please review this draft JEP for Convenience Factory Methods for Collections: https://bugs.openjdk.java.net/browse/JDK-8048330 Brief background: several times over the years there have been proposals to add "collection literals" to the language. The most recent round of this was in regard to JEP 186, a research JEP to explore this topic. That effort was concluded by Brian Goetz, as summarized in this email: http://mail.openjdk.java.net/pipermail/lambda-dev/2014-March/011938.html Essentially, the idea of adding collection literals to the language was set aside in favor of adding some library APIs, not entirely unlike collection literals, that make it more convenient to create collections. That's what this proposal is. Share and enjoy, s'marks From mandy.chung at oracle.com Thu Jul 17 00:55:56 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 16 Jul 2014 17:55:56 -0700 Subject: JDK 9 RFR of JDK-8050798: New unchecked warning introduced in com.sun.jndi.ldap.Connection In-Reply-To: <53C717CA.1050506@oracle.com> References: <53C717CA.1050506@oracle.com> Message-ID: <53C71F1C.3060005@oracle.com> Looks good. Mandy On 7/16/2014 5:24 PM, Joe Darcy wrote: > Hello, > > Please review the patch below for > > JDK-8050798: New unchecked warning introduced in > com.sun.jndi.ldap.Connection > > which addresses a newly-introduced unchecked warning in core libs. > > Thanks, > > -Joe > > diff -r e4a6f3779797 src/share/classes/com/sun/jndi/ldap/Connection.java > --- a/src/share/classes/com/sun/jndi/ldap/Connection.java Tue Jul > 15 11:22:14 2014 -0700 > +++ b/src/share/classes/com/sun/jndi/ldap/Connection.java Wed Jul > 16 17:22:37 2014 -0700 > @@ -258,9 +258,9 @@ > > // create the factory > > + @SuppressWarnings("unchecked") > Class socketFactoryClass = > - (Class) > Obj.helper.loadClass > - (socketFactory); > + (Class SocketFactory>)Obj.helper.loadClass(socketFactory); > Method getDefault = > socketFactoryClass.getMethod("getDefault", new > Class[]{}); > SocketFactory factory = (SocketFactory) > getDefault.invoke(null, new Object[]{}); > From forax at univ-mlv.fr Thu Jul 17 01:03:09 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 17 Jul 2014 03:03:09 +0200 Subject: please review draft JEP: Convenience Factory Methods for Collections In-Reply-To: <53C71CFC.8020903@oracle.com> References: <53C71CFC.8020903@oracle.com> Message-ID: <53C720CD.3000402@univ-mlv.fr> On 07/17/2014 02:46 AM, Stuart Marks wrote: > Hi all, > > Please review this draft JEP for Convenience Factory Methods for > Collections: > > https://bugs.openjdk.java.net/browse/JDK-8048330 > > Brief background: several times over the years there have been > proposals to add "collection literals" to the language. The most > recent round of this was in regard to JEP 186, a research JEP to > explore this topic. That effort was concluded by Brian Goetz, as > summarized in this email: > > http://mail.openjdk.java.net/pipermail/lambda-dev/2014-March/011938.html > > Essentially, the idea of adding collection literals to the language > was set aside in favor of adding some library APIs, not entirely > unlike collection literals, that make it more convenient to create > collections. That's what this proposal is. > > Share and enjoy, > > s'marks > Hi Stuart, I think you should say something about the serialization of the immutable collections because implementation details like the real class name can leak through this channel. That's why, by example, java.util.Collections.ArrayList (the internal class of Collections) was never renamed. Also 5 key/value pairs seems a little bit limited IMO, 7 or 8 will be better but I suppose you want to use the fact that because the number of pairs is really small, the algorithm can do a linear probe. I think you should add a version that takes two arrays of the same size (for an (almost) unlimited number of pairs) with an implementation that clone the two arrays (at least until value type are implemented). I think you should also add a default method toImmutable to Set, List and Map, so one can use HashSet, ArrayList and HashMap as builder for their immutable counterparts. Otherwise, the stream integration will be difficult, i.e. the implementation of Collectors.toImmutableList/Set/Map. cheers, R?mi From huizhe.wang at oracle.com Thu Jul 17 01:23:28 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 16 Jul 2014 18:23:28 -0700 Subject: RFR (JAXP): 8049514: FEATURE_SECURE_PROCESSING can not be turned off on a validator through SchemaFactory In-Reply-To: References: <53C69E7B.0@oracle.com> Message-ID: <53C72590.5070107@oracle.com> Thanks Lance. Joe On 7/16/2014 4:21 PM, Lance Andersen wrote: > Seems fine Joe? > > > On Jul 16, 2014, at 11:47 AM, huizhe wang > wrote: > >> Hi, >> >> JAXP SecurityManager was re-designed to XMLSecurityManager to manage >> jaxp related limits or restrictions. Previously, the existence of a >> SecurityManager was equivalent to setting FEATURE_SECURE_PROCESSING >> to true. After the change, secure processing became a property of >> XMLSecurityManager, thus needs to be queried in order to determine >> the status of secure processing. >> >> Since secure processing is true by default, this bug made it >> impossible to turn off secure processing on a validator through the >> factory when there is no Java Security Manager. >> >> Please review: >> http://cr.openjdk.java.net/~joehw/jdk9/8049514/webrev/ >> >> >> Thanks, >> Joe > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > > From mandy.chung at oracle.com Thu Jul 17 01:51:13 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 16 Jul 2014 18:51:13 -0700 Subject: RFR: JDK-8042589: String.toLowerCase do not work for some concatenated strings In-Reply-To: <53C702E8.8060709@oracle.com> References: <53BDA056.8050305@oracle.com> <53C702E8.8060709@oracle.com> Message-ID: <53C72C11.4010504@oracle.com> > On 07/09/2014 01:04 PM, Xueming Shen wrote: >> Hi, >> >> Please help review the change for JDK-8042589. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8042589 >> webrev: http://cr.openjdk.java.net/~sherman/8042589/webrev/ >> >> This is a regression caused by the following change for #JDK-8032012, >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8032012 >> webrev: http://cr.openjdk.java.net/~sherman/8032012/ >> discussion: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/024862.html >> >> It appears the last optimization for the surrogates we pushed in is >> incomplete. We still need to check isSurrogate() in the optimized >> non-surrogate loop, as the "first" (checked at the very beginning) might >> be triggered by a non-surrogate-upper/lowercase char. The fix looks okay. It may be useful to verify with the submitter and no other issue found since the fix for JDK-8032012 wasn't entirely straight forward. Mandy From stuart.marks at oracle.com Thu Jul 17 01:58:29 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 16 Jul 2014 18:58:29 -0700 Subject: please review draft JEP: Convenience Factory Methods for Collections In-Reply-To: <53C720CD.3000402@univ-mlv.fr> References: <53C71CFC.8020903@oracle.com> <53C720CD.3000402@univ-mlv.fr> Message-ID: <53C72DC5.4000800@oracle.com> On 7/16/14 6:03 PM, Remi Forax wrote: > On 07/17/2014 02:46 AM, Stuart Marks wrote: >> Please review this draft JEP for Convenience Factory Methods for Collections: >> >> https://bugs.openjdk.java.net/browse/JDK-8048330 >> >> Brief background: several times over the years there have been proposals to >> add "collection literals" to the language. The most recent round of this was >> in regard to JEP 186, a research JEP to explore this topic. That effort was >> concluded by Brian Goetz, as summarized in this email: >> >> http://mail.openjdk.java.net/pipermail/lambda-dev/2014-March/011938.html >> >> Essentially, the idea of adding collection literals to the language was set >> aside in favor of adding some library APIs, not entirely unlike collection >> literals, that make it more convenient to create collections. That's what this >> proposal is. > > I think you should say something about the serialization of the immutable > collections > because implementation details like the real class name can leak through this > channel. > That's why, by example, java.util.Collections.ArrayList (the internal class of > Collections) was never renamed. Hi Remi, (I think you mean java.util.Arrays.ArrayList?) But yes, the point is make the implementation classes private and to use serialization proxies (or perhaps just one serialization proxy for all implementation classes) to control the number of classes exposed by the serialized format. I should probably make this more explicit. > Also 5 key/value pairs seems a little bit limited IMO, 7 or 8 will be better but > I suppose you want to use the fact > that because the number of pairs is really small, the algorithm can do a linear > probe. We started with 5 because that's what Guava does, but there's nothing essential about 5. Could be 6 or 7 or maybe even 8. We need to do some investigation of common map sizes in real applications. That's how the Guava guys came up with 5, I think. We have some internal numbers that I'm told are slightly higher, but I still need to track those down. And yes at small sizes it makes sense to do linear probe or even a plain linear search (i.e., no hashing). > I think you should add a version that takes two arrays of the same size (for an > (almost) unlimited number of pairs) > with an implementation that clone the two arrays (at least until value type are > implemented). Yes, one could add such a thing. :-) I guess if we were to choose the right number of key/value pairs for Map.of(...), would there still be a need for immutable maps with arbitrary numbers of key-value pairs? And how convenient would it be to use? > I think you should also add a default method toImmutable to Set, List and Map, > so one can use HashSet, ArrayList > and HashMap as builder for their immutable counterparts. Otherwise, the stream > integration will be difficult, > i.e. the implementation of Collectors.toImmutableList/Set/Map. I don't see this proposal as providing immutable counterparts to the existing mutable collections. The existing collections are designed to deal well with arbitrary numbers of elements, but the immutable collections discussed here are not -- they're intended to support the convenience API, which is focused on relatively small numbers of elements. Now it might be nice to have a set of scalable, immutable collections, which would necessarily entail some additional APIs to construct them from streams and from existing collections. But that's a somewhat different goal. We should have a discussion about whether doing that is necessary, and if so, whether it should be part of this proposal. s'marks From pbenedict at apache.org Thu Jul 17 02:05:53 2014 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 16 Jul 2014 21:05:53 -0500 Subject: please review draft JEP: Convenience Factory Methods for Collections In-Reply-To: <53C72DC5.4000800@oracle.com> References: <53C71CFC.8020903@oracle.com> <53C720CD.3000402@univ-mlv.fr> <53C72DC5.4000800@oracle.com> Message-ID: Regarding why you didn't choose a straight vararg solution, I prefer you do allow any number of key/values as long as you throw an exception if the array is not an even sized. Cheers, Paul On Wed, Jul 16, 2014 at 8:58 PM, Stuart Marks wrote: > On 7/16/14 6:03 PM, Remi Forax wrote: > >> On 07/17/2014 02:46 AM, Stuart Marks wrote: >> >>> Please review this draft JEP for Convenience Factory Methods for >>> Collections: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8048330 >>> >>> Brief background: several times over the years there have been proposals >>> to >>> add "collection literals" to the language. The most recent round of this >>> was >>> in regard to JEP 186, a research JEP to explore this topic. That effort >>> was >>> concluded by Brian Goetz, as summarized in this email: >>> >>> http://mail.openjdk.java.net/pipermail/lambda-dev/2014-March/011938.html >>> >>> Essentially, the idea of adding collection literals to the language was >>> set >>> aside in favor of adding some library APIs, not entirely unlike >>> collection >>> literals, that make it more convenient to create collections. That's >>> what this >>> proposal is. >>> >> >> I think you should say something about the serialization of the immutable >> collections >> because implementation details like the real class name can leak through >> this >> channel. >> That's why, by example, java.util.Collections.ArrayList (the internal >> class of >> Collections) was never renamed. >> > > Hi Remi, > > (I think you mean java.util.Arrays.ArrayList?) > > But yes, the point is make the implementation classes private and to use > serialization proxies (or perhaps just one serialization proxy for all > implementation classes) to control the number of classes exposed by the > serialized format. I should probably make this more explicit. > > Also 5 key/value pairs seems a little bit limited IMO, 7 or 8 will be >> better but >> I suppose you want to use the fact >> that because the number of pairs is really small, the algorithm can do a >> linear >> probe. >> > > We started with 5 because that's what Guava does, but there's nothing > essential about 5. Could be 6 or 7 or maybe even 8. We need to do some > investigation of common map sizes in real applications. That's how the > Guava guys came up with 5, I think. We have some internal numbers that I'm > told are slightly higher, but I still need to track those down. > > And yes at small sizes it makes sense to do linear probe or even a plain > linear search (i.e., no hashing). > > I think you should add a version that takes two arrays of the same size >> (for an >> (almost) unlimited number of pairs) >> with an implementation that clone the two arrays (at least until value >> type are >> implemented). >> > > Yes, one could add such a thing. :-) I guess if we were to choose the > right number of key/value pairs for Map.of(...), would there still be a > need for immutable maps with arbitrary numbers of key-value pairs? And how > convenient would it be to use? > > I think you should also add a default method toImmutable to Set, List and >> Map, >> so one can use HashSet, ArrayList >> and HashMap as builder for their immutable counterparts. Otherwise, the >> stream >> integration will be difficult, >> i.e. the implementation of Collectors.toImmutableList/Set/Map. >> > > I don't see this proposal as providing immutable counterparts to the > existing mutable collections. The existing collections are designed to deal > well with arbitrary numbers of elements, but the immutable collections > discussed here are not -- they're intended to support the convenience API, > which is focused on relatively small numbers of elements. > > Now it might be nice to have a set of scalable, immutable collections, > which would necessarily entail some additional APIs to construct them from > streams and from existing collections. But that's a somewhat different > goal. We should have a discussion about whether doing that is necessary, > and if so, whether it should be part of this proposal. > > s'marks > > > From mike at saxonica.com Thu Jul 17 07:21:42 2014 From: mike at saxonica.com (Michael Kay) Date: Thu, 17 Jul 2014 08:21:42 +0100 Subject: please review draft JEP: Convenience Factory Methods for Collections In-Reply-To: <53C71CFC.8020903@oracle.com> References: <53C71CFC.8020903@oracle.com> Message-ID: <364C8776-4E58-4D6E-933D-0C8D156E5667@saxonica.com> Set.of() and List.of() look very attractive; Map.of() looks very ugly. I would much prefer to write something like Map.of( Map.pair(key, value), Map.pair(key, value), Map.pair(key, value) ); and have no limit on the number of pairs. (Don't care how it works internally...) The last thing I want is to have to rewrite all my code when someone asks me to add a sixth entry to the map initialization! Michael Kay Saxonica mike at saxonica.com +44 (0118) 946 5893 On 17 Jul 2014, at 01:46, Stuart Marks wrote: > Hi all, > > Please review this draft JEP for Convenience Factory Methods for Collections: > > https://bugs.openjdk.java.net/browse/JDK-8048330 > > Brief background: several times over the years there have been proposals to add "collection literals" to the language. The most recent round of this was in regard to JEP 186, a research JEP to explore this topic. That effort was concluded by Brian Goetz, as summarized in this email: > > http://mail.openjdk.java.net/pipermail/lambda-dev/2014-March/011938.html > > Essentially, the idea of adding collection literals to the language was set aside in favor of adding some library APIs, not entirely unlike collection literals, that make it more convenient to create collections. That's what this proposal is. > > Share and enjoy, > > s'marks > From mike at saxonica.com Thu Jul 17 07:26:22 2014 From: mike at saxonica.com (Michael Kay) Date: Thu, 17 Jul 2014 08:26:22 +0100 Subject: FYC: 7197183 : Provide CharSequence.subSequenceView which allows for sub-sequence views of character sequences. In-Reply-To: <715CA12A-461A-4BF2-AC83-06AD953E91F7@oracle.com> References: <715CA12A-461A-4BF2-AC83-06AD953E91F7@oracle.com> Message-ID: In my own product (Saxon) I have a class CharSlice which is pretty much identical to your CharSubSequenceView. So yes, I think it is useful. Michael Kay Saxonica mike at saxonica.com +44 (0118) 946 5893 On 17 Jul 2014, at 01:09, Mike Duigou wrote: > Hello all; > > In Java 7u6 there was a significant change in the implementation of java.lang.String (JDK-6924259). This was done to reduce the size of String instances and it has been generally regarded as a positive change. As with almost any significant change to a class as core to Java as String there have also been applications negatively impacted. Most of the problems involve applications which make heavy use of String.substring() as sub-string instances now involve creation of their own copies of the backing characters. > > There have been previous discussions of mitigations to the 6924259 change in String.substring() behaviour. These discussions haven't come to positive conclusions mostly because they generally require too many changes to the specification or behaviour of String. So here's another proposal (enclosed) that doesn't change the behaviour of any existing classes. It adds two new methods to CharSequence to create sub-sequence views of character sequences. The size of sub-sequence instances very closely matches the size of pre-6924259 String instances and indeed the implementation has the same pre-6924259 limitations, namely that the entire source CharSequence remains alive as long as the sub-sequence is referenced. > > Unlike pre-6924259 the CharSubSequenceView can not be reliably compared via equals() to String instances and it is unsuitable for use as a hash map key. > > With these benefits and caveats in mind, would you use this? > > Mike > > diff -r 66f582158e1c src/share/classes/java/lang/CharSequence.java > --- a/src/share/classes/java/lang/CharSequence.java Wed Jul 16 20:43:53 2014 +0100 > +++ b/src/share/classes/java/lang/CharSequence.java Wed Jul 16 16:58:52 2014 -0700 > @@ -25,11 +25,14 @@ > > package java.lang; > > +import java.io.Serializable; > import java.util.NoSuchElementException; > +import java.util.Objects; > import java.util.PrimitiveIterator; > import java.util.Spliterator; > import java.util.Spliterators; > import java.util.function.IntConsumer; > +import java.util.function.IntSupplier; > import java.util.stream.IntStream; > import java.util.stream.StreamSupport; > > @@ -231,4 +234,114 @@ > Spliterator.ORDERED, > false); > } > + > + /** > + * Provides a sub-sequence view on a character sequence. Changes in the > + * source will be reflected in the sub-sequence. The sub-sequence must, at > + * all times, be a proper sub-sequence of the source character sequence. > + * > + * @since 1.9 > + */ > + static final class CharSubSequenceView implements CharSequence, Serializable { > + > + private final CharSequence source; > + private final int fromInclusive; > + private final IntSupplier toExclusive; > + > + CharSubSequenceView(CharSequence source, int fromInclusive, int toExclusive) { > + this(source, fromInclusive, () -> toExclusive); > + } > + > + CharSubSequenceView(CharSequence source, int fromInclusive, IntSupplier toExclusive) { > + this.source = Objects.requireNonNull(source); > + if(fromInclusive < 0 || fromInclusive >= source.length() || > + toExclusive.getAsInt() < fromInclusive || toExclusive.getAsInt() > source.length()) { > + throw new IllegalArgumentException("Invalid index"); > + } > + this.fromInclusive = fromInclusive; > + this.toExclusive = toExclusive; > + } > + > + @Override > + public int length() { > + return toExclusive.getAsInt() - fromInclusive; > + } > + > + @Override > + public char charAt(int index) { > + if(index >= length()) { > + throw new IllegalArgumentException("Invalid Index"); > + } > + // > + return source.charAt(fromInclusive + index); > + } > + > + @Override > + public CharSequence subSequence(int start, int end) { > + if (end > length()) { > + throw new IllegalArgumentException("Invalid Index"); > + } > + return source.subSequence(fromInclusive + start, fromInclusive + end); > + } > + > + @Override > + public String toString() { > + int len = length(); > + char[] chars = new char[len]; > + for(int each = 0; each < len; each++) { > + chars[each] = charAt(each); > + } > + return new String(chars, true); > + } > + } > + > + /** > + * Returns as a character sequence the specified sub-sequence view of the > + * provided source character sequence. Changes in the source will be > + * reflected in the sub-sequence. The sub-sequence must, at all times, be > + * a proper sub-sequence of the source character sequence. > + * > + * @param source The character sequence from which the sub-sequence is > + * derived. > + * @param startInclusive The index of the character in the source character > + * sequence which will be the first character in the sub-sequence. > + * @param endExclusive The index after the last the character in the source > + * character sequence which will be the last character in the sub-sequence > + * @return the character sub-sequence. > + * @since 1.9 > + */ > + static CharSequence subSequenceView(CharSequence source, int startInclusive, int endExclusive) { > + return new CharSubSequenceView(source, startInclusive, endExclusive); > + } > + > + /** > + * Returns as a character sequence the specified sub-sequence view of the > + * provided source character sequence. Changes in the source will be > + * reflected in the sub-sequence. The sub-sequence must, at all times, be > + * a proper sub-sequence of the source character sequence. This variation > + * allows for the size of the sub-sequence to vary, usually to follow the > + * size of a growing character sequence. > + * > + * @apiNote The most common usage of this subSequence is to follow changes > + * in the size of the source. > + * {@code > + * StringBuilder source = new StringBuilder("prefix:"); > + * CharSeqence toEnd = CharSequence.subSequence(source, 7, source::length); > + * } > + * In this example the value of {@code toEnd} will always be a sub-sequence > + * of {@code source} but will omit the first 7 characters. > + * > + * @param source The character sequence from which the sub-sequence is > + * derived. > + * @param startInclusive The index of the character in the source character > + * sequence which will be the first character in the sub-sequence. > + * @param endExclusive A supplier which returns the index after the last the > + * character in the source character sequence which will be the last > + * character in the sub-sequence > + * @return the character sub-sequence. > + * @since 1.9 > + */ > + static CharSequence subSequenceView(CharSequence source, int startInclusive, IntSupplier endExclusive) { > + return new CharSubSequenceView(source, startInclusive, endExclusive); > + } > } > From tom.hawtin at oracle.com Thu Jul 17 07:46:21 2014 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Thu, 17 Jul 2014 08:46:21 +0100 Subject: please review draft JEP: Convenience Factory Methods for Collections In-Reply-To: <53C71CFC.8020903@oracle.com> References: <53C71CFC.8020903@oracle.com> Message-ID: <53C77F4D.6000106@oracle.com> I note that with the basic proposal, HashSet.of and indeed NavigableSet.of still work. They just do the wrong thing. Tom From mike at saxonica.com Thu Jul 17 07:57:16 2014 From: mike at saxonica.com (Michael Kay) Date: Thu, 17 Jul 2014 08:57:16 +0100 Subject: please review draft JEP: Convenience Factory Methods for Collections In-Reply-To: <364C8776-4E58-4D6E-933D-0C8D156E5667@saxonica.com> References: <53C71CFC.8020903@oracle.com> <364C8776-4E58-4D6E-933D-0C8D156E5667@saxonica.com> Message-ID: <85E84868-E714-438A-A3F9-3DE6802F2CDA@saxonica.com> On 17 Jul 2014, at 08:21, Michael Kay wrote: > Set.of() and List.of() look very attractive; Map.of() looks very ugly. > > I would much prefer to write something like > > Map.of( > Map.pair(key, value), > Map.pair(key, value), > Map.pair(key, value) > ); > Another style that would work for me is Map .add(key,value) .add(key,value) .add(key,value) .add(key,value); Michael Kay Saxonica From forax at univ-mlv.fr Thu Jul 17 08:53:04 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 17 Jul 2014 10:53:04 +0200 Subject: please review draft JEP: Convenience Factory Methods for Collections In-Reply-To: References: <53C71CFC.8020903@oracle.com> <53C720CD.3000402@univ-mlv.fr> <53C72DC5.4000800@oracle.com> Message-ID: <53C78EF0.7040703@univ-mlv.fr> On 07/17/2014 04:05 AM, Paul Benedict wrote: > Regarding why you didn't choose a straight vararg solution, I prefer > you do allow any number of key/values as long as you throw an > exception if the array is not an even sized. You can not extract/infer the type of the key and the type of the value if you have only one array. > > > Cheers, > Paul cheers, R?mi > > > On Wed, Jul 16, 2014 at 8:58 PM, Stuart Marks > wrote: > > On 7/16/14 6:03 PM, Remi Forax wrote: > > On 07/17/2014 02:46 AM, Stuart Marks wrote: > > Please review this draft JEP for Convenience Factory > Methods for Collections: > > https://bugs.openjdk.java.net/browse/JDK-8048330 > > Brief background: several times over the years there have > been proposals to > add "collection literals" to the language. The most recent > round of this was > in regard to JEP 186, a research JEP to explore this > topic. That effort was > concluded by Brian Goetz, as summarized in this email: > > http://mail.openjdk.java.net/pipermail/lambda-dev/2014-March/011938.html > > Essentially, the idea of adding collection literals to the > language was set > aside in favor of adding some library APIs, not entirely > unlike collection > literals, that make it more convenient to create > collections. That's what this > proposal is. > > > I think you should say something about the serialization of > the immutable > collections > because implementation details like the real class name can > leak through this > channel. > That's why, by example, java.util.Collections.ArrayList (the > internal class of > Collections) was never renamed. > > > Hi Remi, > > (I think you mean java.util.Arrays.ArrayList?) > > But yes, the point is make the implementation classes private and > to use serialization proxies (or perhaps just one serialization > proxy for all implementation classes) to control the number of > classes exposed by the serialized format. I should probably make > this more explicit. > > Also 5 key/value pairs seems a little bit limited IMO, 7 or 8 > will be better but > I suppose you want to use the fact > that because the number of pairs is really small, the > algorithm can do a linear > probe. > > > We started with 5 because that's what Guava does, but there's > nothing essential about 5. Could be 6 or 7 or maybe even 8. We > need to do some investigation of common map sizes in real > applications. That's how the Guava guys came up with 5, I think. > We have some internal numbers that I'm told are slightly higher, > but I still need to track those down. > > And yes at small sizes it makes sense to do linear probe or even a > plain linear search (i.e., no hashing). > > I think you should add a version that takes two arrays of the > same size (for an > (almost) unlimited number of pairs) > with an implementation that clone the two arrays (at least > until value type are > implemented). > > > Yes, one could add such a thing. :-) I guess if we were to choose > the right number of key/value pairs for Map.of(...), would there > still be a need for immutable maps with arbitrary numbers of > key-value pairs? And how convenient would it be to use? > > I think you should also add a default method toImmutable to > Set, List and Map, > so one can use HashSet, ArrayList > and HashMap as builder for their immutable counterparts. > Otherwise, the stream > integration will be difficult, > i.e. the implementation of Collectors.toImmutableList/Set/Map. > > > I don't see this proposal as providing immutable counterparts to > the existing mutable collections. The existing collections are > designed to deal well with arbitrary numbers of elements, but the > immutable collections discussed here are not -- they're intended > to support the convenience API, which is focused on relatively > small numbers of elements. > > Now it might be nice to have a set of scalable, immutable > collections, which would necessarily entail some additional APIs > to construct them from streams and from existing collections. But > that's a somewhat different goal. We should have a discussion > about whether doing that is necessary, and if so, whether it > should be part of this proposal. > > s'marks > > > From daniel.fuchs at oracle.com Thu Jul 17 09:41:26 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 17 Jul 2014 11:41:26 +0200 Subject: Review request for 8050804: (jdeps) Recommend supported API to replace use of JDK internal API In-Reply-To: <53C6FED8.2060708@oracle.com> References: <53C5BAD7.1040202@oracle.com> <53C679B6.2050206@oracle.com> <53C69595.60000@oracle.com> <53C6FED8.2060708@oracle.com> Message-ID: <53C79A46.4030108@oracle.com> Hi Mandy, minor: JdepsTask.java:977 could be refactored to use putIfAbsent I wonder whether the summary table at the end should contain a warning for all the usage of jdk internals that have no replacement? Otherwise looks good! I like the output much better :-) best regards, -- daniel On 7/17/14 12:38 AM, Mandy Chung wrote: > Updated webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8050804/webrev.01/ > > I plan to backport this to 8u40. > > Mandy > > On 7/16/14 8:09 AM, Mandy Chung wrote: >> My first version prints a separate table of the replacements following >> the new warning message at the end of the jdeps output. I like the >> first version better than this version replacing rt.jar with "Use..." >> message. I might be too anxious getting developers to take action >> using the supported APIs when there is one and hence this version. >> >> I'll update the webrev to print as a separate table. >> >> thanks >> Mandy >> >> On 7/16/2014 6:10 AM, Daniel Fuchs wrote: >>> Hi Mandy, >>> >>> here is a typical output - with names mangled to save >>> space: >>> >>> s.u.l.p.LPA (rt.jar) >>> -> s.s.a.GP JDK internal API (Use j.s.PA @since 1.1) >>> -> s.u.c.CLDRLPA JDK internal API (rt.jar) >>> >>> In the first dependency line, the archive name has been replaced >>> by the 'Use ...' message. >>> >>> I wonder whether it would be better to keep the archive name >>> and print the use message as additional information, in order >>> to be 'script friendly' so that you could use things like >>> | grep 'rt.jar' on the output. >>> >>> best regards, >>> >>> -- daniel >>> >>> On 7/16/14 1:35 AM, Mandy Chung wrote: >>>> jdeps -jdkinternals flags use of JDK internal APIs. We have created a >>>> wiki page to keep track of the JDK internal APIs and its replacement: >>>> https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool >>>> >>>> >>>> While this page will be updated when we identify any new ones >>>> worthnoting, it'd still be useful for jdeps to suggest the replacement >>>> APIs of the known ones. >>>> >>>> webrev at: >>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8050804/webrev.00/ >>>> >>>> Mandy >>> >> > From Ulf.Zibis at CoSoCo.de Thu Jul 17 09:54:16 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 17 Jul 2014 11:54:16 +0200 Subject: RFR: JDK-8042589: String.toLowerCase do not work for some concatenated strings In-Reply-To: <53C702E8.8060709@oracle.com> References: <53BDA056.8050305@oracle.com> <53C702E8.8060709@oracle.com> Message-ID: <53C79D48.40803@CoSoCo.de> There is again another little optimization possible: instead hasSurr = true; we could use first = ~first; and save variable hasSurr. If there is register pressure (especially on older CPUs), this might be a performance advantage. Also I think we should not grow the result array for any character where "mapLen > srcCount", we could wait until the result array is actually full. -Ulf Am 17.07.2014 00:55, schrieb Xueming Shen: > Still need a reviewer. > > On 07/09/2014 01:04 PM, Xueming Shen wrote: >> Hi, >> >> Please help review the change for JDK-8042589. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8042589 >> webrev: http://cr.openjdk.java.net/~sherman/8042589/webrev/ >> >> This is a regression caused by the following change for #JDK-8032012, >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8032012 >> webrev: http://cr.openjdk.java.net/~sherman/8032012/ >> discussion: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/024862.html >> >> It appears the last optimization for the surrogates we pushed in is >> incomplete. We still need to check isSurrogate() in the optimized >> non-surrogate loop, as the "first" (checked at the very beginning) might >> be triggered by a non-surrogate-upper/lowercase char. >> >> Thanks! >> -Sherman > > From Ulf.Zibis at CoSoCo.de Thu Jul 17 10:37:38 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 17 Jul 2014 12:37:38 +0200 Subject: RFR: JDK-8042589: String.toLowerCase do not work for some concatenated strings In-Reply-To: <53C79D48.40803@CoSoCo.de> References: <53BDA056.8050305@oracle.com> <53C702E8.8060709@oracle.com> <53C79D48.40803@CoSoCo.de> Message-ID: <53C7A772.8030106@CoSoCo.de> Additionally I think, instead of retrieving String lang = locale.getLanguage() multiple times in chain, we could pass "lang" to the methods instead "locale". -Ulf Am 17.07.2014 11:54, schrieb Ulf Zibis: > There is again another little optimization possible: > > instead > hasSurr = true; > we could use > first = ~first; > and save variable hasSurr. > > If there is register pressure (especially on older CPUs), this might be a performance advantage. > > Also I think we should not grow the result array for any character where "mapLen > srcCount", we > could wait until the result array is actually full. > > -Ulf > > > Am 17.07.2014 00:55, schrieb Xueming Shen: >> Still need a reviewer. >> >> On 07/09/2014 01:04 PM, Xueming Shen wrote: >>> Hi, >>> >>> Please help review the change for JDK-8042589. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8042589 >>> webrev: http://cr.openjdk.java.net/~sherman/8042589/webrev/ >>> >>> This is a regression caused by the following change for #JDK-8032012, >>> >>> issue: https://bugs.openjdk.java.net/browse/JDK-8032012 >>> webrev: http://cr.openjdk.java.net/~sherman/8032012/ >>> discussion: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/024862.html >>> >>> It appears the last optimization for the surrogates we pushed in is >>> incomplete. We still need to check isSurrogate() in the optimized >>> non-surrogate loop, as the "first" (checked at the very beginning) might >>> be triggered by a non-surrogate-upper/lowercase char. >>> >>> Thanks! >>> -Sherman >> >> > > From georgiy.rakov at oracle.com Thu Jul 17 11:33:14 2014 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Thu, 17 Jul 2014 15:33:14 +0400 Subject: Fwd: JDK 9 RFR of JDK-8030942: Explicitly state floating-point summation requirements on non-finite inputs In-Reply-To: <49851217-96FD-4A7D-BADB-7857815CF506@oracle.com> References: <53C5C77A.5040500@oracle.com> <49851217-96FD-4A7D-BADB-7857815CF506@oracle.com> Message-ID: <53C7B47A.6070506@oracle.com> Hello, let's consider following excerpt: 149 * It is possible for intermediate sums of finite values to 150 * overflow into opposite-signed infinities; if that occurs, the 151 * final sum will be NaN even if the recorded values are all 152 * finite. It says about "intermediate sums". I could suppose it implies those intermediate sums which are produced during parallel processing. If my supposition is true then: 1) I think it would be good to mention it explicitly because otherwise this excerpt could also be interpreted as if it talks about intermediate sums produced somehow during sequential processing, I'm not sure if this is desirable interpretation. 2) For DoubleSummaryStatistics those intermediate sums are added by calling "combine" I suppose, so I think it would be good to specify in DoubleSummaryStatistics doc, that turning two opposite-signedinfinities into NaN is actually resulted from calling combine(). 3) The result produced from sequential and parallel processing could differ, say considerably. That is for sequential processing it could be +/-INFINITE while for parallel processing - NaN. Would it be good to mention it? Thank you, Georgiy. On 16.07.2014 16:37, Paul Sandoz wrote: > > > Begin forwarded message: > >> *From: *Joe Darcy > >> *Subject: **JDK 9 RFR of JDK-8030942: Explicitly state floating-point >> summation requirements on non-finite inputs* >> *Date: *July 16, 2014 2:29:46 AM GMT+02:00 >> *To: *Core-Libs-Dev > > >> >> Hello, >> >> Please review my changes to address: >> >> JDK-8030942: Explicitly state floating-point summation >> requirements on non-finite inputs >> http://cr.openjdk.java.net/~darcy/8030942.0/ >> >> >> Patch below. >> >> Thanks, >> >> -Joe >> >> --- old/src/share/classes/java/util/DoubleSummaryStatistics.java >> 2014-07-15 17:26:41.000000000 -0700 >> +++ new/src/share/classes/java/util/DoubleSummaryStatistics.java >> 2014-07-15 17:26:41.000000000 -0700 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All >> rights reserved. >> + * Copyright (c) 2012, 2014, Oracle and/or its affiliates. All >> rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -129,9 +129,6 @@ >> * Returns the sum of values recorded, or zero if no values have been >> * recorded. >> * >> - * If any recorded value is a NaN or the sum is at any point a NaN >> - * then the sum will be NaN. >> - * >> *

The value of a floating-point sum is a function both of the >> * input values as well as the order of addition operations. The >> * order of addition operations of this method is intentionally >> @@ -143,6 +140,23 @@ >> * numerical sum compared to a simple summation of {@code double} >> * values. >> * >> + *

If any recorded value is a NaN or the intermediate sum is at >> + * any point a NaN, then the final sum will be NaN. >> + * >> + * If the recorded values contain infinities of opposite sign, the >> + * final sum will be NaN. >> + * >> + * It is possible for intermediate sums of finite values to >> + * overflow into opposite-signed infinities; if that occurs, the >> + * final sum will be NaN even if the recorded values are all >> + * finite. >> + * >> + * If the exact sum is infinite, a properly-signed infinity is >> + * returned. >> + * >> + * If all the recorded values are zero, the sign of zero is >> + * not guaranteed to be preserved in the final sum. >> + * >> * @apiNote Values sorted by increasing absolute magnitude tend >> to yield >> * more accurate results. >> * >> @@ -193,9 +207,6 @@ >> * Returns the arithmetic mean of values recorded, or zero if no >> * values have been recorded. >> * >> - * If any recorded value is a NaN or the sum is at any point a NaN >> - * then the average will be code NaN. >> - * >> *

The average returned can vary depending upon the order in >> * which values are recorded. >> * >> @@ -203,6 +214,10 @@ >> * other technique to reduce the error bound in the {@link #getSum >> * numerical sum} used to compute the average. >> * >> + *

This method can return a NaN or infinite result in the same >> + * kind of numerical situations as {@linkplain #getSum() the sum} >> + * can be NaN or infinite, respectively. >> + * >> * @apiNote Values sorted by increasing absolute magnitude tend >> to yield >> * more accurate results. >> * >> --- old/src/share/classes/java/util/stream/DoubleStream.java >> 2014-07-15 17:26:42.000000000 -0700 >> +++ new/src/share/classes/java/util/stream/DoubleStream.java >> 2014-07-15 17:26:42.000000000 -0700 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All >> rights reserved. >> + * Copyright (c) 2012, 2014, Oracle and/or its affiliates. All >> rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -470,10 +470,7 @@ >> * code is not necessarily equivalent to the summation computation >> * done by this method. >> * >> - *

If any stream element is a NaN or the sum is at any point >> a NaN >> - * then the sum will be NaN. >> - * >> - * The value of a floating-point sum is a function both >> + *

The value of a floating-point sum is a function both >> * of the input values as well as the order of addition >> * operations. The order of addition operations of this method is >> * intentionally not defined to allow for implementation >> @@ -485,6 +482,23 @@ >> * numerical sum compared to a simple summation of {@code double} >> * values. >> * >> + *

If any stream element is a NaN or the intermediate sum is at >> + * any point a NaN, then the final sum will be NaN. >> + * >> + * If the stream elements contain infinities of opposite sign, the >> + * final sum will be NaN. >> + * >> + * It is possible for intermediate sums of finite values to >> + * overflow into opposite-signed infinities; if that occurs, the >> + * final sum will be NaN even if the stream elements are all >> + * finite. >> + * >> + * If the exact sum is infinite, a properly-signed infinity is >> + * returned. >> + * >> + * If all the stream elements are zero, the sign of zero is >> + * not guaranteed to be preserved in the final sum. >> + * >> *

This is a terminal >> * operation. >> * >> @@ -555,9 +569,6 @@ >> * mean of elements of this stream, or an empty optional if this >> * stream is empty. >> * >> - * If any recorded value is a NaN or the sum is at any point a NaN >> - * then the average will be NaN. >> - * >> *

The average returned can vary depending upon the order in >> * which values are recorded. >> * >> @@ -565,6 +576,10 @@ >> * other technique to reduce the error bound in the {@link #sum >> * numerical sum} used to compute the average. >> * >> + *

This method can return a NaN or infinite result in the same >> + * kind of numerical situations as {@linkplain #sum() the sum} can >> + * be NaN or infinite, respectively. >> + * >> *

The average is a special case of a > * href="package-summary.html#Reduction">reduction. >> * >> > From mandy.chung at oracle.com Thu Jul 17 14:43:39 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 17 Jul 2014 07:43:39 -0700 Subject: Review request for 8050804: (jdeps) Recommend supported API to replace use of JDK internal API In-Reply-To: <53C79A46.4030108@oracle.com> References: <53C5BAD7.1040202@oracle.com> <53C679B6.2050206@oracle.com> <53C69595.60000@oracle.com> <53C6FED8.2060708@oracle.com> <53C79A46.4030108@oracle.com> Message-ID: <53C7E11B.4060609@oracle.com> On 7/17/2014 2:41 AM, Daniel Fuchs wrote: > Hi Mandy, > > minor: > JdepsTask.java:977 could be refactored to use putIfAbsent > ok. > I wonder whether the summary table at the end should contain a warning > for all the usage of jdk internals that have no replacement? > It's intentional. The list shown by jdeps is not an excessive list and only includes the classes that I found are used in several products. When we find more jDK internal APIs that are used and have a replacement (or RFE), I'll update the wiki. > Otherwise looks good! I like the output much better :-) > Thanks Mandy > best regards, > > -- daniel > > On 7/17/14 12:38 AM, Mandy Chung wrote: >> Updated webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8050804/webrev.01/ >> >> I plan to backport this to 8u40. >> >> Mandy >> >> On 7/16/14 8:09 AM, Mandy Chung wrote: >>> My first version prints a separate table of the replacements following >>> the new warning message at the end of the jdeps output. I like the >>> first version better than this version replacing rt.jar with "Use..." >>> message. I might be too anxious getting developers to take action >>> using the supported APIs when there is one and hence this version. >>> >>> I'll update the webrev to print as a separate table. >>> >>> thanks >>> Mandy >>> >>> On 7/16/2014 6:10 AM, Daniel Fuchs wrote: >>>> Hi Mandy, >>>> >>>> here is a typical output - with names mangled to save >>>> space: >>>> >>>> s.u.l.p.LPA (rt.jar) >>>> -> s.s.a.GP JDK internal API (Use j.s.PA @since 1.1) >>>> -> s.u.c.CLDRLPA JDK internal API (rt.jar) >>>> >>>> In the first dependency line, the archive name has been replaced >>>> by the 'Use ...' message. >>>> >>>> I wonder whether it would be better to keep the archive name >>>> and print the use message as additional information, in order >>>> to be 'script friendly' so that you could use things like >>>> | grep 'rt.jar' on the output. >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> On 7/16/14 1:35 AM, Mandy Chung wrote: >>>>> jdeps -jdkinternals flags use of JDK internal APIs. We have >>>>> created a >>>>> wiki page to keep track of the JDK internal APIs and its replacement: >>>>> https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool >>>>> >>>>> >>>>> >>>>> While this page will be updated when we identify any new ones >>>>> worthnoting, it'd still be useful for jdeps to suggest the >>>>> replacement >>>>> APIs of the known ones. >>>>> >>>>> webrev at: >>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8050804/webrev.00/ >>>>> >>>>> Mandy >>>> >>> >> > From claes.redestad at oracle.com Thu Jul 17 14:53:04 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 17 Jul 2014 16:53:04 +0200 Subject: FYC: 7197183 : Provide CharSequence.subSequenceView which allows for sub-sequence views of character sequences. In-Reply-To: <715CA12A-461A-4BF2-AC83-06AD953E91F7@oracle.com> References: <715CA12A-461A-4BF2-AC83-06AD953E91F7@oracle.com> Message-ID: <53C7E350.5010700@oracle.com> Hi Mike, while nicely abstracting the problem, promoting developers to re-introduce some of the leakiness that the 7u6 String changes helped remove is something I think we should be wary of. If anything I think such an object should not be Serializable; maybe even have hashCode() throw NotSupportedOperationException() to make sure it's only ever used as a temporary object and prevent abuse? CharSequenceSlice? The alternative - or existing - approach, which admittedly isn't pretty, would be to provide methods with offsets such as Appendable.append(CharSequence, int, int). This avoids need for substring/subSequence or creating any temporary object altogether. The idea with an IntSupplier is pretty neat, though, but could be adopted for the existing offset methods as well. /Claes On 07/17/2014 02:09 AM, Mike Duigou wrote: > Hello all; > > In Java 7u6 there was a significant change in the implementation of java.lang.String (JDK-6924259). This was done to reduce the size of String instances and it has been generally regarded as a positive change. As with almost any significant change to a class as core to Java as String there have also been applications negatively impacted. Most of the problems involve applications which make heavy use of String.substring() as sub-string instances now involve creation of their own copies of the backing characters. > > There have been previous discussions of mitigations to the 6924259 change in String.substring() behaviour. These discussions haven't come to positive conclusions mostly because they generally require too many changes to the specification or behaviour of String. So here's another proposal (enclosed) that doesn't change the behaviour of any existing classes. It adds two new methods to CharSequence to create sub-sequence views of character sequences. The size of sub-sequence instances very closely matches the size of pre-6924259 String instances and indeed the implementation has the same pre-6924259 limitations, namely that the entire source CharSequence remains alive as long as the sub-sequence is referenced. > > Unlike pre-6924259 the CharSubSequenceView can not be reliably compared via equals() to String instances and it is unsuitable for use as a hash map key. > > With these benefits and caveats in mind, would you use this? > > Mike > > diff -r 66f582158e1c src/share/classes/java/lang/CharSequence.java > --- a/src/share/classes/java/lang/CharSequence.java Wed Jul 16 20:43:53 2014 +0100 > +++ b/src/share/classes/java/lang/CharSequence.java Wed Jul 16 16:58:52 2014 -0700 > @@ -25,11 +25,14 @@ > > package java.lang; > > +import java.io.Serializable; > import java.util.NoSuchElementException; > +import java.util.Objects; > import java.util.PrimitiveIterator; > import java.util.Spliterator; > import java.util.Spliterators; > import java.util.function.IntConsumer; > +import java.util.function.IntSupplier; > import java.util.stream.IntStream; > import java.util.stream.StreamSupport; > > @@ -231,4 +234,114 @@ > Spliterator.ORDERED, > false); > } > + > + /** > + * Provides a sub-sequence view on a character sequence. Changes in the > + * source will be reflected in the sub-sequence. The sub-sequence must, at > + * all times, be a proper sub-sequence of the source character sequence. > + * > + * @since 1.9 > + */ > + static final class CharSubSequenceView implements CharSequence, Serializable { > + > + private final CharSequence source; > + private final int fromInclusive; > + private final IntSupplier toExclusive; > + > + CharSubSequenceView(CharSequence source, int fromInclusive, int toExclusive) { > + this(source, fromInclusive, () -> toExclusive); > + } > + > + CharSubSequenceView(CharSequence source, int fromInclusive, IntSupplier toExclusive) { > + this.source = Objects.requireNonNull(source); > + if(fromInclusive < 0 || fromInclusive >= source.length() || > + toExclusive.getAsInt() < fromInclusive || toExclusive.getAsInt() > source.length()) { > + throw new IllegalArgumentException("Invalid index"); > + } > + this.fromInclusive = fromInclusive; > + this.toExclusive = toExclusive; > + } > + > + @Override > + public int length() { > + return toExclusive.getAsInt() - fromInclusive; > + } > + > + @Override > + public char charAt(int index) { > + if(index >= length()) { > + throw new IllegalArgumentException("Invalid Index"); > + } > + // > + return source.charAt(fromInclusive + index); > + } > + > + @Override > + public CharSequence subSequence(int start, int end) { > + if (end > length()) { > + throw new IllegalArgumentException("Invalid Index"); > + } > + return source.subSequence(fromInclusive + start, fromInclusive + end); > + } > + > + @Override > + public String toString() { > + int len = length(); > + char[] chars = new char[len]; > + for(int each = 0; each < len; each++) { > + chars[each] = charAt(each); > + } > + return new String(chars, true); > + } > + } > + > + /** > + * Returns as a character sequence the specified sub-sequence view of the > + * provided source character sequence. Changes in the source will be > + * reflected in the sub-sequence. The sub-sequence must, at all times, be > + * a proper sub-sequence of the source character sequence. > + * > + * @param source The character sequence from which the sub-sequence is > + * derived. > + * @param startInclusive The index of the character in the source character > + * sequence which will be the first character in the sub-sequence. > + * @param endExclusive The index after the last the character in the source > + * character sequence which will be the last character in the sub-sequence > + * @return the character sub-sequence. > + * @since 1.9 > + */ > + static CharSequence subSequenceView(CharSequence source, int startInclusive, int endExclusive) { > + return new CharSubSequenceView(source, startInclusive, endExclusive); > + } > + > + /** > + * Returns as a character sequence the specified sub-sequence view of the > + * provided source character sequence. Changes in the source will be > + * reflected in the sub-sequence. The sub-sequence must, at all times, be > + * a proper sub-sequence of the source character sequence. This variation > + * allows for the size of the sub-sequence to vary, usually to follow the > + * size of a growing character sequence. > + * > + * @apiNote The most common usage of this subSequence is to follow changes > + * in the size of the source. > + * {@code > + * StringBuilder source = new StringBuilder("prefix:"); > + * CharSeqence toEnd = CharSequence.subSequence(source, 7, source::length); > + * } > + * In this example the value of {@code toEnd} will always be a sub-sequence > + * of {@code source} but will omit the first 7 characters. > + * > + * @param source The character sequence from which the sub-sequence is > + * derived. > + * @param startInclusive The index of the character in the source character > + * sequence which will be the first character in the sub-sequence. > + * @param endExclusive A supplier which returns the index after the last the > + * character in the source character sequence which will be the last > + * character in the sub-sequence > + * @return the character sub-sequence. > + * @since 1.9 > + */ > + static CharSequence subSequenceView(CharSequence source, int startInclusive, IntSupplier endExclusive) { > + return new CharSubSequenceView(source, startInclusive, endExclusive); > + } > } > From miroslav.kos at oracle.com Thu Jul 17 15:12:02 2014 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Thu, 17 Jul 2014 17:12:02 +0200 Subject: [9] RFR 8038970: Deprivilege JAX-WS/JAF code Message-ID: <53C7E7C2.5000106@oracle.com> Hi everybody, here is a request for review for 8038970: Deprivilege JAX-WS/JAF code JBS: https://bugs.openjdk.java.net/browse/JDK-8038970 webrev: http://cr.openjdk.java.net/~mkos/8038970/jaxws.04/ This is first part of changes - after this also jdk build will have to be changed. Changeset has been already discussed during testing phase with Sean Mullan and Mandy Chung. Thanks Miran From paul.sandoz at oracle.com Thu Jul 17 15:43:57 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 17 Jul 2014 17:43:57 +0200 Subject: [9] RFR (M): 8050877: Improve code for pairwise argument conversions and value boxing/unboxing In-Reply-To: <53C6A82A.8060501@oracle.com> References: <53C6A82A.8060501@oracle.com> Message-ID: On Jul 16, 2014, at 6:28 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8050877/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8050877 > > Improved MethodHandleImpl.makePairwiseConvert & ValueConversions.unbox and small cleanups in related code. > > Also, improved method handle caching in ValueConversions. > > MethodHandleImpl.makePairwiseConvert: > - * @param level which strength of conversion is allowed > + * @param strict if true, only asType conversions are allowed; if false, explicitCastArguments conversions allowed > + * @param monobox if true, unboxing conversions are assumed to be exactly typed (Integer to int only, not long or double) > > ValueConversions.unbox: > - private static MethodHandle unbox(Wrapper wrap, boolean cast) { > + private static MethodHandle unbox(Wrapper wrap, int kind) { > + // kind 0 -> strongly typed with NPE > + // kind 1 -> strongly typed but zero for null, > + // kind 2 -> asType rules: accept multiple box types but only widening conversions with NPE > + // kind 3 -> explicitCastArguments rules: allow narrowing conversions, zero for null > + WrapperCache cache = UNBOX_CONVERSIONS[kind]; > > Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}. > > Reviewed-by: vlivanov, ? > Contributed-by: john.r.rose at oracle.com > MethodHandleImpl Merge the the 'if' into an 'else if': 365 } else { 366 if (dst.isPrimitive()) { ValueConversions I can see why an EnumMap is used for convenience mapping the Wrapper to MH. IIUC it means the MH ref values are not @Stable? I guess it would be easy to unpack into an explicit array and index from the wrapper ordinal, plus then no additional runtime type checks on the key will be performed for get/put. Dunno how important that is. Can UNBOX_CONVERSIONS be marked as @Stable? does that make any difference? Same for BOX_CONVERSIONS etc. Paul. From mandy.chung at oracle.com Thu Jul 17 16:02:26 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 17 Jul 2014 09:02:26 -0700 Subject: [9] RFR 8038970: Deprivilege JAX-WS/JAF code In-Reply-To: <53C7E7C2.5000106@oracle.com> References: <53C7E7C2.5000106@oracle.com> Message-ID: <53C7F392.9070202@oracle.com> On 7/17/2014 8:12 AM, Miroslav Kos wrote: > Hi everybody, > here is a request for review for > > 8038970: Deprivilege JAX-WS/JAF code > JBS: https://bugs.openjdk.java.net/browse/JDK-8038970 > webrev: http://cr.openjdk.java.net/~mkos/8038970/jaxws.04/ > FYI. The href at the above links were wrong. com/sun/xml/internal/ws/api/streaming/XMLStreamWriterFactory.java line 309: it's fine wrapping with NoSuchMethodError and you can take out throws NoSuchMethodException from line 292 Did you miss JAF classes? As a background, this patch is to prepare for granting minimal set of permissions. Mandy > This is first part of changes - after this also jdk build will have to > be changed. > Changeset has been already discussed during testing phase with Sean > Mullan and Mandy Chung. > > Thanks > Miran From paul.sandoz at oracle.com Thu Jul 17 16:12:42 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 17 Jul 2014 18:12:42 +0200 Subject: [9] RFR (M): 8050884: Intrinsify ValueConversions.identity() functions In-Reply-To: <53C6ABFE.2040004@oracle.com> References: <53C6ABFE.2040004@oracle.com> Message-ID: On Jul 16, 2014, at 6:44 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8050884/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8050884 > > Replace ValueConversions.identity() functions with intrinsics. > > Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}. > > Reviewed-by: vlivanov, ? > Contributed-by: john.r.rose at oracle.com > Looks good. Same question as in previous email on @Stable for MethodHandles.IDENTITY_MHS. FWIW for MethodHandles.IDENTITY_MHS the Wrapper.ordinal() is used as an index rather than using an EnumMap. Paul. From paul.sandoz at oracle.com Thu Jul 17 16:23:28 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 17 Jul 2014 18:23:28 +0200 Subject: [9] RFR (S): 8050887: Intrinsify constants for default values In-Reply-To: <53C6AEE7.8090306@oracle.com> References: <53C6AEE7.8090306@oracle.com> Message-ID: <6EB44980-68DB-43BD-B168-FE122C18A981@oracle.com> On Jul 16, 2014, at 6:57 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8050887/webrev.00 > https://bugs.openjdk.java.net/browse/JDK-8050887 > > Intrinsify MethodHandles.constant() for default values. > > Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}. > > Reviewed-by: vlivanov, ? > Contributed-by: john.r.rose at oracle.com > Looks good. Same question as before on the cached array. Paul. From joe.darcy at oracle.com Thu Jul 17 16:51:21 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 17 Jul 2014 09:51:21 -0700 Subject: Fwd: JDK 9 RFR of JDK-8030942: Explicitly state floating-point summation requirements on non-finite inputs In-Reply-To: <53C7B47A.6070506@oracle.com> References: <53C5C77A.5040500@oracle.com> <49851217-96FD-4A7D-BADB-7857815CF506@oracle.com> <53C7B47A.6070506@oracle.com> Message-ID: <53C7FF09.1060905@oracle.com> Hello, On 07/17/2014 04:33 AM, Georgiy Rakov wrote: > Hello, > > let's consider following excerpt: > > 149 * It is possible for intermediate sums of finite values to > 150 * overflow into opposite-signed infinities; if that occurs, the > 151 * final sum will be NaN even if the recorded values are all > 152 * finite. > It says about "intermediate sums". I could suppose it implies those > intermediate sums which are produced during parallel processing. If my > supposition is true then: Parallel processing is one possible way two intermediate sums can be combined, but since the order of summation is intentionally undefined, even a serial-only computation can have two intermediate sums being combined (as opposed to only combining a new element to an intermediate sum). For example, an allowable implementation of sum() would do pairwise combination of successive elements, then add up pairs of pairs, etc., until the final sum is reached. > > 1) I think it would be good to mention it explicitly because otherwise > this excerpt could also be interpreted as if it talks about > intermediate sums produced somehow during sequential processing, I'm > not sure if this is desirable interpretation. > 2) For DoubleSummaryStatistics those intermediate sums are added by > calling "combine" I suppose, so I think it would be good to specify in > DoubleSummaryStatistics doc, that turning two > opposite-signedinfinities into NaN is actually resulted from calling > combine(). I don't think such detail is necessary or helpful. You can get opposite signed infinities as values in the input. Or you can get opposite signed infinities from being given one infinity as a starting value and then getting the other infinity from overflow. Or you can get both infinities from overflow. I don't think drawing too much distinction between these cases is needed. > 3) The result produced from sequential and parallel processing could > differ, say considerably. That is for sequential processing it could > be +/-INFINITE while for parallel processing - NaN. Would it be good > to mention it? The methods already state something like: 132 *

The value of a floating-point sum is a function both of the 133 * input values as well as the order of addition operations. The 134 * order of addition operations of this method is intentionally 135 * not defined to allow for implementation flexibility to improve 136 * the speed and accuracy of the computed result. Parallel vs serial is only one possible source of the differences that the specification allows; I don't think it is worthwhile calling it out specially. -Joe > > Thank you, > Georgiy. > > On 16.07.2014 16:37, Paul Sandoz wrote: >> >> >> Begin forwarded message: >> >>> *From: *Joe Darcy > >>> *Subject: **JDK 9 RFR of JDK-8030942: Explicitly state >>> floating-point summation requirements on non-finite inputs* >>> *Date: *July 16, 2014 2:29:46 AM GMT+02:00 >>> *To: *Core-Libs-Dev >> > >>> >>> Hello, >>> >>> Please review my changes to address: >>> >>> JDK-8030942: Explicitly state floating-point summation >>> requirements on non-finite inputs >>> http://cr.openjdk.java.net/~darcy/8030942.0/ >>> >>> >>> Patch below. >>> >>> Thanks, >>> >>> -Joe >>> >>> --- old/src/share/classes/java/util/DoubleSummaryStatistics.java >>> 2014-07-15 17:26:41.000000000 -0700 >>> +++ new/src/share/classes/java/util/DoubleSummaryStatistics.java >>> 2014-07-15 17:26:41.000000000 -0700 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All >>> rights reserved. >>> + * Copyright (c) 2012, 2014, Oracle and/or its affiliates. All >>> rights reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> * >>> * This code is free software; you can redistribute it and/or modify it >>> @@ -129,9 +129,6 @@ >>> * Returns the sum of values recorded, or zero if no values have >>> been >>> * recorded. >>> * >>> - * If any recorded value is a NaN or the sum is at any point a NaN >>> - * then the sum will be NaN. >>> - * >>> *

The value of a floating-point sum is a function both of the >>> * input values as well as the order of addition operations. The >>> * order of addition operations of this method is intentionally >>> @@ -143,6 +140,23 @@ >>> * numerical sum compared to a simple summation of {@code double} >>> * values. >>> * >>> + *

If any recorded value is a NaN or the intermediate sum is at >>> + * any point a NaN, then the final sum will be NaN. >>> + * >>> + * If the recorded values contain infinities of opposite sign, the >>> + * final sum will be NaN. >>> + * >>> + * It is possible for intermediate sums of finite values to >>> + * overflow into opposite-signed infinities; if that occurs, the >>> + * final sum will be NaN even if the recorded values are all >>> + * finite. >>> + * >>> + * If the exact sum is infinite, a properly-signed infinity is >>> + * returned. >>> + * >>> + * If all the recorded values are zero, the sign of zero is >>> + * not guaranteed to be preserved in the final sum. >>> + * >>> * @apiNote Values sorted by increasing absolute magnitude tend >>> to yield >>> * more accurate results. >>> * >>> @@ -193,9 +207,6 @@ >>> * Returns the arithmetic mean of values recorded, or zero if no >>> * values have been recorded. >>> * >>> - * If any recorded value is a NaN or the sum is at any point a NaN >>> - * then the average will be code NaN. >>> - * >>> *

The average returned can vary depending upon the order in >>> * which values are recorded. >>> * >>> @@ -203,6 +214,10 @@ >>> * other technique to reduce the error bound in the {@link #getSum >>> * numerical sum} used to compute the average. >>> * >>> + *

This method can return a NaN or infinite result in the same >>> + * kind of numerical situations as {@linkplain #getSum() the sum} >>> + * can be NaN or infinite, respectively. >>> + * >>> * @apiNote Values sorted by increasing absolute magnitude tend >>> to yield >>> * more accurate results. >>> * >>> --- old/src/share/classes/java/util/stream/DoubleStream.java >>> 2014-07-15 17:26:42.000000000 -0700 >>> +++ new/src/share/classes/java/util/stream/DoubleStream.java >>> 2014-07-15 17:26:42.000000000 -0700 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All >>> rights reserved. >>> + * Copyright (c) 2012, 2014, Oracle and/or its affiliates. All >>> rights reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> * >>> * This code is free software; you can redistribute it and/or modify it >>> @@ -470,10 +470,7 @@ >>> * code is not necessarily equivalent to the summation computation >>> * done by this method. >>> * >>> - *

If any stream element is a NaN or the sum is at any point >>> a NaN >>> - * then the sum will be NaN. >>> - * >>> - * The value of a floating-point sum is a function both >>> + *

The value of a floating-point sum is a function both >>> * of the input values as well as the order of addition >>> * operations. The order of addition operations of this method is >>> * intentionally not defined to allow for implementation >>> @@ -485,6 +482,23 @@ >>> * numerical sum compared to a simple summation of {@code double} >>> * values. >>> * >>> + *

If any stream element is a NaN or the intermediate sum is at >>> + * any point a NaN, then the final sum will be NaN. >>> + * >>> + * If the stream elements contain infinities of opposite sign, the >>> + * final sum will be NaN. >>> + * >>> + * It is possible for intermediate sums of finite values to >>> + * overflow into opposite-signed infinities; if that occurs, the >>> + * final sum will be NaN even if the stream elements are all >>> + * finite. >>> + * >>> + * If the exact sum is infinite, a properly-signed infinity is >>> + * returned. >>> + * >>> + * If all the stream elements are zero, the sign of zero is >>> + * not guaranteed to be preserved in the final sum. >>> + * >>> *

This is a terminal >>> * operation. >>> * >>> @@ -555,9 +569,6 @@ >>> * mean of elements of this stream, or an empty optional if this >>> * stream is empty. >>> * >>> - * If any recorded value is a NaN or the sum is at any point a NaN >>> - * then the average will be NaN. >>> - * >>> *

The average returned can vary depending upon the order in >>> * which values are recorded. >>> * >>> @@ -565,6 +576,10 @@ >>> * other technique to reduce the error bound in the {@link #sum >>> * numerical sum} used to compute the average. >>> * >>> + *

This method can return a NaN or infinite result in the same >>> + * kind of numerical situations as {@linkplain #sum() the sum} can >>> + * be NaN or infinite, respectively. >>> + * >>> *

The average is a special case of a >> * href="package-summary.html#Reduction">reduction. >>> * >>> >> > From xueming.shen at oracle.com Thu Jul 17 17:15:17 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 17 Jul 2014 10:15:17 -0700 Subject: RFR: JDK-8042589: String.toLowerCase do not work for some concatenated strings In-Reply-To: <53C79D48.40803@CoSoCo.de> References: <53BDA056.8050305@oracle.com> <53C702E8.8060709@oracle.com> <53C79D48.40803@CoSoCo.de> Message-ID: <53C804A5.5090504@oracle.com> Let's fix the regression first, before make any more "optimization" :-) -Sherman On 07/17/2014 02:54 AM, Ulf Zibis wrote: > There is again another little optimization possible: > > instead > hasSurr = true; > we could use > first = ~first; > and save variable hasSurr. > > If there is register pressure (especially on older CPUs), this might be a performance advantage. > > Also I think we should not grow the result array for any character where "mapLen > srcCount", we could wait until the result array is actually full. > > -Ulf > > > Am 17.07.2014 00:55, schrieb Xueming Shen: >> Still need a reviewer. >> >> On 07/09/2014 01:04 PM, Xueming Shen wrote: >>> Hi, >>> >>> Please help review the change for JDK-8042589. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8042589 >>> webrev: http://cr.openjdk.java.net/~sherman/8042589/webrev/ >>> >>> This is a regression caused by the following change for #JDK-8032012, >>> >>> issue: https://bugs.openjdk.java.net/browse/JDK-8032012 >>> webrev: http://cr.openjdk.java.net/~sherman/8032012/ >>> discussion: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/024862.html >>> >>> It appears the last optimization for the surrogates we pushed in is >>> incomplete. We still need to check isSurrogate() in the optimized >>> non-surrogate loop, as the "first" (checked at the very beginning) might >>> be triggered by a non-surrogate-upper/lowercase char. >>> >>> Thanks! >>> -Sherman >> >> > From stevenschlansker at gmail.com Thu Jul 17 17:17:02 2014 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Thu, 17 Jul 2014 10:17:02 -0700 Subject: please review draft JEP: Convenience Factory Methods for Collections In-Reply-To: <53C71CFC.8020903@oracle.com> References: <53C71CFC.8020903@oracle.com> Message-ID: On Jul 16, 2014, at 5:46 PM, Stuart Marks wrote: > Hi all, > > Please review this draft JEP for Convenience Factory Methods for Collections: > > https://bugs.openjdk.java.net/browse/JDK-8048330 > > Brief background: several times over the years there have been proposals to add "collection literals" to the language. The most recent round of this was in regard to JEP 186, a research JEP to explore this topic. That effort was concluded by Brian Goetz, as summarized in this email: > > http://mail.openjdk.java.net/pipermail/lambda-dev/2014-March/011938.html > > Essentially, the idea of adding collection literals to the language was set aside in favor of adding some library APIs, not entirely unlike collection literals, that make it more convenient to create collections. That's what this proposal is. This is fantastic, I think a large number of developers will cheer as more and more of Guava makes it into core libs :) One thing I notice is that you take a lot of care to not specify how the Map or Set will be implemented. This could be troublesome because different implementations have different requirements for keys ? e.g. HashMap requires hashCode()/equals() but SortedMap requires compareTo(). It seems unlikely that the implementation could reasonably require anything other than equals() and maybe hashCode(), but given the headache created by over/underspecifying maybe clarifying this is worth considering. As another note, you briefly mentioned immutable implementations of Map, Set, and List. These types are well worth adding to the JDK in my opinion - if you try to design an immutable data structure containing such types, you are forced to make many defensive copies to ensure they cannot later be modified. With immutable implementations, defensive copies are trivially cheap or free, which is a great boon to library maintainers. Looking forward to being able to use this! Steven From daniel.smith at oracle.com Thu Jul 17 17:40:03 2014 From: daniel.smith at oracle.com (Dan Smith) Date: Thu, 17 Jul 2014 11:40:03 -0600 Subject: please review draft JEP: Convenience Factory Methods for Collections In-Reply-To: <53C71CFC.8020903@oracle.com> References: <53C71CFC.8020903@oracle.com> Message-ID: The motivation section ought to more directly survey what we have now: - Collections.emptyList/emptySet/emptyMap - Collections.singletonList/singleton/singletonMap - Arrays.asList - EnumSet.of (varargs, plus some overloads) - Stream.empty and Stream.of (singleton plus varargs) - Constructors that, by convention, always have a variant that constructs an empty collection and another to copy the contents of an existing collection This helps to clarify that there are multiple goals: - Provide some default methods in List/Set/Map for easier access to existing behavior (following the pattern of EnumSet) - Add new functionality to create immutable Sets/Maps for 2 <= n <= small number. - (Maybe?) varargs methods to create immutable Sets/Maps or arbitrary size. - Provide an array-less implementation of immutable Lists for 2 <= n <= small number. ---------- "If a mutable collection is desired, the contents of an immutable collection can easily be copied into a collection type of the caller's choice." ... "If there are sufficient use cases to support convenient creation of mutable collections, factory methods for particular mutable collection classes could be added." Following the existing convention, it might make more sense to make these constructors: ArrayList() ArrayList(Collection) ArrayList(E...) // this is new ---------- "Converting a mutable collection into an immutable one is more difficult." In principle, if you've got a varargs List creation method, there's nothing to stop you from overloading it with an Collection/Iterable/Stream version. Same functionality, although this might encourage users to think that larger collections will behave properly. (You could pass in a large array to the varargs method, but presumably most users will be passing in small varargs lists.) ---------- I was curious about other collections that might benefit. - It turns out Queue and Deque are pretty useless as immutable data structures. - SortedSet and SortedMap could be useful. - Stream could probably be made consistent with the overloading scheme you settle on; EnumSet, too, if it's different. - There might be some use cases for Iterator; likely doesn't carry its weight, though. ?Dan On Jul 16, 2014, at 6:46 PM, Stuart Marks wrote: > Hi all, > > Please review this draft JEP for Convenience Factory Methods for Collections: > > https://bugs.openjdk.java.net/browse/JDK-8048330 > > Brief background: several times over the years there have been proposals to add "collection literals" to the language. The most recent round of this was in regard to JEP 186, a research JEP to explore this topic. That effort was concluded by Brian Goetz, as summarized in this email: > > http://mail.openjdk.java.net/pipermail/lambda-dev/2014-March/011938.html > > Essentially, the idea of adding collection literals to the language was set aside in favor of adding some library APIs, not entirely unlike collection literals, that make it more convenient to create collections. That's what this proposal is. > > Share and enjoy, > > s'marks > From mark.reinhold at oracle.com Thu Jul 17 21:19:58 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 17 Jul 2014 14:19:58 -0700 Subject: Covariant overrides on the Buffer Hierarchy redux In-Reply-To: <3D27B84B-20F1-486C-954F-E908DD443DA9@oracle.com> References: <3D27B84B-20F1-486C-954F-E908DD443DA9@oracle.com> Message-ID: <20140717141958.734274@eggemoggin.niobe.net> 2014/7/15 22:58 -0700, paul.sandoz at oracle.com: > There was discussion here: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-April/026458.html > > https://bugs.openjdk.java.net/browse/JDK-4774077 > > http://cr.openjdk.java.net/~rwarburton/buffer-overrides-1/ > > The patch looks good. Agreed! Glad to see this (finally) get done. - Mark From stuart.marks at oracle.com Thu Jul 17 21:36:50 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 17 Jul 2014 14:36:50 -0700 Subject: please review draft JEP: Convenience Factory Methods for Collections In-Reply-To: <364C8776-4E58-4D6E-933D-0C8D156E5667@saxonica.com> References: <53C71CFC.8020903@oracle.com> <364C8776-4E58-4D6E-933D-0C8D156E5667@saxonica.com> Message-ID: <53C841F2.8090009@oracle.com> On 7/17/14 12:21 AM, Michael Kay wrote: > Set.of() and List.of() look very attractive; Map.of() looks very ugly. The proposed Map.of() API offends our sensibilities as programmers, because of its repetition and its lack of generality. I think that's what you mean by "ugly". There is a indeed certain amount of unpleasantness in the specification and implementation of the fix-arg Map.of() methods. But this doesn't show up in actual usage. > I would much prefer to write something like > > Map.of( > Map.pair(key, value), > Map.pair(key, value), > Map.pair(key, value) > ); > > and have no limit on the number of pairs. (Don't care how it works internally...) OK, let's posit the existance of a static Map.entry(k,v) method which will return an AbstractMap.SimpleImmutableEntry of (k,v). (AM.SIE would make a nice pair class but its name is so damned long!) Users will presumably statically import this method. One could then write: Map map = Map.of( entry("BMW", 5), entry("Mercedes", 3), entry("Audi", 4), entry("Ford", 10)); Compare this to the old-fashioned create-then-add technique: Map map = new HashMap<>(); map.put("BMW", 5); map.put("Mercedes", 3); map.put("Audi", 4); map.put("Ford", 10); map = Collections.unmodifiableMap(map); Compared to this, the varargs list of entries reduces the visual clutter some, but not a tremendous amount. There is a smaller difference if you don't care to create the unmodifiable wrapper in the second case. Now compare this to the proposed fixed-args version: Map map = Map.of( "BMW", 5, "Mercedes", 3, "Audi", 4, "Ford", 10); That looks quite a bit simpler. In particular, there is no longer a pair of parentheses around each key-value pair like there is in the other example. That makes things visually much nicer in my estimation. The varargs of map entries is clearly more general. Do we need that generality, and are we willing to put up with more clutter to get that generality? > The last thing I want is to have to rewrite all my code when someone asks me to add a sixth entry to the map initialization! Well, Remi had proposed raising the limit. Suppose we offered 7 key-value pairs instead of 5. Would you then complain about having to rewrite your code if you had to add an 8th entry to the map? (Repeat for any N, N+1.) A fixed-arg approach, while not fully general, can be tailored to solve 80%, or 95%, or 99.9%, or whatever percentage of the cases we choose to solve. Beyond a certain point the benefit provided by a varargs approach vs a fixed N approach becomes vanishingly small. I don't have the numbers at my fingertips, that point is reached very quickly, say around N = 5. But maybe it's a bit higher. The tradeoff here is that we are willing to put up with a certain amount of API ugliness in order to make people's programs nicer. If we can cover a vast majority of people's cases, that's just fine, even if it's not fully general. s'marks (Example data from examples.javacodegeeks.com) > Michael Kay > Saxonica > mike at saxonica.com > +44 (0118) 946 5893 > > > > On 17 Jul 2014, at 01:46, Stuart Marks wrote: > >> Hi all, >> >> Please review this draft JEP for Convenience Factory Methods for Collections: >> >> https://bugs.openjdk.java.net/browse/JDK-8048330 >> >> Brief background: several times over the years there have been proposals to add "collection literals" to the language. The most recent round of this was in regard to JEP 186, a research JEP to explore this topic. That effort was concluded by Brian Goetz, as summarized in this email: >> >> http://mail.openjdk.java.net/pipermail/lambda-dev/2014-March/011938.html >> >> Essentially, the idea of adding collection literals to the language was set aside in favor of adding some library APIs, not entirely unlike collection literals, that make it more convenient to create collections. That's what this proposal is. >> >> Share and enjoy, >> >> s'marks >> > From stuart.marks at oracle.com Thu Jul 17 21:56:33 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 17 Jul 2014 14:56:33 -0700 Subject: please review draft JEP: Convenience Factory Methods for Collections In-Reply-To: <53C77F4D.6000106@oracle.com> References: <53C71CFC.8020903@oracle.com> <53C77F4D.6000106@oracle.com> Message-ID: <53C84691.5080902@oracle.com> On 7/17/14 12:46 AM, Tom Hawtin wrote: > I note that with the basic proposal, HashSet.of and indeed NavigableSet.of still > work. They just do the wrong thing. I should have made more clear in the JEP that the proposed APIs are static methods on the List/Map/Set interfaces, not default methods. Thus they won't be inherited by any subinterfaces or implementors. s'marks From mike.duigou at oracle.com Thu Jul 17 22:05:46 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 17 Jul 2014 15:05:46 -0700 Subject: RFR: 8051057: (s) Optimize StringCharBuffer.toString(int, int) Message-ID: Hello all; While investigating another issue I ran across some code in java.nio.StringCharBuffer.toString(int, int) which might be possible to improve. Currently the implementation calls toString() on the source CharSequence and then uses String.substring to create the desired range. For the current String, StringBuilder and StringBuffer implementations it would be more efficient to first generate the subSequence via CharSequence.subSequence(int, int) and then call toString() on the sub-sequence. For these classes the toString() is actually a NOP as their CharSequence.subSequence(int, int) implementations return a String instance. I looked for other CharSequence implementations and couldn't find any which would preform better with current StringCharBuffer.toString(int, int) implementation. jbsbug: https://bugs.openjdk.java.net/browse/JDK-8051057 webrev: http://cr.openjdk.java.net/~mduigou/JDK-8051057/0/webrev/ Does this seem like a worthwhile improvement for all of the important CharSequence implementations? Mike From stuart.marks at oracle.com Thu Jul 17 22:17:09 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 17 Jul 2014 15:17:09 -0700 Subject: please review draft JEP: Convenience Factory Methods for Collections In-Reply-To: References: <53C71CFC.8020903@oracle.com> Message-ID: <53C84B65.9060308@oracle.com> On 7/17/14 10:17 AM, Steven Schlansker wrote: > This is fantastic, I think a large number of developers will cheer as more and more of Guava > makes it into core libs :) Great! > One thing I notice is that you take a lot of care to not specify how the Map or Set will be implemented. > This could be troublesome because different implementations have different requirements for keys ? > e.g. HashMap requires hashCode()/equals() but SortedMap requires compareTo(). > > It seems unlikely that the implementation could reasonably require anything other than equals() and maybe > hashCode(), but given the headache created by over/underspecifying maybe clarifying this is worth considering. First, I should clarify that these are static factory methods on the interfaces, not default methods. Thus they aren't inherited, and there won't be any complications arising from additional subinterface requirements, such as how SortedMap requires elements to be Comparable. (Unless a comparator is provided, etc.) The implementations of instances returned by these factory methods fulfil just the basic interfaces. In particular, the notion of duplicate elements or keys for Set and Map are defined by equals(), so that's all they have to support. > As another note, you briefly mentioned immutable implementations of Map, Set, and List. These types are well > worth adding to the JDK in my opinion - if you try to design an immutable data structure containing such > types, you are forced to make many defensive copies to ensure they cannot later be modified. With immutable > implementations, defensive copies are trivially cheap or free, which is a great boon to library maintainers. Yes, I certainly see the value in having implementations of immutable collections. There would be some relationship to this "convenience factories" project, but they aren't necessarily the same thing. If a couple really useful immutable implementations could be slipped in, sure, it might work out. But if it turns into a big design discussion with lots of different implementations -- consider ImmutableHashMap, ImmutableTreeMap, etc. -- then it begins to sound like a different effort. s'marks From stuart.marks at oracle.com Thu Jul 17 22:54:04 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 17 Jul 2014 15:54:04 -0700 Subject: please review draft JEP: Convenience Factory Methods for Collections In-Reply-To: References: <53C71CFC.8020903@oracle.com> Message-ID: <53C8540C.5050604@oracle.com> Hi Dan, thanks for the feedback. On 7/17/14 10:40 AM, Dan Smith wrote: > The motivation section ought to more directly survey what we have now: > - Collections.emptyList/emptySet/emptyMap > - Collections.singletonList/singleton/singletonMap > - Arrays.asList > - EnumSet.of (varargs, plus some overloads) > - Stream.empty and Stream.of (singleton plus varargs) > - Constructors that, by convention, always have a variant that constructs an empty collection and another to copy the contents of an existing collection > > This helps to clarify that there are multiple goals: > - Provide some default methods in List/Set/Map for easier access to existing behavior (following the pattern of EnumSet) > - Add new functionality to create immutable Sets/Maps for 2 <= n <= small number. > - (Maybe?) varargs methods to create immutable Sets/Maps or arbitrary size. > - Provide an array-less implementation of immutable Lists for 2 <= n <= small number. WAT, you mean not everybody is a collections expert? :-) Sure, I could add some background here. The relationship with the Collections.empty* and Collections.singleton* methods is especially interesting. They're not very discoverable; they're somewhat verbose, and the naming is odd. (Where is singletonSet? oh.) The implementation returned by Arrays.asList is also incredibly useful but is something of a strange beast compared to other collections. > "If a mutable collection is desired, the contents of an immutable collection can easily be copied into a collection type of the caller's choice." ... "If there are sufficient use cases to support convenient creation of mutable collections, factory methods for particular mutable collection classes could be added." > > Following the existing convention, it might make more sense to make these constructors: > ArrayList() > ArrayList(Collection) > ArrayList(E...) // this is new Note there is also ArrayList(int initialCapacity). This brings in the old constructor-vs-factory-method discussion. A constructor is reasonable since we have no intention of returning an instance of a subclass, which would be a point in favor of a static factory. But I'm concerned about adding the varargs constructor next to existing constructors. Many of the collections have additional constructors besides the ones provided by convention. There may not be any actual ambiguity, but surprising behaviors would result. For example, in List list1 = new ArrayList<>(1, 2); List list2 = new ArrayList<>(3); list1 would be [1, 2] as expected but list2 would be an empty list with an initial capacity of 3. HashSet has a similar issues with the constructor HashSet(int initialCapacity, float loadFactor) > "Converting a mutable collection into an immutable one is more difficult." > > In principle, if you've got a varargs List creation method, there's nothing to stop you from overloading it with an Collection/Iterable/Stream version. Same functionality, although this might encourage users to think that larger collections will behave properly. (You could pass in a large array to the varargs method, but presumably most users will be passing in small varargs lists.) What I meant by "...is more difficult" is that, prior to any of these proposals, creating an immutable collection when given a mutable one is more difficult. (Or at least, it's a pain.) You could copy the collection into a new collection, and then wrap it in an unmodifiable wrapper. Or you could import a third party library with actual immutable collections. Or you could write your own. I guess I should clarify this too. If we were to add a family of immutable collections to the JDK, as has popped up a couple times on this thread, its constructors or factories should clearly be able to consume other collections, streams, etc. > I was curious about other collections that might benefit. > - It turns out Queue and Deque are pretty useless as immutable data structures. > - SortedSet and SortedMap could be useful. > - Stream could probably be made consistent with the overloading scheme you settle on; EnumSet, too, if it's different. > - There might be some use cases for Iterator; likely doesn't carry its weight, though. Yes, interesting. Most collection implementations have special features that apply to mutability. The Sorted (or maybe Navigable) variations of Set or Map could be useful though. s'marks > ?Dan > > On Jul 16, 2014, at 6:46 PM, Stuart Marks wrote: > >> Hi all, >> >> Please review this draft JEP for Convenience Factory Methods for Collections: >> >> https://bugs.openjdk.java.net/browse/JDK-8048330 >> >> Brief background: several times over the years there have been proposals to add "collection literals" to the language. The most recent round of this was in regard to JEP 186, a research JEP to explore this topic. That effort was concluded by Brian Goetz, as summarized in this email: >> >> http://mail.openjdk.java.net/pipermail/lambda-dev/2014-March/011938.html >> >> Essentially, the idea of adding collection literals to the language was set aside in favor of adding some library APIs, not entirely unlike collection literals, that make it more convenient to create collections. That's what this proposal is. >> >> Share and enjoy, >> >> s'marks >> > From john.r.rose at oracle.com Fri Jul 18 00:12:23 2014 From: john.r.rose at oracle.com (John Rose) Date: Thu, 17 Jul 2014 17:12:23 -0700 Subject: [9] RFR (M): 8050052: Small cleanups in java.lang.invoke code In-Reply-To: <53C6C278.4060505@gmail.com> References: <53C00E62.20703@oracle.com> <53C02534.2040000@univ-mlv.fr> <96C06C20-2479-47A2-94F9-49C987AE58A9@oracle.com> <53C696CA.3040908@gmail.com> <53C6C278.4060505@gmail.com> Message-ID: <92054EE4-89C5-4772-8324-4165D0A64710@oracle.com> On Jul 16, 2014, at 11:20 AM, Peter Levart wrote: > An alternative could be: > > public Throwable throwIfUnchecked() { > if (this instanceof RuntimeException) throw (RuntimeException) this; > if (this instanceof Error) throw (Error) this; > return this; > } > > Then use it like: > > try { > ... > } catch (Throwable t) { > throw new WrapperException(t.throwIfUnchecked()); > } I like this one. (I wish we could declare This types, so that TYPEOF[t.throwIfUnchecked()] == TYPEOF[t].) It puts the throw of the "less dangerous" exception type inside the subroutine, making the wrapping and the "more dangerous" (more ad hoc) exception be explicit and in-line. To complete the picture, add: public Throwable throwIf(Class exClass) throws X { if (exClass.isInstance(this)) throw exClass.cast(this); return this; } ...to be used as: try { ... } catch (Throwable t) { t.throwIfUnchecked().throwIf(X.class).throwIf(Y.class).throwIf(Z.class); throw new WrapperException(t); } Or some other combination of sequential and/or fluent calls. ? John From weijun.wang at oracle.com Fri Jul 18 00:52:18 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 18 Jul 2014 08:52:18 +0800 Subject: Different notations for static and instance methods In-Reply-To: <53C84691.5080902@oracle.com> References: <53C71CFC.8020903@oracle.com> <53C77F4D.6000106@oracle.com> <53C84691.5080902@oracle.com> Message-ID: We should define different notations for static and instance methods. For example, List.of and List::of, although I admit it is quite confusing. --Max On Jul 18, 2014, at 5:56, Stuart Marks wrote: > On 7/17/14 12:46 AM, Tom Hawtin wrote: >> I note that with the basic proposal, HashSet.of and indeed NavigableSet.of still >> work. They just do the wrong thing. > > I should have made more clear in the JEP that the proposed APIs are static methods on the List/Map/Set interfaces, not default methods. Thus they won't be inherited by any subinterfaces or implementors. > > s'marks From john.r.rose at oracle.com Fri Jul 18 01:54:48 2014 From: john.r.rose at oracle.com (John Rose) Date: Thu, 17 Jul 2014 18:54:48 -0700 Subject: [9] RFR (M): 8050052: Small cleanups in java.lang.invoke code In-Reply-To: <92054EE4-89C5-4772-8324-4165D0A64710@oracle.com> References: <53C00E62.20703@oracle.com> <53C02534.2040000@univ-mlv.fr> <96C06C20-2479-47A2-94F9-49C987AE58A9@oracle.com> <53C696CA.3040908@gmail.com> <53C6C278.4060505@gmail.com> <92054EE4-89C5-4772-8324-4165D0A64710@oracle.com> Message-ID: FTR, I captured this issue: https://bugs.openjdk.java.net/browse/JDK-8051294 (Wish they were all so easy to catch.) ? John On Jul 17, 2014, at 5:12 PM, John Rose wrote: > On Jul 16, 2014, at 11:20 AM, Peter Levart wrote: > >> An alternative could be: >> >> public Throwable throwIfUnchecked() { >> if (this instanceof RuntimeException) throw (RuntimeException) this; >> if (this instanceof Error) throw (Error) this; >> return this; >> } >> >> Then use it like: >> >> try { >> ... >> } catch (Throwable t) { >> throw new WrapperException(t.throwIfUnchecked()); >> } > > I like this one. (I wish we could declare This types, so that TYPEOF[t.throwIfUnchecked()] == TYPEOF[t].) > > It puts the throw of the "less dangerous" exception type inside the subroutine, making the wrapping and the "more dangerous" (more ad hoc) exception be explicit and in-line. > > To complete the picture, add: > > public Throwable throwIf(Class exClass) throws X { > if (exClass.isInstance(this)) throw exClass.cast(this); > return this; > } > > ...to be used as: > > try { > ... > } catch (Throwable t) { > t.throwIfUnchecked().throwIf(X.class).throwIf(Y.class).throwIf(Z.class); > throw new WrapperException(t); > } > > Or some other combination of sequential and/or fluent calls. > > ? John From tom.hawtin at oracle.com Fri Jul 18 02:46:31 2014 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Fri, 18 Jul 2014 03:46:31 +0100 Subject: please review draft JEP: Convenience Factory Methods for Collections In-Reply-To: <53C84691.5080902@oracle.com> References: <53C71CFC.8020903@oracle.com> <53C77F4D.6000106@oracle.com> <53C84691.5080902@oracle.com> Message-ID: <53C88A87.3030407@oracle.com> On 17/07/2014 22:56, Stuart Marks wrote: > On 7/17/14 12:46 AM, Tom Hawtin wrote: >> I note that with the basic proposal, HashSet.of and indeed >> NavigableSet.of still >> work. They just do the wrong thing. > > I should have made more clear in the JEP that the proposed APIs are > static methods on the List/Map/Set interfaces, not default methods. Thus > they won't be inherited by any subinterfaces or implementors. Ah, static methods of interfaces behave differently to class methods. The language corner case I'm missing is in 8.4.8 (of Java SE 8 JLS) for classes "A class does not inherit static methods from its superinterfaces." and 9.2 for interfaces (if I've parsed this correctly) "The interface inherits, from the interfaces it extends, all members of those interfaces, except for fields, classes, and interfaces that it hides; abstract or default methods that it overrides (9.4.1); and static methods." Tom From mandy.chung at oracle.com Fri Jul 18 04:56:13 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 17 Jul 2014 21:56:13 -0700 Subject: Review request for 8050968: Extension class loader initialization fails on Win7 x64 zh_TW Message-ID: <53C8A8ED.4060106@oracle.com> This is a regression caused by JDK-8038177 that changed sun.nio.cs.ext.ExtendedCharsets to use lambda. It turns out that ExtendedCharsets is loaded during the initialization of the extension class loader when opening jre/lib/ext/meta-index on windows with system locale loading extended charsets and caused the initialization error. The fix is not to avoid lambda in ExtendedCharsets getting the system property value. At some point in the future, I'd like to take a closer look at the system initialization path and what we can do better. Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8050968/webrev.00/ thanks Mandy From mandy.chung at oracle.com Fri Jul 18 04:57:52 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 17 Jul 2014 21:57:52 -0700 Subject: Review request for 8050968: Extension class loader initialization fails on Win7 x64 zh_TW In-Reply-To: <53C8A8ED.4060106@oracle.com> References: <53C8A8ED.4060106@oracle.com> Message-ID: <53C8A950.7020602@oracle.com> On 7/17/2014 9:56 PM, Mandy Chung wrote: > This is a regression caused by JDK-8038177 that changed > sun.nio.cs.ext.ExtendedCharsets to use lambda. It turns out that > ExtendedCharsets is loaded during the initialization of the extension > class loader when opening jre/lib/ext/meta-index on windows with system > locale loading extended charsets and caused the initialization error. > > The fix is not to avoid lambda in ExtendedCharsets getting the system s/avoid/use Mandy > property value. At some point in the future, I'd like to take a closer > look at the system initialization path and what we can do better. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8050968/webrev.00/ > > thanks > Mandy > From david.holmes at oracle.com Fri Jul 18 05:11:14 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Jul 2014 15:11:14 +1000 Subject: Review request for 8050968: Extension class loader initialization fails on Win7 x64 zh_TW In-Reply-To: <53C8A950.7020602@oracle.com> References: <53C8A8ED.4060106@oracle.com> <53C8A950.7020602@oracle.com> Message-ID: <53C8AC72.8030804@oracle.com> Hi Mandy, On 18/07/2014 2:57 PM, Mandy Chung wrote: > > On 7/17/2014 9:56 PM, Mandy Chung wrote: >> This is a regression caused by JDK-8038177 that changed >> sun.nio.cs.ext.ExtendedCharsets to use lambda. It turns out that >> ExtendedCharsets is loaded during the initialization of the extension >> class loader when opening jre/lib/ext/meta-index on windows with system >> locale loading extended charsets and caused the initialization error. >> >> The fix is not to avoid lambda in ExtendedCharsets getting the system > > s/avoid/use This looks okay to me. It is unfortunately very hard to know how introducing a lambda expression can affect the initialization order, particularly when it may depend on locales etc. David ----- > Mandy > >> property value. At some point in the future, I'd like to take a closer >> look at the system initialization path and what we can do better. >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8050968/webrev.00/ >> >> thanks >> Mandy >> > From peter.levart at gmail.com Fri Jul 18 07:57:29 2014 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 18 Jul 2014 09:57:29 +0200 Subject: FYC: 7197183 : Provide CharSequence.subSequenceView which allows for sub-sequence views of character sequences. In-Reply-To: <715CA12A-461A-4BF2-AC83-06AD953E91F7@oracle.com> References: <715CA12A-461A-4BF2-AC83-06AD953E91F7@oracle.com> Message-ID: Hi Mike, Just a warning that CharSubSequenceView is a public class, which is not what you wanted it to be, I think, since its constructors are pkg private. IntSupplier trick is nice, but it makes the wrapper object heavier. If the purpose was to support tracking source sequence length with some optional constant offset (I.e. source.length() - n) then an overloaded method could do the trick. Did you have any other use case in mind? Regards, Peter From Alan.Bateman at oracle.com Fri Jul 18 08:15:37 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 18 Jul 2014 09:15:37 +0100 Subject: Review request for 8050968: Extension class loader initialization fails on Win7 x64 zh_TW In-Reply-To: <53C8A8ED.4060106@oracle.com> References: <53C8A8ED.4060106@oracle.com> Message-ID: <53C8D7A9.8010102@oracle.com> On 18/07/2014 05:56, Mandy Chung wrote: > : > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8050968/webrev.00/ > This looks okay for now. We've had a few other issues like this too, you might remember trying to use lambda in ServiceLoader which leads to recursive initialization. It's definitely an area that needs attention. -Alan. From mike at saxonica.com Fri Jul 18 08:11:17 2014 From: mike at saxonica.com (Michael Kay) Date: Fri, 18 Jul 2014 09:11:17 +0100 Subject: please review draft JEP: Convenience Factory Methods for Collections In-Reply-To: <53C841F2.8090009@oracle.com> References: <53C71CFC.8020903@oracle.com> <364C8776-4E58-4D6E-933D-0C8D156E5667@saxonica.com> <53C841F2.8090009@oracle.com> Message-ID: > > Well, Remi had proposed raising the limit. Suppose we offered 7 key-value pairs instead of 5. Would you then complain about having to rewrite your code if you had to add an 8th entry to the map? Yes, I would. In fact, the higher you make the limit, the bigger the surprise when I find I cannot extend my code in the natural way by adding one more entry. Michael Kay Saxonica From weijun.wang at oracle.com Fri Jul 18 09:09:21 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 18 Jul 2014 17:09:21 +0800 Subject: please review draft JEP: Convenience Factory Methods for Collections In-Reply-To: References: <53C71CFC.8020903@oracle.com> <364C8776-4E58-4D6E-933D-0C8D156E5667@saxonica.com> <53C841F2.8090009@oracle.com> Message-ID: <802A6202-44DF-48A6-A858-69062A7BADD4@oracle.com> A .with(k, v) to create a new immutable map with an extra pair. --Max On Jul 18, 2014, at 16:11, Michael Kay wrote: >> >> Well, Remi had proposed raising the limit. Suppose we offered 7 key-value pairs instead of 5. Would you then complain about having to rewrite your code if you had to add an 8th entry to the map? > > Yes, I would. In fact, the higher you make the limit, the bigger the surprise when I find I cannot extend my code in the natural way by adding one more entry. > > Michael Kay > Saxonica From mike at saxonica.com Fri Jul 18 09:17:49 2014 From: mike at saxonica.com (Michael Kay) Date: Fri, 18 Jul 2014 10:17:49 +0100 Subject: please review draft JEP: Convenience Factory Methods for Collections In-Reply-To: <802A6202-44DF-48A6-A858-69062A7BADD4@oracle.com> References: <53C71CFC.8020903@oracle.com> <364C8776-4E58-4D6E-933D-0C8D156E5667@saxonica.com> <53C841F2.8090009@oracle.com> <802A6202-44DF-48A6-A858-69062A7BADD4@oracle.com> Message-ID: <2EE124AE-6B77-4095-A477-E9F238B1744C@saxonica.com> On 18 Jul 2014, at 10:09, Wang Weijun wrote: > A .with(k, v) to create a new immutable map with an extra pair. > Yes, that's the same as my A.add(k,v) -> A proposal. Works whether A is mutable or immutable. Michael Kay Saxonica From miroslav.kos at oracle.com Fri Jul 18 09:42:01 2014 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Fri, 18 Jul 2014 11:42:01 +0200 Subject: [9] RFR 8038970: Deprivilege JAX-WS/JAF code In-Reply-To: <53C7F392.9070202@oracle.com> References: <53C7E7C2.5000106@oracle.com> <53C7F392.9070202@oracle.com> Message-ID: <53C8EBE9.2050901@oracle.com> Good catch Mandy, thanks! updated webrev: http://cr.openjdk.java.net/~mkos/8038970/jaxws.06/ JBS: https://bugs.openjdk.java.net/browse/JDK-8038970 Added JAF files (overwritten during integration from upstream), removed throws/catch(es) in XMLStreamWriterFactory. Thanks Miran On 17/07/14 18:02, Mandy Chung wrote: > > On 7/17/2014 8:12 AM, Miroslav Kos wrote: >> Hi everybody, >> here is a request for review for >> >> 8038970: Deprivilege JAX-WS/JAF code >> JBS: https://bugs.openjdk.java.net/browse/JDK-8038970 >> webrev: http://cr.openjdk.java.net/~mkos/8038970/jaxws.04/ >> > FYI. The href at the above links were wrong. > > com/sun/xml/internal/ws/api/streaming/XMLStreamWriterFactory.java > line 309: it's fine wrapping with NoSuchMethodError and > you can take out throws NoSuchMethodException from line 292 > > Did you miss JAF classes? > > As a background, this patch is to prepare for granting minimal set > of permissions. > > Mandy > >> This is first part of changes - after this also jdk build will have >> to be changed. >> Changeset has been already discussed during testing phase with Sean >> Mullan and Mandy Chung. >> >> Thanks >> Miran > From vladimir.x.ivanov at oracle.com Fri Jul 18 11:02:04 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 18 Jul 2014 15:02:04 +0400 Subject: [9] RFR (M): 8050877: Improve code for pairwise argument conversions and value boxing/unboxing In-Reply-To: References: <53C6A82A.8060501@oracle.com> Message-ID: <53C8FEAC.2010500@oracle.com> Thanks for review, Paul. > > MethodHandleImpl > > Merge the the 'if' into an 'else if': > 365 } else { > 366 if (dst.isPrimitive()) { Done. > ValueConversions > > I can see why an EnumMap is used for convenience mapping the Wrapper to MH. IIUC it means the MH ref values are not @Stable? I guess it would be easy to unpack into an explicit array and index from the wrapper ordinal, plus then no additional runtime type checks on the key will be performed for get/put. Dunno how important that is. > > Can UNBOX_CONVERSIONS be marked as @Stable? does that make any difference? Same for BOX_CONVERSIONS etc. All 4 caches in ValueConversions can be marked as @Stable. But it's not performance critical, because they are used only during MethodHandle instantiation, which is expected to be expensive. Performance-wise it make sense to reuse MethodHandles. Best regards, Vladimir Ivanov From vladimir.x.ivanov at oracle.com Fri Jul 18 11:03:42 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 18 Jul 2014 15:03:42 +0400 Subject: [9] RFR (M): 8050884: Intrinsify ValueConversions.identity() functions In-Reply-To: References: <53C6ABFE.2040004@oracle.com> Message-ID: <53C8FF0E.8020208@oracle.com> Thanks for review, Paul. > Looks good. > > Same question as in previous email on @Stable for MethodHandles.IDENTITY_MHS. > > FWIW for MethodHandles.IDENTITY_MHS the Wrapper.ordinal() is used as an index rather than using an EnumMap. Yes, caching logic is inconsistent across java.lang.invoke. I'll try to unify it. Best regards, Vladimir Ivanov From georgiy.rakov at oracle.com Fri Jul 18 12:29:41 2014 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Fri, 18 Jul 2014 16:29:41 +0400 Subject: Fwd: JDK 9 RFR of JDK-8030942: Explicitly state floating-point summation requirements on non-finite inputs In-Reply-To: <49851217-96FD-4A7D-BADB-7857815CF506@oracle.com> References: <53C5C77A.5040500@oracle.com> <49851217-96FD-4A7D-BADB-7857815CF506@oracle.com> Message-ID: <53C91335.1070601@oracle.com> Hello Joe, could you please clarify by short example following assertion: 154 * If the exact sum is infinite, a properly-signed infinity is 155 * returned. I'm afraid I don't quite understand what you mean here by 'exact sum'. Thank you, Georgiy. On 16.07.2014 16:37, Paul Sandoz wrote: > > > Begin forwarded message: > >> *From: *Joe Darcy > >> *Subject: **JDK 9 RFR of JDK-8030942: Explicitly state floating-point >> summation requirements on non-finite inputs* >> *Date: *July 16, 2014 2:29:46 AM GMT+02:00 >> *To: *Core-Libs-Dev > > >> >> Hello, >> >> Please review my changes to address: >> >> JDK-8030942: Explicitly state floating-point summation >> requirements on non-finite inputs >> http://cr.openjdk.java.net/~darcy/8030942.0/ >> >> >> Patch below. >> >> Thanks, >> >> -Joe >> >> --- old/src/share/classes/java/util/DoubleSummaryStatistics.java >> 2014-07-15 17:26:41.000000000 -0700 >> +++ new/src/share/classes/java/util/DoubleSummaryStatistics.java >> 2014-07-15 17:26:41.000000000 -0700 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All >> rights reserved. >> + * Copyright (c) 2012, 2014, Oracle and/or its affiliates. All >> rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -129,9 +129,6 @@ >> * Returns the sum of values recorded, or zero if no values have been >> * recorded. >> * >> - * If any recorded value is a NaN or the sum is at any point a NaN >> - * then the sum will be NaN. >> - * >> *

The value of a floating-point sum is a function both of the >> * input values as well as the order of addition operations. The >> * order of addition operations of this method is intentionally >> @@ -143,6 +140,23 @@ >> * numerical sum compared to a simple summation of {@code double} >> * values. >> * >> + *

If any recorded value is a NaN or the intermediate sum is at >> + * any point a NaN, then the final sum will be NaN. >> + * >> + * If the recorded values contain infinities of opposite sign, the >> + * final sum will be NaN. >> + * >> + * It is possible for intermediate sums of finite values to >> + * overflow into opposite-signed infinities; if that occurs, the >> + * final sum will be NaN even if the recorded values are all >> + * finite. >> + * >> + * If the exact sum is infinite, a properly-signed infinity is >> + * returned. >> + * >> + * If all the recorded values are zero, the sign of zero is >> + * not guaranteed to be preserved in the final sum. >> + * >> * @apiNote Values sorted by increasing absolute magnitude tend >> to yield >> * more accurate results. >> * >> @@ -193,9 +207,6 @@ >> * Returns the arithmetic mean of values recorded, or zero if no >> * values have been recorded. >> * >> - * If any recorded value is a NaN or the sum is at any point a NaN >> - * then the average will be code NaN. >> - * >> *

The average returned can vary depending upon the order in >> * which values are recorded. >> * >> @@ -203,6 +214,10 @@ >> * other technique to reduce the error bound in the {@link #getSum >> * numerical sum} used to compute the average. >> * >> + *

This method can return a NaN or infinite result in the same >> + * kind of numerical situations as {@linkplain #getSum() the sum} >> + * can be NaN or infinite, respectively. >> + * >> * @apiNote Values sorted by increasing absolute magnitude tend >> to yield >> * more accurate results. >> * >> --- old/src/share/classes/java/util/stream/DoubleStream.java >> 2014-07-15 17:26:42.000000000 -0700 >> +++ new/src/share/classes/java/util/stream/DoubleStream.java >> 2014-07-15 17:26:42.000000000 -0700 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All >> rights reserved. >> + * Copyright (c) 2012, 2014, Oracle and/or its affiliates. All >> rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -470,10 +470,7 @@ >> * code is not necessarily equivalent to the summation computation >> * done by this method. >> * >> - *

If any stream element is a NaN or the sum is at any point >> a NaN >> - * then the sum will be NaN. >> - * >> - * The value of a floating-point sum is a function both >> + *

The value of a floating-point sum is a function both >> * of the input values as well as the order of addition >> * operations. The order of addition operations of this method is >> * intentionally not defined to allow for implementation >> @@ -485,6 +482,23 @@ >> * numerical sum compared to a simple summation of {@code double} >> * values. >> * >> + *

If any stream element is a NaN or the intermediate sum is at >> + * any point a NaN, then the final sum will be NaN. >> + * >> + * If the stream elements contain infinities of opposite sign, the >> + * final sum will be NaN. >> + * >> + * It is possible for intermediate sums of finite values to >> + * overflow into opposite-signed infinities; if that occurs, the >> + * final sum will be NaN even if the stream elements are all >> + * finite. >> + * >> + * If the exact sum is infinite, a properly-signed infinity is >> + * returned. >> + * >> + * If all the stream elements are zero, the sign of zero is >> + * not guaranteed to be preserved in the final sum. >> + * >> *

This is a terminal >> * operation. >> * >> @@ -555,9 +569,6 @@ >> * mean of elements of this stream, or an empty optional if this >> * stream is empty. >> * >> - * If any recorded value is a NaN or the sum is at any point a NaN >> - * then the average will be NaN. >> - * >> *

The average returned can vary depending upon the order in >> * which values are recorded. >> * >> @@ -565,6 +576,10 @@ >> * other technique to reduce the error bound in the {@link #sum >> * numerical sum} used to compute the average. >> * >> + *

This method can return a NaN or infinite result in the same >> + * kind of numerical situations as {@linkplain #sum() the sum} can >> + * be NaN or infinite, respectively. >> + * >> *

The average is a special case of a > * href="package-summary.html#Reduction">reduction. >> * >> > From pavel.rappo at oracle.com Fri Jul 18 12:37:20 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 18 Jul 2014 13:37:20 +0100 Subject: RFR JDK-8051350: Update javadoc for com.sun.jndi.toolkit.corba.CorbaUtils Message-ID: <774B1718-0CA8-4409-BA98-0C629B8FA185@oracle.com> Hi everyone, Could you please review my change for JDK-8051350? http://cr.openjdk.java.net/~prappo/8051350/webrev.00/ This is just a one-liner javadoc fix. -Pavel From Alan.Bateman at oracle.com Fri Jul 18 12:42:38 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 18 Jul 2014 13:42:38 +0100 Subject: RFR JDK-8051350: Update javadoc for com.sun.jndi.toolkit.corba.CorbaUtils In-Reply-To: <774B1718-0CA8-4409-BA98-0C629B8FA185@oracle.com> References: <774B1718-0CA8-4409-BA98-0C629B8FA185@oracle.com> Message-ID: <53C9163E.7020807@oracle.com> On 18/07/2014 13:37, Pavel Rappo wrote: > Hi everyone, > > Could you please review my change for JDK-8051350? > > http://cr.openjdk.java.net/~prappo/8051350/webrev.00/ > > This is just a one-liner javadoc fix. > Looks okay. Just skimming through this file then there are bunch of odd formatting issues (with comments and strings) that could be fixed too some day. -Alan From Alan.Bateman at oracle.com Fri Jul 18 13:58:44 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 18 Jul 2014 14:58:44 +0100 Subject: RFR: 8051057: (s) Optimize StringCharBuffer.toString(int, int) In-Reply-To: References: Message-ID: <53C92814.3020103@oracle.com> On 17/07/2014 23:05, Mike Duigou wrote: > Hello all; > > While investigating another issue I ran across some code in java.nio.StringCharBuffer.toString(int, int) which might be possible to improve. Currently the implementation calls toString() on the source CharSequence and then uses String.substring to create the desired range. For the current String, StringBuilder and StringBuffer implementations it would be more efficient to first generate the subSequence via CharSequence.subSequence(int, int) and then call toString() on the sub-sequence. For these classes the toString() is actually a NOP as their CharSequence.subSequence(int, int) implementations return a String instance. > > I looked for other CharSequence implementations and couldn't find any which would preform better with current StringCharBuffer.toString(int, int) implementation. > > jbsbug: https://bugs.openjdk.java.net/browse/JDK-8051057 > webrev: http://cr.openjdk.java.net/~mduigou/JDK-8051057/0/webrev/ > > Does this seem like a worthwhile improvement for all of the important CharSequence implementations? > I think this look okay and should be equivalent. Make sure to run the :jdk_nio tests as StringCharBuffer has a history of biting fingers. -Alan. From rob.mckenna at oracle.com Fri Jul 18 14:40:09 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 18 Jul 2014 15:40:09 +0100 Subject: 8050044: (process) Increase reaper thread native stack size by a factor of 2 In-Reply-To: References: <53C56911.7060209@oracle.com> <53C56A18.2080107@oracle.com> Message-ID: <53C931C9.5040000@oracle.com> So doing a bit of homework should probably have been my first approach. Interestingly, we are never actually going to have only 32k allocated for the stack. The VM will allocate the os::Solaris|Linux|etc::min_stack_allowed size which is a minimum of 48k on some platforms but generally 64k+. Windows goes to the trouble of calculating the value based on the guard pages and some other variables. In effect, with the 32k value we're asking the (more specifically, our) VM to allocate the minimum possible stack which is calculated on a per-platform basis. Perhaps the "fix" for this bug should really just be a comment acknowledging that this is a minimum acceptable value and the VM will likely determine the actual size? -Rob On 15/07/14 18:58, Martin Buchholz wrote: > The fear is that stack sizes and alignments have grown over time, and > thread stacks are acquiring things like guard pages, and those pages may > (incorrectly) end up getting included in the stack size. I'm particularly > afraid of the hotspot guard page code. > > It may be worthwhile seeing how low you can make the stack size on popular > platforms before the jtreg tests for process fall over, then multiply by 10 > at least. > > We are approaching the 64-bit only era, when address space restrictions > won't be a problem (for a while) > > > On Tue, Jul 15, 2014 at 10:51 AM, roger riggs > wrote: > >> Hi Rob, >> >> Is there any evidence that needs more space? Is there any way to tell how >> much of >> the existing 32k is being used? >> The reaper has very limited processing to do and there is one thread for >> every process spawned. >> >> Roger >> >> >> >> On 7/15/2014 1:46 PM, Rob McKenna wrote: >> >>> Hi folks, >>> >>> A very simple change suggested by Martin a while back in another review. >>> I'm just getting around to it now: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8050044 >>> webrev: http://cr.openjdk.java.net/~robm/8050044/webrev.01/ >>> >>> Martins comments: http://mail.openjdk.java.net/ >>> pipermail/core-libs-dev/2014-March/025943.html >>> >>> -Rob >>> >>> From xueming.shen at oracle.com Fri Jul 18 15:06:23 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 18 Jul 2014 08:06:23 -0700 Subject: Review request for 8050968: Extension class loader initialization fails on Win7 x64 zh_TW In-Reply-To: <53C8A8ED.4060106@oracle.com> References: <53C8A8ED.4060106@oracle.com> Message-ID: <53C937EF.1030901@oracle.com> On 7/17/14 9:56 PM, Mandy Chung wrote: > This is a regression caused by JDK-8038177 that changed > sun.nio.cs.ext.ExtendedCharsets to use lambda. It turns out that > ExtendedCharsets is loaded during the initialization of the extension > class loader when opening jre/lib/ext/meta-index on windows with system > locale loading extended charsets and caused the initialization error. > > The fix is not to avoid lambda in ExtendedCharsets getting the system > property value. At some point in the future, I'd like to take a closer > look at the system initialization path and what we can do better. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8050968/webrev.00/ > > thanks > Mandy > looks good. From mandy.chung at oracle.com Fri Jul 18 15:13:35 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 18 Jul 2014 08:13:35 -0700 Subject: [9] RFR 8038970: Deprivilege JAX-WS/JAF code In-Reply-To: <53C8EBE9.2050901@oracle.com> References: <53C7E7C2.5000106@oracle.com> <53C7F392.9070202@oracle.com> <53C8EBE9.2050901@oracle.com> Message-ID: <53C9399F.6080403@oracle.com> Looks good. Mandy On 7/18/2014 2:42 AM, Miroslav Kos wrote: > Good catch Mandy, thanks! > > updated webrev: http://cr.openjdk.java.net/~mkos/8038970/jaxws.06/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8038970 > > Added JAF files (overwritten during integration from upstream), > removed throws/catch(es) in XMLStreamWriterFactory. > > Thanks > Miran > > On 17/07/14 18:02, Mandy Chung wrote: >> >> On 7/17/2014 8:12 AM, Miroslav Kos wrote: >>> Hi everybody, >>> here is a request for review for >>> >>> 8038970: Deprivilege JAX-WS/JAF code >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8038970 >>> webrev: http://cr.openjdk.java.net/~mkos/8038970/jaxws.04/ >>> >> FYI. The href at the above links were wrong. >> >> com/sun/xml/internal/ws/api/streaming/XMLStreamWriterFactory.java >> line 309: it's fine wrapping with NoSuchMethodError and >> you can take out throws NoSuchMethodException from line 292 >> >> Did you miss JAF classes? >> >> As a background, this patch is to prepare for granting minimal set >> of permissions. >> >> Mandy >> >>> This is first part of changes - after this also jdk build will have >>> to be changed. >>> Changeset has been already discussed during testing phase with Sean >>> Mullan and Mandy Chung. >>> >>> Thanks >>> Miran >> > From joe.darcy at oracle.com Fri Jul 18 16:14:31 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 18 Jul 2014 09:14:31 -0700 Subject: Fwd: JDK 9 RFR of JDK-8030942: Explicitly state floating-point summation requirements on non-finite inputs In-Reply-To: <53C91335.1070601@oracle.com> References: <53C5C77A.5040500@oracle.com> <49851217-96FD-4A7D-BADB-7857815CF506@oracle.com> <53C91335.1070601@oracle.com> Message-ID: <53C947E7.2020603@oracle.com> Hello Georgiy, On 07/18/2014 05:29 AM, Georgiy Rakov wrote: > Hello Joe, > > could you please clarify by short example following assertion: > > 154 * If the exact sum is infinite, a properly-signed infinity is > 155 * returned. > > I'm afraid I don't quite understand what you mean here by 'exact sum'. By "exact sum," the sum absent any floating-point rounding, the sum you would get using infinite precision to operate on the values in question. The sentence in question is intended to be a short way of saying "If you have same-signed infinities in your input, the result will be an infinity of that sign." In particular, this disallows the behavior that was fixed before JDK 8 GA where having infinities in the input would cause a NaN to be returned because of how the compensated summation code manipulated those values. HTH, -Joe > > Thank you, > Georgiy. > > On 16.07.2014 16:37, Paul Sandoz wrote: >> >> >> Begin forwarded message: >> >>> *From: *Joe Darcy > >>> *Subject: **JDK 9 RFR of JDK-8030942: Explicitly state >>> floating-point summation requirements on non-finite inputs* >>> *Date: *July 16, 2014 2:29:46 AM GMT+02:00 >>> *To: *Core-Libs-Dev >> > >>> >>> Hello, >>> >>> Please review my changes to address: >>> >>> JDK-8030942: Explicitly state floating-point summation >>> requirements on non-finite inputs >>> http://cr.openjdk.java.net/~darcy/8030942.0/ >>> >>> >>> Patch below. >>> >>> Thanks, >>> >>> -Joe >>> >>> --- old/src/share/classes/java/util/DoubleSummaryStatistics.java >>> 2014-07-15 17:26:41.000000000 -0700 >>> +++ new/src/share/classes/java/util/DoubleSummaryStatistics.java >>> 2014-07-15 17:26:41.000000000 -0700 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All >>> rights reserved. >>> + * Copyright (c) 2012, 2014, Oracle and/or its affiliates. All >>> rights reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> * >>> * This code is free software; you can redistribute it and/or modify it >>> @@ -129,9 +129,6 @@ >>> * Returns the sum of values recorded, or zero if no values have >>> been >>> * recorded. >>> * >>> - * If any recorded value is a NaN or the sum is at any point a NaN >>> - * then the sum will be NaN. >>> - * >>> *

The value of a floating-point sum is a function both of the >>> * input values as well as the order of addition operations. The >>> * order of addition operations of this method is intentionally >>> @@ -143,6 +140,23 @@ >>> * numerical sum compared to a simple summation of {@code double} >>> * values. >>> * >>> + *

If any recorded value is a NaN or the intermediate sum is at >>> + * any point a NaN, then the final sum will be NaN. >>> + * >>> + * If the recorded values contain infinities of opposite sign, the >>> + * final sum will be NaN. >>> + * >>> + * It is possible for intermediate sums of finite values to >>> + * overflow into opposite-signed infinities; if that occurs, the >>> + * final sum will be NaN even if the recorded values are all >>> + * finite. >>> + * >>> + * If the exact sum is infinite, a properly-signed infinity is >>> + * returned. >>> + * >>> + * If all the recorded values are zero, the sign of zero is >>> + * not guaranteed to be preserved in the final sum. >>> + * >>> * @apiNote Values sorted by increasing absolute magnitude tend >>> to yield >>> * more accurate results. >>> * >>> @@ -193,9 +207,6 @@ >>> * Returns the arithmetic mean of values recorded, or zero if no >>> * values have been recorded. >>> * >>> - * If any recorded value is a NaN or the sum is at any point a NaN >>> - * then the average will be code NaN. >>> - * >>> *

The average returned can vary depending upon the order in >>> * which values are recorded. >>> * >>> @@ -203,6 +214,10 @@ >>> * other technique to reduce the error bound in the {@link #getSum >>> * numerical sum} used to compute the average. >>> * >>> + *

This method can return a NaN or infinite result in the same >>> + * kind of numerical situations as {@linkplain #getSum() the sum} >>> + * can be NaN or infinite, respectively. >>> + * >>> * @apiNote Values sorted by increasing absolute magnitude tend >>> to yield >>> * more accurate results. >>> * >>> --- old/src/share/classes/java/util/stream/DoubleStream.java >>> 2014-07-15 17:26:42.000000000 -0700 >>> +++ new/src/share/classes/java/util/stream/DoubleStream.java >>> 2014-07-15 17:26:42.000000000 -0700 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All >>> rights reserved. >>> + * Copyright (c) 2012, 2014, Oracle and/or its affiliates. All >>> rights reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> * >>> * This code is free software; you can redistribute it and/or modify it >>> @@ -470,10 +470,7 @@ >>> * code is not necessarily equivalent to the summation computation >>> * done by this method. >>> * >>> - *

If any stream element is a NaN or the sum is at any point >>> a NaN >>> - * then the sum will be NaN. >>> - * >>> - * The value of a floating-point sum is a function both >>> + *

The value of a floating-point sum is a function both >>> * of the input values as well as the order of addition >>> * operations. The order of addition operations of this method is >>> * intentionally not defined to allow for implementation >>> @@ -485,6 +482,23 @@ >>> * numerical sum compared to a simple summation of {@code double} >>> * values. >>> * >>> + *

If any stream element is a NaN or the intermediate sum is at >>> + * any point a NaN, then the final sum will be NaN. >>> + * >>> + * If the stream elements contain infinities of opposite sign, the >>> + * final sum will be NaN. >>> + * >>> + * It is possible for intermediate sums of finite values to >>> + * overflow into opposite-signed infinities; if that occurs, the >>> + * final sum will be NaN even if the stream elements are all >>> + * finite. >>> + * >>> + * If the exact sum is infinite, a properly-signed infinity is >>> + * returned. >>> + * >>> + * If all the stream elements are zero, the sign of zero is >>> + * not guaranteed to be preserved in the final sum. >>> + * >>> *

This is a terminal >>> * operation. >>> * >>> @@ -555,9 +569,6 @@ >>> * mean of elements of this stream, or an empty optional if this >>> * stream is empty. >>> * >>> - * If any recorded value is a NaN or the sum is at any point a NaN >>> - * then the average will be NaN. >>> - * >>> *

The average returned can vary depending upon the order in >>> * which values are recorded. >>> * >>> @@ -565,6 +576,10 @@ >>> * other technique to reduce the error bound in the {@link #sum >>> * numerical sum} used to compute the average. >>> * >>> + *

This method can return a NaN or infinite result in the same >>> + * kind of numerical situations as {@linkplain #sum() the sum} can >>> + * be NaN or infinite, respectively. >>> + * >>> *

The average is a special case of a >> * href="package-summary.html#Reduction">reduction. >>> * >>> >> > From neil.toda at oracle.com Fri Jul 18 16:53:54 2014 From: neil.toda at oracle.com (Neil Toda) Date: Fri, 18 Jul 2014 09:53:54 -0700 Subject: RFR : JDK-8046545 launcher fix to check function return values Message-ID: <53C95122.7090205@oracle.com> Please review this launcher change. Issue: https://bugs.openjdk.java.net/browse/JDK-8046545 webrev: http://cr.openjdk.java.net/~ntoda/8046545/webrev-01/ Summary: Introduce a set of macros for launcher to be used to check for certain conditions after return from select functions. From chris.hegarty at oracle.com Fri Jul 18 17:23:09 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 18 Jul 2014 18:23:09 +0100 Subject: =?windows-1252?Q?Fwd=3A_RFR_=5B9=5D=3A_Consistent_order_of__=27A?= =?windows-1252?Q?nnotation_Type_Hierarchy=27_=26_=27Enum_Hierarc?= =?windows-1252?Q?hy=92_sections=2E?= References: Message-ID: <3B0F2CB6-D3EF-4C40-BA64-072B08E10496@oracle.com> > This is a small code review request for an issue I encountered when trying to compare the result of the output of a docs build from two JDK repos. I?ll file a bug on it soon. > > The issue is that the 'Annotation Type Hierarchy' & 'Enum Hierarchy? sections of ?Use' and ?Tree? view for a package are not always in the same order ( the issue may appear in other views too, but these are the only ones I observed). The implementation uses a List, whose elements may be added in a different order, depending on encounter order. These elements should be ordered, as others are. It just appears to be an oversight in the original implementation. > > diff --git a/src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java b/src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java > --- a/src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java > +++ b/src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java > @@ -155,12 +155,21 @@ > } > > Collections.sort(baseinterfaces); > + Collections.sort(baseAnnotationTypes); > + Collections.sort(baseEnums); > for (List docs : subinterfaces.values()) { > Collections.sort(docs); > } > for (List docs : subclasses.values()) { > Collections.sort(docs); > } > + for (List docs : subAnnotationTypes.values()) { > + Collections.sort(docs); > + } > + for (List docs : subEnums.values()) { > + Collections.sort(docs); > + } > + > } > > -Chris. > From kumar.x.srinivasan at oracle.com Fri Jul 18 17:35:39 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 18 Jul 2014 10:35:39 -0700 Subject: RFR : JDK-8046545 launcher fix to check function return values In-Reply-To: <53C95122.7090205@oracle.com> References: <53C95122.7090205@oracle.com> Message-ID: <53C95AEB.7080505@oracle.com> Neil, The fix looks good. However there is an inaccuracy in the comment: + * Normally, JNI calls do not return if an exception is thrown. + * However, this behavior can change in the future, + * so check for thrown exceptions. This is not true, JNI calls *will* return if an exception is thrown, however best JNI practices dictate that a pending Exception(s) must be cleared or caught, before attempting another JNI call. Under such circumstances the return value will usually be an error or a null value. I suggest making this change to reflect this. Thanks Kumar On 7/18/2014 9:53 AM, Neil Toda wrote: > > Please review this launcher change. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8046545 > webrev: http://cr.openjdk.java.net/~ntoda/8046545/webrev-01/ > > Summary: > > Introduce a set of macros for launcher to be used to check for certain > conditions after > return from select functions. > > From neil.toda at oracle.com Fri Jul 18 17:40:10 2014 From: neil.toda at oracle.com (Neil Toda) Date: Fri, 18 Jul 2014 10:40:10 -0700 Subject: RFR : JDK-8046545 launcher fix to check function return values In-Reply-To: <53C95AEB.7080505@oracle.com> References: <53C95122.7090205@oracle.com> <53C95AEB.7080505@oracle.com> Message-ID: <53C95BFA.4030600@oracle.com> Thanks Kumar. Yes, misspoke here. Will correct the comment. On 7/18/2014 10:35 AM, Kumar Srinivasan wrote: > Neil, > The fix looks good. However there is an inaccuracy in the comment: > > + * Normally, JNI calls do not return if an exception is thrown. > + * However, this behavior can change in the future, > + * so check for thrown exceptions. > > This is not true, JNI calls *will* return if an exception is thrown, > however best > JNI practices dictate that a pending Exception(s) must be cleared or > caught, before > attempting another JNI call. Under such circumstances the return value > will usually > be an error or a null value. I suggest making this change to reflect > this. > > Thanks > Kumar > > > > On 7/18/2014 9:53 AM, Neil Toda wrote: >> >> Please review this launcher change. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8046545 >> webrev: http://cr.openjdk.java.net/~ntoda/8046545/webrev-01/ >> >> Summary: >> >> Introduce a set of macros for launcher to be used to check for >> certain conditions after >> return from select functions. >> >> > From martinrb at google.com Fri Jul 18 17:43:26 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 18 Jul 2014 10:43:26 -0700 Subject: 8050044: (process) Increase reaper thread native stack size by a factor of 2 In-Reply-To: <53C931C9.5040000@oracle.com> References: <53C56911.7060209@oracle.com> <53C56A18.2080107@oracle.com> <53C931C9.5040000@oracle.com> Message-ID: Alright, we can abandon this change. In practice, tests on different platforms will usually catch SOE before users encounter it, because the stacks are all almost identical. Unless there is e.g. a hotspot bug that causes thread local variables to be allocated inside the stack size instead of outside. Is there monitoring available that can warn when e.g. stack high-water mark is ever more than 50%? On Fri, Jul 18, 2014 at 7:40 AM, Rob McKenna wrote: > So doing a bit of homework should probably have been my first approach. > > Interestingly, we are never actually going to have only 32k allocated for > the stack. The VM will allocate the os::Solaris|Linux|etc::min_stack_allowed > size which is a minimum of 48k on some platforms but generally 64k+. > Windows goes to the trouble of calculating the value based on the guard > pages and some other variables. > > In effect, with the 32k value we're asking the (more specifically, our) VM > to allocate the minimum possible stack which is calculated on a > per-platform basis. Perhaps the "fix" for this bug should really just be a > comment acknowledging that this is a minimum acceptable value and the VM > will likely determine the actual size? > > -Rob > > > On 15/07/14 18:58, Martin Buchholz wrote: > >> The fear is that stack sizes and alignments have grown over time, and >> thread stacks are acquiring things like guard pages, and those pages may >> (incorrectly) end up getting included in the stack size. I'm particularly >> afraid of the hotspot guard page code. >> >> It may be worthwhile seeing how low you can make the stack size on popular >> platforms before the jtreg tests for process fall over, then multiply by >> 10 >> at least. >> >> We are approaching the 64-bit only era, when address space restrictions >> won't be a problem (for a while) >> >> >> On Tue, Jul 15, 2014 at 10:51 AM, roger riggs >> wrote: >> >> Hi Rob, >>> >>> Is there any evidence that needs more space? Is there any way to tell >>> how >>> much of >>> the existing 32k is being used? >>> The reaper has very limited processing to do and there is one thread for >>> every process spawned. >>> >>> Roger >>> >>> >>> >>> On 7/15/2014 1:46 PM, Rob McKenna wrote: >>> >>> Hi folks, >>>> >>>> A very simple change suggested by Martin a while back in another review. >>>> I'm just getting around to it now: >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8050044 >>>> webrev: http://cr.openjdk.java.net/~robm/8050044/webrev.01/ >>>> >>>> Martins comments: http://mail.openjdk.java.net/ >>>> pipermail/core-libs-dev/2014-March/025943.html >>>> >>>> -Rob >>>> >>>> >>>> > From georgiy.rakov at oracle.com Fri Jul 18 19:00:50 2014 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Fri, 18 Jul 2014 23:00:50 +0400 Subject: Fwd: JDK 9 RFR of JDK-8030942: Explicitly state floating-point summation requirements on non-finite inputs In-Reply-To: <53C947E7.2020603@oracle.com> References: <53C5C77A.5040500@oracle.com> <49851217-96FD-4A7D-BADB-7857815CF506@oracle.com> <53C91335.1070601@oracle.com> <53C947E7.2020603@oracle.com> Message-ID: <53C96EE2.6000107@oracle.com> On 18.07.2014 20:14, Joe Darcy wrote: > Hello Georgiy, > > On 07/18/2014 05:29 AM, Georgiy Rakov wrote: >> Hello Joe, >> >> could you please clarify by short example following assertion: >> >> 154 * If the exact sum is infinite, a properly-signed infinity is >> 155 * returned. >> >> I'm afraid I don't quite understand what you mean here by 'exact sum'. > > By "exact sum," the sum absent any floating-point rounding, the sum > you would get using infinite precision to operate on the values in > question. > > The sentence in question is intended to be a short way of saying "If > you have same-signed infinities in your input, the result will be an > infinity of that sign." In particular, this disallows the behavior > that was fixed before JDK 8 GA where having infinities in the input > would cause a NaN to be returned because of how the compensated > summation code manipulated those values. > Thanks, I see, however it seems to me a bit confusing, since the term "infinite exact sum" seems to me not obvious and I believe it needs some definition. I'd like to suggest to use more straightforward approach, that is as you've said: "If you have same-signed infinities in your input, the result will be an infinity of that sign.". I believe it would be more clear for end user (at least for me :)) and from conformance point of view. Besides it seems to me a bit questionable. For instance "inexact some" looks like more appropriate, since overflowing to infinity occurs when _actual _sum exceeds the limit. By actual sum I mean sum resulted from actual summation with all the rounding happened. There wouldn't be such questions, provided straightforward approach is used. Thanks, Georgiy. > HTH, > > -Joe > >> >> Thank you, >> Georgiy. >> >> On 16.07.2014 16:37, Paul Sandoz wrote: >>> >>> >>> Begin forwarded message: >>> >>>> *From: *Joe Darcy > >>>> *Subject: **JDK 9 RFR of JDK-8030942: Explicitly state >>>> floating-point summation requirements on non-finite inputs* >>>> *Date: *July 16, 2014 2:29:46 AM GMT+02:00 >>>> *To: *Core-Libs-Dev >>> > >>>> >>>> Hello, >>>> >>>> Please review my changes to address: >>>> >>>> JDK-8030942: Explicitly state floating-point summation >>>> requirements on non-finite inputs >>>> http://cr.openjdk.java.net/~darcy/8030942.0/ >>>> >>>> >>>> Patch below. >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> --- old/src/share/classes/java/util/DoubleSummaryStatistics.java >>>> 2014-07-15 17:26:41.000000000 -0700 >>>> +++ new/src/share/classes/java/util/DoubleSummaryStatistics.java >>>> 2014-07-15 17:26:41.000000000 -0700 >>>> @@ -1,5 +1,5 @@ >>>> /* >>>> - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All >>>> rights reserved. >>>> + * Copyright (c) 2012, 2014, Oracle and/or its affiliates. All >>>> rights reserved. >>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>> * >>>> * This code is free software; you can redistribute it and/or modify it >>>> @@ -129,9 +129,6 @@ >>>> * Returns the sum of values recorded, or zero if no values >>>> have been >>>> * recorded. >>>> * >>>> - * If any recorded value is a NaN or the sum is at any point a NaN >>>> - * then the sum will be NaN. >>>> - * >>>> *

The value of a floating-point sum is a function both of the >>>> * input values as well as the order of addition operations. The >>>> * order of addition operations of this method is intentionally >>>> @@ -143,6 +140,23 @@ >>>> * numerical sum compared to a simple summation of {@code double} >>>> * values. >>>> * >>>> + *

If any recorded value is a NaN or the intermediate sum is at >>>> + * any point a NaN, then the final sum will be NaN. >>>> + * >>>> + * If the recorded values contain infinities of opposite sign, the >>>> + * final sum will be NaN. >>>> + * >>>> + * It is possible for intermediate sums of finite values to >>>> + * overflow into opposite-signed infinities; if that occurs, the >>>> + * final sum will be NaN even if the recorded values are all >>>> + * finite. >>>> + * >>>> + * If the exact sum is infinite, a properly-signed infinity is >>>> + * returned. >>>> + * >>>> + * If all the recorded values are zero, the sign of zero is >>>> + * not guaranteed to be preserved in the final sum. >>>> + * >>>> * @apiNote Values sorted by increasing absolute magnitude tend >>>> to yield >>>> * more accurate results. >>>> * >>>> @@ -193,9 +207,6 @@ >>>> * Returns the arithmetic mean of values recorded, or zero if no >>>> * values have been recorded. >>>> * >>>> - * If any recorded value is a NaN or the sum is at any point a NaN >>>> - * then the average will be code NaN. >>>> - * >>>> *

The average returned can vary depending upon the order in >>>> * which values are recorded. >>>> * >>>> @@ -203,6 +214,10 @@ >>>> * other technique to reduce the error bound in the {@link #getSum >>>> * numerical sum} used to compute the average. >>>> * >>>> + *

This method can return a NaN or infinite result in the same >>>> + * kind of numerical situations as {@linkplain #getSum() the sum} >>>> + * can be NaN or infinite, respectively. >>>> + * >>>> * @apiNote Values sorted by increasing absolute magnitude tend >>>> to yield >>>> * more accurate results. >>>> * >>>> --- old/src/share/classes/java/util/stream/DoubleStream.java >>>> 2014-07-15 17:26:42.000000000 -0700 >>>> +++ new/src/share/classes/java/util/stream/DoubleStream.java >>>> 2014-07-15 17:26:42.000000000 -0700 >>>> @@ -1,5 +1,5 @@ >>>> /* >>>> - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All >>>> rights reserved. >>>> + * Copyright (c) 2012, 2014, Oracle and/or its affiliates. All >>>> rights reserved. >>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>> * >>>> * This code is free software; you can redistribute it and/or modify it >>>> @@ -470,10 +470,7 @@ >>>> * code is not necessarily equivalent to the summation computation >>>> * done by this method. >>>> * >>>> - *

If any stream element is a NaN or the sum is at any >>>> point a NaN >>>> - * then the sum will be NaN. >>>> - * >>>> - * The value of a floating-point sum is a function both >>>> + *

The value of a floating-point sum is a function both >>>> * of the input values as well as the order of addition >>>> * operations. The order of addition operations of this method is >>>> * intentionally not defined to allow for implementation >>>> @@ -485,6 +482,23 @@ >>>> * numerical sum compared to a simple summation of {@code double} >>>> * values. >>>> * >>>> + *

If any stream element is a NaN or the intermediate sum is at >>>> + * any point a NaN, then the final sum will be NaN. >>>> + * >>>> + * If the stream elements contain infinities of opposite sign, the >>>> + * final sum will be NaN. >>>> + * >>>> + * It is possible for intermediate sums of finite values to >>>> + * overflow into opposite-signed infinities; if that occurs, the >>>> + * final sum will be NaN even if the stream elements are all >>>> + * finite. >>>> + * >>>> + * If the exact sum is infinite, a properly-signed infinity is >>>> + * returned. >>>> + * >>>> + * If all the stream elements are zero, the sign of zero is >>>> + * not guaranteed to be preserved in the final sum. >>>> + * >>>> *

This is a terminal >>>> * operation. >>>> * >>>> @@ -555,9 +569,6 @@ >>>> * mean of elements of this stream, or an empty optional if this >>>> * stream is empty. >>>> * >>>> - * If any recorded value is a NaN or the sum is at any point a NaN >>>> - * then the average will be NaN. >>>> - * >>>> *

The average returned can vary depending upon the order in >>>> * which values are recorded. >>>> * >>>> @@ -565,6 +576,10 @@ >>>> * other technique to reduce the error bound in the {@link #sum >>>> * numerical sum} used to compute the average. >>>> * >>>> + *

This method can return a NaN or infinite result in the same >>>> + * kind of numerical situations as {@linkplain #sum() the sum} can >>>> + * be NaN or infinite, respectively. >>>> + * >>>> *

The average is a special case of a >>> * href="package-summary.html#Reduction">reduction. >>>> * >>>> >>> >> > From martinrb at google.com Fri Jul 18 19:35:01 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 18 Jul 2014 12:35:01 -0700 Subject: [concurrency-interest] ThreadLocalRandom clinit troubles In-Reply-To: References: <53A29DC5.1030605@oracle.com> <53A3FA72.3060706@gmail.com> <53A418F2.3080201@gmail.com> <53A43055.5070803@oracle.com> <53A43EF3.8000206@gmail.com> <53A44C3A.6000607@oracle.com> <53A98525.9080908@gmail.com> <53A9EF29.7030208@gmail.com> <53AB09E5.9070303@gmail.com> <53C3F4D0.5090407@oracle.com> Message-ID: I support Peter at al's plan to add an API that ThreadLocalRandom et al can use to get some system entropy without unbounded class dependency loading. It should not surprise anyone that at Google, we are most interested in running on Linux, so while we're waiting for a proper fix to happen we are locally applying a simpler patch that tries explicitly /dev/urandom, falling back to SecureRandom if necessary: http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ThreadLocalRandom-system-entropy/ On Mon, Jul 14, 2014 at 1:54 PM, Bernd wrote: > SecureRandom is unfortunatelly pretty complex. It is interpreting the > seed url in some way (the configuration you mentioned behave very special > since Java 6) , it is mixing seed and continues data and it reorders the > implementations used. > > JEP 123 intended to clear things, but getInstanceStrong() (which nobody > uses?!) did not improve things IMHO. > > Bernd > > PS: I think the webrev changed since then, but the mail from Brad > describes the problem well: > http://mail.openjdk.java.net/pipermail/security-dev/2013-January/006288.html > Am 14.07.2014 21:05 schrieb "Oleksandr Otenko" < > oleksandr.otenko at oracle.com>: > > Can someone summarize what happened? >> >> SecureRandom used to get entropy from /dev/random, which is configurable >> through a policy file to /dev/urandom. Has this changed? >> >> Alex >> >> On 12/07/2014 00:33, Martin Buchholz wrote: >> >> Thanks to Peter for digging into the secure seed generator classes and >> coming up with a patch. Openjdk security folks, please review. I confess >> to getting lost whenever I try to orient myself in the twisty maze of seed >> generator implementation files. >> >> Anyways, it seems important to have prngs like ThreadLocalRandom be >> able to get a few bits of seed entropy without loading hundreds of classes >> and without occupying any file descriptors permanently. Perhaps at Google >> we will go back to writing some simple non-portable startup code to read >> /dev/urandom until openjdk security team comes up with a more principled >> solution (but one that doesn't drag in too much machinery). >> >> >> _______________________________________________ >> Concurrency-interest mailing listConcurrency-interest at cs.oswego.eduhttp://cs.oswego.edu/mailman/listinfo/concurrency-interest >> >> >> From forax at univ-mlv.fr Fri Jul 18 20:15:17 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 18 Jul 2014 22:15:17 +0200 Subject: [9] RFR (M): 8050052: Small cleanups in java.lang.invoke code In-Reply-To: References: <53C00E62.20703@oracle.com> <53C02534.2040000@univ-mlv.fr> <96C06C20-2479-47A2-94F9-49C987AE58A9@oracle.com> <53C696CA.3040908@gmail.com> <53C6C278.4060505@gmail.com> <92054EE4-89C5-4772-8324-4165D0A64710@oracle.com> Message-ID: <53C98055.4020102@univ-mlv.fr> On 07/18/2014 03:54 AM, John Rose wrote: > FTR, I captured this issue: > > https://bugs.openjdk.java.net/browse/JDK-8051294 > > (Wish they were all so easy to catch.) > > ? John Hi John, I like the way the proposed API is composable but i fear that people will still forget to first call throwIfUnchecked() most of the time. I think we should not implement a throwSuppressedIf because a suppressed exception is not a primary one thus it's a more an information when debugging than an exception a code should act upon. I'm not sure that looking recursively for a cause ( :) ) is a good idea, changing the behavior of a program because an exception buried under 10 others doesn't seem appealing to me. Also there is a bug hidden in your implementation of throwCauseIf, you return the value of cause.throwCauseIf instead of this. cheers, R?mi > > On Jul 17, 2014, at 5:12 PM, John Rose wrote: > >> On Jul 16, 2014, at 11:20 AM, Peter Levart wrote: >> >>> An alternative could be: >>> >>> public Throwable throwIfUnchecked() { >>> if (this instanceof RuntimeException) throw (RuntimeException) this; >>> if (this instanceof Error) throw (Error) this; >>> return this; >>> } >>> >>> Then use it like: >>> >>> try { >>> ... >>> } catch (Throwable t) { >>> throw new WrapperException(t.throwIfUnchecked()); >>> } >> I like this one. (I wish we could declare This types, so that TYPEOF[t.throwIfUnchecked()] == TYPEOF[t].) >> >> It puts the throw of the "less dangerous" exception type inside the subroutine, making the wrapping and the "more dangerous" (more ad hoc) exception be explicit and in-line. >> >> To complete the picture, add: >> >> public Throwable throwIf(Class exClass) throws X { >> if (exClass.isInstance(this)) throw exClass.cast(this); >> return this; >> } >> >> ...to be used as: >> >> try { >> ... >> } catch (Throwable t) { >> t.throwIfUnchecked().throwIf(X.class).throwIf(Y.class).throwIf(Z.class); >> throw new WrapperException(t); >> } >> >> Or some other combination of sequential and/or fluent calls. >> >> ? John From claes.redestad at oracle.com Fri Jul 18 21:14:40 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 18 Jul 2014 23:14:40 +0200 Subject: RFR (S): 8050114: Expose Integer/Long formatUnsigned methods internally In-Reply-To: <53C1B632.5080404@oracle.com> References: <53C1B632.5080404@oracle.com> Message-ID: <53C98E40.7050107@oracle.com> Hi, Mike Duigou suggested some simplifications to the formatUnsigned methods. Shows a slight speed-upon some micros as well: http://cr.openjdk.java.net/~redestad/8050114/webrev.2/ /Claes On 2014-07-13 00:26, Claes Redestad wrote: > Hi, > > please review this patch to expose formatUnsignedInt/-Long through > JavaLangAccess. > > webrev: http://cr.openjdk.java.net/~redestad/8050114/webrev.1/ > bug: https://bugs.openjdk.java.net/browse/JDK-8050114 > > The behavior of the methods have been adjusted to be zero-padding in > case the number formatted is shorter than the specified length, since > that simplifies use cases for which this utility is exposed > internally, e.g., JDK-8006627 > . Microbenchmarks > show that this does not adversely affect performance of current uses > through toHexString, toOctalString etc. > > Thanks! > > /Claes From mike.duigou at oracle.com Fri Jul 18 21:39:28 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 18 Jul 2014 14:39:28 -0700 Subject: RFR (S): 8050114: Expose Integer/Long formatUnsigned methods internally In-Reply-To: <53C98E40.7050107@oracle.com> References: <53C1B632.5080404@oracle.com> <53C98E40.7050107@oracle.com> Message-ID: <4E76DDDB-0D56-4398-90E7-AD732135ACEA@oracle.com> Looks good. I will complete some additional testing and push this changeset for you. On Jul 18 2014, at 14:14 , Claes Redestad wrote: > Hi, > > Mike Duigou suggested some simplifications to the formatUnsigned methods. Shows a slight speed-upon some micros as well: > > http://cr.openjdk.java.net/~redestad/8050114/webrev.2/ > > /Claes > > On 2014-07-13 00:26, Claes Redestad wrote: >> Hi, >> >> please review this patch to expose formatUnsignedInt/-Long through JavaLangAccess. >> >> webrev: http://cr.openjdk.java.net/~redestad/8050114/webrev.1/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8050114 >> >> The behavior of the methods have been adjusted to be zero-padding in case the number formatted is shorter than the specified length, since that simplifies use cases for which this utility is exposed internally, e.g., JDK-8006627 . Microbenchmarks show that this does not adversely affect performance of current uses through toHexString, toOctalString etc. All of the existing users of this method pre-size their char buffer and use a zero offset so there are no changes in behaviour. (In case anyone was wondering) Mike From john.r.rose at oracle.com Fri Jul 18 21:53:53 2014 From: john.r.rose at oracle.com (John Rose) Date: Fri, 18 Jul 2014 14:53:53 -0700 Subject: [9] RFR (M): 8050052: Small cleanups in java.lang.invoke code In-Reply-To: <53C98055.4020102@univ-mlv.fr> References: <53C00E62.20703@oracle.com> <53C02534.2040000@univ-mlv.fr> <96C06C20-2479-47A2-94F9-49C987AE58A9@oracle.com> <53C696CA.3040908@gmail.com> <53C6C278.4060505@gmail.com> <92054EE4-89C5-4772-8324-4165D0A64710@oracle.com> <53C98055.4020102@univ-mlv.fr> Message-ID: On Jul 18, 2014, at 1:15 PM, Remi Forax wrote: > I like the way the proposed API is composable but i fear that people will still forget to first call throwIfUnchecked() most of the time. > > I think we should not implement a throwSuppressedIf because a suppressed exception is not a primary one thus it's a more an information when debugging than an exception a code should act upon. > > I'm not sure that looking recursively for a cause ( :) ) is a good idea, changing the behavior of a program because an exception buried under 10 others doesn't seem appealing to me. > Also there is a bug hidden in your implementation of throwCauseIf, you return the value of cause.throwCauseIf instead of this. I agree with all these points; I updated the bug. From ivan.gerasimov at oracle.com Fri Jul 18 22:20:58 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sat, 19 Jul 2014 02:20:58 +0400 Subject: RFR (S): 8050114: Expose Integer/Long formatUnsigned methods internally In-Reply-To: <53C98E40.7050107@oracle.com> References: <53C1B632.5080404@oracle.com> <53C98E40.7050107@oracle.com> Message-ID: <53C99DCA.8080404@oracle.com> Hi Claes! Wouldn't it be better to use do-while here: 339 while (charPos > offset) { 340 buf[--charPos] = Integer.digits[val & mask]; 341 val >>>= shift; 342 } given the precondition // assert len > 0 && (offset + len) <= buf.length : "illegal length"; (charPos > offset) condition should always hold for the first time. This would save one comparison. Sincerely yours, Ivan On 19.07.2014 1:14, Claes Redestad wrote: > Hi, > > Mike Duigou suggested some simplifications to the formatUnsigned > methods. Shows a slight speed-upon some micros as well: > > http://cr.openjdk.java.net/~redestad/8050114/webrev.2/ > > /Claes > > On 2014-07-13 00:26, Claes Redestad wrote: >> Hi, >> >> please review this patch to expose formatUnsignedInt/-Long through >> JavaLangAccess. >> >> webrev: http://cr.openjdk.java.net/~redestad/8050114/webrev.1/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8050114 >> >> The behavior of the methods have been adjusted to be zero-padding in >> case the number formatted is shorter than the specified length, since >> that simplifies use cases for which this utility is exposed >> internally, e.g., JDK-8006627 >> . Microbenchmarks >> show that this does not adversely affect performance of current uses >> through toHexString, toOctalString etc. >> >> Thanks! >> >> /Claes > > > From ivan.gerasimov at oracle.com Fri Jul 18 22:39:16 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sat, 19 Jul 2014 02:39:16 +0400 Subject: RFR [8051382] Optimize java.lang.reflect.Modifier.toString() Message-ID: <53C9A214.1060101@oracle.com> Hello! StringBuilder can be replaced with StringJoiner, which will make the code shorter and, probably, more efficient. The existing regtest (java/lang/reflect/Modifier/toStringTest.java) can be used to make sure nothing is broken. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8051382 WEBREV: http://cr.openjdk.java.net/~igerasim/8051382/0/webrev/ Sincerely yours, Ivan From martinrb at google.com Fri Jul 18 22:53:08 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 18 Jul 2014 15:53:08 -0700 Subject: RFR [8051382] Optimize java.lang.reflect.Modifier.toString() In-Reply-To: <53C9A214.1060101@oracle.com> References: <53C9A214.1060101@oracle.com> Message-ID: It looks like the test has a new import, but no actual new code that uses it. On Fri, Jul 18, 2014 at 3:39 PM, Ivan Gerasimov wrote: > Hello! > > StringBuilder can be replaced with StringJoiner, which will make the code > shorter and, probably, more efficient. > The existing regtest (java/lang/reflect/Modifier/toStringTest.java) can > be used to make sure nothing is broken. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8051382 > WEBREV: http://cr.openjdk.java.net/~igerasim/8051382/0/webrev/ > > Sincerely yours, > Ivan > From ivan.gerasimov at oracle.com Fri Jul 18 22:57:04 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sat, 19 Jul 2014 02:57:04 +0400 Subject: RFR [8051382] Optimize java.lang.reflect.Modifier.toString() In-Reply-To: References: <53C9A214.1060101@oracle.com> Message-ID: <53C9A640.8030808@oracle.com> In the test I only replaced import java.lang.reflect.*; with import java.lang.reflect.Modifier; and added the new bugid to the @bug tag. Sincerely yours, Ivan On 19.07.2014 2:53, Martin Buchholz wrote: > It looks like the test has a new import, but no actual new code that > uses it. > > > On Fri, Jul 18, 2014 at 3:39 PM, Ivan Gerasimov > > wrote: > > Hello! > > StringBuilder can be replaced with StringJoiner, which will make > the code shorter and, probably, more efficient. > The existing regtest > (java/lang/reflect/Modifier/toStringTest.java) can be used to make > sure nothing is broken. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8051382 > WEBREV: http://cr.openjdk.java.net/~igerasim/8051382/0/webrev/ > > > Sincerely yours, > Ivan > > From mike.duigou at oracle.com Fri Jul 18 22:59:39 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 18 Jul 2014 15:59:39 -0700 Subject: RFR (S): 8050114: Expose Integer/Long formatUnsigned methods internally In-Reply-To: <53C99DCA.8080404@oracle.com> References: <53C1B632.5080404@oracle.com> <53C98E40.7050107@oracle.com> <53C99DCA.8080404@oracle.com> Message-ID: <8D2D6C52-5412-472F-A388-9449C6099182@oracle.com> You are correct. I will switch to a do-while. Mike On Jul 18 2014, at 15:20 , Ivan Gerasimov wrote: > Hi Claes! > > Wouldn't it be better to use do-while here: > 339 while (charPos > offset) { > 340 buf[--charPos] = Integer.digits[val & mask]; > 341 val >>>= shift; > 342 } > given the precondition > // assert len > 0 && (offset + len) <= buf.length : "illegal length"; > (charPos > offset) condition should always hold for the first time. > > This would save one comparison. > > Sincerely yours, > Ivan > > On 19.07.2014 1:14, Claes Redestad wrote: >> Hi, >> >> Mike Duigou suggested some simplifications to the formatUnsigned methods. Shows a slight speed-upon some micros as well: >> >> http://cr.openjdk.java.net/~redestad/8050114/webrev.2/ >> >> /Claes >> >> On 2014-07-13 00:26, Claes Redestad wrote: >>> Hi, >>> >>> please review this patch to expose formatUnsignedInt/-Long through JavaLangAccess. >>> >>> webrev: http://cr.openjdk.java.net/~redestad/8050114/webrev.1/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8050114 >>> >>> The behavior of the methods have been adjusted to be zero-padding in case the number formatted is shorter than the specified length, since that simplifies use cases for which this utility is exposed internally, e.g., JDK-8006627 . Microbenchmarks show that this does not adversely affect performance of current uses through toHexString, toOctalString etc. >>> >>> Thanks! >>> >>> /Claes >> >> >> > From martinrb at google.com Fri Jul 18 23:07:35 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 18 Jul 2014 16:07:35 -0700 Subject: RFR [8051382] Optimize java.lang.reflect.Modifier.toString() In-Reply-To: <53C9A640.8030808@oracle.com> References: <53C9A214.1060101@oracle.com> <53C9A640.8030808@oracle.com> Message-ID: Oh sorry, I missed that you had tightened the imports. I took a quick look at StringJoiner. It looks to me like this won't be an optimization, because StringJoiner uses StringBuilder internally, and will actually perform more total operations. It looks to me like StringJoiner itself could be optimized by storing the strings in an array and generating the final String perfectly at the end when all the inputs are known, using the private String constructor that takes a char[]. On Fri, Jul 18, 2014 at 3:57 PM, Ivan Gerasimov wrote: > In the test I only replaced > > import java.lang.reflect.*; > > with > > import java.lang.reflect.Modifier; > > and added the new bugid to the @bug tag. > > Sincerely yours, > Ivan > > > On 19.07.2014 2:53, Martin Buchholz wrote: > > It looks like the test has a new import, but no actual new code that uses > it. > > > On Fri, Jul 18, 2014 at 3:39 PM, Ivan Gerasimov > wrote: > >> Hello! >> >> StringBuilder can be replaced with StringJoiner, which will make the code >> shorter and, probably, more efficient. >> The existing regtest (java/lang/reflect/Modifier/toStringTest.java) can >> be used to make sure nothing is broken. >> >> Would you please help review the fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8051382 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8051382/0/webrev/ >> >> Sincerely yours, >> Ivan >> > > > From stuart.marks at oracle.com Fri Jul 18 23:36:35 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 18 Jul 2014 16:36:35 -0700 Subject: please review draft JEP: Convenience Factory Methods for Collections In-Reply-To: <2EE124AE-6B77-4095-A477-E9F238B1744C@saxonica.com> References: <53C71CFC.8020903@oracle.com> <364C8776-4E58-4D6E-933D-0C8D156E5667@saxonica.com> <53C841F2.8090009@oracle.com> <802A6202-44DF-48A6-A858-69062A7BADD4@oracle.com> <2EE124AE-6B77-4095-A477-E9F238B1744C@saxonica.com> Message-ID: <53C9AF83.9070404@oracle.com> On 7/18/14 2:17 AM, Michael Kay wrote: > On 18 Jul 2014, at 10:09, Wang Weijun wrote: >> A .with(k, v) to create a new immutable map with an extra pair. > > Yes, that's the same as my A.add(k,v) -> A proposal. > > Works whether A is mutable or immutable. I don't think we want to have a Map.add(k,v) instance method (or default method) for immutable maps or for constructing them. For a fast, compact, immutable map implementation, the only way to implement Map.add() would be to copy the entire contents plus the additional pair into a new map. For creating maps with small numbers of entries, this isn't really a big deal, but if you have something like Map.of() .add(k0, v0) .add(k1, v1) ... .add(kN, vN); this would result in O(N^2) performance and space allocation, though most of the allocated space is garbage. Of course, one could avoid the copying overhead by making the immutable maps persistent (i.e., sharing their unmodified portions) but that is an entirely different discussion. I kind of think you're after the ability to chain the method calls. This is certainly convenient and has no arbitrary restrictions on the number of elements. To do something like this we'd put the chainable methods on a builder instead: Map.builder() .add(k0, v0) .add(k1, v1) ... .add(kN, vN) .build(); This is somewhat more cluttered than the Map.of(Entry...) approach: Map.of( entry(k0, v0), entry(k1, v1), ... entry(kN, vN)); but it might make up for it with flexibility. I hesitate a bit to pursue the builder approach, because it can easily get bogged down with additional features, but the special considerations for Map might require it. s'marks From david.lloyd at redhat.com Fri Jul 18 23:41:14 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 18 Jul 2014 18:41:14 -0500 Subject: please review draft JEP: Convenience Factory Methods for Collections In-Reply-To: <53C9AF83.9070404@oracle.com> References: <53C71CFC.8020903@oracle.com> <364C8776-4E58-4D6E-933D-0C8D156E5667@saxonica.com> <53C841F2.8090009@oracle.com> <802A6202-44DF-48A6-A858-69062A7BADD4@oracle.com> <2EE124AE-6B77-4095-A477-E9F238B1744C@saxonica.com> <53C9AF83.9070404@oracle.com> Message-ID: <53C9B09A.1040709@redhat.com> On 07/18/2014 06:36 PM, Stuart Marks wrote: > On 7/18/14 2:17 AM, Michael Kay wrote: >> On 18 Jul 2014, at 10:09, Wang Weijun wrote: >>> A .with(k, v) to create a new immutable map with an extra pair. >> >> Yes, that's the same as my A.add(k,v) -> A proposal. >> >> Works whether A is mutable or immutable. > > I don't think we want to have a Map.add(k,v) instance method (or default > method) for immutable maps or for constructing them. > > For a fast, compact, immutable map implementation, the only way to > implement Map.add() would be to copy the entire contents plus the > additional pair into a new map. For creating maps with small numbers of > entries, this isn't really a big deal, but if you have something like > > Map.of() > .add(k0, v0) > .add(k1, v1) > ... > .add(kN, vN); > > this would result in O(N^2) performance and space allocation, though > most of the allocated space is garbage. Adding another alternative, instead of producing intermediate maps which are copied at each step for the sake of maintaining O(1) lookup, this approach could instead create a linked-list-of-pairs which would be O(n) for lookups, but also O(n) for space - you could then efficiently feed that to a "real" map constructor, especially if each "map" also implemented Map.Entry, which would make an iterator particularly lightweight, making the overall cost for, say, a HashMap be O(n). Not sure it's the "right" approach, just throwing it out there as a random Friday thought. -- - DML From ivan.gerasimov at oracle.com Sat Jul 19 01:18:16 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sat, 19 Jul 2014 05:18:16 +0400 Subject: RFR [8051382] Optimize java.lang.reflect.Modifier.toString() In-Reply-To: References: <53C9A214.1060101@oracle.com> <53C9A640.8030808@oracle.com> Message-ID: <53C9C758.5070203@oracle.com> On 19.07.2014 3:07, Martin Buchholz wrote: > > I took a quick look at StringJoiner. It looks to me like this won't > be an optimization, because StringJoiner uses StringBuilder > internally, and will actually perform more total operations. Unfortunately this is true. Microbenchmarking shows that StringJoiner makes the things 30% slower, which is sad. Then I propose another simple patch giving +15% to the speed: http://cr.openjdk.java.net/~igerasim/8051382/1/webrev/ Sincerely yours, Inan From claes.redestad at oracle.com Sat Jul 19 04:59:19 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 19 Jul 2014 06:59:19 +0200 Subject: RFR [9] 8006627: UUID to/from String performance should be improved by reducing object allocations In-Reply-To: <539CCF9C.9090001@oracle.com> References: <539CCF9C.9090001@oracle.com> Message-ID: <53C9FB27.2050300@oracle.com> Hi, after recent changes, this patch has been revisited and improved slightly, primarily simplifying and speeding up the toString method slightly more: http://cr.openjdk.java.net/~redestad/8006627/webrev.1/ /Claes On 2014-06-15 00:41, Claes Redestad wrote: > Hi, > > please review this patch to improve UUID performance, originally > proposed by Steven Schlansker, rebased to use the allocation-free > methods added in https://bugs.openjdk.java.net/browse/JDK-8041972 > > Webrev: http://cr.openjdk.java.net/~redestad/8006627/webrev.0/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8006627 > > Thanks! > > /Claes From mike at saxonica.com Sat Jul 19 08:27:31 2014 From: mike at saxonica.com (Michael Kay) Date: Sat, 19 Jul 2014 09:27:31 +0100 Subject: please review draft JEP: Convenience Factory Methods for Collections In-Reply-To: <53C9AF83.9070404@oracle.com> References: <53C71CFC.8020903@oracle.com> <364C8776-4E58-4D6E-933D-0C8D156E5667@saxonica.com> <53C841F2.8090009@oracle.com> <802A6202-44DF-48A6-A858-69062A7BADD4@oracle.com> <2EE124AE-6B77-4095-A477-E9F238B1744C@saxonica.com> <53C9AF83.9070404@oracle.com> Message-ID: > > I don't think we want to have a Map.add(k,v) instance method (or default method) for immutable maps or for constructing them. > > For a fast, compact, immutable map implementation, the only way to implement Map.add() would be to copy the entire contents plus the additional pair into a new map. > > this would result in O(N^2) performance and space allocation, though most of the allocated space is garbage. Only with a very naive implementation of immutable maps! With a HashTrie, or RedBlack tree, of Finger tree, adding a new entry can be O(log(N)) in both time and space. > > Of course, one could avoid the copying overhead by making the immutable maps persistent (i.e., sharing their unmodified portions) but that is an entirely different discussion. Well, I think immutable maps are a different discussion anyway, but surely any worthwhile implementation of immutable maps should make it easy and fast to create a new immutable map by adding an entry? > > I kind of think you're after the ability to chain the method calls. Yes. > This is certainly convenient and has no arbitrary restrictions on the number of elements. To do something like this we'd put the chainable methods on a builder instead: > > Map.builder() > .add(k0, v0) > .add(k1, v1) > ... > .add(kN, vN) > .build(); Seems an unnecessary complication to me... For a mutable map it's just: add(k,v) {put(k,v); return this}. For an immutable map using something like a HashTrie, creating a small map using say 5 add() operations is not going to take significantly longer than the builder approach; you can always provide the builder as well for those who want ultimate performance. > Michael Kay Saxonica From forax at univ-mlv.fr Sat Jul 19 09:04:27 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 19 Jul 2014 11:04:27 +0200 Subject: please review draft JEP: Convenience Factory Methods for Collections In-Reply-To: <53C9AF83.9070404@oracle.com> References: <53C71CFC.8020903@oracle.com> <364C8776-4E58-4D6E-933D-0C8D156E5667@saxonica.com> <53C841F2.8090009@oracle.com> <802A6202-44DF-48A6-A858-69062A7BADD4@oracle.com> <2EE124AE-6B77-4095-A477-E9F238B1744C@saxonica.com> <53C9AF83.9070404@oracle.com> Message-ID: <53CA349B.1080301@univ-mlv.fr> On 07/19/2014 01:36 AM, Stuart Marks wrote: > On 7/18/14 2:17 AM, Michael Kay wrote: >> On 18 Jul 2014, at 10:09, Wang Weijun wrote: >>> A .with(k, v) to create a new immutable map with an extra pair. >> >> Yes, that's the same as my A.add(k,v) -> A proposal. >> >> Works whether A is mutable or immutable. > > I don't think we want to have a Map.add(k,v) instance method (or > default method) for immutable maps or for constructing them. > > For a fast, compact, immutable map implementation, the only way to > implement Map.add() would be to copy the entire contents plus the > additional pair into a new map. For creating maps with small numbers > of entries, this isn't really a big deal, but if you have something like > > Map.of() > .add(k0, v0) > .add(k1, v1) > ... > .add(kN, vN); > > this would result in O(N^2) performance and space allocation, though > most of the allocated space is garbage. > > Of course, one could avoid the copying overhead by making the > immutable maps persistent (i.e., sharing their unmodified portions) > but that is an entirely different discussion. > > I kind of think you're after the ability to chain the method calls. > This is certainly convenient and has no arbitrary restrictions on the > number of elements. To do something like this we'd put the chainable > methods on a builder instead: > > Map.builder() > .add(k0, v0) > .add(k1, v1) > ... > .add(kN, vN) > .build(); > > This is somewhat more cluttered than the Map.of(Entry...) approach: > > Map.of( > entry(k0, v0), > entry(k1, v1), > ... > entry(kN, vN)); > > but it might make up for it with flexibility. I hesitate a bit to > pursue the builder approach, because it can easily get bogged down > with additional features, but the special considerations for Map might > require it. > > s'marks You can combine these 2 approachesi using a Ruby like builder approach with a lambda, which provide a builder object (so static method call are replaced by instance method call) avoiding the creation of too many entry objects Map.of(b -> b .entry(k0, v0) .entry(k1, v1) ... .entry(kN, vN)) cheers, R?mi From ivan.gerasimov at oracle.com Sat Jul 19 12:59:21 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sat, 19 Jul 2014 16:59:21 +0400 Subject: RFR [9] 8006627: UUID to/from String performance should be improved by reducing object allocations In-Reply-To: <53C9FB27.2050300@oracle.com> References: <539CCF9C.9090001@oracle.com> <53C9FB27.2050300@oracle.com> Message-ID: <53CA6BA9.9070006@oracle.com> This looks just beautiful! But why do you need the digits() function at all? In my opinion, using formatUnsignedLong directly would be no less clearer. Sincerely yours, Ivan On 19.07.2014 8:59, Claes Redestad wrote: > Hi, > > after recent changes, this patch has been revisited and improved > slightly, primarily simplifying and speeding up the toString method > slightly more: > > http://cr.openjdk.java.net/~redestad/8006627/webrev.1/ > > /Claes > > On 2014-06-15 00:41, Claes Redestad wrote: >> Hi, >> >> please review this patch to improve UUID performance, originally >> proposed by Steven Schlansker, rebased to use the allocation-free >> methods added in https://bugs.openjdk.java.net/browse/JDK-8041972 >> >> Webrev: http://cr.openjdk.java.net/~redestad/8006627/webrev.0/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8006627 >> >> Thanks! >> >> /Claes > > > From kumar.x.srinivasan at oracle.com Sat Jul 19 15:02:49 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Sat, 19 Jul 2014 08:02:49 -0700 Subject: RFR : JDK-8046545 launcher fix to check function return values In-Reply-To: <53C95BFA.4030600@oracle.com> References: <53C95122.7090205@oracle.com> <53C95AEB.7080505@oracle.com> <53C95BFA.4030600@oracle.com> Message-ID: <53CA8899.5000607@oracle.com> [ Since I am sponsoring this patch, I think jcheck needs one more Reviewer besides myself] Neil, looking at your webrev: http://cr.openjdk.java.net/~ntoda/8046545/webrev-02/ Can we not re-use the existing macro for null check ? #define NULL_CHECK_RETURN_VALUE(NCRV_check_pointer, NCRV_return_value) so thus your new macro would become.... +#define CHECK_JNI_RETURN(JNIRETURN, RETURNVALUE) \ + CHECK_JNI_RETURN_EXCEPTION(RETURNVALUE); \ - do { \ - if ((JNIRETURN) == NULL) { \ - JLI_ReportErrorMessage(JNI_ERROR); \ - RETURNVALUE; \ - } \ - } while (JNI_FALSE) + NULL_CHECK_RETURN_VALUE(JNI_RETURN, RETURN_VALUE); Kumar On 7/18/2014 10:40 AM, Neil Toda wrote: > > Thanks Kumar. Yes, misspoke here. Will correct the comment. > > On 7/18/2014 10:35 AM, Kumar Srinivasan wrote: >> Neil, >> The fix looks good. However there is an inaccuracy in the comment: >> >> + * Normally, JNI calls do not return if an exception is thrown. >> + * However, this behavior can change in the future, >> + * so check for thrown exceptions. >> >> This is not true, JNI calls *will* return if an exception is thrown, >> however best >> JNI practices dictate that a pending Exception(s) must be cleared or >> caught, before >> attempting another JNI call. Under such circumstances the return >> value will usually >> be an error or a null value. I suggest making this change to reflect >> this. >> >> Thanks >> Kumar >> >> >> >> On 7/18/2014 9:53 AM, Neil Toda wrote: >>> >>> Please review this launcher change. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8046545 >>> webrev: http://cr.openjdk.java.net/~ntoda/8046545/webrev-01/ >>> >>> Summary: >>> >>> Introduce a set of macros for launcher to be used to check for >>> certain conditions after >>> return from select functions. >>> >>> >> > From martinrb at google.com Sat Jul 19 15:58:07 2014 From: martinrb at google.com (Martin Buchholz) Date: Sat, 19 Jul 2014 08:58:07 -0700 Subject: RFR [8051382] Optimize java.lang.reflect.Modifier.toString() In-Reply-To: <53C9C758.5070203@oracle.com> References: <53C9A214.1060101@oracle.com> <53C9A640.8030808@oracle.com> <53C9C758.5070203@oracle.com> Message-ID: StringJoiner seems written in a style suitable for an application, not in a low-level performance-oriented style suitable for a JDK core library. But we can fix that. http://cr.openjdk.java.net/~martin/webrevs/openjdk9/StringJoiner-optimization/ On Fri, Jul 18, 2014 at 6:18 PM, Ivan Gerasimov wrote: > > On 19.07.2014 3:07, Martin Buchholz wrote: > >> >> I took a quick look at StringJoiner. It looks to me like this won't be >> an optimization, because StringJoiner uses StringBuilder internally, and >> will actually perform more total operations. >> > > Unfortunately this is true. > Microbenchmarking shows that StringJoiner makes the things 30% slower, > which is sad. > > Then I propose another simple patch giving +15% to the speed: > > http://cr.openjdk.java.net/~igerasim/8051382/1/webrev/ > > Sincerely yours, > Inan > > From forax at univ-mlv.fr Sat Jul 19 16:47:52 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 19 Jul 2014 18:47:52 +0200 Subject: RFR [8051382] Optimize java.lang.reflect.Modifier.toString() In-Reply-To: References: <53C9A214.1060101@oracle.com> <53C9A640.8030808@oracle.com> <53C9C758.5070203@oracle.com> Message-ID: <53CAA138.604@univ-mlv.fr> On 07/19/2014 05:58 PM, Martin Buchholz wrote: > StringJoiner seems written in a style suitable for an application, not in a > low-level performance-oriented style suitable for a JDK core library. But > we can fix that. > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/StringJoiner-optimization/ Hi Martin, it's not obvious for me that your implementation is more efficient, if you have a lot of strings, because you store reference to them, you will have references everywhere on heap so toString() will not be very cache friendly. The current implementation that use a StringBuilder will consume more memory but is more cache friendly. otherwise, your implementation of merge is weird (or half weird), unlike add, for merge you combine all strings into a unique big string instead of merging the two arrays, is there a reason for that ? regards, R?mi > > > On Fri, Jul 18, 2014 at 6:18 PM, Ivan Gerasimov > wrote: > >> On 19.07.2014 3:07, Martin Buchholz wrote: >> >>> I took a quick look at StringJoiner. It looks to me like this won't be >>> an optimization, because StringJoiner uses StringBuilder internally, and >>> will actually perform more total operations. >>> >> Unfortunately this is true. >> Microbenchmarking shows that StringJoiner makes the things 30% slower, >> which is sad. >> >> Then I propose another simple patch giving +15% to the speed: >> >> http://cr.openjdk.java.net/~igerasim/8051382/1/webrev/ >> >> Sincerely yours, >> Inan >> >> From martinrb at google.com Sun Jul 20 05:00:57 2014 From: martinrb at google.com (Martin Buchholz) Date: Sat, 19 Jul 2014 22:00:57 -0700 Subject: RFR [8051382] Optimize java.lang.reflect.Modifier.toString() In-Reply-To: <53CAA138.604@univ-mlv.fr> References: <53C9A214.1060101@oracle.com> <53C9A640.8030808@oracle.com> <53C9C758.5070203@oracle.com> <53CAA138.604@univ-mlv.fr> Message-ID: On Sat, Jul 19, 2014 at 9:47 AM, Remi Forax wrote: > > On 07/19/2014 05:58 PM, Martin Buchholz wrote: > >> StringJoiner seems written in a style suitable for an application, not in >> a >> low-level performance-oriented style suitable for a JDK core library. But >> we can fix that. >> >> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ >> StringJoiner-optimization/ >> > > Hi Martin, > it's not obvious for me that your implementation is more efficient, > if you have a lot of strings, because you store reference to them, you > will have references > everywhere on heap so toString() will not be very cache friendly. > The current implementation that use a StringBuilder will consume more > memory but > is more cache friendly. > > In my implementation, the string chars will not even be examined at add() time, and then copied only once at toString() time. In the original, the string chars will be copied twice. True that in my implementation the String objects themselves are examined twice. I guess that most of the time they will still be in cache. > otherwise, your implementation of merge is weird (or half weird), unlike > add, > for merge you combine all strings into a unique big string instead of > merging > the two arrays, is there a reason for that ? > > *

If the other {@code StringJoiner} is using a different delimiter, * then elements from the other {@code StringJoiner} are concatenated with * that delimiter and the result is appended to this {@code StringJoiner} * as a single element. we could have different code paths, depending on whether the delimiters were equal. From peter.firmstone at zeus.net.au Sun Jul 20 10:57:20 2014 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sun, 20 Jul 2014 20:57:20 +1000 Subject: State of Serialization Message-ID: <53CBA090.4070303@zeus.net.au> David, I've gone over the list archives and read your earlier post about serializable constructors and agree with your post. The class SerialFields below, represents the serial form of a Serializable object, the stream protocol would remain unchanged. SerialFields would be the equivalent of an existing Serializable object that declares private static final ObjectStreamField[] serialPersistentFields and uses PutField in it's writeObject method and GetField in its readObject method. Regards, Peter. *State of Java Serialization* Introduction The Java Serialization framework enables object state to be frozen, stored to disk or transferred over a network and unfrozen again into objects. While Java's Serialization capabilities are arguably more sophisticated than most at reconstructing complex object relationships, the ?magic? nothing to do, marker interface, Serializable is problematic. Due to the complexity of serialising state from an object with Serializable superclasses in inheritance hierarchies, private methods were chosen, allowing objects to write and read objects to and from streams. Each class in an Object's inheritance heirarchy that implements or inherits Serializable must be able to write out and read in serialized state, private methods cannot be overridden or called by subclasses, nor is their implementation enforced by the Java language syntax, hence Serializable is a marker interface only. Background Serialization was introduced in Java 1.1. The marker interface Serializable is problematic since implementation of its methods are optional. Developers can make objects serializable by simply declaring implements Serializable and providing a default zero argument constructor. Since private methods are only be called by the ObjectOutputStream / ObjectInputStream, during de-serialisation, subclass are not responsible for calling these methods, hence subclass ProtectionDomain's are not present in the Thread's AccessControlContext and as such are missing from security checks, this is why it's currently essential for classes to ensure that de-serialisation isn't performed in a privileged context. To improve security, it would be preferable to use a deserialization constructor, required to be called by subclasses in the class hierarchies, placing their ProtectionDomains in the stack context, avoiding a number of security issues. Another benefit is the ability to use final fields, while checking invariants during construction. import java.io.Serializable; /** * Object's that implement this interface must provide a public constructor * with the signature: * * (SerialFields fields) throws IOException ClassNotFoundException; * * This constructor, must avoid finalizer attacks by checking invariants * using static methods to retrieve fields, throwing any Exception before * calling another constructor. * * Classes that extend other classes that implement Serializable2, must call * a static method that checks invariants and throw any Exceptions prior to * calling a super class constructor. * * @author peter */ public interface Serializable2 extends Serializable { /** * Allows an object to write its fields, the order each field * is written is important if compatibility with existing Serializable * object implementations is necessary. * * Classes with superclass's that implement Serializable2, must * first call the overridden superclass method, before writing their own * fields. * * @param fields */ void writeObject(SerialFields fields); } import java.io.IOException; import java.util.ArrayList; import java.util.HashMap; import java.util.List; import java.util.Map; /** * To be used by ObjectInput, ObjectOutput frameworks. * * Represents all fields in order as stored in an inheritance hierarchy for * one Object. * * This class is not thread safe. * * @author peter */ public final class SerialFields { public static SerialFields create() throws SecurityException { // Perform security check. return new SerialFields(); } private final Map fields; private final List order; /** * Should only be instantiated by frameworks. */ private SerialFields(){ // TODO Security check in a static method that throws an exception. fields = new HashMap(); order = new ArrayList(); } /** * Fields may be added in order of their serial form, this will be used * by the Serializable 2 Framework to retain compatibility with older * Serializable implementations. * * @param caller * @param name * @param obj * @throws NullPointerException if caller or name is null. */ public void putField(Class caller, String name, Object obj){ // TODO Check if caller is the caller, perform security check if not. if (caller == null) throw new NullPointerException("caller cannot be null"); if (name == null) throw new NullPointerException("name cannot be null"); FieldKey key = new FieldKey(caller, name); // TODO allowable Exception? fields.put(key, obj); //obj can be null or an exception. order.add(key); } /** * * @param caller * @param name * @return * @throws IOException * @throws ClassNotFoundException */ public Object getField(Class caller, String name) throws IOException, ClassNotFoundException { // TODO Check if caller is the caller, perform security check if not. if (caller == null) throw new NullPointerException("caller cannot be null"); if (name == null) throw new NullPointerException("name cannot be null"); Object field = fields.get(new FieldKey(caller, name)); if (field instanceof IOException) throw (IOException) field; if (field instanceof ClassNotFoundException) throw (ClassNotFoundException) field; if (field instanceof RuntimeException) throw (RuntimeException) field; if (field instanceof Error) throw (Error) field; return field; } private static class FieldKey { private final Class caller; private final String fieldName; private final int hash; FieldKey(Class caller, String fieldName){ this.caller = caller; this.fieldName = fieldName; int hash = 3; hash = 79 * hash + (this.caller != null ? this.caller.hashCode() : 0); hash = 79 * hash + (this.fieldName != null ? this.fieldName.hashCode() : 0); this.hash = hash; } @Override public int hashCode() { return hash; } @Override public boolean equals(Object o){ if (!(o instanceof FieldKey)) return false; FieldKey that = (FieldKey) o; if (!caller.equals(that.caller)) return false; return fieldName.equals(that.fieldName); } } } From paul.sandoz at oracle.com Sun Jul 20 20:01:48 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Sun, 20 Jul 2014 13:01:48 -0700 Subject: Fwd: Map.compute() confusing Javadoc References: <935901405613954@web13m.yandex.ru> Message-ID: <78CA59DA-6BE4-4467-A491-4A938F522CFB@oracle.com> Begin forwarded message: > -------- ???????????? ?????????-------- > 17.07.2014, 19:20, "Roman Leventov" : > > Map.compute() Javadoc has the following paragraph: > -------- > The default implementation is equivalent to performing the following steps for this map, then returning the current value or null if absent: > > V oldValue = map.get(key); > V newValue = remappingFunction.apply(key, oldValue); > if (oldValue != null ) { > if (newValue != null) > map.put(key, newValue); > else > map.remove(key); > } else { > if (newValue != null) > map.put(key, newValue); > else > return null; > } > -------- > > But this code don't correspond neither verbal description of the behaviour nor the actual default implementation in java.util.Map. If the oldValue is null and newValue is null, map should still remove the key, not to just `return null;` > From paul.sandoz at oracle.com Sun Jul 20 20:02:32 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Sun, 20 Jul 2014 13:02:32 -0700 Subject: [9] RFR (M): 8050877: Improve code for pairwise argument conversions and value boxing/unboxing In-Reply-To: <53C8FEAC.2010500@oracle.com> References: <53C6A82A.8060501@oracle.com> <53C8FEAC.2010500@oracle.com> Message-ID: <9432C9BE-9A2C-4A41-A3B2-C81C4ED00F31@oracle.com> On Jul 18, 2014, at 4:02 AM, Vladimir Ivanov wrote: >> ValueConversions >> >> I can see why an EnumMap is used for convenience mapping the Wrapper to MH. IIUC it means the MH ref values are not @Stable? I guess it would be easy to unpack into an explicit array and index from the wrapper ordinal, plus then no additional runtime type checks on the key will be performed for get/put. Dunno how important that is. >> >> Can UNBOX_CONVERSIONS be marked as @Stable? does that make any difference? Same for BOX_CONVERSIONS etc. > All 4 caches in ValueConversions can be marked as @Stable. But it's not performance critical, because they are used only during MethodHandle instantiation, which is expected to be expensive. Performance-wise it make sense to reuse MethodHandles. > Ok. Paul. From david.holmes at oracle.com Sun Jul 20 22:25:53 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Jul 2014 08:25:53 +1000 Subject: Fwd: Map.compute() confusing Javadoc In-Reply-To: <78CA59DA-6BE4-4467-A491-4A938F522CFB@oracle.com> References: <935901405613954@web13m.yandex.ru> <78CA59DA-6BE4-4467-A491-4A938F522CFB@oracle.com> Message-ID: <53CC41F1.6070402@oracle.com> See: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018251.html and related bug report. David On 21/07/2014 6:01 AM, Paul Sandoz wrote: > Begin forwarded message: >> -------- ???????????? ?????????-------- >> 17.07.2014, 19:20, "Roman Leventov" : >> >> Map.compute() Javadoc has the following paragraph: >> -------- >> The default implementation is equivalent to performing the following steps for this map, then returning the current value or null if absent: >> >> V oldValue = map.get(key); >> V newValue = remappingFunction.apply(key, oldValue); >> if (oldValue != null ) { >> if (newValue != null) >> map.put(key, newValue); >> else >> map.remove(key); >> } else { >> if (newValue != null) >> map.put(key, newValue); >> else >> return null; >> } >> -------- >> >> But this code don't correspond neither verbal description of the behaviour nor the actual default implementation in java.util.Map. If the oldValue is null and newValue is null, map should still remove the key, not to just `return null;` >> > From claes.redestad at oracle.com Mon Jul 21 11:41:47 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 21 Jul 2014 13:41:47 +0200 Subject: RFR [9] 8006627: UUID to/from String performance should be improved by reducing object allocations In-Reply-To: <53CA6BA9.9070006@oracle.com> References: <539CCF9C.9090001@oracle.com> <53C9FB27.2050300@oracle.com> <53CA6BA9.9070006@oracle.com> Message-ID: <53CCFC7B.7040600@oracle.com> On 07/19/2014 02:59 PM, Ivan Gerasimov wrote: > This looks just beautiful! Thanks! > But why do you need the digits() function at all? > In my opinion, using formatUnsignedLong directly would be no less > clearer. Sure! http://cr.openjdk.java.net/~redestad/8006627/webrev.2/ Small improvement with client compiler; no measurable change with tiered. /Claes > > Sincerely yours, > Ivan > > On 19.07.2014 8:59, Claes Redestad wrote: >> Hi, >> >> after recent changes, this patch has been revisited and improved >> slightly, primarily simplifying and speeding up the toString method >> slightly more: >> >> http://cr.openjdk.java.net/~redestad/8006627/webrev.1/ >> >> /Claes >> >> On 2014-06-15 00:41, Claes Redestad wrote: >>> Hi, >>> >>> please review this patch to improve UUID performance, originally >>> proposed by Steven Schlansker, rebased to use the allocation-free >>> methods added in https://bugs.openjdk.java.net/browse/JDK-8041972 >>> >>> Webrev: http://cr.openjdk.java.net/~redestad/8006627/webrev.0/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8006627 >>> >>> Thanks! >>> >>> /Claes >> >> >> > From tom.hawtin at oracle.com Mon Jul 21 15:10:19 2014 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Mon, 21 Jul 2014 16:10:19 +0100 Subject: State of Serialization In-Reply-To: <53CBA090.4070303@zeus.net.au> References: <53CBA090.4070303@zeus.net.au> Message-ID: <53CD2D5B.9020006@oracle.com> On 20/07/2014 11:57, Peter Firmstone wrote: > Since private methods are only be called by the ObjectOutputStream / > ObjectInputStream, during de-serialisation, subclass are not responsible > for calling these methods, hence subclass ProtectionDomain's are not > present in the Thread's AccessControlContext and as such are missing > from security checks, this is why it's currently essential for classes > to ensure that de-serialisation isn't performed in a privileged context. It's more complicated than that. Even final serialisable classes may have security checks. > To improve security, it would be preferable to use a deserialization > constructor, required to be called by subclasses in the class > hierarchies, placing their ProtectionDomains in the stack context, > avoiding a number of security issues. Another benefit is the ability to > use final fields, while checking invariants during construction. Certainly it would be better have a mechanism that better fitted in with non-serialisation mechanisms. Addressing this without unraveling too much when pulling on a thread, and without increasing complexity of corner cases, is non-trivial. Tom From neil.toda at oracle.com Mon Jul 21 16:31:31 2014 From: neil.toda at oracle.com (Neil Toda) Date: Mon, 21 Jul 2014 09:31:31 -0700 Subject: RFR : JDK-8046545 launcher fix to check function return values In-Reply-To: <53CA8899.5000607@oracle.com> References: <53C95122.7090205@oracle.com> <53C95AEB.7080505@oracle.com> <53C95BFA.4030600@oracle.com> <53CA8899.5000607@oracle.com> Message-ID: <53CD4063.4060104@oracle.com> Hi Kumar Actually, the null check macros have different parameters. NCRV_return_value is an integer. RETURNVALUE in CHECK_JNI_RETURN is a macro, which allows us to have only the two macros: CHECK_JNI_RETURN and CHECK_JNI_RETRUN_EXCEPTION I also think it is cleaner since there are only two, and they are for JNI, to keep them self contained. Would someone be willing to review webrev-02, which contain Kumar's suggested change in the comments included with the macros. Thanks -neil On 7/19/2014 8:02 AM, Kumar Srinivasan wrote: > [ Since I am sponsoring this patch, I think jcheck needs one more > Reviewer besides myself] > > Neil, > > looking at your webrev: > http://cr.openjdk.java.net/~ntoda/8046545/webrev-02/ > > Can we not re-use the existing macro for null check ? > > #define NULL_CHECK_RETURN_VALUE(NCRV_check_pointer, NCRV_return_value) > > so thus your new macro would become.... > > +#define CHECK_JNI_RETURN(JNIRETURN, RETURNVALUE) \ > + CHECK_JNI_RETURN_EXCEPTION(RETURNVALUE); \ > - do { \ > - if ((JNIRETURN) == NULL) { \ > - JLI_ReportErrorMessage(JNI_ERROR); \ > - RETURNVALUE; \ > - } \ > - } while (JNI_FALSE) > + NULL_CHECK_RETURN_VALUE(JNI_RETURN, RETURN_VALUE); > > > Kumar > > On 7/18/2014 10:40 AM, Neil Toda wrote: >> >> Thanks Kumar. Yes, misspoke here. Will correct the comment. >> >> On 7/18/2014 10:35 AM, Kumar Srinivasan wrote: >>> Neil, >>> The fix looks good. However there is an inaccuracy in the comment: >>> >>> + * Normally, JNI calls do not return if an exception is thrown. >>> + * However, this behavior can change in the future, >>> + * so check for thrown exceptions. >>> >>> This is not true, JNI calls *will* return if an exception is thrown, >>> however best >>> JNI practices dictate that a pending Exception(s) must be cleared or >>> caught, before >>> attempting another JNI call. Under such circumstances the return >>> value will usually >>> be an error or a null value. I suggest making this change to reflect >>> this. >>> >>> Thanks >>> Kumar >>> >>> >>> >>> On 7/18/2014 9:53 AM, Neil Toda wrote: >>>> >>>> Please review this launcher change. >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8046545 >>>> webrev: http://cr.openjdk.java.net/~ntoda/8046545/webrev-01/ >>>> >>>> Summary: >>>> >>>> Introduce a set of macros for launcher to be used to check for >>>> certain conditions after >>>> return from select functions. >>>> >>>> >>> >> > From peter.levart at gmail.com Mon Jul 21 16:51:27 2014 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 21 Jul 2014 18:51:27 +0200 Subject: RFR [9] 8006627: UUID to/from String performance should be improved by reducing object allocations In-Reply-To: <53CCFC7B.7040600@oracle.com> References: <539CCF9C.9090001@oracle.com> <53C9FB27.2050300@oracle.com> <53CA6BA9.9070006@oracle.com> <53CCFC7B.7040600@oracle.com> Message-ID: <53CD450F.4060702@gmail.com> Hi Claes, Invalid inputs to UUID.fromString() behave a little different than before. IllegalArgumentException is not thrown for the following inputs: For example: "0": IllegalArgumentException: Invalid UUID string: 0 (before patch) "0": IndexOutOfBoundsException (after patch) "-0": IllegalArgumentException: Invalid UUID string: -0 (before patch) "-0": NumberFormatException (after patch) "0-0-0-0-": IllegalArgumentException: Invalid UUID string: 0-0-0-0- (before patch) "0-0-0-0-": NumberFormatException (after patch) The following input (and similar) do throw NumberFormatException as before, but messages are a little different. That's OK, I suppose. "0-0-0-x-0": NumberFormatException: For input string: "x" (before patch) "0-0-0-x-0": NumberFormatException: Error at index 1 in: "x" (after patch) "0-0-0--0": NumberFormatException: For input string: "" (before patch) "0-0-0--0": NumberFormatException: (after patch) The 1st 3 examples could be fixed by checking that dash1,2,3,4 are all > 0 and that dash4 + 1 < name.length() Regards, Peter On 07/21/2014 01:41 PM, Claes Redestad wrote: > On 07/19/2014 02:59 PM, Ivan Gerasimov wrote: >> This looks just beautiful! > > Thanks! > >> But why do you need the digits() function at all? >> In my opinion, using formatUnsignedLong directly would be no less >> clearer. > > Sure! > > http://cr.openjdk.java.net/~redestad/8006627/webrev.2/ > > Small improvement with client compiler; no measurable change with tiered. > > /Claes > >> >> Sincerely yours, >> Ivan >> >> On 19.07.2014 8:59, Claes Redestad wrote: >>> Hi, >>> >>> after recent changes, this patch has been revisited and improved >>> slightly, primarily simplifying and speeding up the toString method >>> slightly more: >>> >>> http://cr.openjdk.java.net/~redestad/8006627/webrev.1/ >>> >>> /Claes >>> >>> On 2014-06-15 00:41, Claes Redestad wrote: >>>> Hi, >>>> >>>> please review this patch to improve UUID performance, originally >>>> proposed by Steven Schlansker, rebased to use the allocation-free >>>> methods added in https://bugs.openjdk.java.net/browse/JDK-8041972 >>>> >>>> Webrev: http://cr.openjdk.java.net/~redestad/8006627/webrev.0/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8006627 >>>> >>>> Thanks! >>>> >>>> /Claes >>> >>> >>> >> > From xueming.shen at oracle.com Mon Jul 21 17:27:24 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 21 Jul 2014 10:27:24 -0700 Subject: RFR [9] 8006627: UUID to/from String performance should be improved by reducing object allocations In-Reply-To: <53CCFC7B.7040600@oracle.com> References: <539CCF9C.9090001@oracle.com> <53C9FB27.2050300@oracle.com> <53CA6BA9.9070006@oracle.com> <53CCFC7B.7040600@oracle.com> Message-ID: <53CD4D7C.4010405@oracle.com> It appears input like "----" now triggers different exception, the spec says it should throw IAE. -Sherman On 07/21/2014 04:41 AM, Claes Redestad wrote: > On 07/19/2014 02:59 PM, Ivan Gerasimov wrote: >> This looks just beautiful! > > Thanks! > >> But why do you need the digits() function at all? >> In my opinion, using formatUnsignedLong directly would be no less clearer. > > Sure! > > http://cr.openjdk.java.net/~redestad/8006627/webrev.2/ > > Small improvement with client compiler; no measurable change with tiered. > > /Claes > >> >> Sincerely yours, >> Ivan >> >> On 19.07.2014 8:59, Claes Redestad wrote: >>> Hi, >>> >>> after recent changes, this patch has been revisited and improved slightly, primarily simplifying and speeding up the toString method slightly more: >>> >>> http://cr.openjdk.java.net/~redestad/8006627/webrev.1/ >>> >>> /Claes >>> >>> On 2014-06-15 00:41, Claes Redestad wrote: >>>> Hi, >>>> >>>> please review this patch to improve UUID performance, originally proposed by Steven Schlansker, rebased to use the allocation-free methods added in https://bugs.openjdk.java.net/browse/JDK-8041972 >>>> >>>> Webrev: http://cr.openjdk.java.net/~redestad/8006627/webrev.0/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8006627 >>>> >>>> Thanks! >>>> >>>> /Claes >>> >>> >>> >> > From joe.darcy at oracle.com Mon Jul 21 17:58:41 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 21 Jul 2014 10:58:41 -0700 Subject: RFR [8051382] Optimize java.lang.reflect.Modifier.toString() In-Reply-To: References: <53C9A214.1060101@oracle.com> <53C9A640.8030808@oracle.com> <53C9C758.5070203@oracle.com> Message-ID: <53CD54D1.9030405@oracle.com> Hello, As a general comment, I think we should use more of StringJoiner in the JDK libraries; it would help get rid of some awkward loops, even if it isn't that compelling a code benefit in this case. While performance is an important concern, I don't know if producing modifier strings is actually performance critical. Cheers, -Joe On 07/19/2014 08:58 AM, Martin Buchholz wrote: > StringJoiner seems written in a style suitable for an application, not in a > low-level performance-oriented style suitable for a JDK core library. But > we can fix that. > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/StringJoiner-optimization/ > > > On Fri, Jul 18, 2014 at 6:18 PM, Ivan Gerasimov > wrote: > >> On 19.07.2014 3:07, Martin Buchholz wrote: >> >>> I took a quick look at StringJoiner. It looks to me like this won't be >>> an optimization, because StringJoiner uses StringBuilder internally, and >>> will actually perform more total operations. >>> >> Unfortunately this is true. >> Microbenchmarking shows that StringJoiner makes the things 30% slower, >> which is sad. >> >> Then I propose another simple patch giving +15% to the speed: >> >> http://cr.openjdk.java.net/~igerasim/8051382/1/webrev/ >> >> Sincerely yours, >> Inan >> >> From claes.redestad at oracle.com Mon Jul 21 18:05:51 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 21 Jul 2014 20:05:51 +0200 Subject: RFR [9] 8006627: UUID to/from String performance should be improved by reducing object allocations In-Reply-To: <53CD450F.4060702@gmail.com> References: <539CCF9C.9090001@oracle.com> <53C9FB27.2050300@oracle.com> <53CA6BA9.9070006@oracle.com> <53CCFC7B.7040600@oracle.com> <53CD450F.4060702@gmail.com> Message-ID: <53CD567F.4000400@oracle.com> Hi, IIOB is invalid to throw here, so I'll fix that. NumberFormatException is a IllegalArgumentException, so I think it's a gray area if the dash4 + 1 < name.length()-check is needed. I sincerely hope keeping error messages as-is isn't required, though. /Claes On 2014-07-21 18:51, Peter Levart wrote: > Hi Claes, > > Invalid inputs to UUID.fromString() behave a little different than > before. IllegalArgumentException is not thrown for the following inputs: > > For example: > > "0": IllegalArgumentException: Invalid UUID string: 0 (before patch) > "0": IndexOutOfBoundsException (after patch) > > "-0": IllegalArgumentException: Invalid UUID string: -0 (before patch) > "-0": NumberFormatException (after patch) > > "0-0-0-0-": IllegalArgumentException: Invalid UUID string: 0-0-0-0- > (before patch) > "0-0-0-0-": NumberFormatException (after patch) > > The following input (and similar) do throw NumberFormatException as > before, but messages are a little different. That's OK, I suppose. > > "0-0-0-x-0": NumberFormatException: For input string: "x" (before patch) > "0-0-0-x-0": NumberFormatException: Error at index 1 in: "x" (after patch) > > "0-0-0--0": NumberFormatException: For input string: "" (before patch) > "0-0-0--0": NumberFormatException: (after patch) > > > The 1st 3 examples could be fixed by checking that dash1,2,3,4 are all > > 0 and that dash4 + 1 < name.length() > > > Regards, Peter > > > On 07/21/2014 01:41 PM, Claes Redestad wrote: >> On 07/19/2014 02:59 PM, Ivan Gerasimov wrote: >>> This looks just beautiful! >> >> Thanks! >> >>> But why do you need the digits() function at all? >>> In my opinion, using formatUnsignedLong directly would be no less >>> clearer. >> >> Sure! >> >> http://cr.openjdk.java.net/~redestad/8006627/webrev.2/ >> >> Small improvement with client compiler; no measurable change with >> tiered. >> >> /Claes >> >>> >>> Sincerely yours, >>> Ivan >>> >>> On 19.07.2014 8:59, Claes Redestad wrote: >>>> Hi, >>>> >>>> after recent changes, this patch has been revisited and improved >>>> slightly, primarily simplifying and speeding up the toString method >>>> slightly more: >>>> >>>> http://cr.openjdk.java.net/~redestad/8006627/webrev.1/ >>>> >>>> /Claes >>>> >>>> On 2014-06-15 00:41, Claes Redestad wrote: >>>>> Hi, >>>>> >>>>> please review this patch to improve UUID performance, originally >>>>> proposed by Steven Schlansker, rebased to use the allocation-free >>>>> methods added in https://bugs.openjdk.java.net/browse/JDK-8041972 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~redestad/8006627/webrev.0/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8006627 >>>>> >>>>> Thanks! >>>>> >>>>> /Claes >>>> >>>> >>>> >>> >> > From claes.redestad at oracle.com Mon Jul 21 18:32:18 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 21 Jul 2014 20:32:18 +0200 Subject: RFR [9] 8006627: UUID to/from String performance should be improved by reducing object allocations In-Reply-To: <53CD567F.4000400@oracle.com> References: <539CCF9C.9090001@oracle.com> <53C9FB27.2050300@oracle.com> <53CA6BA9.9070006@oracle.com> <53CCFC7B.7040600@oracle.com> <53CD450F.4060702@gmail.com> <53CD567F.4000400@oracle.com> Message-ID: <53CD5CB2.2020903@oracle.com> Hi, new webrev which ensures we always throw some kind of IAE for invalid inputs and adds a few tests to cover this behavior: http://cr.openjdk.java.net/~redestad/8006627/webrev.4 /Claes On 2014-07-21 20:05, Claes Redestad wrote: > Hi, > > IIOB is invalid to throw here, so I'll fix that. > NumberFormatException is a IllegalArgumentException, so I think it's a > gray area if the dash4 + 1 < name.length()-check is needed. > > I sincerely hope keeping error messages as-is isn't required, though. > > /Claes > > On 2014-07-21 18:51, Peter Levart wrote: >> Hi Claes, >> >> Invalid inputs to UUID.fromString() behave a little different than >> before. IllegalArgumentException is not thrown for the following inputs: >> >> For example: >> >> "0": IllegalArgumentException: Invalid UUID string: 0 (before patch) >> "0": IndexOutOfBoundsException (after patch) >> >> "-0": IllegalArgumentException: Invalid UUID string: -0 (before patch) >> "-0": NumberFormatException (after patch) >> >> "0-0-0-0-": IllegalArgumentException: Invalid UUID string: 0-0-0-0- >> (before patch) >> "0-0-0-0-": NumberFormatException (after patch) >> >> The following input (and similar) do throw NumberFormatException as >> before, but messages are a little different. That's OK, I suppose. >> >> "0-0-0-x-0": NumberFormatException: For input string: "x" (before patch) >> "0-0-0-x-0": NumberFormatException: Error at index 1 in: "x" (after >> patch) >> >> "0-0-0--0": NumberFormatException: For input string: "" (before patch) >> "0-0-0--0": NumberFormatException: (after patch) >> >> >> The 1st 3 examples could be fixed by checking that dash1,2,3,4 are >> all > 0 and that dash4 + 1 < name.length() >> >> >> Regards, Peter >> >> >> On 07/21/2014 01:41 PM, Claes Redestad wrote: >>> On 07/19/2014 02:59 PM, Ivan Gerasimov wrote: >>>> This looks just beautiful! >>> >>> Thanks! >>> >>>> But why do you need the digits() function at all? >>>> In my opinion, using formatUnsignedLong directly would be no less >>>> clearer. >>> >>> Sure! >>> >>> http://cr.openjdk.java.net/~redestad/8006627/webrev.2/ >>> >>> Small improvement with client compiler; no measurable change with >>> tiered. >>> >>> /Claes >>> >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> On 19.07.2014 8:59, Claes Redestad wrote: >>>>> Hi, >>>>> >>>>> after recent changes, this patch has been revisited and improved >>>>> slightly, primarily simplifying and speeding up the toString >>>>> method slightly more: >>>>> >>>>> http://cr.openjdk.java.net/~redestad/8006627/webrev.1/ >>>>> >>>>> /Claes >>>>> >>>>> On 2014-06-15 00:41, Claes Redestad wrote: >>>>>> Hi, >>>>>> >>>>>> please review this patch to improve UUID performance, originally >>>>>> proposed by Steven Schlansker, rebased to use the allocation-free >>>>>> methods added in https://bugs.openjdk.java.net/browse/JDK-8041972 >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~redestad/8006627/webrev.0/ >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8006627 >>>>>> >>>>>> Thanks! >>>>>> >>>>>> /Claes >>>>> >>>>> >>>>> >>>> >>> >> > From claes.redestad at oracle.com Mon Jul 21 19:21:42 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 21 Jul 2014 21:21:42 +0200 Subject: RFR [9] 8006627: UUID to/from String performance should be improved by reducing object allocations In-Reply-To: <53CD5CB2.2020903@oracle.com> References: <539CCF9C.9090001@oracle.com> <53C9FB27.2050300@oracle.com> <53CA6BA9.9070006@oracle.com> <53CCFC7B.7040600@oracle.com> <53CD450F.4060702@gmail.com> <53CD567F.4000400@oracle.com> <53CD5CB2.2020903@oracle.com> Message-ID: <53CD6846.9000309@oracle.com> Hi, was asked offline to add a length check at the start (prevents potentially costly scans for huge, invalid input; negligible performance impact for normal cases) and realized dash1 < 0 || dash2 < 0 || dash3 < 0 implies dash4 < 0, so the first three checks are unnecessary and can be skipped: http://cr.openjdk.java.net/~redestad/8006627/webrev.5 /Claes On 2014-07-21 20:32, Claes Redestad wrote: > Hi, > > new webrev which ensures we always throw some kind of IAE for invalid > inputs and adds a few tests to cover this behavior: > http://cr.openjdk.java.net/~redestad/8006627/webrev.4 > > /Claes > > On 2014-07-21 20:05, Claes Redestad wrote: >> Hi, >> >> IIOB is invalid to throw here, so I'll fix that. >> NumberFormatException is a IllegalArgumentException, so I think it's >> a gray area if the dash4 + 1 < name.length()-check is needed. >> >> I sincerely hope keeping error messages as-is isn't required, though. >> >> /Claes >> >> On 2014-07-21 18:51, Peter Levart wrote: >>> Hi Claes, >>> >>> Invalid inputs to UUID.fromString() behave a little different than >>> before. IllegalArgumentException is not thrown for the following >>> inputs: >>> >>> For example: >>> >>> "0": IllegalArgumentException: Invalid UUID string: 0 (before patch) >>> "0": IndexOutOfBoundsException (after patch) >>> >>> "-0": IllegalArgumentException: Invalid UUID string: -0 (before patch) >>> "-0": NumberFormatException (after patch) >>> >>> "0-0-0-0-": IllegalArgumentException: Invalid UUID string: 0-0-0-0- >>> (before patch) >>> "0-0-0-0-": NumberFormatException (after patch) >>> >>> The following input (and similar) do throw NumberFormatException as >>> before, but messages are a little different. That's OK, I suppose. >>> >>> "0-0-0-x-0": NumberFormatException: For input string: "x" (before >>> patch) >>> "0-0-0-x-0": NumberFormatException: Error at index 1 in: "x" (after >>> patch) >>> >>> "0-0-0--0": NumberFormatException: For input string: "" (before patch) >>> "0-0-0--0": NumberFormatException: (after patch) >>> >>> >>> The 1st 3 examples could be fixed by checking that dash1,2,3,4 are >>> all > 0 and that dash4 + 1 < name.length() >>> >>> >>> Regards, Peter >>> >>> >>> On 07/21/2014 01:41 PM, Claes Redestad wrote: >>>> On 07/19/2014 02:59 PM, Ivan Gerasimov wrote: >>>>> This looks just beautiful! >>>> >>>> Thanks! >>>> >>>>> But why do you need the digits() function at all? >>>>> In my opinion, using formatUnsignedLong directly would be no less >>>>> clearer. >>>> >>>> Sure! >>>> >>>> http://cr.openjdk.java.net/~redestad/8006627/webrev.2/ >>>> >>>> Small improvement with client compiler; no measurable change with >>>> tiered. >>>> >>>> /Claes >>>> >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>> On 19.07.2014 8:59, Claes Redestad wrote: >>>>>> Hi, >>>>>> >>>>>> after recent changes, this patch has been revisited and improved >>>>>> slightly, primarily simplifying and speeding up the toString >>>>>> method slightly more: >>>>>> >>>>>> http://cr.openjdk.java.net/~redestad/8006627/webrev.1/ >>>>>> >>>>>> /Claes >>>>>> >>>>>> On 2014-06-15 00:41, Claes Redestad wrote: >>>>>>> Hi, >>>>>>> >>>>>>> please review this patch to improve UUID performance, originally >>>>>>> proposed by Steven Schlansker, rebased to use the >>>>>>> allocation-free methods added in >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8041972 >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~redestad/8006627/webrev.0/ >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8006627 >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> /Claes >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > From peter.levart at gmail.com Mon Jul 21 20:05:59 2014 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 21 Jul 2014 22:05:59 +0200 Subject: RFR [9] 8006627: UUID to/from String performance should be improved by reducing object allocations In-Reply-To: <53CD6846.9000309@oracle.com> References: <539CCF9C.9090001@oracle.com> <53C9FB27.2050300@oracle.com> <53CA6BA9.9070006@oracle.com> <53CCFC7B.7040600@oracle.com> <53CD450F.4060702@gmail.com> <53CD567F.4000400@oracle.com> <53CD5CB2.2020903@oracle.com> <53CD6846.9000309@oracle.com> Message-ID: <53CD72A7.5060401@gmail.com> On 07/21/2014 09:21 PM, Claes Redestad wrote: > Hi, > > was asked offline to add a length check at the start (prevents > potentially costly scans for huge, invalid input; negligible > performance impact for normal cases) and realized dash1 < 0 || dash2 < > 0 || dash3 < 0 implies dash4 < 0, so the first three checks are > unnecessary and can be skipped: > > http://cr.openjdk.java.net/~redestad/8006627/webrev.5 Hi Claes, dash1 < 0 || dash2 < 0 || dash3 < 0 does not imply dash4 < 0 Take for example the following input: "0-0-0" dash1 = 1 dash2 = 3 dash3 = -1 dash4 = 1 (again) but the following check: if (dash4 < 0 || name.indexOf('-', dash4 + 1) > 0) is true in this case. It seems either dash4 < 0 or dash5 > 0 for any number of dashes in the string except exactly 4. It's just that this is not immediately evident for the casual reader. I recommend adding a comment for posterity. Regards, Peter > > /Claes > > On 2014-07-21 20:32, Claes Redestad wrote: >> Hi, >> >> new webrev which ensures we always throw some kind of IAE for >> invalid inputs and adds a few tests to cover this behavior: >> http://cr.openjdk.java.net/~redestad/8006627/webrev.4 >> >> /Claes >> >> On 2014-07-21 20:05, Claes Redestad wrote: >>> Hi, >>> >>> IIOB is invalid to throw here, so I'll fix that. >>> NumberFormatException is a IllegalArgumentException, so I think it's >>> a gray area if the dash4 + 1 < name.length()-check is needed. >>> >>> I sincerely hope keeping error messages as-is isn't required, though. >>> >>> /Claes >>> >>> On 2014-07-21 18:51, Peter Levart wrote: >>>> Hi Claes, >>>> >>>> Invalid inputs to UUID.fromString() behave a little different than >>>> before. IllegalArgumentException is not thrown for the following >>>> inputs: >>>> >>>> For example: >>>> >>>> "0": IllegalArgumentException: Invalid UUID string: 0 (before patch) >>>> "0": IndexOutOfBoundsException (after patch) >>>> >>>> "-0": IllegalArgumentException: Invalid UUID string: -0 (before patch) >>>> "-0": NumberFormatException (after patch) >>>> >>>> "0-0-0-0-": IllegalArgumentException: Invalid UUID string: 0-0-0-0- >>>> (before patch) >>>> "0-0-0-0-": NumberFormatException (after patch) >>>> >>>> The following input (and similar) do throw NumberFormatException as >>>> before, but messages are a little different. That's OK, I suppose. >>>> >>>> "0-0-0-x-0": NumberFormatException: For input string: "x" (before >>>> patch) >>>> "0-0-0-x-0": NumberFormatException: Error at index 1 in: "x" (after >>>> patch) >>>> >>>> "0-0-0--0": NumberFormatException: For input string: "" (before patch) >>>> "0-0-0--0": NumberFormatException: (after patch) >>>> >>>> >>>> The 1st 3 examples could be fixed by checking that dash1,2,3,4 are >>>> all > 0 and that dash4 + 1 < name.length() >>>> >>>> >>>> Regards, Peter >>>> >>>> >>>> On 07/21/2014 01:41 PM, Claes Redestad wrote: >>>>> On 07/19/2014 02:59 PM, Ivan Gerasimov wrote: >>>>>> This looks just beautiful! >>>>> >>>>> Thanks! >>>>> >>>>>> But why do you need the digits() function at all? >>>>>> In my opinion, using formatUnsignedLong directly would be no less >>>>>> clearer. >>>>> >>>>> Sure! >>>>> >>>>> http://cr.openjdk.java.net/~redestad/8006627/webrev.2/ >>>>> >>>>> Small improvement with client compiler; no measurable change with >>>>> tiered. >>>>> >>>>> /Claes >>>>> >>>>>> >>>>>> Sincerely yours, >>>>>> Ivan >>>>>> >>>>>> On 19.07.2014 8:59, Claes Redestad wrote: >>>>>>> Hi, >>>>>>> >>>>>>> after recent changes, this patch has been revisited and >>>>>>> improved slightly, primarily simplifying and speeding up the >>>>>>> toString method slightly more: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~redestad/8006627/webrev.1/ >>>>>>> >>>>>>> /Claes >>>>>>> >>>>>>> On 2014-06-15 00:41, Claes Redestad wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> please review this patch to improve UUID performance, >>>>>>>> originally proposed by Steven Schlansker, rebased to use the >>>>>>>> allocation-free methods added in >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8041972 >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~redestad/8006627/webrev.0/ >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8006627 >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> /Claes >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From stuart.marks at oracle.com Mon Jul 21 20:55:19 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 21 Jul 2014 13:55:19 -0700 Subject: please review draft JEP: Convenience Factory Methods for Collections In-Reply-To: <53C9B09A.1040709@redhat.com> References: <53C71CFC.8020903@oracle.com> <364C8776-4E58-4D6E-933D-0C8D156E5667@saxonica.com> <53C841F2.8090009@oracle.com> <802A6202-44DF-48A6-A858-69062A7BADD4@oracle.com> <2EE124AE-6B77-4095-A477-E9F238B1744C@saxonica.com> <53C9AF83.9070404@oracle.com> <53C9B09A.1040709@redhat.com> Message-ID: <53CD7E37.5000703@oracle.com> On 7/18/14 4:41 PM, David M. Lloyd wrote: > On 07/18/2014 06:36 PM, Stuart Marks wrote: >> Map.of() >> .add(k0, v0) >> .add(k1, v1) >> ... >> .add(kN, vN); >> >> this would result in O(N^2) performance and space allocation, though >> most of the allocated space is garbage. > > Adding another alternative, instead of producing intermediate maps which are > copied at each step for the sake of maintaining O(1) lookup, this approach could > instead create a linked-list-of-pairs which would be O(n) for lookups, but also > O(n) for space - you could then efficiently feed that to a "real" map > constructor, especially if each "map" also implemented Map.Entry, which would > make an iterator particularly lightweight, making the overall cost for, say, a > HashMap be O(n). > > Not sure it's the "right" approach, just throwing it out there as a random > Friday thought. ... now being analyzed in the cold, harsh light of a Monday morning. Er, afternoon. :-) The main difficulty here is if the type returned by add() is a Map, it has to obey all the requirements of the Map contract. That means that somebody has to enforce the uniqueness constraint of the keys. This will affect things like iterating over the map or asking for its size, and so forth. Either the extra work is done at addition time or later when certain results require respecting uniqueness. If add() returns something other than a Map, such as a temporary data structure later used to construct a Map, then pushing the items onto a linked list is quite a sensible idea. (Maybe a linked list of arrays, to reduce per-element overhead.) We don't care if the keys are unique when they're being added, since that'll be taken care of later at map construction time. But this is essentially a builder, not incremental additions to a Map. s'marks From stuart.marks at oracle.com Mon Jul 21 20:57:05 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 21 Jul 2014 13:57:05 -0700 Subject: please review draft JEP: Convenience Factory Methods for Collections In-Reply-To: <53CA349B.1080301@univ-mlv.fr> References: <53C71CFC.8020903@oracle.com> <364C8776-4E58-4D6E-933D-0C8D156E5667@saxonica.com> <53C841F2.8090009@oracle.com> <802A6202-44DF-48A6-A858-69062A7BADD4@oracle.com> <2EE124AE-6B77-4095-A477-E9F238B1744C@saxonica.com> <53C9AF83.9070404@oracle.com> <53CA349B.1080301@univ-mlv.fr> Message-ID: <53CD7EA1.8060906@oracle.com> On 7/19/14 2:04 AM, Remi Forax wrote: > You can combine these 2 approachesi using a Ruby like builder approach with a > lambda, > which provide a builder object (so static method call are replaced by instance > method call) avoiding the creation of too many entry objects > Map.of(b -> b > .entry(k0, v0) > .entry(k1, v1) > ... > .entry(kN, vN)) Very interesting! I'll take a look at this approach. Some of the internal feedback on this JEP draft before I posted it here was, (jokingly) "What, it doesn't use lambda??" Now we might have a way to work lambda into this. :-) s'marks From claes.redestad at oracle.com Mon Jul 21 21:12:58 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 21 Jul 2014 23:12:58 +0200 Subject: RFR [9] 8006627: UUID to/from String performance should be improved by reducing object allocations In-Reply-To: <53CD72A7.5060401@gmail.com> References: <539CCF9C.9090001@oracle.com> <53C9FB27.2050300@oracle.com> <53CA6BA9.9070006@oracle.com> <53CCFC7B.7040600@oracle.com> <53CD450F.4060702@gmail.com> <53CD567F.4000400@oracle.com> <53CD5CB2.2020903@oracle.com> <53CD6846.9000309@oracle.com> <53CD72A7.5060401@gmail.com> Message-ID: <53CD825A.30404@oracle.com> On 2014-07-21 22:05, Peter Levart wrote: > > On 07/21/2014 09:21 PM, Claes Redestad wrote: >> Hi, >> >> was asked offline to add a length check at the start (prevents >> potentially costly scans for huge, invalid input; negligible >> performance impact for normal cases) and realized dash1 < 0 || dash2 >> < 0 || dash3 < 0 implies dash4 < 0, so the first three checks are >> unnecessary and can be skipped: >> >> http://cr.openjdk.java.net/~redestad/8006627/webrev.5 > > Hi Claes, > > dash1 < 0 || dash2 < 0 || dash3 < 0 does not imply dash4 < 0 > > Take for example the following input: "0-0-0" > > dash1 = 1 > dash2 = 3 > dash3 = -1 > dash4 = 1 (again) Well, this is embarrassing... > > but the following check: > > if (dash4 < 0 || name.indexOf('-', dash4 + 1) > 0) > > is true in this case. It seems either dash4 < 0 or dash5 > 0 for any > number of dashes in the string except exactly 4. It's just that this > is not immediately evident for the casual reader. I recommend adding a > comment for posterity. ... but that explains why all test cases worked and reinforced the erroneous assumption. Skipping the checks bring back a few percent in my microbenchmarks, so I guess adding an explanation as to why this actually works in context in an inline comment is the least we should do here: + // For any valid input, dash1 through dash4 will be positive and dash5 + // negative, but it's enough to check dash4 and dash5: + // - if dash1 is -1, dash4 will be -1 + // - if dash1 is positive but dash2 is -1, dash4 will be -1 + // - if dash1 and dash2 is positive, dash3 will be -1, dash4 will be + // positive, but so will dash5 http://cr.openjdk.java.net/~redestad/8006627/webrev.6 Thanks! /Claes > > Regards, Peter > >> >> /Claes >> >> On 2014-07-21 20:32, Claes Redestad wrote: >>> Hi, >>> >>> new webrev which ensures we always throw some kind of IAE for >>> invalid inputs and adds a few tests to cover this behavior: >>> http://cr.openjdk.java.net/~redestad/8006627/webrev.4 >>> >>> /Claes >>> >>> On 2014-07-21 20:05, Claes Redestad wrote: >>>> Hi, >>>> >>>> IIOB is invalid to throw here, so I'll fix that. >>>> NumberFormatException is a IllegalArgumentException, so I think >>>> it's a gray area if the dash4 + 1 < name.length()-check is needed. >>>> >>>> I sincerely hope keeping error messages as-is isn't required, though. >>>> >>>> /Claes >>>> >>>> On 2014-07-21 18:51, Peter Levart wrote: >>>>> Hi Claes, >>>>> >>>>> Invalid inputs to UUID.fromString() behave a little different than >>>>> before. IllegalArgumentException is not thrown for the following >>>>> inputs: >>>>> >>>>> For example: >>>>> >>>>> "0": IllegalArgumentException: Invalid UUID string: 0 (before patch) >>>>> "0": IndexOutOfBoundsException (after patch) >>>>> >>>>> "-0": IllegalArgumentException: Invalid UUID string: -0 (before >>>>> patch) >>>>> "-0": NumberFormatException (after patch) >>>>> >>>>> "0-0-0-0-": IllegalArgumentException: Invalid UUID string: >>>>> 0-0-0-0- (before patch) >>>>> "0-0-0-0-": NumberFormatException (after patch) >>>>> >>>>> The following input (and similar) do throw NumberFormatException >>>>> as before, but messages are a little different. That's OK, I suppose. >>>>> >>>>> "0-0-0-x-0": NumberFormatException: For input string: "x" (before >>>>> patch) >>>>> "0-0-0-x-0": NumberFormatException: Error at index 1 in: "x" >>>>> (after patch) >>>>> >>>>> "0-0-0--0": NumberFormatException: For input string: "" (before >>>>> patch) >>>>> "0-0-0--0": NumberFormatException: (after patch) >>>>> >>>>> >>>>> The 1st 3 examples could be fixed by checking that dash1,2,3,4 are >>>>> all > 0 and that dash4 + 1 < name.length() >>>>> >>>>> >>>>> Regards, Peter >>>>> >>>>> >>>>> On 07/21/2014 01:41 PM, Claes Redestad wrote: >>>>>> On 07/19/2014 02:59 PM, Ivan Gerasimov wrote: >>>>>>> This looks just beautiful! >>>>>> >>>>>> Thanks! >>>>>> >>>>>>> But why do you need the digits() function at all? >>>>>>> In my opinion, using formatUnsignedLong directly would be no >>>>>>> less clearer. >>>>>> >>>>>> Sure! >>>>>> >>>>>> http://cr.openjdk.java.net/~redestad/8006627/webrev.2/ >>>>>> >>>>>> Small improvement with client compiler; no measurable change with >>>>>> tiered. >>>>>> >>>>>> /Claes >>>>>> >>>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan >>>>>>> >>>>>>> On 19.07.2014 8:59, Claes Redestad wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> after recent changes, this patch has been revisited and >>>>>>>> improved slightly, primarily simplifying and speeding up the >>>>>>>> toString method slightly more: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~redestad/8006627/webrev.1/ >>>>>>>> >>>>>>>> /Claes >>>>>>>> >>>>>>>> On 2014-06-15 00:41, Claes Redestad wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> please review this patch to improve UUID performance, >>>>>>>>> originally proposed by Steven Schlansker, rebased to use the >>>>>>>>> allocation-free methods added in >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8041972 >>>>>>>>> >>>>>>>>> Webrev: http://cr.openjdk.java.net/~redestad/8006627/webrev.0/ >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8006627 >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>> /Claes >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From mike.duigou at oracle.com Tue Jul 22 00:33:20 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 21 Jul 2014 17:33:20 -0700 Subject: Map.compute() confusing Javadoc In-Reply-To: <53CC41F1.6070402@oracle.com> References: <935901405613954@web13m.yandex.ru> <78CA59DA-6BE4-4467-A491-4A938F522CFB@oracle.com> <53CC41F1.6070402@oracle.com> Message-ID: <96184758-784A-4A9C-9C56-400E03398D87@oracle.com> Hi Roman; Somewhat unfortunately, "just return null" is what the default and all conforming implementations do of compute do when presented with a Map containing a mapping to null and a mapping function returning null. The specification of the new Java 8 Map methods does not always handle maps containing null values as clean as might be wished. This is mostly to maintain consistent semantics with some pre-java 8 ConcurrentHashMap operations. The chain of debatable decisions all starts with "putIfAbsent()" and then tries to proceed consistently to the other new default operations. In general a null-value mapping in a Map is treated as absent--the same way as CHM would treat a get() returning null. Every attempt I made at improving the behaviour of mapping to null values ended up being weirder and more mysterious than what Java 8 shipped with. Sorry. Mike On Jul 20 2014, at 15:25 , David Holmes wrote: > See: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018251.html > > and related bug report. > > David > > On 21/07/2014 6:01 AM, Paul Sandoz wrote: >> Begin forwarded message: >>> -------- ???????????? ?????????-------- >>> 17.07.2014, 19:20, "Roman Leventov" : >>> >>> Map.compute() Javadoc has the following paragraph: >>> -------- >>> The default implementation is equivalent to performing the following steps for this map, then returning the current value or null if absent: >>> >>> V oldValue = map.get(key); >>> V newValue = remappingFunction.apply(key, oldValue); >>> if (oldValue != null ) { >>> if (newValue != null) >>> map.put(key, newValue); >>> else >>> map.remove(key); >>> } else { >>> if (newValue != null) >>> map.put(key, newValue); >>> else >>> return null; >>> } >>> -------- >>> >>> But this code don't correspond neither verbal description of the behaviour nor the actual default implementation in java.util.Map. If the oldValue is null and newValue is null, map should still remove the key, not to just `return null;` >>> >> From martinrb at google.com Tue Jul 22 01:58:00 2014 From: martinrb at google.com (Martin Buchholz) Date: Mon, 21 Jul 2014 18:58:00 -0700 Subject: RFR [8051382] Optimize java.lang.reflect.Modifier.toString() In-Reply-To: <53CD54D1.9030405@oracle.com> References: <53C9A214.1060101@oracle.com> <53C9A640.8030808@oracle.com> <53C9C758.5070203@oracle.com> <53CD54D1.9030405@oracle.com> Message-ID: On Mon, Jul 21, 2014 at 10:58 AM, Joe Darcy wrote: > Hello, > > As a general comment, I think we should use more of StringJoiner in the > JDK libraries; it would help get rid of some awkward loops, even if it > isn't that compelling a code benefit in this case. > > In performance critical contexts, one can almost always do a little better than to use StringJoiner. StringJoiner feels like an odd API. For performance critical uses, there is no way to presize the output. As a community, we have still not learned that use of constructors (instead of factory methods) is usually a design mistake. > While performance is an important concern, I don't know if producing > modifier strings is actually performance critical. > > I agree that Modifier.toString is probably not performance critical. From joe.darcy at oracle.com Tue Jul 22 03:33:23 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 21 Jul 2014 20:33:23 -0700 Subject: Fwd: JDK 9 RFR of JDK-8030942: Explicitly state floating-point summation requirements on non-finite inputs In-Reply-To: <53C96EE2.6000107@oracle.com> References: <53C5C77A.5040500@oracle.com> <49851217-96FD-4A7D-BADB-7857815CF506@oracle.com> <53C91335.1070601@oracle.com> <53C947E7.2020603@oracle.com> <53C96EE2.6000107@oracle.com> Message-ID: <53CDDB83.6000803@oracle.com> On 07/18/2014 12:00 PM, Georgiy Rakov wrote: > > On 18.07.2014 20:14, Joe Darcy wrote: >> Hello Georgiy, >> >> On 07/18/2014 05:29 AM, Georgiy Rakov wrote: >>> Hello Joe, >>> >>> could you please clarify by short example following assertion: >>> >>> 154 * If the exact sum is infinite, a properly-signed infinity is >>> 155 * returned. >>> >>> I'm afraid I don't quite understand what you mean here by 'exact sum'. >> >> By "exact sum," the sum absent any floating-point rounding, the sum >> you would get using infinite precision to operate on the values in >> question. >> >> The sentence in question is intended to be a short way of saying "If >> you have same-signed infinities in your input, the result will be an >> infinity of that sign." In particular, this disallows the behavior >> that was fixed before JDK 8 GA where having infinities in the input >> would cause a NaN to be returned because of how the compensated >> summation code manipulated those values. >> > Thanks, I see, > however it seems to me a bit confusing, since the term "infinite exact > sum" seems to me not obvious and I believe it needs some definition. > I'd like to suggest to use more straightforward approach, that is as > you've said: "If you have same-signed infinities in your input, the > result will be an infinity of that sign.". I believe it would be more > clear for end user (at least for me :)) and from conformance point of > view. > > Besides it seems to me a bit questionable. For instance "inexact some" > looks like more appropriate, since overflowing to infinity occurs when > _actual _sum exceeds the limit. By actual sum I mean sum resulted from > actual summation with all the rounding happened. There wouldn't be > such questions, provided straightforward approach is used. > > Thanks, > Georgiy. > In response to previous feedback, I propose this revised change to the specification: --- a/src/share/classes/java/util/DoubleSummaryStatistics.java Sat Jul 19 11:22:08 2014 +0800 +++ b/src/share/classes/java/util/DoubleSummaryStatistics.java Mon Jul 21 18:02:54 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -129,9 +129,6 @@ * Returns the sum of values recorded, or zero if no values have been * recorded. * - * If any recorded value is a NaN or the sum is at any point a NaN - * then the sum will be NaN. - * *

The value of a floating-point sum is a function both of the * input values as well as the order of addition operations. The * order of addition operations of this method is intentionally @@ -143,6 +140,44 @@ * numerical sum compared to a simple summation of {@code double} * values. * + * Because of the unspecified order of operations and the + * possibility of using differing summation schemes, the output of + * this method may vary on the same input values. + * + *

Various conditions can result in a non-finite sum being + * computed. This can occur even if the all the recorded values + * being summed are finite. If any recorded value is non-finite, + * the sum will be non-finite: + * + *

    + * + *
  • If any recorded value is a NaN, then the final sum will be + * NaN. + * + *
  • If the recorded values contain one or more infinities, the + * sum will be infinite or NaN. + * + *
      + * + *
    • If the recorded values contain infinities of opposite sign, + * the sum will be NaN. + * + *
    • If the recorded values contain infinities of one sign and + * an intermediate sum overflows to an infinity of the opposite + * sign, the sum may be NaN. + * + *
    + * + *
+ * + * It is possible for intermediate sums of finite values to + * overflow into opposite-signed infinities; if that occurs, the + * final sum will be NaN even if the recorded values are all + * finite. + * + * If all the recorded values are zero, the sign of zero is + * not guaranteed to be preserved in the final sum. + * * @apiNote Values sorted by increasing absolute magnitude tend to yield * more accurate results. * @@ -193,15 +228,9 @@ * Returns the arithmetic mean of values recorded, or zero if no * values have been recorded. * - * If any recorded value is a NaN or the sum is at any point a NaN - * then the average will be code NaN. - * - *

The average returned can vary depending upon the order in - * which values are recorded. - * - * This method may be implemented using compensated summation or - * other technique to reduce the error bound in the {@link #getSum - * numerical sum} used to compute the average. + *

The computed average can vary numerically and have the + * special case behavior as computing the sum; see {@link #getSum} + * for details. * * @apiNote Values sorted by increasing absolute magnitude tend to yield * more accurate results. (With analogous changes in java/util/stream/DoubleStream.java.) Thanks, -Joe From aleksej.efimov at oracle.com Tue Jul 22 13:10:45 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Tue, 22 Jul 2014 17:10:45 +0400 Subject: RFR: 8029837: NPE seen in XMLDocumentFragmentScannerImpl.setProperty since 7u40b33 Message-ID: <53CE62D5.4050107@oracle.com> Hello, Please review the fix [1] for the following bug: https://bugs.openjdk.java.net/browse/JDK-8029837 The problem was discovered during usage of not compatible old JAXB/XJC classes on the stack with latest JDK source (starting from 7u40 release). The problem is that the JAXP XML_SECURITY_PROPERTY_MANAGER and SECURITY_MANAGER properties was not initialized by the XJC task code: new regression test recreates the similar condition. XML related regression tests and JCK tests passes with proposed fix. Thank you, Aleksej [1] Webrev: http://cr.openjdk.java.net/~aefimov/8029837/9/webrev.00/ From georgiy.rakov at oracle.com Tue Jul 22 15:35:03 2014 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Tue, 22 Jul 2014 19:35:03 +0400 Subject: Fwd: JDK 9 RFR of JDK-8030942: Explicitly state floating-point summation requirements on non-finite inputs In-Reply-To: <53CDDB83.6000803@oracle.com> References: <53C5C77A.5040500@oracle.com> <49851217-96FD-4A7D-BADB-7857815CF506@oracle.com> <53C91335.1070601@oracle.com> <53C947E7.2020603@oracle.com> <53C96EE2.6000107@oracle.com> <53CDDB83.6000803@oracle.com> Message-ID: <53CE84A7.4010200@oracle.com> Hello Joe, if I understand correctly the doc doesn't specify exact circumstances leading to infinities, it just has general assertion: *

  • If the recorded values contain one or more infinities, the * sum will be infinite or NaN. this assertion is clarified by following child assertions which specify just NaN-causing circumstances but what exactly can lead to infinities is not specified therein: *