From stuart.marks at oracle.com Sat Mar 1 01:35:40 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 28 Feb 2014 17:35:40 -0800 Subject: [REFRESH] JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger In-Reply-To: <8520F61D-B0CE-4E83-8336-938C745823D1@oracle.com> References: <5305D6EB.30806@oracle.com> <53064179.2060703@gmail.com> <530660FA.1060407@oracle.com> <96CF3236-4E65-4D64-BCF3-1E9660D29BAA@oracle.com> <5306BC4B.4090909@oracle.com> <8229AE11-1ABF-474D-961F-BBD5ACA3DD82@oracle.com> <61708919-691D-4EBF-8685-0CC5FC309701@oracle.com> <10AE28AF-8765-430C-9D83-D0A88062B096@oracle.com> <247D03A1-0D88-437D-B2F1-9CD5DAE8492D@oracle.com> <8520F61D-B0CE-4E83-8336-938C745823D1@oracle.com> Message-ID: <5311396C.3020509@oracle.com> On 2/27/14 12:14 PM, Brian Burkhalter wrote: > > On Feb 27, 2014, at 12:17 AM, Paul Sandoz wrote: > >>> So may I obtain a +1 from a JDK 9 Reviewer now? >>> >> >> Indeed you may. > > Thanks, Paul. I refreshed the webrev http://cr.openjdk.java.net/~bpb/8035279/webrev.01/ with the agreed upon version. Hi Brian, This is pretty good. After this long, strange trip through the JMM, restoring the sentinel values to zeroes and renaming the fields to be explicit about how they represent the actual values seems to be the best approach. Paul's suggestion about using the term "stable value" in comments is good too. I took a look at the serialization stuff. The actual serialized form hasn't changed, so there should be no compatibility here with previous versions. There are some things in the serialization doc that ought to be brought up to date, though. Note that the docs for serialPersistentFields, readObject, and writeObject appear in the javadoc output, in the "Serialized Form" page, even though these members are private! Per another of Paul's comments, the @serial tag should be removed from bitCountPlusOne, bitLengthPlusOne, and lowestSetBitPlusTwo, since these fields do not appear in the serialized representation. The fields bitCount, bitLength, and lowestSetBit appear in the serialized form only for backward compatibility and are otherwise ignored, so their @serialField entries should just say that instead of describing how they were formerly used. Also, firstNonzeroByteNum is missing a @serialField entry, and it should have the same description as the others. Typo at 4236-4237, it says "be\ndefault" instead of "by\ndefault". The comment at lines 4242-4246 should simply be removed. The first and third sentences are redundant with other docs. The second sentence, "The magnitude field is used as a temporary store for the byte array that is deserialized" is incorrect, as there is no longer a 'magnitude' field; a local is used instead. The @serialData tag at line 4316 for writeObject is misused; this is really intended for *extra* serial data written by writeObject after the writeFields() or defaultWriteObject() call, which doesn't occur here. It might be worth being explicit in writeObject's doc comment about writing -1's and -2's as the values for bitCount, bitLength, lowestSetBit, and firstNonzeroByteNum for compatibility with older implementations, even though current implementations will ignore these values. Thanks, s'marks From stuart.marks at oracle.com Sat Mar 1 01:54:27 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 28 Feb 2014 17:54:27 -0800 Subject: [REFRESH] JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger In-Reply-To: <5311396C.3020509@oracle.com> References: <5305D6EB.30806@oracle.com> <53064179.2060703@gmail.com> <530660FA.1060407@oracle.com> <96CF3236-4E65-4D64-BCF3-1E9660D29BAA@oracle.com> <5306BC4B.4090909@oracle.com> <8229AE11-1ABF-474D-961F-BBD5ACA3DD82@oracle.com> <61708919-691D-4EBF-8685-0CC5FC309701@oracle.com> <10AE28AF-8765-430C-9D83-D0A88062B096@oracle.com> <247D03A1-0D88-437D-B2F1-9CD5DAE8492D@oracle.com> <8520F61D-B0CE-4E83-8336-938C745823D1@oracle.com> <5311396C.3020509@oracle.com> Message-ID: <53113DD3.6030309@oracle.com> Woops, I forgot a couple points. The @serial for the 'signum' field at line 130 should be removed. Note that even though this has the same name as the field that appears in the serialized form, the text from the @serialField tag for 'signum' that's part of the serialPersistentFields doc comment is the one that actually appears on the "Serialized Form" page. It might be worthwhile copying the more verbose description from lines 125-128 to the @serialField tag text (lines 4206-4207) since this describes the requirements on the serialized form more precisely. I hate redundancy in documentation, though. Note that the field names in the ObjectStreamField entries of the serialPersistentFields array don't necessarily match the actual fields in the class. In this case 'signum' matches but the others do not. That's ok. The entries in this array describe the field names that are used in the serialized output, which is essential for remaining compatible with older versions of BigInteger. I checked an old version of BigInteger from 1998 and the field names used here match the actual, serialized fields from that old version. s'marks On 2/28/14 5:35 PM, Stuart Marks wrote: > On 2/27/14 12:14 PM, Brian Burkhalter wrote: >> http://cr.openjdk.java.net/~bpb/8035279/webrev.01/ with the agreed upon version. > > Hi Brian, > > This is pretty good. After this long, strange trip through the JMM, restoring > the sentinel values to zeroes and renaming the fields to be explicit about how > they represent the actual values seems to be the best approach. Paul's > suggestion about using the term "stable value" in comments is good too. > > I took a look at the serialization stuff. The actual serialized form hasn't > changed, so there should be no compatibility here with previous versions. > > There are some things in the serialization doc that ought to be brought up to > date, though. Note that the docs for serialPersistentFields, readObject, and > writeObject appear in the javadoc output, in the "Serialized Form" page, even > though these members are private! > > Per another of Paul's comments, the @serial tag should be removed from > bitCountPlusOne, bitLengthPlusOne, and lowestSetBitPlusTwo, since these fields > do not appear in the serialized representation. > > The fields bitCount, bitLength, and lowestSetBit appear in the serialized form > only for backward compatibility and are otherwise ignored, so their @serialField > entries should just say that instead of describing how they were formerly used. > Also, firstNonzeroByteNum is missing a @serialField entry, and it should have > the same description as the others. > > Typo at 4236-4237, it says "be\ndefault" instead of "by\ndefault". > > The comment at lines 4242-4246 should simply be removed. The first and third > sentences are redundant with other docs. The second sentence, "The magnitude > field is used as a temporary store for the byte array that is deserialized" is > incorrect, as there is no longer a 'magnitude' field; a local is used instead. > > The @serialData tag at line 4316 for writeObject is misused; this is really > intended for *extra* serial data written by writeObject after the writeFields() > or defaultWriteObject() call, which doesn't occur here. It might be worth being > explicit in writeObject's doc comment about writing -1's and -2's as the values > for bitCount, bitLength, lowestSetBit, and firstNonzeroByteNum for compatibility > with older implementations, even though current implementations will ignore > these values. > > Thanks, > > s'marks From brian.burkhalter at oracle.com Sat Mar 1 01:53:18 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 28 Feb 2014 17:53:18 -0800 Subject: [REFRESH] JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger In-Reply-To: <5311396C.3020509@oracle.com> References: <5305D6EB.30806@oracle.com> <53064179.2060703@gmail.com> <530660FA.1060407@oracle.com> <96CF3236-4E65-4D64-BCF3-1E9660D29BAA@oracle.com> <5306BC4B.4090909@oracle.com> <8229AE11-1ABF-474D-961F-BBD5ACA3DD82@oracle.com> <61708919-691D-4EBF-8685-0CC5FC309701@oracle.com> <10AE28AF-8765-430C-9D83-D0A88062B096@oracle.com> <247D03A1-0D88-437D-B2F1-9CD5DAE8492D@oracle.com> <8520F61D-B0CE-4E83-8336-938C745823D1@oracle.com> <5311396C.3020509@oracle.com> Message-ID: <96441861-A7FC-48A1-93D2-132B7277B3D5@oracle.com> Hi Stuart On Feb 28, 2014, at 5:35 PM, Stuart Marks wrote: > This is pretty good. After this long, strange trip through the JMM, restoring the sentinel values to zeroes and renaming the fields to be explicit about how they represent the actual values seems to be the best approach. Paul's suggestion about using the term "stable value" in comments is good too. > > I took a look at the serialization stuff. The actual serialized form hasn't changed, so there should be no compatibility here with previous versions. For the above, good! > There are some things in the serialization doc that ought to be brought up to date, though. Note that the docs for serialPersistentFields, readObject, and writeObject appear in the javadoc output, in the "Serialized Form" page, even though these members are private! > > Per another of Paul's comments, the @serial tag should be removed from bitCountPlusOne, bitLengthPlusOne, and lowestSetBitPlusTwo, since these fields do not appear in the serialized representation. Yes, I was wondering about that. > The fields bitCount, bitLength, and lowestSetBit appear in the serialized form only for backward compatibility and are otherwise ignored, so their @serialField entries should just say that instead of describing how they were formerly used. Also, firstNonzeroByteNum is missing a @serialField entry, and it should have the same description as the others. > > Typo at 4236-4237, it says "be\ndefault" instead of "by\ndefault". > > The comment at lines 4242-4246 should simply be removed. The first and third sentences are redundant with other docs. The second sentence, "The magnitude field is used as a temporary store for the byte array that is deserialized" is incorrect, as there is no longer a 'magnitude' field; a local is used instead. > > The @serialData tag at line 4316 for writeObject is misused; this is really intended for *extra* serial data written by writeObject after the writeFields() or defaultWriteObject() call, which doesn't occur here. It might be worth being explicit in writeObject's doc comment about writing -1's and -2's as the values for bitCount, bitLength, lowestSetBit, and firstNonzeroByteNum for compatibility with older implementations, even though current implementations will ignore these values. I will make the suggested updates and repost an updated webrev, probably on Monday. Thanks for the detailed review! Brian From brian.burkhalter at oracle.com Sat Mar 1 01:55:03 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 28 Feb 2014 17:55:03 -0800 Subject: [REFRESH] JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger In-Reply-To: <53113DD3.6030309@oracle.com> References: <5305D6EB.30806@oracle.com> <53064179.2060703@gmail.com> <530660FA.1060407@oracle.com> <96CF3236-4E65-4D64-BCF3-1E9660D29BAA@oracle.com> <5306BC4B.4090909@oracle.com> <8229AE11-1ABF-474D-961F-BBD5ACA3DD82@oracle.com> <61708919-691D-4EBF-8685-0CC5FC309701@oracle.com> <10AE28AF-8765-430C-9D83-D0A88062B096@oracle.com> <247D03A1-0D88-437D-B2F1-9CD5DAE8492D@oracle.com> <8520F61D-B0CE-4E83-8336-938C745823D1@oracle.com> <5311396C.3020509@oracle.com> <53113DD3.6030309@oracle.com> Message-ID: On Feb 28, 2014, at 5:54 PM, Stuart Marks wrote: > Woops, I forgot a couple points. > > The @serial for the 'signum' field at line 130 should be removed. Note that even though this has the same name as the field that appears in the serialized form, the text from the @serialField tag for 'signum' that's part of the serialPersistentFields doc comment is the one that actually appears on the "Serialized Form" page. > > It might be worthwhile copying the more verbose description from lines 125-128 to the @serialField tag text (lines 4206-4207) since this describes the requirements on the serialized form more precisely. I hate redundancy in documentation, though. > > Note that the field names in the ObjectStreamField entries of the serialPersistentFields array don't necessarily match the actual fields in the class. In this case 'signum' matches but the others do not. That's ok. The entries in this array describe the field names that are used in the serialized output, which is essential for remaining compatible with older versions of BigInteger. That was my understanding so it's good to have it corroborated. > I checked an old version of BigInteger from 1998 and the field names used here match the actual, serialized fields from that old version. This sort of detail is really good to hear. I'll incorporate the lot when I update. Thanks much! Brian From Alan.Bateman at oracle.com Sat Mar 1 09:06:14 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 01 Mar 2014 09:06:14 +0000 Subject: RFR (JAXP): 8035469 : Xerces Update: EncodingMap does not recognise Java-style encodings Cp1141-Cp1149 In-Reply-To: <531109AE.2060203@oracle.com> References: <531109AE.2060203@oracle.com> Message-ID: <5311A306.8000402@oracle.com> On 28/02/2014 22:11, David Li wrote: > Hi, > > This is an update from Xerces for a fixed encoding map entry in file > EncodingMap.java. For details, please refer to: > https://bugs.openjdk.java.net/browse/JDK-8035469 > > Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035469/webrev/ > (I don't have a openjdk username yet, so Joe Wang uploaded it) > > No new tests since the change is minor. There were no tests from > Apache fixes. Maybe this is a question for Joe but I wonder if it would be possible to create a test that exercises these encodings? I realize the change is minor but it is also subtle and this maybe be an area where we should have better tests. -Alan From ali.ebrahimi1781 at gmail.com Sat Mar 1 10:17:52 2014 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Sat, 1 Mar 2014 13:47:52 +0330 Subject: Signature of MethodHandleInfo.reflectAs is not specific enough In-Reply-To: <11925E47-E9C3-4234-ADE5-0599CC71254B@oracle.com> References: <528008C9.7000905@univ-mlv.fr> <11925E47-E9C3-4234-ADE5-0599CC71254B@oracle.com> Message-ID: Hi, On Sat, Mar 1, 2014 at 12:16 AM, John Rose wrote: > On Feb 25, 2014, at 3:13 AM, Ali Ebrahimi > wrote: > > I know, this is too late, but I want to share my suggestion: > > public T reflectAs(Class super T> expected, MethodHandles.Lookup lookup) > > > Isn't this the same as > > public T reflectAs... > Oh, sorry, this is my bad. I mean this: public T reflectAs(Class expected, MethodHandles.Lookup lookup) > > I think we considered AccessibleObject but rejected it as not buying > anything significant compared with Member which is an interface. > > Perhaps > > public T reflectAs... > I considered this case, but unfortunately compiler accepts following test case with this signature: String ss = reflectAs(String.class, MethodHandles.lookup()); //OK!!!!!!! This seams as compiler bug, any way with compiler catches error. Finally, one case that compiler accepts with both signature is: Object mo = reflectAs(Object.class, MethodHandles.lookup()); Maybe I'm wrong for this, Dan Smith can better interpret this. T inferred to Object and T is not within its bound (AccessibleObject&Member). Regards, Ali Ebrahimi From yasu at ysfactory.dip.jp Sat Mar 1 14:07:06 2014 From: yasu at ysfactory.dip.jp (Yasumasa Suenaga) Date: Sat, 01 Mar 2014 23:07:06 +0900 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <53112019.9050504@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> Message-ID: <5311E98A.1020004@ysfactory.dip.jp> Hi David, > 1. Generating debug symbols in the binaries (via gcc -g or whatever) > 2. Generating debuginfo files (zipped or not) (FDS) > 3. Stripping debug symbols from the binaries (strip-policy) > > It may be that we don't have clean separation between them, and if so > that should be fixed, but I don't see the current proposal as the way > forward. Currently, 1. depends 2. If FDS set to disable, debug symbols (-g) are not generated. SEPARATED_DEBUGINFO_FILES which my patch provides can separate them. > Also there may well be differences between how things are handled on the > JDK side and hotspot side. libjvm, libjsig. libsaproc are built with each makefiles in hotspot/make . Other native library is built with make/common/NativeCompilation.gmk . Additionally strip command is executed in "image" target which is defined in jdk/make/Images.gmk . This "strip" ignores STRIP_POLICY . Thus ELF binaries which are contained in JDK/JRE images are stripped when we execute "images" or "all" target. So I change: 1. Separating to add "-g" option to compiler from executing objcopy. 2. jdk/make/Images.gmk regards STRIP_POLICY. As I mentioned earlier, this issue is related to RPM. So I hope to fix it before JDK8 GA is released. Thanks, Yasumasa On 2014/03/01 8:47, David Holmes wrote: > On 1/03/2014 1:38 AM, Yasumasa Suenaga wrote: >>> The proper way to fix this is to disable FDS. >> >> Does this mean I have to pass --disable-debug-symbols to configure ? >> I've added comment to JDK-8036003, I think if we pass --disable-debug-symbols >> to configure, gcc/g++ is not passed -g option. "-g" is needed to generate >> debuginfo. > > There are three pieces to all of this: > > 1. Generating debug symbols in the binaries (via gcc -g or whatever) > 2. Generating debuginfo files (zipped or not) (FDS) > 3. Stripping debug symbols from the binaries (strip-policy) > > It may be that we don't have clean separation between them, and if so > that should be fixed, but I don't see the current proposal as the way > forward. > > Also there may well be differences between how things are handled on the > JDK side and hotspot side. > > I will try to look closer if I get a chance but my time is limited at > the moment. > > David > >> >> Thanks, >> >> Yasumasa >> >> >> On 2014/02/28 23:04, Daniel D. Daugherty wrote: >>> The proper way to fix this is to disable FDS. We should not need >>> yet another option to control debug info. >>> >>> Dan >>> >>> >>> On 2/28/14 4:13 AM, David Holmes wrote: >>>> Hi, >>>> >>>> As I put in the bug report this seems way too complicated. Seems to me >>>> all you need to do to get what you want is not use FDS and not strip the >>>> symbols from the binary. The former is trivial. The latter is more >>>> awkward as the strip policy stuff does not work as I would want it to >>>> work, but still doable. >>>> >>>> David >>>> >>>> On 28/02/2014 7:18 PM, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> >>>>> Currently, configure script can accept --disable-debug-symbols and >>>>> --disable-zip-debug-info as controlling to generate debug information. >>>>> However, current makefiles cannot build ELF binaries which is contained >>>>> debug information with "images" target. >>>>> >>>>> Some Linux distros use RPM as package manager. >>>>> RPM is built by rpmbuild command, it strips symbols and debug information >>>>> during to generate rpm packages. >>>>> https://fedoraproject.org/wiki/Packaging:Debuginfo >>>>> >>>>> For example, OpenJDK8 in Fedora20 ships libjvm.so and libjvm.debuginfo . >>>>> libjvm.debuginfo is generated in OpenJDK's makefiles, however it does not >>>>> contain debug information. Actual debug information is shipped by OpenJDK >>>>> debuginfo package. >>>>> This packaging is important when we have to debug JVM/JNI libraries. >>>>> If we want to use debugging tools (GDB, SystemTap, etc...), they may requires >>>>> debuginfo package. Debuggee (e.g. libjvm.so) points libjvm.so.debug which is >>>>> located at sub directory in /usr/lib/debug . It is defined in ELF section >>>>> (.note.gnu.build-id) of libjvm.so . However libjvm.so.debug does not contain >>>>> valid debug information. We need to access libjvm.debuginfo.debug at same location. >>>>> >>>>> >>>>> When we think to build OpenJDK rpm packages, we have to build ELF binaries >>>>> which contain all debug information. we should not to separate debug information. >>>>> >>>>> >>>>> Thus I want to add a variable "SEPARATED_DEBUGINFO_FILES" . >>>>> If we pass "SEPARATED_DEBUGINFO_FILES=false" to make command, "make" does not >>>>> execute objcopy command for generating debuginfo binaries. >>>>> >>>>> If we build rpm packages, we also have to add "STRIP_POLICY=no_strip" to arguments >>>>> of make command. Or ELF binaries will be stripped. >>>>> >>>>> >>>>> I've uploaded webrev for this enhancement. >>>>> This is separated 3-part: top of forest, hotspot, jdk >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/ >>>>> >>>>> Please review it and sponsoring! >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> P.S. >>>>> I tried to add SEPARATED_DEBUGINFO_FILES as a configure option like >>>>> "--disable-separated-debug-info" . >>>>> I ran configure which is located at jdk9/dev directory after I ran autoconf >>>>> and common/autoconf/autogen.sh. However it failed. >>>>> >>>>> I guess this is caused by changeset as below. >>>>> JDK-8035495: Improvements in autoconf integration >>>>> http://hg.openjdk.java.net/jdk9/dev/rev/6e29cd9ac2b4 >>>>> >>>>> This changes add "CHECKME" option to configure script. However, this changes >>>>> affects "configure" only. It should change "configure.ac" . >>>>> >>> >> > From david.x.li at oracle.com Sat Mar 1 18:12:10 2014 From: david.x.li at oracle.com (David Li) Date: Sat, 01 Mar 2014 10:12:10 -0800 Subject: RFR (JAXP): 8035469 : Xerces Update: EncodingMap does not recognise Java-style encodings Cp1141-Cp1149 In-Reply-To: <5311A306.8000402@oracle.com> References: <531109AE.2060203@oracle.com> <5311A306.8000402@oracle.com> Message-ID: <531222FA.1060802@oracle.com> Joe probably knows more about this, but we did some preliminary investigation summarized below. One test that was considered was creating an XML file encoded in one of the formats and then seeing if the parser would process the file after our updates were added. This looked like it requires generating sample XML files with characters from the actual encoding, which we could not figure out in a reasonable amount of time. It's not sufficient to specify the encoding in the XML header (, also tried IBM01140) if all the text in the file is UTF-8, since the parser complains. It was decided that since the changes were minor, and the original Xerces bug did not include any tests or any way of reproducing the error, we would not spend too much time on the issue. For reference, the IBM01140-IBM01149 encodings look like various European languages: http://www.iana.org/assignments/character-sets/character-sets.xhtml. - David On 3/1/2014 1:06 AM, Alan Bateman wrote: > On 28/02/2014 22:11, David Li wrote: >> Hi, >> >> This is an update from Xerces for a fixed encoding map entry in file >> EncodingMap.java. For details, please refer to: >> https://bugs.openjdk.java.net/browse/JDK-8035469 >> >> Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035469/webrev/ >> (I don't have a openjdk username yet, so Joe Wang uploaded it) >> >> No new tests since the change is minor. There were no tests from >> Apache fixes. > Maybe this is a question for Joe but I wonder if it would be possible > to create a test that exercises these encodings? I realize the change > is minor but it is also subtle and this maybe be an area where we > should have better tests. > > -Alan From mike.duigou at oracle.com Sat Mar 1 23:08:56 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Sat, 1 Mar 2014 15:08:56 -0800 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <5311E98A.1020004@ysfactory.dip.jp> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <5311E98A.1020004@ysfactory.dip.jp> Message-ID: On Mar 1 2014, at 06:07 , Yasumasa Suenaga wrote: > Hi David, > >> 1. Generating debug symbols in the binaries (via gcc -g or whatever) >> 2. Generating debuginfo files (zipped or not) (FDS) >> 3. Stripping debug symbols from the binaries (strip-policy) >> >> It may be that we don't have clean separation between them, and if so >> that should be fixed, but I don't see the current proposal as the way >> forward. > > Currently, 1. depends 2. If FDS set to disable, debug symbols (-g) are not > generated. > SEPARATED_DEBUGINFO_FILES which my patch provides can separate them. I think David's list (kudos) is very helpful as I haven't seen the requirements articulated this clearly anywhere else. Some comments: - Are there important tools that cannot deal with external debuginfo files? If we can put debuginfo into external files why would we ever want unstripped binaries? Is strip policy really necessary? Strip policy would seem to only be necessary if there are tools which can't handle external debuginfo. Assuming that everything can use external debuginfo then the policy would be to strip everything. Do I understand correctly that rpmbuild can only deal with unstripped binaries and generates the stripped rpm package and debuginfo package. It sounds kind of strange that find-debuginfo.sh wouldn't be able to use already generated debuginfo files. - I would expect that the flow is something like an extended version of https://blogs.oracle.com/dbx/entry/creating_separate_debug_info : 1. Compile source files with some form of "-g" 2. Create separate debug files for object files. 3. Strip object files. 4. Add gnu_debuglink to object files. 5. Link library or executable which should carry along links to debuginfo. 6a. Debugging, testing, profiling, etc. by developers. 6b. Packaging for program bits and debuginfo. 7. Testing and Use. Hopefully I didn't get any of those steps in the wrong order. What are the "you-cant-get-there-from-here" gaps and breakdowns from implementing this process? - Whether for the FDS debug symbols or RPM debuginfo packaging it seems that the default debug level isn't quite right. I believe that in both cases what's wanted is abbreviated debug info, mostly function names and line number tables, for building stack traces. This is not the debug info that is currently generated. There are four basic alternatives for levels of debug info: 1. (-g0) No debug info whatsoever. Only exported functions and globals will have names. 2. (-g1) Abbreviated debug info. All functions have names and line number information. This seems to be what is needed by both FDS and RPM debuginfo files to produce nice stack traces. 3. (-g) Default debugging info. Adds macro expansions and local variable names. Suitable for source level debugging. 4. (-g3 or -gdwarf-4 -fvar-tracking-assignments). Full debugging info. Most suitable for source level debugging including debugging of optimized code. It is not clear that anyone would want to build the entire product with this option. Compilations are currently done with a mix of -g, -g1, and -gstabs. It would be good to rationalize this somewhat and provide a mechanism for developers to tweak generated debugging output for files or components. - Eventual alignment with http://gcc.gnu.org/wiki/DebugFission on some platforms? > So I change: > > 1. Separating to add "-g" option to compiler from executing objcopy. > 2. jdk/make/Images.gmk regards STRIP_POLICY. > > > As I mentioned earlier, this issue is related to RPM. > So I hope to fix it before JDK8 GA is released. This won't happen (at least not for Java 8u0). Java 8 is already late in it's final candidate stage. It is too late for the initial Java 8 release to consider this magnitude of change. In any event, since the Java 8 rampdown began back in November, any change would first have to be applied to Java 9 and then approved for backport to a Java 8 or an update release (and it is also possibly too late for 8u20). Inability to include your suggested change in Java 8 or 8u20 is in no way a rejection of the ideas or contribution, it's merely a normal consequence of timelines and process. Mike From Ulf.Zibis at CoSoCo.de Sun Mar 2 02:54:52 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sun, 02 Mar 2014 03:54:52 +0100 Subject: Unsafe: efficiently comparing two byte arrays In-Reply-To: References: <530F5136.20405@redhat.com> <8D3E2037-E5D1-4D2E-B779-E7EDD2AF4F58@oracle.com> <530F55CA.3060302@redhat.com> Message-ID: <53129D7C.4080406@CoSoCo.de> Am 28.02.2014 23:29, schrieb Martin Buchholz: > Are word-size reads in ByteBuffer actually intrinsified? I could find no > evidence for that. Perhaps this is an important missing optimization for > hotspot to make? > > I see DirectByteBuffer, but not garden-variety ByteBuffer, using Unsafe. > share/classes/java/nio/Direct-X-Buffer.java.template > > Probably should be investigated using disassembly of jitted code, which I > have never done. See also: https://bugs.openjdk.java.net/browse/JDK-6914113 -Ulf From ivan.gerasimov at oracle.com Sun Mar 2 07:58:39 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sun, 02 Mar 2014 11:58:39 +0400 Subject: RFR [7011804] SequenceInputStream with lots of empty substreams can cause StackOverflowError Message-ID: <5312E4AF.1010806@oracle.com> Hello! SequenceInputStream#read functions are implemented recursively. This may cause stack overflow in some extreme cases with lots of empty substreams. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/7011804 WEBREV: http://cr.openjdk.java.net/~igerasim/7011804/0/webrev/ Sincerely yours, Ivan From chris.hegarty at oracle.com Sun Mar 2 08:37:30 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sun, 2 Mar 2014 08:37:30 +0000 Subject: RFR [7011804] SequenceInputStream with lots of empty substreams can cause StackOverflowError In-Reply-To: <5312E4AF.1010806@oracle.com> References: <5312E4AF.1010806@oracle.com> Message-ID: The source changes look ok to me, but I can't imagine that anyone would run into this under normal circumstances. Quite trivially, I don't think the test needs to be run under othervm, especially with a fixed JDK. -Chris. > On 2 Mar 2014, at 07:58, Ivan Gerasimov wrote: > > Hello! > > SequenceInputStream#read functions are implemented recursively. > This may cause stack overflow in some extreme cases with lots of empty substreams. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/7011804 > WEBREV: http://cr.openjdk.java.net/~igerasim/7011804/0/webrev/ > > Sincerely yours, > Ivan From heinz at javaspecialists.eu Sun Mar 2 08:51:51 2014 From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz) Date: Sun, 02 Mar 2014 10:51:51 +0200 Subject: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods In-Reply-To: <53110B02.7070602@oracle.com> References: <53110B02.7070602@oracle.com> Message-ID: <5312F127.60903@javaspecialists.eu> With a curious 9 months old crawling around the house, I've just moved the sharp knives to the top draw in the kitchen - out of reach. I don't think we should be encouraging people to use monitor.tryLock() for various reasons: 1. We have a richer interface with Lock/ReentrantLock, including better Condition that allow easier timed wait idioms. 2. It is just too easy to get the idioms wrong for Lock.lock() and Lock.unlock(). Every time I show this idiom some people in the audience start arguing with me: lock.lock(); try { // do something } finally { lock.unlock(); } IMHO, this is really an edge case that might be useful to have semi-accessible at some point, but not something that should generally be done. It belongs in the same draw as the sharp knives and the ability to cause arbitrary asynchronous exceptions (which has been made more difficult to do in Java 8). Brian Goetz wrote: > Except that Lock has features that are not supported by intrinsic > locks (timed wait, interruptible wait.) So the Lock returned would > not conform to Lock's contract, and attempting to call these methods > would probably throw UOE. > > On 2/27/2014 6:12 AM, Stephen Colebourne wrote: >> On 26 February 2014 20:54, Martin Buchholz wrote: >>> It does seem that being able to tell whether a java object monitor is >>> currently locked is useful for debugging and monitoring - there >>> should be a >>> way to do that. >> >> Perhaps it would be useful to be able to expose a java object monitor >> as an instance of Lock? >> >> Lock lk = Lock.ofMonitor(object) >> if (lk.tryLock()) { >> ... >> } >> >> Such a method feels like it would be a useful missing link between >> synchronized and locks. >> >> Stephen >> > From ivan.gerasimov at oracle.com Sun Mar 2 09:02:06 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sun, 02 Mar 2014 13:02:06 +0400 Subject: RFR [7011804] SequenceInputStream with lots of empty substreams can cause StackOverflowError In-Reply-To: References: <5312E4AF.1010806@oracle.com> Message-ID: <5312F38E.6000704@oracle.com> Thank you Chris! On 02.03.2014 12:37, Chris Hegarty wrote: > The source changes look ok to me, but I can't imagine that anyone would run into this under normal circumstances. > > Quite trivially, I don't think the test needs to be run under othervm, especially with a fixed JDK. It was meant to be for unfixed JDK. Though, yes you're right - once the stack is unrolled, the VM again should be in a consistent state. So, no othervm should be required. I'll remove it. Sincerely yours, Ivan > -Chris. > >> On 2 Mar 2014, at 07:58, Ivan Gerasimov wrote: >> >> Hello! >> >> SequenceInputStream#read functions are implemented recursively. >> This may cause stack overflow in some extreme cases with lots of empty substreams. >> >> Would you please help review the fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/7011804 >> WEBREV: http://cr.openjdk.java.net/~igerasim/7011804/0/webrev/ >> >> Sincerely yours, >> Ivan > From Alan.Bateman at oracle.com Sun Mar 2 10:50:11 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 02 Mar 2014 10:50:11 +0000 Subject: RFR [7011804] SequenceInputStream with lots of empty substreams can cause StackOverflowError In-Reply-To: <5312E4AF.1010806@oracle.com> References: <5312E4AF.1010806@oracle.com> Message-ID: <53130CE3.50801@oracle.com> On 02/03/2014 07:58, Ivan Gerasimov wrote: > Hello! > > SequenceInputStream#read functions are implemented recursively. > This may cause stack overflow in some extreme cases with lots of empty > substreams. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/7011804 > WEBREV: http://cr.openjdk.java.net/~igerasim/7011804/0/webrev/ Thanks for taking one. I don't think this code has changed much since JDK 1.0 where it seems to have been originally implemented to use recursion. I'm dubious about the bug report and whether the usage is real or made-up to demonstrate the issue. In any case, the changes good to me. One comment in passing is that normally an InputStream read throws IOException when the stream is closed where as SIS returns EOF. There may be an opportunity to clarify the javadoc in a few places (not for this bug of course). The test looks okay. I agree with Chris that there shouldn't be a need to run it in its own VM. -Alan. From ivan.gerasimov at oracle.com Sun Mar 2 11:13:43 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sun, 02 Mar 2014 15:13:43 +0400 Subject: RFR [7011804] SequenceInputStream with lots of empty substreams can cause StackOverflowError In-Reply-To: <53130CE3.50801@oracle.com> References: <5312E4AF.1010806@oracle.com> <53130CE3.50801@oracle.com> Message-ID: <53131267.9090601@oracle.com> Thank you Alan! On 02.03.2014 14:50, Alan Bateman wrote: > On 02/03/2014 07:58, Ivan Gerasimov wrote: >> Hello! >> >> SequenceInputStream#read functions are implemented recursively. >> This may cause stack overflow in some extreme cases with lots of >> empty substreams. >> >> Would you please help review the fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/7011804 >> WEBREV: http://cr.openjdk.java.net/~igerasim/7011804/0/webrev/ > Thanks for taking one. I don't think this code has changed much since > JDK 1.0 where it seems to have been originally implemented to use > recursion. I'm dubious about the bug report and whether the usage is > real or made-up to demonstrate the issue. > It might also be easier for VM to optimize non-recursive code, if there is such a need. > In any case, the changes good to me. One comment in passing is that > normally an InputStream read throws IOException when the stream is > closed where as SIS returns EOF. There may be an opportunity to > clarify the javadoc in a few places (not for this bug of course). > > The test looks okay. I agree with Chris that there shouldn't be a need > to run it in its own VM. > Ok. I'll remove it. Sincerely yours, Ivan > -Alan. > > > From yasu at ysfactory.dip.jp Sun Mar 2 14:01:10 2014 From: yasu at ysfactory.dip.jp (Yasumasa Suenaga) Date: Sun, 02 Mar 2014 23:01:10 +0900 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <5311E98A.1020004@ysfactory.dip.jp> Message-ID: <531339A6.3050806@ysfactory.dip.jp> HI Mike, > - I would expect that the flow is something like an extended version of https://blogs.oracle.com/dbx/entry/creating_separate_debug_info : > 1. Compile source files with some form of "-g" > 2. Create separate debug files for object files. > 3. Strip object files. > 4. Add gnu_debuglink to object files. > 5. Link library or executable which should carry along links to debuginfo. > 6a. Debugging, testing, profiling, etc. by developers. > 6b. Packaging for program bits and debuginfo. > 7. Testing and Use. rpmbuild will execute 2 to 4 implicitly, Modern ELF binary has .note.gnu.build-id section. Debugging tools (e.g. GDB and SA in JDK) use this section for finding debuginfo files. If OpenJDK8 which is shipped by RPM is crashed and we want to analyze core image, we have to merge debuginfo and executable at first (e.g. eu-unstrip command). GDB and SA can find valid debuginfo through .note.gnu.debug-id or .gnu_debuglink section. But these tools can find /usr/lib/debug//.debug . They are cannot find *.debuginfo which are made by makefiles in OpenJDK tree. Yasumasa On 2014/03/02 8:08, Mike Duigou wrote: > > On Mar 1 2014, at 06:07 , Yasumasa Suenaga wrote: > >> Hi David, >> >>> 1. Generating debug symbols in the binaries (via gcc -g or whatever) >>> 2. Generating debuginfo files (zipped or not) (FDS) >>> 3. Stripping debug symbols from the binaries (strip-policy) >>> >>> It may be that we don't have clean separation between them, and if so >>> that should be fixed, but I don't see the current proposal as the way >>> forward. >> >> Currently, 1. depends 2. If FDS set to disable, debug symbols (-g) are not >> generated. >> SEPARATED_DEBUGINFO_FILES which my patch provides can separate them. > > I think David's list (kudos) is very helpful as I haven't seen the requirements articulated this clearly anywhere else. > > Some comments: > > - Are there important tools that cannot deal with external debuginfo files? If we can put debuginfo into external files why would we ever want unstripped binaries? Is strip policy really necessary? Strip policy would seem to only be necessary if there are tools which can't handle external debuginfo. Assuming that everything can use external debuginfo then the policy would be to strip everything. > > Do I understand correctly that rpmbuild can only deal with unstripped binaries and generates the stripped rpm package and debuginfo package. It sounds kind of strange that find-debuginfo.sh wouldn't be able to use already generated debuginfo files. > > - I would expect that the flow is something like an extended version of https://blogs.oracle.com/dbx/entry/creating_separate_debug_info : > 1. Compile source files with some form of "-g" > 2. Create separate debug files for object files. > 3. Strip object files. > 4. Add gnu_debuglink to object files. > 5. Link library or executable which should carry along links to debuginfo. > 6a. Debugging, testing, profiling, etc. by developers. > 6b. Packaging for program bits and debuginfo. > 7. Testing and Use. > > Hopefully I didn't get any of those steps in the wrong order. What are the "you-cant-get-there-from-here" gaps and breakdowns from implementing this process? > > - Whether for the FDS debug symbols or RPM debuginfo packaging it seems that the default debug level isn't quite right. I believe that in both cases what's wanted is abbreviated debug info, mostly function names and line number tables, for building stack traces. This is not the debug info that is currently generated. > > There are four basic alternatives for levels of debug info: > 1. (-g0) No debug info whatsoever. > Only exported functions and globals will have names. > 2. (-g1) Abbreviated debug info. > All functions have names and line number information. This seems to be what is needed by both FDS and RPM debuginfo files to produce nice stack traces. > 3. (-g) Default debugging info. > Adds macro expansions and local variable names. Suitable for source level debugging. > 4. (-g3 or -gdwarf-4 -fvar-tracking-assignments). Full debugging info. > Most suitable for source level debugging including debugging of optimized code. It is not clear that anyone would want to build the entire product with this option. > > Compilations are currently done with a mix of -g, -g1, and -gstabs. It would be good to rationalize this somewhat and provide a mechanism for developers to tweak generated debugging output for files or components. > > - Eventual alignment with http://gcc.gnu.org/wiki/DebugFission on some platforms? > >> So I change: >> >> 1. Separating to add "-g" option to compiler from executing objcopy. >> 2. jdk/make/Images.gmk regards STRIP_POLICY. >> >> >> As I mentioned earlier, this issue is related to RPM. >> So I hope to fix it before JDK8 GA is released. > > This won't happen (at least not for Java 8u0). Java 8 is already late in it's final candidate stage. It is too late for the initial Java 8 release to consider this magnitude of change. In any event, since the Java 8 rampdown began back in November, any change would first have to be applied to Java 9 and then approved for backport to a Java 8 or an update release (and it is also possibly too late for 8u20). > > Inability to include your suggested change in Java 8 or 8u20 is in no way a rejection of the ideas or contribution, it's merely a normal consequence of timelines and process. > > Mike From david.lloyd at redhat.com Sun Mar 2 16:58:31 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Sun, 02 Mar 2014 10:58:31 -0600 Subject: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods In-Reply-To: <5312F127.60903@javaspecialists.eu> References: <53110B02.7070602@oracle.com> <5312F127.60903@javaspecialists.eu> Message-ID: <53136337.9040001@redhat.com> Making the language Kindergarten-friendly at the cost of general usefulness is a mistake, IMO. And anyway there's nothing that is less safe about a Monitors class than ReentrantLock; on the other hand, monitors continue to be considerably lighter (size and (for most of the history of JUC) speed) by every measurement I've ever made. I would advise monitors over ReentrantLock 9 times out of 10 in any of our code. I just don't think your metaphors - neither of monitor methods being dangerous, nor of Java developers being infants - are really apt. On 03/02/2014 02:51 AM, Dr Heinz M. Kabutz wrote: > With a curious 9 months old crawling around the house, I've just moved > the sharp knives to the top draw in the kitchen - out of reach. I don't > think we should be encouraging people to use monitor.tryLock() for > various reasons: > > 1. We have a richer interface with Lock/ReentrantLock, including better > Condition that allow easier timed wait idioms. > > 2. It is just too easy to get the idioms wrong for Lock.lock() and > Lock.unlock(). Every time I show this idiom some people in the audience > start arguing with me: > > lock.lock(); > try { > // do something > } finally { > lock.unlock(); > } > > IMHO, this is really an edge case that might be useful to have > semi-accessible at some point, but not something that should generally > be done. It belongs in the same draw as the sharp knives and the > ability to cause arbitrary asynchronous exceptions (which has been made > more difficult to do in Java 8). > > Brian Goetz wrote: >> Except that Lock has features that are not supported by intrinsic >> locks (timed wait, interruptible wait.) So the Lock returned would >> not conform to Lock's contract, and attempting to call these methods >> would probably throw UOE. >> >> On 2/27/2014 6:12 AM, Stephen Colebourne wrote: >>> On 26 February 2014 20:54, Martin Buchholz wrote: >>>> It does seem that being able to tell whether a java object monitor is >>>> currently locked is useful for debugging and monitoring - there >>>> should be a >>>> way to do that. >>> >>> Perhaps it would be useful to be able to expose a java object monitor >>> as an instance of Lock? >>> >>> Lock lk = Lock.ofMonitor(object) >>> if (lk.tryLock()) { >>> ... >>> } >>> >>> Such a method feels like it would be a useful missing link between >>> synchronized and locks. >>> >>> Stephen >>> >> -- - DML From david.holmes at oracle.com Mon Mar 3 04:39:23 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 03 Mar 2014 14:39:23 +1000 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <5311E98A.1020004@ysfactory.dip.jp> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <5311E98A.1020004@ysfactory.dip.jp> Message-ID: <5314077B.9060908@oracle.com> Hi, On 2/03/2014 12:07 AM, Yasumasa Suenaga wrote: > Hi David, > >> 1. Generating debug symbols in the binaries (via gcc -g or whatever) >> 2. Generating debuginfo files (zipped or not) (FDS) >> 3. Stripping debug symbols from the binaries (strip-policy) >> >> It may be that we don't have clean separation between them, and if so >> that should be fixed, but I don't see the current proposal as the way >> forward. > > Currently, 1. depends 2. If FDS set to disable, debug symbols (-g) are not > generated. Okay. That would seem potentially inconvenient but not really critical. You simply enable FDS (the mere existence of the debuginfo files "shouldn't" cause a problem). Then you only need to address #3 - strip-policy. > SEPARATED_DEBUGINFO_FILES which my patch provides can separate them. > > >> Also there may well be differences between how things are handled on the >> JDK side and hotspot side. > > libjvm, libjsig. libsaproc are built with each makefiles in hotspot/make . > Other native library is built with make/common/NativeCompilation.gmk . > > Additionally strip command is executed in "image" target which is defined > in jdk/make/Images.gmk . This "strip" ignores STRIP_POLICY . Thus ELF binaries > which are contained in JDK/JRE images are stripped when we execute "images" > or "all" target. strip is also applied to the JVM libraries as part of the hotspot build. What occurs in the JDK "images" is additional to that.The hotspot build honors the STRIP_POLICY. It appears that STRIP_POLICY is not considered in the new build, though it was for the old. But perhaps I'm missing it somewhere in the autoconf settings? That aside it seems that you should be able to set POST_STRIP_CMD to "" avoid stripping. Moving forward I think we would need to expose the strip-policy via a configure option and have that pass STRIP_POLICY through to both hotspot and the Images target. > > So I change: > > 1. Separating to add "-g" option to compiler from executing objcopy. > 2. jdk/make/Images.gmk regards STRIP_POLICY. > > > As I mentioned earlier, this issue is related to RPM. > So I hope to fix it before JDK8 GA is released. As Mike said there is no chance of any changes to this getting into 8 GA. But if these are your own builds I'm not sure that is an issue anyway. That said, as per the above I think you can achieve what you want by enabling FDS but set STRIP_POLICY to none, and set POST_STRIP_CMD to empty. Thanks, David > > Thanks, > > Yasumasa > > > On 2014/03/01 8:47, David Holmes wrote: >> On 1/03/2014 1:38 AM, Yasumasa Suenaga wrote: >>>> The proper way to fix this is to disable FDS. >>> >>> Does this mean I have to pass --disable-debug-symbols to configure ? >>> I've added comment to JDK-8036003, I think if we pass --disable-debug-symbols >>> to configure, gcc/g++ is not passed -g option. "-g" is needed to generate >>> debuginfo. >> >> There are three pieces to all of this: >> >> 1. Generating debug symbols in the binaries (via gcc -g or whatever) >> 2. Generating debuginfo files (zipped or not) (FDS) >> 3. Stripping debug symbols from the binaries (strip-policy) >> >> It may be that we don't have clean separation between them, and if so >> that should be fixed, but I don't see the current proposal as the way >> forward. >> >> Also there may well be differences between how things are handled on the >> JDK side and hotspot side. >> >> I will try to look closer if I get a chance but my time is limited at >> the moment. >> >> David >> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2014/02/28 23:04, Daniel D. Daugherty wrote: >>>> The proper way to fix this is to disable FDS. We should not need >>>> yet another option to control debug info. >>>> >>>> Dan >>>> >>>> >>>> On 2/28/14 4:13 AM, David Holmes wrote: >>>>> Hi, >>>>> >>>>> As I put in the bug report this seems way too complicated. Seems to me >>>>> all you need to do to get what you want is not use FDS and not strip the >>>>> symbols from the binary. The former is trivial. The latter is more >>>>> awkward as the strip policy stuff does not work as I would want it to >>>>> work, but still doable. >>>>> >>>>> David >>>>> >>>>> On 28/02/2014 7:18 PM, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> >>>>>> Currently, configure script can accept --disable-debug-symbols and >>>>>> --disable-zip-debug-info as controlling to generate debug information. >>>>>> However, current makefiles cannot build ELF binaries which is contained >>>>>> debug information with "images" target. >>>>>> >>>>>> Some Linux distros use RPM as package manager. >>>>>> RPM is built by rpmbuild command, it strips symbols and debug information >>>>>> during to generate rpm packages. >>>>>> https://fedoraproject.org/wiki/Packaging:Debuginfo >>>>>> >>>>>> For example, OpenJDK8 in Fedora20 ships libjvm.so and libjvm.debuginfo . >>>>>> libjvm.debuginfo is generated in OpenJDK's makefiles, however it does not >>>>>> contain debug information. Actual debug information is shipped by OpenJDK >>>>>> debuginfo package. >>>>>> This packaging is important when we have to debug JVM/JNI libraries. >>>>>> If we want to use debugging tools (GDB, SystemTap, etc...), they may requires >>>>>> debuginfo package. Debuggee (e.g. libjvm.so) points libjvm.so.debug which is >>>>>> located at sub directory in /usr/lib/debug . It is defined in ELF section >>>>>> (.note.gnu.build-id) of libjvm.so . However libjvm.so.debug does not contain >>>>>> valid debug information. We need to access libjvm.debuginfo.debug at same location. >>>>>> >>>>>> >>>>>> When we think to build OpenJDK rpm packages, we have to build ELF binaries >>>>>> which contain all debug information. we should not to separate debug information. >>>>>> >>>>>> >>>>>> Thus I want to add a variable "SEPARATED_DEBUGINFO_FILES" . >>>>>> If we pass "SEPARATED_DEBUGINFO_FILES=false" to make command, "make" does not >>>>>> execute objcopy command for generating debuginfo binaries. >>>>>> >>>>>> If we build rpm packages, we also have to add "STRIP_POLICY=no_strip" to arguments >>>>>> of make command. Or ELF binaries will be stripped. >>>>>> >>>>>> >>>>>> I've uploaded webrev for this enhancement. >>>>>> This is separated 3-part: top of forest, hotspot, jdk >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/ >>>>>> >>>>>> Please review it and sponsoring! >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> P.S. >>>>>> I tried to add SEPARATED_DEBUGINFO_FILES as a configure option like >>>>>> "--disable-separated-debug-info" . >>>>>> I ran configure which is located at jdk9/dev directory after I ran autoconf >>>>>> and common/autoconf/autogen.sh. However it failed. >>>>>> >>>>>> I guess this is caused by changeset as below. >>>>>> JDK-8035495: Improvements in autoconf integration >>>>>> http://hg.openjdk.java.net/jdk9/dev/rev/6e29cd9ac2b4 >>>>>> >>>>>> This changes add "CHECKME" option to configure script. However, this changes >>>>>> affects "configure" only. It should change "configure.ac" . >>>>>> >>>> >>> >> > From david.holmes at oracle.com Mon Mar 3 06:52:57 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 03 Mar 2014 16:52:57 +1000 Subject: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods In-Reply-To: References: <530F31C1.8000604@oracle.com> Message-ID: <531426C9.1060308@oracle.com> On 27/02/2014 11:56 PM, Vitaly Davidovich wrote: > Right, there's no such guarantee/requirement. JVMS mentions that > implementations are permitted to enforce balance (called structured locking > there) but not required: > http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-2.html#jvms-2.11.10 And this proposal would make it impossible to enforce balanced locking. When we defined the Lock API we thought about whether/how Locks and built-in monitors might interact and the decision was to keep them completely distinct. David > Thanks > > Sent from my phone > On Feb 27, 2014 8:40 AM, "Jeroen Frijters" wrote: > >> David Holmes wrote: >>> I don't think this is workable. Exposing a monitor as Lock would allow >>> you to break the guarantees/requirements involving balanced-locking for >>> monitors. >> >> Where are these guarantees/requirements documented? >> >> Regards, >> Jeroen >> >> From aph at redhat.com Mon Mar 3 09:41:33 2014 From: aph at redhat.com (Andrew Haley) Date: Mon, 03 Mar 2014 09:41:33 +0000 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> Message-ID: <53144E4D.8080606@redhat.com> On 02/28/2014 09:18 AM, Yasumasa Suenaga wrote: > For example, OpenJDK8 in Fedora20 ships libjvm.so and libjvm.debuginfo . > libjvm.debuginfo is generated in OpenJDK's makefiles, however it does not > contain debug information. Actual debug information is shipped by OpenJDK > debuginfo package. That's a bug in Fedora's build. We should fix it. Andrew. From aph at redhat.com Mon Mar 3 09:46:38 2014 From: aph at redhat.com (Andrew Haley) Date: Mon, 03 Mar 2014 09:46:38 +0000 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <5311E98A.1020004@ysfactory.dip.jp> Message-ID: <53144F7E.5000105@redhat.com> On 03/01/2014 11:08 PM, Mike Duigou wrote: > Do I understand correctly that rpmbuild can only deal with > unstripped binaries and generates the stripped rpm package and > debuginfo package. Exactly. OpenJDK generating separate debuginfo files is very inconvenient for RPM builds. > It sounds kind of strange that find-debuginfo.sh wouldn't be able to > use already generated debuginfo files. The OpenJDK build can't have any idea of what debuginfo files the distro runtime requires, and indeed this may change. There is more than one mechanism for finding debuginfo. Separating debuginfo is not something that we want the OpenJDK build to do, and the most useful thing that we could have is a switch to turn all of OpenJDK's stripping and separate debuginfo off. I expect the same applies to all distros. Andrew. From vladimir.x.ivanov at oracle.com Mon Mar 3 10:31:40 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 03 Mar 2014 14:31:40 +0400 Subject: [9] RFR (M): 8027827: Improve performance of catchException combinator In-Reply-To: <059F4A27-AA9E-486E-82E6-1077B76AE524@oracle.com> References: <53052622.6010507@oracle.com> <0386E0D6-D515-4C2C-9D6E-DD3B53E8B3E2@oracle.com> <5306420B.9040200@oracle.com> <0516A100-6FAF-4718-8A9F-A82D7C7E7061@oracle.com> <530C6D26.4090000@oracle.com> <059F4A27-AA9E-486E-82E6-1077B76AE524@oracle.com> Message-ID: <53145A0C.5090608@oracle.com> Sigh, it's not so simple... I forgot about 8034120 [1]. The problem is that MH.invoke/invokeWithArguments have unpleasant effect for VarargsCollector. It introduces a difference in behavior between interpreting LF and executing compiled version. Filed 8036117 to track the problem. Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8034120 [2] https://bugs.openjdk.java.net/browse/JDK-8036117 On 2/28/14 12:39 AM, John Rose wrote: > On Feb 26, 2014, at 3:44 AM, Vladimir Ivanov > > wrote: > >>> >>> Maybe use invokeWithArguments with target and catcher? That at least is >>> a one-liner, and probably more efficient. >> >> Yes, that's a good idea! At least, it considerably simplifies the code. >> >> Updated webrev: >> http://cr.openjdk.java.net/~vlivanov/8027827/final/webrev.03/ > > Thumbs up. > > Your use of invokeWithArguments in the unspecialized code is a good > design pattern. The semantics are clear in the original method. This > in turn gives a clear basis for specializing for each combination of > argument arities and types. Specialization should be done using > low-level, high-leverage mechanisms like bytecode spinning or even JIT > optimizations. > > Put another way, if we have reasonable bytecode-generation intrinsics, > feeding to good JIT optimizations, we don't need top-level > specializations in the source code. The need for those has always been > a mark of weakness in the HotSpot implementation of MHs. (Fredrik's > JRockit implementation did it all in the JIT!) We will continue to push > down specializations to lower layers. > > ? John From yasu at ysfactory.dip.jp Mon Mar 3 12:04:51 2014 From: yasu at ysfactory.dip.jp (Yasumasa Suenaga) Date: Mon, 03 Mar 2014 21:04:51 +0900 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <5314077B.9060908@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <5311E98A.1020004@ysfactory.dip.jp> <5314077B.9060908@oracle.com> Message-ID: <53146FE3.9040205@ysfactory.dip.jp> Hi David, > Moving forward I think we would need to expose the strip-policy via a > configure option and have that pass STRIP_POLICY through to both hotspot > and the Images target. I want you to do so :-) Additionally, >>> 1. Generating debug symbols in the binaries (via gcc -g or whatever) >>> 2. Generating debuginfo files (zipped or not) (FDS) >>> 3. Stripping debug symbols from the binaries (strip-policy) I think that FDS should be separated 1 from 2. That is more useful for building OpenJDK. > That said, as per the above I think you can achieve what you > want by enabling FDS but set STRIP_POLICY to none, and set > POST_STRIP_CMD to empty. I tried: $ make images STRIP_POLICY=no_strip POST_STRIP_CMD="" I was able to get binaries which is included debug information. Thanks, Yasumasa On 2014/03/03 13:39, David Holmes wrote: > Hi, > > On 2/03/2014 12:07 AM, Yasumasa Suenaga wrote: >> Hi David, >> >>> 1. Generating debug symbols in the binaries (via gcc -g or whatever) >>> 2. Generating debuginfo files (zipped or not) (FDS) >>> 3. Stripping debug symbols from the binaries (strip-policy) >>> >>> It may be that we don't have clean separation between them, and if so >>> that should be fixed, but I don't see the current proposal as the way >>> forward. >> >> Currently, 1. depends 2. If FDS set to disable, debug symbols (-g) are not >> generated. > > Okay. That would seem potentially inconvenient but not really critical. > You simply enable FDS (the mere existence of the debuginfo files > "shouldn't" cause a problem). Then you only need to address #3 - > strip-policy. > >> SEPARATED_DEBUGINFO_FILES which my patch provides can separate them. >> >> >>> Also there may well be differences between how things are handled on the >>> JDK side and hotspot side. >> >> libjvm, libjsig. libsaproc are built with each makefiles in hotspot/make . >> Other native library is built with make/common/NativeCompilation.gmk . >> >> Additionally strip command is executed in "image" target which is defined >> in jdk/make/Images.gmk . This "strip" ignores STRIP_POLICY . Thus ELF binaries >> which are contained in JDK/JRE images are stripped when we execute "images" >> or "all" target. > > strip is also applied to the JVM libraries as part of the hotspot build. > What occurs in the JDK "images" is additional to that.The hotspot build > honors the STRIP_POLICY. > > It appears that STRIP_POLICY is not considered in the new build, though > it was for the old. But perhaps I'm missing it somewhere in the autoconf > settings? That aside it seems that you should be able to set > POST_STRIP_CMD to "" avoid stripping. > > Moving forward I think we would need to expose the strip-policy via a > configure option and have that pass STRIP_POLICY through to both hotspot > and the Images target. > >> >> So I change: >> >> 1. Separating to add "-g" option to compiler from executing objcopy. >> 2. jdk/make/Images.gmk regards STRIP_POLICY. >> >> >> As I mentioned earlier, this issue is related to RPM. >> So I hope to fix it before JDK8 GA is released. > > As Mike said there is no chance of any changes to this getting into 8 > GA. But if these are your own builds I'm not sure that is an issue > anyway. That said, as per the above I think you can achieve what you > want by enabling FDS but set STRIP_POLICY to none, and set > POST_STRIP_CMD to empty. > > Thanks, > David > >> >> Thanks, >> >> Yasumasa >> >> >> On 2014/03/01 8:47, David Holmes wrote: >>> On 1/03/2014 1:38 AM, Yasumasa Suenaga wrote: >>>>> The proper way to fix this is to disable FDS. >>>> >>>> Does this mean I have to pass --disable-debug-symbols to configure ? >>>> I've added comment to JDK-8036003, I think if we pass --disable-debug-symbols >>>> to configure, gcc/g++ is not passed -g option. "-g" is needed to generate >>>> debuginfo. >>> >>> There are three pieces to all of this: >>> >>> 1. Generating debug symbols in the binaries (via gcc -g or whatever) >>> 2. Generating debuginfo files (zipped or not) (FDS) >>> 3. Stripping debug symbols from the binaries (strip-policy) >>> >>> It may be that we don't have clean separation between them, and if so >>> that should be fixed, but I don't see the current proposal as the way >>> forward. >>> >>> Also there may well be differences between how things are handled on the >>> JDK side and hotspot side. >>> >>> I will try to look closer if I get a chance but my time is limited at >>> the moment. >>> >>> David >>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2014/02/28 23:04, Daniel D. Daugherty wrote: >>>>> The proper way to fix this is to disable FDS. We should not need >>>>> yet another option to control debug info. >>>>> >>>>> Dan >>>>> >>>>> >>>>> On 2/28/14 4:13 AM, David Holmes wrote: >>>>>> Hi, >>>>>> >>>>>> As I put in the bug report this seems way too complicated. Seems to me >>>>>> all you need to do to get what you want is not use FDS and not strip the >>>>>> symbols from the binary. The former is trivial. The latter is more >>>>>> awkward as the strip policy stuff does not work as I would want it to >>>>>> work, but still doable. >>>>>> >>>>>> David >>>>>> >>>>>> On 28/02/2014 7:18 PM, Yasumasa Suenaga wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> >>>>>>> Currently, configure script can accept --disable-debug-symbols and >>>>>>> --disable-zip-debug-info as controlling to generate debug information. >>>>>>> However, current makefiles cannot build ELF binaries which is contained >>>>>>> debug information with "images" target. >>>>>>> >>>>>>> Some Linux distros use RPM as package manager. >>>>>>> RPM is built by rpmbuild command, it strips symbols and debug information >>>>>>> during to generate rpm packages. >>>>>>> https://fedoraproject.org/wiki/Packaging:Debuginfo >>>>>>> >>>>>>> For example, OpenJDK8 in Fedora20 ships libjvm.so and libjvm.debuginfo . >>>>>>> libjvm.debuginfo is generated in OpenJDK's makefiles, however it does not >>>>>>> contain debug information. Actual debug information is shipped by OpenJDK >>>>>>> debuginfo package. >>>>>>> This packaging is important when we have to debug JVM/JNI libraries. >>>>>>> If we want to use debugging tools (GDB, SystemTap, etc...), they may requires >>>>>>> debuginfo package. Debuggee (e.g. libjvm.so) points libjvm.so.debug which is >>>>>>> located at sub directory in /usr/lib/debug . It is defined in ELF section >>>>>>> (.note.gnu.build-id) of libjvm.so . However libjvm.so.debug does not contain >>>>>>> valid debug information. We need to access libjvm.debuginfo.debug at same location. >>>>>>> >>>>>>> >>>>>>> When we think to build OpenJDK rpm packages, we have to build ELF binaries >>>>>>> which contain all debug information. we should not to separate debug information. >>>>>>> >>>>>>> >>>>>>> Thus I want to add a variable "SEPARATED_DEBUGINFO_FILES" . >>>>>>> If we pass "SEPARATED_DEBUGINFO_FILES=false" to make command, "make" does not >>>>>>> execute objcopy command for generating debuginfo binaries. >>>>>>> >>>>>>> If we build rpm packages, we also have to add "STRIP_POLICY=no_strip" to arguments >>>>>>> of make command. Or ELF binaries will be stripped. >>>>>>> >>>>>>> >>>>>>> I've uploaded webrev for this enhancement. >>>>>>> This is separated 3-part: top of forest, hotspot, jdk >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/ >>>>>>> >>>>>>> Please review it and sponsoring! >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> P.S. >>>>>>> I tried to add SEPARATED_DEBUGINFO_FILES as a configure option like >>>>>>> "--disable-separated-debug-info" . >>>>>>> I ran configure which is located at jdk9/dev directory after I ran autoconf >>>>>>> and common/autoconf/autogen.sh. However it failed. >>>>>>> >>>>>>> I guess this is caused by changeset as below. >>>>>>> JDK-8035495: Improvements in autoconf integration >>>>>>> http://hg.openjdk.java.net/jdk9/dev/rev/6e29cd9ac2b4 >>>>>>> >>>>>>> This changes add "CHECKME" option to configure script. However, this changes >>>>>>> affects "configure" only. It should change "configure.ac" . >>>>>>> >>>>> >>>> >>> >> > From yasu at ysfactory.dip.jp Mon Mar 3 12:04:59 2014 From: yasu at ysfactory.dip.jp (Yasumasa Suenaga) Date: Mon, 03 Mar 2014 21:04:59 +0900 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <53144F7E.5000105@redhat.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <5311E98A.1020004@ysfactory.dip.jp> <53144F7E.5000105@redhat.com> Message-ID: <53146FEB.8050300@ysfactory.dip.jp> Hi Andrew, > Separating debuginfo is not > something that we want the OpenJDK build to do, and the most useful > thing that we could have is a switch to turn all of OpenJDK's > stripping and separate debuginfo off. I expect the same applies to > all distros. My patch provides "SEPARATED_DEBUGINFO_FILES" as a switch of separating debuginfo files, and affects "STRIP_POILCY" in HotSpot and other ELF binaries. > I expect the same applies to all distros. We need to pass ' STRIP_POLICY=no_strip POST_STRIP_CMD="" ' to make command as David said. And we need to pick up binaries which are NOT named ".debuginfo" or ".diz" suffix. Thanks, Yasumasa On 2014/03/03 18:46, Andrew Haley wrote: > On 03/01/2014 11:08 PM, Mike Duigou wrote: > >> Do I understand correctly that rpmbuild can only deal with >> unstripped binaries and generates the stripped rpm package and >> debuginfo package. > > Exactly. OpenJDK generating separate debuginfo files is very > inconvenient for RPM builds. > >> It sounds kind of strange that find-debuginfo.sh wouldn't be able to >> use already generated debuginfo files. > > The OpenJDK build can't have any idea of what debuginfo files the > distro runtime requires, and indeed this may change. There is more > than one mechanism for finding debuginfo. Separating debuginfo is not > something that we want the OpenJDK build to do, and the most useful > thing that we could have is a switch to turn all of OpenJDK's > stripping and separate debuginfo off. I expect the same applies to > all distros. > > Andrew. > From dmitry.degrave at oracle.com Mon Mar 3 12:21:28 2014 From: dmitry.degrave at oracle.com (dmeetry degrave) Date: Mon, 03 Mar 2014 16:21:28 +0400 Subject: [7u backport] RFR: 7122142: (ann) Race condition between isAnnotationPresent and getAnnotations In-Reply-To: <20140227134411.GH4321@oracle.com> References: <53089694.4070308@oracle.com> <530B3E32.7020303@gmail.com> <530BB2F6.2000507@oracle.com> <20140227134411.GH4321@oracle.com> Message-ID: <531473C8.3070009@oracle.com> Hi all, I would like to ask someone with a reviewer status in jdk7u project to look at these changes. thanks, dmeetry On 02/27/2014 05:44 PM, Joel Borggren-Franck wrote: > Hi, > > I looked at webrev.1. Looks good. > > cheers > /Joel > > On 2014-02-25, dmeetry degrave wrote: >> Thanks for looking at this, Peter! >> >> On 02/24/2014 04:42 PM, Peter Levart wrote: >>> Hi Dmeetry, >>> >>> On 02/22/2014 01:22 PM, dmeetry degrave wrote: >>>> Hi all, >>>> >>>> I would like to ask for a review of combined back port for >>>> 7u-dev/7u80. The main goal is to have a fix for 7122142 in jdk7, it >>>> also integrates the changes from 8005232, 7185456, 8022721 >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-7122142 >>>> https://bugs.openjdk.java.net/browse/JDK-8005232 >>>> https://bugs.openjdk.java.net/browse/JDK-7185456 >>>> https://bugs.openjdk.java.net/browse/JDK-8022721 >>>> >>>> Original jdk8 changes: >>>> >>>> 7122142: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4ce6502eac0 >>>> 8005232: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1109bfff4e92 >>>> 7185456: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ae03282ba501 >>>> 8022721: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2281a7f79738 >>>> >>>> back port: >>>> >>>> http://cr.openjdk.java.net/~dmeetry/7122142.8005232.7185456.8022721/webrev.0/ >>>> >>>> >>>> Patches can't be applied cleanly, hence it was a manual back port, >>>> though the final result is equivalent to applying the patches in >>>> chronological order (8005232, 7185456, 7122142, 8022721) and applying >>>> all the relevant rejected parts >>> >>> It's good to see those patches being back-ported to 7u. By browsing the >>> webrev, I don't see any obvious difference between the original patches >>> and the backport. >> >> there shouldn't be any! >> >>> Do you happen to remember in what part of code there >>> were rejects so that you had to manually apply the changes? >> >> there were conflicts due to small difference between 7 and 8 >> (copyrights, white spaces, @SuppressWarnings, Class,...). >> >> I copied all rejected parts and original patches here: >> >> http://cr.openjdk.java.net/~dmeetry/7122142.8005232.7185456.8022721/webrev.1/rej/ >> >>>> (with one exception, AnnotationTypeRuntimeAssumptionTest.java test was >>>> not included due to jdk8 API). >>> >>> Ah, It's the Class.getDeclaredAnnotation(Class) that's new in JDK8. >>> Here's the changed test that only uses the JDK7 API so you can include >>> this test too: >>> >>> http://cr.openjdk.java.net/~plevart/jdk7u/7122142/AnnotationTypeRuntimeAssumptionTest.java >> >> Thanks! >> >> http://cr.openjdk.java.net/~dmeetry/7122142.8005232.7185456.8022721/webrev.1/ >> >> (just with the new test added). >> >> thanks, >> dmeetry >>>> >>>> All tests in test/java/lang/annotation passed. >>>> >>>> thanks, >>>> dmeetry >>> >>> Regards, Peter >>> From david.lloyd at redhat.com Mon Mar 3 12:56:49 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 03 Mar 2014 06:56:49 -0600 Subject: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods In-Reply-To: <53137CE2.1010102@javaspecialists.eu> References: <53110B02.7070602@oracle.com> <5312F127.60903@javaspecialists.eu> <53136337.9040001@redhat.com> <53137CE2.1010102@javaspecialists.eu> Message-ID: <53147C11.1010906@redhat.com> Yes, that would necessarily be the contract of a Monitors class, just as it is part of the contract of Lock today. If your argument is that it shouldn't be allowed because it might be used wrong, we might as well just delete most of the JDK, ReentrantLock included, since it suffers from the exact same potential problem. The difference is that monitors have a simple API in the form of synchronized that people were in the past and would continue to be free (and recommended) to use. I would not call recommending monitors to be a "premature optimization". The memory overhead of ReentrantLock is far too large for many use cases, especially when it comes to fine-grained locking of large data sets. In fact I would *only* recommend Lock if your need for the extra behavior it provides (i.e., multiple conditions, tryLock, timed tryLock, and/or interruptible locking) or for the extra behavior provided by ReentrantLock itself (i.e., lock status introspection) outweighs the cost of its memory consumption, which so far has happened zero times in any of the many frameworks I maintain. On the other hand, adding some of the missing functionality to a Monitors class would be pretty handy, especially if doing so doesn't create a large divergence from the existing implementation. Given that tryMonitorEnter already exists, implementing that method on a Monitors class seems fairly trivial, which already takes care of one out of the four special use cases for Locks. Interruptible locking would be my first choice for a number two, if this idea were actually officially on the table. Finally, an isMonitorHeld() method would tie in another branch of the discussion nicely and seems trivially possible as well. Any other information would be a purely It's worth noting that it's already possible for user code to implement the basic functionality using JNI methods, though in the interest of full disclosure it's worth noting that the enter/exit monitor JNI functions are forbidden by spec to interoperate with the corresponding bytecodes. FWIW using the word "monitor" instead of "lock" may help avoid confusion and "scare off" those pesky undergrads. On 03/02/2014 12:48 PM, Dr Heinz M. Kabutz wrote: > Hi Dave, > > "lighter" is subject to the HotSpot Profiler doing the optimizations > that you expect. Problem is, once you begin manually locking / > unlocking monitors, the byte codes are not recognizable as standard > synchronized(monitor) {} code, thus the optimizations will also not be > as good (or completely absent). At least that has been my experience > when I tried it out a few years ago. So the argument that synchronized > is faster than ReentrantLock, besides this being IMHO a premature > optimization, cannot be directly applied to when we manually do use the > monitorEnter/monitorExit methods. > > The reason why I personally think they are more dangerous than > ReentrantLock is that we are used to synchronized() {} taking care of > the unlocking for us. If we see a thread that is in the BLOCKED state > (which only happens with synchronized) then we would typically assume > that another thread is /currently /holding the monitor. > > Take the following example code: > > import sun.misc.*; > > import java.lang.reflect.*; > > public class MonitorMystery { > public static Unsafe getUnsafe() { > try { > for (Field field : Unsafe.class.getDeclaredFields()) { > if (Modifier.isStatic(field.getModifiers())) { > if (field.getType() == Unsafe.class) { > field.setAccessible(true); > return (Unsafe) field.get(null); > } > } > } > throw new IllegalStateException("Unsafe field not found"); > } catch (Exception e) { > throw new IllegalStateException( > "Could not initialize unsafe", e); > } > } > > public static void main(String... args) throws InterruptedException { > Thread t = new Thread() { > public void run() { > getUnsafe().monitorEnter(MonitorMystery.class); > } > }; > t.start(); > Thread.sleep(100); > System.out.println("Trying to synchronize"); > synchronized (MonitorMystery.class) { > System.out.println("Managed to synchronized"); > } > } > } > > We now see that we never manage to synchronize in the main thread and in > fact if you do a thread dump you will see a deadlock involving only a > single thread :-) > > This is why it is so important to use the correct idioms. In my > experience, there are very few Java programmers who get this right. > Brian Goetz's book is correct, but there are other books out there that > do a shocking job of mangling the idiom. > > Whenever possible, use synchronized() { }. If not, IMHO it would be > preferable to switch to ReentrantLock. > > Regards > > Heinz > -- > Dr Heinz M. Kabutz (PhD CompSci) > Author of "The Java(tm) Specialists' Newsletter" > Oracle Java Champion 2005-2013 > JavaOne Rock Star Speaker 2012 > http://www.javaspecialists.eu > Tel: +30 69 75 595 262 > Skype: kabutz > > > > David M. Lloyd wrote: >> Making the language Kindergarten-friendly at the cost of general >> usefulness is a mistake, IMO. And anyway there's nothing that is less >> safe about a Monitors class than ReentrantLock; on the other hand, >> monitors continue to be considerably lighter (size and (for most of >> the history of JUC) speed) by every measurement I've ever made. I >> would advise monitors over ReentrantLock 9 times out of 10 in any of >> our code. >> >> I just don't think your metaphors - neither of monitor methods being >> dangerous, nor of Java developers being infants - are really apt. >> >> On 03/02/2014 02:51 AM, Dr Heinz M. Kabutz wrote: >>> With a curious 9 months old crawling around the house, I've just moved >>> the sharp knives to the top draw in the kitchen - out of reach. I don't >>> think we should be encouraging people to use monitor.tryLock() for >>> various reasons: >>> >>> 1. We have a richer interface with Lock/ReentrantLock, including better >>> Condition that allow easier timed wait idioms. >>> >>> 2. It is just too easy to get the idioms wrong for Lock.lock() and >>> Lock.unlock(). Every time I show this idiom some people in the audience >>> start arguing with me: >>> >>> lock.lock(); >>> try { >>> // do something >>> } finally { >>> lock.unlock(); >>> } >>> >>> IMHO, this is really an edge case that might be useful to have >>> semi-accessible at some point, but not something that should generally >>> be done. It belongs in the same draw as the sharp knives and the >>> ability to cause arbitrary asynchronous exceptions (which has been made >>> more difficult to do in Java 8). >>> >>> Brian Goetz wrote: >>>> Except that Lock has features that are not supported by intrinsic >>>> locks (timed wait, interruptible wait.) So the Lock returned would >>>> not conform to Lock's contract, and attempting to call these methods >>>> would probably throw UOE. >>>> >>>> On 2/27/2014 6:12 AM, Stephen Colebourne wrote: >>>>> On 26 February 2014 20:54, Martin Buchholz >>>>> wrote: >>>>>> It does seem that being able to tell whether a java object monitor is >>>>>> currently locked is useful for debugging and monitoring - there >>>>>> should be a >>>>>> way to do that. >>>>> >>>>> Perhaps it would be useful to be able to expose a java object monitor >>>>> as an instance of Lock? >>>>> >>>>> Lock lk = Lock.ofMonitor(object) >>>>> if (lk.tryLock()) { >>>>> ... >>>>> } >>>>> >>>>> Such a method feels like it would be a useful missing link between >>>>> synchronized and locks. >>>>> >>>>> Stephen >>>>> >>>> >> >> -- - DML From david.lloyd at redhat.com Mon Mar 3 12:57:26 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 03 Mar 2014 06:57:26 -0600 Subject: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods In-Reply-To: <530F31C1.8000604@oracle.com> References: <530F31C1.8000604@oracle.com> Message-ID: <53147C36.9090500@redhat.com> On 02/27/2014 06:38 AM, David Holmes wrote: > On 27/02/2014 9:12 PM, Stephen Colebourne wrote: >> On 26 February 2014 20:54, Martin Buchholz wrote: >>> It does seem that being able to tell whether a java object monitor is >>> currently locked is useful for debugging and monitoring - there >>> should be a >>> way to do that. >> >> Perhaps it would be useful to be able to expose a java object monitor >> as an instance of Lock? >> >> Lock lk = Lock.ofMonitor(object) >> if (lk.tryLock()) { >> ... >> } >> >> Such a method feels like it would be a useful missing link between >> synchronized and locks. > > I don't think this is workable. Exposing a monitor as Lock would allow > you to break the guarantees/requirements involving balanced-locking for > monitors. The JNI APIs also allow this, do they not? -- - DML From daniel.daugherty at oracle.com Mon Mar 3 14:56:38 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 03 Mar 2014 07:56:38 -0700 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <5311E98A.1020004@ysfactory.dip.jp> Message-ID: <53149826.7030106@oracle.com> I think we're having a problem with not all replies making it to all the aliases. Yasumasa's reply to David below that Mike is replying to did not arrive on any of the aliases that I'm on... Folks need to remember to reply to all of the aliases... On 3/1/14 4:08 PM, Mike Duigou wrote: > On Mar 1 2014, at 06:07 , Yasumasa Suenaga wrote: > >> Hi David, >> >>> 1. Generating debug symbols in the binaries (via gcc -g or whatever) >>> 2. Generating debuginfo files (zipped or not) (FDS) >>> 3. Stripping debug symbols from the binaries (strip-policy) >>> >>> It may be that we don't have clean separation between them, and if so >>> that should be fixed, but I don't see the current proposal as the way >>> forward. >> Currently, 1. depends 2. If FDS set to disable, debug symbols (-g) are not >> generated. Bit of history here. When FDS is disabled, the build system is supposed to go back to what was there prior to the FDS project. On Linux, one of the debug configs didn't actually have any debugging flags enabled (debug or fastdebug, I don't remember which). So when I implemented FDS, disabling FDS meant no debug info. Bug in the original? You betcha. >> SEPARATED_DEBUGINFO_FILES which my patch provides can separate them. > I think David's list (kudos) is very helpful as I haven't seen the requirements articulated this clearly anywhere else. > > Some comments: > > - Are there important tools that cannot deal with external debuginfo files? Not that I'm aware of. There have been bugs in the way gobjcopy is extracting the debuginfo into the separate files, but no complete failures as far as I know... > If we can put debuginfo into external files why would we ever want unstripped binaries? We deliver minimal stripped binaries so that can have stack traces with some amount of information in them when the debuginfo files are not available. We have not yet figured out how to implement minimal stripping on Windows so Windows hs_err_pid files have no symbols in them when the debuginfo bundles are not present. > Is strip policy really necessary? Yes. STRIP_POLICY allows folks to configure what they want for the build that they are doing. It is also meant to map to the Oracle policy where we were granted a waiver to deliver minimal symbols in FDS project. > Strip policy would seem to only be necessary if there are tools which can't handle external debuginfo. Assuming that everything can use external debuginfo then the policy would be to strip everything. No you don't want to strip everything. See above aboutminimal info in stack traces. > Do I understand correctly that rpmbuild can only deal with unstripped binaries and generates the stripped rpm package and debuginfo package. It sounds kind of strange that find-debuginfo.sh wouldn't be able to use already generated debuginfo files. > > - I would expect that the flow is something like an extended version of https://blogs.oracle.com/dbx/entry/creating_separate_debug_info : > 1. Compile source files with some form of "-g" > 2. Create separate debug files for object files. > 3. Strip object files. > 4. Add gnu_debuglink to object files. > 5. Link library or executable which should carry along links to debuginfo. > 6a. Debugging, testing, profiling, etc. by developers. > 6b. Packaging for program bits and debuginfo. > 7. Testing and Use. > > Hopefully I didn't get any of those steps in the wrong order. What are the "you-cant-get-there-from-here" gaps and breakdowns from implementing this process? > > - Whether for the FDS debug symbols or RPM debuginfo packaging it seems that the default debug level isn't quite right. I believe that in both cases what's wanted is abbreviated debug info, mostly function names and line number tables, for building stack traces. This is not the debug info that is currently generated. It's STRIP_POLICY=min_strip that leaves the minimal debug info attached to the binaries and the more complete debug info in left in the debuginfo file(s). And I'll disagree about only wanting abbreviated debug info in the separate debuginfo files. > There are four basic alternatives for levels of debug info: > 1. (-g0) No debug info whatsoever. > Only exported functions and globals will have names. > 2. (-g1) Abbreviated debug info. > All functions have names and line number information. This seems to be what is needed by both FDS and RPM debuginfo files to produce nice stack traces. > 3. (-g) Default debugging info. > Adds macro expansions and local variable names. Suitable for source level debugging. > 4. (-g3 or -gdwarf-4 -fvar-tracking-assignments). Full debugging info. > Most suitable for source level debugging including debugging of optimized code. It is not clear that anyone would want to build the entire product with this option. > > Compilations are currently done with a mix of -g, -g1, and -gstabs. It would be good to rationalize this somewhat and provide a mechanism for developers to tweak generated debugging output for files or components. There is a whole boatload of history behind using STABS or DWARF or -g1 and usually (at least in HotSpot) there are comments in the Makefiles explaining the sometimes arcane reasons why these choices were made... On Linux there is a special option DEBUG_BINARIES that is used to specify '-g' for everything. I believe the magic incantation for making RPM happy is something like: DEBUG_BINARIES=true FULL_DEBUG_SYMBOLS=0 STRIP_POLICY=none ALT_OBJCOPY=/does_not_exist The combination of FULL_DEBUG_SYMBOLS=0 and ALT_OBJCOPY=/does_not_exist disables FDS for all build configs and reverts to pre-FDS make logic. STRIP_POLICY=none says don't do any stripping. DEBUG_BINARIES=true says ignore all the other logic about which debug options and just do '-g'. I've accidentally broken DEBUG_BINARIES at least once, but I usually get pinged by the Red Hat folks when I do... Dan > - Eventual alignment with http://gcc.gnu.org/wiki/DebugFission on some platforms? > >> So I change: >> >> 1. Separating to add "-g" option to compiler from executing objcopy. >> 2. jdk/make/Images.gmk regards STRIP_POLICY. >> >> >> As I mentioned earlier, this issue is related to RPM. >> So I hope to fix it before JDK8 GA is released. > This won't happen (at least not for Java 8u0). Java 8 is already late in it's final candidate stage. It is too late for the initial Java 8 release to consider this magnitude of change. In any event, since the Java 8 rampdown began back in November, any change would first have to be applied to Java 9 and then approved for backport to a Java 8 or an update release (and it is also possibly too late for 8u20). > > Inability to include your suggested change in Java 8 or 8u20 is in no way a rejection of the ideas or contribution, it's merely a normal consequence of timelines and process. > > Mike From huizhe.wang at oracle.com Mon Mar 3 16:58:21 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 03 Mar 2014 08:58:21 -0800 Subject: RFR (JAXP): 8035469 : Xerces Update: EncodingMap does not recognise Java-style encodings Cp1141-Cp1149 In-Reply-To: <531222FA.1060802@oracle.com> References: <531109AE.2060203@oracle.com> <5311A306.8000402@oracle.com> <531222FA.1060802@oracle.com> Message-ID: <5314B4AD.3070603@oracle.com> Hi Alan and all, Thanks for bringing up the testing issue. For the Xerces Update project, I'd like to share our process for adding or creating tests. The basis of the process is that, with understanding that the Xerces release have been out for over 3 years and patches were generally verified by users, we trust the quality of the source. We will carefully verify the changes, run regression tests, and add additional tests where necessary. 1) If tests were attached to a fixed issue, they should be brought in, converted to OpenJDK format; 2) If tests were described in the original bug report, create a test based upon it; 3) Create tests or verify existing tests if there is a conflict, or overlapping changeset while merging the sources; 4) Create tests if compatibility is a concern 5) If there was no test in Xerces report, we may skip adding new tests if changes were minor or obvious (e.g. typo). I would think JDK-8035469 falls into the last category. In terms of improving the coverage of encoding mapping, we can bring it up with SQE team. Thanks, Joe On 3/1/2014 10:12 AM, David Li wrote: > Joe probably knows more about this, but we did some preliminary > investigation summarized below. > > One test that was considered was creating an XML file encoded in one > of the formats and then seeing if the parser would process the file > after our updates were added. This looked like it requires generating > sample XML files with characters from the actual encoding, which we > could not figure out in a reasonable amount of time. It's not > sufficient to specify the encoding in the XML header ( version=\"1.0\" encoding=\"CP1140\"?>, also tried IBM01140) if all the > text in the file is UTF-8, since the parser complains. It was decided > that since the changes were minor, and the original Xerces bug did not > include any tests or any way of reproducing the error, we would not > spend too much time on the issue. For reference, the > IBM01140-IBM01149 encodings look like various European languages: > http://www.iana.org/assignments/character-sets/character-sets.xhtml. > > - David > > On 3/1/2014 1:06 AM, Alan Bateman wrote: >> On 28/02/2014 22:11, David Li wrote: >>> Hi, >>> >>> This is an update from Xerces for a fixed encoding map entry in file >>> EncodingMap.java. For details, please refer to: >>> https://bugs.openjdk.java.net/browse/JDK-8035469 >>> >>> Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035469/webrev/ >>> (I don't have a openjdk username yet, so Joe Wang uploaded it) >>> >>> No new tests since the change is minor. There were no tests from >>> Apache fixes. >> Maybe this is a question for Joe but I wonder if it would be possible >> to create a test that exercises these encodings? I realize the change >> is minor but it is also subtle and this maybe be an area where we >> should have better tests. >> >> -Alan > From omajid at redhat.com Mon Mar 3 19:01:03 2014 From: omajid at redhat.com (Omair Majid) Date: Mon, 3 Mar 2014 14:01:03 -0500 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <53144E4D.8080606@redhat.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53144E4D.8080606@redhat.com> Message-ID: <20140303190102.GE2045@redhat.com> * Andrew Haley [2014-03-03 04:43]: > On 02/28/2014 09:18 AM, Yasumasa Suenaga wrote: > > For example, OpenJDK8 in Fedora20 ships libjvm.so and libjvm.debuginfo . > > libjvm.debuginfo is generated in OpenJDK's makefiles, however it does not > > contain debug information. Actual debug information is shipped by OpenJDK > > debuginfo package. > > That's a bug in Fedora's build. We should fix it. This should fix it: http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/commit/?id=1734315551d634b7467f28788d90595b467ea5eb Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From omajid at redhat.com Mon Mar 3 19:11:18 2014 From: omajid at redhat.com (Omair Majid) Date: Mon, 3 Mar 2014 14:11:18 -0500 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <53149826.7030106@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <5311E98A.1020004@ysfactory.dip.jp> <53149826.7030106@oracle.com> Message-ID: <20140303191118.GF2045@redhat.com> Hi, * Daniel D. Daugherty [2014-03-03 09:57]: > On 3/1/14 4:08 PM, Mike Duigou wrote: > > If we can put debuginfo into external files why would we ever want unstripped binaries? > > We deliver minimal stripped binaries so that can have stack traces > with some amount of information in them when the debuginfo files > are not available. We have not yet figured out how to implement > minimal stripping on Windows so Windows hs_err_pid files have no > symbols in them when the debuginfo bundles are not present. Am I reading it right that when tools (like RPM) strip the debug information from these binaries, hotspot will break completely when it tries to generate a stack trace on crash? Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From daniel.daugherty at oracle.com Mon Mar 3 19:20:38 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 03 Mar 2014 12:20:38 -0700 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <20140303191118.GF2045@redhat.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <5311E98A.1020004@ysfactory.dip.jp> <53149826.7030106@oracle.com> <20140303191118.GF2045@redhat.com> Message-ID: <5314D606.70804@oracle.com> On 3/3/14 12:11 PM, Omair Majid wrote: > Hi, > > * Daniel D. Daugherty [2014-03-03 09:57]: >> On 3/1/14 4:08 PM, Mike Duigou wrote: >>> If we can put debuginfo into external files why would we ever want unstripped binaries? >> We deliver minimal stripped binaries so that can have stack traces >> with some amount of information in them when the debuginfo files >> are not available. We have not yet figured out how to implement >> minimal stripping on Windows so Windows hs_err_pid files have no >> symbols in them when the debuginfo bundles are not present. > Am I reading it right that when tools (like RPM) strip the debug > information from these binaries, hotspot will break completely when it > tries to generate a stack trace on crash? Not quite. If you follow this process: - use gobjcopy to copy debug info from libjvm.so -> libjvm.debuginfo - use gobjcopy to tell libjvm.so that debug info is found in libjvm.debuginfo - strip libjvm.so (I don't remember the strip everything option) then you can still get symbols in your crashes as long as you have BOTH libjvm.so and libjvm.debuginfo. However, if you are in a situation where you don't have libjvm.debuginfo, then you do not get symbols in your crashes. When I did the Full Debug Symbols (FDS) project, I copied complete debug info from libjvm.so -> libjvm.debuginfo and left minimal debug info in libjvm.so so that you could still get symbols on crashes on Linux and Solaris when the libjvm.debuginfo files were not present. Dan > > Thanks, > Omair > From mark.reinhold at oracle.com Mon Mar 3 19:26:47 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 3 Mar 2014 11:26:47 -0800 (PST) Subject: JEP 193: Enhanced Volatiles Message-ID: <20140303192647.75AB814B91@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/193 - Mark From brian.burkhalter at oracle.com Mon Mar 3 19:37:01 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 3 Mar 2014 11:37:01 -0800 Subject: [REFRESH] JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger In-Reply-To: <5311396C.3020509@oracle.com> References: <5305D6EB.30806@oracle.com> <53064179.2060703@gmail.com> <530660FA.1060407@oracle.com> <96CF3236-4E65-4D64-BCF3-1E9660D29BAA@oracle.com> <5306BC4B.4090909@oracle.com> <8229AE11-1ABF-474D-961F-BBD5ACA3DD82@oracle.com> <61708919-691D-4EBF-8685-0CC5FC309701@oracle.com> <10AE28AF-8765-430C-9D83-D0A88062B096@oracle.com> <247D03A1-0D88-437D-B2F1-9CD5DAE8492D@oracle.com> <8520F61D-B0CE-4E83-8336-938C745823D1@oracle.com> <5311396C.3020509@oracle.com> Message-ID: Hi Stuart, Thanks for the detailed review! Please see the refreshed webrev http://cr.openjdk.java.net/~bpb/8035279/webrev.02/ and my comments inline, below. I think I'll need another "thumbs up" as this has changed since Paul's approval was posted. On Feb 28, 2014, at 5:35 PM, Stuart Marks wrote: >> Thanks, Paul. I refreshed the webrev http://cr.openjdk.java.net/~bpb/8035279/webrev.01/ with the agreed upon version. > > This is pretty good. After this long, strange trip through the JMM, restoring the sentinel values to zeroes and renaming the fields to be explicit about how they represent the actual values seems to be the best approach. Paul's suggestion about using the term "stable value" in comments is good too. > > I took a look at the serialization stuff. The actual serialized form hasn't changed, so there should be no compatibility here with previous versions. > > There are some things in the serialization doc that ought to be brought up to date, though. Note that the docs for serialPersistentFields, readObject, and writeObject appear in the javadoc output, in the "Serialized Form" page, even though these members are private! Isn't this controlled by options passed to the javadoc tool as opposed to settings in the source code? > Per another of Paul's comments, the @serial tag should be removed from bitCountPlusOne, bitLengthPlusOne, and lowestSetBitPlusTwo, since these fields do not appear in the serialized representation. Corrected. > The fields bitCount, bitLength, and lowestSetBit appear in the serialized form only for backward compatibility and are otherwise ignored, so their @serialField entries should just say that instead of describing how they were formerly used. Also, firstNonzeroByteNum is missing a @serialField entry, and it should have the same description as the others. Corrected. > Typo at 4236-4237, it says "be\ndefault" instead of "by\ndefault". Corrected. > The comment at lines 4242-4246 should simply be removed. The first and third sentences are redundant with other docs. The second sentence, "The magnitude field is used as a temporary store for the byte array that is deserialized" is incorrect, as there is no longer a 'magnitude' field; a local is used instead. Corrected. > The @serialData tag at line 4316 for writeObject is misused; this is really intended for *extra* serial data written by writeObject after the writeFields() or defaultWriteObject() call, which doesn't occur here. It might be worth being explicit in writeObject's doc comment about writing -1's and -2's as the values for bitCount, bitLength, lowestSetBit, and firstNonzeroByteNum for compatibility with older implementations, even though current implementations will ignore these values. Corrected. On Feb 28, 2014, at 5:54 PM, Stuart Marks wrote: > Woops, I forgot a couple points. > > The @serial for the 'signum' field at line 130 should be removed. Note that even though this has the same name as the field that appears in the serialized form, the text from the @serialField tag for 'signum' that's part of the serialPersistentFields doc comment is the one that actually appears on the "Serialized Form" page. Corrected. > It might be worthwhile copying the more verbose description from lines 125-128 to the @serialField tag text (lines 4206-4207) since this describes the requirements on the serialized form more precisely. I hate redundancy in documentation, though. I opted for not copying the verbiage in the interested of reduced redundancy. > Note that the field names in the ObjectStreamField entries of the serialPersistentFields array don't necessarily match the actual fields in the class. In this case 'signum' matches but the others do not. That's ok. The entries in this array describe the field names that are used in the serialized output, which is essential for remaining compatible with older versions of BigInteger. Understood. > I checked an old version of BigInteger from 1998 and the field names used here match the actual, serialized fields from that old version. I verified compatibility with the Java 7 version but no older so this is good information. Thanks, Brian From omajid at redhat.com Mon Mar 3 21:49:24 2014 From: omajid at redhat.com (Omair Majid) Date: Mon, 3 Mar 2014 16:49:24 -0500 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <53112019.9050504@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> Message-ID: <20140303214923.GA26825@redhat.com> * David Holmes [2014-02-28 18:48]: > There are three pieces to all of this: > > 1. Generating debug symbols in the binaries (via gcc -g or whatever) > 2. Generating debuginfo files (zipped or not) (FDS) > 3. Stripping debug symbols from the binaries (strip-policy) > > It may be that we don't have clean separation between them, and if so > that should be fixed, but I don't see the current proposal as the way > forward. Any chance we could clean up the names too? It's not obvious to me why FDS means 'generating debuginfo files'. What do folks think of modifying the OPENJDK build to use this as the settings for the options above by default. 1. Yes 2. No 3. No > Also there may well be differences between how things are handled on the > JDK side and hotspot side. Is there any chance of this becoming consistent between hotspot and JDK? It would be much nicer if concepts like strip-policy were consistent between hotspot and the rest of the JDK. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From brian.goetz at oracle.com Mon Mar 3 22:25:34 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 03 Mar 2014 17:25:34 -0500 Subject: JEP 193: Enhanced Volatiles In-Reply-To: <20140303192647.75AB814B91@eggemoggin.niobe.net> References: <20140303192647.75AB814B91@eggemoggin.niobe.net> Message-ID: <5315015E.7010602@oracle.com> > Posted: http://openjdk.java.net/jeps/193 Some follow-up thoughts on teasing apart the issues covered by this JEP. There are three main layers of questions to answer: 1. How do we surface the various pieces of this into the programming model? This includes language syntax (e.g., x.volatile.compareAndSet()), library surface (e.g., the fictitious and not-terribly-satisfying VolatileInt interface), and relevant restrictions (e.g., can we do volatile operations on non-volatile fields or array elements?) Embedded in this proposal is the desire to not provide a full-blown "lvalue" form for variables; supporting any form of pass-by-reference at the language level is a super-non-goal here. But, we have to watch out for unintended consequences: the VolatileXxx interfaces may end up as a de facto lvalue construct, and not the ideal one. Along these lines, the right level at which to exposes these might (or might not) be FieldHandle, which would be the constrained sibling of MethodHandle. Relatedly, we need to decide whether to expose fences directly in the libraries, such as with (intrinsifiable) static methods on a Fences class; based on discussions in the JMM list, that's probably where we're heading (and that's fine.) 2. Translation to bytecodes. What bytecode should javac emit when it encounters an volatile accessor or atomic update? We've identified a handful of candidates: 2a: new bytecodes. This is the most direct and pure, but most intrusive (and least extensible), means of delivering on the promise of "it's time to move this stuff into the programming model proper." The "wide" bytecode offers a means to express fenced variants of {get,put}{field,static} with only a single new bytecode, but this doesn't scale well to CAS (explosion of data types and data locations (static field, instance field, array element)), which is really the important case. 2b: new MH types. Just as we have field getter/setter method handles, we can have fenced getter/setter handles as well as CAS-er handles. Paul has prototyped something here and demonstrated that its probably viable, but we have to do some measurement to verify that this is at least asymptotically competitive with Unsafe. The spec footprint of this might be broader than we like; a number of new forms of DirectMethodHandle and corresponding constant pool forms. One variant of 2b would be to separate fenced access from CAS, and only require MH support for CAS; translating fenced access would be with a combination of {put,get}field and calls to Fence methods. This reduces the VM footprint. 2c: Field handles. This is formalizing the notion of lvalue at the VM level; define a type FieldHandle which is analogous to MethodHandle, with signature-polymorphic / intrinsifiable methods for fenced get/put and CAS. Smaller footprint than 2b; at worst three flavors (static, instance, and array element). A logical extension of MethodHandle. 2d: Indy+intrinsification. Define a number of indy forms (with intrinsifiable bootstraps) to describe the various fenced and atomic operations. Known combinations of (bootstrap, static args) would effectively be recognized as new bytecodes, since the semantics of the bootstrap can be known to the VM. Again, can be combined with the variant above using fence methods, so this might only be needed for CAS, in which case we need only three forms again: instance field, static field, array element. Fields could be identified nominally (interpreted at link time) or by existing CP-able direct method handles for field accessors (which encapsulates accessibility checking.) There may be others; this is not an exhaustive list. 3. VM intrusion (including java.lang.invoke footprint). Depending on the strategy chosen in (2), there are new VM or JSR-292 artifacts needed to support these forms. From david.lloyd at redhat.com Mon Mar 3 22:53:04 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 03 Mar 2014 16:53:04 -0600 Subject: JEP 193: Enhanced Volatiles In-Reply-To: <5315015E.7010602@oracle.com> References: <20140303192647.75AB814B91@eggemoggin.niobe.net> <5315015E.7010602@oracle.com> Message-ID: <531507D0.9070907@redhat.com> On 03/03/2014 04:25 PM, Brian Goetz wrote: >> Posted: http://openjdk.java.net/jeps/193 > > Some follow-up thoughts on teasing apart the issues covered by this JEP. > > There are three main layers of questions to answer: > > 1. How do we surface the various pieces of this into the programming > model? This includes language syntax (e.g., > x.volatile.compareAndSet()), library surface (e.g., the fictitious and > not-terribly-satisfying VolatileInt interface), and relevant > restrictions (e.g., can we do volatile operations on non-volatile fields > or array elements?) > [...and then...] > 2. Translation to bytecodes. What bytecode should javac emit when it > encounters an volatile accessor or atomic update? We've identified a > handful of candidates: > > 2a: new bytecodes. This is the most direct and pure, but most intrusive > (and least extensible), means of delivering on the promise of "it's time > to move this stuff into the programming model proper." The "wide" > bytecode offers a means to express fenced variants of > {get,put}{field,static} with only a single new bytecode, but this > doesn't scale well to CAS (explosion of data types and data locations > (static field, instance field, array element)), which is really the > important case. Somewhere between new bytecodes and field handles, perhaps a single bytecode could suffice - one which is similar to getfield except instead of reading the field, it pushes a virtual "object" on to the stack which can then only be operated upon by invokeinterface on the pertinent "VolatileXxx" interface and otherwise doesn't have a real "type" per se. -- - DML From brian.burkhalter at oracle.com Tue Mar 4 00:14:15 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 3 Mar 2014 16:14:15 -0800 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal Message-ID: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> Hello all, This review request concerns this issue and proposed patch: issue https://bugs.openjdk.java.net/browse/JDK-6375303 patch http://cr.openjdk.java.net/~bpb/6375303/webrev.00/ A review of the current code did not reveal anything clearly amiss in the nature of the the problems which instigated the original filing of this issue. Examination of the code did however suggest some code style and aesthetic improvements as well as a change to how one lazy initialization was implemented (here we go again ...). Summary: - clean up imports section - add AtomicReferenceFieldUpdater-type constant for stringCache initialization - change some existing static final constants to conform to Java coding style - change name of some local variables so as not to hide instance variables of the same name - add missing @Override annotations - modify lazy initialization of stringCache in toString() to use AtomicReferenceFieldUpdater constant - various other minor cleanup Note that the performance of initialization of stringCache was measured for the extant double-checked locking approach, an AtomicReference, and the AtomicReferenceFieldUpdater and no significant degradation was observed for either of the latter versus the baseline for 1 and 4 threads. The updater has the advantage of adding only one object per class as opposed to one per instance. Thanks, Brian From joe.darcy at oracle.com Tue Mar 4 02:03:55 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 03 Mar 2014 18:03:55 -0800 Subject: JDK 9 RFR to remove a raw lint warning from java/lang/invoke/MethodHandleImpl.java Message-ID: <5315348B.5080904@oracle.com> Hello, The recent changeset for 8027827: Improve performance of catchException combinator 8034120: MethodHandles.catchException doesn't handle VarargsCollector right introduced a raw lint warning to the core libraries. Please review the patch below which removes the warning by adding "" to the type the exType parameter of the method. A JDK build succeeds with the new signature in place. Thanks, -Joe diff -r 6cfedc362f48 src/share/classes/java/lang/invoke/MethodHandleImpl.java --- a/src/share/classes/java/lang/invoke/MethodHandleImpl.java Mon Mar 03 18:17:00 2014 +0400 +++ b/src/share/classes/java/lang/invoke/MethodHandleImpl.java Mon Mar 03 17:49:52 2014 -0800 @@ -734,7 +734,7 @@ * (see {@link InvokerBytecodeGenerator#emitGuardWithCatch emitGuardWithCatch}). */ @LambdaForm.Hidden - static Object guardWithCatch(MethodHandle target, Class exType, MethodHandle catcher, + static Object guardWithCatch(MethodHandle target, Class exType, MethodHandle catcher, Object... av) throws Throwable { try { return target.invokeWithArguments(av); From daniel.daugherty at oracle.com Tue Mar 4 03:02:34 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 03 Mar 2014 20:02:34 -0700 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <20140303214923.GA26825@redhat.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> Message-ID: <5315424A.4080201@oracle.com> On 3/3/14 2:49 PM, Omair Majid wrote: > * David Holmes [2014-02-28 18:48]: >> There are three pieces to all of this: >> >> 1. Generating debug symbols in the binaries (via gcc -g or whatever) >> 2. Generating debuginfo files (zipped or not) (FDS) >> 3. Stripping debug symbols from the binaries (strip-policy) >> >> It may be that we don't have clean separation between them, and if so >> that should be fixed, but I don't see the current proposal as the way >> forward. > Any chance we could clean up the names too? It's not obvious to me why > FDS means 'generating debuginfo files'. FDS stands for Full Debug Symbols and is defined that way in quite a few Makefiles... We just call it FDS for short... > What do folks think of modifying the OPENJDK build to use this as the > settings for the options above by default. > > 1. Yes > 2. No > 3. No Whatever we do here has be architecturallyconsistent across the various OpenJDK platforms. The above settings would not work well on non-Linux platforms so I'm not in favor of doing that. However, I don't have a problem with providing support for config'ing a build to work with the downstream Linux repos... >> Also there may well be differences between how things are handled on the >> JDK side and hotspot side. > Is there any chance of this becoming consistent between hotspot and JDK? > It would be much nicer if concepts like strip-policy were consistent > between hotspot and the rest of the JDK. When I did the Full Debug Symbols (FDS) project, I made it architecturally consistent between the HotSpot and JDK sides. Since the new build system has arrived, something of the consistency has been broken and I haven't been back on the JDK side to see what happened... Dan > > Thanks, > Omair > From david.holmes at oracle.com Tue Mar 4 03:45:29 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 04 Mar 2014 13:45:29 +1000 Subject: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods In-Reply-To: <53147C11.1010906@redhat.com> References: <53110B02.7070602@oracle.com> <5312F127.60903@javaspecialists.eu> <53136337.9040001@redhat.com> <53137CE2.1010102@javaspecialists.eu> <53147C11.1010906@redhat.com> Message-ID: <53154C59.1000001@oracle.com> On 3/03/2014 10:56 PM, David M. Lloyd wrote: > Yes, that would necessarily be the contract of a Monitors class, just as > it is part of the contract of Lock today. If your argument is that it > shouldn't be allowed because it might be used wrong, we might as well > just delete most of the JDK, ReentrantLock included, since it suffers > from the exact same potential problem. The difference is that monitors > have a simple API in the form of synchronized that people were in the > past and would continue to be free (and recommended) to use. We should not introduce anything that allows something that was guaranteed to be safe by the language, to become unsafe. So I can support a call for tryMonitorEnter, but not for explicit enter/exit actions. David ----- > I would not call recommending monitors to be a "premature optimization". > The memory overhead of ReentrantLock is far too large for many use > cases, especially when it comes to fine-grained locking of large data > sets. In fact I would *only* recommend Lock if your need for the extra > behavior it provides (i.e., multiple conditions, tryLock, timed tryLock, > and/or interruptible locking) or for the extra behavior provided by > ReentrantLock itself (i.e., lock status introspection) outweighs the > cost of its memory consumption, which so far has happened zero times in > any of the many frameworks I maintain. > > On the other hand, adding some of the missing functionality to a > Monitors class would be pretty handy, especially if doing so doesn't > create a large divergence from the existing implementation. Given that > tryMonitorEnter already exists, implementing that method on a Monitors > class seems fairly trivial, which already takes care of one out of the > four special use cases for Locks. Interruptible locking would be my > first choice for a number two, if this idea were actually officially on > the table. Finally, an isMonitorHeld() method would tie in another > branch of the discussion nicely and seems trivially possible as well. > Any other information would be a purely > > It's worth noting that it's already possible for user code to implement > the basic functionality using JNI methods, though in the interest of > full disclosure it's worth noting that the enter/exit monitor JNI > functions are forbidden by spec to interoperate with the corresponding > bytecodes. > > FWIW using the word "monitor" instead of "lock" may help avoid confusion > and "scare off" those pesky undergrads. > > On 03/02/2014 12:48 PM, Dr Heinz M. Kabutz wrote: >> Hi Dave, >> >> "lighter" is subject to the HotSpot Profiler doing the optimizations >> that you expect. Problem is, once you begin manually locking / >> unlocking monitors, the byte codes are not recognizable as standard >> synchronized(monitor) {} code, thus the optimizations will also not be >> as good (or completely absent). At least that has been my experience >> when I tried it out a few years ago. So the argument that synchronized >> is faster than ReentrantLock, besides this being IMHO a premature >> optimization, cannot be directly applied to when we manually do use the >> monitorEnter/monitorExit methods. >> >> The reason why I personally think they are more dangerous than >> ReentrantLock is that we are used to synchronized() {} taking care of >> the unlocking for us. If we see a thread that is in the BLOCKED state >> (which only happens with synchronized) then we would typically assume >> that another thread is /currently /holding the monitor. >> >> Take the following example code: >> >> import sun.misc.*; >> >> import java.lang.reflect.*; >> >> public class MonitorMystery { >> public static Unsafe getUnsafe() { >> try { >> for (Field field : Unsafe.class.getDeclaredFields()) { >> if (Modifier.isStatic(field.getModifiers())) { >> if (field.getType() == Unsafe.class) { >> field.setAccessible(true); >> return (Unsafe) field.get(null); >> } >> } >> } >> throw new IllegalStateException("Unsafe field not found"); >> } catch (Exception e) { >> throw new IllegalStateException( >> "Could not initialize unsafe", e); >> } >> } >> >> public static void main(String... args) throws InterruptedException { >> Thread t = new Thread() { >> public void run() { >> getUnsafe().monitorEnter(MonitorMystery.class); >> } >> }; >> t.start(); >> Thread.sleep(100); >> System.out.println("Trying to synchronize"); >> synchronized (MonitorMystery.class) { >> System.out.println("Managed to synchronized"); >> } >> } >> } >> >> We now see that we never manage to synchronize in the main thread and in >> fact if you do a thread dump you will see a deadlock involving only a >> single thread :-) >> >> This is why it is so important to use the correct idioms. In my >> experience, there are very few Java programmers who get this right. >> Brian Goetz's book is correct, but there are other books out there that >> do a shocking job of mangling the idiom. >> >> Whenever possible, use synchronized() { }. If not, IMHO it would be >> preferable to switch to ReentrantLock. >> >> Regards >> >> Heinz >> -- >> Dr Heinz M. Kabutz (PhD CompSci) >> Author of "The Java(tm) Specialists' Newsletter" >> Oracle Java Champion 2005-2013 >> JavaOne Rock Star Speaker 2012 >> http://www.javaspecialists.eu >> Tel: +30 69 75 595 262 >> Skype: kabutz >> >> >> >> David M. Lloyd wrote: >>> Making the language Kindergarten-friendly at the cost of general >>> usefulness is a mistake, IMO. And anyway there's nothing that is less >>> safe about a Monitors class than ReentrantLock; on the other hand, >>> monitors continue to be considerably lighter (size and (for most of >>> the history of JUC) speed) by every measurement I've ever made. I >>> would advise monitors over ReentrantLock 9 times out of 10 in any of >>> our code. >>> >>> I just don't think your metaphors - neither of monitor methods being >>> dangerous, nor of Java developers being infants - are really apt. >>> >>> On 03/02/2014 02:51 AM, Dr Heinz M. Kabutz wrote: >>>> With a curious 9 months old crawling around the house, I've just moved >>>> the sharp knives to the top draw in the kitchen - out of reach. I >>>> don't >>>> think we should be encouraging people to use monitor.tryLock() for >>>> various reasons: >>>> >>>> 1. We have a richer interface with Lock/ReentrantLock, including better >>>> Condition that allow easier timed wait idioms. >>>> >>>> 2. It is just too easy to get the idioms wrong for Lock.lock() and >>>> Lock.unlock(). Every time I show this idiom some people in the >>>> audience >>>> start arguing with me: >>>> >>>> lock.lock(); >>>> try { >>>> // do something >>>> } finally { >>>> lock.unlock(); >>>> } >>>> >>>> IMHO, this is really an edge case that might be useful to have >>>> semi-accessible at some point, but not something that should generally >>>> be done. It belongs in the same draw as the sharp knives and the >>>> ability to cause arbitrary asynchronous exceptions (which has been made >>>> more difficult to do in Java 8). >>>> >>>> Brian Goetz wrote: >>>>> Except that Lock has features that are not supported by intrinsic >>>>> locks (timed wait, interruptible wait.) So the Lock returned would >>>>> not conform to Lock's contract, and attempting to call these methods >>>>> would probably throw UOE. >>>>> >>>>> On 2/27/2014 6:12 AM, Stephen Colebourne wrote: >>>>>> On 26 February 2014 20:54, Martin Buchholz >>>>>> wrote: >>>>>>> It does seem that being able to tell whether a java object >>>>>>> monitor is >>>>>>> currently locked is useful for debugging and monitoring - there >>>>>>> should be a >>>>>>> way to do that. >>>>>> >>>>>> Perhaps it would be useful to be able to expose a java object monitor >>>>>> as an instance of Lock? >>>>>> >>>>>> Lock lk = Lock.ofMonitor(object) >>>>>> if (lk.tryLock()) { >>>>>> ... >>>>>> } >>>>>> >>>>>> Such a method feels like it would be a useful missing link between >>>>>> synchronized and locks. >>>>>> >>>>>> Stephen >>>>>> >>>>> >>> >>> > > From david.holmes at oracle.com Tue Mar 4 03:51:52 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 04 Mar 2014 13:51:52 +1000 Subject: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods In-Reply-To: <53147C36.9090500@redhat.com> References: <530F31C1.8000604@oracle.com> <53147C36.9090500@redhat.com> Message-ID: <53154DD8.9050200@oracle.com> On 3/03/2014 10:57 PM, David M. Lloyd wrote: > On 02/27/2014 06:38 AM, David Holmes wrote: >> On 27/02/2014 9:12 PM, Stephen Colebourne wrote: >>> On 26 February 2014 20:54, Martin Buchholz wrote: >>>> It does seem that being able to tell whether a java object monitor is >>>> currently locked is useful for debugging and monitoring - there >>>> should be a >>>> way to do that. >>> >>> Perhaps it would be useful to be able to expose a java object monitor >>> as an instance of Lock? >>> >>> Lock lk = Lock.ofMonitor(object) >>> if (lk.tryLock()) { >>> ... >>> } >>> >>> Such a method feels like it would be a useful missing link between >>> synchronized and locks. >> >> I don't think this is workable. Exposing a monitor as Lock would allow >> you to break the guarantees/requirements involving balanced-locking for >> monitors. > > The JNI APIs also allow this, do they not? No: http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html#wp5252 "Native code must not use MonitorExit to exit a monitor entered through a synchronized method or a monitorenter Java virtual machine instruction." The above isn't enforced as with most JNI usage rules. David ----- > From david.holmes at oracle.com Tue Mar 4 04:09:07 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 04 Mar 2014 14:09:07 +1000 Subject: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods In-Reply-To: <53154C59.1000001@oracle.com> References: <53110B02.7070602@oracle.com> <5312F127.60903@javaspecialists.eu> <53136337.9040001@redhat.com> <53137CE2.1010102@javaspecialists.eu> <53147C11.1010906@redhat.com> <53154C59.1000001@oracle.com> Message-ID: <531551E3.8030704@oracle.com> On 4/03/2014 1:45 PM, David Holmes wrote: > On 3/03/2014 10:56 PM, David M. Lloyd wrote: >> Yes, that would necessarily be the contract of a Monitors class, just as >> it is part of the contract of Lock today. If your argument is that it >> shouldn't be allowed because it might be used wrong, we might as well >> just delete most of the JDK, ReentrantLock included, since it suffers >> from the exact same potential problem. The difference is that monitors >> have a simple API in the form of synchronized that people were in the >> past and would continue to be free (and recommended) to use. > > We should not introduce anything that allows something that was > guaranteed to be safe by the language, to become unsafe. So I can > support a call for tryMonitorEnter, but not for explicit enter/exit > actions. Which of course is not possible at the API level - Doh! Sorry. David > David > ----- > >> I would not call recommending monitors to be a "premature optimization". >> The memory overhead of ReentrantLock is far too large for many use >> cases, especially when it comes to fine-grained locking of large data >> sets. In fact I would *only* recommend Lock if your need for the extra >> behavior it provides (i.e., multiple conditions, tryLock, timed tryLock, >> and/or interruptible locking) or for the extra behavior provided by >> ReentrantLock itself (i.e., lock status introspection) outweighs the >> cost of its memory consumption, which so far has happened zero times in >> any of the many frameworks I maintain. >> >> On the other hand, adding some of the missing functionality to a >> Monitors class would be pretty handy, especially if doing so doesn't >> create a large divergence from the existing implementation. Given that >> tryMonitorEnter already exists, implementing that method on a Monitors >> class seems fairly trivial, which already takes care of one out of the >> four special use cases for Locks. Interruptible locking would be my >> first choice for a number two, if this idea were actually officially on >> the table. Finally, an isMonitorHeld() method would tie in another >> branch of the discussion nicely and seems trivially possible as well. >> Any other information would be a purely >> >> It's worth noting that it's already possible for user code to implement >> the basic functionality using JNI methods, though in the interest of >> full disclosure it's worth noting that the enter/exit monitor JNI >> functions are forbidden by spec to interoperate with the corresponding >> bytecodes. >> >> FWIW using the word "monitor" instead of "lock" may help avoid confusion >> and "scare off" those pesky undergrads. >> >> On 03/02/2014 12:48 PM, Dr Heinz M. Kabutz wrote: >>> Hi Dave, >>> >>> "lighter" is subject to the HotSpot Profiler doing the optimizations >>> that you expect. Problem is, once you begin manually locking / >>> unlocking monitors, the byte codes are not recognizable as standard >>> synchronized(monitor) {} code, thus the optimizations will also not be >>> as good (or completely absent). At least that has been my experience >>> when I tried it out a few years ago. So the argument that synchronized >>> is faster than ReentrantLock, besides this being IMHO a premature >>> optimization, cannot be directly applied to when we manually do use the >>> monitorEnter/monitorExit methods. >>> >>> The reason why I personally think they are more dangerous than >>> ReentrantLock is that we are used to synchronized() {} taking care of >>> the unlocking for us. If we see a thread that is in the BLOCKED state >>> (which only happens with synchronized) then we would typically assume >>> that another thread is /currently /holding the monitor. >>> >>> Take the following example code: >>> >>> import sun.misc.*; >>> >>> import java.lang.reflect.*; >>> >>> public class MonitorMystery { >>> public static Unsafe getUnsafe() { >>> try { >>> for (Field field : Unsafe.class.getDeclaredFields()) { >>> if (Modifier.isStatic(field.getModifiers())) { >>> if (field.getType() == Unsafe.class) { >>> field.setAccessible(true); >>> return (Unsafe) field.get(null); >>> } >>> } >>> } >>> throw new IllegalStateException("Unsafe field not found"); >>> } catch (Exception e) { >>> throw new IllegalStateException( >>> "Could not initialize unsafe", e); >>> } >>> } >>> >>> public static void main(String... args) throws InterruptedException { >>> Thread t = new Thread() { >>> public void run() { >>> getUnsafe().monitorEnter(MonitorMystery.class); >>> } >>> }; >>> t.start(); >>> Thread.sleep(100); >>> System.out.println("Trying to synchronize"); >>> synchronized (MonitorMystery.class) { >>> System.out.println("Managed to synchronized"); >>> } >>> } >>> } >>> >>> We now see that we never manage to synchronize in the main thread and in >>> fact if you do a thread dump you will see a deadlock involving only a >>> single thread :-) >>> >>> This is why it is so important to use the correct idioms. In my >>> experience, there are very few Java programmers who get this right. >>> Brian Goetz's book is correct, but there are other books out there that >>> do a shocking job of mangling the idiom. >>> >>> Whenever possible, use synchronized() { }. If not, IMHO it would be >>> preferable to switch to ReentrantLock. >>> >>> Regards >>> >>> Heinz >>> -- >>> Dr Heinz M. Kabutz (PhD CompSci) >>> Author of "The Java(tm) Specialists' Newsletter" >>> Oracle Java Champion 2005-2013 >>> JavaOne Rock Star Speaker 2012 >>> http://www.javaspecialists.eu >>> Tel: +30 69 75 595 262 >>> Skype: kabutz >>> >>> >>> >>> David M. Lloyd wrote: >>>> Making the language Kindergarten-friendly at the cost of general >>>> usefulness is a mistake, IMO. And anyway there's nothing that is less >>>> safe about a Monitors class than ReentrantLock; on the other hand, >>>> monitors continue to be considerably lighter (size and (for most of >>>> the history of JUC) speed) by every measurement I've ever made. I >>>> would advise monitors over ReentrantLock 9 times out of 10 in any of >>>> our code. >>>> >>>> I just don't think your metaphors - neither of monitor methods being >>>> dangerous, nor of Java developers being infants - are really apt. >>>> >>>> On 03/02/2014 02:51 AM, Dr Heinz M. Kabutz wrote: >>>>> With a curious 9 months old crawling around the house, I've just moved >>>>> the sharp knives to the top draw in the kitchen - out of reach. I >>>>> don't >>>>> think we should be encouraging people to use monitor.tryLock() for >>>>> various reasons: >>>>> >>>>> 1. We have a richer interface with Lock/ReentrantLock, including >>>>> better >>>>> Condition that allow easier timed wait idioms. >>>>> >>>>> 2. It is just too easy to get the idioms wrong for Lock.lock() and >>>>> Lock.unlock(). Every time I show this idiom some people in the >>>>> audience >>>>> start arguing with me: >>>>> >>>>> lock.lock(); >>>>> try { >>>>> // do something >>>>> } finally { >>>>> lock.unlock(); >>>>> } >>>>> >>>>> IMHO, this is really an edge case that might be useful to have >>>>> semi-accessible at some point, but not something that should generally >>>>> be done. It belongs in the same draw as the sharp knives and the >>>>> ability to cause arbitrary asynchronous exceptions (which has been >>>>> made >>>>> more difficult to do in Java 8). >>>>> >>>>> Brian Goetz wrote: >>>>>> Except that Lock has features that are not supported by intrinsic >>>>>> locks (timed wait, interruptible wait.) So the Lock returned would >>>>>> not conform to Lock's contract, and attempting to call these methods >>>>>> would probably throw UOE. >>>>>> >>>>>> On 2/27/2014 6:12 AM, Stephen Colebourne wrote: >>>>>>> On 26 February 2014 20:54, Martin Buchholz >>>>>>> wrote: >>>>>>>> It does seem that being able to tell whether a java object >>>>>>>> monitor is >>>>>>>> currently locked is useful for debugging and monitoring - there >>>>>>>> should be a >>>>>>>> way to do that. >>>>>>> >>>>>>> Perhaps it would be useful to be able to expose a java object >>>>>>> monitor >>>>>>> as an instance of Lock? >>>>>>> >>>>>>> Lock lk = Lock.ofMonitor(object) >>>>>>> if (lk.tryLock()) { >>>>>>> ... >>>>>>> } >>>>>>> >>>>>>> Such a method feels like it would be a useful missing link between >>>>>>> synchronized and locks. >>>>>>> >>>>>>> Stephen >>>>>>> >>>>>> >>>> >>>> >> >> From heinz at javaspecialists.eu Tue Mar 4 05:10:49 2014 From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz) Date: Tue, 4 Mar 2014 07:10:49 +0200 Subject: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods In-Reply-To: <53154C59.1000001@oracle.com> References: <53110B02.7070602@oracle.com> <5312F127.60903@javaspecialists.eu> <53136337.9040001@redhat.com> <53137CE2.1010102@javaspecialists.eu> <53147C11.1010906@redhat.com> <53154C59.1000001@oracle.com> Message-ID: On 04/03/2014, David Holmes wrote: > On 3/03/2014 10:56 PM, David M. Lloyd wrote: >> Yes, that would necessarily be the contract of a Monitors class, just as >> it is part of the contract of Lock today. If your argument is that it >> shouldn't be allowed because it might be used wrong, we might as well >> just delete most of the JDK, ReentrantLock included, since it suffers >> from the exact same potential problem. The difference is that monitors >> have a simple API in the form of synchronized that people were in the >> past and would continue to be free (and recommended) to use. > > We should not introduce anything that allows something that was > guaranteed to be safe by the language, to become unsafe. So I can > support a call for tryMonitorEnter, but not for explicit enter/exit > actions. We'd need the explicit exit of course if we have the tryMonitorEnter. From joe.darcy at oracle.com Tue Mar 4 06:05:51 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 03 Mar 2014 22:05:51 -0800 Subject: JDK 9 RFR of JDK-8035452: Fix serial lint warnings in core libs In-Reply-To: <5310C044.9090409@oracle.com> References: <530666A5.8050607@oracle.com> <530C1A87.2070608@oracle.com> <530C3DF5.3040707@oracle.com> <530F9C02.5090500@oracle.com> <5310C044.9090409@oracle.com> Message-ID: <53156D3F.8010409@oracle.com> Hi Stuart, Thanks for the careful review. I agree the case of TreeMap.NavigableSbugMap requires some more investigation. In the meantime, I'd like to proceed with the revised patch below for EnumSet and ExceptionProxy. Thanks, -Joe diff -r 6cfedc362f48 src/share/classes/java/util/EnumSet.java --- a/src/share/classes/java/util/EnumSet.java Mon Mar 03 18:17:00 2014 +0400 +++ b/src/share/classes/java/util/EnumSet.java Mon Mar 03 22:02:06 2014 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 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 @@ -77,6 +77,8 @@ * @see EnumMap * @serial exclude */ + at SuppressWarnings("serial") // No serialVersionUID due to usage of + // serial proxy pattern public abstract class EnumSet> extends AbstractSet implements Cloneable, java.io.Serializable { diff -r 6cfedc362f48 src/share/classes/sun/reflect/annotation/ExceptionProxy.java --- a/src/share/classes/sun/reflect/annotation/ExceptionProxy.java Mon Mar 03 18:17:00 2014 +0400 +++ b/src/share/classes/sun/reflect/annotation/ExceptionProxy.java Mon Mar 03 22:02:06 2014 -0800 @@ -37,5 +37,6 @@ * @since 1.5 */ public abstract class ExceptionProxy implements java.io.Serializable { + private static final long serialVersionUID = 7241930048386631401L; protected abstract RuntimeException generateException(); } On 02/28/2014 08:58 AM, Stuart Marks wrote: > On 2/27/14 12:11 PM, Joe Darcy wrote: >> I am trying hard to remain blissfully ignorant of any more low-level >> details of >> the serialization format; however, I might not be successful on that >> goal much >> longer ;-) > > I believe your latter statement is correct. :-) > >> My preference in a case like this is to add the svuid if for no other >> reason >> that is is simple to explain and understand, even if it is not >> strictly required. > > In general, it does seem reasonable to add a svuid in cases where it's > difficult or impractical to prove that the lack of a svuid causes no > compatibility issues. > >> There is a difference in character between a serializable class in >> Java SE >> (java.* and javax.*) and the jdk.Exported(true) types in the JDK and a >> serializable class that lives in sun.* or some other >> jdk.Exported(false) area. >> >> For that latter, the serialization contract has to be different, with >> fewer >> guarantees, just as the general usage contract for those types has fewer >> guarantees. I think this is analogous to putting non-serializable >> classes into >> collections; the collection itself is serializable, but it won't be >> anymore if >> you put non-serializable objects into it. >> >> If a user happens to have a direct or indirect reference to an object >> of a JDK >> implementation type, the compatibility contract is weaker than if an >> object with >> a public Java SE type were being dealt with. > > I'm not sure I buy this. Unfortunately, serialization differs from the > general usage contract in that serialization exposes internals. Just > like it can expose private (non-transient) fields, serialization can > also can expose what might otherwise look like purely internal > implementation types. > > The canonical example of how an application can get a reference to an > apparently internal class is java.util.TimeZone. If an app calls > TimeZone.getDefault(), it gets back an instance of > sun.util.calendar.ZoneInfo without ever mentioning this class by name. > Furthermore, TimeZone and ZoneInfo are serializable, so they can be > serialized directly or as part of another serializable object graph, > and an instance of s.u.c.ZoneInfo does appear in the serialized byte > stream. If s.u.c.ZoneInfo were not to have a svuid, an apparently > innocuous change to it would clearly cause application incompatibilities. > > As it happens, s.u.c.ZoneInfo does have a svuid. I also note in > passing that TimeZone, an abstract class, also has a svuid. > >>> Finally, EnumSet doesn't need a serial version UID. It's serialized >>> using a >>> proxy class, so EnumSet never appears in a serialized byte stream. >>> (Note, its >>> readObject throws an exception unconditionally.) So it's probably >>> safe to >>> suppress its serialization warning. >> >> Yes, EnumSet was a bit tricky, it is serializable itself, but uses a >> proxy >> internally. ("Effective Java, 2nd edition" both recommends the proxy >> pattern and >> recommends adding a svuid to all serializable classes, but doesn't >> explicitly >> give guidance to this combination of features.) >> >> To avoid adding a long comment explaining the proxy pattern and why a >> svuid on >> EnumSet isn't really required, my preference would just be to add the >> svuid if >> it doesn't cause any harm. > > In this case I think it's possible by local reasoning (looking > elsewhere in the EnumSet.java source code) to determine that EnumSet > instances themselves are never actually serialized, because of the use > of the serialization proxy pattern. If nothing else, adding a svuid > here sets a bad example, so suppressing the warning is reasonable. I > don't think a long comment is necessary. Probably something like the > following is sufficient: > > @SuppressWarnings("serial") // no serialVersionUID because of > serialization proxy > > s'marks > > > > From peter.levart at gmail.com Tue Mar 4 07:01:46 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 04 Mar 2014 08:01:46 +0100 Subject: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods In-Reply-To: <531551E3.8030704@oracle.com> References: <53110B02.7070602@oracle.com> <5312F127.60903@javaspecialists.eu> <53136337.9040001@redhat.com> <53137CE2.1010102@javaspecialists.eu> <53147C11.1010906@redhat.com> <53154C59.1000001@oracle.com> <531551E3.8030704@oracle.com> Message-ID: <53157A5A.2000200@gmail.com> On 03/04/2014 05:09 AM, David Holmes wrote: > On 4/03/2014 1:45 PM, David Holmes wrote: >> On 3/03/2014 10:56 PM, David M. Lloyd wrote: >>> Yes, that would necessarily be the contract of a Monitors class, >>> just as >>> it is part of the contract of Lock today. If your argument is that it >>> shouldn't be allowed because it might be used wrong, we might as well >>> just delete most of the JDK, ReentrantLock included, since it suffers >>> from the exact same potential problem. The difference is that monitors >>> have a simple API in the form of synchronized that people were in the >>> past and would continue to be free (and recommended) to use. >> >> We should not introduce anything that allows something that was >> guaranteed to be safe by the language, to become unsafe. So I can >> support a call for tryMonitorEnter, but not for explicit enter/exit >> actions. > > Which of course is not possible at the API level - Doh! Sorry. Unless the API is made safe by packing it into a lambda-consuming method. For example: public static boolean trySynchronized(Runnable action); Regards, Peter > > David > >> David >> ----- >> >>> I would not call recommending monitors to be a "premature >>> optimization". >>> The memory overhead of ReentrantLock is far too large for many use >>> cases, especially when it comes to fine-grained locking of large data >>> sets. In fact I would *only* recommend Lock if your need for the extra >>> behavior it provides (i.e., multiple conditions, tryLock, timed >>> tryLock, >>> and/or interruptible locking) or for the extra behavior provided by >>> ReentrantLock itself (i.e., lock status introspection) outweighs the >>> cost of its memory consumption, which so far has happened zero times in >>> any of the many frameworks I maintain. >>> >>> On the other hand, adding some of the missing functionality to a >>> Monitors class would be pretty handy, especially if doing so doesn't >>> create a large divergence from the existing implementation. Given that >>> tryMonitorEnter already exists, implementing that method on a Monitors >>> class seems fairly trivial, which already takes care of one out of the >>> four special use cases for Locks. Interruptible locking would be my >>> first choice for a number two, if this idea were actually officially on >>> the table. Finally, an isMonitorHeld() method would tie in another >>> branch of the discussion nicely and seems trivially possible as well. >>> Any other information would be a purely >>> >>> It's worth noting that it's already possible for user code to implement >>> the basic functionality using JNI methods, though in the interest of >>> full disclosure it's worth noting that the enter/exit monitor JNI >>> functions are forbidden by spec to interoperate with the corresponding >>> bytecodes. >>> >>> FWIW using the word "monitor" instead of "lock" may help avoid >>> confusion >>> and "scare off" those pesky undergrads. >>> >>> On 03/02/2014 12:48 PM, Dr Heinz M. Kabutz wrote: >>>> Hi Dave, >>>> >>>> "lighter" is subject to the HotSpot Profiler doing the optimizations >>>> that you expect. Problem is, once you begin manually locking / >>>> unlocking monitors, the byte codes are not recognizable as standard >>>> synchronized(monitor) {} code, thus the optimizations will also not be >>>> as good (or completely absent). At least that has been my experience >>>> when I tried it out a few years ago. So the argument that >>>> synchronized >>>> is faster than ReentrantLock, besides this being IMHO a premature >>>> optimization, cannot be directly applied to when we manually do use >>>> the >>>> monitorEnter/monitorExit methods. >>>> >>>> The reason why I personally think they are more dangerous than >>>> ReentrantLock is that we are used to synchronized() {} taking care of >>>> the unlocking for us. If we see a thread that is in the BLOCKED state >>>> (which only happens with synchronized) then we would typically assume >>>> that another thread is /currently /holding the monitor. >>>> >>>> Take the following example code: >>>> >>>> import sun.misc.*; >>>> >>>> import java.lang.reflect.*; >>>> >>>> public class MonitorMystery { >>>> public static Unsafe getUnsafe() { >>>> try { >>>> for (Field field : Unsafe.class.getDeclaredFields()) { >>>> if (Modifier.isStatic(field.getModifiers())) { >>>> if (field.getType() == Unsafe.class) { >>>> field.setAccessible(true); >>>> return (Unsafe) field.get(null); >>>> } >>>> } >>>> } >>>> throw new IllegalStateException("Unsafe field not found"); >>>> } catch (Exception e) { >>>> throw new IllegalStateException( >>>> "Could not initialize unsafe", e); >>>> } >>>> } >>>> >>>> public static void main(String... args) throws >>>> InterruptedException { >>>> Thread t = new Thread() { >>>> public void run() { >>>> getUnsafe().monitorEnter(MonitorMystery.class); >>>> } >>>> }; >>>> t.start(); >>>> Thread.sleep(100); >>>> System.out.println("Trying to synchronize"); >>>> synchronized (MonitorMystery.class) { >>>> System.out.println("Managed to synchronized"); >>>> } >>>> } >>>> } >>>> >>>> We now see that we never manage to synchronize in the main thread >>>> and in >>>> fact if you do a thread dump you will see a deadlock involving only a >>>> single thread :-) >>>> >>>> This is why it is so important to use the correct idioms. In my >>>> experience, there are very few Java programmers who get this right. >>>> Brian Goetz's book is correct, but there are other books out there >>>> that >>>> do a shocking job of mangling the idiom. >>>> >>>> Whenever possible, use synchronized() { }. If not, IMHO it would be >>>> preferable to switch to ReentrantLock. >>>> >>>> Regards >>>> >>>> Heinz >>>> -- >>>> Dr Heinz M. Kabutz (PhD CompSci) >>>> Author of "The Java(tm) Specialists' Newsletter" >>>> Oracle Java Champion 2005-2013 >>>> JavaOne Rock Star Speaker 2012 >>>> http://www.javaspecialists.eu >>>> Tel: +30 69 75 595 262 >>>> Skype: kabutz >>>> >>>> >>>> >>>> David M. Lloyd wrote: >>>>> Making the language Kindergarten-friendly at the cost of general >>>>> usefulness is a mistake, IMO. And anyway there's nothing that is >>>>> less >>>>> safe about a Monitors class than ReentrantLock; on the other hand, >>>>> monitors continue to be considerably lighter (size and (for most of >>>>> the history of JUC) speed) by every measurement I've ever made. I >>>>> would advise monitors over ReentrantLock 9 times out of 10 in any of >>>>> our code. >>>>> >>>>> I just don't think your metaphors - neither of monitor methods being >>>>> dangerous, nor of Java developers being infants - are really apt. >>>>> >>>>> On 03/02/2014 02:51 AM, Dr Heinz M. Kabutz wrote: >>>>>> With a curious 9 months old crawling around the house, I've just >>>>>> moved >>>>>> the sharp knives to the top draw in the kitchen - out of reach. I >>>>>> don't >>>>>> think we should be encouraging people to use monitor.tryLock() for >>>>>> various reasons: >>>>>> >>>>>> 1. We have a richer interface with Lock/ReentrantLock, including >>>>>> better >>>>>> Condition that allow easier timed wait idioms. >>>>>> >>>>>> 2. It is just too easy to get the idioms wrong for Lock.lock() and >>>>>> Lock.unlock(). Every time I show this idiom some people in the >>>>>> audience >>>>>> start arguing with me: >>>>>> >>>>>> lock.lock(); >>>>>> try { >>>>>> // do something >>>>>> } finally { >>>>>> lock.unlock(); >>>>>> } >>>>>> >>>>>> IMHO, this is really an edge case that might be useful to have >>>>>> semi-accessible at some point, but not something that should >>>>>> generally >>>>>> be done. It belongs in the same draw as the sharp knives and the >>>>>> ability to cause arbitrary asynchronous exceptions (which has been >>>>>> made >>>>>> more difficult to do in Java 8). >>>>>> >>>>>> Brian Goetz wrote: >>>>>>> Except that Lock has features that are not supported by intrinsic >>>>>>> locks (timed wait, interruptible wait.) So the Lock returned would >>>>>>> not conform to Lock's contract, and attempting to call these >>>>>>> methods >>>>>>> would probably throw UOE. >>>>>>> >>>>>>> On 2/27/2014 6:12 AM, Stephen Colebourne wrote: >>>>>>>> On 26 February 2014 20:54, Martin Buchholz >>>>>>>> wrote: >>>>>>>>> It does seem that being able to tell whether a java object >>>>>>>>> monitor is >>>>>>>>> currently locked is useful for debugging and monitoring - there >>>>>>>>> should be a >>>>>>>>> way to do that. >>>>>>>> >>>>>>>> Perhaps it would be useful to be able to expose a java object >>>>>>>> monitor >>>>>>>> as an instance of Lock? >>>>>>>> >>>>>>>> Lock lk = Lock.ofMonitor(object) >>>>>>>> if (lk.tryLock()) { >>>>>>>> ... >>>>>>>> } >>>>>>>> >>>>>>>> Such a method feels like it would be a useful missing link between >>>>>>>> synchronized and locks. >>>>>>>> >>>>>>>> Stephen >>>>>>>> >>>>>>> >>>>> >>>>> >>> >>> From peter.levart at gmail.com Tue Mar 4 07:06:42 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 04 Mar 2014 08:06:42 +0100 Subject: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods In-Reply-To: <53157A5A.2000200@gmail.com> References: <53110B02.7070602@oracle.com> <5312F127.60903@javaspecialists.eu> <53136337.9040001@redhat.com> <53137CE2.1010102@javaspecialists.eu> <53147C11.1010906@redhat.com> <53154C59.1000001@oracle.com> <531551E3.8030704@oracle.com> <53157A5A.2000200@gmail.com> Message-ID: <53157B82.8000500@gmail.com> On 03/04/2014 08:01 AM, Peter Levart wrote: > On 03/04/2014 05:09 AM, David Holmes wrote: >> On 4/03/2014 1:45 PM, David Holmes wrote: >>> On 3/03/2014 10:56 PM, David M. Lloyd wrote: >>>> Yes, that would necessarily be the contract of a Monitors class, >>>> just as >>>> it is part of the contract of Lock today. If your argument is that it >>>> shouldn't be allowed because it might be used wrong, we might as well >>>> just delete most of the JDK, ReentrantLock included, since it suffers >>>> from the exact same potential problem. The difference is that >>>> monitors >>>> have a simple API in the form of synchronized that people were in the >>>> past and would continue to be free (and recommended) to use. >>> >>> We should not introduce anything that allows something that was >>> guaranteed to be safe by the language, to become unsafe. So I can >>> support a call for tryMonitorEnter, but not for explicit enter/exit >>> actions. >> >> Which of course is not possible at the API level - Doh! Sorry. > > Unless the API is made safe by packing it into a lambda-consuming > method. For example: > > public static boolean trySynchronized(Runnable action); Sorry, forgot the monitor: public static boolean trySynchronized(Object monitor, Runnable action); I guess new java.lang.Object instance method is out of question? Regards, Peter > > Regards, Peter > >> >> David >> >>> David >>> ----- >>> >>>> I would not call recommending monitors to be a "premature >>>> optimization". >>>> The memory overhead of ReentrantLock is far too large for many use >>>> cases, especially when it comes to fine-grained locking of large data >>>> sets. In fact I would *only* recommend Lock if your need for the >>>> extra >>>> behavior it provides (i.e., multiple conditions, tryLock, timed >>>> tryLock, >>>> and/or interruptible locking) or for the extra behavior provided by >>>> ReentrantLock itself (i.e., lock status introspection) outweighs the >>>> cost of its memory consumption, which so far has happened zero >>>> times in >>>> any of the many frameworks I maintain. >>>> >>>> On the other hand, adding some of the missing functionality to a >>>> Monitors class would be pretty handy, especially if doing so doesn't >>>> create a large divergence from the existing implementation. Given that >>>> tryMonitorEnter already exists, implementing that method on a Monitors >>>> class seems fairly trivial, which already takes care of one out of the >>>> four special use cases for Locks. Interruptible locking would be my >>>> first choice for a number two, if this idea were actually >>>> officially on >>>> the table. Finally, an isMonitorHeld() method would tie in another >>>> branch of the discussion nicely and seems trivially possible as well. >>>> Any other information would be a purely >>>> >>>> It's worth noting that it's already possible for user code to >>>> implement >>>> the basic functionality using JNI methods, though in the interest of >>>> full disclosure it's worth noting that the enter/exit monitor JNI >>>> functions are forbidden by spec to interoperate with the corresponding >>>> bytecodes. >>>> >>>> FWIW using the word "monitor" instead of "lock" may help avoid >>>> confusion >>>> and "scare off" those pesky undergrads. >>>> >>>> On 03/02/2014 12:48 PM, Dr Heinz M. Kabutz wrote: >>>>> Hi Dave, >>>>> >>>>> "lighter" is subject to the HotSpot Profiler doing the optimizations >>>>> that you expect. Problem is, once you begin manually locking / >>>>> unlocking monitors, the byte codes are not recognizable as standard >>>>> synchronized(monitor) {} code, thus the optimizations will also >>>>> not be >>>>> as good (or completely absent). At least that has been my experience >>>>> when I tried it out a few years ago. So the argument that >>>>> synchronized >>>>> is faster than ReentrantLock, besides this being IMHO a premature >>>>> optimization, cannot be directly applied to when we manually do >>>>> use the >>>>> monitorEnter/monitorExit methods. >>>>> >>>>> The reason why I personally think they are more dangerous than >>>>> ReentrantLock is that we are used to synchronized() {} taking care of >>>>> the unlocking for us. If we see a thread that is in the BLOCKED >>>>> state >>>>> (which only happens with synchronized) then we would typically assume >>>>> that another thread is /currently /holding the monitor. >>>>> >>>>> Take the following example code: >>>>> >>>>> import sun.misc.*; >>>>> >>>>> import java.lang.reflect.*; >>>>> >>>>> public class MonitorMystery { >>>>> public static Unsafe getUnsafe() { >>>>> try { >>>>> for (Field field : Unsafe.class.getDeclaredFields()) { >>>>> if (Modifier.isStatic(field.getModifiers())) { >>>>> if (field.getType() == Unsafe.class) { >>>>> field.setAccessible(true); >>>>> return (Unsafe) field.get(null); >>>>> } >>>>> } >>>>> } >>>>> throw new IllegalStateException("Unsafe field not found"); >>>>> } catch (Exception e) { >>>>> throw new IllegalStateException( >>>>> "Could not initialize unsafe", e); >>>>> } >>>>> } >>>>> >>>>> public static void main(String... args) throws >>>>> InterruptedException { >>>>> Thread t = new Thread() { >>>>> public void run() { >>>>> getUnsafe().monitorEnter(MonitorMystery.class); >>>>> } >>>>> }; >>>>> t.start(); >>>>> Thread.sleep(100); >>>>> System.out.println("Trying to synchronize"); >>>>> synchronized (MonitorMystery.class) { >>>>> System.out.println("Managed to synchronized"); >>>>> } >>>>> } >>>>> } >>>>> >>>>> We now see that we never manage to synchronize in the main thread >>>>> and in >>>>> fact if you do a thread dump you will see a deadlock involving only a >>>>> single thread :-) >>>>> >>>>> This is why it is so important to use the correct idioms. In my >>>>> experience, there are very few Java programmers who get this right. >>>>> Brian Goetz's book is correct, but there are other books out there >>>>> that >>>>> do a shocking job of mangling the idiom. >>>>> >>>>> Whenever possible, use synchronized() { }. If not, IMHO it would be >>>>> preferable to switch to ReentrantLock. >>>>> >>>>> Regards >>>>> >>>>> Heinz >>>>> -- >>>>> Dr Heinz M. Kabutz (PhD CompSci) >>>>> Author of "The Java(tm) Specialists' Newsletter" >>>>> Oracle Java Champion 2005-2013 >>>>> JavaOne Rock Star Speaker 2012 >>>>> http://www.javaspecialists.eu >>>>> Tel: +30 69 75 595 262 >>>>> Skype: kabutz >>>>> >>>>> >>>>> >>>>> David M. Lloyd wrote: >>>>>> Making the language Kindergarten-friendly at the cost of general >>>>>> usefulness is a mistake, IMO. And anyway there's nothing that is >>>>>> less >>>>>> safe about a Monitors class than ReentrantLock; on the other hand, >>>>>> monitors continue to be considerably lighter (size and (for most of >>>>>> the history of JUC) speed) by every measurement I've ever made. I >>>>>> would advise monitors over ReentrantLock 9 times out of 10 in any of >>>>>> our code. >>>>>> >>>>>> I just don't think your metaphors - neither of monitor methods being >>>>>> dangerous, nor of Java developers being infants - are really apt. >>>>>> >>>>>> On 03/02/2014 02:51 AM, Dr Heinz M. Kabutz wrote: >>>>>>> With a curious 9 months old crawling around the house, I've just >>>>>>> moved >>>>>>> the sharp knives to the top draw in the kitchen - out of reach. I >>>>>>> don't >>>>>>> think we should be encouraging people to use monitor.tryLock() for >>>>>>> various reasons: >>>>>>> >>>>>>> 1. We have a richer interface with Lock/ReentrantLock, including >>>>>>> better >>>>>>> Condition that allow easier timed wait idioms. >>>>>>> >>>>>>> 2. It is just too easy to get the idioms wrong for Lock.lock() and >>>>>>> Lock.unlock(). Every time I show this idiom some people in the >>>>>>> audience >>>>>>> start arguing with me: >>>>>>> >>>>>>> lock.lock(); >>>>>>> try { >>>>>>> // do something >>>>>>> } finally { >>>>>>> lock.unlock(); >>>>>>> } >>>>>>> >>>>>>> IMHO, this is really an edge case that might be useful to have >>>>>>> semi-accessible at some point, but not something that should >>>>>>> generally >>>>>>> be done. It belongs in the same draw as the sharp knives and the >>>>>>> ability to cause arbitrary asynchronous exceptions (which has been >>>>>>> made >>>>>>> more difficult to do in Java 8). >>>>>>> >>>>>>> Brian Goetz wrote: >>>>>>>> Except that Lock has features that are not supported by intrinsic >>>>>>>> locks (timed wait, interruptible wait.) So the Lock returned >>>>>>>> would >>>>>>>> not conform to Lock's contract, and attempting to call these >>>>>>>> methods >>>>>>>> would probably throw UOE. >>>>>>>> >>>>>>>> On 2/27/2014 6:12 AM, Stephen Colebourne wrote: >>>>>>>>> On 26 February 2014 20:54, Martin Buchholz >>>>>>>>> wrote: >>>>>>>>>> It does seem that being able to tell whether a java object >>>>>>>>>> monitor is >>>>>>>>>> currently locked is useful for debugging and monitoring - there >>>>>>>>>> should be a >>>>>>>>>> way to do that. >>>>>>>>> >>>>>>>>> Perhaps it would be useful to be able to expose a java object >>>>>>>>> monitor >>>>>>>>> as an instance of Lock? >>>>>>>>> >>>>>>>>> Lock lk = Lock.ofMonitor(object) >>>>>>>>> if (lk.tryLock()) { >>>>>>>>> ... >>>>>>>>> } >>>>>>>>> >>>>>>>>> Such a method feels like it would be a useful missing link >>>>>>>>> between >>>>>>>>> synchronized and locks. >>>>>>>>> >>>>>>>>> Stephen >>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> > From jeroen at sumatra.nl Tue Mar 4 07:41:08 2014 From: jeroen at sumatra.nl (Jeroen Frijters) Date: Tue, 4 Mar 2014 07:41:08 +0000 Subject: JEP 193: Enhanced Volatiles In-Reply-To: <5315015E.7010602@oracle.com> References: <20140303192647.75AB814B91@eggemoggin.niobe.net> <5315015E.7010602@oracle.com> Message-ID: Brian Goetz wrote: > Embedded in this proposal is the desire to not provide a full-blown > "lvalue" form for variables; supporting any form of pass-by-reference at > the language level is a super-non-goal here. Why is this? It solves these problems in an extremely clean way and also provides lots of other value (for example, for JEP 191: Foreign Function Interface). I understand pass-by-reference is an expensive feature, but IMNSHO poluting Java with this proposal will prove to be more expensive in the long run. It's like erased generics all over again. Regards, Jeroen From N.LEPICARD at chu-tours.fr Tue Mar 4 10:45:33 2014 From: N.LEPICARD at chu-tours.fr (LE PICARD NICOLAS) Date: Tue, 4 Mar 2014 10:45:33 +0000 Subject: How to close a Process and having shutdown hooks called ? Message-ID: <6C970D250A1EFC45AF831AFA520141DFBAD025@mbxbr02> Hello everyone ! I looked for the answer in this list and did not find anything relevant. I don't know it it's possible to close a Process et call shutdown hooks automatically. I looked into the code and found it was not possible (in jdk7). When we call destroy() on a Process, it will call terminateProcess of ProcessImpl class. This link shows that a TerminateProcess < kills > the process and WH_CBT hooks are NOT called. http://msdn.microsoft.com/en-us/library/windows/desktop/ms686722(v=vs.85).aspx Calling exitProcess (instead of TeminateProcess) seems to be dangerous ... but I don't understand why (ok, dlls could be locked, but when you do a CTRL +C it calls an exitProcess... so what's the problem ???) So I ask < how can we close a process, with the hooks called ? >. My knowledge is way smaller than people on openjdk... so I hope someone has an answer or a workaround. Byte the way, I looked for sending signals (SIGINT for Windows, SIGKILL for linux etc) to close a process. Maybe I'm wrong, but a solution could be to add to ProcessImpl_md.c : #include JNIEXPORT jboolean JNICALL Java_java_lang_ProcessImpl_CloseHandleWithHooks(JNIEnv *env, jclass ignored, jlong handle) { raise(SIGINT) ; } I think,it will call an ExitProcess so ... dangerous or not ? Of course, we have to add also a function in ProcessImpl and make call available from Process through an abstract function like < close() > Any clever thoughts on this subject (I'm sure it is a common problem...) ? Thanks :) Regards. Nicolas Le Picard From rednaxelafx at gmail.com Tue Mar 4 11:51:27 2014 From: rednaxelafx at gmail.com (Krystal Mok) Date: Tue, 4 Mar 2014 03:51:27 -0800 Subject: How to close a Process and having shutdown hooks called ? In-Reply-To: <6C970D250A1EFC45AF831AFA520141DFBAD025@mbxbr02> References: <6C970D250A1EFC45AF831AFA520141DFBAD025@mbxbr02> Message-ID: Hi Nicolas, Looks like a well discussed question. On Posix systems, SIGTERM should work for you. That's the default signal sent by the 'kill' command on Linux. e.g. please take a look here: http://stackoverflow.com/questions/2541597/how-to-gracefully-handle-the-sigkill-signal-in-java - Kris On Tue, Mar 4, 2014 at 2:45 AM, LE PICARD NICOLAS wrote: > Hello everyone ! > > I looked for the answer in this list and did not find anything relevant. > > I don't know it it's possible to close a Process et call shutdown hooks > automatically. I looked into the code and found it was not possible (in > jdk7). > When we call destroy() on a Process, it will call terminateProcess of > ProcessImpl class. > This link shows that a TerminateProcess < kills > the process and WH_CBT > hooks are NOT called. > > http://msdn.microsoft.com/en-us/library/windows/desktop/ms686722(v=vs.85).aspx > Calling exitProcess (instead of TeminateProcess) seems to be dangerous ... > but I don't understand why (ok, dlls could be locked, but when you do a > CTRL +C it calls an exitProcess... so what's the problem ???) > > So I ask < how can we close a process, with the hooks called ? >. My > knowledge is way smaller than people on openjdk... so I hope someone has an > answer or a workaround. > > Byte the way, I looked for sending signals (SIGINT for Windows, SIGKILL > for linux etc) to close a process. > Maybe I'm wrong, but a solution could be to add to ProcessImpl_md.c : > > #include > > > > JNIEXPORT jboolean JNICALL > > Java_java_lang_ProcessImpl_CloseHandleWithHooks(JNIEnv *env, jclass > ignored, jlong handle) > > { > > raise(SIGINT) ; > > } > > I think,it will call an ExitProcess so ... dangerous or not ? > Of course, we have to add also a function in ProcessImpl and make call > available from Process through an abstract function like < close() > > > > Any clever thoughts on this subject (I'm sure it is a common problem...) ? > Thanks :) > > > Regards. > > Nicolas Le Picard > > From dl at cs.oswego.edu Tue Mar 4 12:05:33 2014 From: dl at cs.oswego.edu (Doug Lea) Date: Tue, 04 Mar 2014 07:05:33 -0500 Subject: JEP 193: Enhanced Volatiles In-Reply-To: References: <20140303192647.75AB814B91@eggemoggin.niobe.net> <5315015E.7010602@oracle.com> Message-ID: <5315C18D.5030608@cs.oswego.edu> On 03/04/2014 02:41 AM, Jeroen Frijters wrote: > Brian Goetz wrote: >> Embedded in this proposal is the desire to not provide a full-blown >> "lvalue" form for variables; supporting any form of pass-by-reference at >> the language level is a super-non-goal here. > > Why is this? It solves these problems in an extremely clean way and also > provides lots of other value (for example, for JEP 191: Foreign Function > Interface). > > I understand pass-by-reference is an expensive feature, but IMNSHO poluting > Java with this proposal will prove to be more expensive in the long run. It's > like erased generics all over again. > The expensive version of pass-by-reference is already supported using java.lang.reflect.Field. You can think of .volatile as a version of such mechanics that only works within the context of a single expression, not across method calls. There is plenty of precedent for this. For example you cannot emulate the "+=" operator as a standalone method without resorting to reflection. You can view this JEP as an extension mechanism for safely adding similar l-value-based operators. (Although only the JDK can implement these extensions.) -Doug From Alan.Bateman at oracle.com Tue Mar 4 12:12:11 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 04 Mar 2014 12:12:11 +0000 Subject: How to close a Process and having shutdown hooks called ? In-Reply-To: References: <6C970D250A1EFC45AF831AFA520141DFBAD025@mbxbr02> Message-ID: <5315C31B.6090109@oracle.com> On 04/03/2014 11:51, Krystal Mok wrote: > Hi Nicolas, > > Looks like a well discussed question. On Posix systems, SIGTERM should work > for you. That's the default signal sent by the 'kill' command on Linux. > e.g. please take a look here: > http://stackoverflow.com/questions/2541597/how-to-gracefully-handle-the-sigkill-signal-in-java > > - Kris > I think he's on Windows and is looking for destroy to use something other than TerminateProcess. As background, the destroy method was confusingly specified to kill the sub-process forcibly but it wasn't implemented this way everywhere. On Unix/Linux then the long standing implementation used SIGTERM and so no guarantee that it would cause the sub-process to terminate. This mismatch was examined in JDK 8 (you'll need to go through the archives of this mailing list to see the discussion) and the javadoc updated to make it clear that it is implementation specific as to whether it is done forcibly or not. In addition a new destroyForcibly was added to do the SIGKILL or TerminateProcess for cases where you really want to kill the child. There isn't a corresponding destroyGracefully but clearly this would be useful if were feasible to implement everywhere. -Alan. From N.LEPICARD at chu-tours.fr Tue Mar 4 13:09:21 2014 From: N.LEPICARD at chu-tours.fr (LE PICARD NICOLAS) Date: Tue, 4 Mar 2014 13:09:21 +0000 Subject: How to close a Process and having shutdown hooks called ? In-Reply-To: <5315C31B.6090109@oracle.com> References: <6C970D250A1EFC45AF831AFA520141DFBAD025@mbxbr02> <5315C31B.6090109@oracle.com> Message-ID: <6C970D250A1EFC45AF831AFA520141DFBAD30D@mbxbr02> I didn't know for jdk8 functions destroy and the new one destroyForcibly... And Jonathan was right in his previous answer, I was looking for a solution in Java, I mean a portable one like in Process class, like the "destroyGracefully". I am looking to signals because it seems to be a simple way to achieve this "portable" solution, maybe I'm wrong. It would be useful (as you said) to have a function to kill "gracefully" through Process class, no ? Nicolas Le Picard -----Message d'origine----- De?: Alan Bateman [mailto:Alan.Bateman at oracle.com] Envoy??: mardi 4 mars 2014 13:12 ??: Krystal Mok Cc?: LE PICARD NICOLAS; core-libs-dev at openjdk.java.net Objet?: Re: How to close a Process and having shutdown hooks called ? On 04/03/2014 11:51, Krystal Mok wrote: > Hi Nicolas, > > Looks like a well discussed question. On Posix systems, SIGTERM should > work for you. That's the default signal sent by the 'kill' command on Linux. > e.g. please take a look here: > http://stackoverflow.com/questions/2541597/how-to-gracefully-handle-th > e-sigkill-signal-in-java > > - Kris > I think he's on Windows and is looking for destroy to use something other than TerminateProcess. As background, the destroy method was confusingly specified to kill the sub-process forcibly but it wasn't implemented this way everywhere. On Unix/Linux then the long standing implementation used SIGTERM and so no guarantee that it would cause the sub-process to terminate. This mismatch was examined in JDK 8 (you'll need to go through the archives of this mailing list to see the discussion) and the javadoc updated to make it clear that it is implementation specific as to whether it is done forcibly or not. In addition a new destroyForcibly was added to do the SIGKILL or TerminateProcess for cases where you really want to kill the child. There isn't a corresponding destroyGracefully but clearly this would be useful if were feasible to implement everywhere. -Alan. From peter.levart at gmail.com Tue Mar 4 14:47:19 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 04 Mar 2014 15:47:19 +0100 Subject: How to close a Process and having shutdown hooks called ? In-Reply-To: <6C970D250A1EFC45AF831AFA520141DFBAD30D@mbxbr02> References: <6C970D250A1EFC45AF831AFA520141DFBAD025@mbxbr02> <5315C31B.6090109@oracle.com> <6C970D250A1EFC45AF831AFA520141DFBAD30D@mbxbr02> Message-ID: <5315E777.4020008@gmail.com> On 03/04/2014 02:09 PM, LE PICARD NICOLAS wrote: > I didn't know for jdk8 functions destroy and the new one destroyForcibly... > > And Jonathan was right in his previous answer, I was looking for a solution in Java, I mean a portable one like in Process class, like the "destroyGracefully". > I am looking to signals because it seems to be a simple way to achieve this "portable" solution, maybe I'm wrong. > > It would be useful (as you said) to have a function to kill "gracefully" through Process class, no ? > > Nicolas Le Picard Hi Nicolas, So you're spawning a Java sub-process from a Java master process using java.lang.Process, do I understand correctly? Are you in control of the code that represents the child sub-process? Is this code already using System.in (STDIN) stream for anything? If the answers are YES and NO respectively, then you may be able to use the System.in in the sub-process (spawn a special monitoring thread) and Process.getOutputStream() in the master process to establish a one way channel for passing commands in direction: master process -> sub-process. One of those commands could be "shutdown" for example, that would trigger a System.exit() in the sub-process. This way you could make the shut-down hooks in sub-process be executed before exiting... Regards, Peter > > -----Message d'origine----- > De : Alan Bateman [mailto:Alan.Bateman at oracle.com] > Envoy? : mardi 4 mars 2014 13:12 > ? : Krystal Mok > Cc : LE PICARD NICOLAS; core-libs-dev at openjdk.java.net > Objet : Re: How to close a Process and having shutdown hooks called ? > > On 04/03/2014 11:51, Krystal Mok wrote: >> Hi Nicolas, >> >> Looks like a well discussed question. On Posix systems, SIGTERM should >> work for you. That's the default signal sent by the 'kill' command on Linux. >> e.g. please take a look here: >> http://stackoverflow.com/questions/2541597/how-to-gracefully-handle-th >> e-sigkill-signal-in-java >> >> - Kris >> > I think he's on Windows and is looking for destroy to use something other than TerminateProcess. > > As background, the destroy method was confusingly specified to kill the sub-process forcibly but it wasn't implemented this way everywhere. On Unix/Linux then the long standing implementation used SIGTERM and so no guarantee that it would cause the sub-process to terminate. This mismatch was examined in JDK 8 (you'll need to go through the archives of this mailing list to see the discussion) and the javadoc updated to make it clear that it is implementation specific as to whether it is done forcibly or not. In addition a new destroyForcibly was added to do the SIGKILL or TerminateProcess for cases where you really want to kill the child. There isn't a corresponding destroyGracefully but clearly this would be useful if were feasible to implement everywhere. > > -Alan. From N.LEPICARD at chu-tours.fr Tue Mar 4 15:05:43 2014 From: N.LEPICARD at chu-tours.fr (LE PICARD NICOLAS) Date: Tue, 4 Mar 2014 15:05:43 +0000 Subject: How to close a Process and having shutdown hooks called ? In-Reply-To: <5315E777.4020008@gmail.com> References: <6C970D250A1EFC45AF831AFA520141DFBAD025@mbxbr02> <5315C31B.6090109@oracle.com> <6C970D250A1EFC45AF831AFA520141DFBAD30D@mbxbr02> <5315E777.4020008@gmail.com> Message-ID: <6C970D250A1EFC45AF831AFA520141DFBAD592@mbxbr02> Exactly ! In fact, I'm in mastery of ... nothing ! But I tried to workaround this problem and found that Java Process class lacks something ! I was working in Eclipse and you can process while testing (the red button in console view) but shutdown hooks are not called. So I dug a little to understand why Eclipse team said that it is not possible (up to now). Indeed, Eclipse spawns a new Process Object (a new JVM in fact) but can't close it gracefully. I think other application / programs may need such functionnality so I post on this list to have advices of specialists of openJdk. You are right again on the second part ! Actually I did exactly that in my applications, only for debug/test, very simple : boolean loopz = true; InputStreamReader isr = null; BufferedReader br = null; try { isr = new InputStreamReader(System.in); br = new BufferedReader(isr); while (loopz) { String userInput = br.readLine(); System.out.println("input => "+userInput); if (userInput.equalsIgnoreCase("quit") || userInput.equalsIgnoreCase("exit")) { System.exit(0); } } } catch (Exception er) { er.printStackTrace(); loopz = false; } finally { try { br.close(); } catch (Exception e) {} try { isr.close(); } catch (Exception e) {} } However I think it could be a good add to Java to make a Process having better control on its own child termination. Thanks ! Nicolas Le Picard -----Message d'origine----- De?: Peter Levart [mailto:peter.levart at gmail.com] Envoy??: mardi 4 mars 2014 15:47 ??: LE PICARD NICOLAS; Alan Bateman; Krystal Mok Cc?: core-libs-dev at openjdk.java.net Objet?: Re: How to close a Process and having shutdown hooks called ? On 03/04/2014 02:09 PM, LE PICARD NICOLAS wrote: > I didn't know for jdk8 functions destroy and the new one destroyForcibly... > > And Jonathan was right in his previous answer, I was looking for a solution in Java, I mean a portable one like in Process class, like the "destroyGracefully". > I am looking to signals because it seems to be a simple way to achieve this "portable" solution, maybe I'm wrong. > > It would be useful (as you said) to have a function to kill "gracefully" through Process class, no ? > > Nicolas Le Picard Hi Nicolas, So you're spawning a Java sub-process from a Java master process using java.lang.Process, do I understand correctly? Are you in control of the code that represents the child sub-process? Is this code already using System.in (STDIN) stream for anything? If the answers are YES and NO respectively, then you may be able to use the System.in in the sub-process (spawn a special monitoring thread) and Process.getOutputStream() in the master process to establish a one way channel for passing commands in direction: master process -> sub-process. One of those commands could be "shutdown" for example, that would trigger a System.exit() in the sub-process. This way you could make the shut-down hooks in sub-process be executed before exiting... Regards, Peter > > -----Message d'origine----- > De : Alan Bateman [mailto:Alan.Bateman at oracle.com] Envoy? : mardi 4 > mars 2014 13:12 ? : Krystal Mok Cc : LE PICARD NICOLAS; > core-libs-dev at openjdk.java.net Objet : Re: How to close a Process and > having shutdown hooks called ? > > On 04/03/2014 11:51, Krystal Mok wrote: >> Hi Nicolas, >> >> Looks like a well discussed question. On Posix systems, SIGTERM >> should work for you. That's the default signal sent by the 'kill' command on Linux. >> e.g. please take a look here: >> http://stackoverflow.com/questions/2541597/how-to-gracefully-handle-t >> h >> e-sigkill-signal-in-java >> >> - Kris >> > I think he's on Windows and is looking for destroy to use something other than TerminateProcess. > > As background, the destroy method was confusingly specified to kill the sub-process forcibly but it wasn't implemented this way everywhere. On Unix/Linux then the long standing implementation used SIGTERM and so no guarantee that it would cause the sub-process to terminate. This mismatch was examined in JDK 8 (you'll need to go through the archives of this mailing list to see the discussion) and the javadoc updated to make it clear that it is implementation specific as to whether it is done forcibly or not. In addition a new destroyForcibly was added to do the SIGKILL or TerminateProcess for cases where you really want to kill the child. There isn't a corresponding destroyGracefully but clearly this would be useful if were feasible to implement everywhere. > > -Alan. From peter.levart at gmail.com Tue Mar 4 15:13:46 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 04 Mar 2014 16:13:46 +0100 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> Message-ID: <5315EDAA.5020801@gmail.com> On 03/04/2014 01:14 AM, Brian Burkhalter wrote: > - add AtomicReferenceFieldUpdater-type constant for stringCache initialization Hi Brian, By using volatile read and CAS, there's still a chance that multiple concurrent threads will be invoking the layoutChars(true) concurrently, but you guarantee that only a single instance of String will ever be returned as a result of the toString() method. Is that what you were pursuing? Regards, Peter From david.lloyd at redhat.com Tue Mar 4 15:32:56 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 04 Mar 2014 09:32:56 -0600 Subject: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods In-Reply-To: <53154C59.1000001@oracle.com> References: <53110B02.7070602@oracle.com> <5312F127.60903@javaspecialists.eu> <53136337.9040001@redhat.com> <53137CE2.1010102@javaspecialists.eu> <53147C11.1010906@redhat.com> <53154C59.1000001@oracle.com> Message-ID: <5315F228.1030503@redhat.com> On 03/03/2014 09:45 PM, David Holmes wrote: > On 3/03/2014 10:56 PM, David M. Lloyd wrote: >> Yes, that would necessarily be the contract of a Monitors class, just as >> it is part of the contract of Lock today. If your argument is that it >> shouldn't be allowed because it might be used wrong, we might as well >> just delete most of the JDK, ReentrantLock included, since it suffers >> from the exact same potential problem. The difference is that monitors >> have a simple API in the form of synchronized that people were in the >> past and would continue to be free (and recommended) to use. > > We should not introduce anything that allows something that was > guaranteed to be safe by the language, to become unsafe. Define 'safe'. Because I don't think it's unsafe, any more than unpaired lock/unlock are. There is no uninitialized memory being accessed, no way to bypass security checks, no way to manipulate memory directly, etc. I find this argument to be particularly weak without specific cases. As far as I can tell, the language doesn't make it safe, it makes it *convenient*, and that's a big distinction. There are two cases I can see that are potentially problematic: extra acquires, and extra releases. The risk of extra acquires is that the thread might exit while still holding the lock, leaving it locked forever. However, just parking a thread indefinitely (via various means) within a synchronized block is equally unsafe. The risk of extra releases is that you'll hit IllegalMonitorState exceptions and thread-safety/publication problems. But a user can make this same mistake today with locks. The difference is, that in most cases people would choose the convenience of synchronized unless there is a specific reason for it, making this problem far less likely than the corresponding locks case. -- - DML From mike.duigou at oracle.com Tue Mar 4 17:21:26 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 4 Mar 2014 09:21:26 -0800 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: <5315EDAA.5020801@gmail.com> References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <5315EDAA.5020801@gmail.com> Message-ID: On Mar 4 2014, at 07:13 , Peter Levart wrote: > On 03/04/2014 01:14 AM, Brian Burkhalter wrote: >> - add AtomicReferenceFieldUpdater-type constant for stringCache initialization > > Hi Brian, > > By using volatile read and CAS, there's still a chance that multiple concurrent threads will be invoking the layoutChars(true) concurrently, but you guarantee that only a single instance of String will ever be returned as a result of the toString() method. Is that what you were pursuing? Yes. (I provided the AtomicReferenceFieldUpdater code). The previous implementation had a benign data race that could result in a later layoutChars result replacing an earlier result and multiple string instances being returned. The new implementation, at small cost, prevents multiple different instances from being returned. Mike From brian.burkhalter at oracle.com Tue Mar 4 19:53:15 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 4 Mar 2014 11:53:15 -0800 Subject: [REFRESH] JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger In-Reply-To: References: <5305D6EB.30806@oracle.com> <53064179.2060703@gmail.com> <530660FA.1060407@oracle.com> <96CF3236-4E65-4D64-BCF3-1E9660D29BAA@oracle.com> <5306BC4B.4090909@oracle.com> <8229AE11-1ABF-474D-961F-BBD5ACA3DD82@oracle.com> <61708919-691D-4EBF-8685-0CC5FC309701@oracle.com> <10AE28AF-8765-430C-9D83-D0A88062B096@oracle.com> <247D03A1-0D88-437D-B2F1-9CD5DAE8492D@oracle.com> <8520F61D-B0CE-4E83-8336-938C745823D1@oracle.com> <5311396C.3020509@oracle.com> Message-ID: <442F2C3D-F4F9-4A41-ABE5-669A9F6F3A1C@oracle.com> On Mar 3, 2014, at 11:37 AM, Brian Burkhalter wrote: >> The fields bitCount, bitLength, and lowestSetBit appear in the serialized form only for backward compatibility and are otherwise ignored, so their @serialField entries should just say that instead of describing how they were formerly used. Also, firstNonzeroByteNum is missing a @serialField entry, and it should have the same description as the others. > > Corrected I found another small item here. Currently we have for serialPersistentFields the following: 4203 * @serialField magnitude int[] 4204 * magnitude array of this BigInteger and 4216 new ObjectStreamField("magnitude", byte[].class), In the @serialField annotation the type should also be byte[], no? Thanks, Brian From vladimir.x.ivanov at oracle.com Tue Mar 4 20:00:24 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 05 Mar 2014 00:00:24 +0400 Subject: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed) Message-ID: <531630D8.7030402@oracle.com> http://cr.openjdk.java.net/~vlivanov/8036117/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8036117 84 lines changed: 74 ins; 3 del; 7 mod I have to revert a cleanup I did for 8027827. MethodHandle.invokeWithArguments (and generic invocation) has unpleasant peculiarity in behavior when used with VarargsCollector. So, unfortunately, invokeWithArguments is not an option there. Looking at the API (excerpts from javadoc [1] [2]), the following condition doesn't hold in that case: "trailing parameter type of the caller is a reference type identical to or assignable to the trailing parameter type of the adapter". Example: target.invokeWithArguments((Object[])args) => target.invoke((Object)o1,(Object)o2,(Object)o3) =/> target.invokeExact((Object)o1, (Object)o2, (Object[])o3) because Object !<: Object[]. The fix is to skip unnecessary conversion when invoking a method handle and just do a pairwise type conversion. Testing: failing test case, nashorn w/ experimental features (octane) Thanks! Best regards, Vladimir Ivanov [1] MethodHandle.invokeWithArguments "Performs a variable arity invocation, ..., as if via an inexact invoke from a call site which mentions only the type Object, and whose arity is the length of the argument array." [2] MethodHandle.asVarargsCollector "When called with plain, inexact invoke, if the caller type is the same as the adapter, the adapter invokes the target as with invokeExact. (This is the normal behavior for invoke when types match.) Otherwise, if the caller and adapter arity are the same, and the trailing parameter type of the caller is a reference type identical to or assignable to the trailing parameter type of the adapter, the arguments and return values are converted pairwise, as if by asType on a fixed arity method handle. Otherwise, the arities differ, or the adapter's trailing parameter type is not assignable from the corresponding caller type. In this case, the adapter replaces all trailing arguments from the original trailing argument position onward, by a new array of type arrayType, whose elements comprise (in order) the replaced arguments." From fweimer at redhat.com Tue Mar 4 20:22:44 2014 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 04 Mar 2014 21:22:44 +0100 Subject: Fedora sun.misc.Unsafe statistics Message-ID: <53163614.2070802@redhat.com> Out of curiosity, I looked at JAR files in all RPMs in Fedora rawhide (the development version of Fedora that will turn into Fedora 21) and counted the number of RPM packages which had Java classes referencing individual methods in sun.misc.Unsafe. The attached table is sorted by decreasing package count, and grouped by method name and descriptor. These numbers do not include references through reflection, for obvious reasons. Java programming practices are sometimes at odds with distribution packaging, and due to licensing bias, the Fedora repository might not be representative of the general Java ecosystem. However, the statistics cover 1177 Java source RPMs containing 550829 classes in 570477 versions, so it's quite a bit of code, despite the fairly low number of references to sun.misc.Unsafe. -- Florian Weimer / Red Hat Product Security Team -------------- next part -------------- name | descriptor | count ----------------------+------------------------------------------------------------+------- objectFieldOffset | (Ljava/lang/reflect/Field;)J | 17 arrayBaseOffset | (Ljava/lang/Class;)I | 14 putObject | (Ljava/lang/Object;JLjava/lang/Object;)V | 12 arrayIndexScale | (Ljava/lang/Class;)I | 11 getLong | (Ljava/lang/Object;J)J | 11 compareAndSwapInt | (Ljava/lang/Object;JII)Z | 9 compareAndSwapLong | (Ljava/lang/Object;JJJ)Z | 9 getUnsafe | ()Lsun/misc/Unsafe; | 9 compareAndSwapObject | (Ljava/lang/Object;JLjava/lang/Object;Ljava/lang/Object;)Z | 8 getObject | (Ljava/lang/Object;J)Ljava/lang/Object; | 8 getInt | (Ljava/lang/Object;J)I | 7 putInt | (Ljava/lang/Object;JI)V | 6 putLong | (Ljava/lang/Object;JJ)V | 6 getObjectVolatile | (Ljava/lang/Object;J)Ljava/lang/Object; | 5 putBoolean | (Ljava/lang/Object;JZ)V | 5 putByte | (Ljava/lang/Object;JB)V | 5 putChar | (Ljava/lang/Object;JC)V | 5 putDouble | (Ljava/lang/Object;JD)V | 5 putFloat | (Ljava/lang/Object;JF)V | 5 putObjectVolatile | (Ljava/lang/Object;JLjava/lang/Object;)V | 5 putOrderedObject | (Ljava/lang/Object;JLjava/lang/Object;)V | 5 putShort | (Ljava/lang/Object;JS)V | 5 getBoolean | (Ljava/lang/Object;J)Z | 4 getByte | (Ljava/lang/Object;J)B | 4 getChar | (Ljava/lang/Object;J)C | 4 getDouble | (Ljava/lang/Object;J)D | 4 getFloat | (Ljava/lang/Object;J)F | 4 getInt | (J)I | 4 getLong | (J)J | 4 getShort | (J)S | 4 getShort | (Ljava/lang/Object;J)S | 4 park | (ZJ)V | 4 putInt | (JI)V | 4 putLong | (JJ)V | 4 putShort | (JS)V | 4 throwException | (Ljava/lang/Throwable;)V | 4 unpark | (Ljava/lang/Object;)V | 4 copyMemory | (JJJ)V | 3 copyMemory | (Ljava/lang/Object;JLjava/lang/Object;JJ)V | 3 getByte | (J)B | 3 putByte | (JB)V | 3 putOrderedInt | (Ljava/lang/Object;JI)V | 3 allocateInstance | (Ljava/lang/Class;)Ljava/lang/Object; | 2 defineClass | (Ljava/lang/String;[BII)Ljava/lang/Class; | 2 getDouble | (J)D | 2 getFloat | (J)F | 2 putDouble | (JD)V | 2 putFloat | (JF)V | 2 addressSize | ()I | 1 getLong | (Ljava/lang/Object;I)J | 1 monitorEnter | (Ljava/lang/Object;)V | 1 monitorExit | (Ljava/lang/Object;)V | 1 setMemory | (JJB)V | 1 (53 rows) From stuart.marks at oracle.com Tue Mar 4 21:09:19 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 04 Mar 2014 13:09:19 -0800 Subject: [REFRESH] JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger In-Reply-To: References: <5305D6EB.30806@oracle.com> <53064179.2060703@gmail.com> <530660FA.1060407@oracle.com> <96CF3236-4E65-4D64-BCF3-1E9660D29BAA@oracle.com> <5306BC4B.4090909@oracle.com> <8229AE11-1ABF-474D-961F-BBD5ACA3DD82@oracle.com> <61708919-691D-4EBF-8685-0CC5FC309701@oracle.com> <10AE28AF-8765-430C-9D83-D0A88062B096@oracle.com> <247D03A1-0D88-437D-B2F1-9CD5DAE8492D@oracle.com> <8520F61D-B0CE-4E83-8336-938C745823D1@oracle.com> <5311396C.3020509@oracle.com> Message-ID: <531640FF.2030407@oracle.com> Hi Brian, Just a couple small items. At line 4203, the type of magnitude should be byte[] instead of int[]. Whoops, I could have sworn I wrote that in my previous review, but it must have gotten dropped while I was editing. Sorry about that. For the four compatibility fields in the serial form, the comment is appears in the serialized for backward compatibility Something is missing here. Should it say "appears in the serialized form for backward compatibility" ? The comment block at lines 4300-4306 is good. I might also add a note to say these values are compatible with older implementations. >> There are some things in the serialization doc that ought to be brought up to date, though. Note that the docs for serialPersistentFields, readObject, and writeObject appear in the javadoc output, in the "Serialized Form" page, even though these members are private! > > Isn't this controlled by options passed to the javadoc tool as opposed to settings in the source code? No, serialization is "special" in that all information about the serialized form, including the docs these special private methods and fields, do appear in the Serialized Form output, regardless of the javadoc tool arguments. > I think I'll need another "thumbs up" as this has changed since Paul's approval was posted. Paul is not available this week. If you want to make these corrections and then just push the changeset, it's fine by me; I think it's had enough review. s'marks On 3/3/14 11:37 AM, Brian Burkhalter wrote: > Hi Stuart, > > Thanks for the detailed review! > > Please see the refreshed webrev > http://cr.openjdk.java.net/~bpb/8035279/webrev.02/ and my comments inline, below. > > I think I'll need another "thumbs up" as this has changed since Paul's approval > was posted. > > On Feb 28, 2014, at 5:35 PM, Stuart Marks wrote: > >>> Thanks, Paul. I refreshed the webrev >>> http://cr.openjdk.java.net/~bpb/8035279/webrev.01/ with the agreed upon version. >> >> This is pretty good. After this long, strange trip through the JMM, restoring >> the sentinel values to zeroes and renaming the fields to be explicit about how >> they represent the actual values seems to be the best approach. Paul's >> suggestion about using the term "stable value" in comments is good too. >> >> I took a look at the serialization stuff. The actual serialized form hasn't >> changed, so there should be no compatibility here with previous versions. >> >> There are some things in the serialization doc that ought to be brought up to >> date, though. Note that the docs for serialPersistentFields, readObject, and >> writeObject appear in the javadoc output, in the "Serialized Form" page, even >> though these members are private! > > Isn't this controlled by options passed to the javadoc tool as opposed to > settings in the source code? > >> Per another of Paul's comments, the @serial tag should be removed from >> bitCountPlusOne, bitLengthPlusOne, and lowestSetBitPlusTwo, since these fields >> do not appear in the serialized representation. > > Corrected. > >> The fields bitCount, bitLength, and lowestSetBit appear in the serialized form >> only for backward compatibility and are otherwise ignored, so their >> @serialField entries should just say that instead of describing how they were >> formerly used. Also, firstNonzeroByteNum is missing a @serialField entry, and >> it should have the same description as the others. > > Corrected. > >> Typo at 4236-4237, it says "be\ndefault" instead of "by\ndefault". > > Corrected. > >> The comment at lines 4242-4246 should simply be removed. The first and third >> sentences are redundant with other docs. The second sentence, "The magnitude >> field is used as a temporary store for the byte array that is deserialized" is >> incorrect, as there is no longer a 'magnitude' field; a local is used instead. > > Corrected. > >> The @serialData tag at line 4316 for writeObject is misused; this is really >> intended for *extra* serial data written by writeObject after the >> writeFields() or defaultWriteObject() call, which doesn't occur here. It might >> be worth being explicit in writeObject's doc comment about writing -1's and >> -2's as the values for bitCount, bitLength, lowestSetBit, and >> firstNonzeroByteNum for compatibility with older implementations, even though >> current implementations will ignore these values. > > Corrected. > > On Feb 28, 2014, at 5:54 PM, Stuart Marks wrote: > >> Woops, I forgot a couple points. >> >> The @serial for the 'signum' field at line 130 should be removed. Note that >> even though this has the same name as the field that appears in the serialized >> form, the text from the @serialField tag for 'signum' that's part of the >> serialPersistentFields doc comment is the one that actually appears on the >> "Serialized Form" page. > > Corrected. > >> It might be worthwhile copying the more verbose description from lines 125-128 >> to the @serialField tag text (lines 4206-4207) since this describes the >> requirements on the serialized form more precisely. I hate redundancy in >> documentation, though. > > I opted for not copying the verbiage in the interested of reduced redundancy. > >> Note that the field names in the ObjectStreamField entries of the >> serialPersistentFields array don't necessarily match the actual fields in the >> class. In this case 'signum' matches but the others do not. That's ok. The >> entries in this array describe the field names that are used in the serialized >> output, which is essential for remaining compatible with older versions of >> BigInteger. > > Understood. > >> I checked an old version of BigInteger from 1998 and the field names used here >> match the actual, serialized fields from that old version. > > I verified compatibility with the Java 7 version but no older so this is good > information. > > Thanks, > > Brian From brian.burkhalter at oracle.com Tue Mar 4 21:12:35 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 4 Mar 2014 13:12:35 -0800 Subject: [REFRESH] JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger In-Reply-To: <531640FF.2030407@oracle.com> References: <5305D6EB.30806@oracle.com> <53064179.2060703@gmail.com> <530660FA.1060407@oracle.com> <96CF3236-4E65-4D64-BCF3-1E9660D29BAA@oracle.com> <5306BC4B.4090909@oracle.com> <8229AE11-1ABF-474D-961F-BBD5ACA3DD82@oracle.com> <61708919-691D-4EBF-8685-0CC5FC309701@oracle.com> <10AE28AF-8765-430C-9D83-D0A88062B096@oracle.com> <247D03A1-0D88-437D-B2F1-9CD5DAE8492D@oracle.com> <8520F61D-B0CE-4E83-8336-938C745823D1@oracle.com> <5311396C.3020509@oracle.com> <531640FF.2030407@oracle.com> Message-ID: Hi Stuart, On Mar 4, 2014, at 1:09 PM, Stuart Marks wrote: > Just a couple small items. > > At line 4203, the type of magnitude should be byte[] instead of int[]. Whoops, I could have sworn I wrote that in my previous review, but it must have gotten dropped while I was editing. Sorry about that. I caught that myself and fixed it. > For the four compatibility fields in the serial form, the comment is > > appears in the serialized for backward compatibility > > Something is missing here. Should it say "appears in the serialized form for backward compatibility" ? I also caught and fixed that. > The comment block at lines 4300-4306 is good. I might also add a note to say these values are compatible with older implementations. Will do (I'll refresh the updated webrev at the link below). >>> There are some things in the serialization doc that ought to be brought up to date, though. Note that the docs for serialPersistentFields, readObject, and writeObject appear in the javadoc output, in the "Serialized Form" page, even though these members are private! >> >> Isn't this controlled by options passed to the javadoc tool as opposed to settings in the source code? > > No, serialization is "special" in that all information about the serialized form, including the docs these special private methods and fields, do appear in the Serialized Form output, regardless of the javadoc tool arguments. Thanks for the clarification. >> I think I'll need another "thumbs up" as this has changed since Paul's approval was posted. > > Paul is not available this week. If you want to make these corrections and then just push the changeset, it's fine by me; I think it's had enough review. Sounds good. http://cr.openjdk.java.net/~bpb/8035279/webrev.03/ I think I have to get a CCC request approved first however but if the approval is in place I can push immediately thereafter. Thanks, Brian From david.lloyd at redhat.com Tue Mar 4 21:16:49 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 04 Mar 2014 15:16:49 -0600 Subject: JEP 193: Enhanced Volatiles In-Reply-To: <531507D0.9070907@redhat.com> References: <20140303192647.75AB814B91@eggemoggin.niobe.net> <5315015E.7010602@oracle.com> <531507D0.9070907@redhat.com> Message-ID: <531642C1.7040609@redhat.com> On 03/03/2014 04:53 PM, David M. Lloyd wrote: > On 03/03/2014 04:25 PM, Brian Goetz wrote: >>> Posted: http://openjdk.java.net/jeps/193 >> >> Some follow-up thoughts on teasing apart the issues covered by this JEP. >> >> There are three main layers of questions to answer: >> >> 1. How do we surface the various pieces of this into the programming >> model? This includes language syntax (e.g., >> x.volatile.compareAndSet()), library surface (e.g., the fictitious and >> not-terribly-satisfying VolatileInt interface), and relevant >> restrictions (e.g., can we do volatile operations on non-volatile fields >> or array elements?) >> [...and then...] >> 2. Translation to bytecodes. What bytecode should javac emit when it >> encounters an volatile accessor or atomic update? We've identified a >> handful of candidates: >> >> 2a: new bytecodes. This is the most direct and pure, but most intrusive >> (and least extensible), means of delivering on the promise of "it's time >> to move this stuff into the programming model proper." The "wide" >> bytecode offers a means to express fenced variants of >> {get,put}{field,static} with only a single new bytecode, but this >> doesn't scale well to CAS (explosion of data types and data locations >> (static field, instance field, array element)), which is really the >> important case. > > Somewhere between new bytecodes and field handles, perhaps a single > bytecode could suffice - one which is similar to getfield except instead > of reading the field, it pushes a virtual "object" on to the stack which > can then only be operated upon by invokeinterface on the pertinent > "VolatileXxx" interface and otherwise doesn't have a real "type" per se. I suppose you'd also need a second bytecode for doing the same thing with array elements like *aload, if that branch of this idea is pursued. -- - DML From stuart.marks at oracle.com Tue Mar 4 21:38:57 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 04 Mar 2014 13:38:57 -0800 Subject: [REFRESH] JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger In-Reply-To: References: <5305D6EB.30806@oracle.com> <53064179.2060703@gmail.com> <530660FA.1060407@oracle.com> <96CF3236-4E65-4D64-BCF3-1E9660D29BAA@oracle.com> <5306BC4B.4090909@oracle.com> <8229AE11-1ABF-474D-961F-BBD5ACA3DD82@oracle.com> <61708919-691D-4EBF-8685-0CC5FC309701@oracle.com> <10AE28AF-8765-430C-9D83-D0A88062B096@oracle.com> <247D03A1-0D88-437D-B2F1-9CD5DAE8492D@oracle.com> <8520F61D-B0CE-4E83-8336-938C745823D1@oracle.com> <5311396C.3020509@oracle.com> <531640FF.2030407@oracle.com> Message-ID: <531647F1.7080401@oracle.com> OK, thanks for fixing up this stuff, even before I had mentioned it. As far as I'm concerned the change is ready to go in, but as you mention we still need to get (internal) approval for spec changes. s'marks On 3/4/14 1:12 PM, Brian Burkhalter wrote: > Hi Stuart, > > On Mar 4, 2014, at 1:09 PM, Stuart Marks wrote: > >> Just a couple small items. >> >> At line 4203, the type of magnitude should be byte[] instead of int[]. Whoops, >> I could have sworn I wrote that in my previous review, but it must have gotten >> dropped while I was editing. Sorry about that. > > I caught that myself and fixed it. > >> For the four compatibility fields in the serial form, the comment is >> >> appears in the serialized for backward compatibility >> >> Something is missing here. Should it say "appears in the serialized form for >> backward compatibility" ? > > I also caught and fixed that. > >> The comment block at lines 4300-4306 is good. I might also add a note to say >> these values are compatible with older implementations. > > Will do (I'll refresh the updated webrev at the link below). > >>>> There are some things in the serialization doc that ought to be brought up >>>> to date, though. Note that the docs for serialPersistentFields, readObject, >>>> and writeObject appear in the javadoc output, in the "Serialized Form" page, >>>> even though these members are private! >>> >>> Isn't this controlled by options passed to the javadoc tool as opposed to >>> settings in the source code? >> >> No, serialization is "special" in that all information about the serialized >> form, including the docs these special private methods and fields, do appear >> in the Serialized Form output, regardless of the javadoc tool arguments. > > Thanks for the clarification. > >>> I think I'll need another "thumbs up" as this has changed since Paul's >>> approval was posted. >> >> Paul is not available this week. If you want to make these corrections and >> then just push the changeset, it's fine by me; I think it's had enough review. > > Sounds good. > > http://cr.openjdk.java.net/~bpb/8035279/webrev.03/ > > I think I have to get a CCC request approved first however but if the approval > is in place I can push immediately thereafter. > > Thanks, > > Brian From brian.burkhalter at oracle.com Tue Mar 4 21:47:17 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 4 Mar 2014 13:47:17 -0800 Subject: [REFRESH] JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger In-Reply-To: <531647F1.7080401@oracle.com> References: <5305D6EB.30806@oracle.com> <53064179.2060703@gmail.com> <530660FA.1060407@oracle.com> <96CF3236-4E65-4D64-BCF3-1E9660D29BAA@oracle.com> <5306BC4B.4090909@oracle.com> <8229AE11-1ABF-474D-961F-BBD5ACA3DD82@oracle.com> <61708919-691D-4EBF-8685-0CC5FC309701@oracle.com> <10AE28AF-8765-430C-9D83-D0A88062B096@oracle.com> <247D03A1-0D88-437D-B2F1-9CD5DAE8492D@oracle.com> <8520F61D-B0CE-4E83-8336-938C745823D1@oracle.com> <5311396C.3020509@oracle.com> <531640FF.2030407@oracle.com> <531647F1.7080401@oracle.com> Message-ID: <973FAB03-2039-46BA-A9C1-330991BC9CDE@oracle.com> On Mar 4, 2014, at 1:38 PM, Stuart Marks wrote: > OK, thanks for fixing up this stuff, even before I had mentioned it. This is a positive race condition! > As far as I'm concerned the change is ready to go in, but as you mention we still need to get (internal) approval for spec changes. OK. I'll push it then once the spec change is approved (assuming it is). Thanks for multiple, careful reviews. Brian From fweimer at redhat.com Tue Mar 4 22:12:51 2014 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 04 Mar 2014 23:12:51 +0100 Subject: JEP 193: Enhanced Volatiles In-Reply-To: <5315C18D.5030608@cs.oswego.edu> References: <20140303192647.75AB814B91@eggemoggin.niobe.net> <5315015E.7010602@oracle.com> <5315C18D.5030608@cs.oswego.edu> Message-ID: <53164FE3.8010507@redhat.com> On 03/04/2014 01:05 PM, Doug Lea wrote: > On 03/04/2014 02:41 AM, Jeroen Frijters wrote: >> Brian Goetz wrote: >>> Embedded in this proposal is the desire to not provide a full-blown >>> "lvalue" form for variables; supporting any form of pass-by-reference at >>> the language level is a super-non-goal here. >> >> Why is this? It solves these problems in an extremely clean way and also >> provides lots of other value (for example, for JEP 191: Foreign Function >> Interface). >> >> I understand pass-by-reference is an expensive feature, but IMNSHO >> poluting >> Java with this proposal will prove to be more expensive in the long >> run. It's >> like erased generics all over again. >> > > The expensive version of pass-by-reference is already supported > using java.lang.reflect.Field. And per the statistics posted in , the slightly faster pointer-to-field-member support is one of the prevalent use cases for sun.misc.Unsafe. That's why I share Jeroen's puzzlement. -- Florian Weimer / Red Hat Product Security Team From dl at cs.oswego.edu Wed Mar 5 00:05:39 2014 From: dl at cs.oswego.edu (Doug Lea) Date: Tue, 04 Mar 2014 19:05:39 -0500 Subject: JEP 193: Enhanced Volatiles In-Reply-To: <53164FE3.8010507@redhat.com> References: <20140303192647.75AB814B91@eggemoggin.niobe.net> <5315015E.7010602@oracle.com> <5315C18D.5030608@cs.oswego.edu> <53164FE3.8010507@redhat.com> Message-ID: <53166A53.2090808@cs.oswego.edu> On 03/04/2014 05:12 PM, Florian Weimer wrote: > On 03/04/2014 01:05 PM, Doug Lea wrote: >> On 03/04/2014 02:41 AM, Jeroen Frijters wrote: >>> I understand pass-by-reference is an expensive feature, but IMNSHO >>> poluting >>> Java with this proposal will prove to be more expensive in the long >>> run. It's >>> like erased generics all over again. >>> >> >> The expensive version of pass-by-reference is already supported >> using java.lang.reflect.Field. > > And per the statistics posted in > , > the slightly faster pointer-to-field-member support is one of the prevalent use > cases for sun.misc.Unsafe. That's why I share Jeroen's puzzlement. > Sorry, I'm not sure what usages you have in mind, or what constructions and implementable JVM mechanics could be used to deal with them? -Doug From brian.goetz at oracle.com Wed Mar 5 00:11:04 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 04 Mar 2014 19:11:04 -0500 Subject: JEP 193: Enhanced Volatiles In-Reply-To: References: <20140303192647.75AB814B91@eggemoggin.niobe.net> <5315015E.7010602@oracle.com> Message-ID: <53166B98.2060200@oracle.com> >> Embedded in this proposal is the desire to not provide a >> full-blown "lvalue" form for variables; supporting any form of >> pass-by-reference at the language level is a super-non-goal here. > > Why is this? It solves these problems in an extremely clean way and > also provides lots of other value (for example, for JEP 191: Foreign > Function Interface). > > I understand pass-by-reference is an expensive feature, but IMNSHO > poluting Java with this proposal will prove to be more expensive in > the long run. It's like erased generics all over again. It has nothing to do with it being expensive (though it is); it has to do with being an outright *bad idea* from a stewardship perspective. Right now, the semantics of method calls in Java are simple -- everything (primitives, object references) is passed by value. Adding pass-by-reference would add significant complexity. And method calls are not a niche feature; that added complexity will be borne by every developer, every day. On the other hand, these weird foo.volatile.xxx operations would be used by .0001% of Java developers (congratulations, you're special!) Doesn't it make sense to move the damage to where it only affects those who need it? Or, looking at it the other way, does it make any sense at all to make a key facet of the language dramatically more complex just so that a niche cadre of sewer-dwelling expert users can more easily write the code they want? Spending most of your time in the performance-critical coding sewers often has the unfortunate effect of anti-qualifying you for reasoning about what platform features would be good for the community as a whole. My goal here is to make sure that expert users can get their job done somehow, *without* making the job of mainstream developers harder. The "add lvalues to Java so experts can write CAS-libraries" fails that test miserably. Note that we're not adding any new functionality here; what we're doing is pulling some functionality from Unsafe into the public programming model. Making drastic changes to a key language feature to support that would be killing a fly with a bazooka. And, as I said at the top, its a bad idea anyway. From stuart.marks at oracle.com Wed Mar 5 01:41:46 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 04 Mar 2014 17:41:46 -0800 Subject: JDK 9 RFR of JDK-8035452: Fix serial lint warnings in core libs In-Reply-To: <53156D3F.8010409@oracle.com> References: <530666A5.8050607@oracle.com> <530C1A87.2070608@oracle.com> <530C3DF5.3040707@oracle.com> <530F9C02.5090500@oracle.com> <5310C044.9090409@oracle.com> <53156D3F.8010409@oracle.com> Message-ID: <531680DA.5000209@oracle.com> Hi Joe, These changes are fine. You might want to update the copyright year of ExceptionProxy.java though. s'marks On 3/3/14 10:05 PM, Joe Darcy wrote: > Hi Stuart, > > Thanks for the careful review. I agree the case of TreeMap.NavigableSbugMap > requires some more investigation. In the meantime, I'd like to proceed with the > revised patch below for EnumSet and ExceptionProxy. > > Thanks, > > -Joe > > diff -r 6cfedc362f48 src/share/classes/java/util/EnumSet.java > --- a/src/share/classes/java/util/EnumSet.java Mon Mar 03 18:17:00 2014 +0400 > +++ b/src/share/classes/java/util/EnumSet.java Mon Mar 03 22:02:06 2014 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2003, 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 > @@ -77,6 +77,8 @@ > * @see EnumMap > * @serial exclude > */ > + at SuppressWarnings("serial") // No serialVersionUID due to usage of > + // serial proxy pattern > public abstract class EnumSet> extends AbstractSet > implements Cloneable, java.io.Serializable > { > diff -r 6cfedc362f48 src/share/classes/sun/reflect/annotation/ExceptionProxy.java > --- a/src/share/classes/sun/reflect/annotation/ExceptionProxy.java Mon Mar 03 > 18:17:00 2014 +0400 > +++ b/src/share/classes/sun/reflect/annotation/ExceptionProxy.java Mon Mar 03 > 22:02:06 2014 -0800 > @@ -37,5 +37,6 @@ > * @since 1.5 > */ > public abstract class ExceptionProxy implements java.io.Serializable { > + private static final long serialVersionUID = 7241930048386631401L; > protected abstract RuntimeException generateException(); > } > > > On 02/28/2014 08:58 AM, Stuart Marks wrote: >> On 2/27/14 12:11 PM, Joe Darcy wrote: >>> I am trying hard to remain blissfully ignorant of any more low-level details of >>> the serialization format; however, I might not be successful on that goal much >>> longer ;-) >> >> I believe your latter statement is correct. :-) >> >>> My preference in a case like this is to add the svuid if for no other reason >>> that is is simple to explain and understand, even if it is not strictly >>> required. >> >> In general, it does seem reasonable to add a svuid in cases where it's >> difficult or impractical to prove that the lack of a svuid causes no >> compatibility issues. >> >>> There is a difference in character between a serializable class in Java SE >>> (java.* and javax.*) and the jdk.Exported(true) types in the JDK and a >>> serializable class that lives in sun.* or some other jdk.Exported(false) area. >>> >>> For that latter, the serialization contract has to be different, with fewer >>> guarantees, just as the general usage contract for those types has fewer >>> guarantees. I think this is analogous to putting non-serializable classes into >>> collections; the collection itself is serializable, but it won't be anymore if >>> you put non-serializable objects into it. >>> >>> If a user happens to have a direct or indirect reference to an object of a JDK >>> implementation type, the compatibility contract is weaker than if an object with >>> a public Java SE type were being dealt with. >> >> I'm not sure I buy this. Unfortunately, serialization differs from the general >> usage contract in that serialization exposes internals. Just like it can >> expose private (non-transient) fields, serialization can also can expose what >> might otherwise look like purely internal implementation types. >> >> The canonical example of how an application can get a reference to an >> apparently internal class is java.util.TimeZone. If an app calls >> TimeZone.getDefault(), it gets back an instance of sun.util.calendar.ZoneInfo >> without ever mentioning this class by name. Furthermore, TimeZone and ZoneInfo >> are serializable, so they can be serialized directly or as part of another >> serializable object graph, and an instance of s.u.c.ZoneInfo does appear in >> the serialized byte stream. If s.u.c.ZoneInfo were not to have a svuid, an >> apparently innocuous change to it would clearly cause application >> incompatibilities. >> >> As it happens, s.u.c.ZoneInfo does have a svuid. I also note in passing that >> TimeZone, an abstract class, also has a svuid. >> >>>> Finally, EnumSet doesn't need a serial version UID. It's serialized using a >>>> proxy class, so EnumSet never appears in a serialized byte stream. (Note, its >>>> readObject throws an exception unconditionally.) So it's probably safe to >>>> suppress its serialization warning. >>> >>> Yes, EnumSet was a bit tricky, it is serializable itself, but uses a proxy >>> internally. ("Effective Java, 2nd edition" both recommends the proxy pattern and >>> recommends adding a svuid to all serializable classes, but doesn't explicitly >>> give guidance to this combination of features.) >>> >>> To avoid adding a long comment explaining the proxy pattern and why a svuid on >>> EnumSet isn't really required, my preference would just be to add the svuid if >>> it doesn't cause any harm. >> >> In this case I think it's possible by local reasoning (looking elsewhere in >> the EnumSet.java source code) to determine that EnumSet instances themselves >> are never actually serialized, because of the use of the serialization proxy >> pattern. If nothing else, adding a svuid here sets a bad example, so >> suppressing the warning is reasonable. I don't think a long comment is >> necessary. Probably something like the following is sufficient: >> >> @SuppressWarnings("serial") // no serialVersionUID because of serialization proxy >> >> s'marks >> >> >> >> > From joe.darcy at oracle.com Wed Mar 5 01:44:57 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 04 Mar 2014 17:44:57 -0800 Subject: JDK 9 RFR of JDK-8036568: Serial incompatibility in java.util.TreeMap.NavigableSubMap Message-ID: <53168199.9080504@oracle.com> Hello, Following up from the recent discussions around JDK-8035452: Fix serial lint warnings in core libs it turns out that java.util.TreeMap.NavigableSubMap, a package private nested class used in the TreeMap implementation does indeed need to have a serialVersionUID defined to allow for easy cross-release serialization. An API change made to TreeMap during JDK 8 changed the serialver hash of the class. This patch --- a/src/share/classes/java/util/TreeMap.java Mon Mar 03 18:17:00 2014 +0400 +++ b/src/share/classes/java/util/TreeMap.java Tue Mar 04 17:41:09 2014 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 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 @@ -1335,6 +1335,7 @@ */ abstract static class NavigableSubMap extends AbstractMap implements NavigableMap, java.io.Serializable { + private static final long serialVersionUID = -2102997345730753016L; /** * The backing map. */ restores the serial hash value present in JDK 6 and 7. This particular review request is for JDK 9; we are evaluating options on how best to fix this issue in the JDK 8 train. Thanks, -Joe From stuart.marks at oracle.com Wed Mar 5 02:28:02 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 04 Mar 2014 18:28:02 -0800 Subject: JDK 9 RFR of JDK-8036568: Serial incompatibility in java.util.TreeMap.NavigableSubMap In-Reply-To: <53168199.9080504@oracle.com> References: <53168199.9080504@oracle.com> Message-ID: <53168BB2.6010504@oracle.com> Hi Joe, Fix looks good. I confirmed that the svuid value in your patch is the right one to be compatible with 6 and 7, at least for all the versions of those releases that I have at my fingertips (which is several). And yes, we need to figure out how best to fix this in the 8 release family. s'marks On 3/4/14 5:44 PM, Joe Darcy wrote: > Hello, > > Following up from the recent discussions around > > JDK-8035452: Fix serial lint warnings in core libs > > it turns out that java.util.TreeMap.NavigableSubMap, a package private nested > class used in the TreeMap implementation does indeed need to have a > serialVersionUID defined to allow for easy cross-release serialization. > > An API change made to TreeMap during JDK 8 changed the serialver hash of the > class. This patch > > --- a/src/share/classes/java/util/TreeMap.java Mon Mar 03 18:17:00 2014 +0400 > +++ b/src/share/classes/java/util/TreeMap.java Tue Mar 04 17:41:09 2014 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1997, 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 > @@ -1335,6 +1335,7 @@ > */ > abstract static class NavigableSubMap extends AbstractMap > implements NavigableMap, java.io.Serializable { > + private static final long serialVersionUID = -2102997345730753016L; > /** > * The backing map. > */ > > restores the serial hash value present in JDK 6 and 7. > > This particular review request is for JDK 9; we are evaluating options on how > best to fix this issue in the JDK 8 train. > > Thanks, > > -Joe From david.holmes at oracle.com Wed Mar 5 03:41:51 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 05 Mar 2014 13:41:51 +1000 Subject: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods In-Reply-To: <5315F228.1030503@redhat.com> References: <53110B02.7070602@oracle.com> <5312F127.60903@javaspecialists.eu> <53136337.9040001@redhat.com> <53137CE2.1010102@javaspecialists.eu> <53147C11.1010906@redhat.com> <53154C59.1000001@oracle.com> <5315F228.1030503@redhat.com> Message-ID: <53169CFF.9060204@oracle.com> On 5/03/2014 1:32 AM, David M. Lloyd wrote: > On 03/03/2014 09:45 PM, David Holmes wrote: >> On 3/03/2014 10:56 PM, David M. Lloyd wrote: >>> Yes, that would necessarily be the contract of a Monitors class, just as >>> it is part of the contract of Lock today. If your argument is that it >>> shouldn't be allowed because it might be used wrong, we might as well >>> just delete most of the JDK, ReentrantLock included, since it suffers >>> from the exact same potential problem. The difference is that monitors >>> have a simple API in the form of synchronized that people were in the >>> past and would continue to be free (and recommended) to use. >> >> We should not introduce anything that allows something that was >> guaranteed to be safe by the language, to become unsafe. > > Define 'safe'. Because I don't think it's unsafe, any more than > unpaired lock/unlock are. There is no uninitialized memory being > accessed, no way to bypass security checks, no way to manipulate memory > directly, etc. I find this argument to be particularly weak without > specific cases. As far as I can tell, the language doesn't make it > safe, it makes it *convenient*, and that's a big distinction. I agree it is as unsafe as using Lock. I think not being able to forget to unlock a monitor is more than just convenient. YMMV and obviously does. David ----- > There are two cases I can see that are potentially problematic: extra > acquires, and extra releases. > > The risk of extra acquires is that the thread might exit while still > holding the lock, leaving it locked forever. However, just parking a > thread indefinitely (via various means) within a synchronized block is > equally unsafe. > > The risk of extra releases is that you'll hit IllegalMonitorState > exceptions and thread-safety/publication problems. But a user can make > this same mistake today with locks. The difference is, that in most > cases people would choose the convenience of synchronized unless there > is a specific reason for it, making this problem far less likely than > the corresponding locks case. > From john.r.rose at oracle.com Wed Mar 5 07:20:49 2014 From: john.r.rose at oracle.com (John Rose) Date: Tue, 4 Mar 2014 23:20:49 -0800 Subject: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods In-Reply-To: <53169CFF.9060204@oracle.com> References: <53110B02.7070602@oracle.com> <5312F127.60903@javaspecialists.eu> <53136337.9040001@redhat.com> <53137CE2.1010102@javaspecialists.eu> <53147C11.1010906@redhat.com> <53154C59.1000001@oracle.com> <5315F228.1030503@redhat.com> <53169CFF.9060204@oracle.com> Message-ID: <9862D98A-D9BC-4079-89F6-1C31265C0396@oracle.com> On Mar 4, 2014, at 7:41 PM, David Holmes wrote: > I agree it is as unsafe as using Lock. I think not being able to forget to unlock a monitor is more than just convenient. YMMV and obviously does. That's why that "unsafe" kind of stuff currently lives in class "unsafe". Next there are safe ways to build on those primitives to create safe APIs, using encapsulation and access restriction. The "Runnable" trick for matching monitors is (probably) compatible with low-level unsafe unmatched monitor operations. Another metaphor: It's OK to build an office building using tools that the office workers won't have daily access to. Construction sites have different safety rules than office environments. Some folks get to use nailguns at work; I don't, but that doesn't make me want my building to be constructed using staplers only. ? John From jeroen at sumatra.nl Wed Mar 5 07:40:49 2014 From: jeroen at sumatra.nl (Jeroen Frijters) Date: Wed, 5 Mar 2014 07:40:49 +0000 Subject: JEP 193: Enhanced Volatiles In-Reply-To: <53166B98.2060200@oracle.com> References: <20140303192647.75AB814B91@eggemoggin.niobe.net> <5315015E.7010602@oracle.com> <53166B98.2060200@oracle.com> Message-ID: Brian Goetz wrote: > Right now, the semantics of method calls in Java are simple -- > everything (primitives, object references) is passed by value. Adding > pass-by-reference would add significant complexity. And method calls > are not a niche feature; that added complexity will be borne by every > developer, every day. We'll just have to disagree on this. VB developers are not more sophisticated than Java developers and they've dealt with ByRef just fine (even though many don't understand it). In practice they don't run into it that often. > My goal here is to make sure that expert users can get their job done > somehow, *without* making the job of mainstream developers harder. The > "add lvalues to Java so experts can write CAS-libraries" fails that test > miserably. Why not go for something far less intrusive then? Here's my straw man proposal: Add an annotation that can be placed on native methods to synthesize atomic accessor methods. Example usage: @AtomicField("next") private native boolean compareAndSet(Node expected, Node newValue); @AtomicArray private static native boolean compareAndSet(Node[] array, Node expected, Node newValue); (Note that the method name is not significant, the operation can be derived from the signature, or explicit in the annotation, if necessary.) This requires no changes to the language and adds only a slight burden on the developer (but it's very easy to add tooling support). Regards, Jeroen From me at noctarius.com Wed Mar 5 07:51:08 2014 From: me at noctarius.com (Christoph Engelbert) Date: Wed, 5 Mar 2014 08:51:08 +0100 Subject: JEP 193: Enhanced Volatiles In-Reply-To: References: <20140303192647.75AB814B91@eggemoggin.niobe.net> <5315015E.7010602@oracle.com> <53166B98.2060200@oracle.com> Message-ID: Am 05.03.2014 um 08:40 schrieb Jeroen Frijters : >> My goal here is to make sure that expert users can get their job done >> somehow, *without* making the job of mainstream developers harder. The >> "add lvalues to Java so experts can write CAS-libraries" fails that test >> miserably. > > Why not go for something far less intrusive then? Here's my straw man proposal: > > Add an annotation that can be placed on native methods to synthesize atomic accessor methods. > > Example usage: > > @AtomicField("next") > private native boolean compareAndSet(Node expected, Node newValue); > > @AtomicArray > private static native boolean compareAndSet(Node[] array, Node expected, Node newValue); > > (Note that the method name is not significant, the operation can be derived from the signature, or explicit in the annotation, if necessary.) > > This requires no changes to the language and adds only a slight burden on the developer (but it's very easy to add tooling support). > > Regards, > Jeroen > That looks like a good fit towards what was mentioned earlier using method handles. The JVM or compiler could just look out for those annotations and generate corresponding method / field handles to execute it. Thanks, Chris From mark.sheppard at oracle.com Wed Mar 5 11:28:14 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Wed, 05 Mar 2014 11:28:14 +0000 Subject: RFR: JDK-8035930 - Check jdk/src/windows/native/java/io/io_util_md.c for JNI pending exceptions Message-ID: <53170A4E.2010004@oracle.com> Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8035930/webrev/ to address the issues raised in https://bugs.openjdk.java.net/browse/JDK-8035930 this adds additional NULL check for malloc and JNI calls and check for pending exceptions as appropriate regards Mark From mcnepp02 at googlemail.com Wed Mar 5 11:42:13 2014 From: mcnepp02 at googlemail.com (Gernot Neppert) Date: Wed, 05 Mar 2014 12:42:13 +0100 Subject: JEP 193: Enhanced Volatiles In-Reply-To: <20140303192647.75AB814B91@eggemoggin.niobe.net> References: <20140303192647.75AB814B91@eggemoggin.niobe.net> Message-ID: <53170D95.1070700@googlemail.com> Am 03.03.2014 20:26, schrieb mark.reinhold at oracle.com: > Posted: http://openjdk.java.net/jeps/193 > > - Mark Reading about ideas to integrate atomic operations into the language, I was asking myself which of these operations I was using most frequently in my own code (currently by means of java.util.concurrent.atomic.AtomicXXX variables) and how they could be made more convenient with built-in support. Here's my top 5 list: 1. AtomicReference.compareAndSet(T expect,T update). In almost all of the usecases, "expect" was null. 2. AtomicBoolean.compareAndSet(boolean expect, boolean update. In almost all of the usecases, "expect" was false. 3. AtomicReference.getAndSet(T update). 4. AtomicInteger.getAndIncrement(). 5. AtomicInteger.getAndDecrement(). Now, 4. and 5. would be the easiest to solve: Make postfix "++" and "--" implicitly atomic if used on volatile variables. I know that this would require a change of the JLS, but on the other hand, the precise meaning of "volatile" has been changed once before, so would this be a showstopper? For cases 1. and 2. one could think of a new operator "lhs ?= rhs" with the meaning "Assign the rhs to the lhs only if lhs is currently null. Return true if the assignment took place (Alternatively, return rhs if the assignment took place. Would be more consistent with other assignment operators and convey the same amount of information as a boolean value). Make the operation atomic if lhs is a volatile variable". For case 3. one could devise an operator "lhs := rhs" with the meaning "Assign the rhs to the lhs and return the previous content of the lhs. Make the operation atomic if lhs is a volatile variable". Note that the new operators would have consistent meaning even if used with non-volatile variables (even though they wouldn't provide exciting new possibilities) From Alan.Bateman at oracle.com Wed Mar 5 11:51:00 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 05 Mar 2014 11:51:00 +0000 Subject: RFR: JDK-8035930 - Check jdk/src/windows/native/java/io/io_util_md.c for JNI pending exceptions In-Reply-To: <53170A4E.2010004@oracle.com> References: <53170A4E.2010004@oracle.com> Message-ID: <53170FA4.2060803@oracle.com> On 05/03/2014 11:28, Mark Sheppard wrote: > Hi > please oblige and review the following changes > http://cr.openjdk.java.net/~msheppar/8035930/webrev/ > > to address the issues raised in > https://bugs.openjdk.java.net/browse/JDK-8035930 > > this adds additional NULL check for malloc and JNI calls > and check for pending exceptions as appropriate Just two comments on this: 1. At line 213 then I think it would be better to return with the OOME pending rather than suppressing it and throwing a FNFE. In practical terms then if we are really out of native memory then it won't get very far but it would still be confusing to have FNF thrown for this case. 2. What you think about dropping "pathToNTPath: " from the exception messages? It's not clear to me that it helps and it also means these new exceptions are inconsistent with the other usages. -Alan. From mark.sheppard at oracle.com Wed Mar 5 12:40:45 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Wed, 05 Mar 2014 12:40:45 +0000 Subject: RFR: JDK-8035930 - Check jdk/src/windows/native/java/io/io_util_md.c for JNI pending exceptions In-Reply-To: <53170FA4.2060803@oracle.com> References: <53170A4E.2010004@oracle.com> <53170FA4.2060803@oracle.com> Message-ID: <53171B4D.7090108@oracle.com> Hi Alan, thanks for the reply, I'll make the suggested amendments regards Mark On 05/03/2014 11:51, Alan Bateman wrote: > On 05/03/2014 11:28, Mark Sheppard wrote: >> Hi >> please oblige and review the following changes >> http://cr.openjdk.java.net/~msheppar/8035930/webrev/ >> >> to address the issues raised in >> https://bugs.openjdk.java.net/browse/JDK-8035930 >> >> this adds additional NULL check for malloc and JNI calls >> and check for pending exceptions as appropriate > Just two comments on this: > > 1. At line 213 then I think it would be better to return with the OOME > pending rather than suppressing it and throwing a FNFE. In practical > terms then if we are really out of native memory then it won't get > very far but it would still be confusing to have FNF thrown for this > case. > > 2. What you think about dropping "pathToNTPath: " from the exception > messages? It's not clear to me that it helps and it also means these > new exceptions are inconsistent with the other usages. > > -Alan. From dl at cs.oswego.edu Wed Mar 5 14:04:16 2014 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 05 Mar 2014 09:04:16 -0500 Subject: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods In-Reply-To: References: <530F50DA.3010308@javaspecialists.eu> <144A3A2D-85FF-4F3B-A4DA-1780B809F36B@oracle.com> Message-ID: <53172EE0.6030801@cs.oswego.edu> A few comments on catching up with this discussion... >>> tryMonitorEnter() does no harm and it is out of reach of most >>> programmers. Built-in monitors are heavily optimized for "typical" cases, which does not include any form of tryLock. So the hotspot implementation of tryMonitorEnter is very slow. Making it less slow would probably negatively impact typical cases. So tryMonitorEnter is only useful in cases where you absolutely need the functionality at any cost, and don't want to use a j.u.c Lock. It's not surprising that there almost no known usages, and probably none that justify continued support. The main downside of using a j.u.c Lock just for the sake of tryLock is that you cannot take advantage of the JVM's extremely compact lock representation (basically one bit in the object header) for never-locked objects. On the other hand, if you are trying to minimize footprint, there are usually ways to cope. For example, in a few places inside j.u.c. we've used other available bits as spinlocks and resorted to monitors/Locks only when necessary. In a sense, this emulates monitor inflation. -Doug From pbenedict at apache.org Wed Mar 5 15:18:30 2014 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 5 Mar 2014 09:18:30 -0600 Subject: JEP 193: Enhanced Volatiles In-Reply-To: References: <20140303192647.75AB814B91@eggemoggin.niobe.net> <5315015E.7010602@oracle.com> <53166B98.2060200@oracle.com> Message-ID: This idea really close very the commonly held belief that annotations shouldn't be used to extend the language -- and thus will not be accepted. If the compiler is picking up these annotations to emit different code, that is obviously "shoehorning" annotations into a language feature. On Wed, Mar 5, 2014 at 1:51 AM, Christoph Engelbert wrote: > Am 05.03.2014 um 08:40 schrieb Jeroen Frijters : > > >> My goal here is to make sure that expert users can get their job done > >> somehow, *without* making the job of mainstream developers harder. The > >> "add lvalues to Java so experts can write CAS-libraries" fails that test > >> miserably. > > > > Why not go for something far less intrusive then? Here's my straw man > proposal: > > > > Add an annotation that can be placed on native methods to synthesize > atomic accessor methods. > > > > Example usage: > > > > @AtomicField("next") > > private native boolean compareAndSet(Node expected, Node newValue); > > > > @AtomicArray > > private static native boolean compareAndSet(Node[] array, Node expected, > Node newValue); > > > > (Note that the method name is not significant, the operation can be > derived from the signature, or explicit in the annotation, if necessary.) > > > > This requires no changes to the language and adds only a slight burden > on the developer (but it's very easy to add tooling support). > > > > Regards, > > Jeroen > > > > That looks like a good fit towards what was mentioned earlier using method > handles. The JVM or compiler could just look out for those annotations and > generate corresponding method / field handles to execute it. > > Thanks, > Chris > > -- Cheers, Paul From jeroen at sumatra.nl Wed Mar 5 15:38:24 2014 From: jeroen at sumatra.nl (Jeroen Frijters) Date: Wed, 5 Mar 2014 15:38:24 +0000 Subject: JEP 193: Enhanced Volatiles In-Reply-To: References: <20140303192647.75AB814B91@eggemoggin.niobe.net> <5315015E.7010602@oracle.com> <53166B98.2060200@oracle.com> Message-ID: <915992ef730e4417b010eb592a03b212@mane.sumatrasoftware.com> The JVM should be picking up the annotations (otherwise, you'd still need to design a public API to deal with atomics). BTW, it was explained to me at the JVM Language Summit that the "commonly held belief" about annotations, is not in fact true. Regards, Jeroen > -----Original Message----- > From: paulus.benedictus at gmail.com [mailto:paulus.benedictus at gmail.com] > On Behalf Of Paul Benedict > Sent: Wednesday, March 5, 2014 16:19 > To: Christoph Engelbert > Cc: Jeroen Frijters; core-libs-dev at openjdk.java.net > Subject: Re: JEP 193: Enhanced Volatiles > > This idea really close very the commonly held belief that annotations > shouldn't be used to extend the language -- and thus will not be > accepted. If the compiler is picking up these annotations to emit > different code, that is obviously "shoehorning" annotations into a > language feature. > > > On Wed, Mar 5, 2014 at 1:51 AM, Christoph Engelbert > wrote: > > > Am 05.03.2014 um 08:40 schrieb Jeroen Frijters >: > > > >> My goal here is to make sure that expert users can get their > job done > >> somehow, *without* making the job of mainstream developers > harder. The > >> "add lvalues to Java so experts can write CAS-libraries" fails > that test > >> miserably. > > > > Why not go for something far less intrusive then? Here's my straw > man proposal: > > > > Add an annotation that can be placed on native methods to > synthesize atomic accessor methods. > > > > Example usage: > > > > @AtomicField("next") > > private native boolean compareAndSet(Node expected, Node > newValue); > > > > @AtomicArray > > private static native boolean compareAndSet(Node[] array, Node > expected, Node newValue); > > > > (Note that the method name is not significant, the operation can > be derived from the signature, or explicit in the annotation, if > necessary.) > > > > This requires no changes to the language and adds only a slight > burden on the developer (but it's very easy to add tooling support). > > > > Regards, > > Jeroen > > > > > That looks like a good fit towards what was mentioned earlier using > method handles. The JVM or compiler could just look out for those > annotations and generate corresponding method / field handles to execute > it. > > Thanks, > Chris > > > > > > > -- > > Cheers, > Paul From pbenedict at apache.org Wed Mar 5 16:15:55 2014 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 5 Mar 2014 10:15:55 -0600 Subject: JEP 193: Enhanced Volatiles In-Reply-To: <915992ef730e4417b010eb592a03b212@mane.sumatrasoftware.com> References: <20140303192647.75AB814B91@eggemoggin.niobe.net> <5315015E.7010602@oracle.com> <53166B98.2060200@oracle.com> <915992ef730e4417b010eb592a03b212@mane.sumatrasoftware.com> Message-ID: Jeroen, I agree with you (1) not everyone holds the belief and (2) this is not a technical limitation. This is simply a matter of perspective and intent. However, those in charge in the JDK seem pretty strong on #1 -- at least from what I've seen in my interactions. That's why I don't think this will gain traction, but I am always willing to be surprised. On Wed, Mar 5, 2014 at 9:38 AM, Jeroen Frijters wrote: > The JVM should be picking up the annotations (otherwise, you'd still need > to design a public API to deal with atomics). > > BTW, it was explained to me at the JVM Language Summit that the "commonly > held belief" about annotations, is not in fact true. > > Regards, > Jeroen > > > -----Original Message----- > > From: paulus.benedictus at gmail.com [mailto:paulus.benedictus at gmail.com] > > On Behalf Of Paul Benedict > > Sent: Wednesday, March 5, 2014 16:19 > > To: Christoph Engelbert > > Cc: Jeroen Frijters; core-libs-dev at openjdk.java.net > > Subject: Re: JEP 193: Enhanced Volatiles > > > > This idea really close very the commonly held belief that annotations > > shouldn't be used to extend the language -- and thus will not be > > accepted. If the compiler is picking up these annotations to emit > > different code, that is obviously "shoehorning" annotations into a > > language feature. > > > > > > On Wed, Mar 5, 2014 at 1:51 AM, Christoph Engelbert > > wrote: > > > > > > Am 05.03.2014 um 08:40 schrieb Jeroen Frijters > >: > > > > > > >> My goal here is to make sure that expert users can get their > > job done > > >> somehow, *without* making the job of mainstream developers > > harder. The > > >> "add lvalues to Java so experts can write CAS-libraries" fails > > that test > > >> miserably. > > > > > > Why not go for something far less intrusive then? Here's my straw > > man proposal: > > > > > > Add an annotation that can be placed on native methods to > > synthesize atomic accessor methods. > > > > > > Example usage: > > > > > > @AtomicField("next") > > > private native boolean compareAndSet(Node expected, Node > > newValue); > > > > > > @AtomicArray > > > private static native boolean compareAndSet(Node[] array, Node > > expected, Node newValue); > > > > > > (Note that the method name is not significant, the operation can > > be derived from the signature, or explicit in the annotation, if > > necessary.) > > > > > > This requires no changes to the language and adds only a slight > > burden on the developer (but it's very easy to add tooling support). > > > > > > Regards, > > > Jeroen > > > > > > > > > That looks like a good fit towards what was mentioned earlier using > > method handles. The JVM or compiler could just look out for those > > annotations and generate corresponding method / field handles to execute > > it. > > > > Thanks, > > Chris > > > > > > > > > > > > > > -- > > > > Cheers, > > Paul > -- Cheers, Paul From brian.goetz at oracle.com Wed Mar 5 16:44:22 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 05 Mar 2014 11:44:22 -0500 Subject: JEP 193: Enhanced Volatiles In-Reply-To: <53170D95.1070700@googlemail.com> References: <20140303192647.75AB814B91@eggemoggin.niobe.net> <53170D95.1070700@googlemail.com> Message-ID: <53175466.3090705@oracle.com> (This is already-traveled ground.) The ++/--/+= trick is cute as a shorthand, but without a means of expressing a full-blown CAS, falls short of the goal of "integrate atomic read-modify-write operations into the programming model." IF the latter problem was addressed, we might consider redefining ++ and friends to be shorthand for an RMW operation, and extending that to be atomic if applied on volatiles. But only if we can get all the way there. The "new operator" addresses the above-mentioned hole (though will confuse the hell out of the 99.99% of users that will never use it, but who will still see it on the table of operators in their CS 101 textbook), but runs up against of a different goal; expressing not only atomic operations, but all the possible fencing modes. There's no way we're going to invent a new syntax for each fencing mode, and we don't even know that we will never add new fencing modes. One of the goals here is to align with JMM9, which has a goal of aligning with the recently minted C++ MM (so that we can have a coherent MM across Java and native code.) Though, if we were willing to separate fencing from access, this idea might re-emerge as viable. > Reading about ideas to integrate atomic operations into the language, I > was asking myself which of these operations I was using most frequently > in my own code (currently by means of > java.util.concurrent.atomic.AtomicXXX variables) and how they could be > made more convenient with built-in support. > Here's my top 5 list: > > 1. AtomicReference.compareAndSet(T expect,T update). In almost all of > the usecases, "expect" was null. > > 2. AtomicBoolean.compareAndSet(boolean expect, boolean update. In almost > all of the usecases, "expect" was false. > > 3. AtomicReference.getAndSet(T update). > > 4. AtomicInteger.getAndIncrement(). > > 5. AtomicInteger.getAndDecrement(). > > Now, 4. and 5. would be the easiest to solve: Make postfix "++" and "--" > implicitly atomic if used on volatile variables. I know that this would > require a change of the JLS, but on the other hand, the precise meaning > of "volatile" has been changed once before, so would this be a showstopper? > > For cases 1. and 2. one could think of a new operator "lhs ?= rhs" with > the meaning > "Assign the rhs to the lhs only if lhs is currently null. Return true if > the assignment took place (Alternatively, return rhs if the assignment > took place. Would be more consistent with other assignment operators and > convey the same amount of information as a boolean value). Make the > operation atomic if lhs is a volatile variable". > > For case 3. one could devise an operator "lhs := rhs" with the meaning > "Assign the rhs to the lhs and return the previous content of the lhs. > Make the operation atomic if lhs is a volatile variable". > > Note that the new operators would have consistent meaning even if used > with non-volatile variables (even though they wouldn't provide exciting > new possibilities) > From brian.goetz at oracle.com Wed Mar 5 16:50:44 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 05 Mar 2014 11:50:44 -0500 Subject: JEP 193: Enhanced Volatiles In-Reply-To: References: <20140303192647.75AB814B91@eggemoggin.niobe.net> <5315015E.7010602@oracle.com> <53166B98.2060200@oracle.com> Message-ID: <531755E4.4050107@oracle.com> > Why not go for something far less intrusive then? I'm all for unintrusive. Though note that the intrusiveness metric on language features I(f) is not uniform across observers :) > Here's my straw man > proposal: > > Add an annotation that can be placed on native methods to synthesize > atomic accessor methods. I suspect you were expecting this response: we don't add language semantics through annotations. I'm not trying to frustrate you; evolving a language with millions of users is really, really hard. And one of the things that makes it hard is recognizing our intrinsic conflicts of interest between "what good will this do me" and "what harm will it do others." From jeroen at sumatra.nl Wed Mar 5 16:55:54 2014 From: jeroen at sumatra.nl (Jeroen Frijters) Date: Wed, 5 Mar 2014 16:55:54 +0000 Subject: JEP 193: Enhanced Volatiles In-Reply-To: <531755E4.4050107@oracle.com> References: <20140303192647.75AB814B91@eggemoggin.niobe.net> <5315015E.7010602@oracle.com> <53166B98.2060200@oracle.com> <531755E4.4050107@oracle.com> Message-ID: <95b7ac50741248abbf10009280ed9704@mane.sumatrasoftware.com> Brian Goetz wrote: > I'm all for unintrusive. Though note that the intrusiveness metric on > language features I(f) is not uniform across observers :) Indeed :-) > > Here's my straw man > > proposal: > > > > Add an annotation that can be placed on native methods to synthesize > > atomic accessor methods. > > I suspect you were expecting this response: we don't add language > semantics through annotations. Technically, we're not adding language semantics. The JVM is the one interpreting the annotations. BTW, as I mentioned in another post in this thread, I specifically asked about this at the JVM Language Summit (in 2012 IIRC) and the answer was (by Alex IIRC) that there is no such rule. > I'm not trying to frustrate you; evolving a language with millions of > users is really, really hard. And one of the things that makes it hard > is recognizing our intrinsic conflicts of interest between "what good > will this do me" and "what harm will it do others." I understand, that's why I want to avoid adding language support for this niche/specialist feature. Regards, Jeroen From peter.levart at gmail.com Wed Mar 5 17:07:07 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 05 Mar 2014 18:07:07 +0100 Subject: JEP 193: Enhanced Volatiles In-Reply-To: <95b7ac50741248abbf10009280ed9704@mane.sumatrasoftware.com> References: <20140303192647.75AB814B91@eggemoggin.niobe.net> <5315015E.7010602@oracle.com> <53166B98.2060200@oracle.com> <531755E4.4050107@oracle.com> <95b7ac50741248abbf10009280ed9704@mane.sumatrasoftware.com> Message-ID: <531759BB.8020805@gmail.com> On 03/05/2014 05:55 PM, Jeroen Frijters wrote: > Brian Goetz wrote: > >> I suspect you were expecting this response: we don't add language >> semantics through annotations. > Technically, we're not adding language semantics. The JVM is the one interpreting the annotations. And the JVM is the one implementing the language semantics (together with javac which feeds the JVM with bytecodes). Language semantcis are implemented by the combination of javac and JVM. If you say that this feature does not require any change to javac, you're just saying that you put all the burden on the JVM, but you *are* implementing the language semantics using annotations nevertheless... Regards, Peter >> I'm not trying to frustrate you; evolving a language with millions of >> users is really, really hard. And one of the things that makes it hard >> is recognizing our intrinsic conflicts of interest between "what good >> will this do me" and "what harm will it do others." > I understand, that's why I want to avoid adding language support for this niche/specialist feature. > > Regards, > Jeroen > From forax at univ-mlv.fr Wed Mar 5 17:22:02 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 05 Mar 2014 18:22:02 +0100 Subject: JEP 193: Enhanced Volatiles In-Reply-To: <531759BB.8020805@gmail.com> References: <20140303192647.75AB814B91@eggemoggin.niobe.net> <5315015E.7010602@oracle.com> <53166B98.2060200@oracle.com> <531755E4.4050107@oracle.com> <95b7ac50741248abbf10009280ed9704@mane.sumatrasoftware.com> <531759BB.8020805@gmail.com> Message-ID: <53175D3A.7060502@univ-mlv.fr> On 03/05/2014 06:07 PM, Peter Levart wrote: > > On 03/05/2014 05:55 PM, Jeroen Frijters wrote: >> Brian Goetz wrote: >> >>> I suspect you were expecting this response: we don't add language >>> semantics through annotations. >> Technically, we're not adding language semantics. The JVM is the one >> interpreting the annotations. > > And the JVM is the one implementing the language semantics (together > with javac which feeds the JVM with bytecodes). Language semantcis are > implemented by the combination of javac and JVM. If you say that this > feature does not require any change to javac, you're just saying that > you put all the burden on the JVM, but you *are* implementing the > language semantics using annotations nevertheless... no, it's the other way around. javac maps Java the language to the bytecode semantics. The JVM only execute bytecodes. > > > Regards, Peter cheers, R?mi > >>> I'm not trying to frustrate you; evolving a language with millions of >>> users is really, really hard. And one of the things that makes it hard >>> is recognizing our intrinsic conflicts of interest between "what good >>> will this do me" and "what harm will it do others." >> I understand, that's why I want to avoid adding language support for >> this niche/specialist feature. >> >> Regards, >> Jeroen >> > From brian.goetz at oracle.com Wed Mar 5 17:33:03 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 05 Mar 2014 12:33:03 -0500 Subject: JEP 193: Enhanced Volatiles In-Reply-To: <95b7ac50741248abbf10009280ed9704@mane.sumatrasoftware.com> References: <20140303192647.75AB814B91@eggemoggin.niobe.net> <5315015E.7010602@oracle.com> <53166B98.2060200@oracle.com> <531755E4.4050107@oracle.com> <95b7ac50741248abbf10009280ed9704@mane.sumatrasoftware.com> Message-ID: <53175FCF.4060806@oracle.com> >> I suspect you were expecting this response: we don't add language >> semantics through annotations. > > Technically, we're not adding language semantics. The JVM is the one interpreting the annotations. BTW, as I mentioned in another post in this thread, I specifically asked about this at the JVM Language Summit (in 2012 IIRC) and the answer was (by Alex IIRC) that there is no such rule. Perhaps, but this isn't a court of law :) And the spirit here is pretty clear. But, keep trying! I know you're trying to help,and it only takes one good idea. From forax at univ-mlv.fr Wed Mar 5 17:34:32 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 05 Mar 2014 18:34:32 +0100 Subject: JEP 193: Enhanced Volatiles In-Reply-To: <95b7ac50741248abbf10009280ed9704@mane.sumatrasoftware.com> References: <20140303192647.75AB814B91@eggemoggin.niobe.net> <5315015E.7010602@oracle.com> <53166B98.2060200@oracle.com> <531755E4.4050107@oracle.com> <95b7ac50741248abbf10009280ed9704@mane.sumatrasoftware.com> Message-ID: <53176028.50605@univ-mlv.fr> On 03/05/2014 05:55 PM, Jeroen Frijters wrote: > Brian Goetz wrote: >> I'm all for unintrusive. Though note that the intrusiveness metric on >> language features I(f) is not uniform across observers :) > Indeed :-) > >>> Here's my straw man >>> proposal: >>> >>> Add an annotation that can be placed on native methods to synthesize >>> atomic accessor methods. >> I suspect you were expecting this response: we don't add language >> semantics through annotations. > Technically, we're not adding language semantics. The JVM is the one interpreting the annotations. BTW, as I mentioned in another post in this thread, I specifically asked about this at the JVM Language Summit (in 2012 IIRC) and the answer was (by Alex IIRC) that there is no such rule. and that's not true, the meta-annotations @Inherited or @Target change the semantics of the annotated annotation. > >> I'm not trying to frustrate you; evolving a language with millions of >> users is really, really hard. And one of the things that makes it hard >> is recognizing our intrinsic conflicts of interest between "what good >> will this do me" and "what harm will it do others." > I understand, that's why I want to avoid adding language support for this niche/specialist feature. > > Regards, > Jeroen > R?mi From joe.darcy at oracle.com Wed Mar 5 18:56:24 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 05 Mar 2014 10:56:24 -0800 Subject: JDK 9 RFR to remove a raw lint warning from java/lang/invoke/MethodHandleImpl.java In-Reply-To: <5315348B.5080904@oracle.com> References: <5315348B.5080904@oracle.com> Message-ID: <53177358.60809@oracle.com> *ping* Fixing this issue will restore raw lint warning cleanliness to core libs :-) Thanks, -Joe On 03/03/2014 06:03 PM, Joe Darcy wrote: > Hello, > > The recent changeset for > > 8027827: Improve performance of catchException combinator > 8034120: MethodHandles.catchException doesn't handle > VarargsCollector right > > introduced a raw lint warning to the core libraries. Please review the > patch below which removes the warning by adding " Throwable>" to the type the exType parameter of the method. A JDK > build succeeds with the new signature in place. > > Thanks, > > -Joe > > diff -r 6cfedc362f48 > src/share/classes/java/lang/invoke/MethodHandleImpl.java > --- a/src/share/classes/java/lang/invoke/MethodHandleImpl.java Mon Mar > 03 18:17:00 2014 +0400 > +++ b/src/share/classes/java/lang/invoke/MethodHandleImpl.java Mon Mar > 03 17:49:52 2014 -0800 > @@ -734,7 +734,7 @@ > * (see {@link InvokerBytecodeGenerator#emitGuardWithCatch > emitGuardWithCatch}). > */ > @LambdaForm.Hidden > - static Object guardWithCatch(MethodHandle target, Class exType, > MethodHandle catcher, > + static Object guardWithCatch(MethodHandle target, Class Throwable> exType, MethodHandle catcher, > Object... av) throws Throwable { > try { > return target.invokeWithArguments(av); > From forax at univ-mlv.fr Wed Mar 5 19:36:08 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 05 Mar 2014 20:36:08 +0100 Subject: JDK 9 RFR to remove a raw lint warning from java/lang/invoke/MethodHandleImpl.java In-Reply-To: <53177358.60809@oracle.com> References: <5315348B.5080904@oracle.com> <53177358.60809@oracle.com> Message-ID: <53177CA8.7040609@univ-mlv.fr> On 03/05/2014 07:56 PM, Joe Darcy wrote: > *ping* > > Fixing this issue will restore raw lint warning cleanliness to core > libs :-) > > Thanks, > > -Joe looks good :) R?mi > > On 03/03/2014 06:03 PM, Joe Darcy wrote: >> Hello, >> >> The recent changeset for >> >> 8027827: Improve performance of catchException combinator >> 8034120: MethodHandles.catchException doesn't handle >> VarargsCollector right >> >> introduced a raw lint warning to the core libraries. Please review >> the patch below which removes the warning by adding "> Throwable>" to the type the exType parameter of the method. A JDK >> build succeeds with the new signature in place. >> >> Thanks, >> >> -Joe >> >> diff -r 6cfedc362f48 >> src/share/classes/java/lang/invoke/MethodHandleImpl.java >> --- a/src/share/classes/java/lang/invoke/MethodHandleImpl.java Mon >> Mar 03 18:17:00 2014 +0400 >> +++ b/src/share/classes/java/lang/invoke/MethodHandleImpl.java Mon >> Mar 03 17:49:52 2014 -0800 >> @@ -734,7 +734,7 @@ >> * (see {@link InvokerBytecodeGenerator#emitGuardWithCatch >> emitGuardWithCatch}). >> */ >> @LambdaForm.Hidden >> - static Object guardWithCatch(MethodHandle target, Class exType, >> MethodHandle catcher, >> + static Object guardWithCatch(MethodHandle target, Class> extends Throwable> exType, MethodHandle catcher, >> Object... av) throws Throwable { >> try { >> return target.invokeWithArguments(av); >> > From mark.sheppard at oracle.com Wed Mar 5 19:47:54 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Wed, 05 Mar 2014 19:47:54 +0000 Subject: RFR: JDK-8035930 - Check jdk/src/windows/native/java/io/io_util_md.c for JNI pending exceptions In-Reply-To: <53170FA4.2060803@oracle.com> References: <53170A4E.2010004@oracle.com> <53170FA4.2060803@oracle.com> Message-ID: <53177F6A.8050307@oracle.com> Hi webrev has been updated as per Alan's suggestions http://cr.openjdk.java.net/~msheppar/8035930/webrev.01/ regards Mark On 05/03/2014 11:51, Alan Bateman wrote: > On 05/03/2014 11:28, Mark Sheppard wrote: >> Hi >> please oblige and review the following changes >> http://cr.openjdk.java.net/~msheppar/8035930/webrev/ >> >> to address the issues raised in >> https://bugs.openjdk.java.net/browse/JDK-8035930 >> >> this adds additional NULL check for malloc and JNI calls >> and check for pending exceptions as appropriate > Just two comments on this: > > 1. At line 213 then I think it would be better to return with the OOME > pending rather than suppressing it and throwing a FNFE. In practical > terms then if we are really out of native memory then it won't get > very far but it would still be confusing to have FNF thrown for this > case. > > 2. What you think about dropping "pathToNTPath: " from the exception > messages? It's not clear to me that it helps and it also means these > new exceptions are inconsistent with the other usages. > > -Alan. From Alan.Bateman at oracle.com Wed Mar 5 19:52:04 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 05 Mar 2014 19:52:04 +0000 Subject: RFR: JDK-8035930 - Check jdk/src/windows/native/java/io/io_util_md.c for JNI pending exceptions In-Reply-To: <53177F6A.8050307@oracle.com> References: <53170A4E.2010004@oracle.com> <53170FA4.2060803@oracle.com> <53177F6A.8050307@oracle.com> Message-ID: <53178064.30601@oracle.com> On 05/03/2014 19:47, Mark Sheppard wrote: > Hi > webrev has been updated as per Alan's suggestions > > http://cr.openjdk.java.net/~msheppar/8035930/webrev.01/ This looks to me. A minor nit is that there is a leading space in each exception message now. -Alan. From mark.sheppard at oracle.com Wed Mar 5 19:53:04 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Wed, 05 Mar 2014 19:53:04 +0000 Subject: RFR: JDK-8035340 - (prefs) Check jdk/src/windows/native/java/util/WindowsPreference.c for JNI pending exceptions Message-ID: <531780A0.90702@oracle.com> Hi Please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8035340/webrev/ which address the issues raised in https://bugs.openjdk.java.net/browse/JDK-8035340 This effort adds NULL checks and pending exception check after JNI calls and adds NULL check to malloc calls in WindowsPreferences.c This is a Windows change set. regards Mark From david.x.li at oracle.com Wed Mar 5 20:18:39 2014 From: david.x.li at oracle.com (David Li) Date: Wed, 05 Mar 2014 12:18:39 -0800 Subject: RFR (JAXP): 8035577: Xerces Update: impl/xpath/regex/RangeToken.java Message-ID: <5317869F.4010900@oracle.com> Hi, This is an update from Xerces for file impl/xpath/regex/TokenRange.java. For details, please refer to: https://bugs.openjdk.java.net/browse/JDK-8035577. Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035577/webrev/ No new tests. There were none added in Xerces. Existing tests: JAXP SQE and unit tests passed. Thanks, David From xueming.shen at oracle.com Wed Mar 5 20:37:09 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 05 Mar 2014 12:37:09 -0800 Subject: RFR (JAXP): 8035577: Xerces Update: impl/xpath/regex/RangeToken.java In-Reply-To: <5317869F.4010900@oracle.com> References: <5317869F.4010900@oracle.com> Message-ID: <53178AF5.5020702@oracle.com> nitpicking, (1) shouldn't the variable at #468 to be updated to "lch" instead of "uch" as well? (2) StringBuilder can be used to replace the StringBuffer in toString(). -Sherman On 03/05/2014 12:18 PM, David Li wrote: > Hi, > > This is an update from Xerces for file impl/xpath/regex/TokenRange.java. For details, please refer to: https://bugs.openjdk.java.net/browse/JDK-8035577. > > Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035577/webrev/ > > No new tests. There were none added in Xerces. > > Existing tests: JAXP SQE and unit tests passed. > > Thanks, > David From david.lloyd at redhat.com Wed Mar 5 20:37:17 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 05 Mar 2014 14:37:17 -0600 Subject: JEP 193: Enhanced Volatiles In-Reply-To: <5315015E.7010602@oracle.com> References: <20140303192647.75AB814B91@eggemoggin.niobe.net> <5315015E.7010602@oracle.com> Message-ID: <53178AFD.5070706@redhat.com> On 03/03/2014 04:25 PM, Brian Goetz wrote: >> Posted: http://openjdk.java.net/jeps/193 > > Some follow-up thoughts on teasing apart the issues covered by this JEP. > > There are three main layers of questions to answer: > > 1. How do we surface the various pieces of this into the programming > model? This includes language syntax (e.g., > x.volatile.compareAndSet()), library surface (e.g., the fictitious and > not-terribly-satisfying VolatileInt interface), and relevant > restrictions (e.g., can we do volatile operations on non-volatile fields > or array elements?) Also, relatedly, how far is this taken? It is easy to imagine operations of this sort on reference fields and fields of all 8 primitive types, as well as arrays of all 8 primitive types, and object arrays (which would of course cover all arrays-of-arrays as well). Following the interface idea, you would need (at a maximum) one interface type for each primitive type and one interface type for Objects. Arrays should be able to reuse the same interface type since array element types are constrained to the same set of possible types as fields (though without an actual volatile qualifier of course). So 9 interface types at maximum. At minimum, just having interfaces for ints, longs, and Objects would match what is presently defined in j.u.c.atomic, so 3 seems to be the low end. Personally I think it would be nicest to support all 8, but I expect there were probably good reasons (I'm guessing relating to false sharing) that we don't have AtomicBooleanArrays and so forth. Other random thought, the proposed .volatile syntax possibilities are a little funny (even by the standards of the base strangeness of the proposed syntax): // one of these I guess? int[] foo = ...; int x = foo[0].volatile.compareAndSet(10, 15); // this one, I suppose? int x = foo.volatile[0].compareAndSet(10, 15); If .volatile is treated as a postfix unary operator which operates on the left-hand term (what precedence I wonder? probably pretty high), then the first option makes the most sense and aligns well with "[objectexpression.]foo.volatile..." where "foo" is a field. -- - DML From Lance.Andersen at oracle.com Wed Mar 5 20:46:09 2014 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 5 Mar 2014 15:46:09 -0500 Subject: RFR (JAXP): 8035577: Xerces Update: impl/xpath/regex/RangeToken.java In-Reply-To: <53178AF5.5020702@oracle.com> References: <5317869F.4010900@oracle.com> <53178AF5.5020702@oracle.com> Message-ID: <9C0EC387-6864-4EBC-8D23-122DA086B946@oracle.com> On Mar 5, 2014, at 3:37 PM, Xueming Shen wrote: > nitpicking, > > (1) shouldn't the variable at #468 to be updated to "lch" instead of "uch" as well? I would agree given you are now calling Character.toLowerCase > (2) StringBuilder can be used to replace the StringBuffer in toString(). Agree, but I think this could be considered optional for this putback... > > -Sherman > > On 03/05/2014 12:18 PM, David Li wrote: >> Hi, >> >> This is an update from Xerces for file impl/xpath/regex/TokenRange.java. For details, please refer to: https://bugs.openjdk.java.net/browse/JDK-8035577. >> >> Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035577/webrev/ >> >> No new tests. There were none added in Xerces. >> >> Existing tests: JAXP SQE and unit tests passed. >> >> Thanks, >> David > -------------- next part -------------- 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 vladimir.x.ivanov at oracle.com Wed Mar 5 21:00:24 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 06 Mar 2014 01:00:24 +0400 Subject: JDK 9 RFR to remove a raw lint warning from java/lang/invoke/MethodHandleImpl.java In-Reply-To: <5315348B.5080904@oracle.com> References: <5315348B.5080904@oracle.com> Message-ID: <53179068.8020909@oracle.com> Joe, Looks good (not a Reviewer)! Thanks for the fix. Best regards, Vladimir Ivanov On 3/4/14 6:03 AM, Joe Darcy wrote: > Hello, > > The recent changeset for > > 8027827: Improve performance of catchException combinator > 8034120: MethodHandles.catchException doesn't handle > VarargsCollector right > > introduced a raw lint warning to the core libraries. Please review the > patch below which removes the warning by adding "" > to the type the exType parameter of the method. A JDK build succeeds > with the new signature in place. > > Thanks, > > -Joe > > diff -r 6cfedc362f48 > src/share/classes/java/lang/invoke/MethodHandleImpl.java > --- a/src/share/classes/java/lang/invoke/MethodHandleImpl.java Mon Mar > 03 18:17:00 2014 +0400 > +++ b/src/share/classes/java/lang/invoke/MethodHandleImpl.java Mon Mar > 03 17:49:52 2014 -0800 > @@ -734,7 +734,7 @@ > * (see {@link InvokerBytecodeGenerator#emitGuardWithCatch > emitGuardWithCatch}). > */ > @LambdaForm.Hidden > - static Object guardWithCatch(MethodHandle target, Class exType, > MethodHandle catcher, > + static Object guardWithCatch(MethodHandle target, Class Throwable> exType, MethodHandle catcher, > Object... av) throws Throwable { > try { > return target.invokeWithArguments(av); > From martinrb at google.com Wed Mar 5 21:27:18 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 5 Mar 2014 13:27:18 -0800 Subject: How to close a Process and having shutdown hooks called ? In-Reply-To: <6C970D250A1EFC45AF831AFA520141DFBAD592@mbxbr02> References: <6C970D250A1EFC45AF831AFA520141DFBAD025@mbxbr02> <5315C31B.6090109@oracle.com> <6C970D250A1EFC45AF831AFA520141DFBAD30D@mbxbr02> <5315E777.4020008@gmail.com> <6C970D250A1EFC45AF831AFA520141DFBAD592@mbxbr02> Message-ID: Because of the nature of Java, full access to the underlying OS is not likely to be available. Nothing is stopping you from doing your process management via either native code within your Java process or by placing an intermediate program that will give you fuller access to the OS (I like perl for this purpose) between java and the target executable. On Tue, Mar 4, 2014 at 7:05 AM, LE PICARD NICOLAS wrote: > Exactly ! > > In fact, I'm in mastery of ... nothing ! But I tried to workaround this > problem and found that Java Process class lacks something ! I was working > in Eclipse and you can process while testing (the red button in console > view) but shutdown hooks are not called. So I dug a little to understand > why Eclipse team said that it is not possible (up to now). Indeed, Eclipse > spawns a new Process Object (a new JVM in fact) but can't close it > gracefully. I think other application / programs may need such > functionnality so I post on this list to have advices of specialists of > openJdk. > > You are right again on the second part ! Actually I did exactly that in my > applications, only for debug/test, very simple : > boolean loopz = true; > InputStreamReader isr = null; > BufferedReader br = null; > try { > isr = new InputStreamReader(System.in); > br = new BufferedReader(isr); > while (loopz) { > String userInput = br.readLine(); > System.out.println("input => "+userInput); > if (userInput.equalsIgnoreCase("quit") || > userInput.equalsIgnoreCase("exit")) { > System.exit(0); > } > } > } > catch (Exception er) { > er.printStackTrace(); > loopz = false; > } > finally { > try { br.close(); } catch (Exception e) {} > try { isr.close(); } catch (Exception e) {} > } > > > However I think it could be a good add to Java to make a Process having > better control on its own child termination. > > Thanks ! > > Nicolas Le Picard > > > -----Message d'origine----- > De : Peter Levart [mailto:peter.levart at gmail.com] > Envoy? : mardi 4 mars 2014 15:47 > ? : LE PICARD NICOLAS; Alan Bateman; Krystal Mok > Cc : core-libs-dev at openjdk.java.net > Objet : Re: How to close a Process and having shutdown hooks called ? > > On 03/04/2014 02:09 PM, LE PICARD NICOLAS wrote: > > I didn't know for jdk8 functions destroy and the new one > destroyForcibly... > > > > And Jonathan was right in his previous answer, I was looking for a > solution in Java, I mean a portable one like in Process class, like the > "destroyGracefully". > > I am looking to signals because it seems to be a simple way to achieve > this "portable" solution, maybe I'm wrong. > > > > It would be useful (as you said) to have a function to kill "gracefully" > through Process class, no ? > > > > Nicolas Le Picard > > Hi Nicolas, > > So you're spawning a Java sub-process from a Java master process using > java.lang.Process, do I understand correctly? > > Are you in control of the code that represents the child sub-process? Is > this code already using System.in (STDIN) stream for anything? If the > answers are YES and NO respectively, then you may be able to use the > System.in in the sub-process (spawn a special monitoring thread) and > Process.getOutputStream() in the master process to establish a one way > channel for passing commands in direction: master process -> sub-process. > One of those commands could be "shutdown" for example, that would trigger a > System.exit() in the sub-process. This way you could make the shut-down > hooks in sub-process be executed before exiting... > > Regards, Peter > > > > > -----Message d'origine----- > > De : Alan Bateman [mailto:Alan.Bateman at oracle.com] Envoy? : mardi 4 > > mars 2014 13:12 ? : Krystal Mok Cc : LE PICARD NICOLAS; > > core-libs-dev at openjdk.java.net Objet : Re: How to close a Process and > > having shutdown hooks called ? > > > > On 04/03/2014 11:51, Krystal Mok wrote: > >> Hi Nicolas, > >> > >> Looks like a well discussed question. On Posix systems, SIGTERM > >> should work for you. That's the default signal sent by the 'kill' > command on Linux. > >> e.g. please take a look here: > >> http://stackoverflow.com/questions/2541597/how-to-gracefully-handle-t > >> h > >> e-sigkill-signal-in-java > >> > >> - Kris > >> > > I think he's on Windows and is looking for destroy to use something > other than TerminateProcess. > > > > As background, the destroy method was confusingly specified to kill the > sub-process forcibly but it wasn't implemented this way everywhere. On > Unix/Linux then the long standing implementation used SIGTERM and so no > guarantee that it would cause the sub-process to terminate. This mismatch > was examined in JDK 8 (you'll need to go through the archives of this > mailing list to see the discussion) and the javadoc updated to make it > clear that it is implementation specific as to whether it is done forcibly > or not. In addition a new destroyForcibly was added to do the SIGKILL or > TerminateProcess for cases where you really want to kill the child. There > isn't a corresponding destroyGracefully but clearly this would be useful if > were feasible to implement everywhere. > > > > -Alan. > > From Alan.Bateman at oracle.com Wed Mar 5 21:33:51 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 05 Mar 2014 21:33:51 +0000 Subject: RFR: JDK-8035340 - (prefs) Check jdk/src/windows/native/java/util/WindowsPreference.c for JNI pending exceptions In-Reply-To: <531780A0.90702@oracle.com> References: <531780A0.90702@oracle.com> Message-ID: <5317983F.1030602@oracle.com> On 05/03/2014 19:53, Mark Sheppard wrote: > Hi > Please oblige and review the following changes > http://cr.openjdk.java.net/~msheppar/8035340/webrev/ > > which address the issues raised in > https://bugs.openjdk.java.net/browse/JDK-8035340 > > This effort adds NULL checks and pending exception check after > JNI calls and adds NULL check to malloc calls in WindowsPreferences.c > This is a Windows change set. This mostly looks okay to me. One thing is the return path at L124 where I assume it should release valueNameStr. Could you also look at the indentation of return at L121 as it initially looks like later code is dead code. Otherwise looks okay. -Alan. From Alan.Bateman at oracle.com Wed Mar 5 21:38:40 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 05 Mar 2014 21:38:40 +0000 Subject: RFR (JAXP): 8035577: Xerces Update: impl/xpath/regex/RangeToken.java In-Reply-To: <5317869F.4010900@oracle.com> References: <5317869F.4010900@oracle.com> Message-ID: <53179960.4050700@oracle.com> On 05/03/2014 20:18, David Li wrote: > Hi, > > This is an update from Xerces for file > impl/xpath/regex/TokenRange.java. For details, please refer to: > https://bugs.openjdk.java.net/browse/JDK-8035577. > > Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035577/webrev/ > > No new tests. There were none added in Xerces. > > Existing tests: JAXP SQE and unit tests passed. Do you know if these tests exercise this code? I realize the Xerces didn't come with tests but I do have a concern about changing regex code without knowing that it is at least exercised by some tests. -Alan. From chris.hegarty at oracle.com Wed Mar 5 21:50:34 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 05 Mar 2014 21:50:34 +0000 Subject: RFR: JDK-8035340 - (prefs) Check jdk/src/windows/native/java/util/WindowsPreference.c for JNI pending exceptions In-Reply-To: <531780A0.90702@oracle.com> References: <531780A0.90702@oracle.com> Message-ID: <53179C2A.3070406@oracle.com> Looks ok to me Mark. -Chris. On 05/03/2014 19:53, Mark Sheppard wrote: > Hi > Please oblige and review the following changes > http://cr.openjdk.java.net/~msheppar/8035340/webrev/ > > which address the issues raised in > https://bugs.openjdk.java.net/browse/JDK-8035340 > > This effort adds NULL checks and pending exception check after > JNI calls and adds NULL check to malloc calls in WindowsPreferences.c > This is a Windows change set. > > regards > Mark From david.lloyd at redhat.com Wed Mar 5 22:01:28 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 05 Mar 2014 16:01:28 -0600 Subject: JEP 193: Enhanced Volatiles In-Reply-To: <531642C1.7040609@redhat.com> References: <20140303192647.75AB814B91@eggemoggin.niobe.net> <5315015E.7010602@oracle.com> <531507D0.9070907@redhat.com> <531642C1.7040609@redhat.com> Message-ID: <53179EB8.4030501@redhat.com> On 03/04/2014 03:16 PM, David M. Lloyd wrote: > On 03/03/2014 04:53 PM, David M. Lloyd wrote: >> On 03/03/2014 04:25 PM, Brian Goetz wrote: >>>> Posted: http://openjdk.java.net/jeps/193 >>> >>> Some follow-up thoughts on teasing apart the issues covered by this JEP. >>> >>> There are three main layers of questions to answer: >>> >>> 1. How do we surface the various pieces of this into the programming >>> model? This includes language syntax (e.g., >>> x.volatile.compareAndSet()), library surface (e.g., the fictitious and >>> not-terribly-satisfying VolatileInt interface), and relevant >>> restrictions (e.g., can we do volatile operations on non-volatile fields >>> or array elements?) >>> [...and then...] >>> 2. Translation to bytecodes. What bytecode should javac emit when it >>> encounters an volatile accessor or atomic update? We've identified a >>> handful of candidates: >>> >>> 2a: new bytecodes. This is the most direct and pure, but most intrusive >>> (and least extensible), means of delivering on the promise of "it's time >>> to move this stuff into the programming model proper." The "wide" >>> bytecode offers a means to express fenced variants of >>> {get,put}{field,static} with only a single new bytecode, but this >>> doesn't scale well to CAS (explosion of data types and data locations >>> (static field, instance field, array element)), which is really the >>> important case. >> >> Somewhere between new bytecodes and field handles, perhaps a single >> bytecode could suffice - one which is similar to getfield except instead >> of reading the field, it pushes a virtual "object" on to the stack which >> can then only be operated upon by invokeinterface on the pertinent >> "VolatileXxx" interface and otherwise doesn't have a real "type" per se. > > I suppose you'd also need a second bytecode for doing the same thing > with array elements like *aload, if that branch of this idea is pursued. It could even be a *real* object if it were possible to rely on some form of escape analysis to optimize it in the majority of cases, and if the puzzle of allocation/caching/storing the object could be solved, though the memory usage story in the non-escape case would have to be pretty buttoned down to make this acceptable IMO. -- - DML From stuart.marks at oracle.com Wed Mar 5 22:05:23 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 05 Mar 2014 14:05:23 -0800 Subject: RFR: (s) 8036095: RMI tests using testlibrary.RMID and testlibrary.JavaVM do not pass through vmoptions Message-ID: <53179FA3.4020108@oracle.com> Hi all, Please review this fix to change RMI's test library to pass through vmoptions and javaoptions to rmid and other JVM subprocesses. I've marked this as a "small" review because the changes of substance are confined to the first four files in the webrev, and they're pretty small. The remaining changes are to the individual security.policy files of each test, which requires different permissions granted in order to allow reading of the test.vm.opts and test.java.opts properties. Webrev: http://cr.openjdk.java.net/~smarks/reviews/8036095/webrev.0/ Bug report: https://bugs.openjdk.java.net/browse/JDK-8036095 Thanks, s'marks From mark.sheppard at oracle.com Wed Mar 5 22:05:55 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Wed, 05 Mar 2014 22:05:55 +0000 Subject: RFR: JDK-8035340 - (prefs) Check jdk/src/windows/native/java/util/WindowsPreference.c for JNI pending exceptions In-Reply-To: <5317983F.1030602@oracle.com> References: <531780A0.90702@oracle.com> <5317983F.1030602@oracle.com> Message-ID: <53179FC3.6050802@oracle.com> thanks Alan ... excellent spot (L124) regards Mark On 05/03/2014 21:33, Alan Bateman wrote: > On 05/03/2014 19:53, Mark Sheppard wrote: >> Hi >> Please oblige and review the following changes >> http://cr.openjdk.java.net/~msheppar/8035340/webrev/ >> >> which address the issues raised in >> https://bugs.openjdk.java.net/browse/JDK-8035340 >> >> This effort adds NULL checks and pending exception check after >> JNI calls and adds NULL check to malloc calls in WindowsPreferences.c >> This is a Windows change set. > This mostly looks okay to me. One thing is the return path at L124 > where I assume it should release valueNameStr. Could you also look at > the indentation of return at L121 as it initially looks like later > code is dead code. Otherwise looks okay. > > -Alan. From mark.sheppard at oracle.com Wed Mar 5 22:06:28 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Wed, 05 Mar 2014 22:06:28 +0000 Subject: RFR: JDK-8035340 - (prefs) Check jdk/src/windows/native/java/util/WindowsPreference.c for JNI pending exceptions In-Reply-To: <53179C2A.3070406@oracle.com> References: <531780A0.90702@oracle.com> <53179C2A.3070406@oracle.com> Message-ID: <53179FE4.7060602@oracle.com> thanks Chris On 05/03/2014 21:50, Chris Hegarty wrote: > Looks ok to me Mark. > > -Chris. > > On 05/03/2014 19:53, Mark Sheppard wrote: >> Hi >> Please oblige and review the following changes >> http://cr.openjdk.java.net/~msheppar/8035340/webrev/ >> >> which address the issues raised in >> https://bugs.openjdk.java.net/browse/JDK-8035340 >> >> This effort adds NULL checks and pending exception check after >> JNI calls and adds NULL check to malloc calls in WindowsPreferences.c >> This is a Windows change set. >> >> regards >> Mark From huizhe.wang at oracle.com Wed Mar 5 22:10:59 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 05 Mar 2014 14:10:59 -0800 Subject: RFR (JAXP): 8035577: Xerces Update: impl/xpath/regex/RangeToken.java In-Reply-To: <9C0EC387-6864-4EBC-8D23-122DA086B946@oracle.com> References: <5317869F.4010900@oracle.com> <53178AF5.5020702@oracle.com> <9C0EC387-6864-4EBC-8D23-122DA086B946@oracle.com> Message-ID: <5317A0F3.6060209@oracle.com> On 3/5/2014 12:46 PM, Lance Andersen - Oracle wrote: > On Mar 5, 2014, at 3:37 PM, Xueming Shen wrote: > >> nitpicking, >> >> (1) shouldn't the variable at #468 to be updated to "lch" instead of "uch" as well? > I would agree given you are now calling Character.toLowerCase Also, at line 463 and 464, it looks like 'uppers' meant to be 'lowers' defined at 462. >> (2) StringBuilder can be used to replace the StringBuffer in toString(). > Agree, but I think this could be considered optional for this putback... Yes, feel free to replace StringBuffer with StringBuilder, Vector to ArrayList and etc. -Joe > > >> -Sherman >> >> On 03/05/2014 12:18 PM, David Li wrote: >>> Hi, >>> >>> This is an update from Xerces for file impl/xpath/regex/TokenRange.java. For details, please refer to: https://bugs.openjdk.java.net/browse/JDK-8035577. >>> >>> Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035577/webrev/ >>> >>> No new tests. There were none added in Xerces. >>> >>> Existing tests: JAXP SQE and unit tests passed. >>> >>> Thanks, >>> David > > > 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 huizhe.wang at oracle.com Wed Mar 5 22:17:25 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 05 Mar 2014 14:17:25 -0800 Subject: RFR (JAXP): 8035577: Xerces Update: impl/xpath/regex/RangeToken.java In-Reply-To: <53179960.4050700@oracle.com> References: <5317869F.4010900@oracle.com> <53179960.4050700@oracle.com> Message-ID: <5317A275.10900@oracle.com> On 3/5/2014 1:38 PM, Alan Bateman wrote: > On 05/03/2014 20:18, David Li wrote: >> Hi, >> >> This is an update from Xerces for file >> impl/xpath/regex/TokenRange.java. For details, please refer to: >> https://bugs.openjdk.java.net/browse/JDK-8035577. >> >> Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035577/webrev/ >> >> No new tests. There were none added in Xerces. >> >> Existing tests: JAXP SQE and unit tests passed. > Do you know if these tests exercise this code? I realize the Xerces > didn't come with tests but I do have a concern about changing regex > code without knowing that it is at least exercised by some tests. There are over 100 tests in SQE suite in this area, we'll take a look. -Joe > > -Alan. From Lance.Andersen at oracle.com Wed Mar 5 22:22:56 2014 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 5 Mar 2014 17:22:56 -0500 Subject: RFR (JAXP): 8035577: Xerces Update: impl/xpath/regex/RangeToken.java In-Reply-To: <5317A0F3.6060209@oracle.com> References: <5317869F.4010900@oracle.com> <53178AF5.5020702@oracle.com> <9C0EC387-6864-4EBC-8D23-122DA086B946@oracle.com> <5317A0F3.6060209@oracle.com> Message-ID: <55B87C62-C651-4F1B-9AAF-7B6D07023A1F@oracle.com> On Mar 5, 2014, at 5:10 PM, huizhe wang wrote: > > On 3/5/2014 12:46 PM, Lance Andersen - Oracle wrote: >> On Mar 5, 2014, at 3:37 PM, Xueming Shen wrote: >> >>> nitpicking, >>> >>> (1) shouldn't the variable at #468 to be updated to "lch" instead of "uch" as well? >> I would agree given you are now calling Character.toLowerCase > > Also, at line 463 and 464, it looks like 'uppers' meant to be 'lowers' defined at 462. I think we should add tests with this change it looks like we really need to test this if your suggestion above is correct. > >>> (2) StringBuilder can be used to replace the StringBuffer in toString(). >> Agree, but I think this could be considered optional for this putback... > > Yes, feel free to replace StringBuffer with StringBuilder, Vector to ArrayList and etc. > > -Joe > >> >> >>> -Sherman >>> >>> On 03/05/2014 12:18 PM, David Li wrote: >>>> Hi, >>>> >>>> This is an update from Xerces for file impl/xpath/regex/TokenRange.java. For details, please refer to: https://bugs.openjdk.java.net/browse/JDK-8035577. >>>> >>>> Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035577/webrev/ >>>> >>>> No new tests. There were none added in Xerces. >>>> >>>> Existing tests: JAXP SQE and unit tests passed. >>>> >>>> Thanks, >>>> David >> >> >> 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 >> > -------------- next part -------------- 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 david.lloyd at redhat.com Wed Mar 5 23:05:13 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 05 Mar 2014 17:05:13 -0600 Subject: JEP 193: Enhanced Volatiles In-Reply-To: <53178AFD.5070706@redhat.com> References: <20140303192647.75AB814B91@eggemoggin.niobe.net> <5315015E.7010602@oracle.com> <53178AFD.5070706@redhat.com> Message-ID: <5317ADA9.9030402@redhat.com> On 03/05/2014 02:37 PM, David M. Lloyd wrote: > On 03/03/2014 04:25 PM, Brian Goetz wrote: >>> Posted: http://openjdk.java.net/jeps/193 >> >> Some follow-up thoughts on teasing apart the issues covered by this JEP. >> >> There are three main layers of questions to answer: >> >> 1. How do we surface the various pieces of this into the programming >> model? This includes language syntax (e.g., >> x.volatile.compareAndSet()), library surface (e.g., the fictitious and >> not-terribly-satisfying VolatileInt interface), and relevant >> restrictions (e.g., can we do volatile operations on non-volatile fields >> or array elements?) > > Also, relatedly, how far is this taken? It is easy to imagine > operations of this sort on reference fields and fields of all 8 > primitive types, as well as arrays of all 8 primitive types, and object > arrays (which would of course cover all arrays-of-arrays as well). > > Following the interface idea, you would need (at a maximum) one > interface type for each primitive type and one interface type for > Objects. Arrays should be able to reuse the same interface type since > array element types are constrained to the same set of possible types as > fields (though without an actual volatile qualifier of course). > > So 9 interface types at maximum. At minimum, just having interfaces for > ints, longs, and Objects would match what is presently defined in > j.u.c.atomic, so 3 seems to be the low end. > > Personally I think it would be nicest to support all 8, but I expect > there were probably good reasons (I'm guessing relating to false > sharing) that we don't have AtomicBooleanArrays and so forth. This should be "all 8 primitive types". > Other random thought, the proposed .volatile syntax possibilities are a > little funny (even by the standards of the base strangeness of the > proposed syntax): This should have been "possibilities *for arrays* are a little funny"... Guess I shouldn't bother sending emails with kids about. > // one of these I guess? > int[] foo = ...; > int x = foo[0].volatile.compareAndSet(10, 15); // this one, I suppose? > int x = foo.volatile[0].compareAndSet(10, 15); > > If .volatile is treated as a postfix unary operator which operates on > the left-hand term (what precedence I wonder? probably pretty high), > then the first option makes the most sense and aligns well with > "[objectexpression.]foo.volatile..." where "foo" is a field. -- - DML From david.holmes at oracle.com Thu Mar 6 00:24:49 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 06 Mar 2014 10:24:49 +1000 Subject: JEP 193: Enhanced Volatiles In-Reply-To: <53175D3A.7060502@univ-mlv.fr> References: <20140303192647.75AB814B91@eggemoggin.niobe.net> <5315015E.7010602@oracle.com> <53166B98.2060200@oracle.com> <531755E4.4050107@oracle.com> <95b7ac50741248abbf10009280ed9704@mane.sumatrasoftware.com> <531759BB.8020805@gmail.com> <53175D3A.7060502@univ-mlv.fr> Message-ID: <5317C051.8060100@oracle.com> On 6/03/2014 3:22 AM, Remi Forax wrote: > On 03/05/2014 06:07 PM, Peter Levart wrote: >> >> On 03/05/2014 05:55 PM, Jeroen Frijters wrote: >>> Brian Goetz wrote: >>> >>>> I suspect you were expecting this response: we don't add language >>>> semantics through annotations. >>> Technically, we're not adding language semantics. The JVM is the one >>> interpreting the annotations. >> >> And the JVM is the one implementing the language semantics (together >> with javac which feeds the JVM with bytecodes). Language semantcis are >> implemented by the combination of javac and JVM. If you say that this >> feature does not require any change to javac, you're just saying that >> you put all the burden on the JVM, but you *are* implementing the >> language semantics using annotations nevertheless... > > no, it's the other way around. javac maps Java the language to the > bytecode semantics. > The JVM only execute bytecodes. But if the JVM acts upon annotations to change how it executes those bytecodes then, as Peter said, the JVM is implementing the language semantics. It is also a bit misleading to say that the JVM only executes bytecodes, as the semantics of those bytecodes were driven by the requirements of the language. javac + jvm do form a team here. David >> >> >> Regards, Peter > > cheers, > R?mi > >> >>>> I'm not trying to frustrate you; evolving a language with millions of >>>> users is really, really hard. And one of the things that makes it hard >>>> is recognizing our intrinsic conflicts of interest between "what good >>>> will this do me" and "what harm will it do others." >>> I understand, that's why I want to avoid adding language support for >>> this niche/specialist feature. >>> >>> Regards, >>> Jeroen >>> >> > From joe.darcy at oracle.com Thu Mar 6 00:52:24 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 05 Mar 2014 16:52:24 -0800 Subject: JDK 9 RFR of JDK-8036744: Fix raw lint warnings in java.lang.reflect.WeakCache Message-ID: <5317C6C8.1090003@oracle.com> Hello, Please review the simple patch below which resolves two unchecked cast lint warnings in java.lang.reflect.WeakCache. Thanks, -Joe diff -r 9099a251d211 src/share/classes/java/lang/reflect/WeakCache.java --- a/src/share/classes/java/lang/reflect/WeakCache.java Wed Mar 05 11:53:35 2014 -0800 +++ b/src/share/classes/java/lang/reflect/WeakCache.java Wed Mar 05 16:51:20 2014 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2013, 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 @@ -184,6 +184,7 @@ return reverseMap.size(); } + @SuppressWarnings("unchecked") // refQueue.poll actually returns CacheKey private void expungeStaleEntries() { CacheKey cacheKey; while ((cacheKey = (CacheKey)refQueue.poll()) != null) { @@ -351,6 +352,7 @@ } @Override + @SuppressWarnings("unchecked") public boolean equals(Object obj) { K key; return obj == this || @@ -359,7 +361,7 @@ // cleared CacheKey is only equal to itself (key = this.get()) != null && // compare key by identity - key == ((CacheKey) obj).get(); + key == ((CacheKey) obj).get(); // Cast is safe from getClass check } void expungeFrom(ConcurrentMap> map, From lance.andersen at oracle.com Thu Mar 6 00:56:22 2014 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Wed, 5 Mar 2014 19:56:22 -0500 Subject: JDK 9 RFR of JDK-8036744: Fix raw lint warnings in java.lang.reflect.WeakCache In-Reply-To: <5317C6C8.1090003@oracle.com> References: <5317C6C8.1090003@oracle.com> Message-ID: <6304855C-AB2B-4D88-B787-851246364DC1@oracle.com> +1 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 Sent from my iPad On Mar 5, 2014, at 7:52 PM, Joe Darcy wrote: > Hello, > > Please review the simple patch below which resolves two unchecked cast lint warnings in java.lang.reflect.WeakCache. > > Thanks, > > -Joe > > diff -r 9099a251d211 src/share/classes/java/lang/reflect/WeakCache.java > --- a/src/share/classes/java/lang/reflect/WeakCache.java Wed Mar 05 11:53:35 2014 -0800 > +++ b/src/share/classes/java/lang/reflect/WeakCache.java Wed Mar 05 16:51:20 2014 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2013, 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 > @@ -184,6 +184,7 @@ > return reverseMap.size(); > } > > + @SuppressWarnings("unchecked") // refQueue.poll actually returns CacheKey > private void expungeStaleEntries() { > CacheKey cacheKey; > while ((cacheKey = (CacheKey)refQueue.poll()) != null) { > @@ -351,6 +352,7 @@ > } > > @Override > + @SuppressWarnings("unchecked") > public boolean equals(Object obj) { > K key; > return obj == this || > @@ -359,7 +361,7 @@ > // cleared CacheKey is only equal to itself > (key = this.get()) != null && > // compare key by identity > - key == ((CacheKey) obj).get(); > + key == ((CacheKey) obj).get(); // Cast is safe from getClass check > } > > void expungeFrom(ConcurrentMap> map, > From mandy.chung at oracle.com Thu Mar 6 00:57:11 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 05 Mar 2014 16:57:11 -0800 Subject: JDK 9 RFR of JDK-8036744: Fix raw lint warnings in java.lang.reflect.WeakCache In-Reply-To: <5317C6C8.1090003@oracle.com> References: <5317C6C8.1090003@oracle.com> Message-ID: <5317C7E7.5010506@oracle.com> Thumbs up. Mandy On 3/5/2014 4:52 PM, Joe Darcy wrote: > Hello, > > Please review the simple patch below which resolves two unchecked cast > lint warnings in java.lang.reflect.WeakCache. > > Thanks, > > -Joe > > diff -r 9099a251d211 src/share/classes/java/lang/reflect/WeakCache.java > --- a/src/share/classes/java/lang/reflect/WeakCache.java Wed Mar 05 > 11:53:35 2014 -0800 > +++ b/src/share/classes/java/lang/reflect/WeakCache.java Wed Mar 05 > 16:51:20 2014 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2013, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2013, 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 > @@ -184,6 +184,7 @@ > return reverseMap.size(); > } > > + @SuppressWarnings("unchecked") // refQueue.poll actually returns > CacheKey > private void expungeStaleEntries() { > CacheKey cacheKey; > while ((cacheKey = (CacheKey)refQueue.poll()) != null) { > @@ -351,6 +352,7 @@ > } > > @Override > + @SuppressWarnings("unchecked") > public boolean equals(Object obj) { > K key; > return obj == this || > @@ -359,7 +361,7 @@ > // cleared CacheKey is only equal to itself > (key = this.get()) != null && > // compare key by identity > - key == ((CacheKey) obj).get(); > + key == ((CacheKey) obj).get(); // Cast is safe > from getClass check > } > > void expungeFrom(ConcurrentMap ?>> map, > From david.holmes at oracle.com Thu Mar 6 00:57:42 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 06 Mar 2014 10:57:42 +1000 Subject: RFR: (s) 8036095: RMI tests using testlibrary.RMID and testlibrary.JavaVM do not pass through vmoptions In-Reply-To: <53179FA3.4020108@oracle.com> References: <53179FA3.4020108@oracle.com> Message-ID: <5317C806.1010107@oracle.com> On 6/03/2014 8:05 AM, Stuart Marks wrote: > Hi all, > > Please review this fix to change RMI's test library to pass through > vmoptions and javaoptions to rmid and other JVM subprocesses. Are you sure you want to do that? Run everything with -Xcomp for example? David > I've marked this as a "small" review because the changes of substance > are confined to the first four files in the webrev, and they're pretty > small. The remaining changes are to the individual security.policy files > of each test, which requires different permissions granted in order to > allow reading of the test.vm.opts and test.java.opts properties. > > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/8036095/webrev.0/ > > Bug report: > > https://bugs.openjdk.java.net/browse/JDK-8036095 > > Thanks, > > s'marks > > From stuart.marks at oracle.com Thu Mar 6 05:40:21 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 05 Mar 2014 21:40:21 -0800 Subject: RFR: (s) 8036095: RMI tests using testlibrary.RMID and testlibrary.JavaVM do not pass through vmoptions In-Reply-To: <5317C806.1010107@oracle.com> References: <53179FA3.4020108@oracle.com> <5317C806.1010107@oracle.com> Message-ID: <53180A45.40306@oracle.com> On 3/5/14 4:57 PM, David Holmes wrote: > On 6/03/2014 8:05 AM, Stuart Marks wrote: >> Please review this fix to change RMI's test library to pass through >> vmoptions and javaoptions to rmid and other JVM subprocesses. > > Are you sure you want to do that? Run everything with -Xcomp for example? The choice is between not passing the options and passing them through. I think it's more surprising not to have the options passed through. For example, the test makefiles pass -ea and -esa to jtreg, which adds them to test.vm.opts. Rmid and its activation group JVMs are just as much part of the system under test as the JDK running the test, so not having these options passed through means that we've been testing without assertions enabled in the subprocesses all these years. The -D option to set a system property should probably be passed through as well. I don't know if this makes sense for -Xcomp though. s'marks From david.holmes at oracle.com Thu Mar 6 05:46:49 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 06 Mar 2014 15:46:49 +1000 Subject: RFR: (s) 8036095: RMI tests using testlibrary.RMID and testlibrary.JavaVM do not pass through vmoptions In-Reply-To: <53180A45.40306@oracle.com> References: <53179FA3.4020108@oracle.com> <5317C806.1010107@oracle.com> <53180A45.40306@oracle.com> Message-ID: <53180BC9.8020608@oracle.com> On 6/03/2014 3:40 PM, Stuart Marks wrote: > On 3/5/14 4:57 PM, David Holmes wrote: >> On 6/03/2014 8:05 AM, Stuart Marks wrote: >>> Please review this fix to change RMI's test library to pass through >>> vmoptions and javaoptions to rmid and other JVM subprocesses. >> >> Are you sure you want to do that? Run everything with -Xcomp for example? > > The choice is between not passing the options and passing them through. > I think it's more surprising not to have the options passed through. For > example, the test makefiles pass -ea and -esa to jtreg, which adds them > to test.vm.opts. Rmid and its activation group JVMs are just as much > part of the system under test as the JDK running the test, so not having > these options passed through means that we've been testing without > assertions enabled in the subprocesses all these years. The -D option to > set a system property should probably be passed through as well. I don't > know if this makes sense for -Xcomp though. Indeed that is the problem with all of this - some settings you will want to pass through and some you won't. Though perhaps -Xcomp and other stress options are not something you have to be concerned about with normal core-libs testing. And conversely hotspot testing is unlikely to be running the RMI tests. So I guess it should be reasonably "safe". BTW not a review (sorry) :) David > s'marks From jeroen at sumatra.nl Thu Mar 6 07:52:03 2014 From: jeroen at sumatra.nl (Jeroen Frijters) Date: Thu, 6 Mar 2014 07:52:03 +0000 Subject: JEP 193: Enhanced Volatiles In-Reply-To: <531759BB.8020805@gmail.com> References: <20140303192647.75AB814B91@eggemoggin.niobe.net> <5315015E.7010602@oracle.com> <53166B98.2060200@oracle.com> <531755E4.4050107@oracle.com> <95b7ac50741248abbf10009280ed9704@mane.sumatrasoftware.com> <531759BB.8020805@gmail.com> Message-ID: Sorry Peter, but that is a nonsensical definition of language semantics. By using your definition, if Microsoft adds a feature to the CLR using custom attributes, the Java language semantics change, because on IKVM you can use these custom attributes in your Java code. Regards, Jeroen > -----Original Message----- > From: Peter Levart [mailto:peter.levart at gmail.com] > Sent: Wednesday, March 5, 2014 18:07 > To: Jeroen Frijters; Brian Goetz; core-libs-dev at openjdk.java.net; Doug > Lea > Subject: Re: JEP 193: Enhanced Volatiles > > > On 03/05/2014 05:55 PM, Jeroen Frijters wrote: > > > Brian Goetz wrote: > > > I suspect you were expecting this response: we don't add > language > semantics through annotations. > > Technically, we're not adding language semantics. The JVM is the > one interpreting the annotations. > > > And the JVM is the one implementing the language semantics (together > with javac which feeds the JVM with bytecodes). Language semantcis are > implemented by the combination of javac and JVM. If you say that this > feature does not require any change to javac, you're just saying that > you put all the burden on the JVM, but you *are* implementing the > language semantics using annotations nevertheless... > > > Regards, Peter > > > > > > I'm not trying to frustrate you; evolving a language with > millions of > users is really, really hard. And one of the things that > makes it hard > is recognizing our intrinsic conflicts of interest between > "what good > will this do me" and "what harm will it do others." > > I understand, that's why I want to avoid adding language support > for this niche/specialist feature. > > Regards, > Jeroen > > From jeroen at sumatra.nl Thu Mar 6 08:01:15 2014 From: jeroen at sumatra.nl (Jeroen Frijters) Date: Thu, 6 Mar 2014 08:01:15 +0000 Subject: JEP 193: Enhanced Volatiles In-Reply-To: <5317C051.8060100@oracle.com> References: <20140303192647.75AB814B91@eggemoggin.niobe.net> <5315015E.7010602@oracle.com> <53166B98.2060200@oracle.com> <531755E4.4050107@oracle.com> <95b7ac50741248abbf10009280ed9704@mane.sumatrasoftware.com> <531759BB.8020805@gmail.com> <53175D3A.7060502@univ-mlv.fr> <5317C051.8060100@oracle.com> Message-ID: <3a307320f10b48d4a6330b9fe7cfc89c@mane.sumatrasoftware.com> David Holmes wrote: > But if the JVM acts upon annotations to change how it executes those > bytecodes then, as Peter said, the JVM is implementing the language > semantics. The JVM synthesizes a native method, this has *nothing* to do with language semantics. From the language point of view, native method implementations magically appear. This is just another instance of that. Regards, Jeroen From Alan.Bateman at oracle.com Thu Mar 6 08:29:15 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 06 Mar 2014 08:29:15 +0000 Subject: RFR: (s) 8036095: RMI tests using testlibrary.RMID and testlibrary.JavaVM do not pass through vmoptions In-Reply-To: <53179FA3.4020108@oracle.com> References: <53179FA3.4020108@oracle.com> Message-ID: <531831DB.6090307@oracle.com> On 05/03/2014 22:05, Stuart Marks wrote: > Hi all, > > Please review this fix to change RMI's test library to pass through > vmoptions and javaoptions to rmid and other JVM subprocesses. > > I've marked this as a "small" review because the changes of substance > are confined to the first four files in the webrev, and they're pretty > small. The remaining changes are to the individual security.policy > files of each test, which requires different permissions granted in > order to allow reading of the test.vm.opts and test.java.opts properties. > > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/8036095/webrev.0/ I've looked through the changes and they look okay to me. I also grabbed the patch and ran the jdk_rmi tests with a few XX options specific to jtreg via -vmoption and it works. Just on David's comment then I think it would be surprising to specify options to jtreg but have some but not all tests use it consistently. There have been a number of passes over the shell tests to make sure that VM options are passed through but there is still work required to check tests that use Runtime.exec or ProcessBuilder to start other VMs to see that they pass through the expected options. As to whether someone would run these tests with -Xcomp or other stress options then I don't know but if they do then it would be strange for some tests to use it and not others. -Alan From Alan.Bateman at oracle.com Thu Mar 6 08:31:52 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 06 Mar 2014 08:31:52 +0000 Subject: RFR (JAXP): 8035577: Xerces Update: impl/xpath/regex/RangeToken.java In-Reply-To: <5317A275.10900@oracle.com> References: <5317869F.4010900@oracle.com> <53179960.4050700@oracle.com> <5317A275.10900@oracle.com> Message-ID: <53183278.30006@oracle.com> On 05/03/2014 22:17, huizhe wang wrote: > > On 3/5/2014 1:38 PM, Alan Bateman wrote: >> On 05/03/2014 20:18, David Li wrote: >>> Hi, >>> >>> This is an update from Xerces for file >>> impl/xpath/regex/TokenRange.java. For details, please refer to: >>> https://bugs.openjdk.java.net/browse/JDK-8035577. >>> >>> Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035577/webrev/ >>> >>> No new tests. There were none added in Xerces. >>> >>> Existing tests: JAXP SQE and unit tests passed. >> Do you know if these tests exercise this code? I realize the Xerces >> didn't come with tests but I do have a concern about changing regex >> code without knowing that it is at least exercised by some tests. > > There are over 100 tests in SQE suite in this area, we'll take a look. If you can check then that would be good as I think I can be forgiven for being nervous about bringing in patches that don't have tests. -Alan. From forax at univ-mlv.fr Thu Mar 6 09:22:49 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 06 Mar 2014 10:22:49 +0100 Subject: JEP 193: Enhanced Volatiles In-Reply-To: <5317C051.8060100@oracle.com> References: <20140303192647.75AB814B91@eggemoggin.niobe.net> <5315015E.7010602@oracle.com> <53166B98.2060200@oracle.com> <531755E4.4050107@oracle.com> <95b7ac50741248abbf10009280ed9704@mane.sumatrasoftware.com> <531759BB.8020805@gmail.com> <53175D3A.7060502@univ-mlv.fr> <5317C051.8060100@oracle.com> Message-ID: <53183E69.8010609@univ-mlv.fr> On 03/06/2014 01:24 AM, David Holmes wrote: > On 6/03/2014 3:22 AM, Remi Forax wrote: >> On 03/05/2014 06:07 PM, Peter Levart wrote: >>> >>> On 03/05/2014 05:55 PM, Jeroen Frijters wrote: >>>> Brian Goetz wrote: >>>> >>>>> I suspect you were expecting this response: we don't add language >>>>> semantics through annotations. >>>> Technically, we're not adding language semantics. The JVM is the one >>>> interpreting the annotations. >>> >>> And the JVM is the one implementing the language semantics (together >>> with javac which feeds the JVM with bytecodes). Language semantcis are >>> implemented by the combination of javac and JVM. If you say that this >>> feature does not require any change to javac, you're just saying that >>> you put all the burden on the JVM, but you *are* implementing the >>> language semantics using annotations nevertheless... >> >> no, it's the other way around. javac maps Java the language to the >> bytecode semantics. >> The JVM only execute bytecodes. > > But if the JVM acts upon annotations to change how it executes those > bytecodes then, as Peter said, the JVM is implementing the language > semantics. no, there is no bytecode in the proposal of Jeroen. You can see it has an extended way to call in a VM intrinsic, currently in Hotspot, you have to provide the class name, the method name and the signature to consider a method as an intrinsic. The mechanism proposed by Jeroen is a little bit more general. Moreover, the proposal is interesting because the signature of the native method is under the control of the user so unlike Unsafe equivalent the signature can be verified when the native method is linked making the method safer than their unsafe equivalent. > > It is also a bit misleading to say that the JVM only executes > bytecodes, as the semantics of those bytecodes were driven by the > requirements of the language. javac + jvm do form a team here. Most of the bytecodes are standard opcodes, but you're right that some of them like method calls, instance creation or to a lesser extent get[put]Field/get[put]Static have the Java semantics bolt in, that's why we have invokedynamic (and Unsafe.get/put) BTW. > > David R?mi > >>> >>> >>> Regards, Peter >> >> cheers, >> R?mi >> >>> >>>>> I'm not trying to frustrate you; evolving a language with millions of >>>>> users is really, really hard. And one of the things that makes it >>>>> hard >>>>> is recognizing our intrinsic conflicts of interest between "what good >>>>> will this do me" and "what harm will it do others." >>>> I understand, that's why I want to avoid adding language support for >>>> this niche/specialist feature. >>>> >>>> Regards, >>>> Jeroen >>>> >>> >> From tom.hawtin at oracle.com Thu Mar 6 14:48:03 2014 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Thu, 06 Mar 2014 14:48:03 +0000 Subject: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods In-Reply-To: <5315F228.1030503@redhat.com> References: <53110B02.7070602@oracle.com> <5312F127.60903@javaspecialists.eu> <53136337.9040001@redhat.com> <53137CE2.1010102@javaspecialists.eu> <53147C11.1010906@redhat.com> <53154C59.1000001@oracle.com> <5315F228.1030503@redhat.com> Message-ID: <53188AA3.6060208@oracle.com> On 04/03/2014 15:32, David M. Lloyd wrote: > On 03/03/2014 09:45 PM, David Holmes wrote: >> We should not introduce anything that allows something that was >> guaranteed to be safe by the language, to become unsafe. > > Define 'safe'. Because I don't think it's unsafe, any more than I believe even in the Java library it is common where a publicly accessible monitor is used to safeguard the integrity of security critical datastructures. Where monitorexit to become freely available, that would almost certainly be exploitable. (Technically I believe the JVM spec does (or did) allow unmatched locking in some circumstances, but implementations really shouldn't.) Tom From david.lloyd at redhat.com Thu Mar 6 14:51:50 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 06 Mar 2014 08:51:50 -0600 Subject: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods In-Reply-To: <53188AA3.6060208@oracle.com> References: <53110B02.7070602@oracle.com> <5312F127.60903@javaspecialists.eu> <53136337.9040001@redhat.com> <53137CE2.1010102@javaspecialists.eu> <53147C11.1010906@redhat.com> <53154C59.1000001@oracle.com> <5315F228.1030503@redhat.com> <53188AA3.6060208@oracle.com> Message-ID: <53188B86.2070406@redhat.com> On 03/06/2014 08:48 AM, Tom Hawtin wrote: > On 04/03/2014 15:32, David M. Lloyd wrote: >> On 03/03/2014 09:45 PM, David Holmes wrote: > >>> We should not introduce anything that allows something that was >>> guaranteed to be safe by the language, to become unsafe. >> >> Define 'safe'. Because I don't think it's unsafe, any more than > > I believe even in the Java library it is common where a publicly > accessible monitor is used to safeguard the integrity of security > critical datastructures. Where monitorexit to become freely available, > that would almost certainly be exploitable. I would expect that in a security-critical section, such monitors would be private, else they could be exploited in other ways. -- - DML From fweimer at redhat.com Thu Mar 6 15:25:16 2014 From: fweimer at redhat.com (Florian Weimer) Date: Thu, 06 Mar 2014 16:25:16 +0100 Subject: JEP 193: Enhanced Volatiles In-Reply-To: <53166A53.2090808@cs.oswego.edu> References: <20140303192647.75AB814B91@eggemoggin.niobe.net> <5315015E.7010602@oracle.com> <5315C18D.5030608@cs.oswego.edu> <53164FE3.8010507@redhat.com> <53166A53.2090808@cs.oswego.edu> Message-ID: <5318935C.7050503@redhat.com> On 03/05/2014 01:05 AM, Doug Lea wrote: > On 03/04/2014 05:12 PM, Florian Weimer wrote: >> On 03/04/2014 01:05 PM, Doug Lea wrote: >>> On 03/04/2014 02:41 AM, Jeroen Frijters wrote: >>>> I understand pass-by-reference is an expensive feature, but IMNSHO >>>> poluting >>>> Java with this proposal will prove to be more expensive in the long >>>> run. It's >>>> like erased generics all over again. >>>> >>> >>> The expensive version of pass-by-reference is already supported >>> using java.lang.reflect.Field. >> >> And per the statistics posted in >> , >> >> the slightly faster pointer-to-field-member support is one of the >> prevalent use >> cases for sun.misc.Unsafe. That's why I share Jeroen's puzzlement. > Sorry, I'm not sure what usages you have in mind, or > what constructions and implementable JVM mechanics > could be used to deal with them? If we had lightweight pointer-to-fields, things like compare-and-swap could be implemented as regular intrinsics. It would require less magic syntax, and make it clear that the operations only work with non-static fields and not on local variables etc. It would be possible to write functions that apply a complex sequence of updates to a field, which is impossible under the current proposal. (One aspect I like about Java is that is fairly uniform, e.g., that you can take a subexpression and turn it into a function, or that you can store intermediate results, something that is often impossible in Ada or C++). Pointer-to-fields could be as lightweight as a single integer (they are in C++ and with sun.misc.Unsafe), assuming that the VM enforces type safety. Whether it is a good idea to add another generic type at the VM level before the arrival of reified generics, is a different matter. -- Florian Weimer / Red Hat Product Security Team From vladimir.kempik at oracle.com Thu Mar 6 15:34:07 2014 From: vladimir.kempik at oracle.com (Vladimir Kempik) Date: Thu, 06 Mar 2014 19:34:07 +0400 Subject: RFR: 8036786: Update jdk7 testlibrary to match jdk8 Message-ID: <5318956F.1020603@oracle.com> Please review this change to update jdk part of testlibrary in jdk7. It updates testlibrary with new apis from jdk8's testlibrary. When porting jdk8's testlibrary to jdk7, I had to make few changes: 1) rewrite one lambda usage in StreamPumper.java to non-lambda version. 2) get rid of predicate functionality in ProcessTools.java: startProcess as it wasn't used anyway and unsupported in jdk7. Every test in open part of jdk that uses testlibrary still works after update (in fact there are 3 of them). Webrev: http://cr.openjdk.java.net/~vkempik/8036786/webrev.00/ Thanks, Vladimir. From fweimer at redhat.com Thu Mar 6 15:40:37 2014 From: fweimer at redhat.com (Florian Weimer) Date: Thu, 06 Mar 2014 16:40:37 +0100 Subject: JEP 193: Enhanced Volatiles In-Reply-To: <20140303192647.75AB814B91@eggemoggin.niobe.net> References: <20140303192647.75AB814B91@eggemoggin.niobe.net> Message-ID: <531896F5.1050509@redhat.com> What is the interaction with synthetic accessor methods for private fields? Is it not an issue because the field references will be textual anyway, so that no JVM checks will interfere? -- Florian Weimer / Red Hat Product Security Team From david.lloyd at redhat.com Thu Mar 6 15:38:35 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 06 Mar 2014 09:38:35 -0600 Subject: JEP 193: Enhanced Volatiles In-Reply-To: <5318935C.7050503@redhat.com> References: <20140303192647.75AB814B91@eggemoggin.niobe.net> <5315015E.7010602@oracle.com> <5315C18D.5030608@cs.oswego.edu> <53164FE3.8010507@redhat.com> <53166A53.2090808@cs.oswego.edu> <5318935C.7050503@redhat.com> Message-ID: <5318967B.7000003@redhat.com> On 03/06/2014 09:25 AM, Florian Weimer wrote: > On 03/05/2014 01:05 AM, Doug Lea wrote: >> On 03/04/2014 05:12 PM, Florian Weimer wrote: >>> On 03/04/2014 01:05 PM, Doug Lea wrote: >>>> On 03/04/2014 02:41 AM, Jeroen Frijters wrote: >>>>> I understand pass-by-reference is an expensive feature, but IMNSHO >>>>> poluting >>>>> Java with this proposal will prove to be more expensive in the long >>>>> run. It's >>>>> like erased generics all over again. >>>>> >>>> >>>> The expensive version of pass-by-reference is already supported >>>> using java.lang.reflect.Field. >>> >>> And per the statistics posted in >>> , >>> >>> >>> the slightly faster pointer-to-field-member support is one of the >>> prevalent use >>> cases for sun.misc.Unsafe. That's why I share Jeroen's puzzlement. > >> Sorry, I'm not sure what usages you have in mind, or >> what constructions and implementable JVM mechanics >> could be used to deal with them? > > If we had lightweight pointer-to-fields, things like compare-and-swap > could be implemented as regular intrinsics. It would require less magic > syntax, and make it clear that the operations only work with non-static > fields and not on local variables etc. It would be possible to write > functions that apply a complex sequence of updates to a field, which is > impossible under the current proposal. (One aspect I like about Java is > that is fairly uniform, e.g., that you can take a subexpression and turn > it into a function, or that you can store intermediate results, > something that is often impossible in Ada or C++). > > Pointer-to-fields could be as lightweight as a single integer (they are > in C++ and with sun.misc.Unsafe), assuming that the VM enforces type > safety. Whether it is a good idea to add another generic type at the VM > level before the arrival of reified generics, is a different matter. The proposed interface types *could* be used as such a "pointer", with the caveats I've given in another branch, that we'd really want the object "allocation" to be free or cheap in most cases. It's one construct that is effectively missing from JUC today. There is a "updater for field X on any object" and "updater for *otherwise inaccessible* field X on object Y" but there's no "updater for field X on object Y". The "foo.volatile" syntax *could* provide that, though this does run counter to the JEP which indicates that a raw "foo.volatile" is not by itself a valid expression. But the optimizability of the construct is really the key decision axis as far as I can see; specifically it would have to be able to optimize "foo.volatile.xxx()" constructs directly to the minimal set of instructions while still allowing "foo.volatile" to return a real object that can be fiddled with by others. In particular it would be really annoying if you had to manually maintain another field to hold this hypothetical value of "foo.volatile" to avoid creating a new one every time (though I think it's perfectly reasonable for the JVM to create a "hidden" field which does this in the case where this value escapes the stack). -- - DML From dalibor.topic at oracle.com Thu Mar 6 18:03:27 2014 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 06 Mar 2014 19:03:27 +0100 Subject: [7u backport] RFR: 7122142: (ann) Race condition between isAnnotationPresent and getAnnotations In-Reply-To: <531473C8.3070009@oracle.com> References: <53089694.4070308@oracle.com> <530B3E32.7020303@gmail.com> <530BB2F6.2000507@oracle.com> <20140227134411.GH4321@oracle.com> <531473C8.3070009@oracle.com> Message-ID: <5318B86F.2080405@oracle.com> Looks fine to me as well. cheers, dalibor topic On 3/3/14 1:21 PM, dmeetry degrave wrote: > Hi all, > > I would like to ask someone with a reviewer status in jdk7u project to look at these changes. > > thanks, > dmeetry > > On 02/27/2014 05:44 PM, Joel Borggren-Franck wrote: >> Hi, >> >> I looked at webrev.1. Looks good. >> >> cheers >> /Joel >> >> On 2014-02-25, dmeetry degrave wrote: >>> Thanks for looking at this, Peter! >>> >>> On 02/24/2014 04:42 PM, Peter Levart wrote: >>>> Hi Dmeetry, >>>> >>>> On 02/22/2014 01:22 PM, dmeetry degrave wrote: >>>>> Hi all, >>>>> >>>>> I would like to ask for a review of combined back port for >>>>> 7u-dev/7u80. The main goal is to have a fix for 7122142 in jdk7, it >>>>> also integrates the changes from 8005232, 7185456, 8022721 >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-7122142 >>>>> https://bugs.openjdk.java.net/browse/JDK-8005232 >>>>> https://bugs.openjdk.java.net/browse/JDK-7185456 >>>>> https://bugs.openjdk.java.net/browse/JDK-8022721 >>>>> >>>>> Original jdk8 changes: >>>>> >>>>> 7122142: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4ce6502eac0 >>>>> 8005232: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1109bfff4e92 >>>>> 7185456: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ae03282ba501 >>>>> 8022721: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2281a7f79738 >>>>> >>>>> back port: >>>>> >>>>> http://cr.openjdk.java.net/~dmeetry/7122142.8005232.7185456.8022721/webrev.0/ >>>>> >>>>> >>>>> Patches can't be applied cleanly, hence it was a manual back port, >>>>> though the final result is equivalent to applying the patches in >>>>> chronological order (8005232, 7185456, 7122142, 8022721) and applying >>>>> all the relevant rejected parts >>>> >>>> It's good to see those patches being back-ported to 7u. By browsing the >>>> webrev, I don't see any obvious difference between the original patches >>>> and the backport. >>> >>> there shouldn't be any! >>> >>>> Do you happen to remember in what part of code there >>>> were rejects so that you had to manually apply the changes? >>> >>> there were conflicts due to small difference between 7 and 8 >>> (copyrights, white spaces, @SuppressWarnings, Class,...). >>> >>> I copied all rejected parts and original patches here: >>> >>> http://cr.openjdk.java.net/~dmeetry/7122142.8005232.7185456.8022721/webrev.1/rej/ >>> >>>>> (with one exception, AnnotationTypeRuntimeAssumptionTest.java test was >>>>> not included due to jdk8 API). >>>> >>>> Ah, It's the Class.getDeclaredAnnotation(Class) that's new in JDK8. >>>> Here's the changed test that only uses the JDK7 API so you can include >>>> this test too: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk7u/7122142/AnnotationTypeRuntimeAssumptionTest.java >>> >>> Thanks! >>> >>> http://cr.openjdk.java.net/~dmeetry/7122142.8005232.7185456.8022721/webrev.1/ >>> >>> (just with the new test added). >>> >>> thanks, >>> dmeetry >>>>> >>>>> All tests in test/java/lang/annotation passed. >>>>> >>>>> thanks, >>>>> dmeetry >>>> >>>> Regards, Peter >>>> -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From huizhe.wang at oracle.com Thu Mar 6 19:16:41 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 06 Mar 2014 11:16:41 -0800 Subject: RFR (JAXP): 8035577: Xerces Update: impl/xpath/regex/RangeToken.java In-Reply-To: <53183278.30006@oracle.com> References: <5317869F.4010900@oracle.com> <53179960.4050700@oracle.com> <5317A275.10900@oracle.com> <53183278.30006@oracle.com> Message-ID: <5318C999.2030008@oracle.com> On 3/6/2014 12:31 AM, Alan Bateman wrote: > On 05/03/2014 22:17, huizhe wang wrote: >> >> On 3/5/2014 1:38 PM, Alan Bateman wrote: >>> On 05/03/2014 20:18, David Li wrote: >>>> Hi, >>>> >>>> This is an update from Xerces for file >>>> impl/xpath/regex/TokenRange.java. For details, please refer to: >>>> https://bugs.openjdk.java.net/browse/JDK-8035577. >>>> >>>> Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035577/webrev/ >>>> >>>> No new tests. There were none added in Xerces. >>>> >>>> Existing tests: JAXP SQE and unit tests passed. >>> Do you know if these tests exercise this code? I realize the Xerces >>> didn't come with tests but I do have a concern about changing regex >>> code without knowing that it is at least exercised by some tests. >> >> There are over 100 tests in SQE suite in this area, we'll take a look. > If you can check then that would be good as I think I can be forgiven > for being nervous about bringing in patches that don't have tests. Understand. We'll look into adding new tests. -Joe > > -Alan. From mandy.chung at oracle.com Thu Mar 6 21:10:44 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 06 Mar 2014 13:10:44 -0800 Subject: Review 8035808: Eliminate dependency to GetPropertyAction and other sun.security.action convenient classes Message-ID: <5318E454.107@oracle.com> Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035808/webrev.00/ This patch converts the use of sun.security.action.GetPropertyAction tolambda (PrivilegedAction) () -> System.getProperty(key) Similarly for GetIntegerAction and GetLongAction. The sun.security.action.* classes are just convenient classes that are used not only by the security library but also used by RMI, management, a couple other components that cause cross-module dependency that are not absolutely necessary. They can simply be replaced to call System.getProperty, Integer.getInteger, or Long.getLong at the callsite. Mandy From chris.hegarty at oracle.com Fri Mar 7 09:49:10 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 7 Mar 2014 09:49:10 +0000 Subject: Review 8035808: Eliminate dependency to GetPropertyAction and other sun.security.action convenient classes In-Reply-To: <5318E454.107@oracle.com> References: <5318E454.107@oracle.com> Message-ID: <76169DDB-1433-4267-9EE2-AE87AFF1BFCD@oracle.com> This looks good to me Mandy. Reviewed. -Chris. On 6 Mar 2014, at 21:10, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035808/webrev.00/ > > This patch converts the use of sun.security.action.GetPropertyAction tolambda > (PrivilegedAction) () -> System.getProperty(key) > > Similarly for GetIntegerAction and GetLongAction. > > The sun.security.action.* classes are just convenient classes that are used not only by the security library but also used by RMI, management, a couple other components that cause cross-module dependency that are not absolutely necessary. They can simply be replaced to call System.getProperty, Integer.getInteger, or Long.getLong at the callsite. > > Mandy From Alan.Bateman at oracle.com Fri Mar 7 11:31:44 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 07 Mar 2014 11:31:44 +0000 Subject: Review 8035808: Eliminate dependency to GetPropertyAction and other sun.security.action convenient classes In-Reply-To: <5318E454.107@oracle.com> References: <5318E454.107@oracle.com> Message-ID: <5319AE20.9010003@oracle.com> On 06/03/2014 21:10, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035808/webrev.00/ > > This patch converts the use of sun.security.action.GetPropertyAction > tolambda > (PrivilegedAction) () -> System.getProperty(key) > > Similarly for GetIntegerAction and GetLongAction. > > The sun.security.action.* classes are just convenient classes that are > used not only by the security library but also used by RMI, > management, a couple other components that cause cross-module > dependency that are not absolutely necessary. They can simply be > replaced to call System.getProperty, Integer.getInteger, or > Long.getLong at the callsite. This looks good to me as it reduces the number of inner classes, removes a lot of dependencies on sun.* APIs, and updates the code to use new language features. The only downside appears to the cast but you can't really get away from that here (at least not without declaring a PrivilegedAction for each usage). -Alan. From peter.levart at gmail.com Fri Mar 7 11:39:44 2014 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 07 Mar 2014 12:39:44 +0100 Subject: Review 8035808: Eliminate dependency to GetPropertyAction and other sun.security.action convenient classes In-Reply-To: <5319AE20.9010003@oracle.com> References: <5318E454.107@oracle.com> <5319AE20.9010003@oracle.com> Message-ID: <5319B000.8090306@gmail.com> On 03/07/2014 12:31 PM, Alan Bateman wrote: > On 06/03/2014 21:10, Mandy Chung wrote: >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035808/webrev.00/ >> >> This patch converts the use of sun.security.action.GetPropertyAction >> tolambda >> (PrivilegedAction) () -> System.getProperty(key) >> >> Similarly for GetIntegerAction and GetLongAction. >> >> The sun.security.action.* classes are just convenient classes that >> are used not only by the security library but also used by RMI, >> management, a couple other components that cause cross-module >> dependency that are not absolutely necessary. They can simply be >> replaced to call System.getProperty, Integer.getInteger, or >> Long.getLong at the callsite. > This looks good to me as it reduces the number of inner classes, > removes a lot of dependencies on sun.* APIs, and updates the code to > use new language features. The only downside appears to the cast but > you can't really get away from that here (at least not without > declaring a PrivilegedAction for each usage). > > -Alan. Maybe, if PrivilegedAction interface could be retrofitted as follows: public interface PrivilegedExceptionAction { T run() throws Exception; } public interface PrivilegedAction extends PrivilegedExceptionAction { @Override T run(); } Then in majority of cases where lambda body did not throw a checked exception, the most-specific rule would choose the doPrivileged(PrivilegedAction) method automatically... For checked-exceptional-cases the cast would still be needed. Regards, Peter From Alan.Bateman at oracle.com Fri Mar 7 11:50:55 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 07 Mar 2014 11:50:55 +0000 Subject: Review 8035808: Eliminate dependency to GetPropertyAction and other sun.security.action convenient classes In-Reply-To: <5319B000.8090306@gmail.com> References: <5318E454.107@oracle.com> <5319AE20.9010003@oracle.com> <5319B000.8090306@gmail.com> Message-ID: <5319B29F.5040908@oracle.com> On 07/03/2014 11:39, Peter Levart wrote: > > Maybe, if PrivilegedAction interface could be retrofitted as follows: > > public interface PrivilegedExceptionAction { > T run() throws Exception; > } > > public interface PrivilegedAction extends > PrivilegedExceptionAction { > @Override > T run(); > } > > > Then in majority of cases where lambda body did not throw a checked > exception, the most-specific rule would choose the > doPrivileged(PrivilegedAction) method automatically... For > checked-exceptional-cases the cast would still be needed. There was a discussion on security-dev about this some time ago and this bug created: https://bugs.openjdk.java.net/browse/JDK-8019851 I hope it will be looked at again in 9 as it is an inconvenience in the JDK (but perhaps not as much outside of the JDK where it's not going to be used very much). -Alan. From mark.sheppard at oracle.com Fri Mar 7 13:05:20 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Fri, 07 Mar 2014 13:05:20 +0000 Subject: RFR: JSK-8036609 - Check jdk/src/windows/native/java/lang/ProcessImpl_md.c for JNI pending exceptions Message-ID: <5319C410.5040402@oracle.com> Hi Please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8036609/webrev/ for the issues raised in https://bugs.openjdk.java.net/browse/JDK-8036609 summary: changes adds a couple of ExceptionChecks and a jboolean cast for CloseHandle regards Mark From mark.sheppard at oracle.com Fri Mar 7 13:11:16 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Fri, 07 Mar 2014 13:11:16 +0000 Subject: RFR: JSK-8036609 - Check jdk/src/windows/native/java/lang/ProcessImpl_md.c for JNI pending exceptions In-Reply-To: <5319C410.5040402@oracle.com> References: <5319C410.5040402@oracle.com> Message-ID: <5319C574.6050706@oracle.com> Subject should read RFR: JDK-8036609 apologies for the typo. regards Mark On 07/03/2014 13:05, Mark Sheppard wrote: > Hi > Please oblige and review the following changes > http://cr.openjdk.java.net/~msheppar/8036609/webrev/ > > for the issues raised in > https://bugs.openjdk.java.net/browse/JDK-8036609 > > summary: > changes adds a couple of ExceptionChecks and a jboolean cast for > CloseHandle > > regards > Mark > From fweimer at redhat.com Fri Mar 7 13:14:24 2014 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 07 Mar 2014 14:14:24 +0100 Subject: Review 8035808: Eliminate dependency to GetPropertyAction and other sun.security.action convenient classes In-Reply-To: <5319AE20.9010003@oracle.com> References: <5318E454.107@oracle.com> <5319AE20.9010003@oracle.com> Message-ID: <5319C630.4020605@redhat.com> On 03/07/2014 12:31 PM, Alan Bateman wrote: > This looks good to me as it reduces the number of inner classes, I think we had sun.security.action.GetPropertyAction for exactly this purpose. Consequently, the proposed change actually *increases* class size: -rw-rw-r--. 1 fweimer fweimer 6056 Mar 7 14:00 ./build-orig/linux-x86_64-normal-server-release/jdk/classes/java/rmi/activation/ActivationGroup.class -rw-rw-r--. 1 fweimer fweimer 6656 Mar 7 14:06 ./build/linux-x86_64-normal-server-release/jdk/classes/java/rmi/activation/ActivationGroup.class -- Florian Weimer / Red Hat Product Security Team From Alan.Bateman at oracle.com Fri Mar 7 14:36:58 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 07 Mar 2014 14:36:58 +0000 Subject: Review 8035808: Eliminate dependency to GetPropertyAction and other sun.security.action convenient classes In-Reply-To: <5319C630.4020605@redhat.com> References: <5318E454.107@oracle.com> <5319AE20.9010003@oracle.com> <5319C630.4020605@redhat.com> Message-ID: <5319D98A.1060509@oracle.com> On 07/03/2014 13:14, Florian Weimer wrote: > > I think we had sun.security.action.GetPropertyAction for exactly this > purpose. Consequently, the proposed change actually *increases* class > size: > > -rw-rw-r--. 1 fweimer fweimer 6056 Mar 7 14:00 > ./build-orig/linux-x86_64-normal-server-release/jdk/classes/java/rmi/activation/ActivationGroup.class > -rw-rw-r--. 1 fweimer fweimer 6656 Mar 7 14:06 > ./build/linux-x86_64-normal-server-release/jdk/classes/java/rmi/activation/ActivationGroup.class > Fair, there is a second downside but usually there is a win if there are inner classes replaced. -Alan. From Sergey.Bylokhov at oracle.com Fri Mar 7 15:03:45 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 07 Mar 2014 19:03:45 +0400 Subject: Review 8035808: Eliminate dependency to GetPropertyAction and other sun.security.action convenient classes In-Reply-To: <5319AE20.9010003@oracle.com> References: <5318E454.107@oracle.com> <5319AE20.9010003@oracle.com> Message-ID: <5319DFD1.7060006@oracle.com> On 3/7/14 3:31 PM, Alan Bateman wrote: > On 06/03/2014 21:10, Mandy Chung wrote: >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035808/webrev.00/ >> >> This patch converts the use of sun.security.action.GetPropertyAction >> tolambda >> (PrivilegedAction) () -> System.getProperty(key) >> >> Similarly for GetIntegerAction and GetLongAction. >> >> The sun.security.action.* classes are just convenient classes that >> are used not only by the security library but also used by RMI, >> management, a couple other components that cause cross-module >> dependency that are not absolutely necessary. They can simply be >> replaced to call System.getProperty, Integer.getInteger, or >> Long.getLong at the callsite. > This looks good to me as it reduces the number of inner classes, How it reduce the number of inner classes? Since it replaces a usage of one particular class to the new lambdas each time they are used. Is this absolutely necessary? Does it mean that Get**Actions are deprecated now? > removes a lot of dependencies on sun.* APIs, and updates the code to > use new language features. The only downside appears to the cast but > you can't really get away from that here (at least not without > declaring a PrivilegedAction for each usage). > > -Alan. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri Mar 7 15:34:50 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 07 Mar 2014 19:34:50 +0400 Subject: Review 8035808: Eliminate dependency to GetPropertyAction and other sun.security.action convenient classes In-Reply-To: <5319D98A.1060509@oracle.com> References: <5318E454.107@oracle.com> <5319AE20.9010003@oracle.com> <5319C630.4020605@redhat.com> <5319D98A.1060509@oracle.com> Message-ID: <5319E71A.308@oracle.com> Hi, Alan. Why we cannot move these classes to java.security.* package instead? On 3/7/14 6:36 PM, Alan Bateman wrote: > On 07/03/2014 13:14, Florian Weimer wrote: >> >> I think we had sun.security.action.GetPropertyAction for exactly this >> purpose. Consequently, the proposed change actually *increases* >> class size: >> >> -rw-rw-r--. 1 fweimer fweimer 6056 Mar 7 14:00 >> ./build-orig/linux-x86_64-normal-server-release/jdk/classes/java/rmi/activation/ActivationGroup.class >> -rw-rw-r--. 1 fweimer fweimer 6656 Mar 7 14:06 >> ./build/linux-x86_64-normal-server-release/jdk/classes/java/rmi/activation/ActivationGroup.class >> > Fair, there is a second downside but usually there is a win if there > are inner classes replaced. > > -Alan. -- Best regards, Sergey. From Alan.Bateman at oracle.com Fri Mar 7 15:58:02 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 07 Mar 2014 15:58:02 +0000 Subject: Review 8035808: Eliminate dependency to GetPropertyAction and other sun.security.action convenient classes In-Reply-To: <5319E71A.308@oracle.com> References: <5318E454.107@oracle.com> <5319AE20.9010003@oracle.com> <5319C630.4020605@redhat.com> <5319D98A.1060509@oracle.com> <5319E71A.308@oracle.com> Message-ID: <5319EC8A.3090408@oracle.com> On 07/03/2014 15:34, Sergey Bylokhov wrote: > Hi, Alan. > Why we cannot move these classes to java.security.* package instead? There's nothing to stop adding APIs in java.* but would need to consideration as to whether they hold their weight. It would be interesting to have some data on how many libraries and applications use PrivliegedActions, AccessController, etc. as it may not be too common. -Alan From miroslav.kos at oracle.com Fri Mar 7 16:21:55 2014 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Fri, 07 Mar 2014 17:21:55 +0100 Subject: RFR: 8036030: Update JAX-WS RI integration to latest version Message-ID: <5319F223.4090106@oracle.com> Hi, there is a bulk update of JAX-B/WS from upstream projects - webrev: http://cr.openjdk.java.net/~mkos/8036030/jaxws.00/ more details in issue desc: https://bugs.openjdk.java.net/browse/JDK-8036030 Thanks Miran From chris.hegarty at oracle.com Fri Mar 7 17:14:09 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 7 Mar 2014 17:14:09 +0000 Subject: RFR: JSK-8036609 - Check jdk/src/windows/native/java/lang/ProcessImpl_md.c for JNI pending exceptions In-Reply-To: <5319C574.6050706@oracle.com> References: <5319C410.5040402@oracle.com> <5319C574.6050706@oracle.com> Message-ID: <2AE7692D-7D28-4D0D-BA6F-B61081093803@oracle.com> The changes look ok to me Mark. -Chris. On 7 Mar 2014, at 13:11, Mark Sheppard wrote: > Subject should read > > RFR: JDK-8036609 > > apologies for the typo. > > regards > Mark > > On 07/03/2014 13:05, Mark Sheppard wrote: >> Hi >> Please oblige and review the following changes >> http://cr.openjdk.java.net/~msheppar/8036609/webrev/ >> >> for the issues raised in >> https://bugs.openjdk.java.net/browse/JDK-8036609 >> >> summary: >> changes adds a couple of ExceptionChecks and a jboolean cast for CloseHandle >> >> regards >> Mark >> > From volker.simonis at gmail.com Fri Mar 7 17:43:55 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 7 Mar 2014 18:43:55 +0100 Subject: RFR: 7152892: some jtreg tests fail with permission denied In-Reply-To: <52F52990.5060200@oracle.com> References: <52F52990.5060200@oracle.com> Message-ID: Hi Rob and everybody else on this list, just as a broad link (I don't want to offend anybody, just create some awareness :) We have a new platform called 'AIX' in the OpenJDK. For the matter of JTreg test it behaves mostly like every other Unix platform. I would really appreciate it very much if future test additions/changes which contain the famous: case "$OS" in SunOS | Linux | Darwin ) FS="/" pattern could also add 'AIX' to this list. For this change that would have been especially simple because it also changed several files which already used the new pattern (e.g. test/java/rmi/registry/readTest/readTest.sh): case "$OS" in SunOS | Linux | Darwin | AIX ) PS=":" FS="/" Should there arise any PPC64/AIX related questions in the future please simply CC "ppc-aix-port-dev at openjdk.java.net" - we will be happy to assist. Thank you and best regards, Volker On Fri, Feb 7, 2014 at 7:44 PM, Rob McKenna wrote: > Hi folks, > > When files are copied by our test harness the permissions are left > unchanged. This can cause trouble for a few tests when the test folder is > read only. > > http://cr.openjdk.java.net/~robm/7152892/webrev.01/ > > -Rob > > From brian.burkhalter at oracle.com Fri Mar 7 18:52:27 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 7 Mar 2014 10:52:27 -0800 Subject: JDK 9 RFR of 8036848: Fix deprecation warning in sun.misc.CharacterDecoder Message-ID: <5FAE13CA-1849-4F00-82BB-52797AAA1005@oracle.com> Hello all, This should be an easy one but then again I've been gravely in error about that before ? Issue: https://bugs.openjdk.java.net/browse/JDK-8036848 Patch: http://cr.openjdk.java.net/~bpb/8036848/ Deprecated method: http://download.java.net/jdk8/docs/api/java/lang/String.html#getBytes-int-int-byte:A-int- Successor method: http://download.java.net/jdk8/docs/api/java/lang/String.html#getBytes-- These tests were run (so far): com/sun/crypto/provider/Cipher/KeyWrap/XMLEncKAT.java java/util/Base64/TestBase64Golden.java javax/net/ssl/TLSv12/ShortRSAKeyGCM.java sun/misc/Encode/DecodeBuffer.java sun/misc/Encode/GetBytes.java Thanks, Brian From brian.burkhalter at oracle.com Fri Mar 7 19:46:55 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 7 Mar 2014 11:46:55 -0800 Subject: JDK 9 RFR of 8036848: Fix deprecation warning in sun.misc.CharacterDecoder In-Reply-To: <5FAE13CA-1849-4F00-82BB-52797AAA1005@oracle.com> References: <5FAE13CA-1849-4F00-82BB-52797AAA1005@oracle.com> Message-ID: On Mar 7, 2014, at 10:52 AM, Brian Burkhalter wrote: > Patch: http://cr.openjdk.java.net/~bpb/8036848/ I updated this patch to change some ugly albeit legal syntax. Old: http://cr.openjdk.java.net/~bpb/8036848/webrev.00/ New: http://cr.openjdk.java.net/~bpb/8036848/webrev.01/ To be specific, this method syntax public byte methodReturningByteArray()[] {} was changed to public byte[] methodReturningByteArray() {} Shudder ? Thanks, Brian From mandy.chung at oracle.com Fri Mar 7 20:00:51 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 07 Mar 2014 12:00:51 -0800 Subject: JDK 9 RFR of 8036848: Fix deprecation warning in sun.misc.CharacterDecoder In-Reply-To: References: <5FAE13CA-1849-4F00-82BB-52797AAA1005@oracle.com> Message-ID: <531A2573.4060901@oracle.com> Thumbs up. Mandy On 3/7/14 11:46 AM, Brian Burkhalter wrote: > On Mar 7, 2014, at 10:52 AM, Brian Burkhalter wrote: > >> Patch: http://cr.openjdk.java.net/~bpb/8036848/ > I updated this patch to change some ugly albeit legal syntax. > > Old: http://cr.openjdk.java.net/~bpb/8036848/webrev.00/ > New: http://cr.openjdk.java.net/~bpb/8036848/webrev.01/ > > To be specific, this method syntax > > public byte methodReturningByteArray()[] {} > > was changed to > > public byte[] methodReturningByteArray() {} > > Shudder ? > > Thanks, > > Brian From mandy.chung at oracle.com Fri Mar 7 20:19:23 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 07 Mar 2014 12:19:23 -0800 Subject: Review 8035808: Eliminate dependency to GetPropertyAction and other sun.security.action convenient classes In-Reply-To: <5319DFD1.7060006@oracle.com> References: <5318E454.107@oracle.com> <5319AE20.9010003@oracle.com> <5319DFD1.7060006@oracle.com> Message-ID: <531A29CB.3030307@oracle.com> On 3/7/14 7:03 AM, Sergey Bylokhov wrote: > Is this absolutely necessary? Does it mean that Get**Actions are > deprecated now? The question should be whether this dependency is absolutely necessary and it's not. Get**Action classes are simple convenient classes that you could either use lambda or implement your own one. AWT and other client code in the JDK is another heavy user of sun.security.action that you can consider simply have your own convenient class as module-private API. If sun.security.action were private to the security library, they would not be used in the client code in the first place (there are external code depending on it too [1 for example]). Now we are retrofitting and eliminate unnecessary dependency. Mandy [1] http://grepcode.com/file/repo1.maven.org/maven2/com.googlecode.streamflyer-regex-fast/streamflyer-regex-fast/1.0.1/com/googlecode/streamflyer/regex/fast/PatternSyntaxException.java#PatternSyntaxException.0nl From roger.riggs at oracle.com Fri Mar 7 20:28:49 2014 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 07 Mar 2014 15:28:49 -0500 Subject: Review 8035808: Eliminate dependency to GetPropertyAction and other sun.security.action convenient classes In-Reply-To: <531A29CB.3030307@oracle.com> References: <5318E454.107@oracle.com> <5319AE20.9010003@oracle.com> <5319DFD1.7060006@oracle.com> <531A29CB.3030307@oracle.com> Message-ID: <531A2C01.3000605@oracle.com> Hi, Lambda is deceptively lightweight. It seems like a straightforward operation but the real implementation is more costly than one might expect. There are other cases where the implementation doesn't match the appearance, for example, who pays any attention to the fact that String in switch creates an extra inner class. Roger On 3/7/2014 3:19 PM, Mandy Chung wrote: > On 3/7/14 7:03 AM, Sergey Bylokhov wrote: >> Is this absolutely necessary? Does it mean that Get**Actions are >> deprecated now? > > The question should be whether this dependency is absolutely necessary > and it's not. Get**Action classes are simple convenient classes that > you could either use lambda or implement your own one. AWT and other > client code in the JDK is another heavy user of sun.security.action > that you can consider simply have your own convenient class as > module-private API. If sun.security.action were private to the > security library, they would not be used in the client code in the > first place (there are external code depending on it too [1 for > example]). Now we are retrofitting and eliminate unnecessary dependency. > > Mandy > [1] > http://grepcode.com/file/repo1.maven.org/maven2/com.googlecode.streamflyer-regex-fast/streamflyer-regex-fast/1.0.1/com/googlecode/streamflyer/regex/fast/PatternSyntaxException.java#PatternSyntaxException.0nl From brian.burkhalter at oracle.com Fri Mar 7 20:54:56 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 7 Mar 2014 12:54:56 -0800 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <5315EDAA.5020801@gmail.com> Message-ID: <7BD90C4B-C1CC-4B9F-8C6E-47C1BA299C1F@oracle.com> On Mar 3, 2014, at 4:14 PM, Brian Burkhalter wrote: PING-INg-Ing-ing! > This review request concerns this issue and proposed patch: > > issue https://bugs.openjdk.java.net/browse/JDK-6375303 > patch http://cr.openjdk.java.net/~bpb/6375303/webrev.00/ On Mar 4, 2014, at 9:21 AM, Mike Duigou wrote: > On Mar 4 2014, at 07:13 , Peter Levart wrote: > >> On 03/04/2014 01:14 AM, Brian Burkhalter wrote: >>> - add AtomicReferenceFieldUpdater-type constant for stringCache initialization >> >> Hi Brian, >> >> By using volatile read and CAS, there's still a chance that multiple concurrent threads will be invoking the layoutChars(true) concurrently, but you guarantee that only a single instance of String will ever be returned as a result of the toString() method. Is that what you were pursuing? > > Yes. (I provided the AtomicReferenceFieldUpdater code). The previous implementation had a benign data race that could result in a later layoutChars result replacing an earlier result and multiple string instances being returned. The new implementation, at small cost, prevents multiple different instances from being returned. > > Mike If this looks copacetic, would a JDK 9 Reviewer kindly proffer their Imprimatur? Thanks, Brian From mark.sheppard at oracle.com Fri Mar 7 21:24:28 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Fri, 07 Mar 2014 21:24:28 +0000 Subject: RFR: JDK-8036603 - Check jdk/src/windows/native/java/lang/ProcessEnvironment_md.c for JNI pending exceptions Message-ID: <531A390C.3020802@oracle.com> Hi, Please oblige and review the changes http://cr.openjdk.java.net/~msheppar/8036603/webrev/ which address the issues raised in https://bugs.openjdk.java.net/browse/JDK-8036603 summary JNU_ClassString extracted as parameter to GetMethodID and NewObject calls and NUL_CHECKed regards Mark From Alan.Bateman at oracle.com Fri Mar 7 21:34:44 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 07 Mar 2014 21:34:44 +0000 Subject: RFR: JDK-8036603 - Check jdk/src/windows/native/java/lang/ProcessEnvironment_md.c for JNI pending exceptions In-Reply-To: <531A390C.3020802@oracle.com> References: <531A390C.3020802@oracle.com> Message-ID: <531A3B74.2060205@oracle.com> On 07/03/2014 21:24, Mark Sheppard wrote: > > Hi, > Please oblige and review the changes > http://cr.openjdk.java.net/~msheppar/8036603/webrev/ > > which address the issues raised in > https://bugs.openjdk.java.net/browse/JDK-8036603 > > summary > JNU_ClassString extracted as parameter to GetMethodID and NewObject calls > and NUL_CHECKed Is it necessary to call JNU_ClassString twice? (just wondering if L65-66 can be removed). One suggestion for class_for_method is to rename it to str_class as it might be a bit clearer. -Alan. From mandy.chung at oracle.com Fri Mar 7 21:39:36 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 07 Mar 2014 13:39:36 -0800 Subject: RFR: JDK-8036603 - Check jdk/src/windows/native/java/lang/ProcessEnvironment_md.c for JNI pending exceptions In-Reply-To: <531A390C.3020802@oracle.com> References: <531A390C.3020802@oracle.com> Message-ID: <531A3C98.5050901@oracle.com> On 3/7/14 1:24 PM, Mark Sheppard wrote: > > Hi, > Please oblige and review the changes > http://cr.openjdk.java.net/~msheppar/8036603/webrev/ > Better to rename the variable to "stringClass" or something more explicit. Also you can get rid of line 65-66 to simply use "stringClass". I think the caller doesn't check for null that is not an issue since java.lang.String always exists. Another option is to throw InternalError. Mandy From mandy.chung at oracle.com Fri Mar 7 23:30:36 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 07 Mar 2014 15:30:36 -0800 Subject: Review 8035808: Eliminate dependency to GetPropertyAction and other sun.security.action convenient classes In-Reply-To: <531A461E.6000801@oracle.com> References: <5318E454.107@oracle.com> <5319AE20.9010003@oracle.com> <5319DFD1.7060006@oracle.com> <531A29CB.3030307@oracle.com> <531A461E.6000801@oracle.com> Message-ID: <531A569C.7070003@oracle.com> On 3/7/14 2:20 PM, Sergey Bylokhov wrote: > On 3/8/14 12:19 AM, Mandy Chung wrote: >> On 3/7/14 7:03 AM, Sergey Bylokhov wrote: >>> Is this absolutely necessary? Does it mean that Get**Actions are >>> deprecated now? >> >> The question should be whether this dependency is absolutely >> necessary and it's not. Get**Action classes are simple convenient >> classes that you could either use lambda or implement your own one. >> AWT and other client code in the JDK is another heavy user of >> sun.security.action that you can consider simply have your own >> convenient class as module-private API. If sun.security.action were >> private to the security library, they would not be used in the client >> code in the first place (there are external code depending on it too >> [1 for example]). Now we are retrofitting and eliminate unnecessary >> dependency. > But after this fix: size of class files are increased, instead of > usage of one or two classes we get 50 new lambdas, and of course this > horrible cast. > new GetPropertyAction("user.home")); > vs > (PrivilegedAction) () -> System.getProperty("user.home")); I don't like the cast either and can leave with it as the explicit method call is actually a plus. JDK-8019851 will re-examine this in 9 to bring something better. I'll need to find out from the performance team if the footprint is an issue. I'll follow this up and if it turns out to be an issue, we will fix it differently. The main fix here is to remove the dependency. Sergey - for client code, I do think it's good to eliminate such dependency. On the other hand, as the client code (desktop module) depends on many other internal APIs in the base module, I'll leave it as it is and revisit it later. thanks Mandy From mark.sheppard at oracle.com Fri Mar 7 22:21:55 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Fri, 07 Mar 2014 22:21:55 +0000 Subject: RFR: JDK-8036603 - Check jdk/src/windows/native/java/lang/ProcessEnvironment_md.c for JNI pending exceptions In-Reply-To: <531A3B74.2060205@oracle.com> References: <531A390C.3020802@oracle.com> <531A3B74.2060205@oracle.com> Message-ID: <531A4683.3070606@oracle.com> Thanks Alan and Mandy for the feedback I make the amendments as you both suggest regards Mark On 07/03/2014 21:34, Alan Bateman wrote: > On 07/03/2014 21:24, Mark Sheppard wrote: >> >> Hi, >> Please oblige and review the changes >> http://cr.openjdk.java.net/~msheppar/8036603/webrev/ >> >> which address the issues raised in >> https://bugs.openjdk.java.net/browse/JDK-8036603 >> >> summary >> JNU_ClassString extracted as parameter to GetMethodID and NewObject >> calls >> and NUL_CHECKed > Is it necessary to call JNU_ClassString twice? (just wondering if > L65-66 can be removed). One suggestion for class_for_method is to > rename it to str_class as it might be a bit clearer. > > -Alan. From christian.thalinger at oracle.com Sat Mar 8 00:51:17 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 7 Mar 2014 16:51:17 -0800 Subject: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed) In-Reply-To: <531630D8.7030402@oracle.com> References: <531630D8.7030402@oracle.com> Message-ID: <9CEB01B8-D089-40DC-B63D-779A2994B6C9@oracle.com> Seems good to me. I?d like to have another name for this method: + private static Object invokeCustom(MethodHandle target, Object... args) throws Throwable { On Mar 4, 2014, at 12:00 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8036117/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8036117 > 84 lines changed: 74 ins; 3 del; 7 mod > > I have to revert a cleanup I did for 8027827. > MethodHandle.invokeWithArguments (and generic invocation) has unpleasant > peculiarity in behavior when used with VarargsCollector. So, > unfortunately, invokeWithArguments is not an option there. > > Looking at the API (excerpts from javadoc [1] [2]), the following > condition doesn't hold in that case: > "trailing parameter type of the caller is a reference type identical > to or assignable to the trailing parameter type of the adapter". > > Example: > target.invokeWithArguments((Object[])args) > => > target.invoke((Object)o1,(Object)o2,(Object)o3) > =/> > target.invokeExact((Object)o1, (Object)o2, (Object[])o3) > > because Object !<: Object[]. > > The fix is to skip unnecessary conversion when invoking a method handle > and just do a pairwise type conversion. > > Testing: failing test case, nashorn w/ experimental features (octane) > > Thanks! > > Best regards, > Vladimir Ivanov > > [1] MethodHandle.invokeWithArguments > "Performs a variable arity invocation, ..., as if via an inexact invoke > from a call site which mentions only the type Object, and whose arity is > the length of the argument array." > > [2] MethodHandle.asVarargsCollector > "When called with plain, inexact invoke, if the caller type is the same > as the adapter, the adapter invokes the target as with invokeExact. > (This is the normal behavior for invoke when types match.) > > Otherwise, if the caller and adapter arity are the same, and the > trailing parameter type of the caller is a reference type identical to > or assignable to the trailing parameter type of the adapter, the > arguments and return values are converted pairwise, as if by asType on a > fixed arity method handle. > > Otherwise, the arities differ, or the adapter's trailing parameter type > is not assignable from the corresponding caller type. In this case, the > adapter replaces all trailing arguments from the original trailing > argument position onward, by a new array of type arrayType, whose > elements comprise (in order) the replaced arguments." > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From blackdrag at gmx.org Mon Mar 10 15:10:02 2014 From: blackdrag at gmx.org (Jochen Theodorou) Date: Mon, 10 Mar 2014 16:10:02 +0100 Subject: clarification on docs of Class#getInterfaces() and Class#getGenericInterfaces() needed? Message-ID: <531DD5CA.9080106@gmx.org> Hi, hoping I will not annoy anyway asking this here I was wondering about how to interpret the javadoc of these methods correctly. You basically find this sentence for Class#getInterfaces() and Class#getGenericInterfaces() "If this object represents a class, the return value is an array containing objects representing all interfaces implemented by the class." The problem is that wording of "all". When I look at for example AbstractList, then all means to me more than just List (which is what is returned for AbstractList.class.getInterfaces()). Furthermore, since the wording is so equal you would assume that getInterfaces() and getGenericInterfaces() will always return the same interfaces, in the same order, same length, only one generified, the other not. But this is only true for classes produced by the java compiler. getInterfaces seems to read what is produced from "implements part" in bytecode, while getGenericinterfaces uses the signature. There seems to be nothing forbidding a different order or even a different number. The example, that did bring me to this is scala.runtime.AbstractPartialFunction from Scala 2.10.2 (other versions I did not check). While the implements part says only PartialFunction, the generics signature contains Function1 as well. Since PartialFunction implements Function1 there should be no real problem with that, unless you wrote code like me, that did depend on the two methods returning more or less the same. While much shorter the javadoc used in Android is for me much more clear: http://developer.android.com/reference/java/lang/Class.html#getInterfaces%28%29 """ Returns an array of Class objects that match the interfaces in the implements declaration of the class represented by this Class. The order of the elements in the array is identical to the order in the original class declaration. If the class does not implement any interfaces, an empty array is returned. """ I won't say this will prevent the mistake I made, but at least it will prevent the assumption *all* interfaces are to be shown here. All in all I find it quite difficult to phrase this to not awake assumptions like that, without especially mentioning it. But anyway... should the javadoc be changed? bye Jochen From volker.simonis at gmail.com Mon Mar 10 18:16:36 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 10 Mar 2014 19:16:36 +0100 Subject: RFR[9](XXS): 8037013: [TESTBUG] Fix test/java/lang/ClassLoader/Assert.sh on AIX Message-ID: Hi, could you please review the following trivial change which adds AIX to the list of known OSs in test/java/lang/ClassLoader/Assert.sh: https://bugs.openjdk.java.net/browse/JDK-8037013 http://cr.openjdk.java.net/~simonis/webrevs/8037013/ Thank you and best regards, Volker From mandy.chung at oracle.com Mon Mar 10 18:55:26 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 10 Mar 2014 11:55:26 -0700 Subject: RFR[9](XXS): 8037013: [TESTBUG] Fix test/java/lang/ClassLoader/Assert.sh on AIX In-Reply-To: References: Message-ID: <531E0A9E.50908@oracle.com> Hi Volker, On 3/10/14 11:16 AM, Volker Simonis wrote: > Hi, > > could you please review the following trivial change which adds AIX to > the list of known OSs in test/java/lang/ClassLoader/Assert.sh: > > https://bugs.openjdk.java.net/browse/JDK-8037013 > http://cr.openjdk.java.net/~simonis/webrevs/8037013/ > The link to your webrev is not accessible and could possibly due to the server issue. I guess your fix is to add AIX in the Assert.sh test. Can you paste the diff in mail? I can review it. I raised in the code review of 7152892 [1] that I believe this test doesn't need to be a shell test. I don't know if Rob has started looking into it (he missed my review comment when he pushed the fix). I wonder if you would like to take the opportunity to investigate if Assert.sh can be removed? Mandy [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/024995.html From jonathan.i.yu at gmail.com Tue Mar 4 12:05:56 2014 From: jonathan.i.yu at gmail.com (Jonathan Yu) Date: Tue, 4 Mar 2014 07:05:56 -0500 Subject: How to close a Process and having shutdown hooks called ? In-Reply-To: References: <6C970D250A1EFC45AF831AFA520141DFBAD025@mbxbr02> Message-ID: The referenced question discusses how to handle the *current* process receiving certain signals. The original question was how to portably send signals to *other* processes via the Process abstraction. The comment was that terminate process sends a kill 9 signal which cannot be caught by the target process, and a separate function was desired that would result in shutdown hooks being called. Cheers, Jonathan This message was sent from my mobile device. Please forgive my typographical errors and brevity. On Mar 4, 2014 6:52 AM, "Krystal Mok" wrote: > Hi Nicolas, > > Looks like a well discussed question. On Posix systems, SIGTERM should work > for you. That's the default signal sent by the 'kill' command on Linux. > e.g. please take a look here: > > http://stackoverflow.com/questions/2541597/how-to-gracefully-handle-the-sigkill-signal-in-java > > - Kris > > > On Tue, Mar 4, 2014 at 2:45 AM, LE PICARD NICOLAS > wrote: > > > Hello everyone ! > > > > I looked for the answer in this list and did not find anything relevant. > > > > I don't know it it's possible to close a Process et call shutdown hooks > > automatically. I looked into the code and found it was not possible (in > > jdk7). > > When we call destroy() on a Process, it will call terminateProcess of > > ProcessImpl class. > > This link shows that a TerminateProcess < kills > the process and WH_CBT > > hooks are NOT called. > > > > > http://msdn.microsoft.com/en-us/library/windows/desktop/ms686722(v=vs.85).aspx > > Calling exitProcess (instead of TeminateProcess) seems to be dangerous > ... > > but I don't understand why (ok, dlls could be locked, but when you do a > > CTRL +C it calls an exitProcess... so what's the problem ???) > > > > So I ask < how can we close a process, with the hooks called ? >. My > > knowledge is way smaller than people on openjdk... so I hope someone has > an > > answer or a workaround. > > > > Byte the way, I looked for sending signals (SIGINT for Windows, SIGKILL > > for linux etc) to close a process. > > Maybe I'm wrong, but a solution could be to add to ProcessImpl_md.c : > > > > #include > > > > > > > > JNIEXPORT jboolean JNICALL > > > > Java_java_lang_ProcessImpl_CloseHandleWithHooks(JNIEnv *env, jclass > > ignored, jlong handle) > > > > { > > > > raise(SIGINT) ; > > > > } > > > > I think,it will call an ExitProcess so ... dangerous or not ? > > Of course, we have to add also a function in ProcessImpl and make call > > available from Process through an abstract function like < close() > > > > > > > Any clever thoughts on this subject (I'm sure it is a common problem...) > ? > > Thanks :) > > > > > > Regards. > > > > Nicolas Le Picard > > > > > From brian.burkhalter at oracle.com Mon Mar 10 21:12:10 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 10 Mar 2014 14:12:10 -0700 Subject: JDK 9 RFC on 8029770: Improve user friendliness of preferences storage on Unix systems Message-ID: <0259BBAB-94C2-4735-B645-6305454E507F@oracle.com> This issue (https://bugs.openjdk.java.net/browse/JDK-8029770) concerns improving preference handling (java.util.prefs.Preferences) on systems other than Mac OS X and Windows, essentially Unix systems other than OS X. It would be good to obtain some comments on the behavior of the prospective changes including whether they are even necessary. For the moment, comments on the behavior are of more interest than those on any particular implementation. For background, on the Unix systems in question, the file system is used to store preferences in a tree with nodes mapping to directories. As node names can contain characters which may cause confusion when used verbatim in directory names, in those cases where such characters are detected, the directory name is derived from the node name by encoding the latter using a non-standard variant of the Base 64 Alphabet (Table 1 in [1]) which is immune to alphabetic character case folding. This can result in some strange and human unreadable directory names in the file system preferences tree. The objective here would be to change this scheme to something more user friendly. There are likely numerous approaches to solving this problem, but I think that first it needs to be determined whether interoperability with earlier Java versions is a requirement and, if so, what the nature of this requirement is. There are probably others, but there are at least the following alternatives (not all of which might be sensible): A) No interoperability: Java 9 and subsequent versions would not share preferences with earlier versions. B) Initialization only: Java 9 preferences would be initialized from the state of pre-9 preferences at the instant of first use. C) Unidirectional: Java 9 would detect changes made by earlier versions. D) Bidirectional: Java 9 and pre-9 preferences would be kept in sync. For options C and D note that only Java 9+ instances could effect this behavior. If for example Java 9 was not run for some time on a particular machine, the pre-9 preferences could significantly diverge from the 9 preferences. These would presumably be brought into sync when a Java 9+ instance next invoked the Preferences APIs. Whichever option were chosen, the changes made could include the definition of a system property which could be set to disable the new preferences handling variant, i.e., to force pre-9 file system preferences behavior. Any comments would be appreciated. Thanks, Brian [1] http://tools.ietf.org/rfc/rfc4648.txt From stevenschlansker at gmail.com Mon Mar 10 21:24:29 2014 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Mon, 10 Mar 2014 14:24:29 -0700 Subject: JDK 9 RFC on 8029770: Improve user friendliness of preferences storage on Unix systems In-Reply-To: <0259BBAB-94C2-4735-B645-6305454E507F@oracle.com> References: <0259BBAB-94C2-4735-B645-6305454E507F@oracle.com> Message-ID: On Mar 10, 2014, at 2:12 PM, Brian Burkhalter wrote: > > A) No interoperability: Java 9 and subsequent versions would not share preferences with earlier versions. > B) Initialization only: Java 9 preferences would be initialized from the state of pre-9 preferences at the instant of first use. > C) Unidirectional: Java 9 would detect changes made by earlier versions. > D) Bidirectional: Java 9 and pre-9 preferences would be kept in sync. > > For options C and D note that only Java 9+ instances could effect this behavior. If for example Java 9 was not run for some time on a particular machine, the pre-9 preferences could significantly diverge from the 9 preferences. These would presumably be brought into sync when a Java 9+ instance next invoked the Preferences APIs. If the scope of the change remains to naming only (leaving the file format the same), it may be possible to implement option D via linking - either hard links or symlinks - preserving bidirectional compatibility without the need for an explicit sync operation. From brian.burkhalter at oracle.com Mon Mar 10 21:34:11 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 10 Mar 2014 14:34:11 -0700 Subject: JDK 9 RFC on 8029770: Improve user friendliness of preferences storage on Unix systems In-Reply-To: References: <0259BBAB-94C2-4735-B645-6305454E507F@oracle.com> Message-ID: On Mar 10, 2014, at 2:24 PM, Steven Schlansker wrote: >> D) Bidirectional: Java 9 and pre-9 preferences would be kept in sync. > > If the scope of the change remains to naming only (leaving the file format the same), It is almost naming only; see below. > it may be possible to > implement option D via linking - either hard links or symlinks - preserving bidirectional compatibility > without the need for an explicit sync operation. Interesting possibility but I don't know that it would work. Consider the case where Java 9+ creates some preferences on a system where none existed before. As it does not want to create anything using the old encoding, then any subsequently run Java 8- instance will not detect the new preferences. Also, since Java 8- would not understand the newer encoding, the entries could not be stored in the same tree as this would cause an exception when a Java 8- instance attempted to read them. If I missed something altogether, please elaborate. Thanks, Brian From vladimir.x.ivanov at oracle.com Mon Mar 10 22:21:02 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 11 Mar 2014 02:21:02 +0400 Subject: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed) In-Reply-To: <9CEB01B8-D089-40DC-B63D-779A2994B6C9@oracle.com> References: <531630D8.7030402@oracle.com> <9CEB01B8-D089-40DC-B63D-779A2994B6C9@oracle.com> Message-ID: <531E3ACE.3060108@oracle.com> Chris, thanks for the review. John suggested an elegant way to fix the problem - use asFixedArity. Updated fix: http://cr.openjdk.java.net/~vlivanov/8036117/webrev.01/ Best regards, Vladimir Ivanov On 3/8/14 4:51 AM, Christian Thalinger wrote: > Seems good to me. I?d like to have another name for this method: > > + private static Object invokeCustom(MethodHandle target, Object... args) throws Throwable { > > On Mar 4, 2014, at 12:00 PM, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vlivanov/8036117/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8036117 >> 84 lines changed: 74 ins; 3 del; 7 mod >> >> I have to revert a cleanup I did for 8027827. >> MethodHandle.invokeWithArguments (and generic invocation) has unpleasant >> peculiarity in behavior when used with VarargsCollector. So, >> unfortunately, invokeWithArguments is not an option there. >> >> Looking at the API (excerpts from javadoc [1] [2]), the following >> condition doesn't hold in that case: >> "trailing parameter type of the caller is a reference type identical >> to or assignable to the trailing parameter type of the adapter". >> >> Example: >> target.invokeWithArguments((Object[])args) >> => >> target.invoke((Object)o1,(Object)o2,(Object)o3) >> =/> >> target.invokeExact((Object)o1, (Object)o2, (Object[])o3) >> >> because Object !<: Object[]. >> >> The fix is to skip unnecessary conversion when invoking a method handle >> and just do a pairwise type conversion. >> >> Testing: failing test case, nashorn w/ experimental features (octane) >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov >> >> [1] MethodHandle.invokeWithArguments >> "Performs a variable arity invocation, ..., as if via an inexact invoke >> from a call site which mentions only the type Object, and whose arity is >> the length of the argument array." >> >> [2] MethodHandle.asVarargsCollector >> "When called with plain, inexact invoke, if the caller type is the same >> as the adapter, the adapter invokes the target as with invokeExact. >> (This is the normal behavior for invoke when types match.) >> >> Otherwise, if the caller and adapter arity are the same, and the >> trailing parameter type of the caller is a reference type identical to >> or assignable to the trailing parameter type of the adapter, the >> arguments and return values are converted pairwise, as if by asType on a >> fixed arity method handle. >> >> Otherwise, the arities differ, or the adapter's trailing parameter type >> is not assignable from the corresponding caller type. In this case, the >> adapter replaces all trailing arguments from the original trailing >> argument position onward, by a new array of type arrayType, whose >> elements comprise (in order) the replaced arguments." >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From john.r.rose at oracle.com Mon Mar 10 22:27:06 2014 From: john.r.rose at oracle.com (John Rose) Date: Mon, 10 Mar 2014 15:27:06 -0700 Subject: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed) In-Reply-To: <531E3ACE.3060108@oracle.com> References: <531630D8.7030402@oracle.com> <9CEB01B8-D089-40DC-B63D-779A2994B6C9@oracle.com> <531E3ACE.3060108@oracle.com> Message-ID: <8903F8D3-7032-4C4F-AD6F-AECA6797CA5C@oracle.com> Reviewed. ? John > On Mar 10, 2014, at 3:21 PM, Vladimir Ivanov wrote: > > Chris, thanks for the review. > > John suggested an elegant way to fix the problem - use asFixedArity. > > Updated fix: > http://cr.openjdk.java.net/~vlivanov/8036117/webrev.01/ > > Best regards, > Vladimir Ivanov > >> On 3/8/14 4:51 AM, Christian Thalinger wrote: >> Seems good to me. I?d like to have another name for this method: >> >> + private static Object invokeCustom(MethodHandle target, Object... args) throws Throwable { >> >>> On Mar 4, 2014, at 12:00 PM, Vladimir Ivanov wrote: >>> >>> http://cr.openjdk.java.net/~vlivanov/8036117/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8036117 >>> 84 lines changed: 74 ins; 3 del; 7 mod >>> >>> I have to revert a cleanup I did for 8027827. >>> MethodHandle.invokeWithArguments (and generic invocation) has unpleasant >>> peculiarity in behavior when used with VarargsCollector. So, >>> unfortunately, invokeWithArguments is not an option there. >>> >>> Looking at the API (excerpts from javadoc [1] [2]), the following >>> condition doesn't hold in that case: >>> "trailing parameter type of the caller is a reference type identical >>> to or assignable to the trailing parameter type of the adapter". >>> >>> Example: >>> target.invokeWithArguments((Object[])args) >>> => >>> target.invoke((Object)o1,(Object)o2,(Object)o3) >>> =/> >>> target.invokeExact((Object)o1, (Object)o2, (Object[])o3) >>> >>> because Object !<: Object[]. >>> >>> The fix is to skip unnecessary conversion when invoking a method handle >>> and just do a pairwise type conversion. >>> >>> Testing: failing test case, nashorn w/ experimental features (octane) >>> >>> Thanks! >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] MethodHandle.invokeWithArguments >>> "Performs a variable arity invocation, ..., as if via an inexact invoke >>> from a call site which mentions only the type Object, and whose arity is >>> the length of the argument array." >>> >>> [2] MethodHandle.asVarargsCollector >>> "When called with plain, inexact invoke, if the caller type is the same >>> as the adapter, the adapter invokes the target as with invokeExact. >>> (This is the normal behavior for invoke when types match.) >>> >>> Otherwise, if the caller and adapter arity are the same, and the >>> trailing parameter type of the caller is a reference type identical to >>> or assignable to the trailing parameter type of the adapter, the >>> arguments and return values are converted pairwise, as if by asType on a >>> fixed arity method handle. >>> >>> Otherwise, the arities differ, or the adapter's trailing parameter type >>> is not assignable from the corresponding caller type. In this case, the >>> adapter replaces all trailing arguments from the original trailing >>> argument position onward, by a new array of type arrayType, whose >>> elements comprise (in order) the replaced arguments." >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From christian.thalinger at oracle.com Mon Mar 10 23:08:31 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 10 Mar 2014 16:08:31 -0700 Subject: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed) In-Reply-To: <531E3ACE.3060108@oracle.com> References: <531630D8.7030402@oracle.com> <9CEB01B8-D089-40DC-B63D-779A2994B6C9@oracle.com> <531E3ACE.3060108@oracle.com> Message-ID: <405A79C5-BC28-4C0B-91A9-5B1AED80F377@oracle.com> Even better. On Mar 10, 2014, at 3:21 PM, Vladimir Ivanov wrote: > Chris, thanks for the review. > > John suggested an elegant way to fix the problem - use asFixedArity. > > Updated fix: > http://cr.openjdk.java.net/~vlivanov/8036117/webrev.01/ > > Best regards, > Vladimir Ivanov > > On 3/8/14 4:51 AM, Christian Thalinger wrote: >> Seems good to me. I?d like to have another name for this method: >> >> + private static Object invokeCustom(MethodHandle target, Object... args) throws Throwable { >> >> On Mar 4, 2014, at 12:00 PM, Vladimir Ivanov wrote: >> >>> http://cr.openjdk.java.net/~vlivanov/8036117/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8036117 >>> 84 lines changed: 74 ins; 3 del; 7 mod >>> >>> I have to revert a cleanup I did for 8027827. >>> MethodHandle.invokeWithArguments (and generic invocation) has unpleasant >>> peculiarity in behavior when used with VarargsCollector. So, >>> unfortunately, invokeWithArguments is not an option there. >>> >>> Looking at the API (excerpts from javadoc [1] [2]), the following >>> condition doesn't hold in that case: >>> "trailing parameter type of the caller is a reference type identical >>> to or assignable to the trailing parameter type of the adapter". >>> >>> Example: >>> target.invokeWithArguments((Object[])args) >>> => >>> target.invoke((Object)o1,(Object)o2,(Object)o3) >>> =/> >>> target.invokeExact((Object)o1, (Object)o2, (Object[])o3) >>> >>> because Object !<: Object[]. >>> >>> The fix is to skip unnecessary conversion when invoking a method handle >>> and just do a pairwise type conversion. >>> >>> Testing: failing test case, nashorn w/ experimental features (octane) >>> >>> Thanks! >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] MethodHandle.invokeWithArguments >>> "Performs a variable arity invocation, ..., as if via an inexact invoke >>> from a call site which mentions only the type Object, and whose arity is >>> the length of the argument array." >>> >>> [2] MethodHandle.asVarargsCollector >>> "When called with plain, inexact invoke, if the caller type is the same >>> as the adapter, the adapter invokes the target as with invokeExact. >>> (This is the normal behavior for invoke when types match.) >>> >>> Otherwise, if the caller and adapter arity are the same, and the >>> trailing parameter type of the caller is a reference type identical to >>> or assignable to the trailing parameter type of the adapter, the >>> arguments and return values are converted pairwise, as if by asType on a >>> fixed arity method handle. >>> >>> Otherwise, the arities differ, or the adapter's trailing parameter type >>> is not assignable from the corresponding caller type. In this case, the >>> adapter replaces all trailing arguments from the original trailing >>> argument position onward, by a new array of type arrayType, whose >>> elements comprise (in order) the replaced arguments." >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> > _______________________________________________ > 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 Mar 10 23:12:34 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 11 Mar 2014 03:12:34 +0400 Subject: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed) In-Reply-To: <405A79C5-BC28-4C0B-91A9-5B1AED80F377@oracle.com> References: <531630D8.7030402@oracle.com> <9CEB01B8-D089-40DC-B63D-779A2994B6C9@oracle.com> <531E3ACE.3060108@oracle.com> <405A79C5-BC28-4C0B-91A9-5B1AED80F377@oracle.com> Message-ID: <531E46E2.7030107@oracle.com> John, Chris, thanks! Best regards, Vladimir Ivanov On 3/11/14 3:08 AM, Christian Thalinger wrote: > Even better. > > On Mar 10, 2014, at 3:21 PM, Vladimir Ivanov wrote: > >> Chris, thanks for the review. >> >> John suggested an elegant way to fix the problem - use asFixedArity. >> >> Updated fix: >> http://cr.openjdk.java.net/~vlivanov/8036117/webrev.01/ >> >> Best regards, >> Vladimir Ivanov >> >> On 3/8/14 4:51 AM, Christian Thalinger wrote: >>> Seems good to me. I?d like to have another name for this method: >>> >>> + private static Object invokeCustom(MethodHandle target, Object... args) throws Throwable { >>> >>> On Mar 4, 2014, at 12:00 PM, Vladimir Ivanov wrote: >>> >>>> http://cr.openjdk.java.net/~vlivanov/8036117/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8036117 >>>> 84 lines changed: 74 ins; 3 del; 7 mod >>>> >>>> I have to revert a cleanup I did for 8027827. >>>> MethodHandle.invokeWithArguments (and generic invocation) has unpleasant >>>> peculiarity in behavior when used with VarargsCollector. So, >>>> unfortunately, invokeWithArguments is not an option there. >>>> >>>> Looking at the API (excerpts from javadoc [1] [2]), the following >>>> condition doesn't hold in that case: >>>> "trailing parameter type of the caller is a reference type identical >>>> to or assignable to the trailing parameter type of the adapter". >>>> >>>> Example: >>>> target.invokeWithArguments((Object[])args) >>>> => >>>> target.invoke((Object)o1,(Object)o2,(Object)o3) >>>> =/> >>>> target.invokeExact((Object)o1, (Object)o2, (Object[])o3) >>>> >>>> because Object !<: Object[]. >>>> >>>> The fix is to skip unnecessary conversion when invoking a method handle >>>> and just do a pairwise type conversion. >>>> >>>> Testing: failing test case, nashorn w/ experimental features (octane) >>>> >>>> Thanks! >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> [1] MethodHandle.invokeWithArguments >>>> "Performs a variable arity invocation, ..., as if via an inexact invoke >>>> from a call site which mentions only the type Object, and whose arity is >>>> the length of the argument array." >>>> >>>> [2] MethodHandle.asVarargsCollector >>>> "When called with plain, inexact invoke, if the caller type is the same >>>> as the adapter, the adapter invokes the target as with invokeExact. >>>> (This is the normal behavior for invoke when types match.) >>>> >>>> Otherwise, if the caller and adapter arity are the same, and the >>>> trailing parameter type of the caller is a reference type identical to >>>> or assignable to the trailing parameter type of the adapter, the >>>> arguments and return values are converted pairwise, as if by asType on a >>>> fixed arity method handle. >>>> >>>> Otherwise, the arities differ, or the adapter's trailing parameter type >>>> is not assignable from the corresponding caller type. In this case, the >>>> adapter replaces all trailing arguments from the original trailing >>>> argument position onward, by a new array of type arrayType, whose >>>> elements comprise (in order) the replaced arguments." >>>> _______________________________________________ >>>> mlvm-dev mailing list >>>> mlvm-dev at openjdk.java.net >>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>> >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From mandy.chung at oracle.com Tue Mar 11 01:59:35 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 10 Mar 2014 18:59:35 -0700 Subject: RFR[9](XXS): 8037013: [TESTBUG] Fix test/java/lang/ClassLoader/Assert.sh on AIX In-Reply-To: <531E0A9E.50908@oracle.com> References: <531E0A9E.50908@oracle.com> Message-ID: <531E6E07.2000806@oracle.com> On 3/10/2014 11:55 AM, Mandy Chung wrote: > Hi Volker, > > On 3/10/14 11:16 AM, Volker Simonis wrote: >> Hi, >> >> could you please review the following trivial change which adds AIX to >> the list of known OSs in test/java/lang/ClassLoader/Assert.sh: >> >> https://bugs.openjdk.java.net/browse/JDK-8037013 >> http://cr.openjdk.java.net/~simonis/webrevs/8037013/ >> > > The link to your webrev is not accessible and could possibly due to > the server issue. I guess your fix is to add AIX in the Assert.sh > test. Can you paste the diff in mail? I can review it. > I am able to access the webrev now - looks good. > I raised in the code review of 7152892 [1] that I believe this test > doesn't need to be a shell test. I don't know if Rob has started > looking into it (he missed my review comment when he pushed the > fix). I wonder if you would like to take the opportunity to > investigate if Assert.sh can be removed? > It'd be even better if we could get rid of Assert.sh. thanks Mandy > Mandy > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/024995.html > From charlie.wang at oracle.com Tue Mar 11 05:13:41 2014 From: charlie.wang at oracle.com (Charlie Wang) Date: Tue, 11 Mar 2014 13:13:41 +0800 Subject: Charlie will take one day off this Friday Message-ID: <531E9B85.4080704@oracle.com> Hi, I will take one day off this Friday. Regards, Charlie From sergey.kuksenko at oracle.com Tue Mar 11 08:05:17 2014 From: sergey.kuksenko at oracle.com (Sergey Kuksenko) Date: Tue, 11 Mar 2014 12:05:17 +0400 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <5315EDAA.5020801@gmail.com> Message-ID: <531EC3BD.9050605@oracle.com> Brian, Mike. Could you explain what is the problem with the old caching? String is immutable, BigDecimal is immutable. So we have data race at that place, but it is safe data race. What is the problem if we create several identical strings? You are making stringCache volatile -> performance penalty on ARM & PPC. Setting cache via CAS -> performance penalty everywhere. If you insist to use AtomicFieldUpdater - the better way is to use lazySet, not CAS. On 03/04/2014 09:21 PM, Mike Duigou wrote: > > On Mar 4 2014, at 07:13 , Peter Levart wrote: > >> On 03/04/2014 01:14 AM, Brian Burkhalter wrote: >>> - add AtomicReferenceFieldUpdater-type constant for stringCache initialization >> >> Hi Brian, >> >> By using volatile read and CAS, there's still a chance that multiple concurrent threads will be invoking the layoutChars(true) concurrently, but you guarantee that only a single instance of String will ever be returned as a result of the toString() method. Is that what you were pursuing? > > Yes. (I provided the AtomicReferenceFieldUpdater code). The previous implementation had a benign data race that could result in a later layoutChars result replacing an earlier result and multiple string instances being returned. The new implementation, at small cost, prevents multiple different instances from being returned. > > Mike > -- Best regards, Sergey Kuksenko From sergey.kuksenko at oracle.com Tue Mar 11 08:18:07 2014 From: sergey.kuksenko at oracle.com (Sergey Kuksenko) Date: Tue, 11 Mar 2014 12:18:07 +0400 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> Message-ID: <531EC6BF.4050701@oracle.com> Brian, Could you share your benchmarks? On 03/04/2014 04:14 AM, Brian Burkhalter wrote: > Hello all, > > This review request concerns this issue and proposed patch: > > issue https://bugs.openjdk.java.net/browse/JDK-6375303 > patch http://cr.openjdk.java.net/~bpb/6375303/webrev.00/ > > A review of the current code did not reveal anything clearly amiss in the nature of the the problems which instigated the original filing of this issue. Examination of the code did however suggest some code style and aesthetic improvements as well as a change to how one lazy initialization was implemented (here we go again ...). > > Summary: > > - clean up imports section > - add AtomicReferenceFieldUpdater-type constant for stringCache initialization > - change some existing static final constants to conform to Java coding style > - change name of some local variables so as not to hide instance variables of the same name > - add missing @Override annotations > - modify lazy initialization of stringCache in toString() to use AtomicReferenceFieldUpdater constant > - various other minor cleanup > > Note that the performance of initialization of stringCache was measured for the extant double-checked locking approach, an AtomicReference, and the AtomicReferenceFieldUpdater and no significant degradation was observed for either of the latter versus the baseline for 1 and 4 threads. The updater has the advantage of adding only one object per class as opposed to one per instance. > > Thanks, > > Brian > -- Best regards, Sergey Kuksenko From volker.simonis at gmail.com Tue Mar 11 09:02:06 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 11 Mar 2014 10:02:06 +0100 Subject: JDK 9 RFC on 8029770: Improve user friendliness of preferences storage on Unix systems In-Reply-To: References: <0259BBAB-94C2-4735-B645-6305454E507F@oracle.com> Message-ID: Another problem with links would be that not all file systems support links. Regards, Volker On Mon, Mar 10, 2014 at 10:34 PM, Brian Burkhalter wrote: > > On Mar 10, 2014, at 2:24 PM, Steven Schlansker wrote: > >>> D) Bidirectional: Java 9 and pre-9 preferences would be kept in sync. >> >> If the scope of the change remains to naming only (leaving the file format the same), > > It is almost naming only; see below. > >> it may be possible to >> implement option D via linking - either hard links or symlinks - preserving bidirectional compatibility >> without the need for an explicit sync operation. > > Interesting possibility but I don't know that it would work. Consider the case where Java 9+ creates some preferences on a system where none existed before. As it does not want to create anything using the old encoding, then any subsequently run Java 8- instance will not detect the new preferences. Also, since Java 8- would not understand the newer encoding, the entries could not be stored in the same tree as this would cause an exception when a Java 8- instance attempted to read them. > > If I missed something altogether, please elaborate. > > Thanks, > > Brian From peter.levart at gmail.com Tue Mar 11 11:35:26 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 11 Mar 2014 12:35:26 +0100 Subject: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed) In-Reply-To: <531E46E2.7030107@oracle.com> References: <531630D8.7030402@oracle.com> <9CEB01B8-D089-40DC-B63D-779A2994B6C9@oracle.com> <531E3ACE.3060108@oracle.com> <405A79C5-BC28-4C0B-91A9-5B1AED80F377@oracle.com> <531E46E2.7030107@oracle.com> Message-ID: <531EF4FE.6040806@gmail.com> Hi, Excuse my ignorant question: What is the purpose of @LambdaForm.Hidden annotation? I suspect it has to do with hiding the call frames in stack traces that are part of LambdaForm invocation chain. In this case, method: private static Object[] prepend(Object elem, Object[] array) in MethodHandleImpl need not be annotated with this annotation, since it's call frame is not on stack when one of the target methods is executed. It's just a function used to calculate the argument of the call. In fact, if prepend() ever throws exception (NPE in case array is null?), It would be preferable that it's call frame is visible in the stack trace. Am I right or am I just talking nonsense? Regards, Peter On 03/11/2014 12:12 AM, Vladimir Ivanov wrote: > John, Chris, thanks! > > Best regards, > Vladimir Ivanov > > On 3/11/14 3:08 AM, Christian Thalinger wrote: >> Even better. >> >> On Mar 10, 2014, at 3:21 PM, Vladimir Ivanov >> wrote: >> >>> Chris, thanks for the review. >>> >>> John suggested an elegant way to fix the problem - use asFixedArity. >>> >>> Updated fix: >>> http://cr.openjdk.java.net/~vlivanov/8036117/webrev.01/ >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 3/8/14 4:51 AM, Christian Thalinger wrote: >>>> Seems good to me. I?d like to have another name for this method: >>>> >>>> + private static Object invokeCustom(MethodHandle target, >>>> Object... args) throws Throwable { >>>> >>>> On Mar 4, 2014, at 12:00 PM, Vladimir Ivanov >>>> wrote: >>>> >>>>> http://cr.openjdk.java.net/~vlivanov/8036117/webrev.00/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8036117 >>>>> 84 lines changed: 74 ins; 3 del; 7 mod >>>>> >>>>> I have to revert a cleanup I did for 8027827. >>>>> MethodHandle.invokeWithArguments (and generic invocation) has >>>>> unpleasant >>>>> peculiarity in behavior when used with VarargsCollector. So, >>>>> unfortunately, invokeWithArguments is not an option there. >>>>> >>>>> Looking at the API (excerpts from javadoc [1] [2]), the following >>>>> condition doesn't hold in that case: >>>>> "trailing parameter type of the caller is a reference type >>>>> identical >>>>> to or assignable to the trailing parameter type of the adapter". >>>>> >>>>> Example: >>>>> target.invokeWithArguments((Object[])args) >>>>> => >>>>> target.invoke((Object)o1,(Object)o2,(Object)o3) >>>>> =/> >>>>> target.invokeExact((Object)o1, (Object)o2, (Object[])o3) >>>>> >>>>> because Object !<: Object[]. >>>>> >>>>> The fix is to skip unnecessary conversion when invoking a method >>>>> handle >>>>> and just do a pairwise type conversion. >>>>> >>>>> Testing: failing test case, nashorn w/ experimental features (octane) >>>>> >>>>> Thanks! >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> [1] MethodHandle.invokeWithArguments >>>>> "Performs a variable arity invocation, ..., as if via an inexact >>>>> invoke >>>>> from a call site which mentions only the type Object, and whose >>>>> arity is >>>>> the length of the argument array." >>>>> >>>>> [2] MethodHandle.asVarargsCollector >>>>> "When called with plain, inexact invoke, if the caller type is the >>>>> same >>>>> as the adapter, the adapter invokes the target as with invokeExact. >>>>> (This is the normal behavior for invoke when types match.) >>>>> >>>>> Otherwise, if the caller and adapter arity are the same, and the >>>>> trailing parameter type of the caller is a reference type >>>>> identical to >>>>> or assignable to the trailing parameter type of the adapter, the >>>>> arguments and return values are converted pairwise, as if by >>>>> asType on a >>>>> fixed arity method handle. >>>>> >>>>> Otherwise, the arities differ, or the adapter's trailing parameter >>>>> type >>>>> is not assignable from the corresponding caller type. In this >>>>> case, the >>>>> adapter replaces all trailing arguments from the original trailing >>>>> argument position onward, by a new array of type arrayType, whose >>>>> elements comprise (in order) the replaced arguments." >>>>> _______________________________________________ >>>>> mlvm-dev mailing list >>>>> mlvm-dev at openjdk.java.net >>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>> >>>> _______________________________________________ >>>> mlvm-dev mailing list >>>> mlvm-dev at openjdk.java.net >>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>> >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> > _______________________________________________ > 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 Tue Mar 11 11:59:12 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 11 Mar 2014 15:59:12 +0400 Subject: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed) In-Reply-To: <531EF4FE.6040806@gmail.com> References: <531630D8.7030402@oracle.com> <9CEB01B8-D089-40DC-B63D-779A2994B6C9@oracle.com> <531E3ACE.3060108@oracle.com> <405A79C5-BC28-4C0B-91A9-5B1AED80F377@oracle.com> <531E46E2.7030107@oracle.com> <531EF4FE.6040806@gmail.com> Message-ID: <531EFA90.5070608@oracle.com> Peter, You raised totally valid question. I marked MethodHandleImpl.prepend with @Hidden annotation because it is internal implementation detail of JSR292. You are right that normally a callee can't see it on stack. But it's possible to observe it when stack trace is queried from a separate thread. There's not much value in it in this particular case, but I decided to reduce possible noise. Best regards, Vladimir Ivanov On 3/11/14 3:35 PM, Peter Levart wrote: > Hi, > > Excuse my ignorant question: What is the purpose of @LambdaForm.Hidden > annotation? > > I suspect it has to do with hiding the call frames in stack traces that > are part of LambdaForm invocation chain. In this case, method: > > private static Object[] prepend(Object elem, Object[] array) > > in MethodHandleImpl need not be annotated with this annotation, since > it's call frame is not on stack when one of the target methods is > executed. It's just a function used to calculate the argument of the > call. In fact, if prepend() ever throws exception (NPE in case array is > null?), It would be preferable that it's call frame is visible in the > stack trace. > > Am I right or am I just talking nonsense? > > Regards, Peter > > > On 03/11/2014 12:12 AM, Vladimir Ivanov wrote: >> John, Chris, thanks! >> >> Best regards, >> Vladimir Ivanov >> >> On 3/11/14 3:08 AM, Christian Thalinger wrote: >>> Even better. >>> >>> On Mar 10, 2014, at 3:21 PM, Vladimir Ivanov >>> wrote: >>> >>>> Chris, thanks for the review. >>>> >>>> John suggested an elegant way to fix the problem - use asFixedArity. >>>> >>>> Updated fix: >>>> http://cr.openjdk.java.net/~vlivanov/8036117/webrev.01/ >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 3/8/14 4:51 AM, Christian Thalinger wrote: >>>>> Seems good to me. I?d like to have another name for this method: >>>>> >>>>> + private static Object invokeCustom(MethodHandle target, >>>>> Object... args) throws Throwable { >>>>> >>>>> On Mar 4, 2014, at 12:00 PM, Vladimir Ivanov >>>>> wrote: >>>>> >>>>>> http://cr.openjdk.java.net/~vlivanov/8036117/webrev.00/ >>>>>> https://bugs.openjdk.java.net/browse/JDK-8036117 >>>>>> 84 lines changed: 74 ins; 3 del; 7 mod >>>>>> >>>>>> I have to revert a cleanup I did for 8027827. >>>>>> MethodHandle.invokeWithArguments (and generic invocation) has >>>>>> unpleasant >>>>>> peculiarity in behavior when used with VarargsCollector. So, >>>>>> unfortunately, invokeWithArguments is not an option there. >>>>>> >>>>>> Looking at the API (excerpts from javadoc [1] [2]), the following >>>>>> condition doesn't hold in that case: >>>>>> "trailing parameter type of the caller is a reference type >>>>>> identical >>>>>> to or assignable to the trailing parameter type of the adapter". >>>>>> >>>>>> Example: >>>>>> target.invokeWithArguments((Object[])args) >>>>>> => >>>>>> target.invoke((Object)o1,(Object)o2,(Object)o3) >>>>>> =/> >>>>>> target.invokeExact((Object)o1, (Object)o2, (Object[])o3) >>>>>> >>>>>> because Object !<: Object[]. >>>>>> >>>>>> The fix is to skip unnecessary conversion when invoking a method >>>>>> handle >>>>>> and just do a pairwise type conversion. >>>>>> >>>>>> Testing: failing test case, nashorn w/ experimental features (octane) >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>> [1] MethodHandle.invokeWithArguments >>>>>> "Performs a variable arity invocation, ..., as if via an inexact >>>>>> invoke >>>>>> from a call site which mentions only the type Object, and whose >>>>>> arity is >>>>>> the length of the argument array." >>>>>> >>>>>> [2] MethodHandle.asVarargsCollector >>>>>> "When called with plain, inexact invoke, if the caller type is the >>>>>> same >>>>>> as the adapter, the adapter invokes the target as with invokeExact. >>>>>> (This is the normal behavior for invoke when types match.) >>>>>> >>>>>> Otherwise, if the caller and adapter arity are the same, and the >>>>>> trailing parameter type of the caller is a reference type >>>>>> identical to >>>>>> or assignable to the trailing parameter type of the adapter, the >>>>>> arguments and return values are converted pairwise, as if by >>>>>> asType on a >>>>>> fixed arity method handle. >>>>>> >>>>>> Otherwise, the arities differ, or the adapter's trailing parameter >>>>>> type >>>>>> is not assignable from the corresponding caller type. In this >>>>>> case, the >>>>>> adapter replaces all trailing arguments from the original trailing >>>>>> argument position onward, by a new array of type arrayType, whose >>>>>> elements comprise (in order) the replaced arguments." >>>>>> _______________________________________________ >>>>>> mlvm-dev mailing list >>>>>> mlvm-dev at openjdk.java.net >>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>> >>>>> _______________________________________________ >>>>> mlvm-dev mailing list >>>>> mlvm-dev at openjdk.java.net >>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>> >>>> _______________________________________________ >>>> mlvm-dev mailing list >>>> mlvm-dev at openjdk.java.net >>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>> >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > _______________________________________________ > 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 Tue Mar 11 12:09:10 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 11 Mar 2014 13:09:10 +0100 Subject: JDK 9 RFC on 8029770: Improve user friendliness of preferences storage on Unix systems In-Reply-To: <0259BBAB-94C2-4735-B645-6305454E507F@oracle.com> References: <0259BBAB-94C2-4735-B645-6305454E507F@oracle.com> Message-ID: <531EFCE6.9060701@gmail.com> On 03/10/2014 10:12 PM, Brian Burkhalter wrote: > This issue (https://bugs.openjdk.java.net/browse/JDK-8029770) concerns improving preference handling (java.util.prefs.Preferences) on systems other than Mac OS X and Windows, essentially Unix systems other than OS X. It would be good to obtain some comments on the behavior of the prospective changes including whether they are even necessary. For the moment, comments on the behavior are of more interest than those on any particular implementation. > > For background, on the Unix systems in question, the file system is used to store preferences in a tree with nodes mapping to directories. As node names can contain characters which may cause confusion when used verbatim in directory names, in those cases where such characters are detected, the directory name is derived from the node name by encoding the latter using a non-standard variant of the Base 64 Alphabet (Table 1 in [1]) which is immune to alphabetic character case folding. This can result in some strange and human unreadable directory names in the file system preferences tree. The objective here would be to change this scheme to something more user friendly. > > There are likely numerous approaches to solving this problem, but I think that first it needs to be determined whether interoperability with earlier Java versions is a requirement and, if so, what the nature of this requirement is. There are probably others, but there are at least the following alternatives (not all of which might be sensible): > > A) No interoperability: Java 9 and subsequent versions would not share preferences with earlier versions. > B) Initialization only: Java 9 preferences would be initialized from the state of pre-9 preferences at the instant of first use. > C) Unidirectional: Java 9 would detect changes made by earlier versions. > D) Bidirectional: Java 9 and pre-9 preferences would be kept in sync. > > For options C and D note that only Java 9+ instances could effect this behavior. If for example Java 9 was not run for some time on a particular machine, the pre-9 preferences could significantly diverge from the 9 preferences. These would presumably be brought into sync when a Java 9+ instance next invoked the Preferences APIs. > > Whichever option were chosen, the changes made could include the definition of a system property which could be set to disable the new preferences handling variant, i.e., to force pre-9 file system preferences behavior. > > Any comments would be appreciated. > > Thanks, > > Brian > > [1] http://tools.ietf.org/rfc/rfc4648.txt Hi Brian, What is the purpose of changing the scheme? Is it just to be more power-user and developer friendly? To enable users to inspect the preferences with filesystem tools? What about a little command-line and/or gui "jprefs" tool in the style of regedit or gconftool or similar? Would that be enough to satisfy the goal? Any of the options A...D seem a compatibility nightmare for majority of programs that use preferences. Most users don't ever inspect directories starting with dot '.', so this feature is more or less targeted at developers, right? A tool that is standard part of JRE distribution could do the job of browsing (and perhaps changing of) the preferences without compatibility concerns... Regards, Peter From peter.levart at gmail.com Tue Mar 11 12:13:47 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 11 Mar 2014 13:13:47 +0100 Subject: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed) In-Reply-To: <531EFA90.5070608@oracle.com> References: <531630D8.7030402@oracle.com> <9CEB01B8-D089-40DC-B63D-779A2994B6C9@oracle.com> <531E3ACE.3060108@oracle.com> <405A79C5-BC28-4C0B-91A9-5B1AED80F377@oracle.com> <531E46E2.7030107@oracle.com> <531EF4FE.6040806@gmail.com> <531EFA90.5070608@oracle.com> Message-ID: <531EFDFB.8020908@gmail.com> On 03/11/2014 12:59 PM, Vladimir Ivanov wrote: > Peter, > > You raised totally valid question. > > I marked MethodHandleImpl.prepend with @Hidden annotation because it > is internal implementation detail of JSR292. > > You are right that normally a callee can't see it on stack. *But it's > possible to observe it when stack trace is queried from a separate > thread. * Is this good or bad? It enables tools to see it (for example sampling profilers, etc...). Regards, Peter > > There's not much value in it in this particular case, but I decided to > reduce possible noise. > > Best regards, > Vladimir Ivanov > > On 3/11/14 3:35 PM, Peter Levart wrote: >> Hi, >> >> Excuse my ignorant question: What is the purpose of @LambdaForm.Hidden >> annotation? >> >> I suspect it has to do with hiding the call frames in stack traces that >> are part of LambdaForm invocation chain. In this case, method: >> >> private static Object[] prepend(Object elem, Object[] array) >> >> in MethodHandleImpl need not be annotated with this annotation, since >> it's call frame is not on stack when one of the target methods is >> executed. It's just a function used to calculate the argument of the >> call. In fact, if prepend() ever throws exception (NPE in case array is >> null?), It would be preferable that it's call frame is visible in the >> stack trace. >> >> Am I right or am I just talking nonsense? >> >> Regards, Peter >> >> >> On 03/11/2014 12:12 AM, Vladimir Ivanov wrote: >>> John, Chris, thanks! >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 3/11/14 3:08 AM, Christian Thalinger wrote: >>>> Even better. >>>> >>>> On Mar 10, 2014, at 3:21 PM, Vladimir Ivanov >>>> wrote: >>>> >>>>> Chris, thanks for the review. >>>>> >>>>> John suggested an elegant way to fix the problem - use asFixedArity. >>>>> >>>>> Updated fix: >>>>> http://cr.openjdk.java.net/~vlivanov/8036117/webrev.01/ >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> On 3/8/14 4:51 AM, Christian Thalinger wrote: >>>>>> Seems good to me. I?d like to have another name for this method: >>>>>> >>>>>> + private static Object invokeCustom(MethodHandle target, >>>>>> Object... args) throws Throwable { >>>>>> >>>>>> On Mar 4, 2014, at 12:00 PM, Vladimir Ivanov >>>>>> wrote: >>>>>> >>>>>>> http://cr.openjdk.java.net/~vlivanov/8036117/webrev.00/ >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8036117 >>>>>>> 84 lines changed: 74 ins; 3 del; 7 mod >>>>>>> >>>>>>> I have to revert a cleanup I did for 8027827. >>>>>>> MethodHandle.invokeWithArguments (and generic invocation) has >>>>>>> unpleasant >>>>>>> peculiarity in behavior when used with VarargsCollector. So, >>>>>>> unfortunately, invokeWithArguments is not an option there. >>>>>>> >>>>>>> Looking at the API (excerpts from javadoc [1] [2]), the following >>>>>>> condition doesn't hold in that case: >>>>>>> "trailing parameter type of the caller is a reference type >>>>>>> identical >>>>>>> to or assignable to the trailing parameter type of the adapter". >>>>>>> >>>>>>> Example: >>>>>>> target.invokeWithArguments((Object[])args) >>>>>>> => >>>>>>> target.invoke((Object)o1,(Object)o2,(Object)o3) >>>>>>> =/> >>>>>>> target.invokeExact((Object)o1, (Object)o2, (Object[])o3) >>>>>>> >>>>>>> because Object !<: Object[]. >>>>>>> >>>>>>> The fix is to skip unnecessary conversion when invoking a method >>>>>>> handle >>>>>>> and just do a pairwise type conversion. >>>>>>> >>>>>>> Testing: failing test case, nashorn w/ experimental features >>>>>>> (octane) >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> Best regards, >>>>>>> Vladimir Ivanov >>>>>>> >>>>>>> [1] MethodHandle.invokeWithArguments >>>>>>> "Performs a variable arity invocation, ..., as if via an inexact >>>>>>> invoke >>>>>>> from a call site which mentions only the type Object, and whose >>>>>>> arity is >>>>>>> the length of the argument array." >>>>>>> >>>>>>> [2] MethodHandle.asVarargsCollector >>>>>>> "When called with plain, inexact invoke, if the caller type is the >>>>>>> same >>>>>>> as the adapter, the adapter invokes the target as with invokeExact. >>>>>>> (This is the normal behavior for invoke when types match.) >>>>>>> >>>>>>> Otherwise, if the caller and adapter arity are the same, and the >>>>>>> trailing parameter type of the caller is a reference type >>>>>>> identical to >>>>>>> or assignable to the trailing parameter type of the adapter, the >>>>>>> arguments and return values are converted pairwise, as if by >>>>>>> asType on a >>>>>>> fixed arity method handle. >>>>>>> >>>>>>> Otherwise, the arities differ, or the adapter's trailing parameter >>>>>>> type >>>>>>> is not assignable from the corresponding caller type. In this >>>>>>> case, the >>>>>>> adapter replaces all trailing arguments from the original trailing >>>>>>> argument position onward, by a new array of type arrayType, whose >>>>>>> elements comprise (in order) the replaced arguments." >>>>>>> _______________________________________________ >>>>>>> mlvm-dev mailing list >>>>>>> mlvm-dev at openjdk.java.net >>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>>> >>>>>> _______________________________________________ >>>>>> mlvm-dev mailing list >>>>>> mlvm-dev at openjdk.java.net >>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>>> >>>>> _______________________________________________ >>>>> mlvm-dev mailing list >>>>> mlvm-dev at openjdk.java.net >>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>> >>>> _______________________________________________ >>>> mlvm-dev mailing list >>>> mlvm-dev at openjdk.java.net >>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>> >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From ivan.gerasimov at oracle.com Tue Mar 11 12:24:36 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 11 Mar 2014 16:24:36 +0400 Subject: RFR [8034262] Test java/lang/ProcessBuilder/CloseRace.java fails Message-ID: <531F0084.80703@oracle.com> Hello everybody! The test java/lang/ProcessBuilder/CloseRace.java was reported to intermittently fail. The test timed out, which should mean that at least one of the child threads was never interrupted. I couldn't reproduce the failure, but I suspect it might happen due to call to interrupt() before the child thread became alive (I'm not really sure if it's possible to be non-alive after call to start()). The fix is to explicitly synchronize children with the parent. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8034262 WEBREV: http://cr.openjdk.java.net/~igerasim/8034262/0/webrev/ Sincerely yours, Ivan From Alan.Bateman at oracle.com Tue Mar 11 13:22:24 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 11 Mar 2014 13:22:24 +0000 Subject: JDK 9 RFC on 8029770: Improve user friendliness of preferences storage on Unix systems In-Reply-To: <531EFCE6.9060701@gmail.com> References: <0259BBAB-94C2-4735-B645-6305454E507F@oracle.com> <531EFCE6.9060701@gmail.com> Message-ID: <531F0E10.7080705@oracle.com> On 11/03/2014 12:09, Peter Levart wrote: > : > > What is the purpose of changing the scheme? Is it just to be more > power-user and developer friendly? To enable users to inspect the > preferences with filesystem tools? What about a little command-line > and/or gui "jprefs" tool in the style of regedit or gconftool or > similar? Would that be enough to satisfy the goal? Any of the options > A...D seem a compatibility nightmare for majority of programs that use > preferences. Most users don't ever inspect directories starting with > dot '.', so this feature is more or less targeted at developers, > right? A tool that is standard part of JRE distribution could do the > job of browsing (and perhaps changing of) the preferences without > compatibility concerns... This is mostly about complaints from those with scripts that are forced to deal with special characters in the file name. I don't think the preferences API is used very much so it might not be worth doing anything. If it does change and it might need a tool to migrate existing preferences, all depends on the approach. -Alan From vladimir.x.ivanov at oracle.com Tue Mar 11 14:05:31 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 11 Mar 2014 18:05:31 +0400 Subject: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed) In-Reply-To: <531EFDFB.8020908@gmail.com> References: <531630D8.7030402@oracle.com> <9CEB01B8-D089-40DC-B63D-779A2994B6C9@oracle.com> <531E3ACE.3060108@oracle.com> <405A79C5-BC28-4C0B-91A9-5B1AED80F377@oracle.com> <531E46E2.7030107@oracle.com> <531EF4FE.6040806@gmail.com> <531EFA90.5070608@oracle.com> <531EFDFB.8020908@gmail.com> Message-ID: <531F182B.8000908@oracle.com> >> You raised totally valid question. >> >> I marked MethodHandleImpl.prepend with @Hidden annotation because it >> is internal implementation detail of JSR292. >> >> You are right that normally a callee can't see it on stack. *But it's >> possible to observe it when stack trace is queried from a separate >> thread. * > > Is this good or bad? It enables tools to see it (for example sampling > profilers, etc...). For the purposes of sampling profilers (and other monitoring tools) @Hidden should be completely ignored. These tools should use appropriate API to get the data. I looked into the code and @Hidden has even less effect than I thought initially. It affects very limited set of cases - only users of JVM_FillInStackTrace (when filling exception's stack trace, Thread.dumpStack()). Calls to Thread.getStackTrace() from a separate thread omit stack trace filtering. Best regards, Vladimir Ivanov > Regards, Peter > >> >> There's not much value in it in this particular case, but I decided to >> reduce possible noise. >> >> Best regards, >> Vladimir Ivanov >> >> On 3/11/14 3:35 PM, Peter Levart wrote: >>> Hi, >>> >>> Excuse my ignorant question: What is the purpose of @LambdaForm.Hidden >>> annotation? >>> >>> I suspect it has to do with hiding the call frames in stack traces that >>> are part of LambdaForm invocation chain. In this case, method: >>> >>> private static Object[] prepend(Object elem, Object[] array) >>> >>> in MethodHandleImpl need not be annotated with this annotation, since >>> it's call frame is not on stack when one of the target methods is >>> executed. It's just a function used to calculate the argument of the >>> call. In fact, if prepend() ever throws exception (NPE in case array is >>> null?), It would be preferable that it's call frame is visible in the >>> stack trace. >>> >>> Am I right or am I just talking nonsense? >>> >>> Regards, Peter >>> >>> >>> On 03/11/2014 12:12 AM, Vladimir Ivanov wrote: >>>> John, Chris, thanks! >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 3/11/14 3:08 AM, Christian Thalinger wrote: >>>>> Even better. >>>>> >>>>> On Mar 10, 2014, at 3:21 PM, Vladimir Ivanov >>>>> wrote: >>>>> >>>>>> Chris, thanks for the review. >>>>>> >>>>>> John suggested an elegant way to fix the problem - use asFixedArity. >>>>>> >>>>>> Updated fix: >>>>>> http://cr.openjdk.java.net/~vlivanov/8036117/webrev.01/ >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>> On 3/8/14 4:51 AM, Christian Thalinger wrote: >>>>>>> Seems good to me. I?d like to have another name for this method: >>>>>>> >>>>>>> + private static Object invokeCustom(MethodHandle target, >>>>>>> Object... args) throws Throwable { >>>>>>> >>>>>>> On Mar 4, 2014, at 12:00 PM, Vladimir Ivanov >>>>>>> wrote: >>>>>>> >>>>>>>> http://cr.openjdk.java.net/~vlivanov/8036117/webrev.00/ >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8036117 >>>>>>>> 84 lines changed: 74 ins; 3 del; 7 mod >>>>>>>> >>>>>>>> I have to revert a cleanup I did for 8027827. >>>>>>>> MethodHandle.invokeWithArguments (and generic invocation) has >>>>>>>> unpleasant >>>>>>>> peculiarity in behavior when used with VarargsCollector. So, >>>>>>>> unfortunately, invokeWithArguments is not an option there. >>>>>>>> >>>>>>>> Looking at the API (excerpts from javadoc [1] [2]), the following >>>>>>>> condition doesn't hold in that case: >>>>>>>> "trailing parameter type of the caller is a reference type >>>>>>>> identical >>>>>>>> to or assignable to the trailing parameter type of the adapter". >>>>>>>> >>>>>>>> Example: >>>>>>>> target.invokeWithArguments((Object[])args) >>>>>>>> => >>>>>>>> target.invoke((Object)o1,(Object)o2,(Object)o3) >>>>>>>> =/> >>>>>>>> target.invokeExact((Object)o1, (Object)o2, (Object[])o3) >>>>>>>> >>>>>>>> because Object !<: Object[]. >>>>>>>> >>>>>>>> The fix is to skip unnecessary conversion when invoking a method >>>>>>>> handle >>>>>>>> and just do a pairwise type conversion. >>>>>>>> >>>>>>>> Testing: failing test case, nashorn w/ experimental features >>>>>>>> (octane) >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir Ivanov >>>>>>>> >>>>>>>> [1] MethodHandle.invokeWithArguments >>>>>>>> "Performs a variable arity invocation, ..., as if via an inexact >>>>>>>> invoke >>>>>>>> from a call site which mentions only the type Object, and whose >>>>>>>> arity is >>>>>>>> the length of the argument array." >>>>>>>> >>>>>>>> [2] MethodHandle.asVarargsCollector >>>>>>>> "When called with plain, inexact invoke, if the caller type is the >>>>>>>> same >>>>>>>> as the adapter, the adapter invokes the target as with invokeExact. >>>>>>>> (This is the normal behavior for invoke when types match.) >>>>>>>> >>>>>>>> Otherwise, if the caller and adapter arity are the same, and the >>>>>>>> trailing parameter type of the caller is a reference type >>>>>>>> identical to >>>>>>>> or assignable to the trailing parameter type of the adapter, the >>>>>>>> arguments and return values are converted pairwise, as if by >>>>>>>> asType on a >>>>>>>> fixed arity method handle. >>>>>>>> >>>>>>>> Otherwise, the arities differ, or the adapter's trailing parameter >>>>>>>> type >>>>>>>> is not assignable from the corresponding caller type. In this >>>>>>>> case, the >>>>>>>> adapter replaces all trailing arguments from the original trailing >>>>>>>> argument position onward, by a new array of type arrayType, whose >>>>>>>> elements comprise (in order) the replaced arguments." >>>>>>>> _______________________________________________ >>>>>>>> mlvm-dev mailing list >>>>>>>> mlvm-dev at openjdk.java.net >>>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>>>> >>>>>>> _______________________________________________ >>>>>>> mlvm-dev mailing list >>>>>>> mlvm-dev at openjdk.java.net >>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>>>> >>>>>> _______________________________________________ >>>>>> mlvm-dev mailing list >>>>>> mlvm-dev at openjdk.java.net >>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>> >>>>> _______________________________________________ >>>>> mlvm-dev mailing list >>>>> mlvm-dev at openjdk.java.net >>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>> >>>> _______________________________________________ >>>> mlvm-dev mailing list >>>> mlvm-dev at openjdk.java.net >>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>> >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From pbenedict at apache.org Tue Mar 11 14:23:20 2014 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 11 Mar 2014 09:23:20 -0500 Subject: JDK 9 RFC on 8029770: Improve user friendliness of preferences storage on Unix systems In-Reply-To: <531F0E10.7080705@oracle.com> References: <0259BBAB-94C2-4735-B645-6305454E507F@oracle.com> <531EFCE6.9060701@gmail.com> <531F0E10.7080705@oracle.com> Message-ID: What about providing a shell script with JDK 9 with functions to encode names? Users can then just "source" the file into their scripts and helper functions available to them. Hopefully this would alleviate dealing with special characters. On Tue, Mar 11, 2014 at 8:22 AM, Alan Bateman wrote: > On 11/03/2014 12:09, Peter Levart wrote: > >> : >> >> What is the purpose of changing the scheme? Is it just to be more >> power-user and developer friendly? To enable users to inspect the >> preferences with filesystem tools? What about a little command-line and/or >> gui "jprefs" tool in the style of regedit or gconftool or similar? Would >> that be enough to satisfy the goal? Any of the options A...D seem a >> compatibility nightmare for majority of programs that use preferences. Most >> users don't ever inspect directories starting with dot '.', so this feature >> is more or less targeted at developers, right? A tool that is standard part >> of JRE distribution could do the job of browsing (and perhaps changing of) >> the preferences without compatibility concerns... >> > This is mostly about complaints from those with scripts that are forced to > deal with special characters in the file name. I don't think the > preferences API is used very much so it might not be worth doing anything. > If it does change and it might need a tool to migrate existing preferences, > all depends on the approach. > > -Alan > -- Cheers, Paul From martinrb at google.com Tue Mar 11 15:04:34 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 11 Mar 2014 08:04:34 -0700 Subject: RFR [8034262] Test java/lang/ProcessBuilder/CloseRace.java fails In-Reply-To: <531F0084.80703@oracle.com> References: <531F0084.80703@oracle.com> Message-ID: Thanks for working on my brittle racy tests. Adding a latch as you did is a good improvement, although there's a good chance the real problem lies elsewhere. My standard name for such latches is "threadsStarted", which I think is a bit better than "startedSignal". Please rename. My simple calls to Thread.join are too optimistic. More likely to be helpful is code like (pseudocode follows): thread.join(10, SECONDS); if (thread.isAlive()) { dumpAllStacks(); fail(); } That's more work to implement - optional. On Tue, Mar 11, 2014 at 5:24 AM, Ivan Gerasimov wrote: > Hello everybody! > > The test java/lang/ProcessBuilder/CloseRace.java was reported to > intermittently fail. > The test timed out, which should mean that at least one of the child > threads was never interrupted. > > I couldn't reproduce the failure, but I suspect it might happen due to > call to interrupt() before the child thread became alive (I'm not really > sure if it's possible to be non-alive after call to start()). > The fix is to explicitly synchronize children with the parent. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8034262 > WEBREV: http://cr.openjdk.java.net/~igerasim/8034262/0/webrev/ > > Sincerely yours, > Ivan > From peter.levart at gmail.com Tue Mar 11 16:09:33 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 11 Mar 2014 17:09:33 +0100 Subject: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed) In-Reply-To: <531F182B.8000908@oracle.com> References: <531630D8.7030402@oracle.com> <9CEB01B8-D089-40DC-B63D-779A2994B6C9@oracle.com> <531E3ACE.3060108@oracle.com> <405A79C5-BC28-4C0B-91A9-5B1AED80F377@oracle.com> <531E46E2.7030107@oracle.com> <531EF4FE.6040806@gmail.com> <531EFA90.5070608@oracle.com> <531EFDFB.8020908@gmail.com> <531F182B.8000908@oracle.com> Message-ID: <531F353D.6000309@gmail.com> On 03/11/2014 03:05 PM, Vladimir Ivanov wrote: >>> You raised totally valid question. >>> >>> I marked MethodHandleImpl.prepend with @Hidden annotation because it >>> is internal implementation detail of JSR292. >>> >>> You are right that normally a callee can't see it on stack. *But it's >>> possible to observe it when stack trace is queried from a separate >>> thread. * >> >> Is this good or bad? It enables tools to see it (for example sampling >> profilers, etc...). > For the purposes of sampling profilers (and other monitoring tools) > @Hidden should be completely ignored. These tools should use > appropriate API to get the data. > > I looked into the code and @Hidden has even less effect than I thought > initially. It affects very limited set of cases - only users of > JVM_FillInStackTrace (when filling exception's stack trace, > Thread.dumpStack()). Calls to Thread.getStackTrace() from a separate > thread omit stack trace filtering. So all you're achieving by annotating prepend() method is that any exception stack trace, in case it is thrown inside the prepend() method, will hide where it was thrown from. In case all LambdaForm frames leading to the prepend() method were also hidden, the exception would appear to be thrown from the invocation of the MH... Regards, Peter > > Best regards, > Vladimir Ivanov > >> Regards, Peter >> >>> >>> There's not much value in it in this particular case, but I decided to >>> reduce possible noise. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 3/11/14 3:35 PM, Peter Levart wrote: >>>> Hi, >>>> >>>> Excuse my ignorant question: What is the purpose of @LambdaForm.Hidden >>>> annotation? >>>> >>>> I suspect it has to do with hiding the call frames in stack traces >>>> that >>>> are part of LambdaForm invocation chain. In this case, method: >>>> >>>> private static Object[] prepend(Object elem, Object[] array) >>>> >>>> in MethodHandleImpl need not be annotated with this annotation, since >>>> it's call frame is not on stack when one of the target methods is >>>> executed. It's just a function used to calculate the argument of the >>>> call. In fact, if prepend() ever throws exception (NPE in case >>>> array is >>>> null?), It would be preferable that it's call frame is visible in the >>>> stack trace. >>>> >>>> Am I right or am I just talking nonsense? >>>> >>>> Regards, Peter >>>> >>>> >>>> On 03/11/2014 12:12 AM, Vladimir Ivanov wrote: >>>>> John, Chris, thanks! >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> On 3/11/14 3:08 AM, Christian Thalinger wrote: >>>>>> Even better. >>>>>> >>>>>> On Mar 10, 2014, at 3:21 PM, Vladimir Ivanov >>>>>> wrote: >>>>>> >>>>>>> Chris, thanks for the review. >>>>>>> >>>>>>> John suggested an elegant way to fix the problem - use >>>>>>> asFixedArity. >>>>>>> >>>>>>> Updated fix: >>>>>>> http://cr.openjdk.java.net/~vlivanov/8036117/webrev.01/ >>>>>>> >>>>>>> Best regards, >>>>>>> Vladimir Ivanov >>>>>>> >>>>>>> On 3/8/14 4:51 AM, Christian Thalinger wrote: >>>>>>>> Seems good to me. I?d like to have another name for this method: >>>>>>>> >>>>>>>> + private static Object invokeCustom(MethodHandle target, >>>>>>>> Object... args) throws Throwable { >>>>>>>> >>>>>>>> On Mar 4, 2014, at 12:00 PM, Vladimir Ivanov >>>>>>>> wrote: >>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8036117/webrev.00/ >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8036117 >>>>>>>>> 84 lines changed: 74 ins; 3 del; 7 mod >>>>>>>>> >>>>>>>>> I have to revert a cleanup I did for 8027827. >>>>>>>>> MethodHandle.invokeWithArguments (and generic invocation) has >>>>>>>>> unpleasant >>>>>>>>> peculiarity in behavior when used with VarargsCollector. So, >>>>>>>>> unfortunately, invokeWithArguments is not an option there. >>>>>>>>> >>>>>>>>> Looking at the API (excerpts from javadoc [1] [2]), the following >>>>>>>>> condition doesn't hold in that case: >>>>>>>>> "trailing parameter type of the caller is a reference type >>>>>>>>> identical >>>>>>>>> to or assignable to the trailing parameter type of the adapter". >>>>>>>>> >>>>>>>>> Example: >>>>>>>>> target.invokeWithArguments((Object[])args) >>>>>>>>> => >>>>>>>>> target.invoke((Object)o1,(Object)o2,(Object)o3) >>>>>>>>> =/> >>>>>>>>> target.invokeExact((Object)o1, (Object)o2, (Object[])o3) >>>>>>>>> >>>>>>>>> because Object !<: Object[]. >>>>>>>>> >>>>>>>>> The fix is to skip unnecessary conversion when invoking a method >>>>>>>>> handle >>>>>>>>> and just do a pairwise type conversion. >>>>>>>>> >>>>>>>>> Testing: failing test case, nashorn w/ experimental features >>>>>>>>> (octane) >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Vladimir Ivanov >>>>>>>>> >>>>>>>>> [1] MethodHandle.invokeWithArguments >>>>>>>>> "Performs a variable arity invocation, ..., as if via an inexact >>>>>>>>> invoke >>>>>>>>> from a call site which mentions only the type Object, and whose >>>>>>>>> arity is >>>>>>>>> the length of the argument array." >>>>>>>>> >>>>>>>>> [2] MethodHandle.asVarargsCollector >>>>>>>>> "When called with plain, inexact invoke, if the caller type is >>>>>>>>> the >>>>>>>>> same >>>>>>>>> as the adapter, the adapter invokes the target as with >>>>>>>>> invokeExact. >>>>>>>>> (This is the normal behavior for invoke when types match.) >>>>>>>>> >>>>>>>>> Otherwise, if the caller and adapter arity are the same, and the >>>>>>>>> trailing parameter type of the caller is a reference type >>>>>>>>> identical to >>>>>>>>> or assignable to the trailing parameter type of the adapter, the >>>>>>>>> arguments and return values are converted pairwise, as if by >>>>>>>>> asType on a >>>>>>>>> fixed arity method handle. >>>>>>>>> >>>>>>>>> Otherwise, the arities differ, or the adapter's trailing >>>>>>>>> parameter >>>>>>>>> type >>>>>>>>> is not assignable from the corresponding caller type. In this >>>>>>>>> case, the >>>>>>>>> adapter replaces all trailing arguments from the original >>>>>>>>> trailing >>>>>>>>> argument position onward, by a new array of type arrayType, whose >>>>>>>>> elements comprise (in order) the replaced arguments." >>>>>>>>> _______________________________________________ >>>>>>>>> mlvm-dev mailing list >>>>>>>>> mlvm-dev at openjdk.java.net >>>>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> mlvm-dev mailing list >>>>>>>> mlvm-dev at openjdk.java.net >>>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> mlvm-dev mailing list >>>>>>> mlvm-dev at openjdk.java.net >>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>>> >>>>>> _______________________________________________ >>>>>> mlvm-dev mailing list >>>>>> mlvm-dev at openjdk.java.net >>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>>> >>>>> _______________________________________________ >>>>> mlvm-dev mailing list >>>>> mlvm-dev at openjdk.java.net >>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>> >>>> _______________________________________________ >>>> 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 Tue Mar 11 16:46:02 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 11 Mar 2014 20:46:02 +0400 Subject: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed) In-Reply-To: <531F353D.6000309@gmail.com> References: <531630D8.7030402@oracle.com> <9CEB01B8-D089-40DC-B63D-779A2994B6C9@oracle.com> <531E3ACE.3060108@oracle.com> <405A79C5-BC28-4C0B-91A9-5B1AED80F377@oracle.com> <531E46E2.7030107@oracle.com> <531EF4FE.6040806@gmail.com> <531EFA90.5070608@oracle.com> <531EFDFB.8020908@gmail.com> <531F182B.8000908@oracle.com> <531F353D.6000309@gmail.com> Message-ID: <531F3DCA.7090808@oracle.com> > So all you're achieving by annotating prepend() method is that any > exception stack trace, in case it is thrown inside the prepend() method, > will hide where it was thrown from. In case all LambdaForm frames > leading to the prepend() method were also hidden, the exception would > appear to be thrown from the invocation of the MH... Yes. Also, Thread.dumpStack() won't list it. Do you see any problem here? Best regards, Vladimir Ivanov > > Regards, Peter > >> >> Best regards, >> Vladimir Ivanov >> >>> Regards, Peter >>> >>>> >>>> There's not much value in it in this particular case, but I decided to >>>> reduce possible noise. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 3/11/14 3:35 PM, Peter Levart wrote: >>>>> Hi, >>>>> >>>>> Excuse my ignorant question: What is the purpose of @LambdaForm.Hidden >>>>> annotation? >>>>> >>>>> I suspect it has to do with hiding the call frames in stack traces >>>>> that >>>>> are part of LambdaForm invocation chain. In this case, method: >>>>> >>>>> private static Object[] prepend(Object elem, Object[] array) >>>>> >>>>> in MethodHandleImpl need not be annotated with this annotation, since >>>>> it's call frame is not on stack when one of the target methods is >>>>> executed. It's just a function used to calculate the argument of the >>>>> call. In fact, if prepend() ever throws exception (NPE in case >>>>> array is >>>>> null?), It would be preferable that it's call frame is visible in the >>>>> stack trace. >>>>> >>>>> Am I right or am I just talking nonsense? >>>>> >>>>> Regards, Peter >>>>> >>>>> >>>>> On 03/11/2014 12:12 AM, Vladimir Ivanov wrote: >>>>>> John, Chris, thanks! >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>> On 3/11/14 3:08 AM, Christian Thalinger wrote: >>>>>>> Even better. >>>>>>> >>>>>>> On Mar 10, 2014, at 3:21 PM, Vladimir Ivanov >>>>>>> wrote: >>>>>>> >>>>>>>> Chris, thanks for the review. >>>>>>>> >>>>>>>> John suggested an elegant way to fix the problem - use >>>>>>>> asFixedArity. >>>>>>>> >>>>>>>> Updated fix: >>>>>>>> http://cr.openjdk.java.net/~vlivanov/8036117/webrev.01/ >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir Ivanov >>>>>>>> >>>>>>>> On 3/8/14 4:51 AM, Christian Thalinger wrote: >>>>>>>>> Seems good to me. I?d like to have another name for this method: >>>>>>>>> >>>>>>>>> + private static Object invokeCustom(MethodHandle target, >>>>>>>>> Object... args) throws Throwable { >>>>>>>>> >>>>>>>>> On Mar 4, 2014, at 12:00 PM, Vladimir Ivanov >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8036117/webrev.00/ >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8036117 >>>>>>>>>> 84 lines changed: 74 ins; 3 del; 7 mod >>>>>>>>>> >>>>>>>>>> I have to revert a cleanup I did for 8027827. >>>>>>>>>> MethodHandle.invokeWithArguments (and generic invocation) has >>>>>>>>>> unpleasant >>>>>>>>>> peculiarity in behavior when used with VarargsCollector. So, >>>>>>>>>> unfortunately, invokeWithArguments is not an option there. >>>>>>>>>> >>>>>>>>>> Looking at the API (excerpts from javadoc [1] [2]), the following >>>>>>>>>> condition doesn't hold in that case: >>>>>>>>>> "trailing parameter type of the caller is a reference type >>>>>>>>>> identical >>>>>>>>>> to or assignable to the trailing parameter type of the adapter". >>>>>>>>>> >>>>>>>>>> Example: >>>>>>>>>> target.invokeWithArguments((Object[])args) >>>>>>>>>> => >>>>>>>>>> target.invoke((Object)o1,(Object)o2,(Object)o3) >>>>>>>>>> =/> >>>>>>>>>> target.invokeExact((Object)o1, (Object)o2, (Object[])o3) >>>>>>>>>> >>>>>>>>>> because Object !<: Object[]. >>>>>>>>>> >>>>>>>>>> The fix is to skip unnecessary conversion when invoking a method >>>>>>>>>> handle >>>>>>>>>> and just do a pairwise type conversion. >>>>>>>>>> >>>>>>>>>> Testing: failing test case, nashorn w/ experimental features >>>>>>>>>> (octane) >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Vladimir Ivanov >>>>>>>>>> >>>>>>>>>> [1] MethodHandle.invokeWithArguments >>>>>>>>>> "Performs a variable arity invocation, ..., as if via an inexact >>>>>>>>>> invoke >>>>>>>>>> from a call site which mentions only the type Object, and whose >>>>>>>>>> arity is >>>>>>>>>> the length of the argument array." >>>>>>>>>> >>>>>>>>>> [2] MethodHandle.asVarargsCollector >>>>>>>>>> "When called with plain, inexact invoke, if the caller type is >>>>>>>>>> the >>>>>>>>>> same >>>>>>>>>> as the adapter, the adapter invokes the target as with >>>>>>>>>> invokeExact. >>>>>>>>>> (This is the normal behavior for invoke when types match.) >>>>>>>>>> >>>>>>>>>> Otherwise, if the caller and adapter arity are the same, and the >>>>>>>>>> trailing parameter type of the caller is a reference type >>>>>>>>>> identical to >>>>>>>>>> or assignable to the trailing parameter type of the adapter, the >>>>>>>>>> arguments and return values are converted pairwise, as if by >>>>>>>>>> asType on a >>>>>>>>>> fixed arity method handle. >>>>>>>>>> >>>>>>>>>> Otherwise, the arities differ, or the adapter's trailing >>>>>>>>>> parameter >>>>>>>>>> type >>>>>>>>>> is not assignable from the corresponding caller type. In this >>>>>>>>>> case, the >>>>>>>>>> adapter replaces all trailing arguments from the original >>>>>>>>>> trailing >>>>>>>>>> argument position onward, by a new array of type arrayType, whose >>>>>>>>>> elements comprise (in order) the replaced arguments." >>>>>>>>>> _______________________________________________ >>>>>>>>>> mlvm-dev mailing list >>>>>>>>>> mlvm-dev at openjdk.java.net >>>>>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> mlvm-dev mailing list >>>>>>>>> mlvm-dev at openjdk.java.net >>>>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> mlvm-dev mailing list >>>>>>>> mlvm-dev at openjdk.java.net >>>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>>>> >>>>>>> _______________________________________________ >>>>>>> mlvm-dev mailing list >>>>>>> mlvm-dev at openjdk.java.net >>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>>>> >>>>>> _______________________________________________ >>>>>> mlvm-dev mailing list >>>>>> mlvm-dev at openjdk.java.net >>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>> >>>>> _______________________________________________ >>>>> mlvm-dev mailing list >>>>> mlvm-dev at openjdk.java.net >>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>> > From mike.duigou at oracle.com Tue Mar 11 17:07:04 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 11 Mar 2014 10:07:04 -0700 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: <531EC3BD.9050605@oracle.com> References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <5315EDAA.5020801@gmail.com> <531EC3BD.9050605@oracle.com> Message-ID: On Mar 11 2014, at 01:05 , Sergey Kuksenko wrote: > Brian, Mike. > > Could you explain what is the problem with the old caching? Concern over heap pollution with extra string copies was the motivation to ensure that only a single cached instance was ever returned. > String is immutable, BigDecimal is immutable. So we have data race at that place, but it is safe data race. Agreed that it is safe. > What is the problem if we create several identical strings? We can still create several identical strings. We will now only return the first assigned to stringCache. Other string instances will not escape. > You are making stringCache volatile -> performance penalty on ARM & PPC. It is understood that the volatile is not "free". For this purpose it was believed that the performance cost was a fair trade off to avoid the heap pollution. Regardless of the decision in this case the method used would seem to be the best caching pattern available. We do need to establish when it is appropriate to use this solution and what the tradeoffs are that would make other solutions more appropriate. > Setting cache via CAS -> performance penalty everywhere. This happens only once per BigDecimal (or not at all if the string format is never generated). > If you insist to use AtomicFieldUpdater - the better way is to use lazySet, not CAS. That would seem to be inappropriate for this usage as lazySet would effectively remove that volatile. Brian did some benchmarking of various alternatives which he can probably provide if we think it is relevant to the performance issue you're concerned with. Mike From brian.burkhalter at oracle.com Tue Mar 11 17:10:47 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 11 Mar 2014 10:10:47 -0700 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: <531EC6BF.4050701@oracle.com> References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <531EC6BF.4050701@oracle.com> Message-ID: <4742E0AD-8D87-4F22-8F23-779BDF3A58FE@oracle.com> Sergey, On Mar 11, 2014, at 1:18 AM, Sergey Kuksenko wrote: > Could you share your benchmarks? Of course. Please see: benchmark source: http://cr.openjdk.java.net/~bpb/6375303/Bench6375303.java benchmark results: http://cr.openjdk.java.net/~bpb/6375303/6375303-bench.html Let us know should you find anything amiss. Thanks, Brian From volker.simonis at gmail.com Tue Mar 11 17:56:46 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 11 Mar 2014 18:56:46 +0100 Subject: RFR[9](XXS): 8037013: [TESTBUG] Fix test/java/lang/ClassLoader/Assert.sh on AIX In-Reply-To: <531E6E07.2000806@oracle.com> References: <531E0A9E.50908@oracle.com> <531E6E07.2000806@oracle.com> Message-ID: Hi Mandy, thanks for the review. I'll look into the possibility of removing Assert.sh altogether and post a new webrev soon. Regards, Volker On Tue, Mar 11, 2014 at 2:59 AM, Mandy Chung wrote: > > On 3/10/2014 11:55 AM, Mandy Chung wrote: >> >> Hi Volker, >> >> On 3/10/14 11:16 AM, Volker Simonis wrote: >>> >>> Hi, >>> >>> could you please review the following trivial change which adds AIX to >>> the list of known OSs in test/java/lang/ClassLoader/Assert.sh: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8037013 >>> http://cr.openjdk.java.net/~simonis/webrevs/8037013/ >>> >> >> The link to your webrev is not accessible and could possibly due to the >> server issue. I guess your fix is to add AIX in the Assert.sh test. Can >> you paste the diff in mail? I can review it. >> > > I am able to access the webrev now - looks good. > > >> I raised in the code review of 7152892 [1] that I believe this test >> doesn't need to be a shell test. I don't know if Rob has started looking >> into it (he missed my review comment when he pushed the fix). I wonder if >> you would like to take the opportunity to investigate if Assert.sh can be >> removed? >> > > It'd be even better if we could get rid of Assert.sh. > > thanks > Mandy > >> Mandy >> [1] >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/024995.html > > From ivan.gerasimov at oracle.com Tue Mar 11 18:03:50 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 11 Mar 2014 22:03:50 +0400 Subject: RFR [8034262] Test java/lang/ProcessBuilder/CloseRace.java fails In-Reply-To: References: <531F0084.80703@oracle.com> Message-ID: <531F5006.5070303@oracle.com> Thank you Martin! On 11.03.2014 19:04, Martin Buchholz wrote: > Thanks for working on my brittle racy tests. > > Adding a latch as you did is a good improvement, although there's a > good chance the real problem lies elsewhere. > > My standard name for such latches is "threadsStarted", which I think > is a bit better than "startedSignal". Please rename. > No problem, renamed. > My simple calls to Thread.join are too optimistic. > More likely to be helpful is code like (pseudocode follows): > > thread.join(10, SECONDS); > if (thread.isAlive()) { > dumpAllStacks(); > fail(); > } > Yes, it was a good idea to do that! After implementing your suggestion, I could finally reproduce the failure. The OpenLoop child thread was spinning in the do-while loop, waiting for 'count of fds in use' to become 3. The simple solution is to add a check weather the current thread is interrupted to this and other loops. Would you please take a look at the updated webrev? http://cr.openjdk.java.net/~igerasim/8034262/1/webrev/ Sincerely yours, Ivan > That's more work to implement - optional. > > > On Tue, Mar 11, 2014 at 5:24 AM, Ivan Gerasimov > > wrote: > > Hello everybody! > > The test java/lang/ProcessBuilder/CloseRace.java was reported to > intermittently fail. > The test timed out, which should mean that at least one of the > child threads was never interrupted. > > I couldn't reproduce the failure, but I suspect it might happen > due to call to interrupt() before the child thread became alive > (I'm not really sure if it's possible to be non-alive after call > to start()). > The fix is to explicitly synchronize children with the parent. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8034262 > WEBREV: http://cr.openjdk.java.net/~igerasim/8034262/0/webrev/ > > > Sincerely yours, > Ivan > > From mike.duigou at oracle.com Tue Mar 11 22:31:56 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 11 Mar 2014 15:31:56 -0700 Subject: RFR: 8037097: (s) Improve diagnosability of test failures for java/util/Arrays/Correct.java Message-ID: Hello all; The test java/util/Arrays/Correct.java (yeah, great name...) has failed intermittently in nightly testing. Unfortunately the currently committed version does not provide much information on the failure condition. This changeset is a renovation of the test to hopefully provide additional clues to the root cause should the test fail again. It also adds somewhat more thorough testing as well as generifies and TestNGifies the source. http://cr.openjdk.java.net/~mduigou/JDK-8037097/0/webrev/ Mike From martinrb at google.com Tue Mar 11 22:45:31 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 11 Mar 2014 15:45:31 -0700 Subject: RFR [8034262] Test java/lang/ProcessBuilder/CloseRace.java fails In-Reply-To: <531F5006.5070303@oracle.com> References: <531F0084.80703@oracle.com> <531F5006.5070303@oracle.com> Message-ID: Well done! Not checking for interrupt in the loop is clearly my bug. dumpAllStacks looks like a very useful utility method (basically what jstack does). It feels like we're reinventing the wheel here, but I'm not sure. Instead of "break theLoop" I would have simply returned from the method. On Tue, Mar 11, 2014 at 11:03 AM, Ivan Gerasimov wrote: > Thank you Martin! > > > On 11.03.2014 19:04, Martin Buchholz wrote: > > Thanks for working on my brittle racy tests. > > Adding a latch as you did is a good improvement, although there's a good > chance the real problem lies elsewhere. > > My standard name for such latches is "threadsStarted", which I think is > a bit better than "startedSignal". Please rename. > > No problem, renamed. > > > My simple calls to Thread.join are too optimistic. > More likely to be helpful is code like (pseudocode follows): > > thread.join(10, SECONDS); > if (thread.isAlive()) { > dumpAllStacks(); > fail(); > } > > Yes, it was a good idea to do that! > After implementing your suggestion, I could finally reproduce the failure. > The OpenLoop child thread was spinning in the do-while loop, waiting for > 'count of fds in use' to become 3. > The simple solution is to add a check weather the current thread is > interrupted to this and other loops. > > Would you please take a look at the updated webrev? > http://cr.openjdk.java.net/~igerasim/8034262/1/webrev/ > > Sincerely yours, > Ivan > > > That's more work to implement - optional. > > > On Tue, Mar 11, 2014 at 5:24 AM, Ivan Gerasimov > wrote: > >> Hello everybody! >> >> The test java/lang/ProcessBuilder/CloseRace.java was reported to >> intermittently fail. >> The test timed out, which should mean that at least one of the child >> threads was never interrupted. >> >> I couldn't reproduce the failure, but I suspect it might happen due to >> call to interrupt() before the child thread became alive (I'm not really >> sure if it's possible to be non-alive after call to start()). >> The fix is to explicitly synchronize children with the parent. >> >> Would you please help review the fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8034262 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8034262/0/webrev/ >> >> Sincerely yours, >> Ivan >> > > > From mandy.chung at oracle.com Tue Mar 11 23:02:06 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 11 Mar 2014 16:02:06 -0700 Subject: RFR: 8037097: (s) Improve diagnosability of test failures for java/util/Arrays/Correct.java In-Reply-To: References: Message-ID: <531F95EE.5080200@oracle.com> On 3/11/14 3:31 PM, Mike Duigou wrote: > Hello all; > > The test java/util/Arrays/Correct.java (yeah, great name...) has failed intermittently in nightly testing. Unfortunately the currently committed version does not provide much information on the failure condition. This changeset is a renovation of the test to hopefully provide additional clues to the root cause should the test fail again. It also adds somewhat more thorough testing as well as generifies and TestNGifies the source. > > http://cr.openjdk.java.net/~mduigou/JDK-8037097/0/webrev/ > > Looks good to me. Mandy From mike.duigou at oracle.com Tue Mar 11 23:34:50 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 11 Mar 2014 16:34:50 -0700 Subject: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty In-Reply-To: References: <0541A3EA-A2A5-4977-8054-4EDB28366216@oracle.com> Message-ID: <318A3363-C4F6-42D5-99CD-DB6D00766B0C@oracle.com> On Feb 21 2014, at 14:56 , Martin Buchholz wrote: > You should do -> code conversion separately, and do it pervasively across the entire JDK. From your lips to God's ears.... I keep suggesting this along with a restyle to official style every time we create new repos. Seems unlikely unfortunately as it makes backports harder. > This is not right. > + * {@code (o==null ? get(i)==null : o.equals(get(i)))} Corrected. > You accidentally deleted a stray space here? > > - this.elementData = EMPTY_ELEMENTDATA; > + this.elementData = EMPTY_ELEMENTDATA; Corrected. > public ArrayList(int initialCapacity) { > - super(); > if (initialCapacity < 0) > throw new IllegalArgumentException("Illegal Capacity: "+ > initialCapacity); > - this.elementData = new Object[initialCapacity]; > + this.elementData = (initialCapacity > 0) > + ? new Object[initialCapacity] > + : EMPTY_ELEMENTDATA; > } > > When optimizing for special cases, we should try very hard minimize overhead in the common case. In the above, we now have two branches in the common case. Instead, > > if (initialCapacity > 0) this.elementData = new Object[initialCapacity]; > else if (initialCapacity == 0) this.elementData = EMPTY_ELEMENTDATA; > else barf Corrected. Thanks as always for the feedback. Mike > > > > On Fri, Feb 21, 2014 at 2:41 PM, Mike Duigou wrote: > Hello all; > > This changeset consists of two small performance improvements for ArrayList. Both are related to the lazy initialization introduced in JDK-8011200. > > The first change is in the ArrayList(int capacity) constructor and forces lazy initialization if the requested capacity is zero. It's been observed that in cases where zero capacity is requested that it is very likely that the list never receives any elements. For these cases we permanently avoid the allocation of an element array. > > The second change, noticed by Gustav ?kesson, involves the ArrayList(Collection c) constructor. If c is an empty collection then there is no reason to inflate the backing array for the ArrayList. > > http://cr.openjdk.java.net/~mduigou/JDK-8035584/0/webrev/ > > I also took the opportunity to the -> {@code } conversion for the javadoc. > > Enjoy! > > Mike > From martinrb at google.com Tue Mar 11 23:42:16 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 11 Mar 2014 16:42:16 -0700 Subject: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty In-Reply-To: <318A3363-C4F6-42D5-99CD-DB6D00766B0C@oracle.com> References: <0541A3EA-A2A5-4977-8054-4EDB28366216@oracle.com> <318A3363-C4F6-42D5-99CD-DB6D00766B0C@oracle.com> Message-ID: I don't see the updated webrev. Maybe you also fell victim to "rsync to cr no longer working"? On Tue, Mar 11, 2014 at 4:34 PM, Mike Duigou wrote: > > On Feb 21 2014, at 14:56 , Martin Buchholz wrote: > > You should do -> code conversion separately, and do it pervasively > across the entire JDK. > > > From your lips to God's ears.... I keep suggesting this along with a > restyle to official style every time we create new repos. Seems unlikely > unfortunately as it makes backports harder. > > This is not right. > + * {@code > (o==null ? get(i)==null : o.equals(get(i)))} > > > Corrected. > > You accidentally deleted a stray space here? > > - this.elementData = EMPTY_ELEMENTDATA; > + this.elementData = EMPTY_ELEMENTDATA; > > > Corrected. > > public ArrayList(int initialCapacity) { > - super(); > if (initialCapacity < 0) > throw new IllegalArgumentException("Illegal Capacity: "+ > initialCapacity); > - this.elementData = new Object[initialCapacity]; > + this.elementData = (initialCapacity > 0) > + ? new Object[initialCapacity] > + : EMPTY_ELEMENTDATA; > } > > When optimizing for special cases, we should try very hard minimize > overhead in the common case. In the above, we now have two branches in the > common case. Instead, > > if (initialCapacity > 0) this.elementData = new Object[initialCapacity]; > else if (initialCapacity == 0) this.elementData = EMPTY_ELEMENTDATA; > else barf > > > Corrected. > > Thanks as always for the feedback. > > Mike > > > > > On Fri, Feb 21, 2014 at 2:41 PM, Mike Duigou wrote: > >> Hello all; >> >> This changeset consists of two small performance improvements for >> ArrayList. Both are related to the lazy initialization introduced in >> JDK-8011200. >> >> The first change is in the ArrayList(int capacity) constructor and forces >> lazy initialization if the requested capacity is zero. It's been observed >> that in cases where zero capacity is requested that it is very likely that >> the list never receives any elements. For these cases we permanently avoid >> the allocation of an element array. >> >> The second change, noticed by Gustav ?kesson, involves the >> ArrayList(Collection c) constructor. If c is an empty collection then there >> is no reason to inflate the backing array for the ArrayList. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8035584/0/webrev/ >> >> I also took the opportunity to the -> {@code } conversion for >> the javadoc. >> >> Enjoy! >> >> Mike > > > > From mike.duigou at oracle.com Wed Mar 12 00:20:24 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 11 Mar 2014 17:20:24 -0700 Subject: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty In-Reply-To: References: <0541A3EA-A2A5-4977-8054-4EDB28366216@oracle.com> <318A3363-C4F6-42D5-99CD-DB6D00766B0C@oracle.com> Message-ID: <8FD1E74E-B433-475E-8DF6-3CB7126698AC@oracle.com> I've actually always used scp. :-) Since I accepted all of your changes as suggested and had no other changes I was just going to go ahead and push once testing was done. I've now prepared a revised webrev and can still accept feedback. http://cr.openjdk.java.net/~mduigou/JDK-8035584/1/webrev/ (Note: The webrev also contains https://bugs.openjdk.java.net/browse/JDK-8037097 since I am testing/pushing the two issues together.) Mike On Mar 11 2014, at 16:42 , Martin Buchholz wrote: > I don't see the updated webrev. Maybe you also fell victim to "rsync to cr no longer working"? > > > On Tue, Mar 11, 2014 at 4:34 PM, Mike Duigou wrote: > > On Feb 21 2014, at 14:56 , Martin Buchholz wrote: > >> You should do -> code conversion separately, and do it pervasively across the entire JDK. > > From your lips to God's ears.... I keep suggesting this along with a restyle to official style every time we create new repos. Seems unlikely unfortunately as it makes backports harder. > >> This is not right. >> + * {@code (o==null ? get(i)==null : o.equals(get(i)))} > > Corrected. > >> You accidentally deleted a stray space here? >> >> - this.elementData = EMPTY_ELEMENTDATA; >> + this.elementData = EMPTY_ELEMENTDATA; > > Corrected. > >> public ArrayList(int initialCapacity) { >> - super(); >> if (initialCapacity < 0) >> throw new IllegalArgumentException("Illegal Capacity: "+ >> initialCapacity); >> - this.elementData = new Object[initialCapacity]; >> + this.elementData = (initialCapacity > 0) >> + ? new Object[initialCapacity] >> + : EMPTY_ELEMENTDATA; >> } >> >> When optimizing for special cases, we should try very hard minimize overhead in the common case. In the above, we now have two branches in the common case. Instead, >> >> if (initialCapacity > 0) this.elementData = new Object[initialCapacity]; >> else if (initialCapacity == 0) this.elementData = EMPTY_ELEMENTDATA; >> else barf > > Corrected. > > Thanks as always for the feedback. > > Mike > >> >> >> >> On Fri, Feb 21, 2014 at 2:41 PM, Mike Duigou wrote: >> Hello all; >> >> This changeset consists of two small performance improvements for ArrayList. Both are related to the lazy initialization introduced in JDK-8011200. >> >> The first change is in the ArrayList(int capacity) constructor and forces lazy initialization if the requested capacity is zero. It's been observed that in cases where zero capacity is requested that it is very likely that the list never receives any elements. For these cases we permanently avoid the allocation of an element array. >> >> The second change, noticed by Gustav ?kesson, involves the ArrayList(Collection c) constructor. If c is an empty collection then there is no reason to inflate the backing array for the ArrayList. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8035584/0/webrev/ >> >> I also took the opportunity to the -> {@code } conversion for the javadoc. >> >> Enjoy! >> >> Mike >> > > From martinrb at google.com Wed Mar 12 00:42:19 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 11 Mar 2014 17:42:19 -0700 Subject: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty In-Reply-To: <8FD1E74E-B433-475E-8DF6-3CB7126698AC@oracle.com> References: <0541A3EA-A2A5-4977-8054-4EDB28366216@oracle.com> <318A3363-C4F6-42D5-99CD-DB6D00766B0C@oracle.com> <8FD1E74E-B433-475E-8DF6-3CB7126698AC@oracle.com> Message-ID: I'm hoping y'all have evidence that empty ArrayLists are common in the wild. It is curious that empty lists grow immediately to 10, while ArrayList with capacity 1 grows to 2, then 3... Some people might think that a bug. There are more   changes that need to be reverted. Else looks good. - * More formally, returns the lowest index i such that - * (o==null ? get(i)==null : o.equals(get(i))), + * More formally, returns the lowest index {@code i} such that + * {@code (o==null ? get(i)==null : o.equals(get(i)))}, On Tue, Mar 11, 2014 at 5:20 PM, Mike Duigou wrote: > I've actually always used scp. :-) > > Since I accepted all of your changes as suggested and had no other changes > I was just going to go ahead and push once testing was done. > > I've now prepared a revised webrev and can still accept feedback. > > http://cr.openjdk.java.net/~mduigou/JDK-8035584/1/webrev/ > > (Note: The webrev also contains > https://bugs.openjdk.java.net/browse/JDK-8037097 since I am > testing/pushing the two issues together.) > > Mike > > On Mar 11 2014, at 16:42 , Martin Buchholz wrote: > > I don't see the updated webrev. Maybe you also fell victim to "rsync to > cr no longer working"? > > > On Tue, Mar 11, 2014 at 4:34 PM, Mike Duigou wrote: > >> >> On Feb 21 2014, at 14:56 , Martin Buchholz wrote: >> >> You should do -> code conversion separately, and do it pervasively >> across the entire JDK. >> >> >> From your lips to God's ears.... I keep suggesting this along with a >> restyle to official style every time we create new repos. Seems unlikely >> unfortunately as it makes backports harder. >> >> This is not right. >> + * {@code >> (o==null ? get(i)==null : o.equals(get(i)))} >> >> >> Corrected. >> >> You accidentally deleted a stray space here? >> >> - this.elementData = EMPTY_ELEMENTDATA; >> + this.elementData = EMPTY_ELEMENTDATA; >> >> >> Corrected. >> >> public ArrayList(int initialCapacity) { >> - super(); >> if (initialCapacity < 0) >> throw new IllegalArgumentException("Illegal Capacity: "+ >> initialCapacity); >> - this.elementData = new Object[initialCapacity]; >> + this.elementData = (initialCapacity > 0) >> + ? new Object[initialCapacity] >> + : EMPTY_ELEMENTDATA; >> } >> >> When optimizing for special cases, we should try very hard minimize >> overhead in the common case. In the above, we now have two branches in the >> common case. Instead, >> >> if (initialCapacity > 0) this.elementData = new Object[initialCapacity]; >> else if (initialCapacity == 0) this.elementData = EMPTY_ELEMENTDATA; >> else barf >> >> >> Corrected. >> >> Thanks as always for the feedback. >> >> Mike >> >> >> >> >> On Fri, Feb 21, 2014 at 2:41 PM, Mike Duigou wrote: >> >>> Hello all; >>> >>> This changeset consists of two small performance improvements for >>> ArrayList. Both are related to the lazy initialization introduced in >>> JDK-8011200. >>> >>> The first change is in the ArrayList(int capacity) constructor and >>> forces lazy initialization if the requested capacity is zero. It's been >>> observed that in cases where zero capacity is requested that it is very >>> likely that the list never receives any elements. For these cases we >>> permanently avoid the allocation of an element array. >>> >>> The second change, noticed by Gustav ?kesson, involves the >>> ArrayList(Collection c) constructor. If c is an empty collection then there >>> is no reason to inflate the backing array for the ArrayList. >>> >>> http://cr.openjdk.java.net/~mduigou/JDK-8035584/0/webrev/ >>> >>> I also took the opportunity to the -> {@code } conversion for >>> the javadoc. >>> >>> Enjoy! >>> >>> Mike >> >> >> >> > > From mike.duigou at oracle.com Wed Mar 12 01:18:26 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 11 Mar 2014 18:18:26 -0700 Subject: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty In-Reply-To: References: <0541A3EA-A2A5-4977-8054-4EDB28366216@oracle.com> <318A3363-C4F6-42D5-99CD-DB6D00766B0C@oracle.com> <8FD1E74E-B433-475E-8DF6-3CB7126698AC@oracle.com> Message-ID: <4DC7C9B0-43F2-4FFF-A8D6-CFD1B54ED158@oracle.com> On Mar 11 2014, at 17:42 , Martin Buchholz wrote: > I'm hoping y'all have evidence that empty ArrayLists are common in the wild. Yes, certainly. From the original proposal: > [This change] based upon analysis that shows that in large applications as much as 10% of maps and lists are initialized but never receive any entries. A smaller number spend a large proportion of their lifetime empty. We've found similar results across other workloads as well. > It is curious that empty lists grow immediately to 10, while ArrayList with capacity 1 grows to 2, then 3... Some people might think that a bug. Yes, that's unfortunate. I've made another version that uses a second sentinel for the default sized but empty case. Now I want to reduce the ensureCapacity reallocations! It seems like insane churn to replace the arrays that frequently. > There are more   changes that need to be reverted. > Else looks good. > - * More formally, returns the lowest index i such that > - * (o==null ? get(i)==null : o.equals(get(i))), > + * More formally, returns the lowest index {@code i} such that > + * {@code (o==null ? get(i)==null : o.equals(get(i)))}, Corrected. Thank you. http://cr.openjdk.java.net/~mduigou/JDK-8035584/2/webrev/ Mike > > > On Tue, Mar 11, 2014 at 5:20 PM, Mike Duigou wrote: > I've actually always used scp. :-) > > Since I accepted all of your changes as suggested and had no other changes I was just going to go ahead and push once testing was done. > > I've now prepared a revised webrev and can still accept feedback. > > http://cr.openjdk.java.net/~mduigou/JDK-8035584/1/webrev/ > > (Note: The webrev also contains https://bugs.openjdk.java.net/browse/JDK-8037097 since I am testing/pushing the two issues together.) > > Mike > > On Mar 11 2014, at 16:42 , Martin Buchholz wrote: > >> I don't see the updated webrev. Maybe you also fell victim to "rsync to cr no longer working"? >> >> >> On Tue, Mar 11, 2014 at 4:34 PM, Mike Duigou wrote: >> >> On Feb 21 2014, at 14:56 , Martin Buchholz wrote: >> >>> You should do -> code conversion separately, and do it pervasively across the entire JDK. >> >> From your lips to God's ears.... I keep suggesting this along with a restyle to official style every time we create new repos. Seems unlikely unfortunately as it makes backports harder. >> >>> This is not right. >>> + * {@code (o==null ? get(i)==null : o.equals(get(i)))} >> >> Corrected. >> >>> You accidentally deleted a stray space here? >>> >>> - this.elementData = EMPTY_ELEMENTDATA; >>> + this.elementData = EMPTY_ELEMENTDATA; >> >> Corrected. >> >>> public ArrayList(int initialCapacity) { >>> - super(); >>> if (initialCapacity < 0) >>> throw new IllegalArgumentException("Illegal Capacity: "+ >>> initialCapacity); >>> - this.elementData = new Object[initialCapacity]; >>> + this.elementData = (initialCapacity > 0) >>> + ? new Object[initialCapacity] >>> + : EMPTY_ELEMENTDATA; >>> } >>> >>> When optimizing for special cases, we should try very hard minimize overhead in the common case. In the above, we now have two branches in the common case. Instead, >>> >>> if (initialCapacity > 0) this.elementData = new Object[initialCapacity]; >>> else if (initialCapacity == 0) this.elementData = EMPTY_ELEMENTDATA; >>> else barf >> >> Corrected. >> >> Thanks as always for the feedback. >> >> Mike >> >>> >>> >>> >>> On Fri, Feb 21, 2014 at 2:41 PM, Mike Duigou wrote: >>> Hello all; >>> >>> This changeset consists of two small performance improvements for ArrayList. Both are related to the lazy initialization introduced in JDK-8011200. >>> >>> The first change is in the ArrayList(int capacity) constructor and forces lazy initialization if the requested capacity is zero. It's been observed that in cases where zero capacity is requested that it is very likely that the list never receives any elements. For these cases we permanently avoid the allocation of an element array. >>> >>> The second change, noticed by Gustav ?kesson, involves the ArrayList(Collection c) constructor. If c is an empty collection then there is no reason to inflate the backing array for the ArrayList. >>> >>> http://cr.openjdk.java.net/~mduigou/JDK-8035584/0/webrev/ >>> >>> I also took the opportunity to the -> {@code } conversion for the javadoc. >>> >>> Enjoy! >>> >>> Mike >>> >> >> > > From david.holmes at oracle.com Wed Mar 12 04:46:25 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Mar 2014 14:46:25 +1000 Subject: RFR [8034262] Test java/lang/ProcessBuilder/CloseRace.java fails In-Reply-To: <531F0084.80703@oracle.com> References: <531F0084.80703@oracle.com> Message-ID: <531FE6A1.5090408@oracle.com> On 11/03/2014 10:24 PM, Ivan Gerasimov wrote: > Hello everybody! > > The test java/lang/ProcessBuilder/CloseRace.java was reported to > intermittently fail. > The test timed out, which should mean that at least one of the child > threads was never interrupted. > > I couldn't reproduce the failure, but I suspect it might happen due to > call to interrupt() before the child thread became alive (I'm not really > sure if it's possible to be non-alive after call to start()). It isn't. There's no reason the interrupt() would not be sent. More likely problem is that the thread gets stuck in those busy-loops for some reason; or the process.waitFor does not respond to the interrupt (not sure how that is handled). Need a stack-dump of a hung process. David ----- > The fix is to explicitly synchronize children with the parent. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8034262 > WEBREV: http://cr.openjdk.java.net/~igerasim/8034262/0/webrev/ > > Sincerely yours, > Ivan From joe.darcy at oracle.com Wed Mar 12 06:18:49 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 11 Mar 2014 23:18:49 -0700 Subject: JDK 9 RFR of JDK-8037174: Fix serial lint warnings in sun.applet Message-ID: <531FFC49.7030000@oracle.com> Hello, Please review the patch below to address JDK-8037174: Fix serial lint warnings in sun.applet http://cr.openjdk.java.net/~darcy/8037174.0/ Thanks, -Joe --- old/src/share/classes/sun/applet/AppletEvent.java 2014-03-11 23:15:49.000000000 -0700 +++ new/src/share/classes/sun/applet/AppletEvent.java 2014-03-11 23:15:49.000000000 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 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 @@ -33,7 +33,7 @@ * * @author Sunita Mani */ - + at SuppressWarnings("serial") // JDK-implementation class public class AppletEvent extends EventObject { private Object arg; --- old/src/share/classes/sun/applet/AppletIOException.java 2014-03-11 23:15:49.000000000 -0700 +++ new/src/share/classes/sun/applet/AppletIOException.java 2014-03-11 23:15:49.000000000 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1996, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1996, 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 @@ -32,6 +32,7 @@ * * @author Koji Uno */ + at SuppressWarnings("serial") // JDK implementation class public class AppletIOException extends IOException { private String key = null; --- old/src/share/classes/sun/applet/AppletIllegalArgumentException.java 2014-03-11 23:15:50.000000000 -0700 +++ new/src/share/classes/sun/applet/AppletIllegalArgumentException.java 2014-03-11 23:15:50.000000000 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1996, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1996, 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 @@ -30,6 +30,7 @@ * * @author Arthur van Hoff */ + at SuppressWarnings("serial") // JDK implementation class public class AppletIllegalArgumentException extends IllegalArgumentException { private String key = null; --- old/src/share/classes/sun/applet/AppletPanel.java 2014-03-11 23:15:50.000000000 -0700 +++ new/src/share/classes/sun/applet/AppletPanel.java 2014-03-11 23:15:50.000000000 -0700 @@ -62,6 +62,7 @@ * * @author Arthur van Hoff */ + at SuppressWarnings("serial") // JDK implementation class public abstract class AppletPanel extends Panel implements AppletStub, Runnable { --- old/src/share/classes/sun/applet/AppletProps.java 2014-03-11 23:15:51.000000000 -0700 +++ new/src/share/classes/sun/applet/AppletProps.java 2014-03-11 23:15:51.000000000 -0700 @@ -37,6 +37,7 @@ import sun.security.action.*; + at SuppressWarnings("serial") // JDK implementation class class AppletProps extends Frame { TextField proxyHost; @@ -194,7 +195,7 @@ /* 4066432 */ /* Dialog class to display property-related errors to user */ - + at SuppressWarnings("serial") // JDK implementation class class AppletPropsErrorDialog extends Dialog { public AppletPropsErrorDialog(Frame parent, String title, String message, String buttonText) { --- old/src/share/classes/sun/applet/AppletSecurityException.java 2014-03-11 23:15:51.000000000 -0700 +++ new/src/share/classes/sun/applet/AppletSecurityException.java 2014-03-11 23:15:51.000000000 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1995, 1998, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1995, 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 @@ -30,6 +30,7 @@ * * @author Arthur van Hoff */ + at SuppressWarnings("serial") // JDK-implementation class public class AppletSecurityException extends SecurityException { private String key = null; --- old/src/share/classes/sun/applet/AppletViewer.java 2014-03-11 23:15:52.000000000 -0700 +++ new/src/share/classes/sun/applet/AppletViewer.java 2014-03-11 23:15:52.000000000 -0700 @@ -46,6 +46,7 @@ /** * A frame to show the applet tag in. */ + at SuppressWarnings("serial") // JDK-implementation class class TextFrame extends Frame { /** @@ -115,6 +116,7 @@ * (The document named appletviewertags.html in the JDK's docs/tooldocs directory, * once the JDK docs have been installed.) */ + at SuppressWarnings("serial") // JDK implementation class public class AppletViewer extends Frame implements AppletContext, Printable { --- old/src/share/classes/sun/applet/Main.java 2014-03-11 23:15:52.000000000 -0700 +++ new/src/share/classes/sun/applet/Main.java 2014-03-11 23:15:52.000000000 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1999, 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 @@ -512,6 +512,7 @@ return amh.getMessage(key, arg0, arg1, arg2); } + @SuppressWarnings("serial") // JDK implementation class class ParseException extends RuntimeException { public ParseException(String msg) { From Alan.Bateman at oracle.com Wed Mar 12 07:29:11 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Mar 2014 07:29:11 +0000 Subject: JDK 9 RFR of JDK-8037174: Fix serial lint warnings in sun.applet In-Reply-To: <531FFC49.7030000@oracle.com> References: <531FFC49.7030000@oracle.com> Message-ID: <53200CC7.9070102@oracle.com> cc'ing awt-dev as this where the Applet code is maintained. In any case, the suppressing of serial warnings looks okay to me, assuming of course they don't leak into the serialized stream of a supported type. -Alan. On 12/03/2014 06:18, Joe Darcy wrote: > Hello, > > Please review the patch below to address > > JDK-8037174: Fix serial lint warnings in sun.applet > http://cr.openjdk.java.net/~darcy/8037174.0/ > > Thanks, > > -Joe > > --- old/src/share/classes/sun/applet/AppletEvent.java 2014-03-11 > 23:15:49.000000000 -0700 > +++ new/src/share/classes/sun/applet/AppletEvent.java 2014-03-11 > 23:15:49.000000000 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1997, 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 > @@ -33,7 +33,7 @@ > * > * @author Sunita Mani > */ > - > + at SuppressWarnings("serial") // JDK-implementation class > public class AppletEvent extends EventObject { > > private Object arg; > --- old/src/share/classes/sun/applet/AppletIOException.java 2014-03-11 > 23:15:49.000000000 -0700 > +++ new/src/share/classes/sun/applet/AppletIOException.java 2014-03-11 > 23:15:49.000000000 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1996, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1996, 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 > @@ -32,6 +32,7 @@ > * > * @author Koji Uno > */ > + at SuppressWarnings("serial") // JDK implementation class > public > class AppletIOException extends IOException { > private String key = null; > --- > old/src/share/classes/sun/applet/AppletIllegalArgumentException.java > 2014-03-11 23:15:50.000000000 -0700 > +++ > new/src/share/classes/sun/applet/AppletIllegalArgumentException.java > 2014-03-11 23:15:50.000000000 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1996, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1996, 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 > @@ -30,6 +30,7 @@ > * > * @author Arthur van Hoff > */ > + at SuppressWarnings("serial") // JDK implementation class > public > class AppletIllegalArgumentException extends IllegalArgumentException { > private String key = null; > --- old/src/share/classes/sun/applet/AppletPanel.java 2014-03-11 > 23:15:50.000000000 -0700 > +++ new/src/share/classes/sun/applet/AppletPanel.java 2014-03-11 > 23:15:50.000000000 -0700 > @@ -62,6 +62,7 @@ > * > * @author Arthur van Hoff > */ > + at SuppressWarnings("serial") // JDK implementation class > public > abstract class AppletPanel extends Panel implements AppletStub, > Runnable { > > --- old/src/share/classes/sun/applet/AppletProps.java 2014-03-11 > 23:15:51.000000000 -0700 > +++ new/src/share/classes/sun/applet/AppletProps.java 2014-03-11 > 23:15:51.000000000 -0700 > @@ -37,6 +37,7 @@ > > import sun.security.action.*; > > + at SuppressWarnings("serial") // JDK implementation class > class AppletProps extends Frame { > > TextField proxyHost; > @@ -194,7 +195,7 @@ > > /* 4066432 */ > /* Dialog class to display property-related errors to user */ > - > + at SuppressWarnings("serial") // JDK implementation class > class AppletPropsErrorDialog extends Dialog { > public AppletPropsErrorDialog(Frame parent, String title, String > message, > String buttonText) { > --- old/src/share/classes/sun/applet/AppletSecurityException.java > 2014-03-11 23:15:51.000000000 -0700 > +++ new/src/share/classes/sun/applet/AppletSecurityException.java > 2014-03-11 23:15:51.000000000 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1995, 1998, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1995, 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 > @@ -30,6 +30,7 @@ > * > * @author Arthur van Hoff > */ > + at SuppressWarnings("serial") // JDK-implementation class > public > class AppletSecurityException extends SecurityException { > private String key = null; > --- old/src/share/classes/sun/applet/AppletViewer.java 2014-03-11 > 23:15:52.000000000 -0700 > +++ new/src/share/classes/sun/applet/AppletViewer.java 2014-03-11 > 23:15:52.000000000 -0700 > @@ -46,6 +46,7 @@ > /** > * A frame to show the applet tag in. > */ > + at SuppressWarnings("serial") // JDK-implementation class > class TextFrame extends Frame { > > /** > @@ -115,6 +116,7 @@ > * (The document named appletviewertags.html in the JDK's > docs/tooldocs directory, > * once the JDK docs have been installed.) > */ > + at SuppressWarnings("serial") // JDK implementation class > public class AppletViewer extends Frame implements AppletContext, > Printable { > > --- old/src/share/classes/sun/applet/Main.java 2014-03-11 > 23:15:52.000000000 -0700 > +++ new/src/share/classes/sun/applet/Main.java 2014-03-11 > 23:15:52.000000000 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1999, 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 > @@ -512,6 +512,7 @@ > return amh.getMessage(key, arg0, arg1, arg2); > } > > + @SuppressWarnings("serial") // JDK implementation class > class ParseException extends RuntimeException > { > public ParseException(String msg) { > From Alan.Bateman at oracle.com Wed Mar 12 07:56:38 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Mar 2014 07:56:38 +0000 Subject: RFR: 8037097: (s) Improve diagnosability of test failures for java/util/Arrays/Correct.java In-Reply-To: References: Message-ID: <53201336.9090604@oracle.com> On 11/03/2014 22:31, Mike Duigou wrote: > Hello all; > > The test java/util/Arrays/Correct.java (yeah, great name...) has failed intermittently in nightly testing. Unfortunately the currently committed version does not provide much information on the failure condition. This changeset is a renovation of the test to hopefully provide additional clues to the root cause should the test fail again. It also adds somewhat more thorough testing as well as generifies and TestNGifies the source. > > http://cr.openjdk.java.net/~mduigou/JDK-8037097/0/webrev/ > > Mike I don't think I've ever seen this test fail. The stack trace in the bug report is a big odd, I would have thought it would show more Correct frames. From what I can tell then the test run where this was reported is -agentvm -concurrency so potentially random as to the tests that ran in the VM before this test. Also the test is using random array sizes. It's hard to know what this issue might be, maybe you are chasing a hotspot bug, maybe a subtle bug in stuipdSort. The re-implementation of the test in the webrev looks okay but if you are chasing a hotspot bug then it might not happen with the new test. My only comment on the updated test is that the array size would be useful to have in the output (if it's not in the output when the test fails). -Alan From ivan.gerasimov at oracle.com Wed Mar 12 08:36:51 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 12 Mar 2014 12:36:51 +0400 Subject: RFR [8034262] Test java/lang/ProcessBuilder/CloseRace.java fails In-Reply-To: References: <531F0084.80703@oracle.com> <531F5006.5070303@oracle.com> Message-ID: <53201CA3.6050801@oracle.com> Thanks Martin On 12.03.2014 2:45, Martin Buchholz wrote: > Well done! > > Not checking for interrupt in the loop is clearly my bug. > > dumpAllStacks looks like a very useful utility method (basically what > jstack does). It feels like we're reinventing the wheel here, but I'm > not sure. > jstack calls the hotspot-specific code to dump the stack traces, but I used the jdk-level routine. The dumpAllStacks() function has already done its job, so I could probably just remove it. Though it may be better to keep it just in case. > Instead of "break theLoop" I would have simply returned from the method. > OK, did that. Here's the updated webrev: http://cr.openjdk.java.net/~igerasim/8034262/2/webrev/ Sincerely yours, Ivan > > On Tue, Mar 11, 2014 at 11:03 AM, Ivan Gerasimov > > wrote: > > Thank you Martin! > > > On 11.03.2014 19:04, Martin Buchholz wrote: >> Thanks for working on my brittle racy tests. >> >> Adding a latch as you did is a good improvement, although there's >> a good chance the real problem lies elsewhere. >> >> My standard name for such latches is "threadsStarted", which I >> think is a bit better than "startedSignal". Please rename. >> > No problem, renamed. > > >> My simple calls to Thread.join are too optimistic. >> More likely to be helpful is code like (pseudocode follows): >> >> thread.join(10, SECONDS); >> if (thread.isAlive()) { >> dumpAllStacks(); >> fail(); >> } >> > Yes, it was a good idea to do that! > After implementing your suggestion, I could finally reproduce the > failure. > The OpenLoop child thread was spinning in the do-while loop, > waiting for 'count of fds in use' to become 3. > The simple solution is to add a check weather the current thread > is interrupted to this and other loops. > > Would you please take a look at the updated webrev? > http://cr.openjdk.java.net/~igerasim/8034262/1/webrev/ > > > Sincerely yours, > Ivan > > >> That's more work to implement - optional. >> >> >> On Tue, Mar 11, 2014 at 5:24 AM, Ivan Gerasimov >> > wrote: >> >> Hello everybody! >> >> The test java/lang/ProcessBuilder/CloseRace.java was reported >> to intermittently fail. >> The test timed out, which should mean that at least one of >> the child threads was never interrupted. >> >> I couldn't reproduce the failure, but I suspect it might >> happen due to call to interrupt() before the child thread >> became alive (I'm not really sure if it's possible to be >> non-alive after call to start()). >> The fix is to explicitly synchronize children with the parent. >> >> Would you please help review the fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8034262 >> WEBREV: >> http://cr.openjdk.java.net/~igerasim/8034262/0/webrev/ >> >> >> Sincerely yours, >> Ivan >> >> > > From ivan.gerasimov at oracle.com Wed Mar 12 08:42:10 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 12 Mar 2014 12:42:10 +0400 Subject: RFR [8034262] Test java/lang/ProcessBuilder/CloseRace.java fails In-Reply-To: <531FE6A1.5090408@oracle.com> References: <531F0084.80703@oracle.com> <531FE6A1.5090408@oracle.com> Message-ID: <53201DE2.1010009@oracle.com> Thank you David On 12.03.2014 8:46, David Holmes wrote: > On 11/03/2014 10:24 PM, Ivan Gerasimov wrote: >> Hello everybody! >> >> The test java/lang/ProcessBuilder/CloseRace.java was reported to >> intermittently fail. >> The test timed out, which should mean that at least one of the child >> threads was never interrupted. >> >> I couldn't reproduce the failure, but I suspect it might happen due to >> call to interrupt() before the child thread became alive (I'm not really >> sure if it's possible to be non-alive after call to start()). > > It isn't. There's no reason the interrupt() would not be sent. More > likely problem is that the thread gets stuck in those busy-loops for > some reason; or the process.waitFor does not respond to the interrupt > (not sure how that is handled). > Yes, you are right! The problem was with the loop in the child thread - please see my response to Martin's message above. > Need a stack-dump of a hung process. > Here's the updated webrev with the checks for the thread to be interrupted in the loops and stack dumping in the case of a failure: http://cr.openjdk.java.net/~igerasim/8034262/2/webrev/ Sincerely yours, Ivan > David > ----- > >> The fix is to explicitly synchronize children with the parent. >> >> Would you please help review the fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8034262 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8034262/0/webrev/ >> >> Sincerely yours, >> Ivan > > From peter.levart at gmail.com Wed Mar 12 08:45:25 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 12 Mar 2014 09:45:25 +0100 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <5315EDAA.5020801@gmail.com> <531EC3BD.9050605@oracle.com> Message-ID: <53201EA5.9090702@gmail.com> On 03/11/2014 06:07 PM, Mike Duigou wrote: >> >You are making stringCache volatile -> performance penalty on ARM & PPC. > It is understood that the volatile is not "free". For this purpose it was believed that the performance cost was a fair trade off to avoid the heap pollution. Regardless of the decision in this case the method used would seem to be the best caching pattern available. We do need to establish when it is appropriate to use this solution and what the tradeoffs are that would make other solutions more appropriate. > Hi, What would the following cost? private transient String stringCache; public String toString() { String sc = stringCache; if (sc == null) { sc = (String) U.getObjectVolatile(this, STRING_CACHE_OFFSET); if (sc == null) { sc = layoutChars(true); if (!U.compareAndSwapObject(this, STRING_CACHE_OFFSET, null, sc)) { sc = (String) U.getObjectVolatile(this, STRING_CACHE_OFFSET); } } } return sc; } private static final Unsafe U = Unsafe.getUnsafe(); private static final long STRING_CACHE_OFFSET; static { try { STRING_CACHE_OFFSET = U.objectFieldOffset(BigDecimal.class.getDeclaredField("stringCache")); } catch (NoSuchFieldException e) { throw new Error(e); } } Regards, Peter From peter.levart at gmail.com Wed Mar 12 08:54:36 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 12 Mar 2014 09:54:36 +0100 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: <4742E0AD-8D87-4F22-8F23-779BDF3A58FE@oracle.com> References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <531EC6BF.4050701@oracle.com> <4742E0AD-8D87-4F22-8F23-779BDF3A58FE@oracle.com> Message-ID: <532020CC.7000305@gmail.com> On 03/11/2014 06:10 PM, Brian Burkhalter wrote: > Sergey, > > On Mar 11, 2014, at 1:18 AM, Sergey Kuksenko wrote: > >> Could you share your benchmarks? > Of course. Please see: > > benchmark source: http://cr.openjdk.java.net/~bpb/6375303/Bench6375303.java > benchmark results: http://cr.openjdk.java.net/~bpb/6375303/6375303-bench.html > > Let us know should you find anything amiss. Do you have access to an ARM system (like Raspberry Pi ?) On Intel, volatile read is practically free - especially in micro benchmarks, when compared to normal read. The normal read can't be hoisted out of loops (the microbenchmark harness tries hard to prevent that)... I can try this on my Raspberry Pi when I get home. ;-) It would also be helpful if the JIT-ed assembly for the toString method could be dumped in various scenarios. Regards, Peter > > Thanks, > > Brian From peter.levart at gmail.com Wed Mar 12 09:08:28 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 12 Mar 2014 10:08:28 +0100 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: <4742E0AD-8D87-4F22-8F23-779BDF3A58FE@oracle.com> References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <531EC6BF.4050701@oracle.com> <4742E0AD-8D87-4F22-8F23-779BDF3A58FE@oracle.com> Message-ID: <5320240C.60304@gmail.com> On 03/11/2014 06:10 PM, Brian Burkhalter wrote: > Sergey, > > On Mar 11, 2014, at 1:18 AM, Sergey Kuksenko wrote: > >> Could you share your benchmarks? > Of course. Please see: > > benchmark source: http://cr.openjdk.java.net/~bpb/6375303/Bench6375303.java public class Bench6375303 { * static final Random rnd = ThreadLocalRandom.current();* static final BigDecimal BIG_D = new BigDecimal(new BigInteger(512, rnd)); static final String BIG_D_STRING = BIG_D.toString(); @GenerateMicroBenchmark @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) public void testFirstToString(BlackHole bh) { BigDecimal bigD = new BigDecimal(new BigInteger(512,*rnd*)); bh.consume(bigD.toString()); } @GenerateMicroBenchmark @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) public void testToString(BlackHole bh) { bh.consume(BIG_D.toString()); } } Huh! This is a ThreadLocalRandom anti-pattern. Thou should not use a ThreadLocalRandom instance in a thread that did not obtain it via a call to ThreadLocalRandom.current()... You could create a new BigInteger(512, *rnd*) in the static initializer and use it to create new BigDecima(bigInteger) in testFirstToStrin. * Regards, Peter * > benchmark results: http://cr.openjdk.java.net/~bpb/6375303/6375303-bench.html > > Let us know should you find anything amiss. > > Thanks, > > Brian From david.holmes at oracle.com Wed Mar 12 09:34:58 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Mar 2014 19:34:58 +1000 Subject: RFR [8034262] Test java/lang/ProcessBuilder/CloseRace.java fails In-Reply-To: <53201CA3.6050801@oracle.com> References: <531F0084.80703@oracle.com> <531F5006.5070303@oracle.com> <53201CA3.6050801@oracle.com> Message-ID: <53202A42.4000205@oracle.com> Ivan, Ignore my earlier email as I hadn't seen the follow ups. You don't need the CountDownLatch - but it is harmless. Otherwise looks good to me. Thanks, David On 12/03/2014 6:36 PM, Ivan Gerasimov wrote: > Thanks Martin > > On 12.03.2014 2:45, Martin Buchholz wrote: >> Well done! >> >> Not checking for interrupt in the loop is clearly my bug. >> >> dumpAllStacks looks like a very useful utility method (basically what >> jstack does). It feels like we're reinventing the wheel here, but I'm >> not sure. >> > > jstack calls the hotspot-specific code to dump the stack traces, but I > used the jdk-level routine. > The dumpAllStacks() function has already done its job, so I could > probably just remove it. > Though it may be better to keep it just in case. > >> Instead of "break theLoop" I would have simply returned from the method. >> > > OK, did that. Here's the updated webrev: > > http://cr.openjdk.java.net/~igerasim/8034262/2/webrev/ > > Sincerely yours, > Ivan > >> >> On Tue, Mar 11, 2014 at 11:03 AM, Ivan Gerasimov >> > wrote: >> >> Thank you Martin! >> >> >> On 11.03.2014 19:04, Martin Buchholz wrote: >>> Thanks for working on my brittle racy tests. >>> >>> Adding a latch as you did is a good improvement, although there's >>> a good chance the real problem lies elsewhere. >>> >>> My standard name for such latches is "threadsStarted", which I >>> think is a bit better than "startedSignal". Please rename. >>> >> No problem, renamed. >> >> >>> My simple calls to Thread.join are too optimistic. >>> More likely to be helpful is code like (pseudocode follows): >>> >>> thread.join(10, SECONDS); >>> if (thread.isAlive()) { >>> dumpAllStacks(); >>> fail(); >>> } >>> >> Yes, it was a good idea to do that! >> After implementing your suggestion, I could finally reproduce the >> failure. >> The OpenLoop child thread was spinning in the do-while loop, >> waiting for 'count of fds in use' to become 3. >> The simple solution is to add a check weather the current thread >> is interrupted to this and other loops. >> >> Would you please take a look at the updated webrev? >> http://cr.openjdk.java.net/~igerasim/8034262/1/webrev/ >> >> >> Sincerely yours, >> Ivan >> >> >>> That's more work to implement - optional. >>> >>> >>> On Tue, Mar 11, 2014 at 5:24 AM, Ivan Gerasimov >>> > >>> wrote: >>> >>> Hello everybody! >>> >>> The test java/lang/ProcessBuilder/CloseRace.java was reported >>> to intermittently fail. >>> The test timed out, which should mean that at least one of >>> the child threads was never interrupted. >>> >>> I couldn't reproduce the failure, but I suspect it might >>> happen due to call to interrupt() before the child thread >>> became alive (I'm not really sure if it's possible to be >>> non-alive after call to start()). >>> The fix is to explicitly synchronize children with the parent. >>> >>> Would you please help review the fix? >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8034262 >>> WEBREV: >>> http://cr.openjdk.java.net/~igerasim/8034262/0/webrev/ >>> >>> >>> Sincerely yours, >>> Ivan >>> >>> >> >> > From paul.sandoz at oracle.com Wed Mar 12 09:35:41 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 12 Mar 2014 10:35:41 +0100 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: <531EC3BD.9050605@oracle.com> References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <5315EDAA.5020801@gmail.com> <531EC3BD.9050605@oracle.com> Message-ID: <22776758-BAED-45FB-B301-59D9B91E5BEF@oracle.com> On Mar 11, 2014, at 9:05 AM, Sergey Kuksenko wrote: > Brian, Mike. > > Could you explain what is the problem with the old caching? > String is immutable, BigDecimal is immutable. So we have data race at that place, but it is safe data race. What is the problem if we create several identical strings? I was wondering the same. Not convinced it is so very important for toString() to guarantee one and only one reference to the same value. I would be inclined to leave this alone unless some data indicates otherwise. I do question the use of the ThreadLocal to in effect cache a StringBuilder and char array of 19 characters for memory reuse (that is "heap pollution" per thread! :-) ). This code was introduced ~5 years ago, perhaps it is time to revisit and measure using SPEC* benchmarks? Paul. > You are making stringCache volatile -> performance penalty on ARM & PPC. > Setting cache via CAS -> performance penalty everywhere. > > If you insist to use AtomicFieldUpdater - the better way is to use lazySet, not CAS. From paul.sandoz at oracle.com Wed Mar 12 09:45:51 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 12 Mar 2014 10:45:51 +0100 Subject: Fedora sun.misc.Unsafe statistics In-Reply-To: <53163614.2070802@redhat.com> References: <53163614.2070802@redhat.com> Message-ID: <409CB24B-1960-46BF-9660-D664A14994C0@oracle.com> Hi Florian, Thanks for doing this. Do you have any more context on what RPMs/jars are using what methods of Unsafe? such information would be useful to correlated with that on maven central. I think i can guess some aspects e.g.: monitorEnter | (Ljava/lang/Object;)V | 1 monitorExit | (Ljava/lang/Object;)V | 1 On Mar 4, 2014, at 9:22 PM, Florian Weimer wrote: > Out of curiosity, I looked at JAR files in all RPMs in Fedora rawhide (the development version of Fedora that will turn into Fedora 21) and counted the number of RPM packages which had Java classes referencing individual methods in sun.misc.Unsafe. The attached table is sorted by decreasing package count, and grouped by method name and descriptor. > > These numbers do not include references through reflection, for obvious reasons. > > Java programming practices are sometimes at odds with distribution packaging, and due to licensing bias, the Fedora repository might not be representative of the general Java ecosystem. However, the statistics cover 1177 Java source RPMs containing 550829 classes in 570477 versions, so it's quite a bit of code, despite the fairly low number of references to sun.misc.Unsafe. > It might be useful to obtain the number of (transitive) dependencies on such jars. I don't have data yet from maven central but i know some jars that use Unsafe are quite popular. Paul. From scolebourne at joda.org Wed Mar 12 10:45:11 2014 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 12 Mar 2014 10:45:11 +0000 Subject: RFR: JDK-8036818: DateTimeFormatter withResolverFields() fails to accept null Message-ID: This is a request for review of this bug: https://bugs.openjdk.java.net/browse/JDK-8036818 The method DateTimeFormatter withResolverFields() is supposed to accept null. This is to allow a coy of the formatter to be returned reset to the original state of having no resolver fields. The docs say: "@param resolverFields the new set of resolver fields, null if no fields" which was written to indicate that resetting to null is permitted. The fix is to check for null and return a copy of the formatter. Note that there are two variations of the method which need fixing. Proposed patch: https://gist.github.com/jodastephen/9395197 The patch includes no spec changes. The patch fixes the broken TCK tests. I need a reviewer and a committer please. thanks Stephen From scolebourne at joda.org Wed Mar 12 10:48:20 2014 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 12 Mar 2014 10:48:20 +0000 Subject: RFR: JDK-8035099 LocalTime with(MILLI_OF_DAY/MICRO_OF_DAY) incorrect Message-ID: This is a request for review of this bug: https://bugs.openjdk.java.net/browse/JDK-8035099 The implementation for LocalTime with(MILLI_OF_DAY, n) and LocalTime with(MICRO_OF_DAY, n) fails to match the specification. LocalTime base = LocalTime.of(12, 30, 40, 987654321); LocalTime result = base.with(MILLI_OF_DAY, 0); expected: 00:00:00.000000000 was: 00:00:00.000654321 LocalTime result = base.with(MICRO_OF_DAY, 0); expected: 00:00:00.000000000 was: 00:00:00.000000321 The spec is clear in both cases - "This completely replaces the time and is equivalent to using {@link #ofNanoOfDay(long)}", thus this is clearly a bug. Proposed patch: https://gist.github.com/jodastephen/9057131 The patch includes no spec changes. The patch includes new TCK tests that are derived explicitly from the spec. I need a reviewer and a committer please. thanks Stephen From scolebourne at joda.org Wed Mar 12 10:52:51 2014 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 12 Mar 2014 10:52:51 +0000 Subject: RFR: JDK-8036785 ChronoLocalDate refers to generics that have been removed Message-ID: This is a request for review of this bug: https://bugs.openjdk.java.net/browse/JDK-8036785 During development, ChronoLocalDate had a generic type parameter. It was removed during the development of JSR-310. The Javadoc was not updated to reflect the removal. The necessary change is to text that is essentially non-normative, and as such this change should be non-controversial. Proposed patch: https://gist.github.com/jodastephen/9395412 The patch includes non-normative spec changes. The patch includes no code changes. I need a reviewer and a committer please. thanks Stephen From peter.levart at gmail.com Wed Mar 12 11:44:36 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 12 Mar 2014 12:44:36 +0100 Subject: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed) In-Reply-To: <531F3DCA.7090808@oracle.com> References: <531630D8.7030402@oracle.com> <9CEB01B8-D089-40DC-B63D-779A2994B6C9@oracle.com> <531E3ACE.3060108@oracle.com> <405A79C5-BC28-4C0B-91A9-5B1AED80F377@oracle.com> <531E46E2.7030107@oracle.com> <531EF4FE.6040806@gmail.com> <531EFA90.5070608@oracle.com> <531EFDFB.8020908@gmail.com> <531F182B.8000908@oracle.com> <531F353D.6000309@gmail.com> <531F3DCA.7090808@oracle.com> Message-ID: <532048A4.5010709@gmail.com> On 03/11/2014 05:46 PM, Vladimir Ivanov wrote: >> So all you're achieving by annotating prepend() method is that any >> exception stack trace, in case it is thrown inside the prepend() method, >> will hide where it was thrown from. In case all LambdaForm frames >> leading to the prepend() method were also hidden, the exception would >> appear to be thrown from the invocation of the MH... > Yes. Also, Thread.dumpStack() won't list it. > Do you see any problem here? > It depends on what you're trying to achieve. Whether you're trying to hide the internals even in situations where something goes wrong or you're trying to simplify debugging in case something goes wrong. But I guess not much can go wrong in this method as I suspect the passed-in 'array' can't be null, so it really doesn't matter. Regards, Peter > Best regards, > Vladimir Ivanov > >> >> Regards, Peter >> >>> >>> Best regards, >>> Vladimir Ivanov >>> >>>> Regards, Peter >>>> >>>>> >>>>> There's not much value in it in this particular case, but I >>>>> decided to >>>>> reduce possible noise. >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> On 3/11/14 3:35 PM, Peter Levart wrote: >>>>>> Hi, >>>>>> >>>>>> Excuse my ignorant question: What is the purpose of >>>>>> @LambdaForm.Hidden >>>>>> annotation? >>>>>> >>>>>> I suspect it has to do with hiding the call frames in stack traces >>>>>> that >>>>>> are part of LambdaForm invocation chain. In this case, method: >>>>>> >>>>>> private static Object[] prepend(Object elem, Object[] array) >>>>>> >>>>>> in MethodHandleImpl need not be annotated with this annotation, >>>>>> since >>>>>> it's call frame is not on stack when one of the target methods is >>>>>> executed. It's just a function used to calculate the argument of the >>>>>> call. In fact, if prepend() ever throws exception (NPE in case >>>>>> array is >>>>>> null?), It would be preferable that it's call frame is visible in >>>>>> the >>>>>> stack trace. >>>>>> >>>>>> Am I right or am I just talking nonsense? >>>>>> >>>>>> Regards, Peter >>>>>> >>>>>> >>>>>> On 03/11/2014 12:12 AM, Vladimir Ivanov wrote: >>>>>>> John, Chris, thanks! >>>>>>> >>>>>>> Best regards, >>>>>>> Vladimir Ivanov >>>>>>> >>>>>>> On 3/11/14 3:08 AM, Christian Thalinger wrote: >>>>>>>> Even better. >>>>>>>> >>>>>>>> On Mar 10, 2014, at 3:21 PM, Vladimir Ivanov >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Chris, thanks for the review. >>>>>>>>> >>>>>>>>> John suggested an elegant way to fix the problem - use >>>>>>>>> asFixedArity. >>>>>>>>> >>>>>>>>> Updated fix: >>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8036117/webrev.01/ >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Vladimir Ivanov >>>>>>>>> >>>>>>>>> On 3/8/14 4:51 AM, Christian Thalinger wrote: >>>>>>>>>> Seems good to me. I?d like to have another name for this >>>>>>>>>> method: >>>>>>>>>> >>>>>>>>>> + private static Object invokeCustom(MethodHandle target, >>>>>>>>>> Object... args) throws Throwable { >>>>>>>>>> >>>>>>>>>> On Mar 4, 2014, at 12:00 PM, Vladimir Ivanov >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8036117/webrev.00/ >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8036117 >>>>>>>>>>> 84 lines changed: 74 ins; 3 del; 7 mod >>>>>>>>>>> >>>>>>>>>>> I have to revert a cleanup I did for 8027827. >>>>>>>>>>> MethodHandle.invokeWithArguments (and generic invocation) has >>>>>>>>>>> unpleasant >>>>>>>>>>> peculiarity in behavior when used with VarargsCollector. So, >>>>>>>>>>> unfortunately, invokeWithArguments is not an option there. >>>>>>>>>>> >>>>>>>>>>> Looking at the API (excerpts from javadoc [1] [2]), the >>>>>>>>>>> following >>>>>>>>>>> condition doesn't hold in that case: >>>>>>>>>>> "trailing parameter type of the caller is a reference type >>>>>>>>>>> identical >>>>>>>>>>> to or assignable to the trailing parameter type of the >>>>>>>>>>> adapter". >>>>>>>>>>> >>>>>>>>>>> Example: >>>>>>>>>>> target.invokeWithArguments((Object[])args) >>>>>>>>>>> => >>>>>>>>>>> target.invoke((Object)o1,(Object)o2,(Object)o3) >>>>>>>>>>> =/> >>>>>>>>>>> target.invokeExact((Object)o1, (Object)o2, (Object[])o3) >>>>>>>>>>> >>>>>>>>>>> because Object !<: Object[]. >>>>>>>>>>> >>>>>>>>>>> The fix is to skip unnecessary conversion when invoking a >>>>>>>>>>> method >>>>>>>>>>> handle >>>>>>>>>>> and just do a pairwise type conversion. >>>>>>>>>>> >>>>>>>>>>> Testing: failing test case, nashorn w/ experimental features >>>>>>>>>>> (octane) >>>>>>>>>>> >>>>>>>>>>> Thanks! >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Vladimir Ivanov >>>>>>>>>>> >>>>>>>>>>> [1] MethodHandle.invokeWithArguments >>>>>>>>>>> "Performs a variable arity invocation, ..., as if via an >>>>>>>>>>> inexact >>>>>>>>>>> invoke >>>>>>>>>>> from a call site which mentions only the type Object, and whose >>>>>>>>>>> arity is >>>>>>>>>>> the length of the argument array." >>>>>>>>>>> >>>>>>>>>>> [2] MethodHandle.asVarargsCollector >>>>>>>>>>> "When called with plain, inexact invoke, if the caller type is >>>>>>>>>>> the >>>>>>>>>>> same >>>>>>>>>>> as the adapter, the adapter invokes the target as with >>>>>>>>>>> invokeExact. >>>>>>>>>>> (This is the normal behavior for invoke when types match.) >>>>>>>>>>> >>>>>>>>>>> Otherwise, if the caller and adapter arity are the same, and >>>>>>>>>>> the >>>>>>>>>>> trailing parameter type of the caller is a reference type >>>>>>>>>>> identical to >>>>>>>>>>> or assignable to the trailing parameter type of the adapter, >>>>>>>>>>> the >>>>>>>>>>> arguments and return values are converted pairwise, as if by >>>>>>>>>>> asType on a >>>>>>>>>>> fixed arity method handle. >>>>>>>>>>> >>>>>>>>>>> Otherwise, the arities differ, or the adapter's trailing >>>>>>>>>>> parameter >>>>>>>>>>> type >>>>>>>>>>> is not assignable from the corresponding caller type. In this >>>>>>>>>>> case, the >>>>>>>>>>> adapter replaces all trailing arguments from the original >>>>>>>>>>> trailing >>>>>>>>>>> argument position onward, by a new array of type arrayType, >>>>>>>>>>> whose >>>>>>>>>>> elements comprise (in order) the replaced arguments." >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> mlvm-dev mailing list >>>>>>>>>>> mlvm-dev at openjdk.java.net >>>>>>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> mlvm-dev mailing list >>>>>>>>>> mlvm-dev at openjdk.java.net >>>>>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> mlvm-dev mailing list >>>>>>>>> mlvm-dev at openjdk.java.net >>>>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> mlvm-dev mailing list >>>>>>>> mlvm-dev at openjdk.java.net >>>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> mlvm-dev mailing list >>>>>>> mlvm-dev at openjdk.java.net >>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>>> >>>>>> _______________________________________________ >>>>>> 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 Wed Mar 12 11:54:10 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 12 Mar 2014 12:54:10 +0100 Subject: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed) In-Reply-To: <532048A4.5010709@gmail.com> References: <531630D8.7030402@oracle.com> <9CEB01B8-D089-40DC-B63D-779A2994B6C9@oracle.com> <531E3ACE.3060108@oracle.com> <405A79C5-BC28-4C0B-91A9-5B1AED80F377@oracle.com> <531E46E2.7030107@oracle.com> <531EF4FE.6040806@gmail.com> <531EFA90.5070608@oracle.com> <531EFDFB.8020908@gmail.com> <531F182B.8000908@oracle.com> <531F353D.6000309@gmail.com> <531F3DCA.7090808@oracle.com> <532048A4.5010709@gmail.com> Message-ID: <53204AE2.4090402@gmail.com> On 03/12/2014 12:44 PM, Peter Levart wrote: > On 03/11/2014 05:46 PM, Vladimir Ivanov wrote: >>> So all you're achieving by annotating prepend() method is that any >>> exception stack trace, in case it is thrown inside the prepend() >>> method, >>> will hide where it was thrown from. In case all LambdaForm frames >>> leading to the prepend() method were also hidden, the exception would >>> appear to be thrown from the invocation of the MH... >> Yes. Also, Thread.dumpStack() won't list it. >> Do you see any problem here? >> > It depends on what you're trying to achieve. Whether you're trying to > hide the internals even in situations where something goes wrong or > you're trying to simplify debugging in case something goes wrong. But > I guess not much can go wrong in this method as I suspect the > passed-in 'array' can't be null, so it really doesn't matter. ...currently. But if this method is (re)used in other contexts in the future, ... > > Regards, Peter > >> Best regards, >> Vladimir Ivanov >> >>> >>> Regards, Peter >>> >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>>> Regards, Peter >>>>> >>>>>> >>>>>> There's not much value in it in this particular case, but I >>>>>> decided to >>>>>> reduce possible noise. >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>> On 3/11/14 3:35 PM, Peter Levart wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Excuse my ignorant question: What is the purpose of >>>>>>> @LambdaForm.Hidden >>>>>>> annotation? >>>>>>> >>>>>>> I suspect it has to do with hiding the call frames in stack traces >>>>>>> that >>>>>>> are part of LambdaForm invocation chain. In this case, method: >>>>>>> >>>>>>> private static Object[] prepend(Object elem, Object[] array) >>>>>>> >>>>>>> in MethodHandleImpl need not be annotated with this annotation, >>>>>>> since >>>>>>> it's call frame is not on stack when one of the target methods is >>>>>>> executed. It's just a function used to calculate the argument of >>>>>>> the >>>>>>> call. In fact, if prepend() ever throws exception (NPE in case >>>>>>> array is >>>>>>> null?), It would be preferable that it's call frame is visible >>>>>>> in the >>>>>>> stack trace. >>>>>>> >>>>>>> Am I right or am I just talking nonsense? >>>>>>> >>>>>>> Regards, Peter >>>>>>> >>>>>>> >>>>>>> On 03/11/2014 12:12 AM, Vladimir Ivanov wrote: >>>>>>>> John, Chris, thanks! >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir Ivanov >>>>>>>> >>>>>>>> On 3/11/14 3:08 AM, Christian Thalinger wrote: >>>>>>>>> Even better. >>>>>>>>> >>>>>>>>> On Mar 10, 2014, at 3:21 PM, Vladimir Ivanov >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Chris, thanks for the review. >>>>>>>>>> >>>>>>>>>> John suggested an elegant way to fix the problem - use >>>>>>>>>> asFixedArity. >>>>>>>>>> >>>>>>>>>> Updated fix: >>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8036117/webrev.01/ >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Vladimir Ivanov >>>>>>>>>> >>>>>>>>>> On 3/8/14 4:51 AM, Christian Thalinger wrote: >>>>>>>>>>> Seems good to me. I?d like to have another name for this >>>>>>>>>>> method: >>>>>>>>>>> >>>>>>>>>>> + private static Object invokeCustom(MethodHandle target, >>>>>>>>>>> Object... args) throws Throwable { >>>>>>>>>>> >>>>>>>>>>> On Mar 4, 2014, at 12:00 PM, Vladimir Ivanov >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8036117/webrev.00/ >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8036117 >>>>>>>>>>>> 84 lines changed: 74 ins; 3 del; 7 mod >>>>>>>>>>>> >>>>>>>>>>>> I have to revert a cleanup I did for 8027827. >>>>>>>>>>>> MethodHandle.invokeWithArguments (and generic invocation) has >>>>>>>>>>>> unpleasant >>>>>>>>>>>> peculiarity in behavior when used with VarargsCollector. So, >>>>>>>>>>>> unfortunately, invokeWithArguments is not an option there. >>>>>>>>>>>> >>>>>>>>>>>> Looking at the API (excerpts from javadoc [1] [2]), the >>>>>>>>>>>> following >>>>>>>>>>>> condition doesn't hold in that case: >>>>>>>>>>>> "trailing parameter type of the caller is a reference type >>>>>>>>>>>> identical >>>>>>>>>>>> to or assignable to the trailing parameter type of the >>>>>>>>>>>> adapter". >>>>>>>>>>>> >>>>>>>>>>>> Example: >>>>>>>>>>>> target.invokeWithArguments((Object[])args) >>>>>>>>>>>> => >>>>>>>>>>>> target.invoke((Object)o1,(Object)o2,(Object)o3) >>>>>>>>>>>> =/> >>>>>>>>>>>> target.invokeExact((Object)o1, (Object)o2, (Object[])o3) >>>>>>>>>>>> >>>>>>>>>>>> because Object !<: Object[]. >>>>>>>>>>>> >>>>>>>>>>>> The fix is to skip unnecessary conversion when invoking a >>>>>>>>>>>> method >>>>>>>>>>>> handle >>>>>>>>>>>> and just do a pairwise type conversion. >>>>>>>>>>>> >>>>>>>>>>>> Testing: failing test case, nashorn w/ experimental features >>>>>>>>>>>> (octane) >>>>>>>>>>>> >>>>>>>>>>>> Thanks! >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Vladimir Ivanov >>>>>>>>>>>> >>>>>>>>>>>> [1] MethodHandle.invokeWithArguments >>>>>>>>>>>> "Performs a variable arity invocation, ..., as if via an >>>>>>>>>>>> inexact >>>>>>>>>>>> invoke >>>>>>>>>>>> from a call site which mentions only the type Object, and >>>>>>>>>>>> whose >>>>>>>>>>>> arity is >>>>>>>>>>>> the length of the argument array." >>>>>>>>>>>> >>>>>>>>>>>> [2] MethodHandle.asVarargsCollector >>>>>>>>>>>> "When called with plain, inexact invoke, if the caller type is >>>>>>>>>>>> the >>>>>>>>>>>> same >>>>>>>>>>>> as the adapter, the adapter invokes the target as with >>>>>>>>>>>> invokeExact. >>>>>>>>>>>> (This is the normal behavior for invoke when types match.) >>>>>>>>>>>> >>>>>>>>>>>> Otherwise, if the caller and adapter arity are the same, >>>>>>>>>>>> and the >>>>>>>>>>>> trailing parameter type of the caller is a reference type >>>>>>>>>>>> identical to >>>>>>>>>>>> or assignable to the trailing parameter type of the >>>>>>>>>>>> adapter, the >>>>>>>>>>>> arguments and return values are converted pairwise, as if by >>>>>>>>>>>> asType on a >>>>>>>>>>>> fixed arity method handle. >>>>>>>>>>>> >>>>>>>>>>>> Otherwise, the arities differ, or the adapter's trailing >>>>>>>>>>>> parameter >>>>>>>>>>>> type >>>>>>>>>>>> is not assignable from the corresponding caller type. In this >>>>>>>>>>>> case, the >>>>>>>>>>>> adapter replaces all trailing arguments from the original >>>>>>>>>>>> trailing >>>>>>>>>>>> argument position onward, by a new array of type arrayType, >>>>>>>>>>>> whose >>>>>>>>>>>> elements comprise (in order) the replaced arguments." >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> mlvm-dev mailing list >>>>>>>>>>>> mlvm-dev at openjdk.java.net >>>>>>>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> mlvm-dev mailing list >>>>>>>>>>> mlvm-dev at openjdk.java.net >>>>>>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> mlvm-dev mailing list >>>>>>>>>> mlvm-dev at openjdk.java.net >>>>>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> mlvm-dev mailing list >>>>>>>>> mlvm-dev at openjdk.java.net >>>>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> mlvm-dev mailing list >>>>>>>> mlvm-dev at openjdk.java.net >>>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>>>> >>>>>>> _______________________________________________ >>>>>>> mlvm-dev mailing list >>>>>>> mlvm-dev at openjdk.java.net >>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>> >>> > From scolebourne at joda.org Wed Mar 12 12:29:47 2014 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 12 Mar 2014 12:29:47 +0000 Subject: RFR: JDK-8033662 DateTimeFormatter parsing ignores withZone() Message-ID: This is a request for review of this bug: https://bugs.openjdk.java.net/browse/JDK-8033662 and the duplicate: https://bugs.openjdk.java.net/browse/JDK-8033659 The javadoc of the method java.time.format.DateTimeFormatter::withZone says: "If no zone has been parsed, then this override zone will be included in the result of the parse where it can be used to build instants and date-times." However, the implementation doesn't obey this. This is a very unfortunate bug that makes some date-time parsing a lot harder. A second related bug in an egde case - not properly handling a ChronoZonedDateTime from TemporalField.resolve - is also tested for and fixed. Proposed patch: https://gist.github.com/jodastephen/9505761 The patch includes no spec changes. The patch includes new and refactored TCK tests. The new tests for withZone() and withChronology() are based on the spec. I need a reviewer and a committer please. thanks From petr.pchelko at oracle.com Wed Mar 12 13:23:08 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 12 Mar 2014 17:23:08 +0400 Subject: JDK 9 RFR of JDK-8037174: Fix serial lint warnings in sun.applet In-Reply-To: <53200CC7.9070102@oracle.com> References: <531FFC49.7030000@oracle.com> <53200CC7.9070102@oracle.com> Message-ID: Hello, Joe. The fix looks good. > assuming of course they don't leak into the serialized stream of a supported type. These classes are related to the AppletViewer, so they should not. With best regards. Petr. On 12.03.2014, at 11:29, Alan Bateman wrote: > > cc'ing awt-dev as this where the Applet code is maintained. > > In any case, the suppressing of serial warnings looks okay to me, assuming of course they don't leak into the serialized stream of a supported type. > > -Alan. > > On 12/03/2014 06:18, Joe Darcy wrote: >> Hello, >> >> Please review the patch below to address >> >> JDK-8037174: Fix serial lint warnings in sun.applet >> http://cr.openjdk.java.net/~darcy/8037174.0/ >> >> Thanks, >> >> -Joe >> >> --- old/src/share/classes/sun/applet/AppletEvent.java 2014-03-11 23:15:49.000000000 -0700 >> +++ new/src/share/classes/sun/applet/AppletEvent.java 2014-03-11 23:15:49.000000000 -0700 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1997, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 1997, 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 >> @@ -33,7 +33,7 @@ >> * >> * @author Sunita Mani >> */ >> - >> + at SuppressWarnings("serial") // JDK-implementation class >> public class AppletEvent extends EventObject { >> >> private Object arg; >> --- old/src/share/classes/sun/applet/AppletIOException.java 2014-03-11 23:15:49.000000000 -0700 >> +++ new/src/share/classes/sun/applet/AppletIOException.java 2014-03-11 23:15:49.000000000 -0700 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1996, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 1996, 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 >> @@ -32,6 +32,7 @@ >> * >> * @author Koji Uno >> */ >> + at SuppressWarnings("serial") // JDK implementation class >> public >> class AppletIOException extends IOException { >> private String key = null; >> --- old/src/share/classes/sun/applet/AppletIllegalArgumentException.java 2014-03-11 23:15:50.000000000 -0700 >> +++ new/src/share/classes/sun/applet/AppletIllegalArgumentException.java 2014-03-11 23:15:50.000000000 -0700 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1996, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 1996, 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 >> @@ -30,6 +30,7 @@ >> * >> * @author Arthur van Hoff >> */ >> + at SuppressWarnings("serial") // JDK implementation class >> public >> class AppletIllegalArgumentException extends IllegalArgumentException { >> private String key = null; >> --- old/src/share/classes/sun/applet/AppletPanel.java 2014-03-11 23:15:50.000000000 -0700 >> +++ new/src/share/classes/sun/applet/AppletPanel.java 2014-03-11 23:15:50.000000000 -0700 >> @@ -62,6 +62,7 @@ >> * >> * @author Arthur van Hoff >> */ >> + at SuppressWarnings("serial") // JDK implementation class >> public >> abstract class AppletPanel extends Panel implements AppletStub, Runnable { >> >> --- old/src/share/classes/sun/applet/AppletProps.java 2014-03-11 23:15:51.000000000 -0700 >> +++ new/src/share/classes/sun/applet/AppletProps.java 2014-03-11 23:15:51.000000000 -0700 >> @@ -37,6 +37,7 @@ >> >> import sun.security.action.*; >> >> + at SuppressWarnings("serial") // JDK implementation class >> class AppletProps extends Frame { >> >> TextField proxyHost; >> @@ -194,7 +195,7 @@ >> >> /* 4066432 */ >> /* Dialog class to display property-related errors to user */ >> - >> + at SuppressWarnings("serial") // JDK implementation class >> class AppletPropsErrorDialog extends Dialog { >> public AppletPropsErrorDialog(Frame parent, String title, String message, >> String buttonText) { >> --- old/src/share/classes/sun/applet/AppletSecurityException.java 2014-03-11 23:15:51.000000000 -0700 >> +++ new/src/share/classes/sun/applet/AppletSecurityException.java 2014-03-11 23:15:51.000000000 -0700 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1995, 1998, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 1995, 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 >> @@ -30,6 +30,7 @@ >> * >> * @author Arthur van Hoff >> */ >> + at SuppressWarnings("serial") // JDK-implementation class >> public >> class AppletSecurityException extends SecurityException { >> private String key = null; >> --- old/src/share/classes/sun/applet/AppletViewer.java 2014-03-11 23:15:52.000000000 -0700 >> +++ new/src/share/classes/sun/applet/AppletViewer.java 2014-03-11 23:15:52.000000000 -0700 >> @@ -46,6 +46,7 @@ >> /** >> * A frame to show the applet tag in. >> */ >> + at SuppressWarnings("serial") // JDK-implementation class >> class TextFrame extends Frame { >> >> /** >> @@ -115,6 +116,7 @@ >> * (The document named appletviewertags.html in the JDK's docs/tooldocs directory, >> * once the JDK docs have been installed.) >> */ >> + at SuppressWarnings("serial") // JDK implementation class >> public class AppletViewer extends Frame implements AppletContext, >> Printable { >> >> --- old/src/share/classes/sun/applet/Main.java 2014-03-11 23:15:52.000000000 -0700 >> +++ new/src/share/classes/sun/applet/Main.java 2014-03-11 23:15:52.000000000 -0700 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 1999, 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 >> @@ -512,6 +512,7 @@ >> return amh.getMessage(key, arg0, arg1, arg2); >> } >> >> + @SuppressWarnings("serial") // JDK implementation class >> class ParseException extends RuntimeException >> { >> public ParseException(String msg) { >> > From roger.riggs at oracle.com Wed Mar 12 13:54:45 2014 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 12 Mar 2014 09:54:45 -0400 Subject: RFR: JDK-8036818: DateTimeFormatter withResolverFields() fails to accept null In-Reply-To: References: Message-ID: <53206725.6040901@oracle.com> Looks fine, (not a reviewer). I can sponsor the fix when reviewed. Thanks, Roger On 3/12/2014 6:45 AM, Stephen Colebourne wrote: > This is a request for review of this bug: > https://bugs.openjdk.java.net/browse/JDK-8036818 > > The method DateTimeFormatter withResolverFields() is supposed to > accept null. This is to allow a coy of the formatter to be returned > reset to the original state of having no resolver fields. The docs > say: > "@param resolverFields the new set of resolver fields, null if no fields" > which was written to indicate that resetting to null is permitted. > > The fix is to check for null and return a copy of the formatter. Note > that there are two variations of the method which need fixing. > > Proposed patch: > https://gist.github.com/jodastephen/9395197 > The patch includes no spec changes. > The patch fixes the broken TCK tests. > > I need a reviewer and a committer please. > thanks > Stephen From jason_mehrens at hotmail.com Wed Mar 12 14:06:16 2014 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Wed, 12 Mar 2014 09:06:16 -0500 Subject: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty In-Reply-To: <4DC7C9B0-43F2-4FFF-A8D6-CFD1B54ED158@oracle.com> References: <0541A3EA-A2A5-4977-8054-4EDB28366216@oracle.com>, , <318A3363-C4F6-42D5-99CD-DB6D00766B0C@oracle.com>, , <8FD1E74E-B433-475E-8DF6-3CB7126698AC@oracle.com>, , <4DC7C9B0-43F2-4FFF-A8D6-CFD1B54ED158@oracle.com> Message-ID: Mike, In the constructor do you think you should skip the call to isEmpty and just check the length of toArray? Seems like since the implementation of the given collection is unknown it is probably best to perform as little interaction with it as possible. Also it would be possible for isEmpty to return false followed by toArray returning a zero length array that is different from cached copies. Jason > Subject: Re: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty > From: mike.duigou at oracle.com > Date: Tue, 11 Mar 2014 18:18:26 -0700 > To: martinrb at google.com > CC: core-libs-dev at openjdk.java.net > > > On Mar 11 2014, at 17:42 , Martin Buchholz wrote: > > > I'm hoping y'all have evidence that empty ArrayLists are common in the wild. > Yes, certainly. From the original proposal: > > [This change] based upon analysis that shows that in large applications as much as 10% of maps and lists are initialized but never receive any entries. A smaller number spend a large proportion of their lifetime empty. We've found similar results across other workloads as well. > > > It is curious that empty lists grow immediately to 10, while ArrayList with capacity 1 grows to 2, then 3... Some people might think that a bug. > Yes, that's unfortunate. I've made another version that uses a second sentinel for the default sized but empty case. > > Now I want to reduce the ensureCapacity reallocations! It seems like insane churn to replace the arrays that frequently. > > There are more   changes that need to be reverted. > > Else looks good. > > - * More formally, returns the lowest index i such that > > - * (o==null ? get(i)==null : o.equals(get(i))), > > + * More formally, returns the lowest index {@code i} such that > > + * {@code (o==null ? get(i)==null : o.equals(get(i)))}, > > Corrected. Thank you. > > http://cr.openjdk.java.net/~mduigou/JDK-8035584/2/webrev/ > > > Mike > > > > > > > > > On Tue, Mar 11, 2014 at 5:20 PM, Mike Duigou wrote: > > I've actually always used scp. :-) > > > > Since I accepted all of your changes as suggested and had no other changes I was just going to go ahead and push once testing was done. > > > > I've now prepared a revised webrev and can still accept feedback. > > > > http://cr.openjdk.java.net/~mduigou/JDK-8035584/1/webrev/ > > > > (Note: The webrev also contains https://bugs.openjdk.java.net/browse/JDK-8037097 since I am testing/pushing the two issues together.) > > > > Mike > > > > On Mar 11 2014, at 16:42 , Martin Buchholz wrote: > > > >> I don't see the updated webrev. Maybe you also fell victim to "rsync to cr no longer working"? > >> > >> > >> On Tue, Mar 11, 2014 at 4:34 PM, Mike Duigou wrote: > >> > >> On Feb 21 2014, at 14:56 , Martin Buchholz wrote: > >> > >>> You should do -> code conversion separately, and do it pervasively across the entire JDK. > >> > >> From your lips to God's ears.... I keep suggesting this along with a restyle to official style every time we create new repos. Seems unlikely unfortunately as it makes backports harder. > >> > >>> This is not right. > >>> + * {@code (o==null ? get(i)==null : o.equals(get(i)))} > >> > >> Corrected. > >> > >>> You accidentally deleted a stray space here? > >>> > >>> - this.elementData = EMPTY_ELEMENTDATA; > >>> + this.elementData = EMPTY_ELEMENTDATA; > >> > >> Corrected. > >> > >>> public ArrayList(int initialCapacity) { > >>> - super(); > >>> if (initialCapacity < 0) > >>> throw new IllegalArgumentException("Illegal Capacity: "+ > >>> initialCapacity); > >>> - this.elementData = new Object[initialCapacity]; > >>> + this.elementData = (initialCapacity > 0) > >>> + ? new Object[initialCapacity] > >>> + : EMPTY_ELEMENTDATA; > >>> } > >>> > >>> When optimizing for special cases, we should try very hard minimize overhead in the common case. In the above, we now have two branches in the common case. Instead, > >>> > >>> if (initialCapacity > 0) this.elementData = new Object[initialCapacity]; > >>> else if (initialCapacity == 0) this.elementData = EMPTY_ELEMENTDATA; > >>> else barf > >> > >> Corrected. > >> > >> Thanks as always for the feedback. > >> > >> Mike > >> > >>> > >>> > >>> > >>> On Fri, Feb 21, 2014 at 2:41 PM, Mike Duigou wrote: > >>> Hello all; > >>> > >>> This changeset consists of two small performance improvements for ArrayList. Both are related to the lazy initialization introduced in JDK-8011200. > >>> > >>> The first change is in the ArrayList(int capacity) constructor and forces lazy initialization if the requested capacity is zero. It's been observed that in cases where zero capacity is requested that it is very likely that the list never receives any elements. For these cases we permanently avoid the allocation of an element array. > >>> > >>> The second change, noticed by Gustav ?kesson, involves the ArrayList(Collection c) constructor. If c is an empty collection then there is no reason to inflate the backing array for the ArrayList. > >>> > >>> http://cr.openjdk.java.net/~mduigou/JDK-8035584/0/webrev/ > >>> > >>> I also took the opportunity to the -> {@code } conversion for the javadoc. > >>> > >>> Enjoy! > >>> > >>> Mike > >>> > >> > >> > > > > > From chris.hegarty at oracle.com Wed Mar 12 14:27:49 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 12 Mar 2014 14:27:49 +0000 Subject: RFR: JDK-8036818: DateTimeFormatter withResolverFields() fails to accept null In-Reply-To: <53206725.6040901@oracle.com> References: <53206725.6040901@oracle.com> Message-ID: <53206EE5.1080605@oracle.com> The change look ok to me too. There is a change in behavior here, but I don't expect it to be surprising ( no NPE where there once was ), so I think it should be fine for 8u-dev also. The TCK test changes however, may not be suitable for 8u. Though I'm not sure how these tests feed from the OpenJDK repo into the actual TCK. -Chris. On 12/03/14 13:54, roger riggs wrote: > Looks fine, (not a reviewer). > > I can sponsor the fix when reviewed. > > Thanks, Roger > > On 3/12/2014 6:45 AM, Stephen Colebourne wrote: >> This is a request for review of this bug: >> https://bugs.openjdk.java.net/browse/JDK-8036818 >> >> The method DateTimeFormatter withResolverFields() is supposed to >> accept null. This is to allow a coy of the formatter to be returned >> reset to the original state of having no resolver fields. The docs >> say: >> "@param resolverFields the new set of resolver fields, null if no fields" >> which was written to indicate that resetting to null is permitted. >> >> The fix is to check for null and return a copy of the formatter. Note >> that there are two variations of the method which need fixing. >> >> Proposed patch: >> https://gist.github.com/jodastephen/9395197 >> The patch includes no spec changes. >> The patch fixes the broken TCK tests. >> >> I need a reviewer and a committer please. >> thanks >> Stephen > From scolebourne at joda.org Wed Mar 12 14:32:59 2014 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 12 Mar 2014 14:32:59 +0000 Subject: RFR: JDK-8036818: DateTimeFormatter withResolverFields() fails to accept null In-Reply-To: <53206EE5.1080605@oracle.com> References: <53206725.6040901@oracle.com> <53206EE5.1080605@oracle.com> Message-ID: I am happy for the tests to be located in the test.java.time package rather than the tck.java.time package when backported. However, the original (broken) TCK tests will need to be removed in that scenario. I also do not know exactly how the TCK tests feed into the actual TCK at this point. Stephen On 12 March 2014 14:27, Chris Hegarty wrote: > The change look ok to me too. > > There is a change in behavior here, but I don't expect it to be surprising ( > no NPE where there once was ), so I think it should be fine for 8u-dev also. > > The TCK test changes however, may not be suitable for 8u. Though I'm not > sure how these tests feed from the OpenJDK repo into the actual TCK. > > -Chris. > > On 12/03/14 13:54, roger riggs wrote: >> >> Looks fine, (not a reviewer). >> >> I can sponsor the fix when reviewed. >> >> Thanks, Roger >> >> >> On 3/12/2014 6:45 AM, Stephen Colebourne wrote: >>> >>> This is a request for review of this bug: >>> https://bugs.openjdk.java.net/browse/JDK-8036818 >>> >>> The method DateTimeFormatter withResolverFields() is supposed to >>> accept null. This is to allow a coy of the formatter to be returned >>> reset to the original state of having no resolver fields. The docs >>> say: >>> "@param resolverFields the new set of resolver fields, null if no fields" >>> which was written to indicate that resetting to null is permitted. >>> >>> The fix is to check for null and return a copy of the formatter. Note >>> that there are two variations of the method which need fixing. >>> >>> Proposed patch: >>> https://gist.github.com/jodastephen/9395197 >>> The patch includes no spec changes. >>> The patch fixes the broken TCK tests. >>> >>> I need a reviewer and a committer please. >>> thanks >>> Stephen >> >> > From martinrb at google.com Wed Mar 12 14:43:56 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 12 Mar 2014 07:43:56 -0700 Subject: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty In-Reply-To: References: <0541A3EA-A2A5-4977-8054-4EDB28366216@oracle.com> <318A3363-C4F6-42D5-99CD-DB6D00766B0C@oracle.com> <8FD1E74E-B433-475E-8DF6-3CB7126698AC@oracle.com> <4DC7C9B0-43F2-4FFF-A8D6-CFD1B54ED158@oracle.com> Message-ID: Jason is right. IIRC, the atomicity of toArray is a reason for the ArrayList(Collection) constructor being written the way it is. On Wed, Mar 12, 2014 at 7:06 AM, Jason Mehrens wrote: > Mike, > > In the constructor do you think you should skip the call to isEmpty and > just check the length of toArray? Seems like since the implementation of > the given collection is unknown it is probably best to perform as little > interaction with it as possible. Also it would be possible for isEmpty to > return false followed by toArray returning a zero length array that is > different from cached copies. > > Jason > > > Subject: Re: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c > is empty > > From: mike.duigou at oracle.com > > Date: Tue, 11 Mar 2014 18:18:26 -0700 > > To: martinrb at google.com > > CC: core-libs-dev at openjdk.java.net > > > > > > > On Mar 11 2014, at 17:42 , Martin Buchholz wrote: > > > > > I'm hoping y'all have evidence that empty ArrayLists are common in the > wild. > > Yes, certainly. From the original proposal: > > > [This change] based upon analysis that shows that in large > applications as much as 10% of maps and lists are initialized but never > receive any entries. A smaller number spend a large proportion of their > lifetime empty. We've found similar results across other workloads as well. > > > > > It is curious that empty lists grow immediately to 10, while ArrayList > with capacity 1 grows to 2, then 3... Some people might think that a bug. > > Yes, that's unfortunate. I've made another version that uses a second > sentinel for the default sized but empty case. > > > > Now I want to reduce the ensureCapacity reallocations! It seems like > insane churn to replace the arrays that frequently. > > > There are more   changes that need to be reverted. > > > Else looks good. > > > - * More formally, returns the lowest index i such that > > > - * > (o==null ? get(i)==null : o.equals(get(i))), > > > + * More formally, returns the lowest index {@code i} such that > > > + * {@code > (o==null ? get(i)==null : o.equals(get(i)))}, > > > > Corrected. Thank you. > > > > http://cr.openjdk.java.net/~mduigou/JDK-8035584/2/webrev/ > > > > > > Mike > > > > > > > > > > > > > > > On Tue, Mar 11, 2014 at 5:20 PM, Mike Duigou > wrote: > > > I've actually always used scp. :-) > > > > > > Since I accepted all of your changes as suggested and had no other > changes I was just going to go ahead and push once testing was done. > > > > > > I've now prepared a revised webrev and can still accept feedback. > > > > > > http://cr.openjdk.java.net/~mduigou/JDK-8035584/1/webrev/ > > > > > > (Note: The webrev also contains > https://bugs.openjdk.java.net/browse/JDK-8037097 since I am > testing/pushing the two issues together.) > > > > > > Mike > > > > > > On Mar 11 2014, at 16:42 , Martin Buchholz > wrote: > > > > > >> I don't see the updated webrev. Maybe you also fell victim to "rsync > to cr no longer working"? > > >> > > >> > > >> On Tue, Mar 11, 2014 at 4:34 PM, Mike Duigou > wrote: > > >> > > >> On Feb 21 2014, at 14:56 , Martin Buchholz > wrote: > > >> > > >>> You should do -> code conversion separately, and do it > pervasively across the entire JDK. > > >> > > >> From your lips to God's ears.... I keep suggesting this along with a > restyle to official style every time we create new repos. Seems unlikely > unfortunately as it makes backports harder. > > >> > > >>> This is not right. > > >>> + * {@code > (o==null ? get(i)==null : o.equals(get(i)))} > > >> > > >> Corrected. > > >> > > >>> You accidentally deleted a stray space here? > > >>> > > >>> - this.elementData = EMPTY_ELEMENTDATA; > > >>> + this.elementData = EMPTY_ELEMENTDATA; > > >> > > >> Corrected. > > >> > > >>> public ArrayList(int initialCapacity) { > > >>> - super(); > > >>> if (initialCapacity < 0) > > >>> throw new IllegalArgumentException("Illegal Capacity: "+ > > >>> initialCapacity); > > >>> - this.elementData = new Object[initialCapacity]; > > >>> + this.elementData = (initialCapacity > 0) > > >>> + ? new Object[initialCapacity] > > >>> + : EMPTY_ELEMENTDATA; > > >>> } > > >>> > > >>> When optimizing for special cases, we should try very hard minimize > overhead in the common case. In the above, we now have two branches in the > common case. Instead, > > >>> > > >>> if (initialCapacity > 0) this.elementData = new > Object[initialCapacity]; > > >>> else if (initialCapacity == 0) this.elementData = EMPTY_ELEMENTDATA; > > >>> else barf > > >> > > >> Corrected. > > >> > > >> Thanks as always for the feedback. > > >> > > >> Mike > > >> > > >>> > > >>> > > >>> > > >>> On Fri, Feb 21, 2014 at 2:41 PM, Mike Duigou > wrote: > > >>> Hello all; > > >>> > > >>> This changeset consists of two small performance improvements for > ArrayList. Both are related to the lazy initialization introduced in > JDK-8011200. > > >>> > > >>> The first change is in the ArrayList(int capacity) constructor and > forces lazy initialization if the requested capacity is zero. It's been > observed that in cases where zero capacity is requested that it is very > likely that the list never receives any elements. For these cases we > permanently avoid the allocation of an element array. > > >>> > > >>> The second change, noticed by Gustav ?kesson, involves the > ArrayList(Collection c) constructor. If c is an empty collection then there > is no reason to inflate the backing array for the ArrayList. > > >>> > > >>> http://cr.openjdk.java.net/~mduigou/JDK-8035584/0/webrev/ > > >>> > > >>> I also took the opportunity to the -> {@code } conversion > for the javadoc. > > >>> > > >>> Enjoy! > > >>> > > >>> Mike > > >>> > > >> > > >> > > > > > > > > > From aleksej.efimov at oracle.com Wed Mar 12 15:05:28 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Wed, 12 Mar 2014 19:05:28 +0400 Subject: RFR: 8037012: (tz) Support tzdata2014a Message-ID: <532077B8.3030605@oracle.com> Hello, Can I have a review for a tzdata2014a [1] integration to JDK9: http://cr.openjdk.java.net/~aefimov/8037012/9/webrev.00 The following test sets were executed on the build with latest tzdata: test/sun/util/calendar test/java/util/Calendar test/sun/util/resources/TimeZone test/sun/util/calendar test/java/util/TimeZone test/java/time test/java/util/Formatter test/closed/java/util/Calendar test/closed/java/util/TimeZone One test failure was observed - see the bug report for details: [2]. The review for this test failure fix will be sent in a few moments. Other tests passes. Thank you, Aleksej [1] https://bugs.openjdk.java.net/browse/JDK-8037012 [2] https://bugs.openjdk.java.net/browse/JDK-8037180 From aleksej.efimov at oracle.com Wed Mar 12 15:06:48 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Wed, 12 Mar 2014 19:06:48 +0400 Subject: RFR: 8037180: [TEST_BUG] test/sun/util/calendar/zi/Zoneinfo.java incorrectly calculates raw GMT offset change time Message-ID: <53207808.4090107@oracle.com> Hello, Can I have a review for a 'test/sun/util/calendar/zi/Zoneinfo.java' test bug failure [1] related to the latest tzdata2014a integration [2]. The test failure message: Asia/Istanbul : Asia/Istanbul offset=7200000,dstSavings=3600000,useDaylight=true,transitions=171,offsets=5,checksum=-508379603,gmtChanged=false [NG]offset=7200000,dstSavings=3600000,useDaylight=true,transitions=171,offsets=5,checksum=-508379603,gmtChanged=true ----------System.err:(13/732)---------- java.lang.RuntimeException: FAILED: Asia/Istanbul at TestZoneInfo310.main(TestZoneInfo310.java:170) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:484) at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94) at java.lang.Thread.run(Thread.java:744) This failure caused by the following entry in test tzdata files: Zone Europe/Istanbul 1:55:52 - LMT 1880 1:56:56 - IMT 1910 Oct # Istanbul Mean Time? 2:00 Turkey EE%sT 1978 Oct 15 3:00 Turkey TR%sT 1985 Apr 20 # Turkey Time 2:00 Turkey EE%sT 2007 2:00 EU EE%sT 2011 Mar 27 1:00u 2:00 - EET 2011 Mar 28 1:00u 2:00 EU EE%sT 2014 Mar 30 1:00u 2:00 - EET 2014 Mar 31 1:00u 2:00 EU EE%sT The raw GMT offset here is constant=2:00 and not changed since 1985 Apr 20. But the test code 'test/sun/util/calendar/zi' shows that there will be a future raw GMT offset change. The following fix resolves this problem: http://cr.openjdk.java.net/~aefimov/8037180/9/webrev.00/ -Aleksej [1] https://bugs.openjdk.java.net/browse/JDK-8037180 [2] https://bugs.openjdk.java.net/browse/JDK-8037012 From martinrb at google.com Wed Mar 12 15:51:39 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 12 Mar 2014 08:51:39 -0700 Subject: RFR [8034262] Test java/lang/ProcessBuilder/CloseRace.java fails In-Reply-To: <53201CA3.6050801@oracle.com> References: <531F0084.80703@oracle.com> <531F5006.5070303@oracle.com> <53201CA3.6050801@oracle.com> Message-ID: Latest webrev looks good to me. On Wed, Mar 12, 2014 at 1:36 AM, Ivan Gerasimov wrote: > Thanks Martin > > > On 12.03.2014 2:45, Martin Buchholz wrote: > > Well done! > > Not checking for interrupt in the loop is clearly my bug. > > dumpAllStacks looks like a very useful utility method (basically what > jstack does). It feels like we're reinventing the wheel here, but I'm not > sure. > > > jstack calls the hotspot-specific code to dump the stack traces, but I > used the jdk-level routine. > The dumpAllStacks() function has already done its job, so I could probably > just remove it. > Though it may be better to keep it just in case. > > > Instead of "break theLoop" I would have simply returned from the method. > > > OK, did that. Here's the updated webrev: > > http://cr.openjdk.java.net/~igerasim/8034262/2/webrev/ > > Sincerely yours, > Ivan > > > > On Tue, Mar 11, 2014 at 11:03 AM, Ivan Gerasimov < > ivan.gerasimov at oracle.com> wrote: > >> Thank you Martin! >> >> >> On 11.03.2014 19:04, Martin Buchholz wrote: >> >> Thanks for working on my brittle racy tests. >> >> Adding a latch as you did is a good improvement, although there's a >> good chance the real problem lies elsewhere. >> >> My standard name for such latches is "threadsStarted", which I think is >> a bit better than "startedSignal". Please rename. >> >> No problem, renamed. >> >> >> My simple calls to Thread.join are too optimistic. >> More likely to be helpful is code like (pseudocode follows): >> >> thread.join(10, SECONDS); >> if (thread.isAlive()) { >> dumpAllStacks(); >> fail(); >> } >> >> Yes, it was a good idea to do that! >> After implementing your suggestion, I could finally reproduce the failure. >> The OpenLoop child thread was spinning in the do-while loop, waiting for >> 'count of fds in use' to become 3. >> The simple solution is to add a check weather the current thread is >> interrupted to this and other loops. >> >> Would you please take a look at the updated webrev? >> http://cr.openjdk.java.net/~igerasim/8034262/1/webrev/ >> >> Sincerely yours, >> Ivan >> >> >> That's more work to implement - optional. >> >> >> On Tue, Mar 11, 2014 at 5:24 AM, Ivan Gerasimov < >> ivan.gerasimov at oracle.com> wrote: >> >>> Hello everybody! >>> >>> The test java/lang/ProcessBuilder/CloseRace.java was reported to >>> intermittently fail. >>> The test timed out, which should mean that at least one of the child >>> threads was never interrupted. >>> >>> I couldn't reproduce the failure, but I suspect it might happen due to >>> call to interrupt() before the child thread became alive (I'm not really >>> sure if it's possible to be non-alive after call to start()). >>> The fix is to explicitly synchronize children with the parent. >>> >>> Would you please help review the fix? >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8034262 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8034262/0/webrev/ >>> >>> Sincerely yours, >>> Ivan >>> >> >> >> > > From mark.sheppard at oracle.com Wed Mar 12 17:18:14 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Wed, 12 Mar 2014 17:18:14 +0000 Subject: RFR: JDK-8036603 - Check jdk/src/windows/native/java/lang/ProcessEnvironment_md.c for JNI pending exceptions In-Reply-To: <531A4683.3070606@oracle.com> References: <531A390C.3020802@oracle.com> <531A3B74.2060205@oracle.com> <531A4683.3070606@oracle.com> Message-ID: <532096D6.1060602@oracle.com> Hi an updated webrev as per suggested changes http://cr.openjdk.java.net/~msheppar/8036603/webrev.01/ regards Mark On 07/03/2014 22:21, Mark Sheppard wrote: > Thanks Alan and Mandy for the feedback > > I make the amendments as you both suggest > > regards > Mark > > On 07/03/2014 21:34, Alan Bateman wrote: >> On 07/03/2014 21:24, Mark Sheppard wrote: >>> >>> Hi, >>> Please oblige and review the changes >>> http://cr.openjdk.java.net/~msheppar/8036603/webrev/ >>> >>> which address the issues raised in >>> https://bugs.openjdk.java.net/browse/JDK-8036603 >>> >>> summary >>> JNU_ClassString extracted as parameter to GetMethodID and NewObject >>> calls >>> and NUL_CHECKed >> Is it necessary to call JNU_ClassString twice? (just wondering if >> L65-66 can be removed). One suggestion for class_for_method is to >> rename it to str_class as it might be a bit clearer. >> >> -Alan. > From Alan.Bateman at oracle.com Wed Mar 12 17:24:37 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Mar 2014 17:24:37 +0000 Subject: RFR: JDK-8036603 - Check jdk/src/windows/native/java/lang/ProcessEnvironment_md.c for JNI pending exceptions In-Reply-To: <532096D6.1060602@oracle.com> References: <531A390C.3020802@oracle.com> <531A3B74.2060205@oracle.com> <531A4683.3070606@oracle.com> <532096D6.1060602@oracle.com> Message-ID: <53209855.4080405@oracle.com> On 12/03/2014 17:18, Mark Sheppard wrote: > Hi > an updated webrev as per suggested changes > http://cr.openjdk.java.net/~msheppar/8036603/webrev.01/ This looks good. One other thing in this code (pre-dates your patch but your patch makes it a bit more obvious) is that if NewByteArray fails then we don't call FreeEnvironmentStringsA to free the environment. -Alan From mark.sheppard at oracle.com Wed Mar 12 17:39:05 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Wed, 12 Mar 2014 17:39:05 +0000 Subject: RFR: JDK-8035870 - Check jdk/src/windows/native/java/io/WinNTFileSystem_md.c for JNI pending exceptions Message-ID: <53209BB9.602@oracle.com> Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8035870/webrev/ which address the issues raised in https://bugs.openjdk.java.net/browse/JDK-8035870 summary: checks to return values from malloc added with appropriate JNU_ThrowOutOfMemoryError added regards Mark From mark.sheppard at oracle.com Wed Mar 12 17:47:56 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Wed, 12 Mar 2014 17:47:56 +0000 Subject: RFR: JDK-8036603 - Check jdk/src/windows/native/java/lang/ProcessEnvironment_md.c for JNI pending exceptions In-Reply-To: <53209855.4080405@oracle.com> References: <531A390C.3020802@oracle.com> <531A3B74.2060205@oracle.com> <531A4683.3070606@oracle.com> <532096D6.1060602@oracle.com> <53209855.4080405@oracle.com> Message-ID: <53209DCC.9060906@oracle.com> Hi Alan, so L61 should be if ((bytes = (*env)->NewByteArray(env, i)) == NULL) { FreeEnvironmentStringsA(blockA); return NULL; } regards Mark On 12/03/2014 17:24, Alan Bateman wrote: > On 12/03/2014 17:18, Mark Sheppard wrote: >> Hi >> an updated webrev as per suggested changes >> http://cr.openjdk.java.net/~msheppar/8036603/webrev.01/ > This looks good. One other thing in this code (pre-dates your patch > but your patch makes it a bit more obvious) is that if NewByteArray > fails then we don't call FreeEnvironmentStringsA to free the environment. > > -Alan From daniel.fuchs at oracle.com Wed Mar 12 18:27:28 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 12 Mar 2014 19:27:28 +0100 Subject: RFR: 8036916 - Deprecation warnings in LogManager Message-ID: <5320A710.2020709@oracle.com> Hi, Please find below a trivial fix for [1]: 8036916: Deprecation warnings in LogManager [1] https://bugs.openjdk.java.net/browse/JDK-8036916 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8036916/webrev.00/ best regards, -- daniel From mandy.chung at oracle.com Wed Mar 12 18:34:08 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 12 Mar 2014 11:34:08 -0700 Subject: RFR: 8036916 - Deprecation warnings in LogManager In-Reply-To: <5320A710.2020709@oracle.com> References: <5320A710.2020709@oracle.com> Message-ID: <5320A8A0.3050009@oracle.com> On 3/12/2014 11:27 AM, Daniel Fuchs wrote: > Hi, > > Please find below a trivial fix for [1]: > > 8036916: Deprecation warnings in LogManager > [1] https://bugs.openjdk.java.net/browse/JDK-8036916 > > webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8036916/webrev.00/ Oops.. I didn't catch the typo in the @SuppressWarnings previously. Looks okay. Could isRootOrGlobal do return logger == getGlobalLogger() || .... to avoid another @SuppressWarning? Really minor. Mandy From daniel.fuchs at oracle.com Wed Mar 12 18:51:16 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 12 Mar 2014 19:51:16 +0100 Subject: RFR: 8036916 - Deprecation warnings in LogManager In-Reply-To: <5320A8A0.3050009@oracle.com> References: <5320A710.2020709@oracle.com> <5320A8A0.3050009@oracle.com> Message-ID: <5320ACA4.2050908@oracle.com> On 3/12/14 7:34 PM, Mandy Chung wrote: > > On 3/12/2014 11:27 AM, Daniel Fuchs wrote: >> Hi, >> >> Please find below a trivial fix for [1]: >> >> 8036916: Deprecation warnings in LogManager >> [1] https://bugs.openjdk.java.net/browse/JDK-8036916 >> >> webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8036916/webrev.00/ > > Oops.. I didn't catch the typo in the @SuppressWarnings previously. > > Looks okay. Could isRootOrGlobal do return logger == getGlobalLogger() > || .... to avoid another @SuppressWarning? Really minor. Hi Mandy, Oh - of course - we don't need the new method actually. I was not thinking right: http://cr.openjdk.java.net/~dfuchs/webrev_8036916/webrev.01/ best regards, -- daniel > > Mandy > From mandy.chung at oracle.com Wed Mar 12 18:56:35 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 12 Mar 2014 11:56:35 -0700 Subject: RFR: 8036916 - Deprecation warnings in LogManager In-Reply-To: <5320ACA4.2050908@oracle.com> References: <5320A710.2020709@oracle.com> <5320A8A0.3050009@oracle.com> <5320ACA4.2050908@oracle.com> Message-ID: <5320ADE3.5010502@oracle.com> On 3/12/2014 11:51 AM, Daniel Fuchs wrote: > Hi Mandy, > > Oh - of course - we don't need the new method actually. I was not > thinking right: > > http://cr.openjdk.java.net/~dfuchs/webrev_8036916/webrev.01/ Thumbs up. Mandy From Alan.Bateman at oracle.com Wed Mar 12 19:10:06 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Mar 2014 19:10:06 +0000 Subject: RFR: JDK-8036603 - Check jdk/src/windows/native/java/lang/ProcessEnvironment_md.c for JNI pending exceptions In-Reply-To: <53209DCC.9060906@oracle.com> References: <531A390C.3020802@oracle.com> <531A3B74.2060205@oracle.com> <531A4683.3070606@oracle.com> <532096D6.1060602@oracle.com> <53209855.4080405@oracle.com> <53209DCC.9060906@oracle.com> Message-ID: <5320B10E.5090303@oracle.com> On 12/03/2014 17:47, Mark Sheppard wrote: > Hi Alan, > so L61 should be > if ((bytes = (*env)->NewByteArray(env, i)) == NULL) { > FreeEnvironmentStringsA(blockA); > return NULL; > } That would be good - thanks! -Alan From Alan.Bateman at oracle.com Wed Mar 12 19:21:04 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Mar 2014 19:21:04 +0000 Subject: RFR: JDK-8035870 - Check jdk/src/windows/native/java/io/WinNTFileSystem_md.c for JNI pending exceptions In-Reply-To: <53209BB9.602@oracle.com> References: <53209BB9.602@oracle.com> Message-ID: <5320B3A0.6050402@oracle.com> On 12/03/2014 17:39, Mark Sheppard wrote: > > Hi > please oblige and review the following changes > http://cr.openjdk.java.net/~msheppar/8035870/webrev/ > This looks okay me. It looks like the errno=ENOMEM at line 638 can be removed as part of this. -Alan. From mike.duigou at oracle.com Wed Mar 12 19:41:00 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 12 Mar 2014 12:41:00 -0700 Subject: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty In-Reply-To: References: <0541A3EA-A2A5-4977-8054-4EDB28366216@oracle.com>, , <318A3363-C4F6-42D5-99CD-DB6D00766B0C@oracle.com>, , <8FD1E74E-B433-475E-8DF6-3CB7126698AC@oracle.com>, , <4DC7C9B0-43F2-4FFF-A8D6-CFD1B54ED158@oracle.com> Message-ID: <9CBC797D-F5E2-42CD-B050-A0A706DFDBD4@oracle.com> Hi Jason,' Using isEmpty() was intended to save the array creation but you make a valid point regarding correctness. I have amended the webrev. This handling suggests that it would useful for implementation to cache the empty result for toArray() and I have also added this to ArrayList's toArray. http://cr.openjdk.java.net/~mduigou/JDK-8035584/3/webrev/ Mike On Mar 12 2014, at 07:06 , Jason Mehrens wrote: > Mike, > > In the constructor do you think you should skip the call to isEmpty and just check the length of toArray? Seems like since the implementation of the given collection is unknown it is probably best to perform as little interaction with it as possible. Also it would be possible for isEmpty to return false followed by toArray returning a zero length array that is different from cached copies. > > Jason > > > Subject: Re: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty > > From: mike.duigou at oracle.com > > Date: Tue, 11 Mar 2014 18:18:26 -0700 > > To: martinrb at google.com > > CC: core-libs-dev at openjdk.java.net > > > > > > On Mar 11 2014, at 17:42 , Martin Buchholz wrote: > > > > > I'm hoping y'all have evidence that empty ArrayLists are common in the wild. > > Yes, certainly. From the original proposal: > > > [This change] based upon analysis that shows that in large applications as much as 10% of maps and lists are initialized but never receive any entries. A smaller number spend a large proportion of their lifetime empty. We've found similar results across other workloads as well. > > > > > It is curious that empty lists grow immediately to 10, while ArrayList with capacity 1 grows to 2, then 3... Some people might think that a bug. > > Yes, that's unfortunate. I've made another version that uses a second sentinel for the default sized but empty case. > > > > Now I want to reduce the ensureCapacity reallocations! It seems like insane churn to replace the arrays that frequently. > > > There are more   changes that need to be reverted. > > > Else looks good. > > > - * More formally, returns the lowest index i such that > > > - * (o==null ? get(i)==null : o.equals(get(i))), > > > + * More formally, returns the lowest index {@code i} such that > > > + * {@code (o==null ? get(i)==null : o.equals(get(i)))}, > > > > Corrected. Thank you. > > > > http://cr.openjdk.java.net/~mduigou/JDK-8035584/2/webrev/ > > > > > > Mike > > > > > > > > > > > > > > > On Tue, Mar 11, 2014 at 5:20 PM, Mike Duigou wrote: > > > I've actually always used scp. :-) > > > > > > Since I accepted all of your changes as suggested and had no other changes I was just going to go ahead and push once testing was done. > > > > > > I've now prepared a revised webrev and can still accept feedback. > > > > > > http://cr.openjdk.java.net/~mduigou/JDK-8035584/1/webrev/ > > > > > > (Note: The webrev also contains https://bugs.openjdk.java.net/browse/JDK-8037097 since I am testing/pushing the two issues together.) > > > > > > Mike > > > > > > On Mar 11 2014, at 16:42 , Martin Buchholz wrote: > > > > > >> I don't see the updated webrev. Maybe you also fell victim to "rsync to cr no longer working"? > > >> > > >> > > >> On Tue, Mar 11, 2014 at 4:34 PM, Mike Duigou wrote: > > >> > > >> On Feb 21 2014, at 14:56 , Martin Buchholz wrote: > > >> > > >>> You should do -> code conversion separately, and do it pervasively across the entire JDK. > > >> > > >> From your lips to God's ears.... I keep suggesting this along with a restyle to official style every time we create new repos. Seems unlikely unfortunately as it makes backports harder. > > >> > > >>> This is not right. > > >>> + * {@code (o==null ? get(i)==null : o.equals(get(i)))} > > >> > > >> Corrected. > > >> > > >>> You accidentally deleted a stray space here? > > >>> > > >>> - this.elementData = EMPTY_ELEMENTDATA; > > >>> + this.elementData = EMPTY_ELEMENTDATA; > > >> > > >> Corrected. > > >> > > >>> public ArrayList(int initialCapacity) { > > >>> - super(); > > >>> if (initialCapacity < 0) > > >>> throw new IllegalArgumentException("Illegal Capacity: "+ > > >>> initialCapacity); > > >>> - this.elementData = new Object[initialCapacity]; > > >>> + this.elementData = (initialCapacity > 0) > > >>> + ? new Object[initialCapacity] > > >>> + : EMPTY_ELEMENTDATA; > > >>> } > > >>> > > >>> When optimizing for special cases, we should try very hard minimize overhead in the common case. In the above, we now have two branches in the common case. Instead, > > >>> > > >>> if (initialCapacity > 0) this.elementData = new Object[initialCapacity]; > > >>> else if (initialCapacity == 0) this.elementData = EMPTY_ELEMENTDATA; > > >>> else barf > > >> > > >> Corrected. > > >> > > >> Thanks as always for the feedback. > > >> > > >> Mike > > >> > > >>> > > >>> > > >>> > > >>> On Fri, Feb 21, 2014 at 2:41 PM, Mike Duigou wrote: > > >>> Hello all; > > >>> > > >>> This changeset consists of two small performance improvements for ArrayList. Both are related to the lazy initialization introduced in JDK-8011200. > > >>> > > >>> The first change is in the ArrayList(int capacity) constructor and forces lazy initialization if the requested capacity is zero. It's been observed that in cases where zero capacity is requested that it is very likely that the list never receives any elements. For these cases we permanently avoid the allocation of an element array. > > >>> > > >>> The second change, noticed by Gustav ?kesson, involves the ArrayList(Collection c) constructor. If c is an empty collection then there is no reason to inflate the backing array for the ArrayList. > > >>> > > >>> http://cr.openjdk.java.net/~mduigou/JDK-8035584/0/webrev/ > > >>> > > >>> I also took the opportunity to the -> {@code } conversion for the javadoc. > > >>> > > >>> Enjoy! > > >>> > > >>> Mike > > >>> > > >> > > >> > > > > > > > > From paul.sandoz at oracle.com Wed Mar 12 20:20:29 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 12 Mar 2014 21:20:29 +0100 Subject: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods In-Reply-To: References: <530F50DA.3010308@javaspecialists.eu> <144A3A2D-85FF-4F3B-A4DA-1780B809F36B@oracle.com> Message-ID: <9DF58ED9-C5C6-40A8-8901-C43116836BCE@oracle.com> On Feb 28, 2014, at 10:11 PM, John Rose wrote: > On Feb 28, 2014, at 1:38 AM, Paul Sandoz wrote: > >>> But chances are, the day after I take it off, I will need it. >>> >>> tryMonitorEnter() does no harm and it is out of reach of most programmers. >>> >> >> I think your analogy to a spare wheel is misleading. Continuing with the car theme i liken this feature to a pair of fluffy dice dangling from the rear view mirror [1]: distracting; mostly useless; and mostly harmless. > > The dice in your analogy are *too* useless; nobody can prove tryLock or isLocked useless, just in bad taste. > I did qualify with "mostly" :-) > It's more like a spare tire, maybe just for snow, which is really hard to access, as in "break glass in case of emergency". > > I threw it in, way back when, knowing the operation is portable and natural, and expected that folks would break the glass if they needed it. Despite the barrier to entry, a couple folks did. > Although the only external dep. i can currently find is required just for Java 6 (which Oracle no longer supports). >> All the data so far indicates this is legacy code [2]. > > I think the j.u.c library removed most needs to break the glass (connect to Unsafe). The users went to the standard API, and JVM native object monitors went out of fashion. > > But we are not ready to deprecate them, maybe never, so we should consider whether they need additional modernizations like tryLock or isLocked. All the data so far suggests we don't need them; are they to be treated any differently to other methods we have also removed from other non-public API classes? We could always add them back in the unlikely event of a new requirement, or are you indicating that these should also be retained in case code outside of the JDK needs to break the glass? Paul. From paul.sandoz at oracle.com Wed Mar 12 20:44:11 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 12 Mar 2014 21:44:11 +0100 Subject: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods In-Reply-To: <53172EE0.6030801@cs.oswego.edu> References: <530F50DA.3010308@javaspecialists.eu> <144A3A2D-85FF-4F3B-A4DA-1780B809F36B@oracle.com> <53172EE0.6030801@cs.oswego.edu> Message-ID: On Mar 5, 2014, at 3:04 PM, Doug Lea
wrote: > A few comments on catching up with this discussion... > Same here, back from a holiday last week. >>>> tryMonitorEnter() does no harm and it is out of reach of most >>>> programmers. > > Built-in monitors are heavily optimized for "typical" cases, > which does not include any form of tryLock. So the hotspot > implementation of tryMonitorEnter is very slow. Making > it less slow would probably negatively impact typical cases. > So tryMonitorEnter is only useful in cases where you absolutely need > the functionality at any cost, and don't want to use a j.u.c Lock. > It's not surprising that there almost no known usages, and > probably none that justify continued support. > Thanks, useful information. I would have expected if this offered a perf advantage that the resourceful Unsafe users would have found a use for it :-) Currently i cannot find any external uses of it. Paul. > The main downside of using a j.u.c Lock just for the sake > of tryLock is that you cannot take advantage of the JVM's > extremely compact lock representation (basically one bit in the > object header) for never-locked objects. On the other hand, > if you are trying to minimize footprint, there are usually > ways to cope. For example, in a few places inside j.u.c. we've used > other available bits as spinlocks and resorted to monitors/Locks > only when necessary. In a sense, this emulates monitor inflation. > > -Doug > From john.r.rose at oracle.com Wed Mar 12 21:12:30 2014 From: john.r.rose at oracle.com (John Rose) Date: Wed, 12 Mar 2014 14:12:30 -0700 Subject: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods In-Reply-To: References: <530F50DA.3010308@javaspecialists.eu> <144A3A2D-85FF-4F3B-A4DA-1780B809F36B@oracle.com> <53172EE0.6030801@cs.oswego.edu> Message-ID: <48666F38-592B-4234-8EAD-67607F9C5BBD@oracle.com> I think that we've covered all the angles, and that we can remove it. ? John > On Mar 12, 2014, at 1:44 PM, Paul Sandoz wrote: > > > Currently i cannot find any external uses of it. From john.r.rose at oracle.com Wed Mar 12 21:23:02 2014 From: john.r.rose at oracle.com (John Rose) Date: Wed, 12 Mar 2014 14:23:02 -0700 Subject: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods In-Reply-To: <48666F38-592B-4234-8EAD-67607F9C5BBD@oracle.com> References: <530F50DA.3010308@javaspecialists.eu> <144A3A2D-85FF-4F3B-A4DA-1780B809F36B@oracle.com> <53172EE0.6030801@cs.oswego.edu> <48666F38-592B-4234-8EAD-67607F9C5BBD@oracle.com> Message-ID: <84EB259F-4835-478F-B055-BFEDB73EF40A@oracle.com> P.S. FTR, I wish we could also remove the per-object monitor from its privileged position, so not all objects are burdened by it, and other forms of lock can be switched into the existing notation on a type-by-type basis. This is obviously a long, long term wish. A starting point is a notion of "this object has no monitor". Probably the keyword cannot be repurposed but would eventually be deprecated. And the Moon will reach Roche limit. ? John > On Mar 12, 2014, at 2:12 PM, John Rose wrote: > > I think that we've covered all the angles, and that we can remove it. > > ? John > >> On Mar 12, 2014, at 1:44 PM, Paul Sandoz wrote: >> >> >> Currently i cannot find any external uses of it. From kumar.x.srinivasan at oracle.com Wed Mar 12 21:24:44 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 12 Mar 2014 14:24:44 -0700 Subject: RFR: JDK9: 8037221: [asm] refresh internal ASM version Message-ID: <5320D09C.2070403@oracle.com> Hello, Appreciate if someone cane review this change, so that I can push this into the jdk9 repository, refreshing the internal ASM sources from rev 1700 to 1721, of particular interest is Rev 1710, which fixes [1] known to cause verification errors in the VM. Thereafter I will be back-porting this changeset into 8u20. http://cr.openjdk.java.net/~ksrini/8037221/ The following regression tests have been run: nashorn/test jdk/test/tools/pack200 jdk/test/java/lang/invoke jdk/test/java/util jdk/test/javax/script jdk/test/sun/tools/jrunscript jdk/test/closed/com/oracle/jfr langtools/test Nashorn additional test targets: test test262 octane Thanks in advance Kumar [1] http://forge.ow2.org/tracker/?group_id=23&atid=100023&func=detail&aid=316545 From chris.hegarty at oracle.com Thu Mar 13 09:43:55 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 13 Mar 2014 09:43:55 +0000 Subject: RFR: JDK-8035870 - Check jdk/src/windows/native/java/io/WinNTFileSystem_md.c for JNI pending exceptions In-Reply-To: <53209BB9.602@oracle.com> References: <53209BB9.602@oracle.com> Message-ID: <4BB40F1D-DAB5-4F72-8EF7-3B70E1ED8480@oracle.com> Looks good to me Mark. -Chris. On 12 Mar 2014, at 17:39, Mark Sheppard wrote: > > Hi > please oblige and review the following changes > http://cr.openjdk.java.net/~msheppar/8035870/webrev/ > > which address the issues raised in > https://bugs.openjdk.java.net/browse/JDK-8035870 > > summary: > checks to return values from malloc added with appropriate JNU_ThrowOutOfMemoryError added > > regards > Mark > From paul.sandoz at oracle.com Thu Mar 13 10:33:18 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 13 Mar 2014 11:33:18 +0100 Subject: RFR: JDK9: 8037221: [asm] refresh internal ASM version In-Reply-To: <5320D09C.2070403@oracle.com> References: <5320D09C.2070403@oracle.com> Message-ID: Hi, Eye-balled the changes, nothing obvious popped out. Looks good. It's very minor, and should not block the code going back, but "occured" is a common misspelling of "occurred". Paul. On Mar 12, 2014, at 10:24 PM, Kumar Srinivasan wrote: > Hello, > > Appreciate if someone cane review this change, so that I can push this into the jdk9 repository, > refreshing the internal ASM sources from rev 1700 to 1721, of particular interest is > Rev 1710, which fixes [1] known to cause verification errors in the VM. > Thereafter I will be back-porting this changeset into 8u20. > > http://cr.openjdk.java.net/~ksrini/8037221/ > > The following regression tests have been run: > nashorn/test > jdk/test/tools/pack200 > jdk/test/java/lang/invoke > jdk/test/java/util > jdk/test/javax/script > jdk/test/sun/tools/jrunscript > jdk/test/closed/com/oracle/jfr > langtools/test > > Nashorn additional test targets: > test > test262 > octane > > Thanks in advance > Kumar > > [1] http://forge.ow2.org/tracker/?group_id=23&atid=100023&func=detail&aid=316545 From paul.sandoz at oracle.com Thu Mar 13 11:21:36 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 13 Mar 2014 12:21:36 +0100 Subject: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods In-Reply-To: <84EB259F-4835-478F-B055-BFEDB73EF40A@oracle.com> References: <530F50DA.3010308@javaspecialists.eu> <144A3A2D-85FF-4F3B-A4DA-1780B809F36B@oracle.com> <53172EE0.6030801@cs.oswego.edu> <48666F38-592B-4234-8EAD-67607F9C5BBD@oracle.com> <84EB259F-4835-478F-B055-BFEDB73EF40A@oracle.com> Message-ID: On Mar 12, 2014, at 10:23 PM, John Rose wrote: > P.S. FTR, I wish we could also remove the per-object monitor from its privileged position, so not all objects are burdened by it, and other forms of lock can be switched into the existing notation on a type-by-type basis. This is obviously a long, long term wish. A starting point is a notion of "this object has no monitor". Like an instance of a value type? Paul. > Probably the keyword cannot be repurposed but would eventually be deprecated. And the Moon will reach Roche limit. > > ? John > >> On Mar 12, 2014, at 2:12 PM, John Rose wrote: >> >> I think that we've covered all the angles, and that we can remove it. >> >> ? John >> >>> On Mar 12, 2014, at 1:44 PM, Paul Sandoz wrote: >>> >>> >>> Currently i cannot find any external uses of it. From paul.sandoz at oracle.com Thu Mar 13 11:57:26 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 13 Mar 2014 12:57:26 +0100 Subject: Unsafe: efficiently comparing two byte arrays In-Reply-To: References: <530F5136.20405@redhat.com> <8D3E2037-E5D1-4D2E-B779-E7EDD2AF4F58@oracle.com> <530F55CA.3060302@redhat.com> Message-ID: On Feb 28, 2014, at 11:29 PM, Martin Buchholz wrote: > Are word-size reads in ByteBuffer actually intrinsified? I could find no evidence for that. Perhaps this is an important missing optimization for hotspot to make? > > I see DirectByteBuffer, but not garden-variety ByteBuffer, using Unsafe. > share/classes/java/nio/Direct-X-Buffer.java.template > Yes, no choice :-) I see it only does it when unaligned access is supported: private long getLong(long a) { if (unaligned) { long x = unsafe.getLong(a); return (nativeByteOrder ? x : Bits.swap(x)); } return Bits.getLong(a, bigEndian); } I suppose it could detect if the address + position also aligns, but ideally that should be hoisted out of any loop so the unaligned pre/post bytes are handled separately to the aligned sequence viewed as longs, which most likely means explicit code for the comparison use-case. Now i am in two minds to whether to add ByteBuffer.compareUnsigned or add Arrays.compareUnsigned. An explosion of methods on Arrays for all types (plus to/from versions) would be annoying. Paul. From sean.coffey at oracle.com Thu Mar 13 12:18:20 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Thu, 13 Mar 2014 12:18:20 +0000 Subject: RFR: 8037012: (tz) Support tzdata2014a In-Reply-To: <532077B8.3030605@oracle.com> References: <532077B8.3030605@oracle.com> Message-ID: <5321A20C.808@oracle.com> Looks good to me. regards, Sean. On 12/03/2014 15:05, Aleksej Efimov wrote: > Hello, > > Can I have a review for a tzdata2014a [1] integration to JDK9: > http://cr.openjdk.java.net/~aefimov/8037012/9/webrev.00 > The following test sets were executed on the build with latest tzdata: > test/sun/util/calendar test/java/util/Calendar > test/sun/util/resources/TimeZone test/sun/util/calendar > test/java/util/TimeZone test/java/time test/java/util/Formatter > test/closed/java/util/Calendar test/closed/java/util/TimeZone > > One test failure was observed - see the bug report for details: [2]. > The review for this test failure fix will be sent in a few moments. > Other tests passes. > > Thank you, > Aleksej > > [1] https://bugs.openjdk.java.net/browse/JDK-8037012 > [2] https://bugs.openjdk.java.net/browse/JDK-8037180 > From aph at redhat.com Thu Mar 13 12:19:36 2014 From: aph at redhat.com (Andrew Haley) Date: Thu, 13 Mar 2014 12:19:36 +0000 Subject: Unsafe: efficiently comparing two byte arrays In-Reply-To: References: <530F5136.20405@redhat.com> <8D3E2037-E5D1-4D2E-B779-E7EDD2AF4F58@oracle.com> <530F55CA.3060302@redhat.com> Message-ID: <5321A258.6080602@redhat.com> On 03/13/2014 11:57 AM, Paul Sandoz wrote: > Now i am in two minds to whether to add ByteBuffer.compareUnsigned or add Arrays.compareUnsigned. > > An explosion of methods on Arrays for all types (plus to/from versions) would be annoying. Surely it's a no brainer? All we have to do is add the intrinsics for ByteBuffers, then we get fast ByteBuffers and fast array comparisons too. I don't see the problem. Andrew. From sean.coffey at oracle.com Thu Mar 13 12:19:51 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Thu, 13 Mar 2014 12:19:51 +0000 Subject: RFR: 8037180: [TEST_BUG] test/sun/util/calendar/zi/Zoneinfo.java incorrectly calculates raw GMT offset change time In-Reply-To: <53207808.4090107@oracle.com> References: <53207808.4090107@oracle.com> Message-ID: <5321A267.6050101@oracle.com> Looks good Aleksej. A future rule change doesn't necessarily mean a new GMT offset change. Original test logic seemed buggy. regards, Sean. On 12/03/2014 15:06, Aleksej Efimov wrote: > Hello, > > Can I have a review for a 'test/sun/util/calendar/zi/Zoneinfo.java' > test bug failure [1] related to the latest tzdata2014a integration [2]. > The test failure message: > Asia/Istanbul : Asia/Istanbul > offset=7200000,dstSavings=3600000,useDaylight=true,transitions=171,offsets=5,checksum=-508379603,gmtChanged=false > > [NG]offset=7200000,dstSavings=3600000,useDaylight=true,transitions=171,offsets=5,checksum=-508379603,gmtChanged=true > > ----------System.err:(13/732)---------- > java.lang.RuntimeException: FAILED: Asia/Istanbul > at TestZoneInfo310.main(TestZoneInfo310.java:170) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:484) > at > com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94) > at java.lang.Thread.run(Thread.java:744) > > This failure caused by the following entry in test tzdata files: > Zone Europe/Istanbul 1:55:52 - LMT 1880 > 1:56:56 - IMT 1910 Oct # Istanbul > Mean Time? > 2:00 Turkey EE%sT 1978 Oct 15 > 3:00 Turkey TR%sT 1985 Apr 20 # Turkey Time > 2:00 Turkey EE%sT 2007 > 2:00 EU EE%sT 2011 Mar 27 1:00u > 2:00 - EET 2011 Mar 28 1:00u > 2:00 EU EE%sT 2014 Mar 30 1:00u > 2:00 - EET 2014 Mar 31 1:00u > 2:00 EU EE%sT > > The raw GMT offset here is constant=2:00 and not changed since 1985 > Apr 20. But the test code 'test/sun/util/calendar/zi' shows that there > will be a future raw GMT offset change. The following fix resolves > this problem: http://cr.openjdk.java.net/~aefimov/8037180/9/webrev.00/ > > -Aleksej > > > [1] https://bugs.openjdk.java.net/browse/JDK-8037180 > [2] https://bugs.openjdk.java.net/browse/JDK-8037012 From masayoshi.okutsu at oracle.com Thu Mar 13 12:25:38 2014 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 13 Mar 2014 21:25:38 +0900 Subject: RFR: 8037012: (tz) Support tzdata2014a In-Reply-To: <5321A20C.808@oracle.com> References: <532077B8.3030605@oracle.com> <5321A20C.808@oracle.com> Message-ID: <5321A3C2.3010505@oracle.com> +1 Masayoshi On 3/13/2014 9:18 PM, Se?n Coffey wrote: > Looks good to me. > > regards, > Sean. > > On 12/03/2014 15:05, Aleksej Efimov wrote: >> Hello, >> >> Can I have a review for a tzdata2014a [1] integration to JDK9: >> http://cr.openjdk.java.net/~aefimov/8037012/9/webrev.00 >> The following test sets were executed on the build with latest tzdata: >> test/sun/util/calendar test/java/util/Calendar >> test/sun/util/resources/TimeZone test/sun/util/calendar >> test/java/util/TimeZone test/java/time test/java/util/Formatter >> test/closed/java/util/Calendar test/closed/java/util/TimeZone >> >> One test failure was observed - see the bug report for details: [2]. >> The review for this test failure fix will be sent in a few moments. >> Other tests passes. >> >> Thank you, >> Aleksej >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8037012 >> [2] https://bugs.openjdk.java.net/browse/JDK-8037180 >> > From masayoshi.okutsu at oracle.com Thu Mar 13 12:31:24 2014 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 13 Mar 2014 21:31:24 +0900 Subject: RFR: 8037180: [TEST_BUG] test/sun/util/calendar/zi/Zoneinfo.java incorrectly calculates raw GMT offset change time In-Reply-To: <5321A267.6050101@oracle.com> References: <53207808.4090107@oracle.com> <5321A267.6050101@oracle.com> Message-ID: <5321A51C.4020108@oracle.com> +1 Masayoshi On 3/13/2014 9:19 PM, Se?n Coffey wrote: > Looks good Aleksej. A future rule change doesn't necessarily mean a > new GMT offset change. Original test logic seemed buggy. > > regards, > Sean. > > On 12/03/2014 15:06, Aleksej Efimov wrote: >> Hello, >> >> Can I have a review for a 'test/sun/util/calendar/zi/Zoneinfo.java' >> test bug failure [1] related to the latest tzdata2014a integration [2]. >> The test failure message: >> Asia/Istanbul : Asia/Istanbul >> offset=7200000,dstSavings=3600000,useDaylight=true,transitions=171,offsets=5,checksum=-508379603,gmtChanged=false >> >> [NG]offset=7200000,dstSavings=3600000,useDaylight=true,transitions=171,offsets=5,checksum=-508379603,gmtChanged=true >> >> ----------System.err:(13/732)---------- >> java.lang.RuntimeException: FAILED: Asia/Istanbul >> at TestZoneInfo310.main(TestZoneInfo310.java:170) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:484) >> at >> com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94) >> at java.lang.Thread.run(Thread.java:744) >> >> This failure caused by the following entry in test tzdata files: >> Zone Europe/Istanbul 1:55:52 - LMT 1880 >> 1:56:56 - IMT 1910 Oct # Istanbul >> Mean Time? >> 2:00 Turkey EE%sT 1978 Oct 15 >> 3:00 Turkey TR%sT 1985 Apr 20 # Turkey >> Time >> 2:00 Turkey EE%sT 2007 >> 2:00 EU EE%sT 2011 Mar 27 1:00u >> 2:00 - EET 2011 Mar 28 1:00u >> 2:00 EU EE%sT 2014 Mar 30 1:00u >> 2:00 - EET 2014 Mar 31 1:00u >> 2:00 EU EE%sT >> >> The raw GMT offset here is constant=2:00 and not changed since 1985 >> Apr 20. But the test code 'test/sun/util/calendar/zi' shows that >> there will be a future raw GMT offset change. The following fix >> resolves this problem: >> http://cr.openjdk.java.net/~aefimov/8037180/9/webrev.00/ >> >> -Aleksej >> >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8037180 >> [2] https://bugs.openjdk.java.net/browse/JDK-8037012 > From paul.sandoz at oracle.com Thu Mar 13 12:49:54 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 13 Mar 2014 13:49:54 +0100 Subject: Unsafe: efficiently comparing two byte arrays In-Reply-To: <5321A258.6080602@redhat.com> References: <530F5136.20405@redhat.com> <8D3E2037-E5D1-4D2E-B779-E7EDD2AF4F58@oracle.com> <530F55CA.3060302@redhat.com> <5321A258.6080602@redhat.com> Message-ID: On Mar 13, 2014, at 1:19 PM, Andrew Haley wrote: > On 03/13/2014 11:57 AM, Paul Sandoz wrote: >> Now i am in two minds to whether to add ByteBuffer.compareUnsigned or add Arrays.compareUnsigned. >> >> An explosion of methods on Arrays for all types (plus to/from versions) would be annoying. > > Surely it's a no brainer? All we have to do is add the intrinsics for > ByteBuffers, then we get fast ByteBuffers and fast array comparisons too. > I don't see the problem. > For byte[] comparison, I don't think optimal long access is sufficient on it's own due to alignment issues. It would be nice if we can avoid burdening users with alignment issues to ensure the main comparison loop is efficient. A quick solution is to leverage Unsafe within a ByteBuffer.compareUnsigned method. In fact i believe Unsafe could be used (as Aleksey says in [1]) for put/get as well, which i presume is likely to be much easier/quicker to implement. Might be a good first step until a more superior intrinsics solution is implemented? Paul. [1] https://bugs.openjdk.java.net/browse/JDK-8026049 From aph at redhat.com Thu Mar 13 12:57:39 2014 From: aph at redhat.com (Andrew Haley) Date: Thu, 13 Mar 2014 12:57:39 +0000 Subject: Unsafe: efficiently comparing two byte arrays In-Reply-To: References: <530F5136.20405@redhat.com> <8D3E2037-E5D1-4D2E-B779-E7EDD2AF4F58@oracle.com> <530F55CA.3060302@redhat.com> <5321A258.6080602@redhat.com> Message-ID: <5321AB43.6040008@redhat.com> On 03/13/2014 12:49 PM, Paul Sandoz wrote: > On Mar 13, 2014, at 1:19 PM, Andrew Haley wrote: >> On 03/13/2014 11:57 AM, Paul Sandoz wrote: >>> Now i am in two minds to whether to add ByteBuffer.compareUnsigned or add Arrays.compareUnsigned. >>> >>> An explosion of methods on Arrays for all types (plus to/from versions) would be annoying. >> >> Surely it's a no brainer? All we have to do is add the intrinsics for >> ByteBuffers, then we get fast ByteBuffers and fast array comparisons too. >> I don't see the problem. > > For byte[] comparison, I don't think optimal long access is > sufficient on it's own due to alignment issues. It would be nice if > we can avoid burdening users with alignment issues to ensure the > main comparison loop is efficient. But alignment issues are a feature of the hardware, not of software. The problem right now is that ByteBuffers use a byte-by-byte comparison of longs, even when it isn't needed, because there aren't the intrinsics. > A quick solution is to leverage Unsafe within a > ByteBuffer.compareUnsigned method. In fact i believe Unsafe could be > used (as Aleksey says in [1]) for put/get as well, which i presume > is likely to be much easier/quicker to implement. Might be a good > first step until a more superior intrinsics solution is implemented? I still don't get it, sorry. What can Unsafe do that ByteBuffer intrinsics can't do? Andrew. From gunnar at hibernate.org Thu Mar 13 13:24:53 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 13 Mar 2014 14:24:53 +0100 Subject: Accessing type annotations at runtime Message-ID: Hi, Is it possible to retrieve type annotations (as defined by JSR 308) using reflection at runtime? E.g. I would like to retrieve the @NotNull annotation from a member declared like this: private List<@NotNull String> names; I assumed that this would be possible using reflection, but I couldn't find a way to do it. Is there an example for this somewhere? Or are type annotations only meant to be accessed by compile-time tools such as the Checker framework? I noticed that the byte code of my class contains information about the annotation, so I guess one could access it by examining the class file if it's really not possible via the reflection API. Many thanks, --Gunnar From kumar.x.srinivasan at oracle.com Thu Mar 13 13:43:52 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 13 Mar 2014 06:43:52 -0700 Subject: RFR: JDK9: 8037221: [asm] refresh internal ASM version In-Reply-To: References: <5320D09C.2070403@oracle.com> Message-ID: <5321B618.7000703@oracle.com> Thanks Paul, for the review!. > Hi, > > Eye-balled the changes, nothing obvious popped out. Looks good. > > It's very minor, and should not block the code going back, but "occured" is a common misspelling of "occurred". fyi, these are *all* changes made upstream, by the ASM team, the only file we generate is the version.txt to help us identify what we have. Kumar > > Paul. > > On Mar 12, 2014, at 10:24 PM, Kumar Srinivasan wrote: > >> Hello, >> >> Appreciate if someone cane review this change, so that I can push this into the jdk9 repository, >> refreshing the internal ASM sources from rev 1700 to 1721, of particular interest is >> Rev 1710, which fixes [1] known to cause verification errors in the VM. >> Thereafter I will be back-porting this changeset into 8u20. >> >> http://cr.openjdk.java.net/~ksrini/8037221/ >> >> The following regression tests have been run: >> nashorn/test >> jdk/test/tools/pack200 >> jdk/test/java/lang/invoke >> jdk/test/java/util >> jdk/test/javax/script >> jdk/test/sun/tools/jrunscript >> jdk/test/closed/com/oracle/jfr >> langtools/test >> >> Nashorn additional test targets: >> test >> test262 >> octane >> >> Thanks in advance >> Kumar >> >> [1] http://forge.ow2.org/tracker/?group_id=23&atid=100023&func=detail&aid=316545 From paul.sandoz at oracle.com Thu Mar 13 14:19:34 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 13 Mar 2014 15:19:34 +0100 Subject: Unsafe: efficiently comparing two byte arrays In-Reply-To: <5321AB43.6040008@redhat.com> References: <530F5136.20405@redhat.com> <8D3E2037-E5D1-4D2E-B779-E7EDD2AF4F58@oracle.com> <530F55CA.3060302@redhat.com> <5321A258.6080602@redhat.com> <5321AB43.6040008@redhat.com> Message-ID: On Mar 13, 2014, at 1:57 PM, Andrew Haley wrote: > On 03/13/2014 12:49 PM, Paul Sandoz wrote: >> On Mar 13, 2014, at 1:19 PM, Andrew Haley wrote: >>> On 03/13/2014 11:57 AM, Paul Sandoz wrote: >>>> Now i am in two minds to whether to add ByteBuffer.compareUnsigned or add Arrays.compareUnsigned. >>>> >>>> An explosion of methods on Arrays for all types (plus to/from versions) would be annoying. >>> >>> Surely it's a no brainer? All we have to do is add the intrinsics for >>> ByteBuffers, then we get fast ByteBuffers and fast array comparisons too. >>> I don't see the problem. >> >> For byte[] comparison, I don't think optimal long access is >> sufficient on it's own due to alignment issues. It would be nice if >> we can avoid burdening users with alignment issues to ensure the >> main comparison loop is efficient. > > But alignment issues are a feature of the hardware, not of software. > The problem right now is that ByteBuffers use a byte-by-byte > comparison of longs, even when it isn't needed, because there aren't > the intrinsics. > I was considering the following case: byte[] b1 = ... byte[] b2 = ... // compare from offset ByteBuffer left = ByteBuffer.wrap(b1, 1, b1.length - 1); ByteBuffer right = ByteBuffer.wrap(b2, 1, b2.length - 1); int r = compare(left, right); static int compare(ByteBuffer left, ByteBuffer right) { int minLength = Math.min(left.remaining(), right.remaining()); int minWords = minLength / 8; for (int i = 0; i < minWords * 8; i += 8) { long lw = left.getLong(); // Inefficient when unaligned access is not supported by hardware? long rw = right.getLong(); // Are bounds checks hoisted out? i presume so if (lw != rw) { return Long.compareUnsigned(lw, rw); } } for (int i = minWords * 8; i < minLength; i++) { int result = Byte.toUnsignedInt(left.get()) - Byte.toUnsignedInt(right.get()); if (result != 0) { return result; } } return left.remaining() - right.remaining(); } Certain Apache code (e.g. see Cassandra) supports comparing byte[] arrays with offsets and i am not sure that code is portable [1]. I was wondering in the case where the hardware does not support unaligned access it might be possible to sill optimize by reading longs at aligned positions and doing some some extra bit twiddling. >> A quick solution is to leverage Unsafe within a >> ByteBuffer.compareUnsigned method. In fact i believe Unsafe could be >> used (as Aleksey says in [1]) for put/get as well, which i presume >> is likely to be much easier/quicker to implement. Might be a good >> first step until a more superior intrinsics solution is implemented? > > I still don't get it, sorry. What can Unsafe do that ByteBuffer > intrinsics can't do? > We can arguably implement it faster [2] and i presume it will be simpler too. Paul. [1] https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob;f=src/java/org/apache/cassandra/utils/FastByteComparisons.java;h=4be6cd42b3035055c2b6102718d2cf49b73669f1;hb=HEAD#l184 [2] Well, i argue it is since i know next to nothing about how to implement an intrinsic :-) From david.lloyd at redhat.com Thu Mar 13 14:26:03 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 13 Mar 2014 09:26:03 -0500 Subject: Unsafe: efficiently comparing two byte arrays In-Reply-To: <5321A258.6080602@redhat.com> References: <530F5136.20405@redhat.com> <8D3E2037-E5D1-4D2E-B779-E7EDD2AF4F58@oracle.com> <530F55CA.3060302@redhat.com> <5321A258.6080602@redhat.com> Message-ID: <5321BFFB.1060009@redhat.com> On 03/13/2014 07:19 AM, Andrew Haley wrote: > On 03/13/2014 11:57 AM, Paul Sandoz wrote: >> Now i am in two minds to whether to add ByteBuffer.compareUnsigned or add Arrays.compareUnsigned. >> >> An explosion of methods on Arrays for all types (plus to/from versions) would be annoying. > > Surely it's a no brainer? All we have to do is add the intrinsics for > ByteBuffers, then we get fast ByteBuffers and fast array comparisons too. > I don't see the problem. Why such a hangup on ByteBuffers and Arrays? I think it'd be super useful to simply have methods on Long, Integer, etc: public static void getBytesBE(long orig, byte[] dst, int off) public static void getBytesLE(long orig, byte[] dst, int off) public static int compareBE(long orig, byte[] other, int off) public static int compareLE(long orig, byte[] other, int off) public static long getLongFromBytesBE(byte[] src, int off) public static long getLongFromBytesLE(byte[] src, int off) ... It makes sense as there are already some byte- and bit-ish methods on there (reversing byte order for example, or finding population count, etc.). If these were intrinsic, ByteBuffer could use these methods (as could Arrays.fill(...) and friends, if one was so inclined). Then Data*Stream could use them as well perhaps. -- - DML From joe.darcy at oracle.com Thu Mar 13 14:39:34 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 13 Mar 2014 07:39:34 -0700 Subject: Accessing type annotations at runtime In-Reply-To: References: Message-ID: <5321C326.3070106@oracle.com> Hello, See the methods in java.lang.reflect named "getAnnotedFoo" which return java.lang.reflect.AnnotedType or a subinterface. -Joe On 3/13/2014 6:24 AM, Gunnar Morling wrote: > Hi, > > Is it possible to retrieve type annotations (as defined by JSR 308) using > reflection at runtime? E.g. I would like to retrieve the @NotNull > annotation from a member declared like this: > > private List<@NotNull String> names; > > I assumed that this would be possible using reflection, but I couldn't find > a way to do it. Is there an example for this somewhere? Or are type > annotations only meant to be accessed by compile-time tools such as the > Checker framework? > > I noticed that the byte code of my class contains information about the > annotation, so I guess one could access it by examining the class file if > it's really not possible via the reflection API. > > Many thanks, > > --Gunnar From ivan.gerasimov at oracle.com Thu Mar 13 15:29:42 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 13 Mar 2014 19:29:42 +0400 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange Message-ID: <5321CEE6.403@oracle.com> Hello! Would you please review a simple fix of the javadoc for ArrayList#removeRange() method? The doc says that IndexOutOfBoundsException is thrown if fromIndex or toIndex is out of range (fromIndex < 0 || fromIndex >= size() || toIndex > size() || toIndex < fromIndex). The condition 'fromIndex >= size()' isn't true and should be removed from the doc. For example, the code list.removeRange(size(), size()) does not throw any exception. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8014066 WEBREV: http://cr.openjdk.java.net/~igerasim/8014066/0/webrev/ Sincerely yours, Ivan From chris.hegarty at oracle.com Thu Mar 13 15:47:39 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 13 Mar 2014 15:47:39 +0000 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <5321CEE6.403@oracle.com> References: <5321CEE6.403@oracle.com> Message-ID: <123FE971-9F74-43E6-988A-86D9A1804C68@oracle.com> Ivan, This does look a little odd, but since fromIndex is inclusive I would think that it should throw if passed a value of size() ?? -Chris. On 13 Mar 2014, at 15:29, Ivan Gerasimov wrote: > Hello! > > Would you please review a simple fix of the javadoc for ArrayList#removeRange() method? > > The doc says that IndexOutOfBoundsException is thrown if fromIndex or toIndex is out of range (fromIndex < 0 || fromIndex >= size() || toIndex > size() || toIndex < fromIndex). > > The condition 'fromIndex >= size()' isn't true and should be removed from the doc. > > For example, the code list.removeRange(size(), size()) does not throw any exception. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8014066 > WEBREV: http://cr.openjdk.java.net/~igerasim/8014066/0/webrev/ > > Sincerely yours, > Ivan From jason_mehrens at hotmail.com Thu Mar 13 15:56:17 2014 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Thu, 13 Mar 2014 10:56:17 -0500 Subject: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty In-Reply-To: <9CBC797D-F5E2-42CD-B050-A0A706DFDBD4@oracle.com> References: <0541A3EA-A2A5-4977-8054-4EDB28366216@oracle.com>, , <318A3363-C4F6-42D5-99CD-DB6D00766B0C@oracle.com>, , <8FD1E74E-B433-475E-8DF6-3CB7126698AC@oracle.com>, , <4DC7C9B0-43F2-4FFF-A8D6-CFD1B54ED158@oracle.com> , <9CBC797D-F5E2-42CD-B050-A0A706DFDBD4@oracle.com> Message-ID: Mike, The constructor modification looks good. The only other alternative I can think would be to use 'c.toArray(EMPTY_ELEMENTDATA)' to avoid creating an extra array. I'm guessing that version would not perform as well as your current version. The modification for toArray violates the List contract because the returned array must be safe (must use 'new' and must not retain reference). I think you'll have to back out that change. Contract violation aside, the only case that I can see that might unsafe for an empty array would be acquiring the monitor of EMPTY_ELEMENTDATA array. When we patched the Collections$EmptyXXX classes we avoided returning a cached empty array for this reason. Jason Subject: Re: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty From: mike.duigou at oracle.com Date: Wed, 12 Mar 2014 12:41:00 -0700 CC: martinrb at google.com; core-libs-dev at openjdk.java.net To: jason_mehrens at hotmail.com Hi Jason,' Using isEmpty() was intended to save the array creation but you make a valid point regarding correctness. I have amended the webrev. This handling suggests that it would useful for implementation to cache the empty result for toArray() and I have also added this to ArrayList's toArray. http://cr.openjdk.java.net/~mduigou/JDK-8035584/3/webrev/ Mike On Mar 12 2014, at 07:06 , Jason Mehrens wrote: Mike, In the constructor do you think you should skip the call to isEmpty and just check the length of toArray? Seems like since the implementation of the given collection is unknown it is probably best to perform as little interaction with it as possible. Also it would be possible for isEmpty to return false followed by toArray returning a zero length array that is different from cached copies. Jason > Subject: Re: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty > From: mike.duigou at oracle.com > Date: Tue, 11 Mar 2014 18:18:26 -0700 > To: martinrb at google.com > CC: core-libs-dev at openjdk.java.net > > > On Mar 11 2014, at 17:42 , Martin Buchholz wrote: > > > I'm hoping y'all have evidence that empty ArrayLists are common in the wild. > Yes, certainly. From the original proposal: > > [This change] based upon analysis that shows that in large applications as much as 10% of maps and lists are initialized but never receive any entries. A smaller number spend a large proportion of their lifetime empty. We've found similar results across other workloads as well. > > > It is curious that empty lists grow immediately to 10, while ArrayList with capacity 1 grows to 2, then 3... Some people might think that a bug. > Yes, that's unfortunate. I've made another version that uses a second sentinel for the default sized but empty case. > > Now I want to reduce the ensureCapacity reallocations! It seems like insane churn to replace the arrays that frequently. > > There are more   changes that need to be reverted. > > Else looks good. > > - * More formally, returns the lowest index i such that > > - * (o==null ? get(i)==null : o.equals(get(i))), > > + * More formally, returns the lowest index {@code i} such that > > + * {@code (o==null ? get(i)==null : o.equals(get(i)))}, > > Corrected. Thank you. > > http://cr.openjdk.java.net/~mduigou/JDK-8035584/2/webrev/ > > > Mike > > > > > > > > > On Tue, Mar 11, 2014 at 5:20 PM, Mike Duigou wrote: > > I've actually always used scp. :-) > > > > Since I accepted all of your changes as suggested and had no other changes I was just going to go ahead and push once testing was done. > > > > I've now prepared a revised webrev and can still accept feedback. > > > > http://cr.openjdk.java.net/~mduigou/JDK-8035584/1/webrev/ > > > > (Note: The webrev also contains https://bugs.openjdk.java.net/browse/JDK-8037097 since I am testing/pushing the two issues together.) > > > > Mike > > > > On Mar 11 2014, at 16:42 , Martin Buchholz wrote: > > > >> I don't see the updated webrev. Maybe you also fell victim to "rsync to cr no longer working"? > >> > >> > >> On Tue, Mar 11, 2014 at 4:34 PM, Mike Duigou wrote: > >> > >> On Feb 21 2014, at 14:56 , Martin Buchholz wrote: > >> > >>> You should do -> code conversion separately, and do it pervasively across the entire JDK. > >> > >> From your lips to God's ears.... I keep suggesting this along with a restyle to official style every time we create new repos. Seems unlikely unfortunately as it makes backports harder. > >> > >>> This is not right. > >>> + * {@code (o==null ? get(i)==null : o.equals(get(i)))} > >> > >> Corrected. > >> > >>> You accidentally deleted a stray space here? > >>> > >>> - this.elementData = EMPTY_ELEMENTDATA; > >>> + this.elementData = EMPTY_ELEMENTDATA; > >> > >> Corrected. > >> > >>> public ArrayList(int initialCapacity) { > >>> - super(); > >>> if (initialCapacity < 0) > >>> throw new IllegalArgumentException("Illegal Capacity: "+ > >>> initialCapacity); > >>> - this.elementData = new Object[initialCapacity]; > >>> + this.elementData = (initialCapacity > 0) > >>> + ? new Object[initialCapacity] > >>> + : EMPTY_ELEMENTDATA; > >>> } > >>> > >>> When optimizing for special cases, we should try very hard minimize overhead in the common case. In the above, we now have two branches in the common case. Instead, > >>> > >>> if (initialCapacity > 0) this.elementData = new Object[initialCapacity]; > >>> else if (initialCapacity == 0) this.elementData = EMPTY_ELEMENTDATA; > >>> else barf > >> > >> Corrected. > >> > >> Thanks as always for the feedback. > >> > >> Mike > >> > >>> > >>> > >>> > >>> On Fri, Feb 21, 2014 at 2:41 PM, Mike Duigou wrote: > >>> Hello all; > >>> > >>> This changeset consists of two small performance improvements for ArrayList. Both are related to the lazy initialization introduced in JDK-8011200. > >>> > >>> The first change is in the ArrayList(int capacity) constructor and forces lazy initialization if the requested capacity is zero. It's been observed that in cases where zero capacity is requested that it is very likely that the list never receives any elements. For these cases we permanently avoid the allocation of an element array. > >>> > >>> The second change, noticed by Gustav ?kesson, involves the ArrayList(Collection c) constructor. If c is an empty collection then there is no reason to inflate the backing array for the ArrayList. > >>> > >>> http://cr.openjdk.java.net/~mduigou/JDK-8035584/0/webrev/ > >>> > >>> I also took the opportunity to the -> {@code } conversion for the javadoc. > >>> > >>> Enjoy! > >>> > >>> Mike > >>> > >> > >> > > > > > From gunnar at hibernate.org Thu Mar 13 16:03:46 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 13 Mar 2014 17:03:46 +0100 Subject: Accessing type annotations at runtime In-Reply-To: <5321C326.3070106@oracle.com> References: <5321C326.3070106@oracle.com> Message-ID: Hi Joe, Thanks for the reply and hinting me the right direction! I had seen these methods but was missing the down-cast to AnnotatedParameterizedType which gives access to getAnnotatedActualTypeArguments(). In case it's helpful to others, that's what I ended up with: Field myField = ...; // List AnnotatedParameterizedType type = (AnnotatedParameterizedType) declaredField.getAnnotatedType(); // String AnnotatedType typeArg = type.getAnnotatedActualTypeArguments()[0]; // @NotNull Annotation annotation = typeArg.getAnnotations()[0]; Thanks again, --Gunnar 2014-03-13 15:39 GMT+01:00 Joe Darcy : > Hello, > > See the methods in java.lang.reflect named "getAnnotedFoo" which return > java.lang.reflect.AnnotedType or a subinterface. > > -Joe > > > On 3/13/2014 6:24 AM, Gunnar Morling wrote: > >> Hi, >> >> Is it possible to retrieve type annotations (as defined by JSR 308) using >> reflection at runtime? E.g. I would like to retrieve the @NotNull >> annotation from a member declared like this: >> >> private List<@NotNull String> names; >> >> I assumed that this would be possible using reflection, but I couldn't >> find >> a way to do it. Is there an example for this somewhere? Or are type >> annotations only meant to be accessed by compile-time tools such as the >> Checker framework? >> >> I noticed that the byte code of my class contains information about the >> annotation, so I guess one could access it by examining the class file if >> it's really not possible via the reflection API. >> >> Many thanks, >> >> --Gunnar >> > > From david.lloyd at redhat.com Thu Mar 13 16:07:08 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 13 Mar 2014 11:07:08 -0500 Subject: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty In-Reply-To: References: <0541A3EA-A2A5-4977-8054-4EDB28366216@oracle.com>, , <318A3363-C4F6-42D5-99CD-DB6D00766B0C@oracle.com>, , <8FD1E74E-B433-475E-8DF6-3CB7126698AC@oracle.com>, , <4DC7C9B0-43F2-4FFF-A8D6-CFD1B54ED158@oracle.com> , <9CBC797D-F5E2-42CD-B050-A0A706DFDBD4@oracle.com> Message-ID: <5321D7AC.1000305@redhat.com> You could definitely safely do a check to see if elementData == EMPTY_ELEMENTDATA (irrespective of size), and if so, return EMPTY_ELEMENTDATA instead of copying. I don't think however that that method, as is, is actually unsafe. I can't think of a code path where, say, a sudden concurrent change in size would cause a problem that wouldn't already be a problem with the original method. If size was 0 when the assignment and check took place, and suddenly grew, returning an empty array is OK at this point. If size was >0 and then suddenly shrunk or went to 0, the copy would copy extra elements - but that would already be the case with the original implementation. On 03/13/2014 10:56 AM, Jason Mehrens wrote: > Mike, > > The constructor modification looks good. The only other alternative I can think would be to use 'c.toArray(EMPTY_ELEMENTDATA)' to avoid creating an extra array. I'm guessing that version would not perform as well as your current version. > > The modification for toArray violates the List contract because the returned array must be safe (must use 'new' and must not retain reference). I think you'll have to back out that change. Contract violation aside, the only case that I can see that might unsafe for an empty array would be acquiring the monitor of EMPTY_ELEMENTDATA array. When we patched the Collections$EmptyXXX classes we avoided returning a cached empty array for this reason. > > Jason > > Subject: Re: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty > From: mike.duigou at oracle.com > Date: Wed, 12 Mar 2014 12:41:00 -0700 > CC: martinrb at google.com; core-libs-dev at openjdk.java.net > To: jason_mehrens at hotmail.com > > Hi Jason,' > Using isEmpty() was intended to save the array creation but you make a valid point regarding correctness. I have amended the webrev. This handling suggests that it would useful for implementation to cache the empty result for toArray() and I have also added this to ArrayList's toArray. > http://cr.openjdk.java.net/~mduigou/JDK-8035584/3/webrev/ > Mike > On Mar 12 2014, at 07:06 , Jason Mehrens wrote: > > > Mike, > > In the constructor do you think you should skip the call to isEmpty and just check the length of toArray? Seems like since the implementation of the given collection is unknown it is probably best to perform as little interaction with it as possible. Also it would be possible for isEmpty to return false followed by toArray returning a zero length array that is different from cached copies. > > Jason > >> Subject: Re: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty >> From: mike.duigou at oracle.com >> Date: Tue, 11 Mar 2014 18:18:26 -0700 >> To: martinrb at google.com >> CC: core-libs-dev at openjdk.java.net >> >> >> On Mar 11 2014, at 17:42 , Martin Buchholz wrote: >> >>> I'm hoping y'all have evidence that empty ArrayLists are common in the wild. >> Yes, certainly. From the original proposal: >>> [This change] based upon analysis that shows that in large applications as much as 10% of maps and lists are initialized but never receive any entries. A smaller number spend a large proportion of their lifetime empty. We've found similar results across other workloads as well. >> >>> It is curious that empty lists grow immediately to 10, while ArrayList with capacity 1 grows to 2, then 3... Some people might think that a bug. >> Yes, that's unfortunate. I've made another version that uses a second sentinel for the default sized but empty case. >> >> Now I want to reduce the ensureCapacity reallocations! It seems like insane churn to replace the arrays that frequently. >>> There are more   changes that need to be reverted. >>> Else looks good. >>> - * More formally, returns the lowest index i such that >>> - * (o==null ? get(i)==null : o.equals(get(i))), >>> + * More formally, returns the lowest index {@code i} such that >>> + * {@code (o==null ? get(i)==null : o.equals(get(i)))}, >> >> Corrected. Thank you. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8035584/2/webrev/ >> >> >> Mike >> >> >> >>> >>> >>> On Tue, Mar 11, 2014 at 5:20 PM, Mike Duigou wrote: >>> I've actually always used scp. :-) >>> >>> Since I accepted all of your changes as suggested and had no other changes I was just going to go ahead and push once testing was done. >>> >>> I've now prepared a revised webrev and can still accept feedback. >>> >>> http://cr.openjdk.java.net/~mduigou/JDK-8035584/1/webrev/ >>> >>> (Note: The webrev also contains https://bugs.openjdk.java.net/browse/JDK-8037097 since I am testing/pushing the two issues together.) >>> >>> Mike >>> >>> On Mar 11 2014, at 16:42 , Martin Buchholz wrote: >>> >>>> I don't see the updated webrev. Maybe you also fell victim to "rsync to cr no longer working"? >>>> >>>> >>>> On Tue, Mar 11, 2014 at 4:34 PM, Mike Duigou wrote: >>>> >>>> On Feb 21 2014, at 14:56 , Martin Buchholz wrote: >>>> >>>>> You should do -> code conversion separately, and do it pervasively across the entire JDK. >>>> >>>> From your lips to God's ears.... I keep suggesting this along with a restyle to official style every time we create new repos. Seems unlikely unfortunately as it makes backports harder. >>>> >>>>> This is not right. >>>>> + * {@code (o==null ? get(i)==null : o.equals(get(i)))} >>>> >>>> Corrected. >>>> >>>>> You accidentally deleted a stray space here? >>>>> >>>>> - this.elementData = EMPTY_ELEMENTDATA; >>>>> + this.elementData = EMPTY_ELEMENTDATA; >>>> >>>> Corrected. >>>> >>>>> public ArrayList(int initialCapacity) { >>>>> - super(); >>>>> if (initialCapacity < 0) >>>>> throw new IllegalArgumentException("Illegal Capacity: "+ >>>>> initialCapacity); >>>>> - this.elementData = new Object[initialCapacity]; >>>>> + this.elementData = (initialCapacity > 0) >>>>> + ? new Object[initialCapacity] >>>>> + : EMPTY_ELEMENTDATA; >>>>> } >>>>> >>>>> When optimizing for special cases, we should try very hard minimize overhead in the common case. In the above, we now have two branches in the common case. Instead, >>>>> >>>>> if (initialCapacity > 0) this.elementData = new Object[initialCapacity]; >>>>> else if (initialCapacity == 0) this.elementData = EMPTY_ELEMENTDATA; >>>>> else barf >>>> >>>> Corrected. >>>> >>>> Thanks as always for the feedback. >>>> >>>> Mike >>>> >>>>> >>>>> >>>>> >>>>> On Fri, Feb 21, 2014 at 2:41 PM, Mike Duigou wrote: >>>>> Hello all; >>>>> >>>>> This changeset consists of two small performance improvements for ArrayList. Both are related to the lazy initialization introduced in JDK-8011200. >>>>> >>>>> The first change is in the ArrayList(int capacity) constructor and forces lazy initialization if the requested capacity is zero. It's been observed that in cases where zero capacity is requested that it is very likely that the list never receives any elements. For these cases we permanently avoid the allocation of an element array. >>>>> >>>>> The second change, noticed by Gustav ?kesson, involves the ArrayList(Collection c) constructor. If c is an empty collection then there is no reason to inflate the backing array for the ArrayList. >>>>> >>>>> http://cr.openjdk.java.net/~mduigou/JDK-8035584/0/webrev/ >>>>> >>>>> I also took the opportunity to the -> {@code } conversion for the javadoc. >>>>> >>>>> Enjoy! >>>>> >>>>> Mike >>>>> >>>> >>>> >>> >>> >> > > > > -- - DML From ivan.gerasimov at oracle.com Thu Mar 13 16:15:50 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 13 Mar 2014 20:15:50 +0400 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <123FE971-9F74-43E6-988A-86D9A1804C68@oracle.com> References: <5321CEE6.403@oracle.com> <123FE971-9F74-43E6-988A-86D9A1804C68@oracle.com> Message-ID: <5321D9B6.2050301@oracle.com> Thank you Chris! It is System.arraycopy() method, where checking is performed and the exception is thrown. Here's this code: if ( (((unsigned int) length + (unsigned int) src_pos) > (unsigned int) s->length()) || (((unsigned int) length + (unsigned int) dst_pos) > (unsigned int) d->length()) ) { THROW(vmSymbols::java_lang_ArrayIndexOutOfBoundsException()); } This confirms that size() is a valid value for fromIndex. Another way to think of it is that fromIndex <= toIndex, and toIndex can be equal to size(). Therefore, fromIndex can be equal to size() too. The documentation also says that 'If toIndex==fromIndex, this operation has no effect.', so removeRange(size(), size()) is a valid expression and should not cause an exception be thrown (and it actually does not). Sincerely yours, Ivan On 13.03.2014 19:47, Chris Hegarty wrote: > Ivan, > > This does look a little odd, but since fromIndex is inclusive I would think that it should throw if passed a value of size() ?? > > -Chris. > > On 13 Mar 2014, at 15:29, Ivan Gerasimov wrote: > >> Hello! >> >> Would you please review a simple fix of the javadoc for ArrayList#removeRange() method? >> >> The doc says that IndexOutOfBoundsException is thrown if fromIndex or toIndex is out of range (fromIndex < 0 || fromIndex >= size() || toIndex > size() || toIndex < fromIndex). >> >> The condition 'fromIndex >= size()' isn't true and should be removed from the doc. >> >> For example, the code list.removeRange(size(), size()) does not throw any exception. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8014066 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8014066/0/webrev/ >> >> Sincerely yours, >> Ivan > > From aph at redhat.com Thu Mar 13 16:26:59 2014 From: aph at redhat.com (Andrew Haley) Date: Thu, 13 Mar 2014 16:26:59 +0000 Subject: Unsafe: efficiently comparing two byte arrays In-Reply-To: References: <530F5136.20405@redhat.com> <8D3E2037-E5D1-4D2E-B779-E7EDD2AF4F58@oracle.com> <530F55CA.3060302@redhat.com> <5321A258.6080602@redhat.com> <5321AB43.6040008@redhat.com> Message-ID: <5321DC53.3080906@redhat.com> On 03/13/2014 02:19 PM, Paul Sandoz wrote: > > On Mar 13, 2014, at 1:57 PM, Andrew Haley wrote: > >> On 03/13/2014 12:49 PM, Paul Sandoz wrote: >>> On Mar 13, 2014, at 1:19 PM, Andrew Haley wrote: >>>> On 03/13/2014 11:57 AM, Paul Sandoz wrote: >>>>> Now i am in two minds to whether to add ByteBuffer.compareUnsigned or add Arrays.compareUnsigned. >>>>> >>>>> An explosion of methods on Arrays for all types (plus to/from versions) would be annoying. >>>> >>>> Surely it's a no brainer? All we have to do is add the intrinsics for >>>> ByteBuffers, then we get fast ByteBuffers and fast array comparisons too. >>>> I don't see the problem. >>> >>> For byte[] comparison, I don't think optimal long access is >>> sufficient on it's own due to alignment issues. It would be nice if >>> we can avoid burdening users with alignment issues to ensure the >>> main comparison loop is efficient. >> >> But alignment issues are a feature of the hardware, not of software. >> The problem right now is that ByteBuffers use a byte-by-byte >> comparison of longs, even when it isn't needed, because there aren't >> the intrinsics. > > I was considering the following case: > > byte[] b1 = ... > byte[] b2 = ... > // compare from offset > ByteBuffer left = ByteBuffer.wrap(b1, 1, b1.length - 1); > ByteBuffer right = ByteBuffer.wrap(b2, 1, b2.length - 1); > int r = compare(left, right); > > static int compare(ByteBuffer left, ByteBuffer right) { > int minLength = Math.min(left.remaining(), right.remaining()); > int minWords = minLength / 8; > > for (int i = 0; i < minWords * 8; i += 8) { > long lw = left.getLong(); // Inefficient when unaligned access is not supported by hardware? Possibly, but HotSpot can do an awful lot with specialization when offsets are known. > long rw = right.getLong(); // Are bounds checks hoisted out? i presume so Yes. > if (lw != rw) { > return Long.compareUnsigned(lw, rw); > } > } > > for (int i = minWords * 8; i < minLength; i++) { > int result = Byte.toUnsignedInt(left.get()) - Byte.toUnsignedInt(right.get()); > if (result != 0) { > return result; > } > } > > return left.remaining() - right.remaining(); > } > > Certain Apache code (e.g. see Cassandra) supports comparing byte[] > arrays with offsets and i am not sure that code is portable [1]. > > I was wondering in the case where the hardware does not support > unaligned access it might be possible to sill optimize by reading > longs at aligned positions and doing some some extra bit twiddling. Probably, but given that the offsets of two strings don't have to be the same, it can get very messy. >>> A quick solution is to leverage Unsafe within a >>> ByteBuffer.compareUnsigned method. In fact i believe Unsafe could be >>> used (as Aleksey says in [1]) for put/get as well, which i presume >>> is likely to be much easier/quicker to implement. Might be a good >>> first step until a more superior intrinsics solution is implemented? >> >> I still don't get it, sorry. What can Unsafe do that ByteBuffer >> intrinsics can't do? > > We can arguably implement it faster [2] I doubt that very much. In fact, I would say that it is almost certainly not true. HotSpot usually knows, for example, when both offsets are zero and can generate better code for machines with strict alignment. And also, Unsafe has the same speed problems with unaligned data that an intrinsic would have. > and i presume it will be simpler too. And that. But the key point is this: we want intrinsics for ByteBuffers anyway. Andrew. From aph at redhat.com Thu Mar 13 16:29:16 2014 From: aph at redhat.com (Andrew Haley) Date: Thu, 13 Mar 2014 16:29:16 +0000 Subject: Unsafe: efficiently comparing two byte arrays In-Reply-To: <5321BFFB.1060009@redhat.com> References: <530F5136.20405@redhat.com> <8D3E2037-E5D1-4D2E-B779-E7EDD2AF4F58@oracle.com> <530F55CA.3060302@redhat.com> <5321A258.6080602@redhat.com> <5321BFFB.1060009@redhat.com> Message-ID: <5321DCDC.6020805@redhat.com> On 03/13/2014 02:26 PM, David M. Lloyd wrote: > On 03/13/2014 07:19 AM, Andrew Haley wrote: >> On 03/13/2014 11:57 AM, Paul Sandoz wrote: >>> Now i am in two minds to whether to add ByteBuffer.compareUnsigned or add Arrays.compareUnsigned. >>> >>> An explosion of methods on Arrays for all types (plus to/from versions) would be annoying. >> >> Surely it's a no brainer? All we have to do is add the intrinsics for >> ByteBuffers, then we get fast ByteBuffers and fast array comparisons too. >> I don't see the problem. > > Why such a hangup on ByteBuffers and Arrays? I think it'd be super > useful to simply have methods on Long, Integer, etc: > > public static void getBytesBE(long orig, byte[] dst, int off) > public static void getBytesLE(long orig, byte[] dst, int off) > > public static int compareBE(long orig, byte[] other, int off) > public static int compareLE(long orig, byte[] other, int off) > > public static long getLongFromBytesBE(byte[] src, int off) > public static long getLongFromBytesLE(byte[] src, int off) I take your point, but this is a whole lot of new library work, both in implementation and specification, whereas we already have this in ByteBuffers, albeit with a suboptimal implementation. Andrew. From martinrb at google.com Thu Mar 13 16:34:40 2014 From: martinrb at google.com (Martin Buchholz) Date: Thu, 13 Mar 2014 09:34:40 -0700 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <5321CEE6.403@oracle.com> References: <5321CEE6.403@oracle.com> Message-ID: I notice there are zero jtreg tests for removeRange. That should be fixed. I notice there is a removeRange in CopyOnWriteArrayList, but it is package-private instead of "protected", which seems like an oversight. Can Doug remember any history on that? I notice that AbstractList.removeRange contains no @throws. That should be fixed? The existing @throws javadoc from CopyOnWriteArrayList seems better: * @throws IndexOutOfBoundsException if fromIndex or toIndex out of range * ({@code fromIndex < 0 || toIndex > size() || toIndex < fromIndex}) This paragraph in AbstractList *

This method is called by the {@code clear} operation on this list * and its subLists. Overriding this method to take advantage of * the internals of the list implementation can substantially * improve the performance of the {@code clear} operation on this list * and its subLists. looks like it belongs inside the @implSpec (it's not a requirement on subclasses) ObTesting (a start) import java.util.*; public class RemoveRange { static class PublicArrayList extends ArrayList { PublicArrayList(int cap) { super(cap); } public void removeRange(int fromIndex, int toIndex) { super.removeRange(fromIndex, toIndex); } } public static void main(String[] args) throws Throwable { PublicArrayList x = new PublicArrayList(11); for (int i = 0; i < 11; i++) x.add(null); x.removeRange(x.size(), x.size()); } } On Thu, Mar 13, 2014 at 8:29 AM, Ivan Gerasimov wrote: > Hello! > > Would you please review a simple fix of the javadoc for > ArrayList#removeRange() method? > > The doc says that IndexOutOfBoundsException is thrown if fromIndex or > toIndex is out of range (fromIndex < 0 || fromIndex >= size() || toIndex > > size() || toIndex < fromIndex). > > The condition 'fromIndex >= size()' isn't true and should be removed from > the doc. > > For example, the code list.removeRange(size(), size()) does not throw any > exception. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8014066 > WEBREV: http://cr.openjdk.java.net/~igerasim/8014066/0/webrev/ > > Sincerely yours, > Ivan > From martinrb at google.com Thu Mar 13 16:37:46 2014 From: martinrb at google.com (Martin Buchholz) Date: Thu, 13 Mar 2014 09:37:46 -0700 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <5321D9B6.2050301@oracle.com> References: <5321CEE6.403@oracle.com> <123FE971-9F74-43E6-988A-86D9A1804C68@oracle.com> <5321D9B6.2050301@oracle.com> Message-ID: The corner case for removeRange(SIZE, SIZE) does seem rather tricky, and it's easy for an implementation to get it wrong. All the more reason to add tests! On Thu, Mar 13, 2014 at 9:15 AM, Ivan Gerasimov wrote: > Thank you Chris! > > It is System.arraycopy() method, where checking is performed and the > exception is thrown. > Here's this code: > if ( (((unsigned int) length + (unsigned int) src_pos) > (unsigned int) > s->length()) > || (((unsigned int) length + (unsigned int) dst_pos) > (unsigned int) > d->length()) ) { > THROW(vmSymbols::java_lang_ArrayIndexOutOfBoundsException()); > } > > This confirms that size() is a valid value for fromIndex. > > Another way to think of it is that fromIndex <= toIndex, and toIndex can > be equal to size(). > Therefore, fromIndex can be equal to size() too. > > The documentation also says that 'If toIndex==fromIndex, this operation > has no effect.', so removeRange(size(), size()) is a valid expression and > should not cause an exception be thrown (and it actually does not). > > Sincerely yours, > Ivan > > > On 13.03.2014 19:47, Chris Hegarty wrote: > >> Ivan, >> >> This does look a little odd, but since fromIndex is inclusive I would >> think that it should throw if passed a value of size() ?? >> >> -Chris. >> >> On 13 Mar 2014, at 15:29, Ivan Gerasimov >> wrote: >> >> Hello! >>> >>> Would you please review a simple fix of the javadoc for >>> ArrayList#removeRange() method? >>> >>> The doc says that IndexOutOfBoundsException is thrown if fromIndex or >>> toIndex is out of range (fromIndex < 0 || fromIndex >= size() || toIndex > >>> size() || toIndex < fromIndex). >>> >>> The condition 'fromIndex >= size()' isn't true and should be removed >>> from the doc. >>> >>> For example, the code list.removeRange(size(), size()) does not throw >>> any exception. >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8014066 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8014066/0/webrev/ >>> >>> Sincerely yours, >>> Ivan >>> >> >> >> > From martinrb at google.com Thu Mar 13 16:53:41 2014 From: martinrb at google.com (Martin Buchholz) Date: Thu, 13 Mar 2014 09:53:41 -0700 Subject: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty In-Reply-To: References: <0541A3EA-A2A5-4977-8054-4EDB28366216@oracle.com> <318A3363-C4F6-42D5-99CD-DB6D00766B0C@oracle.com> <8FD1E74E-B433-475E-8DF6-3CB7126698AC@oracle.com> <4DC7C9B0-43F2-4FFF-A8D6-CFD1B54ED158@oracle.com> <9CBC797D-F5E2-42CD-B050-A0A706DFDBD4@oracle.com> Message-ID: It's time to add general purpose public static final empty arrays to Arrays.java for Object, all the primitive types, and perhaps also String, instead of local copies scattered around the JDK; then have ArrayList use Arrays.EMPTY_OBJECT_ARRAY. On Thu, Mar 13, 2014 at 8:56 AM, Jason Mehrens wrote: > Mike, > > The constructor modification looks good. The only other alternative I can > think would be to use 'c.toArray(EMPTY_ELEMENTDATA)' to avoid creating an > extra array. I'm guessing that version would not perform as well as your > current version. > > The modification for toArray violates the List contract because the > returned array must be safe (must use 'new' and must not retain > reference). I think you'll have to back out that change. Contract > violation aside, the only case that I can see that might unsafe for an > empty array would be acquiring the monitor of EMPTY_ELEMENTDATA array. > When we patched the Collections$EmptyXXX classes we avoided returning a > cached empty array for this reason. > > Jason > > ------------------------------ > Subject: Re: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is > empty > From: mike.duigou at oracle.com > Date: Wed, 12 Mar 2014 12:41:00 -0700 > CC: martinrb at google.com; core-libs-dev at openjdk.java.net > To: jason_mehrens at hotmail.com > > > Hi Jason,' > > Using isEmpty() was intended to save the array creation but you make a > valid point regarding correctness. I have amended the webrev. This handling > suggests that it would useful for implementation to cache the empty result > for toArray() and I have also added this to ArrayList's toArray. > > http://cr.openjdk.java.net/~mduigou/JDK-8035584/3/webrev/ > > Mike > > On Mar 12 2014, at 07:06 , Jason Mehrens > wrote: > > Mike, > > In the constructor do you think you should skip the call to isEmpty and > just check the length of toArray? Seems like since the implementation of > the given collection is unknown it is probably best to perform as little > interaction with it as possible. Also it would be possible for isEmpty to > return false followed by toArray returning a zero length array that is > different from cached copies. > > Jason > > > Subject: Re: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c > is empty > > From: mike.duigou at oracle.com > > Date: Tue, 11 Mar 2014 18:18:26 -0700 > > To: martinrb at google.com > > CC: core-libs-dev at openjdk.java.net > > > > > > On Mar 11 2014, at 17:42 , Martin Buchholz wrote: > > > > > I'm hoping y'all have evidence that empty ArrayLists are common in the > wild. > > Yes, certainly. From the original proposal: > > > [This change] based upon analysis that shows that in large > applications as much as 10% of maps and lists are initialized but never > receive any entries. A smaller number spend a large proportion of their > lifetime empty. We've found similar results across other workloads as well. > > > > > It is curious that empty lists grow immediately to 10, while ArrayList > with capacity 1 grows to 2, then 3... Some people might think that a bug. > > Yes, that's unfortunate. I've made another version that uses a second > sentinel for the default sized but empty case. > > > > Now I want to reduce the ensureCapacity reallocations! It seems like > insane churn to replace the arrays that frequently. > > > There are more   changes that need to be reverted. > > > Else looks good. > > > - * More formally, returns the lowest index i such that > > > - * > (o==null ? get(i)==null : o.equals(get(i))), > > > + * More formally, returns the lowest index {@code i} such that > > > + * {@code > (o==null ? get(i)==null : o.equals(get(i)))}, > > > > Corrected. Thank you. > > > > http://cr.openjdk.java.net/~mduigou/JDK-8035584/2/webrev/ > > > > > > Mike > > > > > > > > > > > > > > > On Tue, Mar 11, 2014 at 5:20 PM, Mike Duigou > wrote: > > > I've actually always used scp. :-) > > > > > > Since I accepted all of your changes as suggested and had no other > changes I was just going to go ahead and push once testing was done. > > > > > > I've now prepared a revised webrev and can still accept feedback. > > > > > > http://cr.openjdk.java.net/~mduigou/JDK-8035584/1/webrev/ > > > > > > (Note: The webrev also contains > https://bugs.openjdk.java.net/browse/JDK-8037097 since I am > testing/pushing the two issues together.) > > > > > > Mike > > > > > > On Mar 11 2014, at 16:42 , Martin Buchholz > wrote: > > > > > >> I don't see the updated webrev. Maybe you also fell victim to "rsync > to cr no longer working"? > > >> > > >> > > >> On Tue, Mar 11, 2014 at 4:34 PM, Mike Duigou > wrote: > > >> > > >> On Feb 21 2014, at 14:56 , Martin Buchholz > wrote: > > >> > > >>> You should do -> code conversion separately, and do it > pervasively across the entire JDK. > > >> > > >> From your lips to God's ears.... I keep suggesting this along with a > restyle to official style every time we create new repos. Seems unlikely > unfortunately as it makes backports harder. > > >> > > >>> This is not right. > > >>> + * {@code > (o==null ? get(i)==null : o.equals(get(i)))} > > >> > > >> Corrected. > > >> > > >>> You accidentally deleted a stray space here? > > >>> > > >>> - this.elementData = EMPTY_ELEMENTDATA; > > >>> + this.elementData = EMPTY_ELEMENTDATA; > > >> > > >> Corrected. > > >> > > >>> public ArrayList(int initialCapacity) { > > >>> - super(); > > >>> if (initialCapacity < 0) > > >>> throw new IllegalArgumentException("Illegal Capacity: "+ > > >>> initialCapacity); > > >>> - this.elementData = new Object[initialCapacity]; > > >>> + this.elementData = (initialCapacity > 0) > > >>> + ? new Object[initialCapacity] > > >>> + : EMPTY_ELEMENTDATA; > > >>> } > > >>> > > >>> When optimizing for special cases, we should try very hard minimize > overhead in the common case. In the above, we now have two branches in the > common case. Instead, > > >>> > > >>> if (initialCapacity > 0) this.elementData = new > Object[initialCapacity]; > > >>> else if (initialCapacity == 0) this.elementData = EMPTY_ELEMENTDATA; > > >>> else barf > > >> > > >> Corrected. > > >> > > >> Thanks as always for the feedback. > > >> > > >> Mike > > >> > > >>> > > >>> > > >>> > > >>> On Fri, Feb 21, 2014 at 2:41 PM, Mike Duigou > wrote: > > >>> Hello all; > > >>> > > >>> This changeset consists of two small performance improvements for > ArrayList. Both are related to the lazy initialization introduced in > JDK-8011200. > > >>> > > >>> The first change is in the ArrayList(int capacity) constructor and > forces lazy initialization if the requested capacity is zero. It's been > observed that in cases where zero capacity is requested that it is very > likely that the list never receives any elements. For these cases we > permanently avoid the allocation of an element array. > > >>> > > >>> The second change, noticed by Gustav ?kesson, involves the > ArrayList(Collection c) constructor. If c is an empty collection then there > is no reason to inflate the backing array for the ArrayList. > > >>> > > >>> http://cr.openjdk.java.net/~mduigou/JDK-8035584/0/webrev/ > > >>> > > >>> I also took the opportunity to the -> {@code } conversion > for the javadoc. > > >>> > > >>> Enjoy! > > >>> > > >>> Mike > > >>> > > >> > > >> > > > > > > > > > > > From ivan.gerasimov at oracle.com Thu Mar 13 17:00:02 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 13 Mar 2014 21:00:02 +0400 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: References: <5321CEE6.403@oracle.com> Message-ID: <5321E412.6070204@oracle.com> Thank you Martin for your feedback! I'll add the test with the next webrev. Here's the test I used to check that the exception isn't thrown: class Test extends java.util.ArrayList { public static void main(String[] args) throws Throwable { Test list = new Test(); list.add(1); list.removeRange(list.size(), list.size()); } } Sincerely yours, Ivan On 13.03.2014 20:34, Martin Buchholz wrote: > I notice there are zero jtreg tests for removeRange. That should be > fixed. > > I notice there is a removeRange in CopyOnWriteArrayList, but it is > package-private instead of "protected", which seems like an oversight. > Can Doug remember any history on that? > > I notice that AbstractList.removeRange contains no @throws. That > should be fixed? > > The existing @throws javadoc from CopyOnWriteArrayList seems better: > > * @throws IndexOutOfBoundsException if fromIndex or toIndex out > of range > * ({@code fromIndex < 0 || toIndex > size() || toIndex < > fromIndex}) > > This paragraph in AbstractList > > *

This method is called by the {@code clear} operation on this > list > * and its subLists. Overriding this method to take advantage of > * the internals of the list implementation can substantially > * improve the performance of the {@code clear} operation on this list > * and its subLists. > > looks like it belongs inside the @implSpec (it's not a requirement on > subclasses) > > ObTesting (a start) > > import java.util.*; > > public class RemoveRange { > static class PublicArrayList extends ArrayList { > PublicArrayList(int cap) { super(cap); } > public void removeRange(int fromIndex, int toIndex) { > super.removeRange(fromIndex, toIndex); > } > } > public static void main(String[] args) throws Throwable { > PublicArrayList x = new PublicArrayList(11); > for (int i = 0; i < 11; i++) x.add(null); > x.removeRange(x.size(), x.size()); > } > } > > > > > On Thu, Mar 13, 2014 at 8:29 AM, Ivan Gerasimov > > wrote: > > Hello! > > Would you please review a simple fix of the javadoc for > ArrayList#removeRange() method? > > The doc says that IndexOutOfBoundsException is thrown if fromIndex > or toIndex is out of range (fromIndex < 0 || fromIndex >= size() > || toIndex > size() || toIndex < fromIndex). > > The condition 'fromIndex >= size()' isn't true and should be > removed from the doc. > > For example, the code list.removeRange(size(), size()) does not > throw any exception. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8014066 > WEBREV: http://cr.openjdk.java.net/~igerasim/8014066/0/webrev/ > > > Sincerely yours, > Ivan > > From paul.sandoz at oracle.com Thu Mar 13 17:02:11 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 13 Mar 2014 18:02:11 +0100 Subject: Unsafe: efficiently comparing two byte arrays In-Reply-To: <5321DC53.3080906@redhat.com> References: <530F5136.20405@redhat.com> <8D3E2037-E5D1-4D2E-B779-E7EDD2AF4F58@oracle.com> <530F55CA.3060302@redhat.com> <5321A258.6080602@redhat.com> <5321AB43.6040008@redhat.com> <5321DC53.3080906@redhat.com> Message-ID: <36FF3557-C153-4B30-8F25-4CED60399549@oracle.com> On Mar 13, 2014, at 5:26 PM, Andrew Haley wrote: > >>>> A quick solution is to leverage Unsafe within a >>>> ByteBuffer.compareUnsigned method. In fact i believe Unsafe could be >>>> used (as Aleksey says in [1]) for put/get as well, which i presume >>>> is likely to be much easier/quicker to implement. Might be a good >>>> first step until a more superior intrinsics solution is implemented? >>> >>> I still don't get it, sorry. What can Unsafe do that ByteBuffer >>> intrinsics can't do? >> >> We can arguably implement it faster [2] > > I doubt that very much. In fact, I would say that it is almost > certainly not true. HotSpot usually knows, for example, when both > offsets are zero and can generate better code for machines with strict > alignment. > > And also, Unsafe has the same speed problems with unaligned data > that an intrinsic would have. > I meant i can *implement* a comparison solution using Unsafe faster than i can implement a more general solution using intrinsics. I presume intrinsics might be of great advantage if SIMD instructions can be leveraged? if not would it be reasonable to assume that for common 0 offset case the two solutions might be similar in terms of performance? >> and i presume it will be simpler too. > > And that. > > But the key point is this: we want intrinsics for ByteBuffers anyway. > Yeah, but i think that could take longer and there is also the Arrays 2.0 work to consider, the scope is considerably larger than providing an efficient comparison method for byte[] arrays. It is possible to tackle this simple use-case with an API tweak (ByteBuffer.compareUnsigned) and revisit the implementation if/when instincts for arrays get into 9. That is a small but useful step in the right direction. Paul. From aph at redhat.com Thu Mar 13 17:17:27 2014 From: aph at redhat.com (Andrew Haley) Date: Thu, 13 Mar 2014 17:17:27 +0000 Subject: Unsafe: efficiently comparing two byte arrays In-Reply-To: <36FF3557-C153-4B30-8F25-4CED60399549@oracle.com> References: <530F5136.20405@redhat.com> <8D3E2037-E5D1-4D2E-B779-E7EDD2AF4F58@oracle.com> <530F55CA.3060302@redhat.com> <5321A258.6080602@redhat.com> <5321AB43.6040008@redhat.com> <5321DC53.3080906@redhat.com> <36FF3557-C153-4B30-8F25-4CED60399549@oracle.com> Message-ID: <5321E827.1060006@redhat.com> On 03/13/2014 05:02 PM, Paul Sandoz wrote: > On Mar 13, 2014, at 5:26 PM, Andrew Haley wrote: >> >>>>> A quick solution is to leverage Unsafe within a >>>>> ByteBuffer.compareUnsigned method. In fact i believe Unsafe could be >>>>> used (as Aleksey says in [1]) for put/get as well, which i presume >>>>> is likely to be much easier/quicker to implement. Might be a good >>>>> first step until a more superior intrinsics solution is implemented? >>>> >>>> I still don't get it, sorry. What can Unsafe do that ByteBuffer >>>> intrinsics can't do? >>> >>> We can arguably implement it faster [2] >> >> I doubt that very much. In fact, I would say that it is almost >> certainly not true. HotSpot usually knows, for example, when both >> offsets are zero and can generate better code for machines with strict >> alignment. >> >> And also, Unsafe has the same speed problems with unaligned data >> that an intrinsic would have. > > I meant i can *implement* a comparison solution using Unsafe faster > than i can implement a more general solution using intrinsics. I see. Yes, what you said is clear, now I read it again. :-) > I presume intrinsics might be of great advantage if SIMD > instructions can be leveraged? if not would it be reasonable to > assume that for common 0 offset case the two solutions might be > similar in terms of performance? That's hard to say for sure. It might well be so, but I suspect you'll hit memor bandwidth limits in both cases. > Yeah, but i think that could take longer and there is also the > Arrays 2.0 work to consider, the scope is considerably larger than > providing an efficient comparison method for byte[] arrays. OK, so I think I understand now: you can do what you need without having to drag in HotSpot engineers. But Unsafe only works really efficiently when it is intrinsified. > It is possible to tackle this simple use-case with an API tweak > (ByteBuffer.compareUnsigned) and revisit the implementation if/when > instincts for arrays get into 9. That is a small but useful step in > the right direction. Ok, fair point. Andrew. From mattis.castegren at oracle.com Thu Mar 13 14:02:00 2014 From: mattis.castegren at oracle.com (Mattis Castegren) Date: Thu, 13 Mar 2014 07:02:00 -0700 (PDT) Subject: RFR: 8036786: Update jdk7 testlibrary to match jdk8 In-Reply-To: <5318956F.1020603@oracle.com> References: <5318956F.1020603@oracle.com> Message-ID: Hi Could we have someone review this change. This is just a backport from JDK8, but there were some small changes so we want to get a proper review here. We have several other backports waiting for this change (fixes using the new test libraries), so it would be good to get this going. Kind Regards /Mattis -----Original Message----- From: Vladimir Kempik Sent: den 6 mars 2014 16:34 To: core-libs-dev at openjdk.java.net Cc: Mattis Castegren Subject: RFR: 8036786: Update jdk7 testlibrary to match jdk8 Please review this change to update jdk part of testlibrary in jdk7. It updates testlibrary with new apis from jdk8's testlibrary. When porting jdk8's testlibrary to jdk7, I had to make few changes: 1) rewrite one lambda usage in StreamPumper.java to non-lambda version. 2) get rid of predicate functionality in ProcessTools.java: startProcess as it wasn't used anyway and unsupported in jdk7. Every test in open part of jdk that uses testlibrary still works after update (in fact there are 3 of them). Webrev: http://cr.openjdk.java.net/~vkempik/8036786/webrev.00/ Thanks, Vladimir. From ivan.gerasimov at oracle.com Thu Mar 13 18:16:00 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 13 Mar 2014 22:16:00 +0400 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: References: <5321CEE6.403@oracle.com> <123FE971-9F74-43E6-988A-86D9A1804C68@oracle.com> <5321D9B6.2050301@oracle.com> Message-ID: <5321F5E0.7000408@oracle.com> On 13.03.2014 20:37, Martin Buchholz wrote: > The corner case for removeRange(SIZE, SIZE) does seem rather tricky, > and it's easy for an implementation to get it wrong. All the more > reason to add tests! > It was a good idea to add a test for removeRange(). I just discovered that IOOB isn't thrown when you call removeRange(1, 0) or removeRange(4, 0). However, the exception is thrown when you call removeRange(5, 0). The fix seems to become a bit more than just a doc typo fix :-) Sincerely yours, Ivan > > On Thu, Mar 13, 2014 at 9:15 AM, Ivan Gerasimov > > wrote: > > Thank you Chris! > > It is System.arraycopy() method, where checking is performed and > the exception is thrown. > Here's this code: > if ( (((unsigned int) length + (unsigned int) src_pos) > > (unsigned int) s->length()) > || (((unsigned int) length + (unsigned int) dst_pos) > > (unsigned int) d->length()) ) { > THROW(vmSymbols::java_lang_ArrayIndexOutOfBoundsException()); > } > > This confirms that size() is a valid value for fromIndex. > > Another way to think of it is that fromIndex <= toIndex, and > toIndex can be equal to size(). > Therefore, fromIndex can be equal to size() too. > > The documentation also says that 'If toIndex==fromIndex, this > operation has no effect.', so removeRange(size(), size()) is a > valid expression and should not cause an exception be thrown (and > it actually does not). > > Sincerely yours, > Ivan > > > On 13.03.2014 19:47, Chris Hegarty wrote: > > Ivan, > > This does look a little odd, but since fromIndex is inclusive > I would think that it should throw if passed a value of size() ?? > > -Chris. > > On 13 Mar 2014, at 15:29, Ivan Gerasimov > > > wrote: > > Hello! > > Would you please review a simple fix of the javadoc for > ArrayList#removeRange() method? > > The doc says that IndexOutOfBoundsException is thrown if > fromIndex or toIndex is out of range (fromIndex < 0 || > fromIndex >= size() || toIndex > size() || toIndex < > fromIndex). > > The condition 'fromIndex >= size()' isn't true and should > be removed from the doc. > > For example, the code list.removeRange(size(), size()) > does not throw any exception. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8014066 > WEBREV: > http://cr.openjdk.java.net/~igerasim/8014066/0/webrev/ > > > Sincerely yours, > Ivan > > > > > From ivan.gerasimov at oracle.com Thu Mar 13 18:27:07 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 13 Mar 2014 22:27:07 +0400 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <5321F5E0.7000408@oracle.com> References: <5321CEE6.403@oracle.com> <123FE971-9F74-43E6-988A-86D9A1804C68@oracle.com> <5321D9B6.2050301@oracle.com> <5321F5E0.7000408@oracle.com> Message-ID: <5321F87B.8010300@oracle.com> On 13.03.2014 22:16, Ivan Gerasimov wrote: > > On 13.03.2014 20:37, Martin Buchholz wrote: >> The corner case for removeRange(SIZE, SIZE) does seem rather tricky, >> and it's easy for an implementation to get it wrong. All the more >> reason to add tests! >> > It was a good idea to add a test for removeRange(). > I just discovered that IOOB isn't thrown when you call removeRange(1, > 0) or removeRange(4, 0). > However, the exception is thrown when you call removeRange(5, 0). > > The fix seems to become a bit more than just a doc typo fix :-) > And when you do list.removeRange(1, 0), the list becomes longer. > Sincerely yours, > Ivan > >> >> On Thu, Mar 13, 2014 at 9:15 AM, Ivan Gerasimov >> > wrote: >> >> Thank you Chris! >> >> It is System.arraycopy() method, where checking is performed and >> the exception is thrown. >> Here's this code: >> if ( (((unsigned int) length + (unsigned int) src_pos) > >> (unsigned int) s->length()) >> || (((unsigned int) length + (unsigned int) dst_pos) > >> (unsigned int) d->length()) ) { >> THROW(vmSymbols::java_lang_ArrayIndexOutOfBoundsException()); >> } >> >> This confirms that size() is a valid value for fromIndex. >> >> Another way to think of it is that fromIndex <= toIndex, and >> toIndex can be equal to size(). >> Therefore, fromIndex can be equal to size() too. >> >> The documentation also says that 'If toIndex==fromIndex, this >> operation has no effect.', so removeRange(size(), size()) is a >> valid expression and should not cause an exception be thrown (and >> it actually does not). >> >> Sincerely yours, >> Ivan >> >> >> On 13.03.2014 19:47, Chris Hegarty wrote: >> >> Ivan, >> >> This does look a little odd, but since fromIndex is inclusive >> I would think that it should throw if passed a value of >> size() ?? >> >> -Chris. >> >> On 13 Mar 2014, at 15:29, Ivan Gerasimov >> > >> wrote: >> >> Hello! >> >> Would you please review a simple fix of the javadoc for >> ArrayList#removeRange() method? >> >> The doc says that IndexOutOfBoundsException is thrown if >> fromIndex or toIndex is out of range (fromIndex < 0 || >> fromIndex >= size() || toIndex > size() || toIndex < >> fromIndex). >> >> The condition 'fromIndex >= size()' isn't true and should >> be removed from the doc. >> >> For example, the code list.removeRange(size(), size()) >> does not throw any exception. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8014066 >> WEBREV: >> http://cr.openjdk.java.net/~igerasim/8014066/0/webrev/ >> >> >> Sincerely yours, >> Ivan >> >> >> >> >> > > > From ivan.gerasimov at oracle.com Thu Mar 13 19:03:25 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 13 Mar 2014 23:03:25 +0400 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <5321F87B.8010300@oracle.com> References: <5321CEE6.403@oracle.com> <123FE971-9F74-43E6-988A-86D9A1804C68@oracle.com> <5321D9B6.2050301@oracle.com> <5321F5E0.7000408@oracle.com> <5321F87B.8010300@oracle.com> Message-ID: <532200FD.9060705@oracle.com> Would you please take a look at the updated webrev: http://cr.openjdk.java.net/~igerasim/8014066/1/webrev/ In addition to the javadoc correction, it includes a regression test and a check for (fromIndex > toIndex). The last check turns out to be sufficient for removeRange() method to agree with the javadoc. Other checks are handled by the following System.arraycopy() call. Sincerely yours, Ivan On 13.03.2014 22:27, Ivan Gerasimov wrote: > > On 13.03.2014 22:16, Ivan Gerasimov wrote: >> >> On 13.03.2014 20:37, Martin Buchholz wrote: >>> The corner case for removeRange(SIZE, SIZE) does seem rather tricky, >>> and it's easy for an implementation to get it wrong. All the more >>> reason to add tests! >>> >> It was a good idea to add a test for removeRange(). >> I just discovered that IOOB isn't thrown when you call removeRange(1, >> 0) or removeRange(4, 0). >> However, the exception is thrown when you call removeRange(5, 0). >> >> The fix seems to become a bit more than just a doc typo fix :-) >> > > And when you do list.removeRange(1, 0), the list becomes longer. > > >> Sincerely yours, >> Ivan >> >>> >>> On Thu, Mar 13, 2014 at 9:15 AM, Ivan Gerasimov >>> > wrote: >>> >>> Thank you Chris! >>> >>> It is System.arraycopy() method, where checking is performed and >>> the exception is thrown. >>> Here's this code: >>> if ( (((unsigned int) length + (unsigned int) src_pos) > >>> (unsigned int) s->length()) >>> || (((unsigned int) length + (unsigned int) dst_pos) > >>> (unsigned int) d->length()) ) { >>> THROW(vmSymbols::java_lang_ArrayIndexOutOfBoundsException()); >>> } >>> >>> This confirms that size() is a valid value for fromIndex. >>> >>> Another way to think of it is that fromIndex <= toIndex, and >>> toIndex can be equal to size(). >>> Therefore, fromIndex can be equal to size() too. >>> >>> The documentation also says that 'If toIndex==fromIndex, this >>> operation has no effect.', so removeRange(size(), size()) is a >>> valid expression and should not cause an exception be thrown (and >>> it actually does not). >>> >>> Sincerely yours, >>> Ivan >>> >>> >>> On 13.03.2014 19:47, Chris Hegarty wrote: >>> >>> Ivan, >>> >>> This does look a little odd, but since fromIndex is inclusive >>> I would think that it should throw if passed a value of >>> size() ?? >>> >>> -Chris. >>> >>> On 13 Mar 2014, at 15:29, Ivan Gerasimov >>> > >>> wrote: >>> >>> Hello! >>> >>> Would you please review a simple fix of the javadoc for >>> ArrayList#removeRange() method? >>> >>> The doc says that IndexOutOfBoundsException is thrown if >>> fromIndex or toIndex is out of range (fromIndex < 0 || >>> fromIndex >= size() || toIndex > size() || toIndex < >>> fromIndex). >>> >>> The condition 'fromIndex >= size()' isn't true and should >>> be removed from the doc. >>> >>> For example, the code list.removeRange(size(), size()) >>> does not throw any exception. >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8014066 >>> WEBREV: >>> http://cr.openjdk.java.net/~igerasim/8014066/0/webrev/ >>> >>> >>> Sincerely yours, >>> Ivan >>> >>> >>> >>> >>> >> >> >> > > > From john.r.rose at oracle.com Thu Mar 13 19:21:46 2014 From: john.r.rose at oracle.com (John Rose) Date: Thu, 13 Mar 2014 12:21:46 -0700 Subject: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods In-Reply-To: References: <530F50DA.3010308@javaspecialists.eu> <144A3A2D-85FF-4F3B-A4DA-1780B809F36B@oracle.com> <53172EE0.6030801@cs.oswego.edu> <48666F38-592B-4234-8EAD-67607F9C5BBD@oracle.com> <84EB259F-4835-478F-B055-BFEDB73EF40A@oracle.com> Message-ID: <72323F62-D84F-4AC7-9D60-4281B036731B@oracle.com> On Mar 13, 2014, at 4:21 AM, Paul Sandoz wrote: > On Mar 12, 2014, at 10:23 PM, John Rose wrote: >> P.S. FTR, I wish we could also remove the per-object monitor from its privileged position, so not all objects are burdened by it, and other forms of lock can be switched into the existing notation on a type-by-type basis. This is obviously a long, long term wish. A starting point is a notion of "this object has no monitor". > > Like an instance of a value type? Yes, and also a *boxed* instance of value type, yes. Like String or Integer, if I had my wish (incompatible change only for unreasonable code). Like the unenforced "value-based classes" of JDK 8, notably Optional. And frozen objects (JEP 169). http://download.java.net/jdk8/docs/api/java/lang/doc-files/ValueBased.html http://openjdk.java.net/jeps/169 ? John > Paul. > >> Probably the keyword cannot be repurposed but would eventually be deprecated. And the Moon will reach Roche limit. >> >> ? John >> >>> On Mar 12, 2014, at 2:12 PM, John Rose wrote: >>> >>> I think that we've covered all the angles, and that we can remove it. >>> >>> ? John >>> >>>> On Mar 12, 2014, at 1:44 PM, Paul Sandoz wrote: >>>> >>>> >>>> Currently i cannot find any external uses of it. > From ivan.gerasimov at oracle.com Thu Mar 13 19:42:48 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 13 Mar 2014 23:42:48 +0400 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <532200FD.9060705@oracle.com> References: <5321CEE6.403@oracle.com> <123FE971-9F74-43E6-988A-86D9A1804C68@oracle.com> <5321D9B6.2050301@oracle.com> <5321F5E0.7000408@oracle.com> <5321F87B.8010300@oracle.com> <532200FD.9060705@oracle.com> Message-ID: <53220A38.9080508@oracle.com> Sorry, I forgot to incorporate changes to AbstractList.removeRange() documentation, which you Martin had suggested. Here's the webrev with those included: http://cr.openjdk.java.net/~igerasim/8014066/2/webrev/ Sincerely yours, Ivan On 13.03.2014 23:03, Ivan Gerasimov wrote: > Would you please take a look at the updated webrev: > http://cr.openjdk.java.net/~igerasim/8014066/1/webrev/ > > In addition to the javadoc correction, it includes a regression test > and a check for (fromIndex > toIndex). > The last check turns out to be sufficient for removeRange() method to > agree with the javadoc. > Other checks are handled by the following System.arraycopy() call. > > Sincerely yours, > Ivan > > > On 13.03.2014 22:27, Ivan Gerasimov wrote: >> >> On 13.03.2014 22:16, Ivan Gerasimov wrote: >>> >>> On 13.03.2014 20:37, Martin Buchholz wrote: >>>> The corner case for removeRange(SIZE, SIZE) does seem rather >>>> tricky, and it's easy for an implementation to get it wrong. All >>>> the more reason to add tests! >>>> >>> It was a good idea to add a test for removeRange(). >>> I just discovered that IOOB isn't thrown when you call >>> removeRange(1, 0) or removeRange(4, 0). >>> However, the exception is thrown when you call removeRange(5, 0). >>> >>> The fix seems to become a bit more than just a doc typo fix :-) >>> >> >> And when you do list.removeRange(1, 0), the list becomes longer. >> >> >>> Sincerely yours, >>> Ivan >>> >>>> >>>> On Thu, Mar 13, 2014 at 9:15 AM, Ivan Gerasimov >>>> > wrote: >>>> >>>> Thank you Chris! >>>> >>>> It is System.arraycopy() method, where checking is performed and >>>> the exception is thrown. >>>> Here's this code: >>>> if ( (((unsigned int) length + (unsigned int) src_pos) > >>>> (unsigned int) s->length()) >>>> || (((unsigned int) length + (unsigned int) dst_pos) > >>>> (unsigned int) d->length()) ) { >>>> THROW(vmSymbols::java_lang_ArrayIndexOutOfBoundsException()); >>>> } >>>> >>>> This confirms that size() is a valid value for fromIndex. >>>> >>>> Another way to think of it is that fromIndex <= toIndex, and >>>> toIndex can be equal to size(). >>>> Therefore, fromIndex can be equal to size() too. >>>> >>>> The documentation also says that 'If toIndex==fromIndex, this >>>> operation has no effect.', so removeRange(size(), size()) is a >>>> valid expression and should not cause an exception be thrown (and >>>> it actually does not). >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> >>>> On 13.03.2014 19:47, Chris Hegarty wrote: >>>> >>>> Ivan, >>>> >>>> This does look a little odd, but since fromIndex is inclusive >>>> I would think that it should throw if passed a value of >>>> size() ?? >>>> >>>> -Chris. >>>> >>>> On 13 Mar 2014, at 15:29, Ivan Gerasimov >>>> > >>>> wrote: >>>> >>>> Hello! >>>> >>>> Would you please review a simple fix of the javadoc for >>>> ArrayList#removeRange() method? >>>> >>>> The doc says that IndexOutOfBoundsException is thrown if >>>> fromIndex or toIndex is out of range (fromIndex < 0 || >>>> fromIndex >= size() || toIndex > size() || toIndex < >>>> fromIndex). >>>> >>>> The condition 'fromIndex >= size()' isn't true and should >>>> be removed from the doc. >>>> >>>> For example, the code list.removeRange(size(), size()) >>>> does not throw any exception. >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8014066 >>>> WEBREV: >>>> http://cr.openjdk.java.net/~igerasim/8014066/0/webrev/ >>>> >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > From dl at cs.oswego.edu Thu Mar 13 22:59:03 2014 From: dl at cs.oswego.edu (Doug Lea) Date: Thu, 13 Mar 2014 18:59:03 -0400 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: References: <5321CEE6.403@oracle.com> Message-ID: <53223837.4010306@cs.oswego.edu> On 03/13/2014 12:34 PM, Martin Buchholz wrote: > I notice there are zero jtreg tests for removeRange. That should be fixed. > > I notice there is a removeRange in CopyOnWriteArrayList, but it is > package-private instead of "protected", which seems like an oversight. Can Doug > remember any history on that? CopyOnWriteArrayList does not extend AbstractList, but its sublist does. The sublist relies on COWAL.removeRange only for clear. So COWAL sublist clearing uses the same idea as AbstractList, and gives it the same name, but it is not the same AbstractList method, so need not be protected. -Doug > > I notice that AbstractList.removeRange contains no @throws. That should be fixed? > > The existing @throws javadoc from CopyOnWriteArrayList seems better: > > * @throws IndexOutOfBoundsException if fromIndex or toIndex out of range > * ({@code fromIndex < 0 || toIndex > size() || toIndex < fromIndex}) > > This paragraph in AbstractList > > *

This method is called by the {@code clear} operation on this list > * and its subLists. Overriding this method to take advantage of > * the internals of the list implementation can substantially > * improve the performance of the {@code clear} operation on this list > * and its subLists. > > looks like it belongs inside the @implSpec (it's not a requirement on subclasses) > > ObTesting (a start) > > import java.util.*; > > public class RemoveRange { > static class PublicArrayList extends ArrayList { > PublicArrayList(int cap) { super(cap); } > public void removeRange(int fromIndex, int toIndex) { > super.removeRange(fromIndex, toIndex); > } > } > public static void main(String[] args) throws Throwable { > PublicArrayList x = new PublicArrayList(11); > for (int i = 0; i < 11; i++) x.add(null); > x.removeRange(x.size(), x.size()); > } > } > > > > > On Thu, Mar 13, 2014 at 8:29 AM, Ivan Gerasimov > wrote: > > Hello! > > Would you please review a simple fix of the javadoc for > ArrayList#removeRange() method? > > The doc says that IndexOutOfBoundsException is thrown if fromIndex or > toIndex is out of range (fromIndex < 0 || fromIndex >= size() || toIndex > > size() || toIndex < fromIndex). > > The condition 'fromIndex >= size()' isn't true and should be removed from > the doc. > > For example, the code list.removeRange(size(), size()) does not throw any > exception. > > BUGURL: https://bugs.openjdk.java.net/__browse/JDK-8014066 > > WEBREV: http://cr.openjdk.java.net/~__igerasim/8014066/0/webrev/ > > > Sincerely yours, > Ivan > > From david.x.li at oracle.com Thu Mar 13 23:07:40 2014 From: david.x.li at oracle.com (David Li) Date: Thu, 13 Mar 2014 16:07:40 -0700 Subject: RFR (JAXP): 8035577: Xerces Update: impl/xpath/regex/RangeToken.java Message-ID: <53223A3C.6020706@oracle.com> Hi, This is an update from Xerces for file impl/xpath/regex/TokenRange.java. For details, please refer to: https://bugs.openjdk.java.net/browse/JDK-8035577. Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035577/webrev/ New test case was added for code change in RangeToken.intersectRanges. Other minor issues from last review comments are updated. Existing tests: JAXP SQE and unit tests passed. Thanks, David From huizhe.wang at oracle.com Thu Mar 13 23:36:48 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 13 Mar 2014 16:36:48 -0700 Subject: RFR (JAXP): 8035577: Xerces Update: impl/xpath/regex/RangeToken.java In-Reply-To: <53223A3C.6020706@oracle.com> References: <53223A3C.6020706@oracle.com> Message-ID: <53224110.3000202@oracle.com> Thanks David for the update! Joe On 3/13/2014 4:07 PM, David Li wrote: > Hi, > > This is an update from Xerces for file > impl/xpath/regex/TokenRange.java. For details, please refer to: > https://bugs.openjdk.java.net/browse/JDK-8035577. > > Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035577/webrev/ > > New test case was added for code change in > RangeToken.intersectRanges. Other minor issues from last review > comments are updated. > > Existing tests: JAXP SQE and unit tests passed. > > Thanks, > David From brian.burkhalter at oracle.com Fri Mar 14 00:29:42 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 13 Mar 2014 17:29:42 -0700 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: <5320240C.60304@gmail.com> References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <531EC6BF.4050701@oracle.com> <4742E0AD-8D87-4F22-8F23-779BDF3A58FE@oracle.com> <5320240C.60304@gmail.com> Message-ID: On Mar 12, 2014, at 2:08 AM, Peter Levart wrote: > Huh! This is a ThreadLocalRandom anti-pattern. Thou should not use a ThreadLocalRandom instance in a thread that did not obtain it via a call to ThreadLocalRandom.current()? Good point. > You could create a new BigInteger(512, rnd) in the static initializer and use it to create new BigDecima(bigInteger) in testFirstToStrin. I simply replaced ThreadLocalRandom with Random which probably creates a bottleneck but there is no significant difference in the results. http://cr.openjdk.java.net/~bpb/6375303/Bench6375303.java http://cr.openjdk.java.net/~bpb/6375303/6375303-bench.html Thanks, Brian From brian.burkhalter at oracle.com Fri Mar 14 00:32:20 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 13 Mar 2014 17:32:20 -0700 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: <53201EA5.9090702@gmail.com> References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <5315EDAA.5020801@gmail.com> <531EC3BD.9050605@oracle.com> <53201EA5.9090702@gmail.com> Message-ID: <9F3778F1-2BEE-4E9E-B362-D4547C72F475@oracle.com> On Mar 12, 2014, at 1:45 AM, Peter Levart wrote: > What would the following cost? > > > private transient String stringCache; > > public String toString() { > [?] This version did not show any significant difference in the benchmark results (updated) http://cr.openjdk.java.net/~bpb/6375303/6375303-bench.html versus the other approaches. This is not to say that the benchmark is valid for any of them. This approach does have the advantage or not using volatile. Thanks, Brian From david.holmes at oracle.com Fri Mar 14 04:56:35 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Mar 2014 14:56:35 +1000 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <53220A38.9080508@oracle.com> References: <5321CEE6.403@oracle.com> <123FE971-9F74-43E6-988A-86D9A1804C68@oracle.com> <5321D9B6.2050301@oracle.com> <5321F5E0.7000408@oracle.com> <5321F87B.8010300@oracle.com> <532200FD.9060705@oracle.com> <53220A38.9080508@oracle.com> Message-ID: <53228C03.5070106@oracle.com> Hi Ivan, I think we need to apply the brakes here and back up a bit :) First of all these aren't typo fixes they are spec changes and they will need to go through CCC for approval. Second point is that the condition "fromIndex >= size()" is already captured by the condition "if {@code fromIndex} or {@code toIndex} is out of range". By definition fromIndex is out-of-range if it is < 0 or >= size(). So I don't see any error here even if there is some redundancy. Third, a call a.removeRange(a.size(), a.size()) hits the normal dilemma of "what should be checked first?". The spec states that removeRange(n,n) is a no-op, so if we do that check first we just return, even for bad things like removeRange(-5, -5). Of course if we check all the preconditions first then we would in fact throw the IOOBE. I'm in the camp that says we check preconditions first because it detects silly mistakes sooner. Fourth, your code change to add the additional pre-condition check: protected void removeRange(int fromIndex, int toIndex) { modCount++; + if (fromIndex > toIndex) + throw new IndexOutOfBoundsException( needs to be done _before_ the change to modCount! And finally, the AbstractList.removeRange change: + * @throws NoSuchElementException if {@code (toIndex > size())} seems to reflect an implementation accident rather than a clear API design choice. If the toIndex is out of range then IndexOutOfBoundsException is what should be thrown. Otherwise you constrain any subtypes that override this to throw an exception type that only has meaning with the AbstractList implementation strategy - and by doing so you are making ArrayList.removeRange violate this new specification. It is unfortunate that the existing specification(s) for removeRange are lacking this key detail on exception processing, and lack consistency between AbstractList and it's sublcass ArrayList. I think ArrayList has the better/cleaner specification and that should be pushed up AbstractList and AbstractList's implementation should be modified to explicitly check the pre-conditions. David ----- On 14/03/2014 5:42 AM, Ivan Gerasimov wrote: > Sorry, I forgot to incorporate changes to AbstractList.removeRange() > documentation, which you Martin had suggested. > > Here's the webrev with those included: > http://cr.openjdk.java.net/~igerasim/8014066/2/webrev/ > > Sincerely yours, > Ivan > > > On 13.03.2014 23:03, Ivan Gerasimov wrote: >> Would you please take a look at the updated webrev: >> http://cr.openjdk.java.net/~igerasim/8014066/1/webrev/ >> >> In addition to the javadoc correction, it includes a regression test >> and a check for (fromIndex > toIndex). >> The last check turns out to be sufficient for removeRange() method to >> agree with the javadoc. >> Other checks are handled by the following System.arraycopy() call. >> >> Sincerely yours, >> Ivan >> >> >> On 13.03.2014 22:27, Ivan Gerasimov wrote: >>> >>> On 13.03.2014 22:16, Ivan Gerasimov wrote: >>>> >>>> On 13.03.2014 20:37, Martin Buchholz wrote: >>>>> The corner case for removeRange(SIZE, SIZE) does seem rather >>>>> tricky, and it's easy for an implementation to get it wrong. All >>>>> the more reason to add tests! >>>>> >>>> It was a good idea to add a test for removeRange(). >>>> I just discovered that IOOB isn't thrown when you call >>>> removeRange(1, 0) or removeRange(4, 0). >>>> However, the exception is thrown when you call removeRange(5, 0). >>>> >>>> The fix seems to become a bit more than just a doc typo fix :-) >>>> >>> >>> And when you do list.removeRange(1, 0), the list becomes longer. >>> >>> >>>> Sincerely yours, >>>> Ivan >>>> >>>>> >>>>> On Thu, Mar 13, 2014 at 9:15 AM, Ivan Gerasimov >>>>> > wrote: >>>>> >>>>> Thank you Chris! >>>>> >>>>> It is System.arraycopy() method, where checking is performed and >>>>> the exception is thrown. >>>>> Here's this code: >>>>> if ( (((unsigned int) length + (unsigned int) src_pos) > >>>>> (unsigned int) s->length()) >>>>> || (((unsigned int) length + (unsigned int) dst_pos) > >>>>> (unsigned int) d->length()) ) { >>>>> THROW(vmSymbols::java_lang_ArrayIndexOutOfBoundsException()); >>>>> } >>>>> >>>>> This confirms that size() is a valid value for fromIndex. >>>>> >>>>> Another way to think of it is that fromIndex <= toIndex, and >>>>> toIndex can be equal to size(). >>>>> Therefore, fromIndex can be equal to size() too. >>>>> >>>>> The documentation also says that 'If toIndex==fromIndex, this >>>>> operation has no effect.', so removeRange(size(), size()) is a >>>>> valid expression and should not cause an exception be thrown (and >>>>> it actually does not). >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>> >>>>> On 13.03.2014 19:47, Chris Hegarty wrote: >>>>> >>>>> Ivan, >>>>> >>>>> This does look a little odd, but since fromIndex is inclusive >>>>> I would think that it should throw if passed a value of >>>>> size() ?? >>>>> >>>>> -Chris. >>>>> >>>>> On 13 Mar 2014, at 15:29, Ivan Gerasimov >>>>> > >>>>> wrote: >>>>> >>>>> Hello! >>>>> >>>>> Would you please review a simple fix of the javadoc for >>>>> ArrayList#removeRange() method? >>>>> >>>>> The doc says that IndexOutOfBoundsException is thrown if >>>>> fromIndex or toIndex is out of range (fromIndex < 0 || >>>>> fromIndex >= size() || toIndex > size() || toIndex < >>>>> fromIndex). >>>>> >>>>> The condition 'fromIndex >= size()' isn't true and should >>>>> be removed from the doc. >>>>> >>>>> For example, the code list.removeRange(size(), size()) >>>>> does not throw any exception. >>>>> >>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8014066 >>>>> WEBREV: >>>>> http://cr.openjdk.java.net/~igerasim/8014066/0/webrev/ >>>>> >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > From martinrb at google.com Fri Mar 14 06:38:05 2014 From: martinrb at google.com (Martin Buchholz) Date: Thu, 13 Mar 2014 23:38:05 -0700 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <53223837.4010306@cs.oswego.edu> References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> Message-ID: On Thu, Mar 13, 2014 at 3:59 PM, Doug Lea

wrote: > On 03/13/2014 12:34 PM, Martin Buchholz wrote: > >> I notice there are zero jtreg tests for removeRange. That should be >> fixed. >> >> I notice there is a removeRange in CopyOnWriteArrayList, but it is >> package-private instead of "protected", which seems like an oversight. >> Can Doug >> remember any history on that? >> > > CopyOnWriteArrayList does not extend AbstractList, but its > sublist does. The sublist relies on COWAL.removeRange only for clear. > So COWAL sublist clearing uses the same idea as > AbstractList, and gives it the same name, but it is not the > same AbstractList method, so need not be protected. > Ahh OK, I think the party line for *users* is if they want to remove a range of elements from a list, use list.subList(fromIndex, toIndex).clear (), so there's no advantage in making COWAL.removeRange a public interface. From ivan.gerasimov at oracle.com Fri Mar 14 07:05:21 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 14 Mar 2014 11:05:21 +0400 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <53228C03.5070106@oracle.com> References: <5321CEE6.403@oracle.com> <123FE971-9F74-43E6-988A-86D9A1804C68@oracle.com> <5321D9B6.2050301@oracle.com> <5321F5E0.7000408@oracle.com> <5321F87B.8010300@oracle.com> <532200FD.9060705@oracle.com> <53220A38.9080508@oracle.com> <53228C03.5070106@oracle.com> Message-ID: <5322AA31.1040703@oracle.com> Thank you David for your reply! On 14.03.2014 8:56, David Holmes wrote: > Hi Ivan, > > I think we need to apply the brakes here and back up a bit :) > > First of all these aren't typo fixes they are spec changes and they > will need to go through CCC for approval. > Yes, sure. I haven't done that before, so will need to find someone to assist me for the first time. > Second point is that the condition "fromIndex >= size()" is already > captured by the condition "if {@code fromIndex} or {@code toIndex} is > out of range". By definition fromIndex is out-of-range if it is < 0 or > >= size(). So I don't see any error here even if there is some > redundancy. > I don't think that 'fromIndex < size()' restriction is quite natural. I've scanned through several other methods in JDK, where the pair 'fromIndex, toIndex' is used as the arguments. For example, List.subList(), BitSet.clear(), BitSet.flip(), BitSet.get(), BitSet.set(), Arrays.sort(), Arrays.binarySearch(), Arrays.fill() and several others. None of these methods have this kind of restriction, at least in the documentation. > Third, a call a.removeRange(a.size(), a.size()) hits the normal > dilemma of "what should be checked first?". The spec states that > removeRange(n,n) is a no-op, so if we do that check first we just > return, even for bad things like removeRange(-5, -5). Of course if we > check all the preconditions first then we would in fact throw the > IOOBE. I'm in the camp that says we check preconditions first because > it detects silly mistakes sooner. > In my opinion a.removeRange(a.size(), a.size()) is a valid expression, while removeRange(-5, -5) is not. For example, if had a need to remove some elements up to the end of the list, I would have toIndex fixed to 'a.end()': a.remove(fromIndex, a.end()). In this situation, I would need to have a way to specify an empty set of items to be removed, thus having fromIndex == a.end(). I agree that preconditions should be checked first, so removeRange(-5, -5) should throw an exception. > Fourth, your code change to add the additional pre-condition check: > > protected void removeRange(int fromIndex, int toIndex) { > modCount++; > + if (fromIndex > toIndex) > + throw new IndexOutOfBoundsException( > > needs to be done _before_ the change to modCount! > I placed it right before a call to System.copyarray(), where all other checks are performed. But I don't mind moving it to the top of the method. > And finally, the AbstractList.removeRange change: > > + * @throws NoSuchElementException if {@code (toIndex > size())} > > seems to reflect an implementation accident rather than a clear API > design choice. If the toIndex is out of range then > IndexOutOfBoundsException is what should be thrown. Otherwise you > constrain any subtypes that override this to throw an exception type > that only has meaning with the AbstractList implementation strategy - > and by doing so you are making ArrayList.removeRange violate this new > specification. > > It is unfortunate that the existing specification(s) for removeRange > are lacking this key detail on exception processing, and lack > consistency between AbstractList and it's sublcass ArrayList. I think > ArrayList has the better/cleaner specification and that should be > pushed up AbstractList and AbstractList's implementation should be > modified to explicitly check the pre-conditions. > Again, I agree with you. One thing I noticed is that some methods I mentioned above (List.subList(), Arrays.sort(), etc) throw IllegalArgumentException when fromIndex > toIndex, not IndexOutOfBoundException. Wouldn't it be more correct to adopt this into removeRange() too? Sincerely yours, Ivan > David > ----- > > On 14/03/2014 5:42 AM, Ivan Gerasimov wrote: >> Sorry, I forgot to incorporate changes to AbstractList.removeRange() >> documentation, which you Martin had suggested. >> >> Here's the webrev with those included: >> http://cr.openjdk.java.net/~igerasim/8014066/2/webrev/ >> >> Sincerely yours, >> Ivan >> >> >> On 13.03.2014 23:03, Ivan Gerasimov wrote: >>> Would you please take a look at the updated webrev: >>> http://cr.openjdk.java.net/~igerasim/8014066/1/webrev/ >>> >>> In addition to the javadoc correction, it includes a regression test >>> and a check for (fromIndex > toIndex). >>> The last check turns out to be sufficient for removeRange() method to >>> agree with the javadoc. >>> Other checks are handled by the following System.arraycopy() call. >>> >>> Sincerely yours, >>> Ivan >>> >>> >>> On 13.03.2014 22:27, Ivan Gerasimov wrote: >>>> >>>> On 13.03.2014 22:16, Ivan Gerasimov wrote: >>>>> >>>>> On 13.03.2014 20:37, Martin Buchholz wrote: >>>>>> The corner case for removeRange(SIZE, SIZE) does seem rather >>>>>> tricky, and it's easy for an implementation to get it wrong. All >>>>>> the more reason to add tests! >>>>>> >>>>> It was a good idea to add a test for removeRange(). >>>>> I just discovered that IOOB isn't thrown when you call >>>>> removeRange(1, 0) or removeRange(4, 0). >>>>> However, the exception is thrown when you call removeRange(5, 0). >>>>> >>>>> The fix seems to become a bit more than just a doc typo fix :-) >>>>> >>>> >>>> And when you do list.removeRange(1, 0), the list becomes longer. >>>> >>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>>> >>>>>> On Thu, Mar 13, 2014 at 9:15 AM, Ivan Gerasimov >>>>>> > >>>>>> wrote: >>>>>> >>>>>> Thank you Chris! >>>>>> >>>>>> It is System.arraycopy() method, where checking is performed and >>>>>> the exception is thrown. >>>>>> Here's this code: >>>>>> if ( (((unsigned int) length + (unsigned int) src_pos) > >>>>>> (unsigned int) s->length()) >>>>>> || (((unsigned int) length + (unsigned int) dst_pos) > >>>>>> (unsigned int) d->length()) ) { >>>>>> THROW(vmSymbols::java_lang_ArrayIndexOutOfBoundsException()); >>>>>> } >>>>>> >>>>>> This confirms that size() is a valid value for fromIndex. >>>>>> >>>>>> Another way to think of it is that fromIndex <= toIndex, and >>>>>> toIndex can be equal to size(). >>>>>> Therefore, fromIndex can be equal to size() too. >>>>>> >>>>>> The documentation also says that 'If toIndex==fromIndex, this >>>>>> operation has no effect.', so removeRange(size(), size()) is a >>>>>> valid expression and should not cause an exception be thrown >>>>>> (and >>>>>> it actually does not). >>>>>> >>>>>> Sincerely yours, >>>>>> Ivan >>>>>> >>>>>> >>>>>> On 13.03.2014 19:47, Chris Hegarty wrote: >>>>>> >>>>>> Ivan, >>>>>> >>>>>> This does look a little odd, but since fromIndex is >>>>>> inclusive >>>>>> I would think that it should throw if passed a value of >>>>>> size() ?? >>>>>> >>>>>> -Chris. >>>>>> >>>>>> On 13 Mar 2014, at 15:29, Ivan Gerasimov >>>>>> >>>>> > >>>>>> wrote: >>>>>> >>>>>> Hello! >>>>>> >>>>>> Would you please review a simple fix of the javadoc for >>>>>> ArrayList#removeRange() method? >>>>>> >>>>>> The doc says that IndexOutOfBoundsException is thrown if >>>>>> fromIndex or toIndex is out of range (fromIndex < 0 || >>>>>> fromIndex >= size() || toIndex > size() || toIndex < >>>>>> fromIndex). >>>>>> >>>>>> The condition 'fromIndex >= size()' isn't true and >>>>>> should >>>>>> be removed from the doc. >>>>>> >>>>>> For example, the code list.removeRange(size(), size()) >>>>>> does not throw any exception. >>>>>> >>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8014066 >>>>>> WEBREV: >>>>>> http://cr.openjdk.java.net/~igerasim/8014066/0/webrev/ >>>>>> >>>>>> >>>>>> Sincerely yours, >>>>>> Ivan >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> > > From david.holmes at oracle.com Fri Mar 14 08:31:09 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Mar 2014 18:31:09 +1000 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <5322AA31.1040703@oracle.com> References: <5321CEE6.403@oracle.com> <123FE971-9F74-43E6-988A-86D9A1804C68@oracle.com> <5321D9B6.2050301@oracle.com> <5321F5E0.7000408@oracle.com> <5321F87B.8010300@oracle.com> <532200FD.9060705@oracle.com> <53220A38.9080508@oracle.com> <53228C03.5070106@oracle.com> <5322AA31.1040703@oracle.com> Message-ID: <5322BE4D.80204@oracle.com> Hi Ivan, On 14/03/2014 5:05 PM, Ivan Gerasimov wrote: > Thank you David for your reply! > > On 14.03.2014 8:56, David Holmes wrote: >> Hi Ivan, >> >> I think we need to apply the brakes here and back up a bit :) >> >> First of all these aren't typo fixes they are spec changes and they >> will need to go through CCC for approval. >> > Yes, sure. I haven't done that before, so will need to find someone to > assist me for the first time. > >> Second point is that the condition "fromIndex >= size()" is already >> captured by the condition "if {@code fromIndex} or {@code toIndex} is >> out of range". By definition fromIndex is out-of-range if it is < 0 or >> >= size(). So I don't see any error here even if there is some >> redundancy. >> > I don't think that 'fromIndex < size()' restriction is quite natural. Seems perfectly natural to ensure the fromIndex is somewhere in the available range. > I've scanned through several other methods in JDK, where the pair > 'fromIndex, toIndex' is used as the arguments. > For example, List.subList(), BitSet.clear(), BitSet.flip(), > BitSet.get(), BitSet.set(), Arrays.sort(), Arrays.binarySearch(), > Arrays.fill() and several others. > None of these methods have this kind of restriction, at least in the > documentation. List.subList states: IndexOutOfBoundsException - for an illegal endpoint index value (fromIndex < 0 || toIndex > size || fromIndex > toIndex) which means that fromIndex <= toIndex <= size; hence fromIndex > size() is illegal. Also CharSequence.subSequence: IndexOutOfBoundsException - if start or end are negative, if end is greater than length(), or if start is greater than end As I said fromIndex >= size() is actually captured by saying fromIndex must be in range. >> Third, a call a.removeRange(a.size(), a.size()) hits the normal >> dilemma of "what should be checked first?". The spec states that >> removeRange(n,n) is a no-op, so if we do that check first we just >> return, even for bad things like removeRange(-5, -5). Of course if we >> check all the preconditions first then we would in fact throw the >> IOOBE. I'm in the camp that says we check preconditions first because >> it detects silly mistakes sooner. >> > In my opinion a.removeRange(a.size(), a.size()) is a valid expression, > while removeRange(-5, -5) is not. > For example, if had a need to remove some elements up to the end of the > list, I would have toIndex fixed to 'a.end()': a.remove(fromIndex, > a.end()). > In this situation, I would need to have a way to specify an empty set of > items to be removed, thus having fromIndex == a.end(). That's a good point. I think the prohibition on fromIndex==size() is wrong, as per the other examples (subList, subSequence). > I agree that preconditions should be checked first, so removeRange(-5, > -5) should throw an exception. > > >> Fourth, your code change to add the additional pre-condition check: >> >> protected void removeRange(int fromIndex, int toIndex) { >> modCount++; >> + if (fromIndex > toIndex) >> + throw new IndexOutOfBoundsException( >> >> needs to be done _before_ the change to modCount! >> > I placed it right before a call to System.copyarray(), where all other > checks are performed. That is a bug in the existing code then. If a precondition fails then the data structure is not modified and the modCount should not be changed. This is what happens when you piggy-back pre-condition checks. > But I don't mind moving it to the top of the method. Thanks - every little helps :) >> And finally, the AbstractList.removeRange change: >> >> + * @throws NoSuchElementException if {@code (toIndex > size())} >> >> seems to reflect an implementation accident rather than a clear API >> design choice. If the toIndex is out of range then >> IndexOutOfBoundsException is what should be thrown. Otherwise you >> constrain any subtypes that override this to throw an exception type >> that only has meaning with the AbstractList implementation strategy - >> and by doing so you are making ArrayList.removeRange violate this new >> specification. >> >> It is unfortunate that the existing specification(s) for removeRange >> are lacking this key detail on exception processing, and lack >> consistency between AbstractList and it's sublcass ArrayList. I think >> ArrayList has the better/cleaner specification and that should be >> pushed up AbstractList and AbstractList's implementation should be >> modified to explicitly check the pre-conditions. >> > Again, I agree with you. > One thing I noticed is that some methods I mentioned above > (List.subList(), Arrays.sort(), etc) throw IllegalArgumentException when > fromIndex > toIndex, not IndexOutOfBoundException. > Wouldn't it be more correct to adopt this into removeRange() too? Unfortunately there are a lot of inconsistencies in the API design throughout the JDK - even in classes that are somewhat related. That said List.subList throws IOOBE, But I do see examples of: IllegalArgumentException - if fromIndex > toIndex which is definitely more correct if both values are in range, but then what if both are out of range? Anyway you can't just arbitrarily make changes to the specifications of these methods - even if trying to fix obvious inconsistencies. The main priority is that specs and implementations agree; and that specs in subtypes are consistent with the spec in the supertypes. I see a number of issues here that may be tricky to reconcile having regard for compatability. Cheers, David > Sincerely yours, > Ivan > > >> David >> ----- >> >> On 14/03/2014 5:42 AM, Ivan Gerasimov wrote: >>> Sorry, I forgot to incorporate changes to AbstractList.removeRange() >>> documentation, which you Martin had suggested. >>> >>> Here's the webrev with those included: >>> http://cr.openjdk.java.net/~igerasim/8014066/2/webrev/ >>> >>> Sincerely yours, >>> Ivan >>> >>> >>> On 13.03.2014 23:03, Ivan Gerasimov wrote: >>>> Would you please take a look at the updated webrev: >>>> http://cr.openjdk.java.net/~igerasim/8014066/1/webrev/ >>>> >>>> In addition to the javadoc correction, it includes a regression test >>>> and a check for (fromIndex > toIndex). >>>> The last check turns out to be sufficient for removeRange() method to >>>> agree with the javadoc. >>>> Other checks are handled by the following System.arraycopy() call. >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> >>>> On 13.03.2014 22:27, Ivan Gerasimov wrote: >>>>> >>>>> On 13.03.2014 22:16, Ivan Gerasimov wrote: >>>>>> >>>>>> On 13.03.2014 20:37, Martin Buchholz wrote: >>>>>>> The corner case for removeRange(SIZE, SIZE) does seem rather >>>>>>> tricky, and it's easy for an implementation to get it wrong. All >>>>>>> the more reason to add tests! >>>>>>> >>>>>> It was a good idea to add a test for removeRange(). >>>>>> I just discovered that IOOB isn't thrown when you call >>>>>> removeRange(1, 0) or removeRange(4, 0). >>>>>> However, the exception is thrown when you call removeRange(5, 0). >>>>>> >>>>>> The fix seems to become a bit more than just a doc typo fix :-) >>>>>> >>>>> >>>>> And when you do list.removeRange(1, 0), the list becomes longer. >>>>> >>>>> >>>>>> Sincerely yours, >>>>>> Ivan >>>>>> >>>>>>> >>>>>>> On Thu, Mar 13, 2014 at 9:15 AM, Ivan Gerasimov >>>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Thank you Chris! >>>>>>> >>>>>>> It is System.arraycopy() method, where checking is performed and >>>>>>> the exception is thrown. >>>>>>> Here's this code: >>>>>>> if ( (((unsigned int) length + (unsigned int) src_pos) > >>>>>>> (unsigned int) s->length()) >>>>>>> || (((unsigned int) length + (unsigned int) dst_pos) > >>>>>>> (unsigned int) d->length()) ) { >>>>>>> THROW(vmSymbols::java_lang_ArrayIndexOutOfBoundsException()); >>>>>>> } >>>>>>> >>>>>>> This confirms that size() is a valid value for fromIndex. >>>>>>> >>>>>>> Another way to think of it is that fromIndex <= toIndex, and >>>>>>> toIndex can be equal to size(). >>>>>>> Therefore, fromIndex can be equal to size() too. >>>>>>> >>>>>>> The documentation also says that 'If toIndex==fromIndex, this >>>>>>> operation has no effect.', so removeRange(size(), size()) is a >>>>>>> valid expression and should not cause an exception be thrown >>>>>>> (and >>>>>>> it actually does not). >>>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan >>>>>>> >>>>>>> >>>>>>> On 13.03.2014 19:47, Chris Hegarty wrote: >>>>>>> >>>>>>> Ivan, >>>>>>> >>>>>>> This does look a little odd, but since fromIndex is >>>>>>> inclusive >>>>>>> I would think that it should throw if passed a value of >>>>>>> size() ?? >>>>>>> >>>>>>> -Chris. >>>>>>> >>>>>>> On 13 Mar 2014, at 15:29, Ivan Gerasimov >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Hello! >>>>>>> >>>>>>> Would you please review a simple fix of the javadoc for >>>>>>> ArrayList#removeRange() method? >>>>>>> >>>>>>> The doc says that IndexOutOfBoundsException is thrown if >>>>>>> fromIndex or toIndex is out of range (fromIndex < 0 || >>>>>>> fromIndex >= size() || toIndex > size() || toIndex < >>>>>>> fromIndex). >>>>>>> >>>>>>> The condition 'fromIndex >= size()' isn't true and >>>>>>> should >>>>>>> be removed from the doc. >>>>>>> >>>>>>> For example, the code list.removeRange(size(), size()) >>>>>>> does not throw any exception. >>>>>>> >>>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8014066 >>>>>>> WEBREV: >>>>>>> http://cr.openjdk.java.net/~igerasim/8014066/0/webrev/ >>>>>>> >>>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >> >> > From peter.levart at gmail.com Fri Mar 14 10:39:34 2014 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 14 Mar 2014 11:39:34 +0100 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <531EC6BF.4050701@oracle.com> <4742E0AD-8D87-4F22-8F23-779BDF3A58FE@oracle.com> <5320240C.60304@gmail.com> Message-ID: <5322DC66.5070003@gmail.com> On 03/14/2014 01:29 AM, Brian Burkhalter wrote: > > On Mar 12, 2014, at 2:08 AM, Peter Levart wrote: > >> Huh! This is a ThreadLocalRandom anti-pattern. Thou should not use a >> ThreadLocalRandom instance in a thread that did not obtain it via a >> call to ThreadLocalRandom.current()? > > Good point. > >> You could create a new BigInteger(512,*rnd*) in the static >> initializer and use it to create new BigDecima(bigInteger) in >> testFirstToStrin. > > I simply replaced ThreadLocalRandom with Random which probably creates > a bottleneck but there is no significant difference in the results. That's probably because the time spent computing the toString representation initially (the concurrent part of testFirstToString benchmark) takes much more time than computing the random number (the synchronized/serialized part). The difference would probably show with bigger number of threads on a suitable machine of course. But in general it would be better to just use "ThreadLocalRandom.current()" everywhere you use "rnd" variable. This is precisely it's purpose - a random number generator that is never contended. The overhead of ThreadLocalRandom.current() call is hardly measurable by itself. Regards, Peter > > http://cr.openjdk.java.net/~bpb/6375303/Bench6375303.java > > http://cr.openjdk.java.net/~bpb/6375303/6375303-bench.html > > > Thanks, > > Brian From peter.levart at gmail.com Fri Mar 14 10:42:36 2014 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 14 Mar 2014 11:42:36 +0100 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: <9F3778F1-2BEE-4E9E-B362-D4547C72F475@oracle.com> References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <5315EDAA.5020801@gmail.com> <531EC3BD.9050605@oracle.com> <53201EA5.9090702@gmail.com> <9F3778F1-2BEE-4E9E-B362-D4547C72F475@oracle.com> Message-ID: <5322DD1C.3090601@gmail.com> On 03/14/2014 01:32 AM, Brian Burkhalter wrote: > > On Mar 12, 2014, at 1:45 AM, Peter Levart wrote: > >> What would the following cost? >> >> >> private transient String stringCache; >> >> public String toString() { >> [?] > > This version did not show any significant difference in the benchmark > results (updated) > > http://cr.openjdk.java.net/~bpb/6375303/6375303-bench.html > > > versus the other approaches. This is not to say that the benchmark is > valid for any of them. This approach does have the advantage or not > using volatile. I've forgot to run this on my Raspberry Pi. Stay tuned... Peter > > Thanks, > > Brian From ivan.gerasimov at oracle.com Fri Mar 14 10:50:06 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 14 Mar 2014 14:50:06 +0400 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <5322BE4D.80204@oracle.com> References: <5321CEE6.403@oracle.com> <123FE971-9F74-43E6-988A-86D9A1804C68@oracle.com> <5321D9B6.2050301@oracle.com> <5321F5E0.7000408@oracle.com> <5321F87B.8010300@oracle.com> <532200FD.9060705@oracle.com> <53220A38.9080508@oracle.com> <53228C03.5070106@oracle.com> <5322AA31.1040703@oracle.com> <5322BE4D.80204@oracle.com> Message-ID: <5322DEDE.6090908@oracle.com> Thanks David! On 14.03.2014 12:31, David Holmes wrote: > >> >>> Second point is that the condition "fromIndex >= size()" is already >>> captured by the condition "if {@code fromIndex} or {@code toIndex} is >>> out of range". By definition fromIndex is out-of-range if it is < 0 or >>> >= size(). So I don't see any error here even if there is some >>> redundancy. >>> >> I don't think that 'fromIndex < size()' restriction is quite natural. > > Seems perfectly natural to ensure the fromIndex is somewhere in the > available range. > Sorry, what I meant was that it is too restrictive. 'fromIndex <= size()' is indeed natural. > >>> And finally, the AbstractList.removeRange change: >>> >>> + * @throws NoSuchElementException if {@code (toIndex > size())} >>> >>> seems to reflect an implementation accident rather than a clear API >>> design choice. If the toIndex is out of range then >>> IndexOutOfBoundsException is what should be thrown. Otherwise you >>> constrain any subtypes that override this to throw an exception type >>> that only has meaning with the AbstractList implementation strategy - >>> and by doing so you are making ArrayList.removeRange violate this new >>> specification. >>> >>> It is unfortunate that the existing specification(s) for removeRange >>> are lacking this key detail on exception processing, and lack >>> consistency between AbstractList and it's sublcass ArrayList. I think >>> ArrayList has the better/cleaner specification and that should be >>> pushed up AbstractList and AbstractList's implementation should be >>> modified to explicitly check the pre-conditions. >>> >> Again, I agree with you. >> One thing I noticed is that some methods I mentioned above >> (List.subList(), Arrays.sort(), etc) throw IllegalArgumentException when >> fromIndex > toIndex, not IndexOutOfBoundException. >> Wouldn't it be more correct to adopt this into removeRange() too? > > Unfortunately there are a lot of inconsistencies in the API design > throughout the JDK - even in classes that are somewhat related. That > said List.subList throws IOOBE, But I do see examples of: > > IllegalArgumentException - if fromIndex > toIndex > > which is definitely more correct if both values are in range, but then > what if both are out of range? > > Anyway you can't just arbitrarily make changes to the specifications > of these methods - even if trying to fix obvious inconsistencies. The > main priority is that specs and implementations agree; and that specs > in subtypes are consistent with the spec in the supertypes. > > I see a number of issues here that may be tricky to reconcile having > regard for compatability. > What we have how is: AbstractList#removeRange() - spec misses throws section; - implementation has a bug: the function may throw NoSuchElementException instead of IndexOutOfBoundsException; ArrayList#removeRange() - spec contains wrong condition 'fromIndex >= size()' ; - implementation has a bug: the condition fromIndex <= toIndex isn't checked at all. Thus, we'll need to adjust both spec and implementation of both base and derived classes. That's why I ask, if it may make sense to add IllegalArgumentException for fromIndex > toIndex case, since the spec needs to be corrected anyway. Of course, no problem to leave only IndexOutOfBoundsException. Concerning the ambiguity, which exception to throw if toIndex < fromIndex and some of them is out of range. I believe, the conditions should be checked in the order they're listed in the spec. Therefore, IndexOutOfBoundsException in this case. Sincerely yours, Ivan From peter.levart at gmail.com Fri Mar 14 10:53:25 2014 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 14 Mar 2014 11:53:25 +0100 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <5322AA31.1040703@oracle.com> References: <5321CEE6.403@oracle.com> <123FE971-9F74-43E6-988A-86D9A1804C68@oracle.com> <5321D9B6.2050301@oracle.com> <5321F5E0.7000408@oracle.com> <5321F87B.8010300@oracle.com> <532200FD.9060705@oracle.com> <53220A38.9080508@oracle.com> <53228C03.5070106@oracle.com> <5322AA31.1040703@oracle.com> Message-ID: <5322DFA5.7070704@gmail.com> On 03/14/2014 08:05 AM, Ivan Gerasimov wrote: > One thing I noticed is that some methods I mentioned above > (List.subList(), Arrays.sort(), etc) throw IllegalArgumentException > when fromIndex > toIndex, not IndexOutOfBoundException. > Wouldn't it be more correct to adopt this into removeRange() too? The question is, what exception should be thrown for removeRange(0, -1) then... The order of checks matters and should be specified if two kinds of exceptions are thrown... Regards, Peter From Roger.Riggs at Oracle.com Fri Mar 14 11:10:36 2014 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 14 Mar 2014 07:10:36 -0400 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <5322DEDE.6090908@oracle.com> References: <5321CEE6.403@oracle.com> <123FE971-9F74-43E6-988A-86D9A1804C68@oracle.com> <5321D9B6.2050301@oracle.com> <5321F5E0.7000408@oracle.com> <5321F87B.8010300@oracle.com> <532200FD.9060705@oracle.com> <53220A38.9080508@oracle.com> <53228C03.5070106@oracle.com> <5322AA31.1040703@oracle.com> <5322BE4D.80204@oracle.com> <5322DEDE.6090908@oracle.com> Message-ID: <5322E3AC.3030808@Oracle.com> Hi, Without getting into the details, make sure that the behavior seen by applications is not changed without careful and exhaustive review. Usually, the specification is updated to match the existing long standing behavior including exceptions and edge cases. Roger On 3/14/14 6:50 AM, Ivan Gerasimov wrote: > Thanks David! > > On 14.03.2014 12:31, David Holmes wrote: >> >>> >>>> Second point is that the condition "fromIndex >= size()" is already >>>> captured by the condition "if {@code fromIndex} or {@code toIndex} is >>>> out of range". By definition fromIndex is out-of-range if it is < 0 or >>>> >= size(). So I don't see any error here even if there is some >>>> redundancy. >>>> >>> I don't think that 'fromIndex < size()' restriction is quite natural. >> >> Seems perfectly natural to ensure the fromIndex is somewhere in the >> available range. >> > > Sorry, what I meant was that it is too restrictive. > 'fromIndex <= size()' is indeed natural. > >> >>>> And finally, the AbstractList.removeRange change: >>>> >>>> + * @throws NoSuchElementException if {@code (toIndex > size())} >>>> >>>> seems to reflect an implementation accident rather than a clear API >>>> design choice. If the toIndex is out of range then >>>> IndexOutOfBoundsException is what should be thrown. Otherwise you >>>> constrain any subtypes that override this to throw an exception type >>>> that only has meaning with the AbstractList implementation strategy - >>>> and by doing so you are making ArrayList.removeRange violate this new >>>> specification. >>>> >>>> It is unfortunate that the existing specification(s) for removeRange >>>> are lacking this key detail on exception processing, and lack >>>> consistency between AbstractList and it's sublcass ArrayList. I think >>>> ArrayList has the better/cleaner specification and that should be >>>> pushed up AbstractList and AbstractList's implementation should be >>>> modified to explicitly check the pre-conditions. >>>> >>> Again, I agree with you. >>> One thing I noticed is that some methods I mentioned above >>> (List.subList(), Arrays.sort(), etc) throw IllegalArgumentException >>> when >>> fromIndex > toIndex, not IndexOutOfBoundException. >>> Wouldn't it be more correct to adopt this into removeRange() too? >> >> Unfortunately there are a lot of inconsistencies in the API design >> throughout the JDK - even in classes that are somewhat related. That >> said List.subList throws IOOBE, But I do see examples of: >> >> IllegalArgumentException - if fromIndex > toIndex >> >> which is definitely more correct if both values are in range, but >> then what if both are out of range? >> >> Anyway you can't just arbitrarily make changes to the specifications >> of these methods - even if trying to fix obvious inconsistencies. The >> main priority is that specs and implementations agree; and that specs >> in subtypes are consistent with the spec in the supertypes. >> >> I see a number of issues here that may be tricky to reconcile having >> regard for compatability. >> > > What we have how is: > > AbstractList#removeRange() > - spec misses throws section; > - implementation has a bug: the function may throw > NoSuchElementException instead of IndexOutOfBoundsException; > > ArrayList#removeRange() > - spec contains wrong condition 'fromIndex >= size()' ; > - implementation has a bug: the condition fromIndex <= toIndex isn't > checked at all. > > Thus, we'll need to adjust both spec and implementation of both base > and derived classes. > That's why I ask, if it may make sense to add IllegalArgumentException > for fromIndex > toIndex case, since the spec needs to be corrected > anyway. > Of course, no problem to leave only IndexOutOfBoundsException. > > Concerning the ambiguity, which exception to throw if toIndex < > fromIndex and some of them is out of range. > I believe, the conditions should be checked in the order they're > listed in the spec. > Therefore, IndexOutOfBoundsException in this case. > > Sincerely yours, > Ivan > From ivan.gerasimov at oracle.com Fri Mar 14 11:19:50 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 14 Mar 2014 15:19:50 +0400 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <5322DFA5.7070704@gmail.com> References: <5321CEE6.403@oracle.com> <123FE971-9F74-43E6-988A-86D9A1804C68@oracle.com> <5321D9B6.2050301@oracle.com> <5321F5E0.7000408@oracle.com> <5321F87B.8010300@oracle.com> <532200FD.9060705@oracle.com> <53220A38.9080508@oracle.com> <53228C03.5070106@oracle.com> <5322AA31.1040703@oracle.com> <5322DFA5.7070704@gmail.com> Message-ID: <5322E5D6.5020403@oracle.com> Thanks Peter for the comments. On 14.03.2014 14:53, Peter Levart wrote: > On 03/14/2014 08:05 AM, Ivan Gerasimov wrote: >> One thing I noticed is that some methods I mentioned above >> (List.subList(), Arrays.sort(), etc) throw IllegalArgumentException >> when fromIndex > toIndex, not IndexOutOfBoundException. >> Wouldn't it be more correct to adopt this into removeRange() too? > > The question is, what exception should be thrown for removeRange(0, > -1) then... The order of checks matters and should be specified if two > kinds of exceptions are thrown... > In my opinion, the order of the checks should match the order of the listed exceptions in the spec. If the order is: @throws IndexOutOfBoundException if either index is negative or either index is greater than size() @throws IllegalArgumentException if (fromIndex > toIndex) then removeRange(0, -1) should throw IndexOutOfBoundException. Sincerely yours, Ivan From vladimir.x.ivanov at oracle.com Fri Mar 14 11:28:06 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 14 Mar 2014 15:28:06 +0400 Subject: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types Message-ID: <5322E7C6.3050603@oracle.com> http://cr.openjdk.java.net/~vlivanov/8037210/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8037210 953 lines changed: 425 ins; 217 del; 311 mod This is a massive cleanup of JSR292 code to replace char-based description of basic types by numeric constants. Contributed-by: john.r.rose at oracle.com Testing: jdk/java/{lang/invoke,util}, vm.mlvm.testlist, nashorn, jruby Flags: -ea -esa -Xverify:all -D...COMPILE_THRESHOLD={0,30} Best regards, Vladimir Ivanov From dl at cs.oswego.edu Fri Mar 14 11:42:07 2014 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 14 Mar 2014 07:42:07 -0400 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> Message-ID: <5322EB0F.8010900@cs.oswego.edu> On 03/14/2014 02:38 AM, Martin Buchholz wrote: > On Thu, Mar 13, 2014 at 3:59 PM, Doug Lea
> wrote: > On 03/13/2014 12:34 PM, Martin Buchholz wrote: > I notice there are zero jtreg tests for removeRange. That should be fixed. > > I notice there is a removeRange in CopyOnWriteArrayList, but it is > package-private instead of "protected", which seems like an oversight. > Can Doug > remember any history on that? > > > CopyOnWriteArrayList does not extend AbstractList, but its > sublist does. The sublist relies on COWAL.removeRange only for clear. > So COWAL sublist clearing uses the same idea as > AbstractList, and gives it the same name, but it is not the > same AbstractList method, so need not be protected. > > > Ahh OK, I think the party line for *users* is if they want to remove a range of > elements from a list, use list.subList(fromIndex, toIndex).clear (), so there's > no advantage in making COWAL.removeRange a public interface. Right. This relates to the question of range checks for removeRange. Josh Block created removeRange as part of an incompletely documented recipe for AbstractList-based List implementations. It was intended that people creating new kinds of Lists implement this as a helper method to simplify sublist implementations. It is designed to be called only from other public methods that would either themselves perform range checks or skip them if statically unnecessary. So, there aren't any redundant checks in the default removeRange. Leaving this partially exposed as "protected" doesn't quite ensure that implementors follow this guidance, but in practice, I suspect that they all have. So it is not clear whether changing the spec or the implementation would be doing anyone a favor. -Doug From vladimir.x.ivanov at oracle.com Fri Mar 14 11:45:54 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 14 Mar 2014 15:45:54 +0400 Subject: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms Message-ID: <5322EBF2.7030209@oracle.com> http://cr.openjdk.java.net/~vlivanov/8037209/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8037209 440 lines changed: 313 ins; 67 del; 60 mod This is a cleanup of JSR292 code to improve bytecode assembly code for lambda forms. 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} -D...PROFILE_LEVEL={0,1} Best regards, Vladimir Ivanov From david.holmes at oracle.com Fri Mar 14 12:02:16 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Mar 2014 22:02:16 +1000 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <5322E5D6.5020403@oracle.com> References: <5321CEE6.403@oracle.com> <123FE971-9F74-43E6-988A-86D9A1804C68@oracle.com> <5321D9B6.2050301@oracle.com> <5321F5E0.7000408@oracle.com> <5321F87B.8010300@oracle.com> <532200FD.9060705@oracle.com> <53220A38.9080508@oracle.com> <53228C03.5070106@oracle.com> <5322AA31.1040703@oracle.com> <5322DFA5.7070704@gmail.com> <5322E5D6.5020403@oracle.com> Message-ID: <5322EFC8.6030604@oracle.com> Ivan, On 14/03/2014 9:19 PM, Ivan Gerasimov wrote: > Thanks Peter for the comments. > > On 14.03.2014 14:53, Peter Levart wrote: >> On 03/14/2014 08:05 AM, Ivan Gerasimov wrote: >>> One thing I noticed is that some methods I mentioned above >>> (List.subList(), Arrays.sort(), etc) throw IllegalArgumentException >>> when fromIndex > toIndex, not IndexOutOfBoundException. >>> Wouldn't it be more correct to adopt this into removeRange() too? >> >> The question is, what exception should be thrown for removeRange(0, >> -1) then... The order of checks matters and should be specified if two >> kinds of exceptions are thrown... >> > > In my opinion, the order of the checks should match the order of the > listed exceptions in the spec. That's a nice proposal but unfortunately there has never been a rule that you have to document exceptions in the order you expect them to be checked; nor do you have to implement exception checks in the order they are documented. So it is too late to try and enforce this now. David ----- > If the order is: > @throws IndexOutOfBoundException if either index is negative or either > index is greater than size() > @throws IllegalArgumentException if (fromIndex > toIndex) > > then removeRange(0, -1) should throw IndexOutOfBoundException. > > Sincerely yours, > Ivan > From paul.sandoz at oracle.com Fri Mar 14 12:04:38 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 14 Mar 2014 13:04:38 +0100 Subject: RFR 8037106: Optimize Arrays.asList(...).forEach Message-ID: <80B43E05-0AB3-43B7-B4F3-26FBCCD67E6E@oracle.com> Hi, This patch overrides some default methods with more optimal ones for the Arrays.asList implementation: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8037106-arrays.asList.forEach/webrev/ It required some surgical work on tests to shove in the Arrays.asList test case, since it is a factory method and does not support structural modification. There are of course other optimizations that could apply to Arrays.asList, namely that of sub-list, but i have left that as another future possible exercise (plus further work could be done to Abstract/List, including providing a Spliterator for List & RandomAccess). Paul. From david.holmes at oracle.com Fri Mar 14 12:07:47 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Mar 2014 22:07:47 +1000 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <5322EB0F.8010900@cs.oswego.edu> References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> <5322EB0F.8010900@cs.oswego.edu> Message-ID: <5322F113.2070505@oracle.com> Hi Doug, On 14/03/2014 9:42 PM, Doug Lea wrote: > On 03/14/2014 02:38 AM, Martin Buchholz wrote: >> On Thu, Mar 13, 2014 at 3:59 PM, Doug Lea
> > wrote: >> On 03/13/2014 12:34 PM, Martin Buchholz wrote: >> I notice there are zero jtreg tests for removeRange. That >> should be fixed. >> >> I notice there is a removeRange in CopyOnWriteArrayList, but >> it is >> package-private instead of "protected", which seems like an >> oversight. >> Can Doug >> remember any history on that? >> >> >> CopyOnWriteArrayList does not extend AbstractList, but its >> sublist does. The sublist relies on COWAL.removeRange only for clear. >> So COWAL sublist clearing uses the same idea as >> AbstractList, and gives it the same name, but it is not the >> same AbstractList method, so need not be protected. >> >> >> Ahh OK, I think the party line for *users* is if they want to remove a >> range of >> elements from a list, use list.subList(fromIndex, toIndex).clear (), >> so there's >> no advantage in making COWAL.removeRange a public interface. > > Right. This relates to the question of range checks for removeRange. > Josh Block created removeRange as part of an incompletely documented > recipe for AbstractList-based List implementations. It was intended that > people creating new kinds of Lists implement this as a helper > method to simplify sublist implementations. It is designed > to be called only from other public methods that would either themselves > perform range checks or skip them if statically unnecessary. > So, there aren't any redundant checks in the default removeRange. > Leaving this partially exposed as "protected" doesn't quite > ensure that implementors follow this guidance, but in practice, > I suspect that they all have. So it is not clear whether changing > the spec or the implementation would be doing anyone a favor. So what you are saying is that protected overrides of protected methods are not required to honor the specification of the super method? That certainly gives some implementation flexibility, but I don't think I've ever seen it expressed as a rule. David ----- > -Doug > > > From ivan.gerasimov at oracle.com Fri Mar 14 12:14:59 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 14 Mar 2014 16:14:59 +0400 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <5322EFC8.6030604@oracle.com> References: <5321CEE6.403@oracle.com> <123FE971-9F74-43E6-988A-86D9A1804C68@oracle.com> <5321D9B6.2050301@oracle.com> <5321F5E0.7000408@oracle.com> <5321F87B.8010300@oracle.com> <532200FD.9060705@oracle.com> <53220A38.9080508@oracle.com> <53228C03.5070106@oracle.com> <5322AA31.1040703@oracle.com> <5322DFA5.7070704@gmail.com> <5322E5D6.5020403@oracle.com> <5322EFC8.6030604@oracle.com> Message-ID: <5322F2C3.4080603@oracle.com> On 14.03.2014 16:02, David Holmes wrote: > Ivan, > > On 14/03/2014 9:19 PM, Ivan Gerasimov wrote: >> Thanks Peter for the comments. >> >> On 14.03.2014 14:53, Peter Levart wrote: >>> On 03/14/2014 08:05 AM, Ivan Gerasimov wrote: >>>> One thing I noticed is that some methods I mentioned above >>>> (List.subList(), Arrays.sort(), etc) throw IllegalArgumentException >>>> when fromIndex > toIndex, not IndexOutOfBoundException. >>>> Wouldn't it be more correct to adopt this into removeRange() too? >>> >>> The question is, what exception should be thrown for removeRange(0, >>> -1) then... The order of checks matters and should be specified if two >>> kinds of exceptions are thrown... >>> >> >> In my opinion, the order of the checks should match the order of the >> listed exceptions in the spec. > > That's a nice proposal but unfortunately there has never been a rule > that you have to document exceptions in the order you expect them to > be checked; nor do you have to implement exception checks in the order > they are documented. So it is too late to try and enforce this now. > Sigh. The order can still be stated explicitly in the doc, if it's decided to throw IllegalArgumentException. And, of course, there's no such problem if IndexOutOfBoundException is the only exception thrown. Sincerely yours, Ivan > David > ----- > >> If the order is: >> @throws IndexOutOfBoundException if either index is negative or either >> index is greater than size() >> @throws IllegalArgumentException if (fromIndex > toIndex) >> >> then removeRange(0, -1) should throw IndexOutOfBoundException. >> >> Sincerely yours, >> Ivan >> > > From vladimir.x.ivanov at oracle.com Fri Mar 14 12:19:35 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 14 Mar 2014 16:19:35 +0400 Subject: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms In-Reply-To: <5322EBF2.7030209@oracle.com> References: <5322EBF2.7030209@oracle.com> Message-ID: <5322F3D7.9010103@oracle.com> FYI, this change isn't limited to only bytecode assembly improvements, but also contains caching of lambda forms for setters/getter of typed arrays. If there are any objections, I can back the caching logic out and include it into one of upcoming changes. Best regards, Vladimir Ivanov On 3/14/14 3:45 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8037209/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8037209 > 440 lines changed: 313 ins; 67 del; 60 mod > > This is a cleanup of JSR292 code to improve bytecode assembly code for > lambda forms. > > 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} > -D...PROFILE_LEVEL={0,1} > > Best regards, > Vladimir Ivanov > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From david.holmes at oracle.com Fri Mar 14 12:20:56 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Mar 2014 22:20:56 +1000 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <5322F2C3.4080603@oracle.com> References: <5321CEE6.403@oracle.com> <123FE971-9F74-43E6-988A-86D9A1804C68@oracle.com> <5321D9B6.2050301@oracle.com> <5321F5E0.7000408@oracle.com> <5321F87B.8010300@oracle.com> <532200FD.9060705@oracle.com> <53220A38.9080508@oracle.com> <53228C03.5070106@oracle.com> <5322AA31.1040703@oracle.com> <5322DFA5.7070704@gmail.com> <5322E5D6.5020403@oracle.com> <5322EFC8.6030604@oracle.com> <5322F2C3.4080603@oracle.com> Message-ID: <5322F428.9020100@oracle.com> On 14/03/2014 10:14 PM, Ivan Gerasimov wrote: > > On 14.03.2014 16:02, David Holmes wrote: >> Ivan, >> >> On 14/03/2014 9:19 PM, Ivan Gerasimov wrote: >>> Thanks Peter for the comments. >>> >>> On 14.03.2014 14:53, Peter Levart wrote: >>>> On 03/14/2014 08:05 AM, Ivan Gerasimov wrote: >>>>> One thing I noticed is that some methods I mentioned above >>>>> (List.subList(), Arrays.sort(), etc) throw IllegalArgumentException >>>>> when fromIndex > toIndex, not IndexOutOfBoundException. >>>>> Wouldn't it be more correct to adopt this into removeRange() too? >>>> >>>> The question is, what exception should be thrown for removeRange(0, >>>> -1) then... The order of checks matters and should be specified if two >>>> kinds of exceptions are thrown... >>>> >>> >>> In my opinion, the order of the checks should match the order of the >>> listed exceptions in the spec. >> >> That's a nice proposal but unfortunately there has never been a rule >> that you have to document exceptions in the order you expect them to >> be checked; nor do you have to implement exception checks in the order >> they are documented. So it is too late to try and enforce this now. >> > Sigh. > The order can still be stated explicitly in the doc, if it's decided to > throw IllegalArgumentException. Of course the order can be explicitly stated. My point was that you can't just look at existing spec and decide that defines the order of checking. Cheers, David > And, of course, there's no such problem if IndexOutOfBoundException is > the only exception thrown. > > Sincerely yours, > Ivan > > >> David >> ----- >> >>> If the order is: >>> @throws IndexOutOfBoundException if either index is negative or either >>> index is greater than size() >>> @throws IllegalArgumentException if (fromIndex > toIndex) >>> >>> then removeRange(0, -1) should throw IndexOutOfBoundException. >>> >>> Sincerely yours, >>> Ivan >>> >> >> > From dl at cs.oswego.edu Fri Mar 14 12:22:07 2014 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 14 Mar 2014 08:22:07 -0400 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <5322F113.2070505@oracle.com> References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> <5322EB0F.8010900@cs.oswego.edu> <5322F113.2070505@oracle.com> Message-ID: <5322F46F.5050700@cs.oswego.edu> On 03/14/2014 08:07 AM, David Holmes wrote: > So what you are saying is that protected overrides of protected methods are not > required to honor the specification of the super method? Not always, but ... > > That certainly gives some implementation flexibility, but I don't think I've > ever seen it expressed as a rule. > ... this is the convention for @implSpecs for default methods on interfaces. Which probably would have been used here instead of AbstractList had they existed back in JDK1.2. -Doug From paul.sandoz at oracle.com Fri Mar 14 12:38:36 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 14 Mar 2014 13:38:36 +0100 Subject: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms In-Reply-To: <5322F3D7.9010103@oracle.com> References: <5322EBF2.7030209@oracle.com> <5322F3D7.9010103@oracle.com> Message-ID: <94F61B19-8904-42FA-9E16-CC0A6B30FD79@oracle.com> On Mar 14, 2014, at 1:19 PM, Vladimir Ivanov wrote: > FYI, this change isn't limited to only bytecode assembly improvements, but also contains caching of lambda forms for setters/getter of typed arrays. > Do you mean for MethodHandles.arrayElementGetter/Setter? If so i don't see relevant changes in: http://cr.openjdk.java.net/~vlivanov/8037210/webrev.00/src/share/classes/java/lang/invoke/MethodHandleImpl.java.sdiff.html to say MethodHandleImpl.ArrayAccessor: static final class ArrayAccessor { /// Support for array element access static final HashMap, MethodHandle> GETTER_CACHE = new HashMap<>(); // TODO use it static final HashMap, MethodHandle> SETTER_CACHE = new HashMap<>(); // TODO use it Paul. > If there are any objections, I can back the caching logic out and include it into one of upcoming changes. > > Best regards, > Vladimir Ivanov > > On 3/14/14 3:45 PM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8037209/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8037209 >> 440 lines changed: 313 ins; 67 del; 60 mod >> >> This is a cleanup of JSR292 code to improve bytecode assembly code for >> lambda forms. >> >> 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} >> -D...PROFILE_LEVEL={0,1} >> >> 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 Mar 14 13:17:56 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 14 Mar 2014 17:17:56 +0400 Subject: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms In-Reply-To: <94F61B19-8904-42FA-9E16-CC0A6B30FD79@oracle.com> References: <5322EBF2.7030209@oracle.com> <5322F3D7.9010103@oracle.com> <94F61B19-8904-42FA-9E16-CC0A6B30FD79@oracle.com> Message-ID: <53230184.9090007@oracle.com> Paul, You are looking at the other fix (8037210). The correct link is [1]. Best regards, Vladimir Ivanov [1] http://cr.openjdk.java.net/~vlivanov/8037209/webrev.00/src/share/classes/java/lang/invoke/MethodHandleImpl.java.sdiff.html On 3/14/14 4:38 PM, Paul Sandoz wrote: > > On Mar 14, 2014, at 1:19 PM, Vladimir Ivanov > > wrote: > >> FYI, this change isn't limited to only bytecode assembly improvements, >> but also contains caching of lambda forms for setters/getter of typed >> arrays. >> > > Do you mean for MethodHandles.arrayElementGetter/Setter? If so i don't > see relevant changes in: > > http://cr.openjdk.java.net/~vlivanov/8037210/webrev.00/src/share/classes/java/lang/invoke/MethodHandleImpl.java.sdiff.html > > to say MethodHandleImpl.ArrayAccessor: > > static final class ArrayAccessor { > /// Support for array element access > static final HashMap, MethodHandle> GETTER_CACHE = new > HashMap<>(); // TODO use it > static final HashMap, MethodHandle> SETTER_CACHE = new > HashMap<>(); // TODO use it > > Paul. > >> If there are any objections, I can back the caching logic out and >> include it into one of upcoming changes. >> >> Best regards, >> Vladimir Ivanov >> >> On 3/14/14 3:45 PM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8037209/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8037209 >>> 440 lines changed: 313 ins; 67 del; 60 mod >>> >>> This is a cleanup of JSR292 code to improve bytecode assembly code for >>> lambda forms. >>> >>> 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} >>> -D...PROFILE_LEVEL={0,1} >>> >>> Best regards, >>> Vladimir Ivanov >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From marcus.lagergren at oracle.com Fri Mar 14 13:25:47 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Fri, 14 Mar 2014 14:25:47 +0100 Subject: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms In-Reply-To: <53230184.9090007@oracle.com> References: <5322EBF2.7030209@oracle.com> <5322F3D7.9010103@oracle.com> <94F61B19-8904-42FA-9E16-CC0A6B30FD79@oracle.com> <53230184.9090007@oracle.com> Message-ID: To get into this faster it would be nice if the new private fields (or the existing ones for that matter) had a comment describing what they were for, e.g. + private final byte[] localTypes; + private final Class[] localClasses; I can figure it out from the code, but it would have been a better starting point. If that there are new apparent performance regressions caused by, e.g. profile pollusion from reusing existing method handles, I am fine with this. +1 /M On 14 Mar 2014, at 14:17, Vladimir Ivanov wrote: > Paul, > > You are looking at the other fix (8037210). > The correct link is [1]. > > Best regards, > Vladimir Ivanov > > [1] http://cr.openjdk.java.net/~vlivanov/8037209/webrev.00/src/share/classes/java/lang/invoke/MethodHandleImpl.java.sdiff.html > > On 3/14/14 4:38 PM, Paul Sandoz wrote: >> >> On Mar 14, 2014, at 1:19 PM, Vladimir Ivanov >> > wrote: >> >>> FYI, this change isn't limited to only bytecode assembly improvements, >>> but also contains caching of lambda forms for setters/getter of typed >>> arrays. >>> >> >> Do you mean for MethodHandles.arrayElementGetter/Setter? If so i don't >> see relevant changes in: >> >> http://cr.openjdk.java.net/~vlivanov/8037210/webrev.00/src/share/classes/java/lang/invoke/MethodHandleImpl.java.sdiff.html >> >> to say MethodHandleImpl.ArrayAccessor: >> >> static final class ArrayAccessor { >> /// Support for array element access >> static final HashMap, MethodHandle> GETTER_CACHE = new >> HashMap<>(); // TODO use it >> static final HashMap, MethodHandle> SETTER_CACHE = new >> HashMap<>(); // TODO use it >> >> Paul. >> >>> If there are any objections, I can back the caching logic out and >>> include it into one of upcoming changes. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 3/14/14 3:45 PM, Vladimir Ivanov wrote: >>>> http://cr.openjdk.java.net/~vlivanov/8037209/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8037209 >>>> 440 lines changed: 313 ins; 67 del; 60 mod >>>> >>>> This is a cleanup of JSR292 code to improve bytecode assembly code for >>>> lambda forms. >>>> >>>> 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} >>>> -D...PROFILE_LEVEL={0,1} >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> _______________________________________________ >>>> mlvm-dev mailing list >>>> mlvm-dev at openjdk.java.net >>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> >> >> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> From joel.franck at oracle.com Fri Mar 14 13:23:25 2014 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Fri, 14 Mar 2014 14:23:25 +0100 Subject: clarification on docs of Class#getInterfaces() and Class#getGenericInterfaces() needed? In-Reply-To: <531DD5CA.9080106@gmx.org> References: <531DD5CA.9080106@gmx.org> Message-ID: <20140314132325.GJ23030@oracle.com> Hi Jochen, On 2014-03-10, Jochen Theodorou wrote: > > You basically find this sentence for Class#getInterfaces() and > Class#getGenericInterfaces() "If this object represents a class, the > return value is an array containing objects representing all > interfaces implemented by the class." > > The problem is that wording of "all". When I look at for example > AbstractList, then all means to me more than just List (which is > what is returned for AbstractList.class.getInterfaces()). I agree this could be clearer. I plan to improve this for 9. See https://bugs.openjdk.java.net/browse/JDK-8023020 for the javadoc cleanup and https://bugs.openjdk.java.net/browse/JDK-6761417 for a related enhancement request. I do think it is important to state the various corner cases but the main part of the method doc could be improved. cheers /Joel From brian.burkhalter at oracle.com Fri Mar 14 14:17:58 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 14 Mar 2014 07:17:58 -0700 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: <5322DC66.5070003@gmail.com> References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <531EC6BF.4050701@oracle.com> <4742E0AD-8D87-4F22-8F23-779BDF3A58FE@oracle.com> <5320240C.60304@gmail.com> <5322DC66.5070003@gmail.com> Message-ID: On Mar 14, 2014, at 3:39 AM, Peter Levart wrote: > But in general it would be better to just use "ThreadLocalRandom.current()" everywhere you use "rnd" variable. This is precisely it's purpose - a random number generator that is never contended. The overhead of ThreadLocalRandom.current() call is hardly measurable by itself. I'll update that and re-run some of the benchmarks later. Thanks, Brian From peter.levart at gmail.com Fri Mar 14 14:18:27 2014 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 14 Mar 2014 15:18:27 +0100 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <5322F2C3.4080603@oracle.com> References: <5321CEE6.403@oracle.com> <123FE971-9F74-43E6-988A-86D9A1804C68@oracle.com> <5321D9B6.2050301@oracle.com> <5321F5E0.7000408@oracle.com> <5321F87B.8010300@oracle.com> <532200FD.9060705@oracle.com> <53220A38.9080508@oracle.com> <53228C03.5070106@oracle.com> <5322AA31.1040703@oracle.com> <5322DFA5.7070704@gmail.com> <5322E5D6.5020403@oracle.com> <5322EFC8.6030604@oracle.com> <5322F2C3.4080603@oracle.com> Message-ID: <53230FB3.5020406@gmail.com> On 03/14/2014 01:14 PM, Ivan Gerasimov wrote: > > On 14.03.2014 16:02, David Holmes wrote: >> Ivan, >> >> On 14/03/2014 9:19 PM, Ivan Gerasimov wrote: >>> Thanks Peter for the comments. >>> >>> On 14.03.2014 14:53, Peter Levart wrote: >>>> On 03/14/2014 08:05 AM, Ivan Gerasimov wrote: >>>>> One thing I noticed is that some methods I mentioned above >>>>> (List.subList(), Arrays.sort(), etc) throw IllegalArgumentException >>>>> when fromIndex > toIndex, not IndexOutOfBoundException. >>>>> Wouldn't it be more correct to adopt this into removeRange() too? >>>> >>>> The question is, what exception should be thrown for removeRange(0, >>>> -1) then... The order of checks matters and should be specified if two >>>> kinds of exceptions are thrown... >>>> >>> >>> In my opinion, the order of the checks should match the order of the >>> listed exceptions in the spec. >> >> That's a nice proposal but unfortunately there has never been a rule >> that you have to document exceptions in the order you expect them to >> be checked; nor do you have to implement exception checks in the >> order they are documented. So it is too late to try and enforce this >> now. >> > Sigh. > The order can still be stated explicitly in the doc, if it's decided > to throw IllegalArgumentException. Or the checks could be documented in a way that they have disjunctive conditions so that the order doesn't matter: @throws IndexOutOfBoundException if either index is negative or either index is greater than size() @throws IllegalArgumentException if (fromIndex > toIndex) and neither index is negative nor greater than size() Regards, Peter > And, of course, there's no such problem if IndexOutOfBoundException is > the only exception thrown. > > Sincerely yours, > Ivan > > >> David >> ----- >> >>> If the order is: >>> @throws IndexOutOfBoundException if either index is negative or either >>> index is greater than size() >>> @throws IllegalArgumentException if (fromIndex > toIndex) >>> >>> then removeRange(0, -1) should throw IndexOutOfBoundException. >>> >>> Sincerely yours, >>> Ivan >>> >> >> > From brian.burkhalter at oracle.com Fri Mar 14 14:18:59 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 14 Mar 2014 07:18:59 -0700 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: <5322DD1C.3090601@gmail.com> References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <5315EDAA.5020801@gmail.com> <531EC3BD.9050605@oracle.com> <53201EA5.9090702@gmail.com> <9F3778F1-2BEE-4E9E-B362-D4547C72F475@oracle.com> <5322DD1C.3090601@gmail.com> Message-ID: On Mar 14, 2014, at 3:42 AM, Peter Levart wrote: >> This approach does have the advantage or not using volatile. > > I've forgot to run this on my Raspberry Pi. Stay tuned... I used to have a BeagleBoard on a previous project but do not have any of these sorts of devices at my disposal at this time. Thanks, Brian From Alan.Bateman at oracle.com Fri Mar 14 14:30:22 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 14 Mar 2014 14:30:22 +0000 Subject: RFR 8037106: Optimize Arrays.asList(...).forEach In-Reply-To: <80B43E05-0AB3-43B7-B4F3-26FBCCD67E6E@oracle.com> References: <80B43E05-0AB3-43B7-B4F3-26FBCCD67E6E@oracle.com> Message-ID: <5323127E.1060909@oracle.com> On 14/03/2014 12:04, Paul Sandoz wrote: > Hi, > > This patch overrides some default methods with more optimal ones for the Arrays.asList implementation: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8037106-arrays.asList.forEach/webrev/ > > It required some surgical work on tests to shove in the Arrays.asList test case, since it is a factory method and does not support structural modification. > > There are of course other optimizations that could apply to Arrays.asList, namely that of sub-list, but i have left that as another future possible exercise (plus further work could be done to Abstract/List, including providing a Spliterator for List& RandomAccess). > > Paul. The override in Arrays look good to me. The refactoring in the tests looks good too (and it reduced the line length so should make future side-by-side reviews a bit easier). -Alan. From Alan.Bateman at oracle.com Fri Mar 14 14:38:59 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 14 Mar 2014 14:38:59 +0000 Subject: RFR (JAXP): 8035577: Xerces Update: impl/xpath/regex/RangeToken.java In-Reply-To: <53223A3C.6020706@oracle.com> References: <53223A3C.6020706@oracle.com> Message-ID: <53231483.7010908@oracle.com> On 13/03/2014 23:07, David Li wrote: > Hi, > > This is an update from Xerces for file > impl/xpath/regex/TokenRange.java. For details, please refer to: > https://bugs.openjdk.java.net/browse/JDK-8035577. > > Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035577/webrev/ > > New test case was added for code change in > RangeToken.intersectRanges. Other minor issues from last review > comments are updated. > > Existing tests: JAXP SQE and unit tests passed. A bit of side question but this regex code seems very old (Hashtable, Vector ...) and I'm wondering how feasible it would be to replace it completely with java.util.regex. Joe might know if this has ever been discussed upstream (and I appreciate there is a desire to keep the code the same where possible). -Alan From Alan.Bateman at oracle.com Fri Mar 14 14:41:55 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 14 Mar 2014 14:41:55 +0000 Subject: RFR: 8036786: Update jdk7 testlibrary to match jdk8 In-Reply-To: References: <5318956F.1020603@oracle.com> Message-ID: <53231533.9010908@oracle.com> Adding serviceability-dev to the CC list as this seems to be where this testlibrary has mostly been developed and maintained. -Alan. On 13/03/2014 14:02, Mattis Castegren wrote: > Hi > > Could we have someone review this change. This is just a backport from JDK8, but there were some small changes so we want to get a proper review here. > > We have several other backports waiting for this change (fixes using the new test libraries), so it would be good to get this going. > > Kind Regards > /Mattis > > -----Original Message----- > From: Vladimir Kempik > Sent: den 6 mars 2014 16:34 > To: core-libs-dev at openjdk.java.net > Cc: Mattis Castegren > Subject: RFR: 8036786: Update jdk7 testlibrary to match jdk8 > > Please review this change to update jdk part of testlibrary in jdk7. > > It updates testlibrary with new apis from jdk8's testlibrary. > > When porting jdk8's testlibrary to jdk7, I had to make few changes: > > 1) rewrite one lambda usage in StreamPumper.java to non-lambda version. > > 2) get rid of predicate functionality in ProcessTools.java: startProcess > as it wasn't used anyway and unsupported in jdk7. > > Every test in open part of jdk that uses testlibrary still works after > update (in fact there are 3 of them). > > Webrev: > http://cr.openjdk.java.net/~vkempik/8036786/webrev.00/ > > Thanks, Vladimir. From martinrb at google.com Fri Mar 14 15:46:35 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 14 Mar 2014 08:46:35 -0700 Subject: RFR 8037106: Optimize Arrays.asList(...).forEach In-Reply-To: <80B43E05-0AB3-43B7-B4F3-26FBCCD67E6E@oracle.com> References: <80B43E05-0AB3-43B7-B4F3-26FBCCD67E6E@oracle.com> Message-ID: Looks good to me. I'm willing to believe for-loop over array is as efficient as fortran-style loop + for (E e : a) { + action.accept(e); + } but then you could change the other loops as well, e.g. in indexOf + final int size = a.length; + for (int i = 0; i < size; i++) { I like to write this using the idiom for (int i = 0, size = ...; i < size; i++) On Fri, Mar 14, 2014 at 5:04 AM, Paul Sandoz wrote: > Hi, > > This patch overrides some default methods with more optimal ones for the > Arrays.asList implementation: > > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8037106-arrays.asList.forEach/webrev/ > > It required some surgical work on tests to shove in the Arrays.asList test > case, since it is a factory method and does not support structural > modification. > > There are of course other optimizations that could apply to Arrays.asList, > namely that of sub-list, but i have left that as another future possible > exercise (plus further work could be done to Abstract/List, including > providing a Spliterator for List & RandomAccess). > > Paul. > From paul.sandoz at oracle.com Fri Mar 14 15:53:01 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 14 Mar 2014 16:53:01 +0100 Subject: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms In-Reply-To: <53230184.9090007@oracle.com> References: <5322EBF2.7030209@oracle.com> <5322F3D7.9010103@oracle.com> <94F61B19-8904-42FA-9E16-CC0A6B30FD79@oracle.com> <53230184.9090007@oracle.com> Message-ID: <2FCC64E3-3753-4CE0-9CC6-849FF737BFB5@oracle.com> On Mar 14, 2014, at 2:17 PM, Vladimir Ivanov wrote: > Paul, > > You are looking at the other fix (8037210). > The correct link is [1]. > 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? 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 paul.sandoz at oracle.com Fri Mar 14 16:10:48 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 14 Mar 2014 17:10:48 +0100 Subject: RFR 8037106: Optimize Arrays.asList(...).forEach In-Reply-To: References: <80B43E05-0AB3-43B7-B4F3-26FBCCD67E6E@oracle.com> Message-ID: <0A4CACFA-02EF-4EF3-99EF-A7D1455E272A@oracle.com> On Mar 14, 2014, at 4:46 PM, Martin Buchholz wrote: > Looks good to me. > Thanks. > I'm willing to believe for-loop over array is as efficient as fortran-style loop > > + for (E e : a) { > + action.accept(e); > + } > Yeah, i previously went through a whole bunch of code replacing such fortran-style loops with 'foreach' style based on automated code analysis. > but then you could change the other loops as well, e.g. in indexOf > > + final int size = a.length; > + for (int i = 0; i < size; i++) { > > I like to write this using the idiom > > for (int i = 0, size = ...; i < size; i++) > I copied over code from ArrayList, but presumably the following is sufficient: @Override public void replaceAll(UnaryOperator operator) { Objects.requireNonNull(operator); final E[] a = this.a; for (int i = 0; i < a.length; i++) { a[i] = operator.apply(a[i]); } } ? no need for a local size variable. I changed my local patch to do the above. Paul. From ivan.gerasimov at oracle.com Fri Mar 14 16:22:56 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 14 Mar 2014 20:22:56 +0400 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <53230FB3.5020406@gmail.com> References: <5321CEE6.403@oracle.com> <123FE971-9F74-43E6-988A-86D9A1804C68@oracle.com> <5321D9B6.2050301@oracle.com> <5321F5E0.7000408@oracle.com> <5321F87B.8010300@oracle.com> <532200FD.9060705@oracle.com> <53220A38.9080508@oracle.com> <53228C03.5070106@oracle.com> <5322AA31.1040703@oracle.com> <5322DFA5.7070704@gmail.com> <5322E5D6.5020403@oracle.com> <5322EFC8.6030604@oracle.com> <5322F2C3.4080603@oracle.com> <53230FB3.5020406@gmail.com> Message-ID: <53232CE0.8030100@oracle.com> On 14.03.2014 18:18, Peter Levart wrote: > On 03/14/2014 01:14 PM, Ivan Gerasimov wrote: >> >> On 14.03.2014 16:02, David Holmes wrote: >>> Ivan, >>> >>> On 14/03/2014 9:19 PM, Ivan Gerasimov wrote: >>>> Thanks Peter for the comments. >>>> >>>> On 14.03.2014 14:53, Peter Levart wrote: >>>>> On 03/14/2014 08:05 AM, Ivan Gerasimov wrote: >>>>>> One thing I noticed is that some methods I mentioned above >>>>>> (List.subList(), Arrays.sort(), etc) throw IllegalArgumentException >>>>>> when fromIndex > toIndex, not IndexOutOfBoundException. >>>>>> Wouldn't it be more correct to adopt this into removeRange() too? >>>>> >>>>> The question is, what exception should be thrown for removeRange(0, >>>>> -1) then... The order of checks matters and should be specified if >>>>> two >>>>> kinds of exceptions are thrown... >>>>> >>>> >>>> In my opinion, the order of the checks should match the order of the >>>> listed exceptions in the spec. >>> >>> That's a nice proposal but unfortunately there has never been a rule >>> that you have to document exceptions in the order you expect them to >>> be checked; nor do you have to implement exception checks in the >>> order they are documented. So it is too late to try and enforce this >>> now. >>> >> Sigh. >> The order can still be stated explicitly in the doc, if it's decided >> to throw IllegalArgumentException. > > Or the checks could be documented in a way that they have disjunctive > conditions so that the order doesn't matter: > > @throws IndexOutOfBoundException if either index is negative or either > index is greater than size() > @throws IllegalArgumentException if (fromIndex > toIndex) and neither > index is negative nor greater than size() > Yes, this is the most clear way! Sincerely yours, Ivan > Regards, Peter > >> And, of course, there's no such problem if IndexOutOfBoundException >> is the only exception thrown. >> >> Sincerely yours, >> Ivan >> >> >>> David >>> ----- >>> >>>> If the order is: >>>> @throws IndexOutOfBoundException if either index is negative or either >>>> index is greater than size() >>>> @throws IllegalArgumentException if (fromIndex > toIndex) >>>> >>>> then removeRange(0, -1) should throw IndexOutOfBoundException. >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>> >>> >> > > > From vladimir.x.ivanov at oracle.com Fri Mar 14 16:36:03 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 14 Mar 2014 20:36:03 +0400 Subject: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms In-Reply-To: <2FCC64E3-3753-4CE0-9CC6-849FF737BFB5@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> Message-ID: <53232FF3.9020803@oracle.com> > 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 ivan.gerasimov at oracle.com Fri Mar 14 16:58:20 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 14 Mar 2014 20:58:20 +0400 Subject: RFR [6943190] TEST_BUG: java/lang/Runtime/exec/ExecWithInput.java hardcodes path to cat In-Reply-To: <530F06A3.1030107@oracle.com> References: <530B80CF.9090403@oracle.com> <530E5D0F.90409@oracle.com> <530E6877.5050504@oracle.com> <530F06A3.1030107@oracle.com> Message-ID: <5323352C.4080007@oracle.com> Hello! This is a friendly reminder. Can someone with the Reviewer status please help review this? In short: we have a few java tests that run shell commands. In some tests the path to the command is omitted, in other tests an absolute path is given. In the third group of tests, the *other* absolute path to the same commands is used. As Martin suggested, I added searching for the command at certain fixed directories before using it. The final webrev can be found here: http://cr.openjdk.java.net/~igerasim/6943190/2/webrev/ Thanks in advance, Ivan From huizhe.wang at oracle.com Fri Mar 14 17:01:16 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 14 Mar 2014 10:01:16 -0700 Subject: RFR (JAXP): 8035577: Xerces Update: impl/xpath/regex/RangeToken.java In-Reply-To: <53231483.7010908@oracle.com> References: <53223A3C.6020706@oracle.com> <53231483.7010908@oracle.com> Message-ID: <532335DC.2070501@oracle.com> On 3/14/2014 7:38 AM, Alan Bateman wrote: > On 13/03/2014 23:07, David Li wrote: >> Hi, >> >> This is an update from Xerces for file >> impl/xpath/regex/TokenRange.java. For details, please refer to: >> https://bugs.openjdk.java.net/browse/JDK-8035577. >> >> Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035577/webrev/ >> >> New test case was added for code change in >> RangeToken.intersectRanges. Other minor issues from last review >> comments are updated. >> >> Existing tests: JAXP SQE and unit tests passed. > A bit of side question but this regex code seems very old (Hashtable, > Vector ...) and I'm wondering how feasible it would be to replace it > completely with java.util.regex. Joe might know if this has ever been > discussed upstream (and I appreciate there is a desire to keep the > code the same where possible). We are open to newer features. Xerces still support JDK 1.4, but we have moved on and accepted JDK 7 features. We will update and replace the old code such as Hashtable, Vector along the way and where possible. Note that, I mentioned to the corelib before, that Xalan has a strip-down version of Hashtable that actually performs better than Hashmap. As for the Xerces-flavor of regex, it's a XML Schema conformant implementation. It supports that defined in the XML Schema specification: http://www.w3.org/TR/2000/WD-xmlschema-2-20000407/#regexs. It may be possible to replace with java.util.regex but not without some sort of pattern-translation mechanism. -Joe > > -Alan From huizhe.wang at oracle.com Fri Mar 14 21:02:02 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 14 Mar 2014 14:02:02 -0700 Subject: RFR (JAXP): 8035577: Xerces Update: impl/xpath/regex/RangeToken.java In-Reply-To: <532335DC.2070501@oracle.com> References: <53223A3C.6020706@oracle.com> <53231483.7010908@oracle.com> <532335DC.2070501@oracle.com> Message-ID: <53236E4A.2010808@oracle.com> I may be wrong, but the test passes without the patch. It looks like we may need to fix the bug David found: https://bugs.openjdk.java.net/browse/JDK-8037324 -Joe On 3/14/2014 10:01 AM, huizhe wang wrote: > > On 3/14/2014 7:38 AM, Alan Bateman wrote: >> On 13/03/2014 23:07, David Li wrote: >>> Hi, >>> >>> This is an update from Xerces for file >>> impl/xpath/regex/TokenRange.java. For details, please refer to: >>> https://bugs.openjdk.java.net/browse/JDK-8035577. >>> >>> Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035577/webrev/ >>> >>> New test case was added for code change in >>> RangeToken.intersectRanges. Other minor issues from last review >>> comments are updated. >>> >>> Existing tests: JAXP SQE and unit tests passed. >> A bit of side question but this regex code seems very old (Hashtable, >> Vector ...) and I'm wondering how feasible it would be to replace it >> completely with java.util.regex. Joe might know if this has ever been >> discussed upstream (and I appreciate there is a desire to keep the >> code the same where possible). > > We are open to newer features. Xerces still support JDK 1.4, but we > have moved on and accepted JDK 7 features. We will update and replace > the old code such as Hashtable, Vector along the way and where > possible. Note that, I mentioned to the corelib before, that Xalan has > a strip-down version of Hashtable that actually performs better than > Hashmap. > > As for the Xerces-flavor of regex, it's a XML Schema conformant > implementation. It supports that defined in the XML Schema > specification: > http://www.w3.org/TR/2000/WD-xmlschema-2-20000407/#regexs. It may be > possible to replace with java.util.regex but not without some sort of > pattern-translation mechanism. > > -Joe > >> >> -Alan > From mike.duigou at oracle.com Fri Mar 14 21:44:31 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 14 Mar 2014 14:44:31 -0700 Subject: RFR 8037106: Optimize Arrays.asList(...).forEach In-Reply-To: <80B43E05-0AB3-43B7-B4F3-26FBCCD67E6E@oracle.com> References: <80B43E05-0AB3-43B7-B4F3-26FBCCD67E6E@oracle.com> Message-ID: Looks good to me. There are some additional optimization opportunities but they can certainly wait. Mike On Mar 14 2014, at 05:04 , Paul Sandoz wrote: > Hi, > > This patch overrides some default methods with more optimal ones for the Arrays.asList implementation: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8037106-arrays.asList.forEach/webrev/ > > It required some surgical work on tests to shove in the Arrays.asList test case, since it is a factory method and does not support structural modification. > > There are of course other optimizations that could apply to Arrays.asList, namely that of sub-list, but i have left that as another future possible exercise (plus further work could be done to Abstract/List, including providing a Spliterator for List & RandomAccess). > > Paul. From mike.duigou at oracle.com Fri Mar 14 21:44:31 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 14 Mar 2014 14:44:31 -0700 Subject: RFR 8037106: Optimize Arrays.asList(...).forEach In-Reply-To: <80B43E05-0AB3-43B7-B4F3-26FBCCD67E6E@oracle.com> References: <80B43E05-0AB3-43B7-B4F3-26FBCCD67E6E@oracle.com> Message-ID: <8F8875CF-EC55-4C1D-B913-8F426EF6B8A5@oracle.com> Looks good to me. There are some additional optimization opportunities but they can certainly wait. Mike On Mar 14 2014, at 05:04 , Paul Sandoz wrote: > Hi, > > This patch overrides some default methods with more optimal ones for the Arrays.asList implementation: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8037106-arrays.asList.forEach/webrev/ > > It required some surgical work on tests to shove in the Arrays.asList test case, since it is a factory method and does not support structural modification. > > There are of course other optimizations that could apply to Arrays.asList, namely that of sub-list, but i have left that as another future possible exercise (plus further work could be done to Abstract/List, including providing a Spliterator for List & RandomAccess). > > Paul. From Ulf.Zibis at CoSoCo.de Fri Mar 14 23:17:42 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sat, 15 Mar 2014 00:17:42 +0100 Subject: RFR 8037106: Optimize Arrays.asList(...).forEach In-Reply-To: <0A4CACFA-02EF-4EF3-99EF-A7D1455E272A@oracle.com> References: <80B43E05-0AB3-43B7-B4F3-26FBCCD67E6E@oracle.com> <0A4CACFA-02EF-4EF3-99EF-A7D1455E272A@oracle.com> Message-ID: <53238E16.9060307@CoSoCo.de> Am 14.03.2014 17:10, schrieb Paul Sandoz: >> I'm willing to believe for-loop over array is as efficient as fortran-style loop >> >> + for (E e : a) { >> + action.accept(e); >> + } >> > Yeah, i previously went through a whole bunch of code replacing such fortran-style loops with 'foreach' style based on automated code analysis. But wouldn't this help a little more? : + final E[] a = this.a; + for (E e : a) { + action.accept(e); + } I more like the given style with less spaces: 3854 for (int i=0; i References: <53223A3C.6020706@oracle.com> <53231483.7010908@oracle.com> <532335DC.2070501@oracle.com> <53236E4A.2010808@oracle.com> Message-ID: <53239FE5.6040304@oracle.com> Yeah, the test passes without the patch. That is my error. The test I wrote is for testing the correctness of the code I added. It doesn't test the specific change. I can add another test for the change. I can also move the bug I filed to this bug fix. -David On 3/14/2014 2:02 PM, huizhe wang wrote: > I may be wrong, but the test passes without the patch. It looks like > we may need to fix the bug David found: > https://bugs.openjdk.java.net/browse/JDK-8037324 > > -Joe > > > On 3/14/2014 10:01 AM, huizhe wang wrote: >> >> On 3/14/2014 7:38 AM, Alan Bateman wrote: >>> On 13/03/2014 23:07, David Li wrote: >>>> Hi, >>>> >>>> This is an update from Xerces for file >>>> impl/xpath/regex/TokenRange.java. For details, please refer to: >>>> https://bugs.openjdk.java.net/browse/JDK-8035577. >>>> >>>> Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035577/webrev/ >>>> >>>> New test case was added for code change in >>>> RangeToken.intersectRanges. Other minor issues from last review >>>> comments are updated. >>>> >>>> Existing tests: JAXP SQE and unit tests passed. >>> A bit of side question but this regex code seems very old >>> (Hashtable, Vector ...) and I'm wondering how feasible it would be >>> to replace it completely with java.util.regex. Joe might know if >>> this has ever been discussed upstream (and I appreciate there is a >>> desire to keep the code the same where possible). >> >> We are open to newer features. Xerces still support JDK 1.4, but we >> have moved on and accepted JDK 7 features. We will update and replace >> the old code such as Hashtable, Vector along the way and where >> possible. Note that, I mentioned to the corelib before, that Xalan >> has a strip-down version of Hashtable that actually performs better >> than Hashmap. >> >> As for the Xerces-flavor of regex, it's a XML Schema conformant >> implementation. It supports that defined in the XML Schema >> specification: >> http://www.w3.org/TR/2000/WD-xmlschema-2-20000407/#regexs. It may be >> possible to replace with java.util.regex but not without some sort of >> pattern-translation mechanism. >> >> -Joe >> >>> >>> -Alan >> > From mike.duigou at oracle.com Sat Mar 15 03:45:43 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 14 Mar 2014 20:45:43 -0700 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <5322F2C3.4080603@oracle.com> References: <5321CEE6.403@oracle.com> <123FE971-9F74-43E6-988A-86D9A1804C68@oracle.com> <5321D9B6.2050301@oracle.com> <5321F5E0.7000408@oracle.com> <5321F87B.8010300@oracle.com> <532200FD.9060705@oracle.com> <53220A38.9080508@oracle.com> <53228C03.5070106@oracle.com> <5322AA31.1040703@oracle.com> <5322DFA5.7070704@gmail.com> <5322E5D6.5020403@oracle.com> <5322EFC8.6030604@oracle.com> <5322F2C3.4080603@oracle.com> Message-ID: <6C483030-7C0C-45E9-8588-DDF754AB18AD@oracle.com> On Mar 14 2014, at 05:14 , Ivan Gerasimov wrote: > > On 14.03.2014 16:02, David Holmes wrote: >> Ivan, >> >> On 14/03/2014 9:19 PM, Ivan Gerasimov wrote: >>> Thanks Peter for the comments. >>> >>> On 14.03.2014 14:53, Peter Levart wrote: >>>> On 03/14/2014 08:05 AM, Ivan Gerasimov wrote: >>>>> One thing I noticed is that some methods I mentioned above >>>>> (List.subList(), Arrays.sort(), etc) throw IllegalArgumentException >>>>> when fromIndex > toIndex, not IndexOutOfBoundException. >>>>> Wouldn't it be more correct to adopt this into removeRange() too? >>>> >>>> The question is, what exception should be thrown for removeRange(0, >>>> -1) then... The order of checks matters and should be specified if two >>>> kinds of exceptions are thrown... >>>> >>> >>> In my opinion, the order of the checks should match the order of the >>> listed exceptions in the spec. The @throws tags aren't ordered. The javadoc tool is free to re-order them (such as alphabetization or grouping by super class). Specifying the exception behaviour to this degree seems like vast overspecification. What's the value other than to someone writing a validation test who might have to catch or expect both exceptions? In real user code it doesn't seem important which particular exception is thrown. In either case the fix that must be applied by the programmer is likely the same in either case. Mike From martinrb at google.com Sat Mar 15 13:24:23 2014 From: martinrb at google.com (Martin Buchholz) Date: Sat, 15 Mar 2014 06:24:23 -0700 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <5322EB0F.8010900@cs.oswego.edu> References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> <5322EB0F.8010900@cs.oswego.edu> Message-ID: We understand the intent of removeRange better now. I agree that making further improvements is tricky. I think we can all agree that the initial patch http://cr.openjdk.java.net/~igerasim/8014066/0/webrev/jdk.patch is a clear improvement (simple spec bug fix) fromIndex == size must be OK because it results from a call to clear on an already empty list. Maybe we should check that unambitious fix in first. Changing the spec for removeRange to add more requirements on subclass implementations seems wrong because there are existing implementations and because the (underspecified) contract is that removeRange will only be called from a call to clear, which in turn will ensure that the indices are legal. Adding more bounds checks now will just add overhead without catching user mistakes in practice. Improving the spec to clarify the contract as originally designed by Josh would be good, but it will be hard to find good wording and get approval from all the interested parties. Software is hard. On Fri, Mar 14, 2014 at 4:42 AM, Doug Lea
wrote: > On 03/14/2014 02:38 AM, Martin Buchholz wrote: > >> On Thu, Mar 13, 2014 at 3:59 PM, Doug Lea
> > wrote: >> On 03/13/2014 12:34 PM, Martin Buchholz wrote: >> I notice there are zero jtreg tests for removeRange. That should >> be fixed. >> >> I notice there is a removeRange in CopyOnWriteArrayList, but it is >> package-private instead of "protected", which seems like an >> oversight. >> Can Doug >> remember any history on that? >> >> >> CopyOnWriteArrayList does not extend AbstractList, but its >> sublist does. The sublist relies on COWAL.removeRange only for clear. >> So COWAL sublist clearing uses the same idea as >> AbstractList, and gives it the same name, but it is not the >> same AbstractList method, so need not be protected. >> >> >> Ahh OK, I think the party line for *users* is if they want to remove a >> range of >> elements from a list, use list.subList(fromIndex, toIndex).clear (), so >> there's >> no advantage in making COWAL.removeRange a public interface. >> > > Right. This relates to the question of range checks for removeRange. > Josh Block created removeRange as part of an incompletely documented > recipe for AbstractList-based List implementations. It was intended that > people creating new kinds of Lists implement this as a helper > method to simplify sublist implementations. It is designed > to be called only from other public methods that would either themselves > perform range checks or skip them if statically unnecessary. > So, there aren't any redundant checks in the default removeRange. > Leaving this partially exposed as "protected" doesn't quite > ensure that implementors follow this guidance, but in practice, > I suspect that they all have. So it is not clear whether changing > the spec or the implementation would be doing anyone a favor. > > -Doug > > > > From ivan.gerasimov at oracle.com Sat Mar 15 19:23:34 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sat, 15 Mar 2014 23:23:34 +0400 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> <5322EB0F.8010900@cs.oswego.edu> Message-ID: <5324A8B6.8010009@oracle.com> Thank you Martin! On 15.03.2014 17:24, Martin Buchholz wrote: > We understand the intent of removeRange better now. I agree that making > further improvements is tricky. > > I think we can all agree that the initial patch > http://cr.openjdk.java.net/~igerasim/8014066/0/webrev/jdk.patch > is a clear improvement (simple spec bug fix) > fromIndex == size must be OK because it results from a call to clear on an > already empty list. > Maybe we should check that unambitious fix in first. What about a regtest then? Wouldn't it be good to check at least that removeRange(size(), size()) works, and removeRange(-1,size()) or (0, size()+1) throw the exception? Sincerely yours, Ivan > Changing the spec for removeRange to add more requirements on subclass > implementations seems wrong because there are existing implementations and > because the (underspecified) contract is that removeRange will only be > called from a call to clear, which in turn will ensure that the indices are > legal. Adding more bounds checks now will just add overhead without > catching user mistakes in practice. > > Improving the spec to clarify the contract as originally designed by Josh > would be good, but it will be hard to find good wording and get approval > from all the interested parties. > > Software is hard. > > > On Fri, Mar 14, 2014 at 4:42 AM, Doug Lea
wrote: > >> On 03/14/2014 02:38 AM, Martin Buchholz wrote: >> >>> On Thu, Mar 13, 2014 at 3:59 PM, Doug Lea
>> > wrote: >>> On 03/13/2014 12:34 PM, Martin Buchholz wrote: >>> I notice there are zero jtreg tests for removeRange. That should >>> be fixed. >>> >>> I notice there is a removeRange in CopyOnWriteArrayList, but it is >>> package-private instead of "protected", which seems like an >>> oversight. >>> Can Doug >>> remember any history on that? >>> >>> >>> CopyOnWriteArrayList does not extend AbstractList, but its >>> sublist does. The sublist relies on COWAL.removeRange only for clear. >>> So COWAL sublist clearing uses the same idea as >>> AbstractList, and gives it the same name, but it is not the >>> same AbstractList method, so need not be protected. >>> >>> >>> Ahh OK, I think the party line for *users* is if they want to remove a >>> range of >>> elements from a list, use list.subList(fromIndex, toIndex).clear (), so >>> there's >>> no advantage in making COWAL.removeRange a public interface. >>> >> Right. This relates to the question of range checks for removeRange. >> Josh Block created removeRange as part of an incompletely documented >> recipe for AbstractList-based List implementations. It was intended that >> people creating new kinds of Lists implement this as a helper >> method to simplify sublist implementations. It is designed >> to be called only from other public methods that would either themselves >> perform range checks or skip them if statically unnecessary. >> So, there aren't any redundant checks in the default removeRange. >> Leaving this partially exposed as "protected" doesn't quite >> ensure that implementors follow this guidance, but in practice, >> I suspect that they all have. So it is not clear whether changing >> the spec or the implementation would be doing anyone a favor. >> >> -Doug >> >> >> >> > From martinrb at google.com Sun Mar 16 00:41:16 2014 From: martinrb at google.com (Martin Buchholz) Date: Sat, 15 Mar 2014 17:41:16 -0700 Subject: RFR [6943190] TEST_BUG: java/lang/Runtime/exec/ExecWithInput.java hardcodes path to cat In-Reply-To: <5323352C.4080007@oracle.com> References: <530B80CF.9090403@oracle.com> <530E5D0F.90409@oracle.com> <530E6877.5050504@oracle.com> <530F06A3.1030107@oracle.com> <5323352C.4080007@oracle.com> Message-ID: Thanks for trying to make these tests more robust. 33 private static final String[] paths = {"/bin", "/usr/bin", 34 "/usr/local/bin", "/system/bin", "/sbin", "/usr/bin/sbin", 35 "/usr/local/sbin", "/system/sbin"}; I think in practice { "/bin", "/usr/bin" } would work very well. I would definitely leave out /usr/local, since that is a location for non-standard program variants to be installed. I don't know anything about /system - I would leave it out. Pedants would suggest getting the system default PATH using "getconf PATH", and that might get you /usr/xpg4/bin, but probably overkill here. I wouldn't fall back to looking on PATH. There should be as few dependencies on the user's environment as possible. I would leave out the crufty windows-checking code from each test, and instead write test code like: If (UnixCommands.tee() == null || UnixCommands.cat() == null) return; Imagine these tests will be run on some other strange OS someday. On Fri, Mar 14, 2014 at 9:58 AM, Ivan Gerasimov wrote: > Hello! > > This is a friendly reminder. > Can someone with the Reviewer status please help review this? > > In short: we have a few java tests that run shell commands. > In some tests the path to the command is omitted, in other tests an > absolute path is given. > In the third group of tests, the *other* absolute path to the same > commands is used. > > As Martin suggested, I added searching for the command at certain fixed > directories before using it. > > The final webrev can be found here: > http://cr.openjdk.java.net/~igerasim/6943190/2/webrev/ > > Thanks in advance, > Ivan > > > From martinrb at google.com Sun Mar 16 01:04:45 2014 From: martinrb at google.com (Martin Buchholz) Date: Sat, 15 Mar 2014 18:04:45 -0700 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <5324A8B6.8010009@oracle.com> References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> <5322EB0F.8010900@cs.oswego.edu> <5324A8B6.8010009@oracle.com> Message-ID: Many years ago, I wrote MOAT.java in an attempt to test many implementations with one piece of code. I would modify the list testing part of that file to do something like if (list instanceof AbstractList) { check that removeRange(size(), size()) is a no-op ... maybe check that removeRange with invalid indices does something reasonable. } BUT: removeRange is not really a public API - it's an API for subclassers, and so it is much more reasonable for removeRange to assume that it is being called with valid indices. On Sat, Mar 15, 2014 at 12:23 PM, Ivan Gerasimov wrote: > Thank you Martin! > > > On 15.03.2014 17:24, Martin Buchholz wrote: > >> We understand the intent of removeRange better now. I agree that making >> further improvements is tricky. >> >> I think we can all agree that the initial patch >> http://cr.openjdk.java.net/~igerasim/8014066/0/webrev/jdk.patch >> is a clear improvement (simple spec bug fix) >> fromIndex == size must be OK because it results from a call to clear on >> an >> already empty list. >> Maybe we should check that unambitious fix in first. >> > What about a regtest then? > Wouldn't it be good to check at least that removeRange(size(), size()) > works, and removeRange(-1,size()) or (0, size()+1) throw the exception? > > Sincerely yours, > Ivan > > > Changing the spec for removeRange to add more requirements on subclass >> implementations seems wrong because there are existing implementations and >> because the (underspecified) contract is that removeRange will only be >> called from a call to clear, which in turn will ensure that the indices >> are >> legal. Adding more bounds checks now will just add overhead without >> catching user mistakes in practice. >> >> Improving the spec to clarify the contract as originally designed by Josh >> would be good, but it will be hard to find good wording and get approval >> from all the interested parties. >> >> Software is hard. >> >> >> On Fri, Mar 14, 2014 at 4:42 AM, Doug Lea
wrote: >> >> On 03/14/2014 02:38 AM, Martin Buchholz wrote: >>> >>> On Thu, Mar 13, 2014 at 3:59 PM, Doug Lea
>>> > wrote: >>>> On 03/13/2014 12:34 PM, Martin Buchholz wrote: >>>> I notice there are zero jtreg tests for removeRange. That >>>> should >>>> be fixed. >>>> >>>> I notice there is a removeRange in CopyOnWriteArrayList, but >>>> it is >>>> package-private instead of "protected", which seems like an >>>> oversight. >>>> Can Doug >>>> remember any history on that? >>>> >>>> >>>> CopyOnWriteArrayList does not extend AbstractList, but its >>>> sublist does. The sublist relies on COWAL.removeRange only for >>>> clear. >>>> So COWAL sublist clearing uses the same idea as >>>> AbstractList, and gives it the same name, but it is not the >>>> same AbstractList method, so need not be protected. >>>> >>>> >>>> Ahh OK, I think the party line for *users* is if they want to remove a >>>> range of >>>> elements from a list, use list.subList(fromIndex, toIndex).clear (), so >>>> there's >>>> no advantage in making COWAL.removeRange a public interface. >>>> >>>> Right. This relates to the question of range checks for removeRange. >>> Josh Block created removeRange as part of an incompletely documented >>> recipe for AbstractList-based List implementations. It was intended that >>> people creating new kinds of Lists implement this as a helper >>> method to simplify sublist implementations. It is designed >>> to be called only from other public methods that would either themselves >>> perform range checks or skip them if statically unnecessary. >>> So, there aren't any redundant checks in the default removeRange. >>> Leaving this partially exposed as "protected" doesn't quite >>> ensure that implementors follow this guidance, but in practice, >>> I suspect that they all have. So it is not clear whether changing >>> the spec or the implementation would be doing anyone a favor. >>> >>> -Doug >>> >>> >>> >>> >>> >> > From david.holmes at oracle.com Sun Mar 16 04:46:51 2014 From: david.holmes at oracle.com (David Holmes) Date: Sun, 16 Mar 2014 14:46:51 +1000 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <5322F46F.5050700@cs.oswego.edu> References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> <5322EB0F.8010900@cs.oswego.edu> <5322F113.2070505@oracle.com> <5322F46F.5050700@cs.oswego.edu> Message-ID: <53252CBB.5000803@oracle.com> On 14/03/2014 10:22 PM, Doug Lea wrote: > On 03/14/2014 08:07 AM, David Holmes wrote: > >> So what you are saying is that protected overrides of protected >> methods are not >> required to honor the specification of the super method? > > Not always, but ... > >> >> That certainly gives some implementation flexibility, but I don't >> think I've >> ever seen it expressed as a rule. >> > > ... this is the convention for @implSpecs for default methods on > interfaces. > Which probably would have been used here instead of AbstractList had > they existed back in JDK1.2. However @throws is not part of implSpecs. AbstractList should have defined the potential exceptions and subclass implementations would have to conform. David > -Doug > > From david.holmes at oracle.com Sun Mar 16 04:51:55 2014 From: david.holmes at oracle.com (David Holmes) Date: Sun, 16 Mar 2014 14:51:55 +1000 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> <5322EB0F.8010900@cs.oswego.edu> Message-ID: <53252DEB.6070805@oracle.com> Hi Martin, On 15/03/2014 11:24 PM, Martin Buchholz wrote: > We understand the intent of removeRange better now. I agree that making > further improvements is tricky. Almost impossible I'd say :) > I think we can all agree that the initial patch > http://cr.openjdk.java.net/~igerasim/8014066/0/webrev/jdk.patch > is a clear improvement (simple spec bug fix) > fromIndex == size must be OK because it results from a call to clear on an > already empty list. > Maybe we should check that unambitious fix in first. I agree. Though I'd suggest that in keeping with the "fixing a typo" theme we simply change: * fromIndex >= size() || to * fromIndex > size() || Although this constraint is already implicit in the "in range" requirement, a one character change is much easier to accept as correct. David ----- > Changing the spec for removeRange to add more requirements on subclass > implementations seems wrong because there are existing implementations and > because the (underspecified) contract is that removeRange will only be > called from a call to clear, which in turn will ensure that the indices are > legal. Adding more bounds checks now will just add overhead without > catching user mistakes in practice. > > Improving the spec to clarify the contract as originally designed by Josh > would be good, but it will be hard to find good wording and get approval > from all the interested parties. > > Software is hard. > > > On Fri, Mar 14, 2014 at 4:42 AM, Doug Lea
wrote: > >> On 03/14/2014 02:38 AM, Martin Buchholz wrote: >> >>> On Thu, Mar 13, 2014 at 3:59 PM, Doug Lea
>> > wrote: >>> On 03/13/2014 12:34 PM, Martin Buchholz wrote: >>> I notice there are zero jtreg tests for removeRange. That should >>> be fixed. >>> >>> I notice there is a removeRange in CopyOnWriteArrayList, but it is >>> package-private instead of "protected", which seems like an >>> oversight. >>> Can Doug >>> remember any history on that? >>> >>> >>> CopyOnWriteArrayList does not extend AbstractList, but its >>> sublist does. The sublist relies on COWAL.removeRange only for clear. >>> So COWAL sublist clearing uses the same idea as >>> AbstractList, and gives it the same name, but it is not the >>> same AbstractList method, so need not be protected. >>> >>> >>> Ahh OK, I think the party line for *users* is if they want to remove a >>> range of >>> elements from a list, use list.subList(fromIndex, toIndex).clear (), so >>> there's >>> no advantage in making COWAL.removeRange a public interface. >>> >> >> Right. This relates to the question of range checks for removeRange. >> Josh Block created removeRange as part of an incompletely documented >> recipe for AbstractList-based List implementations. It was intended that >> people creating new kinds of Lists implement this as a helper >> method to simplify sublist implementations. It is designed >> to be called only from other public methods that would either themselves >> perform range checks or skip them if statically unnecessary. >> So, there aren't any redundant checks in the default removeRange. >> Leaving this partially exposed as "protected" doesn't quite >> ensure that implementors follow this guidance, but in practice, >> I suspect that they all have. So it is not clear whether changing >> the spec or the implementation would be doing anyone a favor. >> >> -Doug >> >> >> >> From ivan.gerasimov at oracle.com Sun Mar 16 16:52:54 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sun, 16 Mar 2014 20:52:54 +0400 Subject: RFR [6943190] TEST_BUG: java/lang/Runtime/exec/ExecWithInput.java hardcodes path to cat In-Reply-To: References: <530B80CF.9090403@oracle.com> <530E5D0F.90409@oracle.com> <530E6877.5050504@oracle.com> <530F06A3.1030107@oracle.com> <5323352C.4080007@oracle.com> Message-ID: <5325D6E6.8090208@oracle.com> Thank you Martin, for your comments! On 16.03.2014 4:41, Martin Buchholz wrote: > Thanks for trying to make these tests more robust. > > 33 private static final String[] paths = {"/bin", "/usr/bin", > 34 "/usr/local/bin", "/system/bin", "/sbin", "/usr/bin/sbin", > 35 "/usr/local/sbin", "/system/sbin"}; > > I think in practice { "/bin", "/usr/bin" } would work very well. I > would definitely leave out /usr/local, since that is a location for > non-standard program variants to be installed. I don't know anything > about /system - I would leave it out. Pedants would suggest getting > the system default PATH using "getconf PATH", and that might get you > /usr/xpg4/bin, but probably overkill here. > I agree, and I'll make this search list shorter. > I wouldn't fall back to looking on PATH. There should be as few > dependencies on the user's environment as possible. > I imagine the perfect world with this information provided to the test by the harness tool. These commands are executed from shell scripts too, and I've seen the same problem with hard-coded path. Take https://bugs.openjdk.java.net/browse/JDK-6543375, for example. The fix there was to remove the absolute path and rely on the PATH variable. > I would leave out the crufty windows-checking code from each test, and > instead write test code like: > > If (UnixCommands.tee() == null || UnixCommands.cat() == null) > return; > Done. I kept the check for specific OS, where it is required by the test itself. Would you please take a look at the updated webrev with your suggestions incorporated: http://cr.openjdk.java.net/~igerasim/6943190/3/webrev/ Sincerely yours, Ivan > Imagine these tests will be run on some other strange OS someday. > > > > On Fri, Mar 14, 2014 at 9:58 AM, Ivan Gerasimov > > wrote: > > Hello! > > This is a friendly reminder. > Can someone with the Reviewer status please help review this? > > In short: we have a few java tests that run shell commands. > In some tests the path to the command is omitted, in other tests > an absolute path is given. > In the third group of tests, the *other* absolute path to the same > commands is used. > > As Martin suggested, I added searching for the command at certain > fixed directories before using it. > > The final webrev can be found here: > http://cr.openjdk.java.net/~igerasim/6943190/2/webrev/ > > > Thanks in advance, > Ivan > > > From ivan.gerasimov at oracle.com Sun Mar 16 22:37:41 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 17 Mar 2014 02:37:41 +0400 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> <5322EB0F.8010900@cs.oswego.edu> <5324A8B6.8010009@oracle.com> Message-ID: <532627B5.8020507@oracle.com> Here is yet another iteration of the fix: http://cr.openjdk.java.net/~igerasim/8014066/3/webrev/ 1) The condition 'fromIndex >= size()' is removed from the spec. I prefer removing it rather than replacing it with 'fromIndex > size()' for two reasons: - 'fromIndex > size()' already follows on from two other conditions (toIndex > size() || toIndex < fromIndex); - it is consistent with the spec for CopyOnWriteArrayList#removeRange(). 2) Kept the check for 'fromIndex > toIndex' in removeRange(). While I understand that this should not add anything significant to the current code, as currently removeRange() is always called with valid arguments. However, if it is stated in the spec that in case of 'fromIndex > toIndex' an exception is thrown, I believe it should be thrown, otherwise why it's stated? 3) Moved the test to MOAT.java The test looks a bit foreign over there, but reuses some of the infrastructure. Sincerely yours, Ivan From Ulf.Zibis at CoSoCo.de Sun Mar 16 22:52:32 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sun, 16 Mar 2014 23:52:32 +0100 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <532627B5.8020507@oracle.com> References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> <5322EB0F.8010900@cs.oswego.edu> <5324A8B6.8010009@oracle.com> <532627B5.8020507@oracle.com> Message-ID: <53262B30.4060309@CoSoCo.de> Am 16.03.2014 23:37, schrieb Ivan Gerasimov: > Here is yet another iteration of the fix: > http://cr.openjdk.java.net/~igerasim/8014066/3/webrev/ > > 2) > Kept the check for 'fromIndex > toIndex' in removeRange(). > While I understand that this should not add anything significant to the current code, as currently > removeRange() is always called with valid arguments. > However, if it is stated in the spec that in case of 'fromIndex > toIndex' an exception is thrown, > I believe it should be thrown, otherwise why it's stated? Isn't this a perfect situation to use an assert statement? Needless to say, then the spec must be adapted. -Ulf From ivan.gerasimov at oracle.com Mon Mar 17 06:03:37 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 17 Mar 2014 10:03:37 +0400 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <53262B30.4060309@CoSoCo.de> References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> <5322EB0F.8010900@cs.oswego.edu> <5324A8B6.8010009@oracle.com> <532627B5.8020507@oracle.com> <53262B30.4060309@CoSoCo.de> Message-ID: <53269039.90503@oracle.com> On 17.03.2014 2:52, Ulf Zibis wrote: > Am 16.03.2014 23:37, schrieb Ivan Gerasimov: >> Here is yet another iteration of the fix: >> http://cr.openjdk.java.net/~igerasim/8014066/3/webrev/ >> >> 2) >> Kept the check for 'fromIndex > toIndex' in removeRange(). >> While I understand that this should not add anything significant to >> the current code, as currently removeRange() is always called with >> valid arguments. >> However, if it is stated in the spec that in case of 'fromIndex > >> toIndex' an exception is thrown, I believe it should be thrown, >> otherwise why it's stated? > > Isn't this a perfect situation to use an assert statement? Needless to > say, then the spec must be adapted. > Yeah, it might be more fair to write that it's assumed that the passed arguments are valid and use asserts as you suggest. Though I think that the current trend is to do as little modifications as possible. Sincerely yours, Ivan > -Ulf > > > From Alan.Bateman at oracle.com Mon Mar 17 07:50:57 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 17 Mar 2014 07:50:57 +0000 Subject: RFR [6943190] TEST_BUG: java/lang/Runtime/exec/ExecWithInput.java hardcodes path to cat In-Reply-To: <5325D6E6.8090208@oracle.com> References: <530B80CF.9090403@oracle.com> <530E5D0F.90409@oracle.com> <530E6877.5050504@oracle.com> <530F06A3.1030107@oracle.com> <5323352C.4080007@oracle.com> <5325D6E6.8090208@oracle.com> Message-ID: <5326A961.5030803@oracle.com> On 16/03/2014 16:52, Ivan Gerasimov wrote: > > Would you please take a look at the updated webrev with your > suggestions incorporated: > http://cr.openjdk.java.net/~igerasim/6943190/3/webrev/ Ivan - I see that a number of the tests have been changed to /othervm and I'm wondering what the reason for this is. Clearly tests for Process will be launching new VMs but it would be great if we could avoid having to launch a VM for the test "main" too. Another general comment is that if a command is not found the tests will now pass and the only way to know that anything has gone wrong is to look in the .jtr file. I would personally prefer the tests to fail so that any issues in the environment or special-casing for new ports can be found quickly. For the Linux or Solaris-only tests then the tests now output an information message via System.err, I assume this should be System.out as it's not really an error or usage message. On the places to search then I'm wondering about /system/bin. Is that needed? I assume that if there is a port to an operating system that uses this location then it will be added as part of the port. -Alan. From ivan.gerasimov at oracle.com Mon Mar 17 09:06:53 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 17 Mar 2014 13:06:53 +0400 Subject: RFR [6943190] TEST_BUG: java/lang/Runtime/exec/ExecWithInput.java hardcodes path to cat In-Reply-To: <5326A961.5030803@oracle.com> References: <530B80CF.9090403@oracle.com> <530E5D0F.90409@oracle.com> <530E6877.5050504@oracle.com> <530F06A3.1030107@oracle.com> <5323352C.4080007@oracle.com> <5325D6E6.8090208@oracle.com> <5326A961.5030803@oracle.com> Message-ID: <5326BB2D.6060201@oracle.com> Thank you Alan! On 17.03.2014 11:50, Alan Bateman wrote: > On 16/03/2014 16:52, Ivan Gerasimov wrote: >> >> Would you please take a look at the updated webrev with your >> suggestions incorporated: >> http://cr.openjdk.java.net/~igerasim/6943190/3/webrev/ > > Ivan - I see that a number of the tests have been changed to /othervm > and I'm wondering what the reason for this is. Clearly tests for > Process will be launching new VMs but it would be great if we could > avoid having to launch a VM for the test "main" too. > These two tests used the commands run from non very common location (/usr/bin/ instead of /bin/), so I suspect they have been rarely run. As it follows from the summaries, one of them ensures the VM doesn't crash; the other checks, whether the input/output streams are left open. Both tests in the case of a failure could interfere with other tests unless they run in the othervm mode. That's why I thought it's better to add the flag. > Another general comment is that if a command is not found the tests > will now pass and the only way to know that anything has gone wrong is > to look in the .jtr file. I would personally prefer the tests to fail > so that any issues in the environment or special-casing for new ports > can be found quickly. > I've tried not to change the tests' logic too much. For example, in test/java/lang/Runtime/exec/ConcurrentRead.java, if 'tee' hadn't been found, the test just silently exited. And I only added some debug output about that fact. Otherwise, if we treat the 'tee' absence as an error, we may start seeing failures in different environments, which would not be related to ConcurrentRead.java itself. IMO ideally, there should be a configurable part of the harness, where all the shell commands are set up. So that they could be accessed by both Java and shell-based regtests. > For the Linux or Solaris-only tests then the tests now output an > information message via System.err, I assume this should be System.out > as it's not really an error or usage message. > Fixed it. > On the places to search then I'm wondering about /system/bin. Is that > needed? I assume that if there is a port to an operating system that > uses this location then it will be added as part of the port. > > -Alan. > Sincerely yours, Ivan From volker.simonis at gmail.com Mon Mar 17 10:48:08 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 17 Mar 2014 11:48:08 +0100 Subject: RFR[9](XXS): 8037013: [TESTBUG] Fix test/java/lang/ClassLoader/Assert.sh on AIX In-Reply-To: References: <531E0A9E.50908@oracle.com> <531E6E07.2000806@oracle.com> Message-ID: Hi Mandy, sorry for the delay. You are right, the shell script isn't needed. I updated the change as suggested by you in the mail you referenced. Here's the new webrev (tested on Linux/AIX/Solaris): http://cr.openjdk.java.net/~simonis/webrevs/8037013_2/webrev/ OK, to push now? Thank you and best regards, Volker On Tue, Mar 11, 2014 at 6:56 PM, Volker Simonis wrote: > Hi Mandy, > > thanks for the review. > > I'll look into the possibility of removing Assert.sh altogether and > post a new webrev soon. > > Regards, > Volker > > > On Tue, Mar 11, 2014 at 2:59 AM, Mandy Chung wrote: >> >> On 3/10/2014 11:55 AM, Mandy Chung wrote: >>> >>> Hi Volker, >>> >>> On 3/10/14 11:16 AM, Volker Simonis wrote: >>>> >>>> Hi, >>>> >>>> could you please review the following trivial change which adds AIX to >>>> the list of known OSs in test/java/lang/ClassLoader/Assert.sh: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8037013 >>>> http://cr.openjdk.java.net/~simonis/webrevs/8037013/ >>>> >>> >>> The link to your webrev is not accessible and could possibly due to the >>> server issue. I guess your fix is to add AIX in the Assert.sh test. Can >>> you paste the diff in mail? I can review it. >>> >> >> I am able to access the webrev now - looks good. >> >> >>> I raised in the code review of 7152892 [1] that I believe this test >>> doesn't need to be a shell test. I don't know if Rob has started looking >>> into it (he missed my review comment when he pushed the fix). I wonder if >>> you would like to take the opportunity to investigate if Assert.sh can be >>> removed? >>> >> >> It'd be even better if we could get rid of Assert.sh. >> >> thanks >> Mandy >> >>> Mandy >>> [1] >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/024995.html >> >> From scolebourne at joda.org Mon Mar 17 11:17:44 2014 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 17 Mar 2014 11:17:44 +0000 Subject: RFR: JDK-8036818: DateTimeFormatter withResolverFields() fails to accept null In-Reply-To: <53206EE5.1080605@oracle.com> References: <53206725.6040901@oracle.com> <53206EE5.1080605@oracle.com> Message-ID: To confirm, this counts as a review "yes"? Stephen On 12 March 2014 14:27, Chris Hegarty wrote: > The change look ok to me too. > > There is a change in behavior here, but I don't expect it to be surprising ( > no NPE where there once was ), so I think it should be fine for 8u-dev also. > > The TCK test changes however, may not be suitable for 8u. Though I'm not > sure how these tests feed from the OpenJDK repo into the actual TCK. > > -Chris. > > On 12/03/14 13:54, roger riggs wrote: >> >> Looks fine, (not a reviewer). >> >> I can sponsor the fix when reviewed. >> >> Thanks, Roger >> >> >> On 3/12/2014 6:45 AM, Stephen Colebourne wrote: >>> >>> This is a request for review of this bug: >>> https://bugs.openjdk.java.net/browse/JDK-8036818 >>> >>> The method DateTimeFormatter withResolverFields() is supposed to >>> accept null. This is to allow a coy of the formatter to be returned >>> reset to the original state of having no resolver fields. The docs >>> say: >>> "@param resolverFields the new set of resolver fields, null if no fields" >>> which was written to indicate that resetting to null is permitted. >>> >>> The fix is to check for null and return a copy of the formatter. Note >>> that there are two variations of the method which need fixing. >>> >>> Proposed patch: >>> https://gist.github.com/jodastephen/9395197 >>> The patch includes no spec changes. >>> The patch fixes the broken TCK tests. >>> >>> I need a reviewer and a committer please. >>> thanks >>> Stephen >> >> > From scolebourne at joda.org Mon Mar 17 11:18:19 2014 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 17 Mar 2014 11:18:19 +0000 Subject: RFR: JDK-8035099 LocalTime with(MILLI_OF_DAY/MICRO_OF_DAY) incorrect In-Reply-To: References: Message-ID: ping On 12 March 2014 10:48, Stephen Colebourne wrote: > This is a request for review of this bug: > https://bugs.openjdk.java.net/browse/JDK-8035099 > > The implementation for LocalTime with(MILLI_OF_DAY, n) and LocalTime > with(MICRO_OF_DAY, n) fails to match the specification. > > LocalTime base = LocalTime.of(12, 30, 40, 987654321); > > LocalTime result = base.with(MILLI_OF_DAY, 0); > expected: 00:00:00.000000000 > was: 00:00:00.000654321 > > LocalTime result = base.with(MICRO_OF_DAY, 0); > expected: 00:00:00.000000000 > was: 00:00:00.000000321 > > The spec is clear in both cases - "This completely replaces the time > and is equivalent to using {@link #ofNanoOfDay(long)}", thus this is > clearly a bug. > > > Proposed patch: > https://gist.github.com/jodastephen/9057131 > The patch includes no spec changes. > The patch includes new TCK tests that are derived explicitly from the spec. > > I need a reviewer and a committer please. > thanks > Stephen From scolebourne at joda.org Mon Mar 17 11:18:34 2014 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 17 Mar 2014 11:18:34 +0000 Subject: RFR: JDK-8036785 ChronoLocalDate refers to generics that have been removed In-Reply-To: References: Message-ID: ping On 12 March 2014 10:52, Stephen Colebourne wrote: > This is a request for review of this bug: > https://bugs.openjdk.java.net/browse/JDK-8036785 > > During development, ChronoLocalDate had a generic type parameter. It > was removed during the development of JSR-310. The Javadoc was not > updated to reflect the removal. > > The necessary change is to text that is essentially non-normative, and > as such this change should be non-controversial. > > > Proposed patch: > https://gist.github.com/jodastephen/9395412 > The patch includes non-normative spec changes. > The patch includes no code changes. > > I need a reviewer and a committer please. > thanks > Stephen From scolebourne at joda.org Mon Mar 17 11:18:45 2014 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 17 Mar 2014 11:18:45 +0000 Subject: RFR: JDK-8033662 DateTimeFormatter parsing ignores withZone() In-Reply-To: References: Message-ID: ping On 12 March 2014 12:29, Stephen Colebourne wrote: > This is a request for review of this bug: > https://bugs.openjdk.java.net/browse/JDK-8033662 > and the duplicate: > https://bugs.openjdk.java.net/browse/JDK-8033659 > > The javadoc of the method java.time.format.DateTimeFormatter::withZone says: > "If no zone has been parsed, then this override zone will be included > in the result of the parse where it can be used to build instants and > date-times." > However, the implementation doesn't obey this. > > This is a very unfortunate bug that makes some date-time parsing a lot harder. > > A second related bug in an egde case - not properly handling a > ChronoZonedDateTime from TemporalField.resolve - is also tested for > and fixed. > > > Proposed patch: > https://gist.github.com/jodastephen/9505761 > The patch includes no spec changes. > The patch includes new and refactored TCK tests. The new tests for > withZone() and withChronology() are based on the spec. > > I need a reviewer and a committer please. > thanks From roger.riggs at oracle.com Mon Mar 17 13:51:38 2014 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 17 Mar 2014 09:51:38 -0400 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <532627B5.8020507@oracle.com> References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> <5322EB0F.8010900@cs.oswego.edu> <5324A8B6.8010009@oracle.com> <532627B5.8020507@oracle.com> Message-ID: <5326FDEA.9060707@oracle.com> Hi Ivan, Just to see the effect of the change, I ran the test without the code change and it reported 331 failures and only 1 IndexOutOfBoundsException not thrown and that was in java.util.Collections$SingletonMap. (I can't appreciate the error reporting style with just a stack trace; especially given the generated cases in nested loops). I would have expected to see failures reporting the incorrect exception being thrown for ArrayList itself. Though most are likely due to the same condition outside the range, its hard to tell if there are other failures. Can you check that the test is detecting and reporting the right errors for the current implementation. Thanks, Roger On 3/16/2014 6:37 PM, Ivan Gerasimov wrote: > Here is yet another iteration of the fix: > http://cr.openjdk.java.net/~igerasim/8014066/3/webrev/ > > 1) > The condition 'fromIndex >= size()' is removed from the spec. > I prefer removing it rather than replacing it with 'fromIndex > > size()' for two reasons: > - 'fromIndex > size()' already follows on from two other conditions > (toIndex > size() || toIndex < fromIndex); > - it is consistent with the spec for CopyOnWriteArrayList#removeRange(). > > 2) > Kept the check for 'fromIndex > toIndex' in removeRange(). > While I understand that this should not add anything significant to > the current code, as currently removeRange() is always called with > valid arguments. > However, if it is stated in the spec that in case of 'fromIndex > > toIndex' an exception is thrown, I believe it should be thrown, > otherwise why it's stated? > > 3) > Moved the test to MOAT.java > The test looks a bit foreign over there, but reuses some of the > infrastructure. > > Sincerely yours, > Ivan > From chris.hegarty at oracle.com Mon Mar 17 13:58:09 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 17 Mar 2014 13:58:09 +0000 Subject: RFR: JDK-8036818: DateTimeFormatter withResolverFields() fails to accept null In-Reply-To: References: <53206725.6040901@oracle.com> <53206EE5.1080605@oracle.com> Message-ID: <1D30060C-0582-4F67-B891-ADDC193F58D2@oracle.com> > On 17 Mar 2014, at 11:17, Stephen Colebourne wrote: > > To confirm, this counts as a review "yes"? Yes. Sorry if this wasn't clear. -Chris. > Stephen > > >> On 12 March 2014 14:27, Chris Hegarty wrote: >> The change look ok to me too. >> >> There is a change in behavior here, but I don't expect it to be surprising ( >> no NPE where there once was ), so I think it should be fine for 8u-dev also. >> >> The TCK test changes however, may not be suitable for 8u. Though I'm not >> sure how these tests feed from the OpenJDK repo into the actual TCK. >> >> -Chris. >> >>> On 12/03/14 13:54, roger riggs wrote: >>> >>> Looks fine, (not a reviewer). >>> >>> I can sponsor the fix when reviewed. >>> >>> Thanks, Roger >>> >>> >>>> On 3/12/2014 6:45 AM, Stephen Colebourne wrote: >>>> >>>> This is a request for review of this bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8036818 >>>> >>>> The method DateTimeFormatter withResolverFields() is supposed to >>>> accept null. This is to allow a coy of the formatter to be returned >>>> reset to the original state of having no resolver fields. The docs >>>> say: >>>> "@param resolverFields the new set of resolver fields, null if no fields" >>>> which was written to indicate that resetting to null is permitted. >>>> >>>> The fix is to check for null and return a copy of the formatter. Note >>>> that there are two variations of the method which need fixing. >>>> >>>> Proposed patch: >>>> https://gist.github.com/jodastephen/9395197 >>>> The patch includes no spec changes. >>>> The patch fixes the broken TCK tests. >>>> >>>> I need a reviewer and a committer please. >>>> thanks >>>> Stephen >> From roger.riggs at oracle.com Mon Mar 17 14:51:30 2014 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 17 Mar 2014 10:51:30 -0400 Subject: RFR: JDK-8035099 LocalTime with(MILLI_OF_DAY/MICRO_OF_DAY) incorrect In-Reply-To: References: Message-ID: <53270BF2.7070304@oracle.com> Hi, This looks fine (not a Reviewer). I'm checking on how to handle the change in TCK tests. The same question (and answer) applies to JDK-8036818: DateTimeFormatter withResolverFields() fails to accept null Roger On 3/12/2014 6:48 AM, Stephen Colebourne wrote: > This is a request for review of this bug: > https://bugs.openjdk.java.net/browse/JDK-8035099 > > The implementation for LocalTime with(MILLI_OF_DAY, n) and LocalTime > with(MICRO_OF_DAY, n) fails to match the specification. > > LocalTime base = LocalTime.of(12, 30, 40, 987654321); > > LocalTime result = base.with(MILLI_OF_DAY, 0); > expected: 00:00:00.000000000 > was: 00:00:00.000654321 > > LocalTime result = base.with(MICRO_OF_DAY, 0); > expected: 00:00:00.000000000 > was: 00:00:00.000000321 > > The spec is clear in both cases - "This completely replaces the time > and is equivalent to using {@link #ofNanoOfDay(long)}", thus this is > clearly a bug. > > > Proposed patch: > https://gist.github.com/jodastephen/9057131 > The patch includes no spec changes. > The patch includes new TCK tests that are derived explicitly from the spec. > > I need a reviewer and a committer please. > thanks > Stephen From Sergey.Bylokhov at oracle.com Mon Mar 17 15:01:57 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 17 Mar 2014 19:01:57 +0400 Subject: [9] Review request: new macro for conversion to jboolean Message-ID: <53270E65.4070001@oracle.com> Hello. This review request is for the new macro, which simplify conversion to jboolean. It will be useful for fixing parfait warnings. We have a lot of places, where we cast some type to jboolean: BOOL = retVal; return (jboolean) retVal; WARNING: Expecting value of JNI primitive type jboolean: mismatched value retVal with size 32 bits, retVal used for conversion to int8 in return +++ b/src/share/native/common/jni_util.h Mon Mar 17 18:28:48 2014 +0400 @@ -277,6 +277,7 @@ #define IS_NULL(obj) ((obj) == NULL) #define JNU_IsNull(env,obj) ((obj) == NULL) +#define IS_TRUE(obj) ((obj) ? JNI_TRUE : JNI_FALSE) I am not sure about the name, probably someone have a better suggestion? The fix is for jdk9/dev. -- Best regards, Sergey. From roger.riggs at oracle.com Mon Mar 17 15:04:38 2014 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 17 Mar 2014 11:04:38 -0400 Subject: RFR: JDK-8036785 ChronoLocalDate refers to generics that have been removed In-Reply-To: References: Message-ID: <53270F06.50206@oracle.com> Looks fine. (not a Reviewer) On 3/12/2014 6:52 AM, Stephen Colebourne wrote: > This is a request for review of this bug: > https://bugs.openjdk.java.net/browse/JDK-8036785 > > During development, ChronoLocalDate had a generic type parameter. It > was removed during the development of JSR-310. The Javadoc was not > updated to reflect the removal. > > The necessary change is to text that is essentially non-normative, and > as such this change should be non-controversial. > > > Proposed patch: > https://gist.github.com/jodastephen/9395412 > The patch includes non-normative spec changes. > The patch includes no code changes. > > I need a reviewer and a committer please. > thanks > Stephen From paul.sandoz at oracle.com Mon Mar 17 15:41:45 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 17 Mar 2014 16:41:45 +0100 Subject: RFR 8037106: Optimize Arrays.asList(...).forEach In-Reply-To: <53238E16.9060307@CoSoCo.de> References: <80B43E05-0AB3-43B7-B4F3-26FBCCD67E6E@oracle.com> <0A4CACFA-02EF-4EF3-99EF-A7D1455E272A@oracle.com> <53238E16.9060307@CoSoCo.de> Message-ID: <59A82D78-969A-42B3-8CE3-BABC0353A208@oracle.com> On Mar 15, 2014, at 12:17 AM, Ulf Zibis wrote: > Am 14.03.2014 17:10, schrieb Paul Sandoz: >>> I'm willing to believe for-loop over array is as efficient as fortran-style loop >>> >>> + for (E e : a) { >>> + action.accept(e); >>> + } >>> >> Yeah, i previously went through a whole bunch of code replacing such fortran-style loops with 'foreach' style based on automated code analysis. > > But wouldn't this help a little more? : > + final E[] a = this.a; > + for (E e : a) { > + action.accept(e); > + } > Thanks, i changed it to that. > > I more like the given style with less spaces: > 3854 for (int i=0; i It better visualizes the 3 parts of the for statement. > Subjectively that irritates my eyes :-) non-subjectively it is inconsistently applied. Paul. From Sergey.Bylokhov at oracle.com Mon Mar 17 16:07:31 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 17 Mar 2014 20:07:31 +0400 Subject: RFR 8037106: Optimize Arrays.asList(...).forEach In-Reply-To: <59A82D78-969A-42B3-8CE3-BABC0353A208@oracle.com> References: <80B43E05-0AB3-43B7-B4F3-26FBCCD67E6E@oracle.com> <0A4CACFA-02EF-4EF3-99EF-A7D1455E272A@oracle.com> <53238E16.9060307@CoSoCo.de> <59A82D78-969A-42B3-8CE3-BABC0353A208@oracle.com> Message-ID: <53271DC3.4020606@oracle.com> On 3/17/14 7:41 PM, Paul Sandoz wrote: > On Mar 15, 2014, at 12:17 AM, Ulf Zibis wrote: > >> Am 14.03.2014 17:10, schrieb Paul Sandoz: >>>> I'm willing to believe for-loop over array is as efficient as fortran-style loop >>>> >>>> + for (E e : a) { >>>> + action.accept(e); >>>> + } >>>> >>> Yeah, i previously went through a whole bunch of code replacing such fortran-style loops with 'foreach' style based on automated code analysis. >> But wouldn't this help a little more? : >> + final E[] a = this.a; >> + for (E e : a) { >> + action.accept(e); >> + } >> > Thanks, i changed it to that. ? Why this line is needed: final E[] a = this.a; Since according to specification foreach over array should be transformed to: JLS 14.14.2: *T[] #a = Expression; * L1: L2: ... Lm: for (int #i = 0; #i < #a.length; #i++) { VariableModifiersopt TargetType Identifier = #a[#i]; Statement } So your code will be transformed to: + final E[] a = this.a; + E[] #a = a; + for (E e : #a) { + action.accept(e); + } Or I miss something? >> I more like the given style with less spaces: >> 3854 for (int i=0; i> It better visualizes the 3 parts of the for statement. >> > Subjectively that irritates my eyes :-) non-subjectively it is inconsistently applied. > > Paul. -- Best regards, Sergey. From mark.reinhold at oracle.com Mon Mar 17 16:08:02 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 17 Mar 2014 09:08:02 -0700 Subject: RFR 8037106: Optimize Arrays.asList(...).forEach In-Reply-To: <59A82D78-969A-42B3-8CE3-BABC0353A208@oracle.com> References: <80B43E05-0AB3-43B7-B4F3-26FBCCD67E6E@oracle.com>, , <0A4CACFA-02EF-4EF3-99EF-A7D1455E272A@oracle.com>, <53238E16.9060307@CoSoCo.de>, <59A82D78-969A-42B3-8CE3-BABC0353A208@oracle.com> Message-ID: <20140317090802.722581@eggemoggin.niobe.net> 2014/3/17 1:41 -0700, paul.sandoz at oracle.com: > On Mar 15, 2014, at 12:17 AM, Ulf Zibis wrote: >> ... >> >> I more like the given style with less spaces: >> 3854 for (int i=0; i> It better visualizes the 3 parts of the for statement. >> > > Subjectively that irritates my eyes :-) non-subjectively it is > inconsistently applied. It's also, well, just plain wrong. - Mark From daniel.fuchs at oracle.com Mon Mar 17 16:28:01 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 17 Mar 2014 17:28:01 +0100 Subject: Javadoc in 9 seems to treat all interfaces with only one method as functional interfaces Message-ID: <53272291.7030501@oracle.com> Hi guys, While playing with JDK 9 javadoc command I noticed that it seems to treat all single method interfaces as if they were functional interfaces - even though they don't have the @FunctionalInterface annotation. For instance - I did 'make docs' - and I'm seeing this text in the javadoc for 'java.awt.event.ActionListener': >> Functional Interface: This is a functional interface and can therefore be used as the assignment target for a lambda expression or method reference. << Is that a known issue, or a new regression, or did I miss something? best regards, -- daniel From paul.sandoz at oracle.com Mon Mar 17 16:36:25 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 17 Mar 2014 17:36:25 +0100 Subject: RFR 8037106: Optimize Arrays.asList(...).forEach In-Reply-To: <53271DC3.4020606@oracle.com> References: <80B43E05-0AB3-43B7-B4F3-26FBCCD67E6E@oracle.com> <0A4CACFA-02EF-4EF3-99EF-A7D1455E272A@oracle.com> <53238E16.9060307@CoSoCo.de> <59A82D78-969A-42B3-8CE3-BABC0353A208@oracle.com> <53271DC3.4020606@oracle.com> Message-ID: Hi Sergey, Thanks, you are right! I did not realize it copied the array into a local variable, but that makes sense. Here is the byte code generated by javac (9) for two different methods: void x() { for (Object o : a) { System.out.println(o); } } 0: aload_0 1: getfield #2 // Field a:[Ljava/lang/Object; 4: astore_1 5: aload_1 6: arraylength 7: istore_2 8: iconst_0 9: istore_3 10: iload_3 11: iload_2 12: if_icmpge 34 15: aload_1 16: iload_3 17: aaload 18: astore 4 20: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream; 23: aload 4 25: invokevirtual #4 // Method java/io/PrintStream.println:(Ljava/lang/Object;)V 28: iinc 3, 1 31: goto 10 34: return void y() { Object[] a = this.a; for (Object o : a) { System.out.println(o); } } 0: aload_0 1: getfield #2 // Field a:[Ljava/lang/Object; 4: astore_1 5: aload_1 6: astore_2 7: aload_2 8: arraylength 9: istore_3 10: iconst_0 11: istore 4 13: iload 4 15: iload_3 16: if_icmpge 39 19: aload_2 20: iload 4 22: aaload 23: astore 5 25: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream; 28: aload 5 30: invokevirtual #4 // Method java/io/PrintStream.println:(Ljava/lang/Object;)V 33: iinc 4, 1 36: goto 13 39: return Paul. On Mar 17, 2014, at 5:07 PM, Sergey Bylokhov wrote: > On 3/17/14 7:41 PM, Paul Sandoz wrote: >> On Mar 15, 2014, at 12:17 AM, Ulf Zibis wrote: >> >>> Am 14.03.2014 17:10, schrieb Paul Sandoz: >>>>> I'm willing to believe for-loop over array is as efficient as fortran-style loop >>>>> >>>>> + for (E e : a) { >>>>> + action.accept(e); >>>>> + } >>>>> >>>> Yeah, i previously went through a whole bunch of code replacing such fortran-style loops with 'foreach' style based on automated code analysis. >>> But wouldn't this help a little more? : >>> + final E[] a = this.a; >>> + for (E e : a) { >>> + action.accept(e); >>> + } >>> >> Thanks, i changed it to that. > ? Why this line is needed: > final E[] a = this.a; > Since according to specification foreach over array should be transformed to: > JLS 14.14.2: > T[] #a = Expression; > L1: L2: ... Lm: > for (int #i = 0; #i < #a.length; #i++) { > VariableModifiersopt TargetType Identifier = #a[#i]; > Statement > } > > So your code will be transformed to: > + final E[] a = this.a; > + E[] #a = a; > + for (E e : #a) { > + action.accept(e); > + } > Or I miss something? >>> I more like the given style with less spaces: >>> 3854 for (int i=0; i>> It better visualizes the 3 parts of the for statement. >>> >> Subjectively that irritates my eyes :-) non-subjectively it is inconsistently applied. >> >> Paul. > > > -- > Best regards, Sergey. From kumar.x.srinivasan at oracle.com Mon Mar 17 17:21:56 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 17 Mar 2014 10:21:56 -0700 Subject: RFR: 8037529: [asm] add back @Suppress tags, removed by last bulk refresh Message-ID: <53272F34.1080104@oracle.com> Hello, Please review fix for adding back @SuppressWarnings tag http://cr.openjdk.java.net/~ksrini/8037529/webrev.0/ removed inadvertently with the push for http://cr.openjdk.java.net/~ksrini/8037221/ Remi, can you please facilitate getting this fix back into the ASM source base ? this will make our lives easier, and of course ASM will compiler cleaner, alternately ASM could use serialVersionUID for these classes. Thanks Kumar From martinrb at google.com Mon Mar 17 17:53:33 2014 From: martinrb at google.com (Martin Buchholz) Date: Mon, 17 Mar 2014 10:53:33 -0700 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <532627B5.8020507@oracle.com> References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> <5322EB0F.8010900@cs.oswego.edu> <5324A8B6.8010009@oracle.com> <532627B5.8020507@oracle.com> Message-ID: On Sun, Mar 16, 2014 at 3:37 PM, Ivan Gerasimov wrote: > Here is yet another iteration of the fix: > http://cr.openjdk.java.net/~igerasim/8014066/3/webrev/ > > 1) > The condition 'fromIndex >= size()' is removed from the spec. > I prefer removing it rather than replacing it with 'fromIndex > size()' > for two reasons: > - 'fromIndex > size()' already follows on from two other conditions > (toIndex > size() || toIndex < fromIndex); > - it is consistent with the spec for CopyOnWriteArrayList#removeRange(). > > Here I'll agree with Ivan and disagree with David. > 2) > Kept the check for 'fromIndex > toIndex' in removeRange(). > While I understand that this should not add anything significant to the > current code, as currently removeRange() is always called with valid > arguments. > However, if it is stated in the spec that in case of 'fromIndex > toIndex' > an exception is thrown, I believe it should be thrown, otherwise why it's > stated? > > It's a good point. ArrayList is performance critical, but removeRange of course far less so. Nevertheless, when adding range checking code like this, create a helper method to create the exception message as is already done in ArrayList: /** * Constructs an IndexOutOfBoundsException detail message. * Of the many possible refactorings of the error handling code, * this "outlining" performs best with both server and client VMs. */ private String outOfBoundsMsg(int index) { return "Index: "+index+", Size: "+size; } > 3) > Moved the test to MOAT.java > The test looks a bit foreign over there, but reuses some of the > infrastructure. > The idea of MOAT is to do NxM testing (many implementations, many assertions). When testing only one implementation, don't put it in MOAT. Today a test like MOAT is looking quite dated. Today we would make use of lambda and testng instead of my old homebrew infrastructure. Here's some test code for you to add to MOAT (please incorporate): diff --git a/test/java/util/Collection/MOAT.java b/test/java/util/Collection/MOAT.java --- a/test/java/util/Collection/MOAT.java +++ b/test/java/util/Collection/MOAT.java @@ -54,6 +54,7 @@ import java.util.*; import java.util.concurrent.*; import static java.util.Collections.*; +import java.lang.reflect.*; public class MOAT { public static void realMain(String[] args) { @@ -721,6 +722,28 @@ equal(l instanceof RandomAccess, l.subList(0,0) instanceof RandomAccess); + + l.iterator(); + l.listIterator(); + l.listIterator(0); + l.listIterator(l.size()); + THROWS(IndexOutOfBoundsException.class, + new Fun(){void f(){l.listIterator(-1);}}, + new Fun(){void f(){l.listIterator(l.size() + 1);}}); + + if (l instanceof AbstractList) { + try { + int size = l.size(); + AbstractList abList = (AbstractList) l; + Method m = AbstractList.class.getDeclaredMethod("removeRange", new Class[] { int.class, int.class }); + m.setAccessible(true); + m.invoke(abList, new Object[] { 0, 0 }); + m.invoke(abList, new Object[] { size, size }); + equal(size, l.size()); + } + catch (UnsupportedOperationException ignored) {/* OK */} + catch (Throwable t) { unexpected(t); } + } } private static void testCollection(Collection c) { From martinrb at google.com Mon Mar 17 17:57:57 2014 From: martinrb at google.com (Martin Buchholz) Date: Mon, 17 Mar 2014 10:57:57 -0700 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <5326FDEA.9060707@oracle.com> References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> <5322EB0F.8010900@cs.oswego.edu> <5324A8B6.8010009@oracle.com> <532627B5.8020507@oracle.com> <5326FDEA.9060707@oracle.com> Message-ID: On Mon, Mar 17, 2014 at 6:51 AM, roger riggs wrote: > Hi Ivan, > > (I can't appreciate the error reporting style with just a stack trace; > especially given the generated cases in nested loops). > > Today testng provides better assertion testing methods. It's true that the old test infrastructure is not very helpful when an error is found, but it doesn't have to be - it's optimized to encourage the writing of test assertions; debugging root causes of failures is rarely difficult. From martinrb at google.com Mon Mar 17 18:31:40 2014 From: martinrb at google.com (Martin Buchholz) Date: Mon, 17 Mar 2014 11:31:40 -0700 Subject: RFR [6943190] TEST_BUG: java/lang/Runtime/exec/ExecWithInput.java hardcodes path to cat In-Reply-To: <5326BB2D.6060201@oracle.com> References: <530B80CF.9090403@oracle.com> <530E5D0F.90409@oracle.com> <530E6877.5050504@oracle.com> <530F06A3.1030107@oracle.com> <5323352C.4080007@oracle.com> <5325D6E6.8090208@oracle.com> <5326A961.5030803@oracle.com> <5326BB2D.6060201@oracle.com> Message-ID: The latest webrev looks pretty good. It matters very little, but I agree with Alan that we should send messages about not being able to find dependencies to stdout. Test isolation is always a compromise. I would use othervm only when we are polluting global state during a *successful* run. Because test performance matters. On Mon, Mar 17, 2014 at 2:06 AM, Ivan Gerasimov wrote: > Thank you Alan! > > > On 17.03.2014 11:50, Alan Bateman wrote: > >> On 16/03/2014 16:52, Ivan Gerasimov wrote: >> >>> >>> Would you please take a look at the updated webrev with your suggestions >>> incorporated: >>> http://cr.openjdk.java.net/~igerasim/6943190/3/webrev/ >>> >> >> Ivan - I see that a number of the tests have been changed to /othervm and >> I'm wondering what the reason for this is. Clearly tests for Process will >> be launching new VMs but it would be great if we could avoid having to >> launch a VM for the test "main" too. >> >> > These two tests used the commands run from non very common location > (/usr/bin/ instead of /bin/), so I suspect they have been rarely run. > As it follows from the summaries, one of them ensures the VM doesn't > crash; the other checks, whether the input/output streams are left open. > Both tests in the case of a failure could interfere with other tests > unless they run in the othervm mode. > That's why I thought it's better to add the flag. > > > Another general comment is that if a command is not found the tests will >> now pass and the only way to know that anything has gone wrong is to look >> in the .jtr file. I would personally prefer the tests to fail so that any >> issues in the environment or special-casing for new ports can be found >> quickly. >> >> I've tried not to change the tests' logic too much. > > For example, in test/java/lang/Runtime/exec/ConcurrentRead.java, if 'tee' > hadn't been found, the test just silently exited. > And I only added some debug output about that fact. > Otherwise, if we treat the 'tee' absence as an error, we may start seeing > failures in different environments, which would not be related to > ConcurrentRead.java itself. > > IMO ideally, there should be a configurable part of the harness, where all > the shell commands are set up. > So that they could be accessed by both Java and shell-based regtests. > > > For the Linux or Solaris-only tests then the tests now output an >> information message via System.err, I assume this should be System.out as >> it's not really an error or usage message. >> >> Fixed it. > > > On the places to search then I'm wondering about /system/bin. Is that >> needed? I assume that if there is a port to an operating system that uses >> this location then it will be added as part of the port. >> >> -Alan. >> >> > Sincerely yours, > Ivan > From anthony.petrov at oracle.com Mon Mar 17 18:31:54 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 17 Mar 2014 22:31:54 +0400 Subject: [9] Review request: new macro for conversion to jboolean In-Reply-To: <53270E65.4070001@oracle.com> References: <53270E65.4070001@oracle.com> Message-ID: <53273F9A.3080403@oracle.com> Personally, I'd call it to_jboolean(obj), but IS_TRUE(obj) sounds good to me too. Either way, I'm fine with the fix. -- best regards, Anthony On 3/17/2014 7:01 PM, Sergey Bylokhov wrote: > Hello. > This review request is for the new macro, which simplify conversion to > jboolean. It will be useful for fixing parfait warnings. > > We have a lot of places, where we cast some type to jboolean: > > BOOL = retVal; > return (jboolean) retVal; > > WARNING: Expecting value of JNI primitive type jboolean: mismatched > value retVal with size 32 bits, retVal used for conversion to int8 in return > > > +++ b/src/share/native/common/jni_util.h Mon Mar 17 18:28:48 2014 +0400 > @@ -277,6 +277,7 @@ > > #define IS_NULL(obj) ((obj) == NULL) > #define JNU_IsNull(env,obj) ((obj) == NULL) > +#define IS_TRUE(obj) ((obj) ? JNI_TRUE : JNI_FALSE) > > I am not sure about the name, probably someone have a better suggestion? > > The fix is for jdk9/dev. > > -- > Best regards, Sergey. > From Ulf.Zibis at CoSoCo.de Mon Mar 17 18:36:09 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Mon, 17 Mar 2014 19:36:09 +0100 Subject: RFR 8037106: Optimize Arrays.asList(...).forEach In-Reply-To: References: <80B43E05-0AB3-43B7-B4F3-26FBCCD67E6E@oracle.com> <0A4CACFA-02EF-4EF3-99EF-A7D1455E272A@oracle.com> <53238E16.9060307@CoSoCo.de> <59A82D78-969A-42B3-8CE3-BABC0353A208@oracle.com> <53271DC3.4020606@oracle.com> Message-ID: <53274099.5010403@CoSoCo.de> Am 17.03.2014 17:36, schrieb Paul Sandoz: > Hi Sergey, > > Thanks, you are right! I did not realize it copied the array into a local variable, but that makes sense. > > Here is the byte code generated by javac (9) for two different methods: > ..... Thanks from me too, this is great work. I floated my question because of ... Am 14.03.2014 16:46, schrieb Martin Buchholz: > + final int size = a.length; > + for (int i = 0; i < size; i++) { > > I like to write this using the idiom > > for (int i = 0, size = ...; i < size; i++) This is not thread-proof (Given there is no: final E[] a = this.a;). If a becomes replaced concurrently while looping, size becomes invalid as length of a. Good to know, that foreach over array is always thread-proof and additionally performs at least equal (except of the initial local caching) than a plain fortran-style loop. -Ulf From martinrb at google.com Mon Mar 17 19:13:09 2014 From: martinrb at google.com (Martin Buchholz) Date: Mon, 17 Mar 2014 12:13:09 -0700 Subject: RFR 8037106: Optimize Arrays.asList(...).forEach In-Reply-To: <53274099.5010403@CoSoCo.de> References: <80B43E05-0AB3-43B7-B4F3-26FBCCD67E6E@oracle.com> <0A4CACFA-02EF-4EF3-99EF-A7D1455E272A@oracle.com> <53238E16.9060307@CoSoCo.de> <59A82D78-969A-42B3-8CE3-BABC0353A208@oracle.com> <53271DC3.4020606@oracle.com> <53274099.5010403@CoSoCo.de> Message-ID: On Mon, Mar 17, 2014 at 11:36 AM, Ulf Zibis wrote: > > > Am 14.03.2014 16:46, schrieb Martin Buchholz: > > + final int size = a.length; >> + for (int i = 0; i < size; i++) { >> >> I like to write this using the idiom >> >> for (int i = 0, size = ...; i < size; i++) >> > > This is not thread-proof (Given there is no: final E[] a = this.a;). If a > becomes replaced concurrently while looping, size becomes invalid as length > of a. > That's orthogonal, I think. Certainly, the reflex in concurrent code is to always copy fields to locals, for both performance and correctness. From Alan.Bateman at oracle.com Mon Mar 17 20:25:17 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 17 Mar 2014 20:25:17 +0000 Subject: Javadoc in 9 seems to treat all interfaces with only one method as functional interfaces In-Reply-To: <53272291.7030501@oracle.com> References: <53272291.7030501@oracle.com> Message-ID: <53275A2C.4040300@oracle.com> On 17/03/2014 16:28, Daniel Fuchs wrote: > Hi guys, > > While playing with JDK 9 javadoc command I noticed that it > seems to treat all single method interfaces as if they were > functional interfaces - even though they don't have the > @FunctionalInterface annotation. > > For instance - I did 'make docs' - and I'm seeing this text > in the javadoc for 'java.awt.event.ActionListener': > > >> > Functional Interface: > This is a functional interface and can therefore be used as the > assignment target for a lambda expression or method reference. > << > > Is that a known issue, or a new regression, or did I miss something? Is this JDK-8029143? From what I can tell, it hasn't been forward ported to jdk9/dev yet. -Alan. From Alan.Bateman at oracle.com Mon Mar 17 20:33:59 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 17 Mar 2014 20:33:59 +0000 Subject: RFR[9](XXS): 8037013: [TESTBUG] Fix test/java/lang/ClassLoader/Assert.sh on AIX In-Reply-To: References: <531E0A9E.50908@oracle.com> <531E6E07.2000806@oracle.com> Message-ID: <53275C37.2080304@oracle.com> On 17/03/2014 10:48, Volker Simonis wrote: > Hi Mandy, > > sorry for the delay. You are right, the shell script isn't needed. I > updated the change as suggested by you in the mail you referenced. > Here's the new webrev (tested on Linux/AIX/Solaris): > > http://cr.openjdk.java.net/~simonis/webrevs/8037013_2/webrev/ > > OK, to push now? > Mandy is out today. The removal of the shell script and the updated @build/@run look good to me. -Alan. From Alan.Bateman at oracle.com Mon Mar 17 20:45:52 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 17 Mar 2014 20:45:52 +0000 Subject: RFR [6943190] TEST_BUG: java/lang/Runtime/exec/ExecWithInput.java hardcodes path to cat In-Reply-To: <5326BB2D.6060201@oracle.com> References: <530B80CF.9090403@oracle.com> <530E5D0F.90409@oracle.com> <530E6877.5050504@oracle.com> <530F06A3.1030107@oracle.com> <5323352C.4080007@oracle.com> <5325D6E6.8090208@oracle.com> <5326A961.5030803@oracle.com> <5326BB2D.6060201@oracle.com> Message-ID: <53275F00.5070706@oracle.com> On 17/03/2014 09:06, Ivan Gerasimov wrote: > Thank you Alan! > > These two tests used the commands run from non very common location > (/usr/bin/ instead of /bin/), so I suspect they have been rarely run. > As it follows from the summaries, one of them ensures the VM doesn't > crash; the other checks, whether the input/output streams are left open. > Both tests in the case of a failure could interfere with other tests > unless they run in the othervm mode. > That's why I thought it's better to add the flag. If a test is badly behaved and is leaving streams open then I would agree with othervm. However these are old issues (right?) and should not be happening now. Also if a test tickles a bug that causes the VM to crash then jtreg will spin up a new VM for the next test. So if it's possible to avoid othervm then we should (and from what I can tell then these tests have been well behaved when running without othervm before). > : > > For example, in test/java/lang/Runtime/exec/ConcurrentRead.java, if > 'tee' hadn't been found, the test just silently exited. Okay, it's not a big deal as it shouldn't happen but still worth considering as it would be a lot better (in my view) to not hide an issue that prevents the test from running. > : > > IMO ideally, there should be a configurable part of the harness, where > all the shell commands are set up. > So that they could be accessed by both Java and shell-based regtests. test/lib/testlibrary is the place for test-suite wide infrastructure. I don't know if there are tests beyond the Process area that needs to do the same kind of thing. > >> For the Linux or Solaris-only tests then the tests now output an >> information message via System.err, I assume this should be >> System.out as it's not really an error or usage message. >> > Fixed it. Thanks. -Alan. From Ulf.Zibis at CoSoCo.de Mon Mar 17 20:57:39 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Mon, 17 Mar 2014 21:57:39 +0100 Subject: RFR 8037106: Optimize Arrays.asList(...).forEach In-Reply-To: <20140317090802.722581@eggemoggin.niobe.net> References: <80B43E05-0AB3-43B7-B4F3-26FBCCD67E6E@oracle.com>, , <0A4CACFA-02EF-4EF3-99EF-A7D1455E272A@oracle.com>, <53238E16.9060307@CoSoCo.de>, <59A82D78-969A-42B3-8CE3-BABC0353A208@oracle.com> <20140317090802.722581@eggemoggin.niobe.net> Message-ID: <532761C3.50509@CoSoCo.de> Am 17.03.2014 17:08, schrieb mark.reinhold at oracle.com: > 2014/3/17 1:41 -0700, paul.sandoz at oracle.com: >> On Mar 15, 2014, at 12:17 AM, Ulf Zibis wrote: >>> ... >>> >>> I more like the given style with less spaces: >>> 3854 for (int i=0; i>> It better visualizes the 3 parts of the for statement. >>> >> Subjectively that irritates my eyes :-) non-subjectively it is >> inconsistently applied. What you mean by inconsistently? In the JDK sources? > It's also, well, just plain wrong. > > - Mark You are correct from java code conventions. But I'm wondering, why this "wrong" style is such popular, even in JDK, at least in older sources - where IDE-driven auto-formatting was not available ;-) My only explanation: People think, it's better readable, it better visualizes the 3 parts of the for statement. BTW: IIRC, in NetBeans both styles are configurable for auto-formatting. -Ulf Another similar case: https://bugs.openjdk.java.net/browse/JDK-6939278 From mandy.chung at oracle.com Mon Mar 17 22:39:34 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 17 Mar 2014 15:39:34 -0700 Subject: RFR[9](XXS): 8037013: [TESTBUG] Fix test/java/lang/ClassLoader/Assert.sh on AIX In-Reply-To: References: <531E0A9E.50908@oracle.com> <531E6E07.2000806@oracle.com> Message-ID: <532779A6.7090503@oracle.com> On 3/17/2014 3:48 AM, Volker Simonis wrote: > Hi Mandy, > > sorry for the delay. You are right, the shell script isn't needed. I > updated the change as suggested by you in the mail you referenced. > Here's the new webrev (tested on Linux/AIX/Solaris): > > http://cr.openjdk.java.net/~simonis/webrevs/8037013_2/webrev/ Looks good to me. Thanks for looking into it Volker. > OK, to push now? Go for it. Mandy > Thank you and best regards, > Volker > > > On Tue, Mar 11, 2014 at 6:56 PM, Volker Simonis > wrote: >> Hi Mandy, >> >> thanks for the review. >> >> I'll look into the possibility of removing Assert.sh altogether and >> post a new webrev soon. >> >> Regards, >> Volker >> >> >> On Tue, Mar 11, 2014 at 2:59 AM, Mandy Chung wrote: >>> On 3/10/2014 11:55 AM, Mandy Chung wrote: >>>> Hi Volker, >>>> >>>> On 3/10/14 11:16 AM, Volker Simonis wrote: >>>>> Hi, >>>>> >>>>> could you please review the following trivial change which adds AIX to >>>>> the list of known OSs in test/java/lang/ClassLoader/Assert.sh: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8037013 >>>>> http://cr.openjdk.java.net/~simonis/webrevs/8037013/ >>>>> >>>> The link to your webrev is not accessible and could possibly due to the >>>> server issue. I guess your fix is to add AIX in the Assert.sh test. Can >>>> you paste the diff in mail? I can review it. >>>> >>> I am able to access the webrev now - looks good. >>> >>> >>>> I raised in the code review of 7152892 [1] that I believe this test >>>> doesn't need to be a shell test. I don't know if Rob has started looking >>>> into it (he missed my review comment when he pushed the fix). I wonder if >>>> you would like to take the opportunity to investigate if Assert.sh can be >>>> removed? >>>> >>> It'd be even better if we could get rid of Assert.sh. >>> >>> thanks >>> Mandy >>> >>>> Mandy >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/024995.html >>> From bhavesh.x.patel at oracle.com Mon Mar 17 23:12:04 2014 From: bhavesh.x.patel at oracle.com (Bhavesh Patel) Date: Mon, 17 Mar 2014 16:12:04 -0700 (PDT) Subject: Javadoc in 9 seems to treat all interfaces with only one method as functional interfaces Message-ID: <686d8210-83e6-4d2e-a308-e5bf1797e790@default> Will forward port it. I will send an email once it is done. Regards, Bhavesh. ----- Original Message ----- From: michel.trudeau at oracle.com To: Alan.Bateman at oracle.com, bhavesh.x.patel at oracle.com Cc: daniel.fuchs at oracle.com, core-libs-dev at openjdk.java.net Sent: Monday, March 17, 2014 3:50:43 PM GMT -08:00 US/Canada Pacific Subject: Re: Javadoc in 9 seems to treat all interfaces with only one method as functional interfaces Bhavesh, Can you take care of this ? Create a forward port bug to 9 and then do the push for it. Thanks, Michel Alan Bateman wrote: > On 17/03/2014 16:28, Daniel Fuchs wrote: >> Hi guys, >> >> While playing with JDK 9 javadoc command I noticed that it >> seems to treat all single method interfaces as if they were >> functional interfaces - even though they don't have the >> @FunctionalInterface annotation. >> >> For instance - I did 'make docs' - and I'm seeing this text >> in the javadoc for 'java.awt.event.ActionListener': >> >> >> >> Functional Interface: >> This is a functional interface and can therefore be used as the >> assignment target for a lambda expression or method reference. >> << >> >> Is that a known issue, or a new regression, or did I miss something? > Is this JDK-8029143? From what I can tell, it hasn't been forward > ported to jdk9/dev yet. > > -Alan. From gnu.andrew at redhat.com Tue Mar 18 01:19:30 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 17 Mar 2014 21:19:30 -0400 (EDT) Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <5315424A.4080201@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> Message-ID: <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 3/3/14 2:49 PM, Omair Majid wrote: > > * David Holmes [2014-02-28 18:48]: > >> There are three pieces to all of this: > >> > >> 1. Generating debug symbols in the binaries (via gcc -g or whatever) > >> 2. Generating debuginfo files (zipped or not) (FDS) > >> 3. Stripping debug symbols from the binaries (strip-policy) > >> > >> It may be that we don't have clean separation between them, and if so > >> that should be fixed, but I don't see the current proposal as the way > >> forward. > > Any chance we could clean up the names too? It's not obvious to me why > > FDS means 'generating debuginfo files'. > > FDS stands for Full Debug Symbols and is defined that way in > quite a few Makefiles... We just call it FDS for short... > At least to me, Full Debug Symbols suggests #1 (i.e. that symbols are generated in the binaries), not #2. That's why it sounded so odd to me when you suggested turning it off, when we discussed this before. It's also not clear why you'd want a situation where #3 would be turned off, but not #2, as you end up with two copies of the debug symbols. That's the problem I believe we have with our builds; we can turn the stripping off, but then we end up with duplicate debug information. Do we need more than just the following three alternatives? #1. No debugging information at all. #2. Debugging information left in the original binaries. #3. Debugging information stripped from the binaries and zipped in separate files. It sounds to me like Oracle want #3, while distros want #2 and I imagine some end users may just want #1 for a faster, smaller build. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From david.holmes at oracle.com Tue Mar 18 06:22:31 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Mar 2014 16:22:31 +1000 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <532627B5.8020507@oracle.com> References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> <5322EB0F.8010900@cs.oswego.edu> <5324A8B6.8010009@oracle.com> <532627B5.8020507@oracle.com> Message-ID: <5327E627.9020004@oracle.com> Hi Ivan, On 17/03/2014 8:37 AM, Ivan Gerasimov wrote: > Here is yet another iteration of the fix: > http://cr.openjdk.java.net/~igerasim/8014066/3/webrev/ > > 1) > The condition 'fromIndex >= size()' is removed from the spec. > I prefer removing it rather than replacing it with 'fromIndex > size()' > for two reasons: > - 'fromIndex > size()' already follows on from two other conditions > (toIndex > size() || toIndex < fromIndex); > - it is consistent with the spec for CopyOnWriteArrayList#removeRange(). Ok. > 2) > Kept the check for 'fromIndex > toIndex' in removeRange(). > While I understand that this should not add anything significant to the > current code, as currently removeRange() is always called with valid > arguments. > However, if it is stated in the spec that in case of 'fromIndex > > toIndex' an exception is thrown, I believe it should be thrown, > otherwise why it's stated? I postulate that there may have been some confusion here regarding the logical size of the ArrayList and the actual size of the elementData array. If size were actually elementData.length, then System.arraycopy would throw IOOBE if fromIndex > toIndex. So this extra check is fine, and fixes a bug, though to nitpick as it is spec'd as toIndex 3) > Moved the test to MOAT.java > The test looks a bit foreign over there, but reuses some of the > infrastructure. I'll leave the testing comments to others more qualified. Thanks, David > Sincerely yours, > Ivan > From paul.sandoz at oracle.com Tue Mar 18 08:26:34 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 18 Mar 2014 09:26:34 +0100 Subject: RFR 8037106: Optimize Arrays.asList(...).forEach In-Reply-To: <532761C3.50509@CoSoCo.de> References: <80B43E05-0AB3-43B7-B4F3-26FBCCD67E6E@oracle.com>, , <0A4CACFA-02EF-4EF3-99EF-A7D1455E272A@oracle.com>, <53238E16.9060307@CoSoCo.de>, <59A82D78-969A-42B3-8CE3-BABC0353A208@oracle.com> <20140317090802.722581@eggemoggin.niobe.net> <532761C3.50509@CoSoCo.de> Message-ID: On Mar 17, 2014, at 9:57 PM, Ulf Zibis wrote: > Am 17.03.2014 17:08, schrieb mark.reinhold at oracle.com: >> 2014/3/17 1:41 -0700, paul.sandoz at oracle.com: >>> On Mar 15, 2014, at 12:17 AM, Ulf Zibis wrote: >>>> ... >>>> >>>> I more like the given style with less spaces: >>>> 3854 for (int i=0; i>>> It better visualizes the 3 parts of the for statement. >>>> >>> Subjectively that irritates my eyes :-) non-subjectively it is >>> inconsistently applied. > > What you mean by inconsistently? In the JDK sources? > Yes. Paul. From paul.sandoz at oracle.com Tue Mar 18 08:31:01 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 18 Mar 2014 09:31:01 +0100 Subject: RFR: 8037529: [asm] add back @Suppress tags, removed by last bulk refresh In-Reply-To: <53272F34.1080104@oracle.com> References: <53272F34.1080104@oracle.com> Message-ID: <98F50A23-7D22-41E6-BE1B-176AAF6423C5@oracle.com> On Mar 17, 2014, at 6:21 PM, Kumar Srinivasan wrote: > Hello, > > Please review fix for adding back @SuppressWarnings tag > http://cr.openjdk.java.net/~ksrini/8037529/webrev.0/ > > removed inadvertently with the push for > http://cr.openjdk.java.net/~ksrini/8037221/ > Oops i missed those removals hidden in all the other changes. +1 Paul. > Remi, can you please facilitate getting this fix back into the ASM source base ? > this will make our lives easier, and of course ASM will compiler cleaner, > alternately ASM could use serialVersionUID for these classes. > > Thanks > Kumar > > > > From magnus.ihse.bursie at oracle.com Tue Mar 18 08:59:28 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 18 Mar 2014 09:59:28 +0100 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> Message-ID: <53280AF0.5000502@oracle.com> On 2014-03-18 02:19, Andrew Hughes wrote: > Do we need more than just the following three alternatives? > > #1. No debugging information at all. > #2. Debugging information left in the original binaries. > #3. Debugging information stripped from the binaries and zipped in separate files. > > It sounds to me like Oracle want #3, while distros want #2 and I imagine some > end users may just want #1 for a faster, smaller build. I'm completely thinking along your lines here. I think we should focus on the end result, not the specific implementations details. I've been thinking about exposing a configure option like this: --with-debug-symbols=none (for #1) --with-debug-symbols=internal (for #2) --with-debug-symbols=zipped (for #3) but perhaps with better names. I also imagine there might be a use case for yet another option, #4. Debuggin information stripped from the binaries, but not zipped expressed like this --with-debug-symbols=external And then this would be the only user interface needed, and the rest of the current set of not-really-clear flags can be hidden inside the configure script. For compatibility reasons, the default would be --with-debug-symbols=zipped (which is called "FDS" here), just as we currently do, but distributions would just need to add a --with-debug-symbols=internal to get what they want. /Magnus From gnu.andrew at redhat.com Tue Mar 18 17:28:54 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 18 Mar 2014 13:28:54 -0400 (EDT) Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <53280AF0.5000502@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <53280AF0.5000502@oracle.com> Message-ID: <874803482.1166247.1395163734109.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 2014-03-18 02:19, Andrew Hughes wrote: > > Do we need more than just the following three alternatives? > > > > #1. No debugging information at all. > > #2. Debugging information left in the original binaries. > > #3. Debugging information stripped from the binaries and zipped in separate > > files. > > > > It sounds to me like Oracle want #3, while distros want #2 and I imagine > > some > > end users may just want #1 for a faster, smaller build. > > I'm completely thinking along your lines here. I think we should focus > on the end result, not the specific implementations details. I've been > thinking about exposing a configure option like this: > > --with-debug-symbols=none (for #1) > --with-debug-symbols=internal (for #2) > --with-debug-symbols=zipped (for #3) > > but perhaps with better names. I also imagine there might be a use case > for yet another option, > #4. Debuggin information stripped from the binaries, but not zipped > > expressed like this > --with-debug-symbols=external > > And then this would be the only user interface needed, and the rest of > the current set of not-really-clear flags can be hidden inside the > configure script. > > For compatibility reasons, the default would be > --with-debug-symbols=zipped (which is called "FDS" here), just as we > currently do, but distributions would just need to add a > --with-debug-symbols=internal to get what they want. > > /Magnus > That sounds perfect. We already have to change numerous defaults; one more isn't an issue. The problem at the moment is that, at least in 7, I've had to patch the Makefiles to get what we want (i.e. making STRIP_POLICY=no_strip not create duplicate debuginfo in zipped debuginfo files) and that should be avoided if possible. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From daniel.daugherty at oracle.com Tue Mar 18 17:57:04 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 18 Mar 2014 11:57:04 -0600 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> Message-ID: <532888F0.2050402@oracle.com> On 3/17/14 7:19 PM, Andrew Hughes wrote: > ----- Original Message ----- >> On 3/3/14 2:49 PM, Omair Majid wrote: >>> * David Holmes [2014-02-28 18:48]: >>>> There are three pieces to all of this: >>>> >>>> 1. Generating debug symbols in the binaries (via gcc -g or whatever) >>>> 2. Generating debuginfo files (zipped or not) (FDS) >>>> 3. Stripping debug symbols from the binaries (strip-policy) >>>> >>>> It may be that we don't have clean separation between them, and if so >>>> that should be fixed, but I don't see the current proposal as the way >>>> forward. >>> Any chance we could clean up the names too? It's not obvious to me why >>> FDS means 'generating debuginfo files'. >> FDS stands for Full Debug Symbols and is defined that way in >> quite a few Makefiles... We just call it FDS for short... >> > At least to me, Full Debug Symbols suggests #1 (i.e. that symbols are generated > in the binaries), not #2. That's why it sounded so odd to me when you suggested > turning it off, when we discussed this before. > > It's also not clear why you'd want a situation where #3 would be turned off, but > not #2, as you end up with two copies of the debug symbols. That's the problem > I believe we have with our builds; we can turn the stripping off, but then we > end up with duplicate debug information. > > Do we need more than just the following three alternatives? > > #1. No debugging information at all. > #2. Debugging information left in the original binaries. > #3. Debugging information stripped from the binaries and zipped in separate files. The way Oracle does it is complete debug info in the separate files and partial debug info left in the original binaries so you get symbol names in stack traces for those cases where the full debug info bundles are not available. I'm not clear whether we need a 4th alternative or if #3 covers this case. Dan > > It sounds to me like Oracle want #3, while distros want #2 and I imagine some > end users may just want #1 for a faster, smaller build. From gnu.andrew at redhat.com Tue Mar 18 18:22:59 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 18 Mar 2014 14:22:59 -0400 (EDT) Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <532888F0.2050402@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <532888F0.2050402@oracle.com> Message-ID: <1371463485.1186545.1395166979412.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 3/17/14 7:19 PM, Andrew Hughes wrote: > > ----- Original Message ----- > >> On 3/3/14 2:49 PM, Omair Majid wrote: > >>> * David Holmes [2014-02-28 18:48]: > >>>> There are three pieces to all of this: > >>>> > >>>> 1. Generating debug symbols in the binaries (via gcc -g or whatever) > >>>> 2. Generating debuginfo files (zipped or not) (FDS) > >>>> 3. Stripping debug symbols from the binaries (strip-policy) > >>>> > >>>> It may be that we don't have clean separation between them, and if so > >>>> that should be fixed, but I don't see the current proposal as the way > >>>> forward. > >>> Any chance we could clean up the names too? It's not obvious to me why > >>> FDS means 'generating debuginfo files'. > >> FDS stands for Full Debug Symbols and is defined that way in > >> quite a few Makefiles... We just call it FDS for short... > >> > > At least to me, Full Debug Symbols suggests #1 (i.e. that symbols are > > generated > > in the binaries), not #2. That's why it sounded so odd to me when you > > suggested > > turning it off, when we discussed this before. > > > > It's also not clear why you'd want a situation where #3 would be turned > > off, but > > not #2, as you end up with two copies of the debug symbols. That's the > > problem > > I believe we have with our builds; we can turn the stripping off, but then > > we > > end up with duplicate debug information. > > > > Do we need more than just the following three alternatives? > > > > #1. No debugging information at all. > > #2. Debugging information left in the original binaries. > > #3. Debugging information stripped from the binaries and zipped in separate > > files. > > The way Oracle does it is complete debug info in the > separate files and partial debug info left in the original > binaries so you get symbol names in stack traces for those > cases where the full debug info bundles are not available. > > I'm not clear whether we need a 4th alternative or if #3 > covers this case. > The intent was for #3 to cover this case (i.e. whatever Oracle does now) and for #2 to be what the GNU/Linux distributions want (i.e. binaries with all debuginfo generated and left intact so they can do their own stripping). > Dan > > > > > > It sounds to me like Oracle want #3, while distros want #2 and I imagine > > some > > end users may just want #1 for a faster, smaller build. > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From ivan.gerasimov at oracle.com Tue Mar 18 18:28:10 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 18 Mar 2014 22:28:10 +0400 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> <5322EB0F.8010900@cs.oswego.edu> <5324A8B6.8010009@oracle.com> <532627B5.8020507@oracle.com> Message-ID: <5328903A.6070104@oracle.com> Hello! Would you please take a look at the next iteration of webrev? I incorporated the last suggestions in it. When I first proposed a simple typo fix, I didn't think it's going to cause such a big discussion :) Assuming this last iteration is OK, should the next step be a CCC request? Sincerely yours, Ivan From ivan.gerasimov at oracle.com Tue Mar 18 18:37:50 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 18 Mar 2014 22:37:50 +0400 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <5328903A.6070104@oracle.com> References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> <5322EB0F.8010900@cs.oswego.edu> <5324A8B6.8010009@oracle.com> <532627B5.8020507@oracle.com> <5328903A.6070104@oracle.com> Message-ID: <5328927E.2030004@oracle.com> Sorry, here's the link: http://cr.openjdk.java.net/~igerasim/8014066/4/webrev/ On 18.03.2014 22:28, Ivan Gerasimov wrote: > Hello! > > Would you please take a look at the next iteration of webrev? > I incorporated the last suggestions in it. > > When I first proposed a simple typo fix, I didn't think it's going to > cause such a big discussion :) > > Assuming this last iteration is OK, should the next step be a CCC > request? > > Sincerely yours, > Ivan > > From michel.trudeau at oracle.com Mon Mar 17 22:50:45 2014 From: michel.trudeau at oracle.com (Michel Trudeau) Date: Mon, 17 Mar 2014 15:50:45 -0700 Subject: Javadoc in 9 seems to treat all interfaces with only one method as functional interfaces In-Reply-To: <53275A2C.4040300@oracle.com> References: <53272291.7030501@oracle.com> <53275A2C.4040300@oracle.com> Message-ID: <53277C45.708@oracle.com> Bhavesh, Can you take care of this ? Create a forward port bug to 9 and then do the push for it. Thanks, Michel Alan Bateman wrote: > On 17/03/2014 16:28, Daniel Fuchs wrote: >> Hi guys, >> >> While playing with JDK 9 javadoc command I noticed that it >> seems to treat all single method interfaces as if they were >> functional interfaces - even though they don't have the >> @FunctionalInterface annotation. >> >> For instance - I did 'make docs' - and I'm seeing this text >> in the javadoc for 'java.awt.event.ActionListener': >> >> >> >> Functional Interface: >> This is a functional interface and can therefore be used as the >> assignment target for a lambda expression or method reference. >> << >> >> Is that a known issue, or a new regression, or did I miss something? > Is this JDK-8029143? From what I can tell, it hasn't been forward > ported to jdk9/dev yet. > > -Alan. From christian.thalinger at oracle.com Tue Mar 18 20:36:16 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 18 Mar 2014 13:36:16 -0700 Subject: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types In-Reply-To: <5322E7C6.3050603@oracle.com> References: <5322E7C6.3050603@oracle.com> Message-ID: <659B1DAF-A57F-457F-9F68-8856795555BF@oracle.com> On Mar 14, 2014, at 4:28 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8037210/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8037210 > 953 lines changed: 425 ins; 217 del; 311 mod > > This is a massive cleanup of JSR292 code to replace char-based description of basic types by numeric constants. Why are we not using an Enum instead of an "untyped" byte? > > Contributed-by: john.r.rose at oracle.com > > Testing: jdk/java/{lang/invoke,util}, vm.mlvm.testlist, nashorn, jruby > Flags: -ea -esa -Xverify:all -D...COMPILE_THRESHOLD={0,30} > > Best regards, > Vladimir Ivanov > _______________________________________________ > 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 Mar 18 20:40:29 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 18 Mar 2014 13:40:29 -0700 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <5328927E.2030004@oracle.com> References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> <5322EB0F.8010900@cs.oswego.edu> <5324A8B6.8010009@oracle.com> <532627B5.8020507@oracle.com> <5328903A.6070104@oracle.com> <5328927E.2030004@oracle.com> Message-ID: I approve the latest webrev. On Tue, Mar 18, 2014 at 11:37 AM, Ivan Gerasimov wrote: > Sorry, here's the link: > http://cr.openjdk.java.net/~igerasim/8014066/4/webrev/ > > > On 18.03.2014 22:28, Ivan Gerasimov wrote: > >> Hello! >> >> Would you please take a look at the next iteration of webrev? >> I incorporated the last suggestions in it. >> >> When I first proposed a simple typo fix, I didn't think it's going to >> cause such a big discussion :) >> >> Assuming this last iteration is OK, should the next step be a CCC request? >> >> Sincerely yours, >> Ivan >> >> >> > From daniel.daugherty at oracle.com Tue Mar 18 21:15:55 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 18 Mar 2014 15:15:55 -0600 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <1371463485.1186545.1395166979412.JavaMail.zimbra@redhat.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <532888F0.2050402@oracle.com> <1371463485.1186545.1395166979412.JavaMail.zimbra@redhat.com> Message-ID: <5328B78B.8020806@oracle.com> On 3/18/14 12:22 PM, Andrew Hughes wrote: > ----- Original Message ----- >> On 3/17/14 7:19 PM, Andrew Hughes wrote: >>> ----- Original Message ----- >>>> On 3/3/14 2:49 PM, Omair Majid wrote: >>>>> * David Holmes [2014-02-28 18:48]: >>>>>> There are three pieces to all of this: >>>>>> >>>>>> 1. Generating debug symbols in the binaries (via gcc -g or whatever) >>>>>> 2. Generating debuginfo files (zipped or not) (FDS) >>>>>> 3. Stripping debug symbols from the binaries (strip-policy) >>>>>> >>>>>> It may be that we don't have clean separation between them, and if so >>>>>> that should be fixed, but I don't see the current proposal as the way >>>>>> forward. >>>>> Any chance we could clean up the names too? It's not obvious to me why >>>>> FDS means 'generating debuginfo files'. >>>> FDS stands for Full Debug Symbols and is defined that way in >>>> quite a few Makefiles... We just call it FDS for short... >>>> >>> At least to me, Full Debug Symbols suggests #1 (i.e. that symbols are >>> generated >>> in the binaries), not #2. That's why it sounded so odd to me when you >>> suggested >>> turning it off, when we discussed this before. >>> >>> It's also not clear why you'd want a situation where #3 would be turned >>> off, but >>> not #2, as you end up with two copies of the debug symbols. That's the >>> problem >>> I believe we have with our builds; we can turn the stripping off, but then >>> we >>> end up with duplicate debug information. >>> >>> Do we need more than just the following three alternatives? >>> >>> #1. No debugging information at all. >>> #2. Debugging information left in the original binaries. >>> #3. Debugging information stripped from the binaries and zipped in separate >>> files. >> The way Oracle does it is complete debug info in the >> separate files and partial debug info left in the original >> binaries so you get symbol names in stack traces for those >> cases where the full debug info bundles are not available. >> >> I'm not clear whether we need a 4th alternative or if #3 >> covers this case. >> > The intent was for #3 to cover this case (i.e. whatever Oracle does now) > and for #2 to be what the GNU/Linux distributions want (i.e. binaries with > all debuginfo generated and left intact so they can do their own stripping). Very cool. Thanks for the clarification. Dan > >> Dan >> >> >>> It sounds to me like Oracle want #3, while distros want #2 and I imagine >>> some >>> end users may just want #1 for a faster, smaller build. >> From john.r.rose at oracle.com Tue Mar 18 21:35:59 2014 From: john.r.rose at oracle.com (John Rose) Date: Tue, 18 Mar 2014 14:35:59 -0700 Subject: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types In-Reply-To: <659B1DAF-A57F-457F-9F68-8856795555BF@oracle.com> References: <5322E7C6.3050603@oracle.com> <659B1DAF-A57F-457F-9F68-8856795555BF@oracle.com> Message-ID: On Mar 18, 2014, at 1:36 PM, Christian Thalinger wrote: > Why are we not using an Enum instead of an "untyped" byte? Byte is moderately typed, in the sense (which I rely on during development) that you can't assign an int or char to a byte w/o a cast. That's why it is not just a plain int. But those values (L_TYPE etc.) are used a lot as numbers, and specifically as low-level array indexes, and also comparisons (x < V_TYPE). To turn them into enums, we'd have to add lots of calls to '.ordinal()' to turn them right back to numbers. That dilutes (completely IMO) the value they have as enums to raise the level of the code. ? John From mike.duigou at oracle.com Tue Mar 18 22:11:51 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 18 Mar 2014 15:11:51 -0700 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <5328927E.2030004@oracle.com> References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> <5322EB0F.8010900@cs.oswego.edu> <5324A8B6.8010009@oracle.com> <532627B5.8020507@oracle.com> <5328903A.6070104@oracle.com> <5328927E.2030004@oracle.com> Message-ID: Looks good. On Mar 18 2014, at 11:37 , Ivan Gerasimov wrote: > Sorry, here's the link: > http://cr.openjdk.java.net/~igerasim/8014066/4/webrev/ > > On 18.03.2014 22:28, Ivan Gerasimov wrote: >> Hello! >> >> Would you please take a look at the next iteration of webrev? >> I incorporated the last suggestions in it. >> >> When I first proposed a simple typo fix, I didn't think it's going to cause such a big discussion :) The most innocent questions have the most complicated answers. >> >> Assuming this last iteration is OK, should the next step be a CCC request? Yes. (I can be your reviewer for that, ping me once you have created the CCC) Mike From Ulf.Zibis at CoSoCo.de Tue Mar 18 22:12:26 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Tue, 18 Mar 2014 23:12:26 +0100 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <5328903A.6070104@oracle.com> References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> <5322EB0F.8010900@cs.oswego.edu> <5324A8B6.8010009@oracle.com> <532627B5.8020507@oracle.com> <5328903A.6070104@oracle.com> Message-ID: <5328C4CA.6090906@CoSoCo.de> Am 18.03.2014 19:28, schrieb Ivan Gerasimov: > > Assuming this last iteration is OK, should the next step be a CCC request? Do you mean? : /* * ... + * It is assumed that fromIndex <= toIndex, otherwise the behaviour of this method is undefined. * ... - * toIndex < fromIndex}) * ... */ protected void removeRange(int fromIndex, int toIndex) { ... Please remove and replace inline by size - toIndex: 621 int numMoved = size - toIndex; About modCount: Wouldn't it be more correct to code? : 616 if (fromIndex > toIndex) { 617 throw new IndexOutOfBoundsException( 618 outOfBoundsMsg(fromIndex, toIndex)); 619 } 620 try { 621 modCount++; 622 System.arraycopy(elementData, toIndex, elementData, fromIndex, 623 size - toIndex); 624 } catch (IndexOutOfBoundsException ioobe) { 625 modCount--; 626 throw ioobe; 627 } Of even better : 000 private int[] modCount = { 0 }; ... 616 if (fromIndex > toIndex) { 617 throw new IndexOutOfBoundsException( 618 outOfBoundsMsg(fromIndex, toIndex)); 619 } 620 System.arraycopy(elementData, toIndex, elementData, fromIndex, 621 size - toIndex, modCount); Or : 000 public class ArrayList ... implements ModCounter { 001 private int modCount = 0; 001 void incModCount() { 001 modCount++; 004 } ... 616 if (fromIndex > toIndex) { 617 throw new IndexOutOfBoundsException( 618 outOfBoundsMsg(fromIndex, toIndex)); 619 } 620 System.arraycopy(elementData, toIndex, elementData, fromIndex, 621 size - toIndex, this); -Ulf From martinrb at google.com Tue Mar 18 22:17:01 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 18 Mar 2014 15:17:01 -0700 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <5328C4CA.6090906@CoSoCo.de> References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> <5322EB0F.8010900@cs.oswego.edu> <5324A8B6.8010009@oracle.com> <532627B5.8020507@oracle.com> <5328903A.6070104@oracle.com> <5328C4CA.6090906@CoSoCo.de> Message-ID: modCount is an imprecise concurrent modification mechanism. It doesn't have to be kept transactionally correct. On Tue, Mar 18, 2014 at 3:12 PM, Ulf Zibis wrote: > Am 18.03.2014 19:28, schrieb Ivan Gerasimov: > > >> Assuming this last iteration is OK, should the next step be a CCC request? >> > > Do you mean? : > /* > * ... > + * It is assumed that fromIndex <= toIndex, otherwise the behaviour > of this method is undefined. > * ... > - * toIndex < fromIndex}) > * ... > */ > protected void removeRange(int fromIndex, int toIndex) { > ... > > Please remove and replace inline by size - toIndex: > 621 int numMoved = size - toIndex; > > > About modCount: > > Wouldn't it be more correct to code? : > > 616 if (fromIndex > toIndex) { > 617 throw new IndexOutOfBoundsException( > 618 outOfBoundsMsg(fromIndex, toIndex)); > 619 } > 620 try { > 621 modCount++; > 622 System.arraycopy(elementData, toIndex, elementData, > fromIndex, > 623 size - toIndex); > 624 } catch (IndexOutOfBoundsException ioobe) { > 625 modCount--; > 626 throw ioobe; > 627 } > > Of even better : > > 000 private int[] modCount = { 0 }; > ... > 616 if (fromIndex > toIndex) { > 617 throw new IndexOutOfBoundsException( > 618 outOfBoundsMsg(fromIndex, toIndex)); > 619 } > 620 System.arraycopy(elementData, toIndex, elementData, fromIndex, > 621 size - toIndex, modCount); > > Or : > > 000 public class ArrayList ... implements ModCounter { > 001 private int modCount = 0; > 001 void incModCount() { > 001 modCount++; > 004 } > ... > 616 if (fromIndex > toIndex) { > 617 throw new IndexOutOfBoundsException( > 618 outOfBoundsMsg(fromIndex, toIndex)); > 619 } > 620 System.arraycopy(elementData, toIndex, elementData, fromIndex, > 621 size - toIndex, this); > > -Ulf > > > From Ulf.Zibis at CoSoCo.de Tue Mar 18 22:54:38 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Tue, 18 Mar 2014 23:54:38 +0100 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> <5322EB0F.8010900@cs.oswego.edu> <5324A8B6.8010009@oracle.com> <532627B5.8020507@oracle.com> <5328903A.6070104@oracle.com> <5328C4CA.6090906@CoSoCo.de> Message-ID: <5328CEAE.2000902@CoSoCo.de> Am 18.03.2014 23:17, schrieb Martin Buchholz: > modCount is an imprecise concurrent modification mechanism. It doesn't have to be kept > transactionally correct. Thanks, yes I know. But does it hurt to make it more precise? See this as a concept for a RFE. -Ulf From martinrb at google.com Tue Mar 18 23:39:53 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 18 Mar 2014 16:39:53 -0700 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <5328CEAE.2000902@CoSoCo.de> References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> <5322EB0F.8010900@cs.oswego.edu> <5324A8B6.8010009@oracle.com> <532627B5.8020507@oracle.com> <5328903A.6070104@oracle.com> <5328C4CA.6090906@CoSoCo.de> <5328CEAE.2000902@CoSoCo.de> Message-ID: On Tue, Mar 18, 2014 at 3:54 PM, Ulf Zibis wrote: > Am 18.03.2014 23:17, schrieb Martin Buchholz: > > modCount is an imprecise concurrent modification mechanism. It doesn't >> have to be kept transactionally correct. >> > > Thanks, yes I know. > But does it hurt to make it more precise? > How does it help to make it more precise? From christian.thalinger at oracle.com Wed Mar 19 01:18:06 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 18 Mar 2014 18:18:06 -0700 Subject: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types In-Reply-To: References: <5322E7C6.3050603@oracle.com> <659B1DAF-A57F-457F-9F68-8856795555BF@oracle.com> Message-ID: On Mar 18, 2014, at 2:35 PM, John Rose wrote: > On Mar 18, 2014, at 1:36 PM, Christian Thalinger wrote: > >> Why are we not using an Enum instead of an "untyped" byte? > > Byte is moderately typed, in the sense (which I rely on during development) that you can't assign an int or char to a byte w/o a cast. > That's why it is not just a plain int. > > But those values (L_TYPE etc.) are used a lot as numbers, and specifically as low-level array indexes, and also comparisons (x < V_TYPE). > > To turn them into enums, we'd have to add lots of calls to '.ordinal()' to turn them right back to numbers. That dilutes (completely IMO) the value they have as enums to raise the level of the code. But without being strongly typed we get bugs like this one: @Override - MethodHandle bindArgument(int pos, char basicType, Object value) { + MethodHandle bindArgument(int pos, byte basicType, Object value) { // If the member needs dispatching, do so. if (pos == 0 && basicType == 'L') { I?m just saying that for the sake of maintainability and correctness an Enum would be better. > > ? John > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From ivan.gerasimov at oracle.com Wed Mar 19 08:19:43 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 19 Mar 2014 12:19:43 +0400 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <5328C4CA.6090906@CoSoCo.de> References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> <5322EB0F.8010900@cs.oswego.edu> <5324A8B6.8010009@oracle.com> <532627B5.8020507@oracle.com> <5328903A.6070104@oracle.com> <5328C4CA.6090906@CoSoCo.de> Message-ID: <5329531F.9070109@oracle.com> Thank you Ulf! On 19.03.2014 2:12, Ulf Zibis wrote: > Am 18.03.2014 19:28, schrieb Ivan Gerasimov: >> >> Assuming this last iteration is OK, should the next step be a CCC >> request? > > Do you mean? : > /* > * ... > + * It is assumed that fromIndex <= toIndex, otherwise the > behaviour of this method is undefined. > * ... > - * toIndex < fromIndex}) > * ... > */ > protected void removeRange(int fromIndex, int toIndex) { > ... > The (fromIndex > toIndex) condition is checked now, so the behavior of the method is defined - it throws an exception. > Please remove and replace inline by size - toIndex: > 621 int numMoved = size - toIndex; > It is done this way throughout the class. I don't think it has to be changed in this particular place. Improving modCound handling can be done with a different RFE I guess, as it doesn't connected to the rest of the fix. Sincerely yours, Ivan > > About modCount: > > Wouldn't it be more correct to code? : > > 616 if (fromIndex > toIndex) { > 617 throw new IndexOutOfBoundsException( > 618 outOfBoundsMsg(fromIndex, toIndex)); > 619 } > 620 try { > 621 modCount++; > 622 System.arraycopy(elementData, toIndex, elementData, > fromIndex, > 623 size - toIndex); > 624 } catch (IndexOutOfBoundsException ioobe) { > 625 modCount--; > 626 throw ioobe; > 627 } > > Of even better : > > 000 private int[] modCount = { 0 }; > ... > 616 if (fromIndex > toIndex) { > 617 throw new IndexOutOfBoundsException( > 618 outOfBoundsMsg(fromIndex, toIndex)); > 619 } > 620 System.arraycopy(elementData, toIndex, elementData, > fromIndex, > 621 size - toIndex, modCount); > > Or : > > 000 public class ArrayList ... implements ModCounter { > 001 private int modCount = 0; > 001 void incModCount() { > 001 modCount++; > 004 } > ... > 616 if (fromIndex > toIndex) { > 617 throw new IndexOutOfBoundsException( > 618 outOfBoundsMsg(fromIndex, toIndex)); > 619 } > 620 System.arraycopy(elementData, toIndex, elementData, > fromIndex, > 621 size - toIndex, this); > > -Ulf > > > > From david.holmes at oracle.com Wed Mar 19 08:29:25 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 19 Mar 2014 18:29:25 +1000 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <5328927E.2030004@oracle.com> References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> <5322EB0F.8010900@cs.oswego.edu> <5324A8B6.8010009@oracle.com> <532627B5.8020507@oracle.com> <5328903A.6070104@oracle.com> <5328927E.2030004@oracle.com> Message-ID: <53295565.6030001@oracle.com> Fine by me. David On 19/03/2014 4:37 AM, Ivan Gerasimov wrote: > Sorry, here's the link: > http://cr.openjdk.java.net/~igerasim/8014066/4/webrev/ > > On 18.03.2014 22:28, Ivan Gerasimov wrote: >> Hello! >> >> Would you please take a look at the next iteration of webrev? >> I incorporated the last suggestions in it. >> >> When I first proposed a simple typo fix, I didn't think it's going to >> cause such a big discussion :) >> >> Assuming this last iteration is OK, should the next step be a CCC >> request? >> >> Sincerely yours, >> Ivan >> >> > From chris.hegarty at oracle.com Wed Mar 19 10:02:33 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 19 Mar 2014 10:02:33 +0000 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <53295565.6030001@oracle.com> References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> <5322EB0F.8010900@cs.oswego.edu> <5324A8B6.8010009@oracle.com> <532627B5.8020507@oracle.com> <5328903A.6070104@oracle.com> <5328927E.2030004@oracle.com> <53295565.6030001@oracle.com> Message-ID: <53296B39.4030004@oracle.com> On 19/03/14 08:29, David Holmes wrote: > Fine by me. > > David > > On 19/03/2014 4:37 AM, Ivan Gerasimov wrote: >> Sorry, here's the link: >> http://cr.openjdk.java.net/~igerasim/8014066/4/webrev/ Looks fine to me too. -Chris. >> >> On 18.03.2014 22:28, Ivan Gerasimov wrote: >>> Hello! >>> >>> Would you please take a look at the next iteration of webrev? >>> I incorporated the last suggestions in it. >>> >>> When I first proposed a simple typo fix, I didn't think it's going to >>> cause such a big discussion :) >>> >>> Assuming this last iteration is OK, should the next step be a CCC >>> request? >>> >>> Sincerely yours, >>> Ivan >>> >>> >> From Alan.Bateman at oracle.com Wed Mar 19 10:48:02 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 19 Mar 2014 10:48:02 +0000 Subject: RFR: JDK-8035099 LocalTime with(MILLI_OF_DAY/MICRO_OF_DAY) incorrect In-Reply-To: <53270BF2.7070304@oracle.com> References: <53270BF2.7070304@oracle.com> Message-ID: <532975E2.6030900@oracle.com> On 17/03/2014 14:51, roger riggs wrote: > Hi, > > This looks fine (not a Reviewer). Looks okay to me too. > > I'm checking on how to handle the change in TCK tests. > The same question (and answer) applies to JDK-8036818: > DateTimeFormatter withResolverFields() fails to accept null There is a process for challenging conformance tests so I wouldn't expect any issues. -Alan From Alan.Bateman at oracle.com Wed Mar 19 10:53:55 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 19 Mar 2014 10:53:55 +0000 Subject: RFR: JDK-8036785 ChronoLocalDate refers to generics that have been removed In-Reply-To: References: Message-ID: <53297743.7000909@oracle.com> On 12/03/2014 10:52, Stephen Colebourne wrote: > This is a request for review of this bug: > https://bugs.openjdk.java.net/browse/JDK-8036785 > > During development, ChronoLocalDate had a generic type parameter. It > was removed during the development of JSR-310. The Javadoc was not > updated to reflect the removal. > > The necessary change is to text that is essentially non-normative, and > as such this change should be non-controversial. > Have you considered using @apiNote here? -Alan. From scolebourne at joda.org Wed Mar 19 10:59:07 2014 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 19 Mar 2014 10:59:07 +0000 Subject: RFR: JDK-8036785 ChronoLocalDate refers to generics that have been removed In-Reply-To: <53297743.7000909@oracle.com> References: <53297743.7000909@oracle.com> Message-ID: At the time it was originally written I don't think @apiNote existed. I agree it would be good to get the separation in there. However my current concern is getting the change back to jdk8u, and it seems that the simplest solution might be the best to achieve that. Perhaps later, I might then consider rechecking all of java.time for non-normative stuff to go in a separate commit. Stephen On 19 March 2014 10:53, Alan Bateman wrote: > On 12/03/2014 10:52, Stephen Colebourne wrote: >> >> This is a request for review of this bug: >> https://bugs.openjdk.java.net/browse/JDK-8036785 >> >> During development, ChronoLocalDate had a generic type parameter. It >> was removed during the development of JSR-310. The Javadoc was not >> updated to reflect the removal. >> >> The necessary change is to text that is essentially non-normative, and >> as such this change should be non-controversial. >> > Have you considered using @apiNote here? > > -Alan. From Alan.Bateman at oracle.com Wed Mar 19 11:07:14 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 19 Mar 2014 11:07:14 +0000 Subject: RFR: JDK-8036785 ChronoLocalDate refers to generics that have been removed In-Reply-To: References: <53297743.7000909@oracle.com> Message-ID: <53297A62.2090605@oracle.com> On 19/03/2014 10:59, Stephen Colebourne wrote: > At the time it was originally written I don't think @apiNote existed. > I agree it would be good to get the separation in there. However my > current concern is getting the change back to jdk8u, and it seems that > the simplest solution might be the best to achieve that. > > Perhaps later, I might then consider rechecking all of java.time for > non-normative stuff to go in a separate commit. > I'd like to us make use of the the new tags in other areas, especially paragraphs and statements where it might not be initially clear where they are normative or non-normative. In any case, the patch looks okay to me and I think Roger has said he would sponsor it. -Alan From aph at redhat.com Tue Mar 18 18:25:34 2014 From: aph at redhat.com (Andrew Haley) Date: Tue, 18 Mar 2014 18:25:34 +0000 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <1371463485.1186545.1395166979412.JavaMail.zimbra@redhat.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <532888F0.2050402@oracle.com> <1371463485.1186545.1395166979412.JavaMail.zimbra@redhat.com> Message-ID: <53288F9E.6070309@redhat.com> On 03/18/2014 06:22 PM, Andrew Hughes wrote: > The intent was for #3 to cover this case (i.e. whatever Oracle does now) > and for #2 to be what the GNU/Linux distributions want (i.e. binaries with > all debuginfo generated and left intact so they can do their own stripping). Mmm, but maybe that will break things when debuginfo isn't installed. In fact, I already know that it has broken some things. So it's not ideal. Andrew. From magnus.ihse.bursie at oracle.com Wed Mar 19 13:51:33 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 19 Mar 2014 14:51:33 +0100 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <53288F9E.6070309@redhat.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <532888F0.2050402@oracle.com> <1371463485.1186545.1395166979412.JavaMail.zimbra@redhat.com> <53288F9E.6070309@redhat.com> Message-ID: <5329A0E5.4000603@oracle.com> On 2014-03-18 19:25, Andrew Haley wrote: > On 03/18/2014 06:22 PM, Andrew Hughes wrote: >> The intent was for #3 to cover this case (i.e. whatever Oracle does now) >> and for #2 to be what the GNU/Linux distributions want (i.e. binaries with >> all debuginfo generated and left intact so they can do their own stripping). > Mmm, but maybe that will break things when debuginfo isn't installed. > In fact, I already know that it has broken some things. So it's not > ideal. Which case is it that will break? #3 or #2? What would an ideal solution be for you? /Magnus From ivan.gerasimov at oracle.com Wed Mar 19 14:34:57 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 19 Mar 2014 18:34:57 +0400 Subject: RFR [6943190] TEST_BUG: java/lang/Runtime/exec/ExecWithInput.java hardcodes path to cat In-Reply-To: <53275F00.5070706@oracle.com> References: <530B80CF.9090403@oracle.com> <530E5D0F.90409@oracle.com> <530E6877.5050504@oracle.com> <530F06A3.1030107@oracle.com> <5323352C.4080007@oracle.com> <5325D6E6.8090208@oracle.com> <5326A961.5030803@oracle.com> <5326BB2D.6060201@oracle.com> <53275F00.5070706@oracle.com> Message-ID: <5329AB11.2080702@oracle.com> Thanks Alan! >> These two tests used the commands run from non very common location >> (/usr/bin/ instead of /bin/), so I suspect they have been rarely run. >> As it follows from the summaries, one of them ensures the VM doesn't >> crash; the other checks, whether the input/output streams are left open. >> Both tests in the case of a failure could interfere with other tests >> unless they run in the othervm mode. >> That's why I thought it's better to add the flag. > If a test is badly behaved and is leaving streams open then I would > agree with othervm. However these are old issues (right?) and should > not be happening now. Also if a test tickles a bug that causes the VM > to crash then jtreg will spin up a new VM for the next test. So if > it's possible to avoid othervm then we should (and from what I can > tell then these tests have been well behaved when running without > othervm before). > Yes, got it. I will remove othervm mode. Once I was suggested to add the othervm mode to the test which was to detect a memory leak (in the case of a poor behavior). So I was under wrong impression that we need to use this mode even when normal run of a test doesn't influence any other. Omitting othervm for the tests that do not interfere with others during normal runs does make sense, and I will follow this rule from now on. >> >> IMO ideally, there should be a configurable part of the harness, >> where all the shell commands are set up. >> So that they could be accessed by both Java and shell-based regtests. > test/lib/testlibrary is the place for test-suite wide infrastructure. > I don't know if there are tests beyond the Process area that needs to > do the same kind of thing. > I meant something that can be configured by a user of the harness. It's beyond the scope of this bug, of course. Sincerely yours, Ivan From aph at redhat.com Wed Mar 19 14:54:32 2014 From: aph at redhat.com (Andrew Haley) Date: Wed, 19 Mar 2014 14:54:32 +0000 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <5329A0E5.4000603@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <532888F0.2050402@oracle.com> <1371463485.1186545.1395166979412.JavaMail.zimbra@redhat.com> <53288F9E.6070309@redhat.com> <5329A0E5.4000603@oracle.com> Message-ID: <5329AFA8.2090003@redhat.com> On 03/19/2014 01:51 PM, Magnus Ihse Bursie wrote: > On 2014-03-18 19:25, Andrew Haley wrote: >> On 03/18/2014 06:22 PM, Andrew Hughes wrote: >>> The intent was for #3 to cover this case (i.e. whatever Oracle does now) >>> and for #2 to be what the GNU/Linux distributions want (i.e. binaries with >>> all debuginfo generated and left intact so they can do their own stripping). >> Mmm, but maybe that will break things when debuginfo isn't installed. >> In fact, I already know that it has broken some things. So it's not >> ideal. > > Which case is it that will break? #3 or #2? What would an ideal solution > be for you? I think the problem was that jstack and jmap didn't work until the debuginfo package was installed. This tells me that the debuginfo stripping in our Linux build system is too aggressive for this purpose. I think that's something we must fix ourselves. What we really need from OpenJDK is a way to build with complete debuginfo in both binaries and jarfiles. Andrew. From gnu.andrew at redhat.com Wed Mar 19 14:57:31 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 19 Mar 2014 10:57:31 -0400 (EDT) Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <5329AFA8.2090003@redhat.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <532888F0.2050402@oracle.com> <1371463485.1186545.1395166979412.JavaMail.zimbra@redhat.com> <53288F9E.6070309@redhat.com> <5329A0E5.4000603@oracle.com> <5329AFA8.2090003@redhat.com> Message-ID: <955387107.1663490.1395241051025.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 03/19/2014 01:51 PM, Magnus Ihse Bursie wrote: > > On 2014-03-18 19:25, Andrew Haley wrote: > >> On 03/18/2014 06:22 PM, Andrew Hughes wrote: > >>> The intent was for #3 to cover this case (i.e. whatever Oracle does now) > >>> and for #2 to be what the GNU/Linux distributions want (i.e. binaries > >>> with > >>> all debuginfo generated and left intact so they can do their own > >>> stripping). > >> Mmm, but maybe that will break things when debuginfo isn't installed. > >> In fact, I already know that it has broken some things. So it's not > >> ideal. > > > > Which case is it that will break? #3 or #2? What would an ideal solution > > be for you? > > I think the problem was that jstack and jmap didn't work until the > debuginfo package was installed. This tells me that the debuginfo > stripping in our Linux build system is too aggressive for this purpose. > Yes, https://bugzilla.redhat.com/show_bug.cgi?id=1010786 The distro builds strip too much and remove the needed symtab from libjvm.so. > I think that's something we must fix ourselves. What we really > need from OpenJDK is a way to build with complete debuginfo in > both binaries and jarfiles. This was my intent with #2. The jstack/jmap issue needs to be fixed by stripping less debuginfo post-build on libjvm.so. > > Andrew. > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From ivan.gerasimov at oracle.com Wed Mar 19 15:50:07 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 19 Mar 2014 19:50:07 +0400 Subject: RFR [6943190] TEST_BUG: java/lang/Runtime/exec/ExecWithInput.java hardcodes path to cat In-Reply-To: <53275F00.5070706@oracle.com> References: <530B80CF.9090403@oracle.com> <530E5D0F.90409@oracle.com> <530E6877.5050504@oracle.com> <530F06A3.1030107@oracle.com> <5323352C.4080007@oracle.com> <5325D6E6.8090208@oracle.com> <5326A961.5030803@oracle.com> <5326BB2D.6060201@oracle.com> <53275F00.5070706@oracle.com> Message-ID: <5329BCAF.3040106@oracle.com> Here's the (hopefully final) polished webrev: removed 'othervm' and replaced stderr with stdout in reporting of the wrong OS. Would you please take a look? http://cr.openjdk.java.net/~igerasim/6943190/4/webrev/ Sincerely yours, Ivan From martinrb at google.com Wed Mar 19 16:11:00 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 19 Mar 2014 09:11:00 -0700 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <5329531F.9070109@oracle.com> References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> <5322EB0F.8010900@cs.oswego.edu> <5324A8B6.8010009@oracle.com> <532627B5.8020507@oracle.com> <5328903A.6070104@oracle.com> <5328C4CA.6090906@CoSoCo.de> <5329531F.9070109@oracle.com> Message-ID: On Wed, Mar 19, 2014 at 1:19 AM, Ivan Gerasimov wrote: > > Improving modCound handling can be done with a different RFE I guess, as > it doesn't connected to the rest of the fix. > > I don't think modCount handling needs improvement. If you're actually looking for follow-on improvements, I suggest globally replacing all of my Fun() poor-man emulations of lambdas with Real Lambdas. From martinrb at google.com Wed Mar 19 16:23:46 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 19 Mar 2014 09:23:46 -0700 Subject: RFR [6943190] TEST_BUG: java/lang/Runtime/exec/ExecWithInput.java hardcodes path to cat In-Reply-To: <5329BCAF.3040106@oracle.com> References: <530B80CF.9090403@oracle.com> <530E5D0F.90409@oracle.com> <530E6877.5050504@oracle.com> <530F06A3.1030107@oracle.com> <5323352C.4080007@oracle.com> <5325D6E6.8090208@oracle.com> <5326A961.5030803@oracle.com> <5326BB2D.6060201@oracle.com> <53275F00.5070706@oracle.com> <5329BCAF.3040106@oracle.com> Message-ID: + if (trueCmd == null) { + System.err.println("'true' not found"); return; + } I expected to see System.out used instead (not that it matters much). I would write: System.out.println("'true' command not found; skipping test"); On Wed, Mar 19, 2014 at 8:50 AM, Ivan Gerasimov wrote: > Here's the (hopefully final) polished webrev: removed 'othervm' and > replaced stderr with stdout in reporting of the wrong OS. > > Would you please take a look? > > http://cr.openjdk.java.net/~igerasim/6943190/4/webrev/ > > Sincerely yours, > Ivan > > From ivan.gerasimov at oracle.com Wed Mar 19 16:27:59 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 19 Mar 2014 20:27:59 +0400 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> <5322EB0F.8010900@cs.oswego.edu> <5324A8B6.8010009@oracle.com> <532627B5.8020507@oracle.com> <5328903A.6070104@oracle.com> <5328C4CA.6090906@CoSoCo.de> <5329531F.9070109@oracle.com> Message-ID: <5329C58F.9010904@oracle.com> On 19.03.2014 20:11, Martin Buchholz wrote: > > > > On Wed, Mar 19, 2014 at 1:19 AM, Ivan Gerasimov > > wrote: > > > Improving modCound handling can be done with a different RFE I > guess, as it doesn't connected to the rest of the fix. > > > I don't think modCount handling needs improvement. > I didn't mean to propose modCount improvement. What I really meant was that modCount improvement (if required) should be separated from the removeRange's spec fix. > If you're actually looking for follow-on improvements, I suggest > globally replacing all of my Fun() poor-man emulations of lambdas with > Real Lambdas. > Thanks for suggestion, Martin. I crated an issue to track this: https://bugs.openjdk.java.net/browse/JDK-8037866 Sincerely yours, Ivan From ivan.gerasimov at oracle.com Wed Mar 19 17:34:44 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 19 Mar 2014 21:34:44 +0400 Subject: RFR [6943190] TEST_BUG: java/lang/Runtime/exec/ExecWithInput.java hardcodes path to cat In-Reply-To: References: <530B80CF.9090403@oracle.com> <530E5D0F.90409@oracle.com> <530E6877.5050504@oracle.com> <530F06A3.1030107@oracle.com> <5323352C.4080007@oracle.com> <5325D6E6.8090208@oracle.com> <5326A961.5030803@oracle.com> <5326BB2D.6060201@oracle.com> <53275F00.5070706@oracle.com> <5329BCAF.3040106@oracle.com> Message-ID: <5329D534.3030509@oracle.com> Thanks Martin! On 19.03.2014 20:23, Martin Buchholz wrote: > I expected to see System.out used instead (not that it matters much). > > I would write: > > System.out.println("'true' command not found; skipping test"); Two cases are mixed here: - normal run (OS does not have this command), - erroneous run (OS isn't configured correctly, so the command couldn't be find). I agree it's not matters much, so no problem to replace the output as you suggest. Here's the (final?) webrev: http://cr.openjdk.java.net/~igerasim/6943190/5/webrev/ Sincerely yours, Ivan From jeremymanson at google.com Wed Mar 19 17:41:30 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 19 Mar 2014 10:41:30 -0700 Subject: StringBuilder version of java.util.regex.Matcher.append* Message-ID: Hi folks, We've had this internally for a while, and I keep meaning to bring it up here. The Matcher class has a few public methods that take StringBuffers, and we've found it useful to add similar versions that take StringBuilders. It has two benefits: - Users don't have to convert from one to the other when they want to use the method in question. The symmetry is nice. - The StringBuilder variants are faster (if lock optimizations don't kick in, which happens in the interpreter and the client compiler). For interpreted / client-compiled code, we saw something like a 25% speedup on String.replaceAll(), which calls into this code. Any interest? Diff attached. Jeremy From martinrb at google.com Wed Mar 19 17:46:36 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 19 Mar 2014 10:46:36 -0700 Subject: RFR [6943190] TEST_BUG: java/lang/Runtime/exec/ExecWithInput.java hardcodes path to cat In-Reply-To: <5329D534.3030509@oracle.com> References: <530B80CF.9090403@oracle.com> <530E5D0F.90409@oracle.com> <530E6877.5050504@oracle.com> <530F06A3.1030107@oracle.com> <5323352C.4080007@oracle.com> <5325D6E6.8090208@oracle.com> <5326A961.5030803@oracle.com> <5326BB2D.6060201@oracle.com> <53275F00.5070706@oracle.com> <5329BCAF.3040106@oracle.com> <5329D534.3030509@oracle.com> Message-ID: Looks Good To Me! On Wed, Mar 19, 2014 at 10:34 AM, Ivan Gerasimov wrote: > Thanks Martin! > > > On 19.03.2014 20:23, Martin Buchholz wrote: > >> I expected to see System.out used instead (not that it matters much). >> >> I would write: >> >> System.out.println("'true' command not found; skipping test"); >> > > Two cases are mixed here: > - normal run (OS does not have this command), > - erroneous run (OS isn't configured correctly, so the command couldn't be > find). > > I agree it's not matters much, so no problem to replace the output as you > suggest. > > Here's the (final?) webrev: > http://cr.openjdk.java.net/~igerasim/6943190/5/webrev/ > > Sincerely yours, > Ivan > From jeremymanson at google.com Wed Mar 19 17:51:14 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 19 Mar 2014 10:51:14 -0700 Subject: StringBuilder version of java.util.regex.Matcher.append* In-Reply-To: References: Message-ID: I'm told that the diff didn't make it. I've put it in a Google drive folder... https://drive.google.com/file/d/0B_GaXa6O4K5LY3Y0aHpranM3aEU/edit?usp=sharing Jeremy On Wed, Mar 19, 2014 at 10:41 AM, Jeremy Manson wrote: > Hi folks, > > We've had this internally for a while, and I keep meaning to bring it up > here. The Matcher class has a few public methods that take StringBuffers, > and we've found it useful to add similar versions that take StringBuilders. > > It has two benefits: > > - Users don't have to convert from one to the other when they want to use > the method in question. The symmetry is nice. > > - The StringBuilder variants are faster (if lock optimizations don't kick > in, which happens in the interpreter and the client compiler). For > interpreted / client-compiled code, we saw something like a 25% speedup on > String.replaceAll(), which calls into this code. > > Any interest? Diff attached. > > Jeremy > From xueming.shen at oracle.com Wed Mar 19 18:09:38 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 19 Mar 2014 11:09:38 -0700 Subject: StringBuilder version of java.util.regex.Matcher.append* In-Reply-To: References: Message-ID: <5329DD62.1070907@oracle.com> Similar suggestion has been on the to-do list for a while. There were discussion back then that it might be interesting to add the more general interface Appendable... The issue was how to deal with the IOE declared by the Appendable methods then. If the appendable is not going to happen, then it is definitely worth adding the StringBuilder for better performance. -Sherman On 03/19/2014 10:51 AM, Jeremy Manson wrote: > I'm told that the diff didn't make it. I've put it in a Google drive > folder... > > https://drive.google.com/file/d/0B_GaXa6O4K5LY3Y0aHpranM3aEU/edit?usp=sharing > > Jeremy > > > On Wed, Mar 19, 2014 at 10:41 AM, Jeremy Mansonwrote: > >> Hi folks, >> >> We've had this internally for a while, and I keep meaning to bring it up >> here. The Matcher class has a few public methods that take StringBuffers, >> and we've found it useful to add similar versions that take StringBuilders. >> >> It has two benefits: >> >> - Users don't have to convert from one to the other when they want to use >> the method in question. The symmetry is nice. >> >> - The StringBuilder variants are faster (if lock optimizations don't kick >> in, which happens in the interpreter and the client compiler). For >> interpreted / client-compiled code, we saw something like a 25% speedup on >> String.replaceAll(), which calls into this code. >> >> Any interest? Diff attached. >> >> Jeremy >> From Sergey.Bylokhov at oracle.com Wed Mar 19 18:36:39 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 19 Mar 2014 22:36:39 +0400 Subject: [9] Review request: new macro for conversion to jboolean In-Reply-To: <53273F9A.3080403@oracle.com> References: <53270E65.4070001@oracle.com> <53273F9A.3080403@oracle.com> Message-ID: <5329E3B7.7000000@oracle.com> Thanks Anthony! Can somebody from the core-libs team take a look? On 3/17/14 10:31 PM, Anthony Petrov wrote: > Personally, I'd call it to_jboolean(obj), but IS_TRUE(obj) sounds good > to me too. Either way, I'm fine with the fix. > > -- > best regards, > Anthony > > On 3/17/2014 7:01 PM, Sergey Bylokhov wrote: >> Hello. >> This review request is for the new macro, which simplify conversion to >> jboolean. It will be useful for fixing parfait warnings. >> >> We have a lot of places, where we cast some type to jboolean: >> >> BOOL = retVal; >> return (jboolean) retVal; >> >> WARNING: Expecting value of JNI primitive type jboolean: mismatched >> value retVal with size 32 bits, retVal used for conversion to int8 in >> return >> >> >> +++ b/src/share/native/common/jni_util.h Mon Mar 17 18:28:48 2014 >> +0400 >> @@ -277,6 +277,7 @@ >> >> #define IS_NULL(obj) ((obj) == NULL) >> #define JNU_IsNull(env,obj) ((obj) == NULL) >> +#define IS_TRUE(obj) ((obj) ? JNI_TRUE : JNI_FALSE) >> >> I am not sure about the name, probably someone have a better suggestion? >> >> The fix is for jdk9/dev. >> >> -- >> Best regards, Sergey. >> -- Best regards, Sergey. From mandy.chung at oracle.com Wed Mar 19 18:37:43 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 19 Mar 2014 11:37:43 -0700 Subject: Review request for 8035807: Convert use of sun.misc.BASE64Encoder/Decoder with java.util.Base64 Message-ID: <5329E3F7.6070007@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8035807 Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.00/ This patch converts the last 2 references to sun.misc.BASE64Encoder/Decoder from the jdk repo with java.util.Base64. We should also update the tests and I have filed JDK-8037873 for that. Thanks Mandy From vincent.x.ryan at oracle.com Wed Mar 19 19:03:37 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 19 Mar 2014 19:03:37 +0000 Subject: Review request for 8035807: Convert use of sun.misc.BASE64Encoder/Decoder with java.util.Base64 In-Reply-To: <5329E3F7.6070007@oracle.com> References: <5329E3F7.6070007@oracle.com> Message-ID: Fix looks fine. You just need to update the import statements in Obj.java On 19 Mar 2014, at 18:37, Mandy Chung wrote: > https://bugs.openjdk.java.net/browse/JDK-8035807 > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.00/ > > This patch converts the last 2 references to sun.misc.BASE64Encoder/Decoder from the jdk repo with java.util.Base64. We should also update the tests and I have filed JDK-8037873 for that. > > Thanks > Mandy From mandy.chung at oracle.com Wed Mar 19 19:06:00 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 19 Mar 2014 12:06:00 -0700 Subject: Review request for 8035807: Convert use of sun.misc.BASE64Encoder/Decoder with java.util.Base64 In-Reply-To: References: <5329E3F7.6070007@oracle.com> Message-ID: <5329EA98.6050608@oracle.com> On 3/19/2014 12:03 PM, Vincent Ryan wrote: > Fix looks fine. You just need to update the import statements in Obj.java Fixed. Not sure how it's missed in the webrev :) thanks Mandy > > On 19 Mar 2014, at 18:37, Mandy Chung wrote: > >> https://bugs.openjdk.java.net/browse/JDK-8035807 >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.00/ >> >> This patch converts the last 2 references to sun.misc.BASE64Encoder/Decoder from the jdk repo with java.util.Base64. We should also update the tests and I have filed JDK-8037873 for that. >> >> Thanks >> Mandy From vincent.x.ryan at oracle.com Wed Mar 19 19:11:55 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 19 Mar 2014 19:11:55 +0000 Subject: Review request for 8035807: Convert use of sun.misc.BASE64Encoder/Decoder with java.util.Base64 In-Reply-To: <5329EA98.6050608@oracle.com> References: <5329E3F7.6070007@oracle.com> <5329EA98.6050608@oracle.com> Message-ID: OK. Thanks. On 19 Mar 2014, at 19:06, Mandy Chung wrote: > On 3/19/2014 12:03 PM, Vincent Ryan wrote: >> Fix looks fine. You just need to update the import statements in Obj.java > > Fixed. Not sure how it's missed in the webrev :) > > thanks > Mandy > >> >> On 19 Mar 2014, at 18:37, Mandy Chung wrote: >> >>> https://bugs.openjdk.java.net/browse/JDK-8035807 >>> >>> Webrev at: >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.00/ >>> >>> This patch converts the last 2 references to sun.misc.BASE64Encoder/Decoder from the jdk repo with java.util.Base64. We should also update the tests and I have filed JDK-8037873 for that. >>> >>> Thanks >>> Mandy > From Alan.Bateman at oracle.com Wed Mar 19 19:26:12 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 19 Mar 2014 19:26:12 +0000 Subject: Review request for 8035807: Convert use of sun.misc.BASE64Encoder/Decoder with java.util.Base64 In-Reply-To: <5329E3F7.6070007@oracle.com> References: <5329E3F7.6070007@oracle.com> Message-ID: <5329EF54.8090702@oracle.com> On 19/03/2014 18:37, Mandy Chung wrote: > https://bugs.openjdk.java.net/browse/JDK-8035807 > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.00/ > > This patch converts the last 2 references to > sun.misc.BASE64Encoder/Decoder from the jdk repo with > java.util.Base64. We should also update the tests and I have filed > JDK-8037873 for that. Good to see more conversion to the new API, looks good to me. -Alan From xueming.shen at oracle.com Wed Mar 19 19:28:52 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 19 Mar 2014 12:28:52 -0700 Subject: Review request for 8035807: Convert use of sun.misc.BASE64Encoder/Decoder with java.util.Base64 In-Reply-To: <5329E3F7.6070007@oracle.com> References: <5329E3F7.6070007@oracle.com> Message-ID: <5329EFF4.9060008@oracle.com> On 03/19/2014 11:37 AM, Mandy Chung wrote: > https://bugs.openjdk.java.net/browse/JDK-8035807 > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.00/ > > This patch converts the last 2 references to sun.misc.BASE64Encoder/Decoder from the jdk repo with java.util.Base64. We should also update the tests and I have filed JDK-8037873 for that. > > Thanks > Mandy The sun.misc.BASE64En/Decoder is MIME type, so it outputs the \r\n per 76 characters during encoding, and ignores/skip \r or \n when decoding. The new Base64.getEncoder/Decoder() returns the "basic" Base64 coder, which it never inserts line separator when output, and throws exception for any non-base64- alphabet character, including \r and \n. The only disadvantage/incompatibility (j.u.Base64.getMimeDecoer() vs sun.misc.BASE64Decoder) of switching to j.u.Base64 MIME type en/decoder is that the Base64 Mime decoder ignores/skips any non-base64-alphabet (including \r and \n), while sun.misc.BASE64Decoder appears to simply use the init value "-1" for any non-base64-alphabet character for decoding. I'm not familiar with the use scenario of ldap's Obj class, so I'm not sure if it matters (if it ever outputs/inputs > 76 character data, or even it does,if the difference matters). Btw, except getMimeEncoder(int ...) all other Base64.getXXXEn/Decoder() returns singleton, so the de/encoder cache might not be necessary. -Sherman From jeremymanson at google.com Wed Mar 19 19:45:47 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 19 Mar 2014 12:45:47 -0700 Subject: StringBuilder version of java.util.regex.Matcher.append* In-Reply-To: <5329DD62.1070907@oracle.com> References: <5329DD62.1070907@oracle.com> Message-ID: There aren't really many design points that occur to me here, so I'd be interested to hear what the problems are: - Suppress the IOE. Make users call a method to get the exception out. This seems way too fragile to me (no one is going to remember to do that), but hey, someone decided it was the right thing to do for Formatter. - Don't suppress the IOE. Make new variants of this method that throw IOE. In this case, you probably want to keep the StringBuffer/Builder variants around, so that users don't have to insert unnecessary catches into their code (I can imagine the agonized screaming now). The second case seems much stronger to me, and in that case, we want this patch. Jeremy On Wed, Mar 19, 2014 at 11:09 AM, Xueming Shen wrote: > Similar suggestion has been on the to-do list for a while. There were > discussion back > then that it might be interesting to add the more general interface > Appendable... > The issue was how to deal with the IOE declared by the Appendable methods > then. > > If the appendable is not going to happen, then it is definitely worth > adding the StringBuilder > for better performance. > > -Sherman > > > > On 03/19/2014 10:51 AM, Jeremy Manson wrote: > >> I'm told that the diff didn't make it. I've put it in a Google drive >> folder... >> >> https://drive.google.com/file/d/0B_GaXa6O4K5LY3Y0aHpranM3aEU/ >> edit?usp=sharing >> >> Jeremy >> >> >> On Wed, Mar 19, 2014 at 10:41 AM, Jeremy Manson> >wrote: >> >> Hi folks, >>> >>> We've had this internally for a while, and I keep meaning to bring it up >>> here. The Matcher class has a few public methods that take >>> StringBuffers, >>> and we've found it useful to add similar versions that take >>> StringBuilders. >>> >>> It has two benefits: >>> >>> - Users don't have to convert from one to the other when they want to use >>> the method in question. The symmetry is nice. >>> >>> - The StringBuilder variants are faster (if lock optimizations don't kick >>> in, which happens in the interpreter and the client compiler). For >>> interpreted / client-compiled code, we saw something like a 25% speedup >>> on >>> String.replaceAll(), which calls into this code. >>> >>> Any interest? Diff attached. >>> >>> Jeremy >>> >>> > From mike.duigou at oracle.com Wed Mar 19 19:49:14 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 19 Mar 2014 12:49:14 -0700 Subject: [9] Review request: new macro for conversion to jboolean In-Reply-To: <5329E3B7.7000000@oracle.com> References: <53270E65.4070001@oracle.com> <53273F9A.3080403@oracle.com> <5329E3B7.7000000@oracle.com> Message-ID: Definitely a useful macro. I too would prefer a name like TO_JBOOLEAN since it reveals the result type. Also all uppercase to identify it as a macro. If we are paranoid and want to reduce the chance of a name collision then JNU_TO_JBOOLEAN perhaps. I would also define the macro as: #define JNU_TO_JBOOLEAN(obj) (jboolean) ((obj) ? JNI_TRUE : JNI_FALSE) so that the type of the result is explicit. Unfortunately jni.h doesn't define JNI_TRUE or false with a cast to jboolean as they probably should. Mike On Mar 19 2014, at 11:36 , Sergey Bylokhov wrote: > Thanks Anthony! > > Can somebody from the core-libs team take a look? > > On 3/17/14 10:31 PM, Anthony Petrov wrote: >> Personally, I'd call it to_jboolean(obj), but IS_TRUE(obj) sounds good to me too. Either way, I'm fine with the fix. >> >> -- >> best regards, >> Anthony >> >> On 3/17/2014 7:01 PM, Sergey Bylokhov wrote: >>> Hello. >>> This review request is for the new macro, which simplify conversion to >>> jboolean. It will be useful for fixing parfait warnings. >>> >>> We have a lot of places, where we cast some type to jboolean: >>> >>> BOOL = retVal; >>> return (jboolean) retVal; >>> >>> WARNING: Expecting value of JNI primitive type jboolean: mismatched >>> value retVal with size 32 bits, retVal used for conversion to int8 in return >>> >>> >>> +++ b/src/share/native/common/jni_util.h Mon Mar 17 18:28:48 2014 +0400 >>> @@ -277,6 +277,7 @@ >>> >>> #define IS_NULL(obj) ((obj) == NULL) >>> #define JNU_IsNull(env,obj) ((obj) == NULL) >>> +#define IS_TRUE(obj) ((obj) ? JNI_TRUE : JNI_FALSE) >>> >>> I am not sure about the name, probably someone have a better suggestion? >>> >>> The fix is for jdk9/dev. >>> >>> -- >>> Best regards, Sergey. >>> > > > -- > Best regards, Sergey. > From philip.race at oracle.com Wed Mar 19 20:05:56 2014 From: philip.race at oracle.com (Phil Race) Date: Wed, 19 Mar 2014 13:05:56 -0700 Subject: [9] Review request: new macro for conversion to jboolean In-Reply-To: References: <53270E65.4070001@oracle.com> <53273F9A.3080403@oracle.com> <5329E3B7.7000000@oracle.com> Message-ID: <5329F8A4.6030908@oracle.com> I think having it start with "JNU_" is a good suggestion. I've been wondering over the last week or so if it would not have been better to have CHECK_NULL called JNU_CHECK_NULL to reduce collision chances and to make it clearer where it comes from .. -phil. On 3/19/2014 12:49 PM, Mike Duigou wrote: > Definitely a useful macro. > > I too would prefer a name like TO_JBOOLEAN since it reveals the result type. Also all uppercase to identify it as a macro. If we are paranoid and want to reduce the chance of a name collision then JNU_TO_JBOOLEAN perhaps. > > I would also define the macro as: > > #define JNU_TO_JBOOLEAN(obj) (jboolean) ((obj) ? JNI_TRUE : JNI_FALSE) > > so that the type of the result is explicit. Unfortunately jni.h doesn't define JNI_TRUE or false with a cast to jboolean as they probably should. > > Mike > > On Mar 19 2014, at 11:36 , Sergey Bylokhov wrote: > >> Thanks Anthony! >> >> Can somebody from the core-libs team take a look? >> >> On 3/17/14 10:31 PM, Anthony Petrov wrote: >>> Personally, I'd call it to_jboolean(obj), but IS_TRUE(obj) sounds good to me too. Either way, I'm fine with the fix. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 3/17/2014 7:01 PM, Sergey Bylokhov wrote: >>>> Hello. >>>> This review request is for the new macro, which simplify conversion to >>>> jboolean. It will be useful for fixing parfait warnings. >>>> >>>> We have a lot of places, where we cast some type to jboolean: >>>> >>>> BOOL = retVal; >>>> return (jboolean) retVal; >>>> >>>> WARNING: Expecting value of JNI primitive type jboolean: mismatched >>>> value retVal with size 32 bits, retVal used for conversion to int8 in return >>>> >>>> >>>> +++ b/src/share/native/common/jni_util.h Mon Mar 17 18:28:48 2014 +0400 >>>> @@ -277,6 +277,7 @@ >>>> >>>> #define IS_NULL(obj) ((obj) == NULL) >>>> #define JNU_IsNull(env,obj) ((obj) == NULL) >>>> +#define IS_TRUE(obj) ((obj) ? JNI_TRUE : JNI_FALSE) >>>> >>>> I am not sure about the name, probably someone have a better suggestion? >>>> >>>> The fix is for jdk9/dev. >>>> >>>> -- >>>> Best regards, Sergey. >>>> >> >> -- >> Best regards, Sergey. >> From philip.race at oracle.com Wed Mar 19 20:08:26 2014 From: philip.race at oracle.com (Phil Race) Date: Wed, 19 Mar 2014 13:08:26 -0700 Subject: [9] Review request: new macro for conversion to jboolean In-Reply-To: <5329F8A4.6030908@oracle.com> References: <53270E65.4070001@oracle.com> <53273F9A.3080403@oracle.com> <5329E3B7.7000000@oracle.com> <5329F8A4.6030908@oracle.com> Message-ID: <5329F93A.2010205@oracle.com> PS .. so maybe whilst you are touching this file you could do #define JNU_CHECK_NULL CHECK_NULL #define JNU_CHECK_NULL_RETURN CHECK_NULL_RETURN so we could migrate to these (clearer) ones -phil. On 3/19/2014 1:05 PM, Phil Race wrote: > I think having it start with "JNU_" is a good suggestion. > I've been wondering over the last week or so if it would not have been > better to have CHECK_NULL called JNU_CHECK_NULL to reduce collision > chances > and to make it clearer where it comes from .. > > -phil. > > On 3/19/2014 12:49 PM, Mike Duigou wrote: >> Definitely a useful macro. >> >> I too would prefer a name like TO_JBOOLEAN since it reveals the >> result type. Also all uppercase to identify it as a macro. If we are >> paranoid and want to reduce the chance of a name collision then >> JNU_TO_JBOOLEAN perhaps. >> >> I would also define the macro as: >> >> #define JNU_TO_JBOOLEAN(obj) (jboolean) ((obj) ? JNI_TRUE : JNI_FALSE) >> >> so that the type of the result is explicit. Unfortunately jni.h >> doesn't define JNI_TRUE or false with a cast to jboolean as they >> probably should. >> >> Mike >> >> On Mar 19 2014, at 11:36 , Sergey Bylokhov >> wrote: >> >>> Thanks Anthony! >>> >>> Can somebody from the core-libs team take a look? >>> >>> On 3/17/14 10:31 PM, Anthony Petrov wrote: >>>> Personally, I'd call it to_jboolean(obj), but IS_TRUE(obj) sounds >>>> good to me too. Either way, I'm fine with the fix. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 3/17/2014 7:01 PM, Sergey Bylokhov wrote: >>>>> Hello. >>>>> This review request is for the new macro, which simplify >>>>> conversion to >>>>> jboolean. It will be useful for fixing parfait warnings. >>>>> >>>>> We have a lot of places, where we cast some type to jboolean: >>>>> >>>>> BOOL = retVal; >>>>> return (jboolean) retVal; >>>>> >>>>> WARNING: Expecting value of JNI primitive type jboolean: mismatched >>>>> value retVal with size 32 bits, retVal used for conversion to int8 >>>>> in return >>>>> >>>>> >>>>> +++ b/src/share/native/common/jni_util.h Mon Mar 17 18:28:48 >>>>> 2014 +0400 >>>>> @@ -277,6 +277,7 @@ >>>>> >>>>> #define IS_NULL(obj) ((obj) == NULL) >>>>> #define JNU_IsNull(env,obj) ((obj) == NULL) >>>>> +#define IS_TRUE(obj) ((obj) ? JNI_TRUE : JNI_FALSE) >>>>> >>>>> I am not sure about the name, probably someone have a better >>>>> suggestion? >>>>> >>>>> The fix is for jdk9/dev. >>>>> >>>>> -- >>>>> Best regards, Sergey. >>>>> >>> >>> -- >>> Best regards, Sergey. >>> > From roger.riggs at oracle.com Wed Mar 19 20:07:58 2014 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 19 Mar 2014 16:07:58 -0400 Subject: [9] Review request: new macro for conversion to jboolean In-Reply-To: <5329F93A.2010205@oracle.com> References: <53270E65.4070001@oracle.com> <53273F9A.3080403@oracle.com> <5329E3B7.7000000@oracle.com> <5329F8A4.6030908@oracle.com> <5329F93A.2010205@oracle.com> Message-ID: <5329F91E.4050703@oracle.com> Hi, Well... When JNU_RETURN was added, there was a long discussion about NOT using JNU unless the JNI environment was an argument to the macro. So, the simple name is preferred. Roger On 3/19/2014 4:08 PM, Phil Race wrote: > PS .. so maybe whilst you are touching this file you could do > #define JNU_CHECK_NULL CHECK_NULL > #define JNU_CHECK_NULL_RETURN CHECK_NULL_RETURN > > so we could migrate to these (clearer) ones > > -phil. > > On 3/19/2014 1:05 PM, Phil Race wrote: >> I think having it start with "JNU_" is a good suggestion. >> I've been wondering over the last week or so if it would not have been >> better to have CHECK_NULL called JNU_CHECK_NULL to reduce collision >> chances >> and to make it clearer where it comes from .. >> >> -phil. >> >> On 3/19/2014 12:49 PM, Mike Duigou wrote: >>> Definitely a useful macro. >>> >>> I too would prefer a name like TO_JBOOLEAN since it reveals the >>> result type. Also all uppercase to identify it as a macro. If we are >>> paranoid and want to reduce the chance of a name collision then >>> JNU_TO_JBOOLEAN perhaps. >>> >>> I would also define the macro as: >>> >>> #define JNU_TO_JBOOLEAN(obj) (jboolean) ((obj) ? JNI_TRUE : JNI_FALSE) >>> >>> so that the type of the result is explicit. Unfortunately jni.h >>> doesn't define JNI_TRUE or false with a cast to jboolean as they >>> probably should. >>> >>> Mike >>> >>> On Mar 19 2014, at 11:36 , Sergey Bylokhov >>> wrote: >>> >>>> Thanks Anthony! >>>> >>>> Can somebody from the core-libs team take a look? >>>> >>>> On 3/17/14 10:31 PM, Anthony Petrov wrote: >>>>> Personally, I'd call it to_jboolean(obj), but IS_TRUE(obj) sounds >>>>> good to me too. Either way, I'm fine with the fix. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 3/17/2014 7:01 PM, Sergey Bylokhov wrote: >>>>>> Hello. >>>>>> This review request is for the new macro, which simplify >>>>>> conversion to >>>>>> jboolean. It will be useful for fixing parfait warnings. >>>>>> >>>>>> We have a lot of places, where we cast some type to jboolean: >>>>>> >>>>>> BOOL = retVal; >>>>>> return (jboolean) retVal; >>>>>> >>>>>> WARNING: Expecting value of JNI primitive type jboolean: mismatched >>>>>> value retVal with size 32 bits, retVal used for conversion to >>>>>> int8 in return >>>>>> >>>>>> >>>>>> +++ b/src/share/native/common/jni_util.h Mon Mar 17 18:28:48 >>>>>> 2014 +0400 >>>>>> @@ -277,6 +277,7 @@ >>>>>> >>>>>> #define IS_NULL(obj) ((obj) == NULL) >>>>>> #define JNU_IsNull(env,obj) ((obj) == NULL) >>>>>> +#define IS_TRUE(obj) ((obj) ? JNI_TRUE : JNI_FALSE) >>>>>> >>>>>> I am not sure about the name, probably someone have a better >>>>>> suggestion? >>>>>> >>>>>> The fix is for jdk9/dev. >>>>>> >>>>>> -- >>>>>> Best regards, Sergey. >>>>>> >>>> >>>> -- >>>> Best regards, Sergey. >>>> >> > From mandy.chung at oracle.com Wed Mar 19 20:33:28 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 19 Mar 2014 13:33:28 -0700 Subject: Review request for 8035807: Convert use of sun.misc.BASE64Encoder/Decoder with java.util.Base64 In-Reply-To: <5329EFF4.9060008@oracle.com> References: <5329E3F7.6070007@oracle.com> <5329EFF4.9060008@oracle.com> Message-ID: <5329FF18.3070201@oracle.com> On 3/19/2014 12:28 PM, Xueming Shen wrote: > On 03/19/2014 11:37 AM, Mandy Chung wrote: >> https://bugs.openjdk.java.net/browse/JDK-8035807 >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.00/ >> >> This patch converts the last 2 references to >> sun.misc.BASE64Encoder/Decoder from the jdk repo with >> java.util.Base64. We should also update the tests and I have filed >> JDK-8037873 for that. >> >> Thanks >> Mandy > > The sun.misc.BASE64En/Decoder is MIME type, so it outputs the \r\n per 76 > characters during encoding, and ignores/skip \r or \n when decoding. > The new > Base64.getEncoder/Decoder() returns the "basic" Base64 coder, which it > never > inserts line separator when output, and throws exception for any > non-base64- > alphabet character, including \r and \n. > > The only disadvantage/incompatibility (j.u.Base64.getMimeDecoer() vs > sun.misc.BASE64Decoder) of switching to j.u.Base64 MIME type en/decoder > is that the Base64 Mime decoder ignores/skips any non-base64-alphabet > (including \r and \n), while sun.misc.BASE64Decoder appears to simply > use the init value "-1" for any non-base64-alphabet character for > decoding. > > I'm not familiar with the use scenario of ldap's Obj class, so I'm not > sure if > it matters (if it ever outputs/inputs > 76 character data, or even it > does,if > the difference matters). > Thanks Sherman. I believe both cases don't have the 76 characters constraint although it uses MIME type encoder/decoder previously unless Vinnie and Alan say otherwise. > Btw, except getMimeEncoder(int ...) all other Base64.getXXXEn/Decoder() > returns singleton, so the de/encoder cache might not be necessary. Thanks. It calls encode/decode in a loop and so I think keeping a local variable to avoid getting it multiple time seems reasonable. Mandy From Alan.Bateman at oracle.com Wed Mar 19 21:23:02 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 19 Mar 2014 21:23:02 +0000 Subject: Review request for 8035807: Convert use of sun.misc.BASE64Encoder/Decoder with java.util.Base64 In-Reply-To: <5329FF18.3070201@oracle.com> References: <5329E3F7.6070007@oracle.com> <5329EFF4.9060008@oracle.com> <5329FF18.3070201@oracle.com> Message-ID: <532A0AB6.8060303@oracle.com> On 19/03/2014 20:33, Mandy Chung wrote: > : > > I believe both cases don't have the 76 characters constraint although > it uses MIME type encoder/decoder previously unless Vinnie and Alan > say otherwise. Sherman makes a good point and we should double check the LDAP spec to see which base64 scheme this is (I suspect it is MIME). Vinnie will likely know if it's not often from the RFC. -Alan. From Alan.Bateman at oracle.com Wed Mar 19 21:39:02 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 19 Mar 2014 21:39:02 +0000 Subject: RFR [6943190] TEST_BUG: java/lang/Runtime/exec/ExecWithInput.java hardcodes path to cat In-Reply-To: <5329D534.3030509@oracle.com> References: <530B80CF.9090403@oracle.com> <530E5D0F.90409@oracle.com> <530E6877.5050504@oracle.com> <530F06A3.1030107@oracle.com> <5323352C.4080007@oracle.com> <5325D6E6.8090208@oracle.com> <5326A961.5030803@oracle.com> <5326BB2D.6060201@oracle.com> <53275F00.5070706@oracle.com> <5329BCAF.3040106@oracle.com> <5329D534.3030509@oracle.com> Message-ID: <532A0E76.3040906@oracle.com> On 19/03/2014 17:34, Ivan Gerasimov wrote: > > Here's the (final?) webrev: > http://cr.openjdk.java.net/~igerasim/6943190/5/webrev/ This looks okay although I would prefer for a number of these tests to fail if the command is not found (otherwise it is will just hide issues). We can create another bug for this if you'd prefer. -Alan. From brian.burkhalter at oracle.com Wed Mar 19 22:01:43 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 19 Mar 2014 15:01:43 -0700 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <531EC6BF.4050701@oracle.com> <4742E0AD-8D87-4F22-8F23-779BDF3A58FE@oracle.com> <5320240C.60304@gmail.com> <5322DC66.5070003@gmail.com> Message-ID: <96B8A54B-77FC-4973-8A92-2344A1621F43@oracle.com> On Mar 14, 2014, at 7:17 AM, Brian Burkhalter wrote: > On Mar 14, 2014, at 3:39 AM, Peter Levart wrote: > >> But in general it would be better to just use "ThreadLocalRandom.current()" everywhere you use "rnd" variable. This is precisely it's purpose - a random number generator that is never contended. The overhead of ThreadLocalRandom.current() call is hardly measurable by itself. > > I'll update that and re-run some of the benchmarks later. Following up on the content above and this earlier message in the thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-March/025676.html I have posted a revised patch (NB: I know lines 2897-2906 should be elsewhere) http://cr.openjdk.java.net/~bpb/6375303/webrev.01/ and updated benchmark source (using only ThreadLocalRandom.current()) http://cr.openjdk.java.net/~bpb/6375303/Bench6375303.java and updated benchmark results for three different variations http://cr.openjdk.java.net/~bpb/6375303/6375303-bench-2.html This version of toString() is from Peter and dispenses with the volatile qualifier on stringCache. At least on my system, there is no statistically significant micro-performance difference among the three versions tested, viz., baseline, toString() change only, toString() change plus other cleanup. Any comments appreciated. Thanks, Brian From Ulf.Zibis at CoSoCo.de Wed Mar 19 22:02:47 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Wed, 19 Mar 2014 23:02:47 +0100 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <5329531F.9070109@oracle.com> References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> <5322EB0F.8010900@cs.oswego.edu> <5324A8B6.8010009@oracle.com> <532627B5.8020507@oracle.com> <5328903A.6070104@oracle.com> <5328C4CA.6090906@CoSoCo.de> <5329531F.9070109@oracle.com> Message-ID: <532A1407.20300@CoSoCo.de> Am 19.03.2014 09:19, schrieb Ivan Gerasimov: > Thank you Ulf! > > On 19.03.2014 2:12, Ulf Zibis wrote: >> Am 18.03.2014 19:28, schrieb Ivan Gerasimov: >>> >>> Assuming this last iteration is OK, should the next step be a CCC request? >> >> Do you mean? : >> /* >> * ... >> + * It is assumed that fromIndex <= toIndex, otherwise the behaviour of this method is >> undefined. >> * ... >> - * toIndex < fromIndex}) >> * ... >> */ >> protected void removeRange(int fromIndex, int toIndex) { >> ... >> > > The (fromIndex > toIndex) condition is checked now, so the behavior of the method is defined - it > throws an exception. Because Martin stated some days ago, that it normally should not occur, that removeRange is invoked with toIndex < fromIndex, and checking this again unnecessarily decreases performance a little, I was hoping, your "next CCC step" would be to drop this check. -Ulf From martinrb at google.com Wed Mar 19 22:32:41 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 19 Mar 2014 15:32:41 -0700 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <532A1407.20300@CoSoCo.de> References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> <5322EB0F.8010900@cs.oswego.edu> <5324A8B6.8010009@oracle.com> <532627B5.8020507@oracle.com> <5328903A.6070104@oracle.com> <5328C4CA.6090906@CoSoCo.de> <5329531F.9070109@oracle.com> <532A1407.20300@CoSoCo.de> Message-ID: No one is as performance obsessed as Ulf. In this case, because it's specified to throw, and because it's a bulk operation, let's try hard not to care about the wasted nanoseconds. On Wed, Mar 19, 2014 at 3:02 PM, Ulf Zibis wrote: > Am 19.03.2014 09:19, schrieb Ivan Gerasimov: > > Thank you Ulf! >> >> On 19.03.2014 2:12, Ulf Zibis wrote: >> >>> Am 18.03.2014 19:28, schrieb Ivan Gerasimov: >>> >>>> >>>> Assuming this last iteration is OK, should the next step be a CCC >>>> request? >>>> >>> >>> Do you mean? : >>> /* >>> * ... >>> + * It is assumed that fromIndex <= toIndex, otherwise the behaviour >>> of this method is undefined. >>> * ... >>> - * toIndex < fromIndex}) >>> * ... >>> */ >>> protected void removeRange(int fromIndex, int toIndex) { >>> ... >>> >>> >> The (fromIndex > toIndex) condition is checked now, so the behavior of >> the method is defined - it throws an exception. >> > > Because Martin stated some days ago, that it normally should not occur, > that removeRange is invoked with toIndex < fromIndex, and checking this > again unnecessarily decreases performance a little, I was hoping, your > "next CCC step" would be to drop this check. > > -Ulf > > From Ulf.Zibis at CoSoCo.de Wed Mar 19 22:37:32 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Wed, 19 Mar 2014 23:37:32 +0100 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> <5322EB0F.8010900@cs.oswego.edu> <5324A8B6.8010009@oracle.com> <532627B5.8020507@oracle.com> <5328903A.6070104@oracle.com> <5328C4CA.6090906@CoSoCo.de> <5329531F.9070109@oracle.com> <532A1407.20300@CoSoCo.de> Message-ID: <532A1C2C.1050601@CoSoCo.de> Am 19.03.2014 23:32, schrieb Martin Buchholz: > No one is as performance obsessed as Ulf. :-D :-D :-D From david.x.li at oracle.com Wed Mar 19 23:10:14 2014 From: david.x.li at oracle.com (David Li) Date: Wed, 19 Mar 2014 16:10:14 -0700 Subject: RFR (JAXP): 8035577: Xerces Update: impl/xpath/regex/RangeToken.java Message-ID: <532A23D6.2070503@oracle.com> Hi, This is an update from Xerces for file impl/xpath/regex/TokenRange.java. For details, please refer to: https://bugs.openjdk.java.net/browse/JDK-8035577. Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035577/webrev/ Existing tests: JAXP SQE and unit tests passed. Test cases added for typo fix in RangeToken.intersectRanges. Code also updated to fix a bug where regular expression intersection returns incorrect value when first range ends later than second range. Example below. Test cases have been added to cover any scenarios that the code changes affect. new RegularExpression("(?[b-d]&[a-r])"); -> returns [b-d] (Correct) new RegularExpression("(?[a-r]&[b-d])"); -> returns [b-de-r] (Incorrect) Thanks, David P.S. Notes on bug fixes. 1) Line 404 removal of while loop. This fixes a new bug where incorrect results are given when first range ends later than second range. In the old code we got (?[a-r]&[b-d]) -> returns [b-de-r] By removing the while loop, we get [b-d]. This while loop looks like a copy-paste error from subtractRanges. In subtractRanges we need to keep the leftover portion from the first range, but this does not apply to intersection. 2) Line 388, addition of src2 += 2; This code change affects anything of the form (?[a-r]&[b-eg-j]). The code execution is diagrammed below. o------------o (src1) o--o o--o (src2) For the first match we get o------------o (src1) o--o (src2) Next we want to run src2+=2 to get the second pair of endpoints (since the first two endpoints are already used). Notice how src1begin has been updated to this.ranges[src1] = src2end+1, which is directly from the code. o------o (src1) o--o (src2) The src2+=2 statement was left out of the old code, and is added in this webrev. If we leave out the src2+=2 at line 388, on the next iteration of the large while loop we will reach case "} else if (src2end < src1begin) {" which also executes "src2+=2". This means the correct final result is generated, but on a later loop. We want to add the new code because it's better to have all associated variable updated in the sameloop. In addition, all the other conditions have similar src1 or src2 updates. From mike.duigou at oracle.com Wed Mar 19 23:32:05 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 19 Mar 2014 16:32:05 -0700 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: <96B8A54B-77FC-4973-8A92-2344A1621F43@oracle.com> References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <531EC6BF.4050701@oracle.com> <4742E0AD-8D87-4F22-8F23-779BDF3A58FE@oracle.com> <5320240C.60304@gmail.com> <5322DC66.5070003@gmail.com> <96B8A54B-77FC-4973-8A92-2344A1621F43@oracle.com> Message-ID: <31604636-122D-4861-9362-DCC212C664CD@oracle.com> I On Mar 19 2014, at 15:01 , Brian Burkhalter wrote: > > On Mar 14, 2014, at 7:17 AM, Brian Burkhalter wrote: > >> On Mar 14, 2014, at 3:39 AM, Peter Levart wrote: >> >>> But in general it would be better to just use "ThreadLocalRandom.current()" everywhere you use "rnd" variable. This is precisely it's purpose - a random number generator that is never contended. The overhead of ThreadLocalRandom.current() call is hardly measurable by itself. >> >> I'll update that and re-run some of the benchmarks later. > > Following up on the content above and this earlier message in the thread: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-March/025676.html > > I have posted a revised patch (NB: I know lines 2897-2906 should be elsewhere) > > http://cr.openjdk.java.net/~bpb/6375303/webrev.01/ > > and updated benchmark source (using only ThreadLocalRandom.current()) > > http://cr.openjdk.java.net/~bpb/6375303/Bench6375303.java > > and updated benchmark results for three different variations > > http://cr.openjdk.java.net/~bpb/6375303/6375303-bench-2.html > > This version of toString() is from Peter and dispenses with the volatile qualifier on stringCache. At least on my system, there is no statistically significant micro-performance difference among the three versions tested, viz., baseline, toString() change only, toString() change plus other cleanup. Since the Unsafe.getObjectVolatile() allows use of volatile semantics without having to declare the field volatile I think this is a better idiom than what I had previously suggested. Hopefully this is a pattern we can use elsewhere. Are the java.util.concurrent.atomic imports still needed? I have not reviewed the other changes. Mike From peter.levart at gmail.com Wed Mar 19 23:32:26 2014 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 20 Mar 2014 00:32:26 +0100 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: <96B8A54B-77FC-4973-8A92-2344A1621F43@oracle.com> References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <531EC6BF.4050701@oracle.com> <4742E0AD-8D87-4F22-8F23-779BDF3A58FE@oracle.com> <5320240C.60304@gmail.com> <5322DC66.5070003@gmail.com> <96B8A54B-77FC-4973-8A92-2344A1621F43@oracle.com> Message-ID: <532A290A.7090307@gmail.com> On 03/19/2014 11:01 PM, Brian Burkhalter wrote: > > On Mar 14, 2014, at 7:17 AM, Brian Burkhalter > > wrote: > >> On Mar 14, 2014, at 3:39 AM, Peter Levart wrote: >> >>> But in general it would be better to just use >>> "ThreadLocalRandom.current()" everywhere you use "rnd" variable. >>> This is precisely it's purpose - a random number generator that is >>> never contended. The overhead of ThreadLocalRandom.current() call is >>> hardly measurable by itself. >> >> I'll update that and re-run some of the benchmarks later. > > Following up on the content above and this earlier message in the thread: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-March/025676.html > > I have posted a revised patch (NB: I know lines 2897-2906 should be > elsewhere) > > http://cr.openjdk.java.net/~bpb/6375303/webrev.01/ > > > and updated benchmark source (using only ThreadLocalRandom.current()) > > http://cr.openjdk.java.net/~bpb/6375303/Bench6375303.java > > > and updated benchmark results for three different variations > > http://cr.openjdk.java.net/~bpb/6375303/6375303-bench-2.html > > > This version of toString() is from Peter and dispenses with the > volatile qualifier on stringCache. At least on my system, there is no > statistically significant micro-performance difference among the three > versions tested, viz., baseline, toString() change only, toString() > change plus other cleanup. > > Any comments appreciated. > > Thanks, > > Brian Hi Brian, Here's my promised run of your latest webrev and microbenchmark on ARM platform (Raspberry Pi) with just released JDK 8 for ARM (-client compiler, since -server does not work on Raspberry Pi): org.openjdk.jmh.Main parameters: ".*" -i 10 -r 5 -wi 5 -w 1 -f 1 -t 1 --- Baseline, 1-thread --- Benchmark Mode Samples Mean Mean error Units o.s.Bench6375303.testFirstToString avgt 10 330618.266 2211.637 ns/op o.s.Bench6375303.testToString avgt 10 80.546 0.134 ns/op --- Proposed webrev, 1-thread --- Benchmark Mode Samples Mean Mean error Units o.s.Bench6375303.testFirstToString avgt 10 326588.284 1714.892 ns/op o.s.Bench6375303.testToString avgt 10 102.582 0.295 ns/op --- Previous variant with volatile stringCache field, 1-thread --- Benchmark Mode Samples Mean Mean error Units o.s.Bench6375303.testFirstToString avgt 10 328795.783 2508.173 ns/op o.s.Bench6375303.testToString avgt 10 105.741 0.316 ns/op So both variants seem to be more or less the same but slower than baseline. Why would they be slower? Answer: they have more bytecodes. If I run with following JVM options: -XX:+UnlockDiagnosticVMOptions -XX:MaxInlineSize=100 (and only the "testToString" benchmark), I get: --- Baseline, 1-thread --- Benchmark Mode Samples Mean Mean error Units o.s.Bench6375303.testToString avgt 10 80.839 0.742 ns/op --- Proposed webrev, 1-thread --- Benchmark Mode Samples Mean Mean error Units o.s.Bench6375303.testToString avgt 10 80.851 0.771 ns/op --- Previous variant with volatile stringCache field, 1-thread --- Benchmark Mode Samples Mean Mean error Units o.s.Bench6375303.testToString avgt 10 80.834 0.749 ns/op So the solution is to "reduce number of bytecodes in toString()". For example, the following: public String toString() { String sc = stringCache; if (sc == null) { sc = toStringSlow(); } return sc; } private String toStringSlow() { String sc = (String) U.getObjectVolatile(this, STRING_CACHE_OFFSET); if (sc == null) { sc = layoutChars(true); if (!U.compareAndSwapObject(this, STRING_CACHE_OFFSET, null, sc)) { sc = (String) U.getObjectVolatile(this, STRING_CACHE_OFFSET); } } return sc; } ...gives the good results even without special JVM options: Benchmark Mode Samples Mean Mean error Units o.s.Bench6375303.testToString avgt 10 80.925 0.313 ns/op Regards, Peter From brian.burkhalter at oracle.com Wed Mar 19 23:34:41 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 19 Mar 2014 16:34:41 -0700 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: <31604636-122D-4861-9362-DCC212C664CD@oracle.com> References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <531EC6BF.4050701@oracle.com> <4742E0AD-8D87-4F22-8F23-779BDF3A58FE@oracle.com> <5320240C.60304@gmail.com> <5322DC66.5070003@gmail.com> <96B8A54B-77FC-4973-8A92-2344A1621F43@oracle.com> <31604636-122D-4861-9362-DCC212C664CD@oracle.com> Message-ID: <67712CB4-2CFF-4E29-AF84-BF300C382B3C@oracle.com> On Mar 19, 2014, at 4:32 PM, Mike Duigou wrote: > Since the Unsafe.getObjectVolatile() allows use of volatile semantics without having to declare the field volatile I think this is a better idiom than what I had previously suggested. Hopefully this is a pattern we can use elsewhere. > > Are the java.util.concurrent.atomic imports still needed? No they are not. I can remove them (and move the code at lines 2897-2906 to following coding conventions) if this is eventually approved. > I have not reviewed the other changes. Aside from toString() they are mostly straightforward cleanup. Thanks, Brian From brian.burkhalter at oracle.com Wed Mar 19 23:41:05 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 19 Mar 2014 16:41:05 -0700 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: <532A290A.7090307@gmail.com> References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <531EC6BF.4050701@oracle.com> <4742E0AD-8D87-4F22-8F23-779BDF3A58FE@oracle.com> <5320240C.60304@gmail.com> <5322DC66.5070003@gmail.com> <96B8A54B-77FC-4973-8A92-2344A1621F43@oracle.com> <532A290A.7090307@gmail.com> Message-ID: <1110EF84-EF2B-45C0-A61E-1C4397749BED@oracle.com> Hi Peter, On Mar 19, 2014, at 4:32 PM, Peter Levart wrote: > So the solution is to "reduce number of bytecodes in toString()". For example, the following: > > > public String toString() { > String sc = stringCache; > if (sc == null) { > sc = toStringSlow(); > } > return sc; > } > > private String toStringSlow() { > String sc = (String) U.getObjectVolatile(this, STRING_CACHE_OFFSET); > if (sc == null) { > sc = layoutChars(true); > if (!U.compareAndSwapObject(this, STRING_CACHE_OFFSET, null, sc)) { > sc = (String) U.getObjectVolatile(this, STRING_CACHE_OFFSET); > } > } > return sc; > } > > > ...gives the good results even without special JVM options: > > Benchmark Mode Samples Mean Mean error Units > o.s.Bench6375303.testToString avgt 10 80.925 0.313 ns/op That?s great! I can re-try that version on my system for comparison. Thanks, Brian From Sergey.Bylokhov at oracle.com Wed Mar 19 23:43:10 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 20 Mar 2014 03:43:10 +0400 Subject: [9] Review request: new macro for conversion to jboolean In-Reply-To: <5329F91E.4050703@oracle.com> References: <53270E65.4070001@oracle.com> <53273F9A.3080403@oracle.com> <5329E3B7.7000000@oracle.com> <5329F8A4.6030908@oracle.com> <5329F93A.2010205@oracle.com> <5329F91E.4050703@oracle.com> Message-ID: <532A2B8E.9040707@oracle.com> Thanks. So if nobody objects, the final version will be: #define IS_NULL(obj) ((obj) == NULL) #define JNU_IsNull(env,obj) ((obj) == NULL) +#define TO_JBOOLEAN(obj) (jboolean) ((obj) ? JNI_TRUE : JNI_FALSE) On 3/20/14 12:07 AM, roger riggs wrote: > Hi, > > Well... When JNU_RETURN was added, there was a long discussion about > NOT using JNU unless the JNI environment was an argument to the macro. > > So, the simple name is preferred. > > Roger > > On 3/19/2014 4:08 PM, Phil Race wrote: >> PS .. so maybe whilst you are touching this file you could do >> #define JNU_CHECK_NULL CHECK_NULL >> #define JNU_CHECK_NULL_RETURN CHECK_NULL_RETURN >> >> so we could migrate to these (clearer) ones >> >> -phil. >> >> On 3/19/2014 1:05 PM, Phil Race wrote: >>> I think having it start with "JNU_" is a good suggestion. >>> I've been wondering over the last week or so if it would not have been >>> better to have CHECK_NULL called JNU_CHECK_NULL to reduce collision >>> chances >>> and to make it clearer where it comes from .. >>> >>> -phil. >>> >>> On 3/19/2014 12:49 PM, Mike Duigou wrote: >>>> Definitely a useful macro. >>>> >>>> I too would prefer a name like TO_JBOOLEAN since it reveals the >>>> result type. Also all uppercase to identify it as a macro. If we >>>> are paranoid and want to reduce the chance of a name collision then >>>> JNU_TO_JBOOLEAN perhaps. >>>> >>>> I would also define the macro as: >>>> >>>> #define JNU_TO_JBOOLEAN(obj) (jboolean) ((obj) ? JNI_TRUE : JNI_FALSE) >>>> >>>> so that the type of the result is explicit. Unfortunately jni.h >>>> doesn't define JNI_TRUE or false with a cast to jboolean as they >>>> probably should. >>>> >>>> Mike >>>> >>>> On Mar 19 2014, at 11:36 , Sergey Bylokhov >>>> wrote: >>>> >>>>> Thanks Anthony! >>>>> >>>>> Can somebody from the core-libs team take a look? >>>>> >>>>> On 3/17/14 10:31 PM, Anthony Petrov wrote: >>>>>> Personally, I'd call it to_jboolean(obj), but IS_TRUE(obj) sounds >>>>>> good to me too. Either way, I'm fine with the fix. >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 3/17/2014 7:01 PM, Sergey Bylokhov wrote: >>>>>>> Hello. >>>>>>> This review request is for the new macro, which simplify >>>>>>> conversion to >>>>>>> jboolean. It will be useful for fixing parfait warnings. >>>>>>> >>>>>>> We have a lot of places, where we cast some type to jboolean: >>>>>>> >>>>>>> BOOL = retVal; >>>>>>> return (jboolean) retVal; >>>>>>> >>>>>>> WARNING: Expecting value of JNI primitive type jboolean: mismatched >>>>>>> value retVal with size 32 bits, retVal used for conversion to >>>>>>> int8 in return >>>>>>> >>>>>>> >>>>>>> +++ b/src/share/native/common/jni_util.h Mon Mar 17 18:28:48 >>>>>>> 2014 +0400 >>>>>>> @@ -277,6 +277,7 @@ >>>>>>> >>>>>>> #define IS_NULL(obj) ((obj) == NULL) >>>>>>> #define JNU_IsNull(env,obj) ((obj) == NULL) >>>>>>> +#define IS_TRUE(obj) ((obj) ? JNI_TRUE : JNI_FALSE) >>>>>>> >>>>>>> I am not sure about the name, probably someone have a better >>>>>>> suggestion? >>>>>>> >>>>>>> The fix is for jdk9/dev. >>>>>>> >>>>>>> -- >>>>>>> Best regards, Sergey. >>>>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >>>>> >>> >> > -- Best regards, Sergey. From brian.burkhalter at oracle.com Wed Mar 19 23:51:48 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 19 Mar 2014 16:51:48 -0700 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: <1110EF84-EF2B-45C0-A61E-1C4397749BED@oracle.com> References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <531EC6BF.4050701@oracle.com> <4742E0AD-8D87-4F22-8F23-779BDF3A58FE@oracle.com> <5320240C.60304@gmail.com> <5322DC66.5070003@gmail.com> <96B8A54B-77FC-4973-8A92-2344A1621F43@oracle.com> <532A290A.7090307@gmail.com> <1110EF84-EF2B-45C0-A61E-1C4397749BED@oracle.com> Message-ID: On Mar 19, 2014, at 4:41 PM, Brian Burkhalter wrote: >> Benchmark Mode Samples Mean Mean error Units >> o.s.Bench6375303.testToString avgt 10 80.925 0.313 ns/op > > That?s great! I can re-try that version on my system for comparison. Here are the results on my system: http://cr.openjdk.java.net/~bpb/6375303/6375303-bench-3.html Thanks, Brian From Roger.Riggs at Oracle.com Thu Mar 20 02:30:31 2014 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 19 Mar 2014 22:30:31 -0400 Subject: [9] Review request: new macro for conversion to jboolean In-Reply-To: <532A2B8E.9040707@oracle.com> References: <53270E65.4070001@oracle.com> <53273F9A.3080403@oracle.com> <5329E3B7.7000000@oracle.com> <5329F8A4.6030908@oracle.com> <5329F93A.2010205@oracle.com> <5329F91E.4050703@oracle.com> <532A2B8E.9040707@oracle.com> Message-ID: <532A52C7.5010900@Oracle.com> Hi Sergey, Please give this a day to stew. I'd like some time to consider other names before agreeing. (Not that my agreement is necessary or sufficient). Thanks, Roger On 3/19/14 7:43 PM, Sergey Bylokhov wrote: > Thanks. > So if nobody objects, the final version will be: > > #define IS_NULL(obj) ((obj) == NULL) > #define JNU_IsNull(env,obj) ((obj) == NULL) > +#define TO_JBOOLEAN(obj) (jboolean) ((obj) ? JNI_TRUE : JNI_FALSE) > > > On 3/20/14 12:07 AM, roger riggs wrote: >> Hi, >> >> Well... When JNU_RETURN was added, there was a long discussion about >> NOT using JNU unless the JNI environment was an argument to the macro. >> >> So, the simple name is preferred. >> >> Roger >> >> On 3/19/2014 4:08 PM, Phil Race wrote: >>> PS .. so maybe whilst you are touching this file you could do >>> #define JNU_CHECK_NULL CHECK_NULL >>> #define JNU_CHECK_NULL_RETURN CHECK_NULL_RETURN >>> >>> so we could migrate to these (clearer) ones >>> >>> -phil. >>> >>> On 3/19/2014 1:05 PM, Phil Race wrote: >>>> I think having it start with "JNU_" is a good suggestion. >>>> I've been wondering over the last week or so if it would not have been >>>> better to have CHECK_NULL called JNU_CHECK_NULL to reduce collision >>>> chances >>>> and to make it clearer where it comes from .. >>>> >>>> -phil. >>>> >>>> On 3/19/2014 12:49 PM, Mike Duigou wrote: >>>>> Definitely a useful macro. >>>>> >>>>> I too would prefer a name like TO_JBOOLEAN since it reveals the >>>>> result type. Also all uppercase to identify it as a macro. If we >>>>> are paranoid and want to reduce the chance of a name collision >>>>> then JNU_TO_JBOOLEAN perhaps. >>>>> >>>>> I would also define the macro as: >>>>> >>>>> #define JNU_TO_JBOOLEAN(obj) (jboolean) ((obj) ? JNI_TRUE : >>>>> JNI_FALSE) >>>>> >>>>> so that the type of the result is explicit. Unfortunately jni.h >>>>> doesn't define JNI_TRUE or false with a cast to jboolean as they >>>>> probably should. >>>>> >>>>> Mike >>>>> >>>>> On Mar 19 2014, at 11:36 , Sergey Bylokhov >>>>> wrote: >>>>> >>>>>> Thanks Anthony! >>>>>> >>>>>> Can somebody from the core-libs team take a look? >>>>>> >>>>>> On 3/17/14 10:31 PM, Anthony Petrov wrote: >>>>>>> Personally, I'd call it to_jboolean(obj), but IS_TRUE(obj) >>>>>>> sounds good to me too. Either way, I'm fine with the fix. >>>>>>> >>>>>>> -- >>>>>>> best regards, >>>>>>> Anthony >>>>>>> >>>>>>> On 3/17/2014 7:01 PM, Sergey Bylokhov wrote: >>>>>>>> Hello. >>>>>>>> This review request is for the new macro, which simplify >>>>>>>> conversion to >>>>>>>> jboolean. It will be useful for fixing parfait warnings. >>>>>>>> >>>>>>>> We have a lot of places, where we cast some type to jboolean: >>>>>>>> >>>>>>>> BOOL = retVal; >>>>>>>> return (jboolean) retVal; >>>>>>>> >>>>>>>> WARNING: Expecting value of JNI primitive type jboolean: >>>>>>>> mismatched >>>>>>>> value retVal with size 32 bits, retVal used for conversion to >>>>>>>> int8 in return >>>>>>>> >>>>>>>> >>>>>>>> +++ b/src/share/native/common/jni_util.h Mon Mar 17 18:28:48 >>>>>>>> 2014 +0400 >>>>>>>> @@ -277,6 +277,7 @@ >>>>>>>> >>>>>>>> #define IS_NULL(obj) ((obj) == NULL) >>>>>>>> #define JNU_IsNull(env,obj) ((obj) == NULL) >>>>>>>> +#define IS_TRUE(obj) ((obj) ? JNI_TRUE : JNI_FALSE) >>>>>>>> >>>>>>>> I am not sure about the name, probably someone have a better >>>>>>>> suggestion? >>>>>>>> >>>>>>>> The fix is for jdk9/dev. >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, Sergey. >>>>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, Sergey. >>>>>> >>>> >>> >> > > From peter.levart at gmail.com Thu Mar 20 07:06:04 2014 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 20 Mar 2014 08:06:04 +0100 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: <532A290A.7090307@gmail.com> References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <531EC6BF.4050701@oracle.com> <4742E0AD-8D87-4F22-8F23-779BDF3A58FE@oracle.com> <5320240C.60304@gmail.com> <5322DC66.5070003@gmail.com> <96B8A54B-77FC-4973-8A92-2344A1621F43@oracle.com> <532A290A.7090307@gmail.com> Message-ID: <532A935C.2060604@gmail.com> On 03/20/2014 12:32 AM, Peter Levart wrote: > > On 03/19/2014 11:01 PM, Brian Burkhalter wrote: >> >> On Mar 14, 2014, at 7:17 AM, Brian Burkhalter >> > wrote: >> >>> On Mar 14, 2014, at 3:39 AM, Peter Levart wrote: >>> >>>> But in general it would be better to just use >>>> "ThreadLocalRandom.current()" everywhere you use "rnd" variable. >>>> This is precisely it's purpose - a random number generator that is >>>> never contended. The overhead of ThreadLocalRandom.current() call >>>> is hardly measurable by itself. >>> >>> I'll update that and re-run some of the benchmarks later. >> >> Following up on the content above and this earlier message in the thread: >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-March/025676.html >> >> I have posted a revised patch (NB: I know lines 2897-2906 should be >> elsewhere) >> >> http://cr.openjdk.java.net/~bpb/6375303/webrev.01/ >> >> >> and updated benchmark source (using only ThreadLocalRandom.current()) >> >> http://cr.openjdk.java.net/~bpb/6375303/Bench6375303.java >> >> >> and updated benchmark results for three different variations >> >> http://cr.openjdk.java.net/~bpb/6375303/6375303-bench-2.html >> >> >> This version of toString() is from Peter and dispenses with the >> volatile qualifier on stringCache. At least on my system, there is no >> statistically significant micro-performance difference among the >> three versions tested, viz., baseline, toString() change only, >> toString() change plus other cleanup. >> >> Any comments appreciated. >> >> Thanks, >> >> Brian > > Hi Brian, > > Here's my promised run of your latest webrev and microbenchmark on ARM > platform (Raspberry Pi) with just released JDK 8 for ARM (-client > compiler, since -server does not work on Raspberry Pi): > > org.openjdk.jmh.Main parameters: ".*" -i 10 -r 5 -wi 5 -w 1 -f 1 -t 1 > > --- Baseline, 1-thread --- > > Benchmark Mode Samples Mean Mean error Units > o.s.Bench6375303.testFirstToString avgt 10 330618.266 2211.637 ns/op > o.s.Bench6375303.testToString avgt 10 80.546 0.134 ns/op > > --- Proposed webrev, 1-thread --- > > Benchmark Mode Samples Mean Mean error Units > o.s.Bench6375303.testFirstToString avgt 10 326588.284 1714.892 ns/op > o.s.Bench6375303.testToString avgt 10 102.582 0.295 ns/op > > --- Previous variant with volatile stringCache field, 1-thread --- > > Benchmark Mode Samples Mean Mean error Units > o.s.Bench6375303.testFirstToString avgt 10 328795.783 2508.173 ns/op > o.s.Bench6375303.testToString avgt 10 105.741 0.316 ns/op > > > So both variants seem to be more or less the same but slower than baseline. > > Why would they be slower? Answer: they have more bytecodes. > > If I run with following JVM options: -XX:+UnlockDiagnosticVMOptions -XX:MaxInlineSize=100 (and only the "testToString" benchmark), I get: > > > --- Baseline, 1-thread --- > > Benchmark Mode Samples Mean Mean error Units > o.s.Bench6375303.testToString avgt 10 80.839 0.742 ns/op > > --- Proposed webrev, 1-thread --- > > Benchmark Mode Samples Mean Mean error Units > o.s.Bench6375303.testToString avgt 10 80.851 0.771 ns/op > > --- Previous variant with volatile stringCache field, 1-thread --- > > Benchmark Mode Samples Mean Mean error Units > o.s.Bench6375303.testToString avgt 10 80.834 0.749 ns/op Hi, The answer, I was thinking about last night, for question: "Why is this double-checked non-volatile-then-volatile trick not any faster than pure volatile variant even on ARM platform where volatile read should have some penalty compared to normal read?", might be in the fact that Raspberry Pi is a single-core/single-thread "machine". Would anyone with JVM JIT compiler expertise care to share some insight? I suspect that on such platform, the compiler optimizes volatile accesses so that they are performed without otherwise necessary memory fences... Regards, Peter > > > So the solution is to "reduce number of bytecodes in toString()". For example, the following: > > > public String toString() { > String sc = stringCache; > if (sc == null) { > sc = toStringSlow(); > } > return sc; > } > > private String toStringSlow() { > String sc = (String) U.getObjectVolatile(this, STRING_CACHE_OFFSET); > if (sc == null) { > sc = layoutChars(true); > if (!U.compareAndSwapObject(this, STRING_CACHE_OFFSET, null, sc)) { > sc = (String) U.getObjectVolatile(this, STRING_CACHE_OFFSET); > } > } > return sc; > } > > > ...gives the good results even without special JVM options: > > Benchmark Mode Samples Mean Mean error Units > o.s.Bench6375303.testToString avgt 10 80.925 0.313 ns/op > > > > Regards, Peter > From ivan.gerasimov at oracle.com Thu Mar 20 07:25:49 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 20 Mar 2014 11:25:49 +0400 Subject: RFR [6943190] TEST_BUG: java/lang/Runtime/exec/ExecWithInput.java hardcodes path to cat In-Reply-To: <532A0E76.3040906@oracle.com> References: <530B80CF.9090403@oracle.com> <530E5D0F.90409@oracle.com> <530E6877.5050504@oracle.com> <530F06A3.1030107@oracle.com> <5323352C.4080007@oracle.com> <5325D6E6.8090208@oracle.com> <5326A961.5030803@oracle.com> <5326BB2D.6060201@oracle.com> <53275F00.5070706@oracle.com> <5329BCAF.3040106@oracle.com> <5329D534.3030509@oracle.com> <532A0E76.3040906@oracle.com> Message-ID: <532A97FD.8060906@oracle.com> Thank you Alan! > This looks okay although I would prefer for a number of these tests to > fail if the command is not found (otherwise it is will just hide issues). Now I've got two suggestions that somehow contradict each other. Martin suggested to check for particular OS only as a last resort, but without knowing that we run under Unix, we cannot treat a command absence as an error. I think we can assume that none of the tests which need UnixCommands are for Windows, so I added explicit checking for that. Having made sure the OS is a Unix (i.e. not Windows), the absence of a required command now causes an exception to be thrown. Would you please take a look at the updated webrev? http://cr.openjdk.java.net/~igerasim/6943190/6/webrev/ Sincerely yours, Ivan From aleksey.shipilev at oracle.com Thu Mar 20 07:49:58 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 20 Mar 2014 11:49:58 +0400 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: <532A935C.2060604@gmail.com> References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <531EC6BF.4050701@oracle.com> <4742E0AD-8D87-4F22-8F23-779BDF3A58FE@oracle.com> <5320240C.60304@gmail.com> <5322DC66.5070003@gmail.com> <96B8A54B-77FC-4973-8A92-2344A1621F43@oracle.com> <532A290A.7090307@gmail.com> <532A935C.2060604@gmail.com> Message-ID: <532A9DA6.6080707@oracle.com> On 03/20/2014 11:06 AM, Peter Levart wrote: > I was thinking about last night, for question: "Why is this > double-checked non-volatile-then-volatile trick not any faster than pure > volatile variant even on ARM platform where volatile read should have > some penalty compared to normal read?", might be in the fact that > Raspberry Pi is a single-core/single-thread "machine". Would anyone with > JVM JIT compiler expertise care to share some insight? I suspect that on > such platform, the compiler optimizes volatile accesses so that they are > performed without otherwise necessary memory fences... Yes, at least C2 is known to not emit memory fences on uniprocessor machines. You need to have a multicore ARM. If you are still interested, contact me privately and I can arrange the access to my personal quad-core Cortex-A9. -Aleksey. From peter.levart at gmail.com Thu Mar 20 08:32:02 2014 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 20 Mar 2014 09:32:02 +0100 Subject: StringBuilder version of java.util.regex.Matcher.append* In-Reply-To: References: Message-ID: <532AA782.5030809@gmail.com> On 03/19/2014 06:51 PM, Jeremy Manson wrote: > I'm told that the diff didn't make it. I've put it in a Google drive > folder... > > https://drive.google.com/file/d/0B_GaXa6O4K5LY3Y0aHpranM3aEU/edit?usp=sharing > > Jeremy Hi Jeremy, Your factoring-out of expandReplacement() method exposed an opportunity to further optimize the code. Instead of creating intermediate StringBuilder instance for each expandReplacement() call, this method could append directly to resulting StringBuffer/StringBuilder, like in the following: http://cr.openjdk.java.net/~plevart/jdk9-dev/MatcherWithStringBuilder/webrev.01/ Regards, Peter > > > On Wed, Mar 19, 2014 at 10:41 AM, Jeremy Manson wrote: > >> Hi folks, >> >> We've had this internally for a while, and I keep meaning to bring it up >> here. The Matcher class has a few public methods that take StringBuffers, >> and we've found it useful to add similar versions that take StringBuilders. >> >> It has two benefits: >> >> - Users don't have to convert from one to the other when they want to use >> the method in question. The symmetry is nice. >> >> - The StringBuilder variants are faster (if lock optimizations don't kick >> in, which happens in the interpreter and the client compiler). For >> interpreted / client-compiled code, we saw something like a 25% speedup on >> String.replaceAll(), which calls into this code. >> >> Any interest? Diff attached. >> >> Jeremy >> From magnus.ihse.bursie at oracle.com Thu Mar 20 08:57:02 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 20 Mar 2014 09:57:02 +0100 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <955387107.1663490.1395241051025.JavaMail.zimbra@redhat.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <532888F0.2050402@oracle.com> <1371463485.1186545.1395166979412.JavaMail.zimbra@redhat.com> <53288F9E.6070309@redhat.com> <5329A0E5.4000603@oracle.com> <5329AFA8.2090003@redhat.com> <955387107.1663490.1395241051025.JavaMail.zimbra@redhat.com> Message-ID: <532AAD5E.1000006@oracle.com> On 2014-03-19 15:57, Andrew Hughes wrote: > > >> I think that's something we must fix ourselves. What we really >> need from OpenJDK is a way to build with complete debuginfo in >> both binaries and jarfiles. > This was my intent with #2. The jstack/jmap issue needs to be fixed by > stripping less debuginfo post-build on libjvm.so. Ok, that sounds great. We provide a way to keep the debuginfo in the binaries, and then you can do your own magic, and everyone is happy. :) I'll re-target the original bug (JDK-8036003) so that it is about implementing such debuginfo handling instead. /Magnus From Ulf.Zibis at CoSoCo.de Thu Mar 20 10:05:41 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 20 Mar 2014 11:05:41 +0100 Subject: RFR [8014066] Mistake in documentation of ArrayList#removeRange In-Reply-To: <532A1C2C.1050601@CoSoCo.de> References: <5321CEE6.403@oracle.com> <53223837.4010306@cs.oswego.edu> <5322EB0F.8010900@cs.oswego.edu> <5324A8B6.8010009@oracle.com> <532627B5.8020507@oracle.com> <5328903A.6070104@oracle.com> <5328C4CA.6090906@CoSoCo.de> <5329531F.9070109@oracle.com> <532A1407.20300@CoSoCo.de> <532A1C2C.1050601@CoSoCo.de> Message-ID: <532ABD75.8070908@CoSoCo.de> Am 19.03.2014 23:37, schrieb Ulf Zibis: > Am 19.03.2014 23:32, schrieb Martin Buchholz: >> No one is as performance obsessed as Ulf. > > :-D :-D :-D And additionally footprint obsessed -Ulf From david.holmes at oracle.com Thu Mar 20 12:24:41 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 Mar 2014 22:24:41 +1000 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <53280AF0.5000502@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <53280AF0.5000502@oracle.com> Message-ID: <532ADE09.7050602@oracle.com> On 18/03/2014 6:59 PM, Magnus Ihse Bursie wrote: > On 2014-03-18 02:19, Andrew Hughes wrote: >> Do we need more than just the following three alternatives? >> >> #1. No debugging information at all. >> #2. Debugging information left in the original binaries. >> #3. Debugging information stripped from the binaries and zipped in >> separate files. >> >> It sounds to me like Oracle want #3, while distros want #2 and I >> imagine some >> end users may just want #1 for a faster, smaller build. > > I'm completely thinking along your lines here. I think we should focus > on the end result, not the specific implementations details. I've been > thinking about exposing a configure option like this: > > --with-debug-symbols=none (for #1) > --with-debug-symbols=internal (for #2) > --with-debug-symbols=zipped (for #3) I don't think this quite works as there are other variations not captured here. Rather than "zipped" it should just be "external". Whether the debuginfo files are zipped or not is then an additional build time option. Additionally we still have to be able to control the degree of stripping that is carried out. It doesn't make sense to me to try and enumerate all possible combinations as top-level configure options. Further, as Dan was saying, this doesn't capture the overlap between "internal" and "external" because we still leave some symbols internal even when creating the debuginfo file. So I don't think this proposed categorization works. We still have three aspects: - generating symbols into the object files - stripping symbols from the final binaries - saving symbols into an external form Each of which can potentally be varied (of course if you don't generate symbols in the obj files stripping and saving are non issues). David ----- > but perhaps with better names. I also imagine there might be a use case > for yet another option, > #4. Debuggin information stripped from the binaries, but not zipped > > expressed like this > --with-debug-symbols=external > > And then this would be the only user interface needed, and the rest of > the current set of not-really-clear flags can be hidden inside the > configure script. > > For compatibility reasons, the default would be > --with-debug-symbols=zipped (which is called "FDS" here), just as we > currently do, but distributions would just need to add a > --with-debug-symbols=internal to get what they want. > > /Magnus From Alan.Bateman at oracle.com Thu Mar 20 13:09:08 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 20 Mar 2014 13:09:08 +0000 Subject: RFR [6943190] TEST_BUG: java/lang/Runtime/exec/ExecWithInput.java hardcodes path to cat In-Reply-To: <532A97FD.8060906@oracle.com> References: <530B80CF.9090403@oracle.com> <530E5D0F.90409@oracle.com> <530E6877.5050504@oracle.com> <530F06A3.1030107@oracle.com> <5323352C.4080007@oracle.com> <5325D6E6.8090208@oracle.com> <5326A961.5030803@oracle.com> <5326BB2D.6060201@oracle.com> <53275F00.5070706@oracle.com> <5329BCAF.3040106@oracle.com> <5329D534.3030509@oracle.com> <532A0E76.3040906@oracle.com> <532A97FD.8060906@oracle.com> Message-ID: <532AE874.4050002@oracle.com> On 20/03/2014 07:25, Ivan Gerasimov wrote: > > Now I've got two suggestions that somehow contradict each other. > Martin suggested to check for particular OS only as a last resort, but > without knowing that we run under Unix, we cannot treat a command > absence as an error. It's always hard to get complete agreement on things like this but for tests that are *nix specific then I would say that it's better to check it at the start and have it just pass on Windows without needlessly checking for programs that don't exist or can't be used by the test. > > I think we can assume that none of the tests which need UnixCommands > are for Windows, so I added explicit checking for that. > Having made sure the OS is a Unix (i.e. not Windows), the absence of a > required command now causes an exception to be thrown. > > Would you please take a look at the updated webrev? > > http://cr.openjdk.java.net/~igerasim/6943190/6/webrev/ This looks okay to me. An alternative would be for findCommand to throw an exception when the command is not found and that would allow most of the ensureCommandAvailables(...) usages to be removed and saves searching for them twice. -Alan From Lance.Andersen at oracle.com Thu Mar 20 15:40:10 2014 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 20 Mar 2014 11:40:10 -0400 Subject: RFR (JAXP): 8035577: Xerces Update: impl/xpath/regex/RangeToken.java In-Reply-To: <532A23D6.2070503@oracle.com> References: <532A23D6.2070503@oracle.com> Message-ID: I think this OK. The comments with the o--o did not do much for me though and found them a bit confusing but perhaps I need more coffee this morning ? Also, not sure we need the @author tag but I think its usage varies in the workspace Best Lance On Mar 19, 2014, at 7:10 PM, David Li wrote: > Hi, > > This is an update from Xerces for file impl/xpath/regex/TokenRange.java. For details, please refer to: https://bugs.openjdk.java.net/browse/JDK-8035577. > > Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035577/webrev/ > > Existing tests: JAXP SQE and unit tests passed. > > Test cases added for typo fix in RangeToken.intersectRanges. Code also updated to fix a bug where regular expression intersection returns incorrect value when first range ends later than second range. Example below. Test cases have been added to cover any scenarios that the code changes affect. > > new RegularExpression("(?[b-d]&[a-r])"); -> returns [b-d] (Correct) > new RegularExpression("(?[a-r]&[b-d])"); -> returns [b-de-r] (Incorrect) > > Thanks, > David > > P.S. Notes on bug fixes. > 1) Line 404 removal of while loop. > This fixes a new bug where incorrect results are given when first range ends later than second range. In the old code we got > (?[a-r]&[b-d]) -> returns [b-de-r] > By removing the while loop, we get [b-d]. > This while loop looks like a copy-paste error from subtractRanges. In subtractRanges we need to keep the leftover portion from the first range, but this does not apply to intersection. > > 2) Line 388, addition of src2 += 2; > This code change affects anything of the form (?[a-r]&[b-eg-j]). The code execution is diagrammed below. > o------------o (src1) > o--o o--o (src2) > For the first match we get > o------------o (src1) > o--o (src2) > Next we want to run src2+=2 to get the second pair of endpoints (since the first two endpoints are already used). Notice how src1begin has been updated to this.ranges[src1] = src2end+1, which is directly from the code. > o------o (src1) > o--o (src2) > The src2+=2 statement was left out of the old code, and is added in this webrev. If we leave out the src2+=2 at line 388, on the next iteration of the large while loop we will reach case "} else if (src2end < src1begin) {" which also executes "src2+=2". This means the correct final result is generated, but on a later loop. We want to add the new code because it's better to have all associated variable updated in the sameloop. In addition, all the other conditions have similar src1 or src2 updates. > -------------- next part -------------- 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 jeremymanson at google.com Thu Mar 20 16:52:52 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Thu, 20 Mar 2014 09:52:52 -0700 Subject: StringBuilder version of java.util.regex.Matcher.append* In-Reply-To: <532AA782.5030809@gmail.com> References: <532AA782.5030809@gmail.com> Message-ID: That's definitely an improvement - I think that when I wrote this (circa 2009), I didn't think about Appendable. I take it my argument convinced someone? :) Jeremy On Thu, Mar 20, 2014 at 1:32 AM, Peter Levart wrote: > On 03/19/2014 06:51 PM, Jeremy Manson wrote: > >> I'm told that the diff didn't make it. I've put it in a Google drive >> folder... >> >> https://drive.google.com/file/d/0B_GaXa6O4K5LY3Y0aHpranM3aEU/ >> edit?usp=sharing >> >> Jeremy >> > > Hi Jeremy, > > Your factoring-out of expandReplacement() method exposed an opportunity to > further optimize the code. Instead of creating intermediate StringBuilder > instance for each expandReplacement() call, this method could append > directly to resulting StringBuffer/StringBuilder, like in the following: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/MatcherWithStringBuilder/ > webrev.01/ > > > Regards, Peter > > > >> >> On Wed, Mar 19, 2014 at 10:41 AM, Jeremy Manson >> wrote: >> >> Hi folks, >>> >>> We've had this internally for a while, and I keep meaning to bring it up >>> here. The Matcher class has a few public methods that take >>> StringBuffers, >>> and we've found it useful to add similar versions that take >>> StringBuilders. >>> >>> It has two benefits: >>> >>> - Users don't have to convert from one to the other when they want to use >>> the method in question. The symmetry is nice. >>> >>> - The StringBuilder variants are faster (if lock optimizations don't kick >>> in, which happens in the interpreter and the client compiler). For >>> interpreted / client-compiled code, we saw something like a 25% speedup >>> on >>> String.replaceAll(), which calls into this code. >>> >>> Any interest? Diff attached. >>> >>> Jeremy >>> >>> > From xueming.shen at oracle.com Thu Mar 20 17:25:03 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 20 Mar 2014 10:25:03 -0700 Subject: StringBuilder version of java.util.regex.Matcher.append* In-Reply-To: References: <532AA782.5030809@gmail.com> Message-ID: <532B246F.20302@oracle.com> 2009? I do have something similar back to 2009 :-) http://cr.openjdk.java.net/~sherman/regex_replace/webrev/ Then the ball was dropped around the discussion of whether or not the IOE should be thrown. But if we are going to/have to have explicit StringBuilder/Buffer pair anyway, then we can keep the Appendable version as private for now and deal with the StringBuilder and Appendable as two separate issues. -Sherman On 03/20/2014 09:52 AM, Jeremy Manson wrote: > That's definitely an improvement - I think that when I wrote this (circa > 2009), I didn't think about Appendable. > > I take it my argument convinced someone? :) > > Jeremy > > > On Thu, Mar 20, 2014 at 1:32 AM, Peter Levartwrote: > >> On 03/19/2014 06:51 PM, Jeremy Manson wrote: >> >>> I'm told that the diff didn't make it. I've put it in a Google drive >>> folder... >>> >>> https://drive.google.com/file/d/0B_GaXa6O4K5LY3Y0aHpranM3aEU/ >>> edit?usp=sharing >>> >>> Jeremy >>> >> Hi Jeremy, >> >> Your factoring-out of expandReplacement() method exposed an opportunity to >> further optimize the code. Instead of creating intermediate StringBuilder >> instance for each expandReplacement() call, this method could append >> directly to resulting StringBuffer/StringBuilder, like in the following: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/MatcherWithStringBuilder/ >> webrev.01/ >> >> >> Regards, Peter >> >> >> >>> On Wed, Mar 19, 2014 at 10:41 AM, Jeremy Manson >>> wrote: >>> >>> Hi folks, >>>> We've had this internally for a while, and I keep meaning to bring it up >>>> here. The Matcher class has a few public methods that take >>>> StringBuffers, >>>> and we've found it useful to add similar versions that take >>>> StringBuilders. >>>> >>>> It has two benefits: >>>> >>>> - Users don't have to convert from one to the other when they want to use >>>> the method in question. The symmetry is nice. >>>> >>>> - The StringBuilder variants are faster (if lock optimizations don't kick >>>> in, which happens in the interpreter and the client compiler). For >>>> interpreted / client-compiled code, we saw something like a 25% speedup >>>> on >>>> String.replaceAll(), which calls into this code. >>>> >>>> Any interest? Diff attached. >>>> >>>> Jeremy >>>> >>>> From jeremymanson at google.com Thu Mar 20 17:38:54 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Thu, 20 Mar 2014 10:38:54 -0700 Subject: StringBuilder version of java.util.regex.Matcher.append* In-Reply-To: <532B246F.20302@oracle.com> References: <532AA782.5030809@gmail.com> <532B246F.20302@oracle.com> Message-ID: Sherman, If you had released it then (which you wouldn't have been able to do, because you would have to wait another two years for Java 7), you would have found that it improved performance even with C2. It is only post-escape-analysis that the performance in C2 equalized. Anyway, I think adding the StringBuilder variant and deferring / dealing with the Appendable differently is the right approach, FWIW. Jeremy On Thu, Mar 20, 2014 at 10:25 AM, Xueming Shen wrote: > 2009? I do have something similar back to 2009 :-) > > http://cr.openjdk.java.net/~sherman/regex_replace/webrev/ > > Then the ball was dropped around the discussion of whether or not > the IOE should be thrown. > > But if we are going to/have to have explicit StringBuilder/Buffer pair > anyway, then we can keep the Appendable version as private for now > and deal with the StringBuilder and Appendable as two separate > issues. > > -Sherman > > > On 03/20/2014 09:52 AM, Jeremy Manson wrote: > >> That's definitely an improvement - I think that when I wrote this (circa >> 2009), I didn't think about Appendable. >> >> I take it my argument convinced someone? :) >> >> Jeremy >> >> >> On Thu, Mar 20, 2014 at 1:32 AM, Peter Levart >> wrote: >> >> On 03/19/2014 06:51 PM, Jeremy Manson wrote: >>> >>> I'm told that the diff didn't make it. I've put it in a Google drive >>>> folder... >>>> >>>> https://drive.google.com/file/d/0B_GaXa6O4K5LY3Y0aHpranM3aEU/ >>>> edit?usp=sharing >>>> >>>> Jeremy >>>> >>>> Hi Jeremy, >>> >>> Your factoring-out of expandReplacement() method exposed an opportunity >>> to >>> further optimize the code. Instead of creating intermediate StringBuilder >>> instance for each expandReplacement() call, this method could append >>> directly to resulting StringBuffer/StringBuilder, like in the following: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/MatcherWithStringBuilder/ >>> webrev.01/ >>> >>> >>> Regards, Peter >>> >>> >>> >>> On Wed, Mar 19, 2014 at 10:41 AM, Jeremy Manson>>> > >>>> wrote: >>>> >>>> Hi folks, >>>> >>>>> We've had this internally for a while, and I keep meaning to bring it >>>>> up >>>>> here. The Matcher class has a few public methods that take >>>>> StringBuffers, >>>>> and we've found it useful to add similar versions that take >>>>> StringBuilders. >>>>> >>>>> It has two benefits: >>>>> >>>>> - Users don't have to convert from one to the other when they want to >>>>> use >>>>> the method in question. The symmetry is nice. >>>>> >>>>> - The StringBuilder variants are faster (if lock optimizations don't >>>>> kick >>>>> in, which happens in the interpreter and the client compiler). For >>>>> interpreted / client-compiled code, we saw something like a 25% speedup >>>>> on >>>>> String.replaceAll(), which calls into this code. >>>>> >>>>> Any interest? Diff attached. >>>>> >>>>> Jeremy >>>>> >>>>> >>>>> > From ivan.gerasimov at oracle.com Thu Mar 20 18:18:28 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 20 Mar 2014 22:18:28 +0400 Subject: RFR [6943190] TEST_BUG: java/lang/Runtime/exec/ExecWithInput.java hardcodes path to cat In-Reply-To: <532AE874.4050002@oracle.com> References: <530B80CF.9090403@oracle.com> <530E5D0F.90409@oracle.com> <530E6877.5050504@oracle.com> <530F06A3.1030107@oracle.com> <5323352C.4080007@oracle.com> <5325D6E6.8090208@oracle.com> <5326A961.5030803@oracle.com> <5326BB2D.6060201@oracle.com> <53275F00.5070706@oracle.com> <5329BCAF.3040106@oracle.com> <5329D534.3030509@oracle.com> <532A0E76.3040906@oracle.com> <532A97FD.8060906@oracle.com> <532AE874.4050002@oracle.com> Message-ID: <532B30F4.9090402@oracle.com> Thank you Alan! >> >> I think we can assume that none of the tests which need UnixCommands >> are for Windows, so I added explicit checking for that. >> Having made sure the OS is a Unix (i.e. not Windows), the absence of >> a required command now causes an exception to be thrown. >> >> Would you please take a look at the updated webrev? >> >> http://cr.openjdk.java.net/~igerasim/6943190/6/webrev/ > This looks okay to me. An alternative would be for findCommand to > throw an exception when the command is not found and that would allow > most of the ensureCommandAvailables(...) usages to be removed and > saves searching for them twice. > I think it is informative to have the prerequisites checking at the beginning of the test. And the results of the search are cached in UnixCommands.nameToCommand map, so they're searched for only once. Sincerely yours, Ivan From scolebourne at joda.org Thu Mar 20 18:24:51 2014 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 20 Mar 2014 18:24:51 +0000 Subject: RFR: JDK-8033662 DateTimeFormatter parsing ignores withZone() In-Reply-To: References: Message-ID: Hi there, It would be great if I could get a review please. The patch is viewable in plain text at JIRA (for IP reasons): https://bugs.openjdk.java.net/secure/attachment/19216/ParseWithZone.patch The same patch is viewable in a nice format at GitHub https://gist.github.com/jodastephen/9505761 This really needs to make 8u20 IMO, so I need to get it into jdk9 first thanks Stephen On 12 March 2014 12:29, Stephen Colebourne wrote: > This is a request for review of this bug: > https://bugs.openjdk.java.net/browse/JDK-8033662 > and the duplicate: > https://bugs.openjdk.java.net/browse/JDK-8033659 > > The javadoc of the method java.time.format.DateTimeFormatter::withZone says: > "If no zone has been parsed, then this override zone will be included > in the result of the parse where it can be used to build instants and > date-times." > However, the implementation doesn't obey this. > > This is a very unfortunate bug that makes some date-time parsing a lot harder. > > A second related bug in an egde case - not properly handling a > ChronoZonedDateTime from TemporalField.resolve - is also tested for > and fixed. > > > Proposed patch: > https://gist.github.com/jodastephen/9505761 > The patch includes no spec changes. > The patch includes new and refactored TCK tests. The new tests for > withZone() and withChronology() are based on the spec. > > I need a reviewer and a committer please. > thanks From huizhe.wang at oracle.com Thu Mar 20 18:33:33 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 20 Mar 2014 11:33:33 -0700 Subject: RFR (JAXP): 8035577: Xerces Update: impl/xpath/regex/RangeToken.java In-Reply-To: References: <532A23D6.2070503@oracle.com> Message-ID: <532B347D.4040908@oracle.com> On 3/20/2014 8:40 AM, Lance Andersen - Oracle wrote: > I think this OK. > > The comments with the o--o did not do much for me though and found them a bit confusing but perhaps I need more coffee this morning ? Black or white? :-) It illustrates an intersection. For example, the result of the following would be o--o: o------o (src1) o--o (src2) -Joe > > Also, not sure we need the @author tag but I think its usage varies in the workspace > > Best > Lance > On Mar 19, 2014, at 7:10 PM, David Li wrote: > >> Hi, >> >> This is an update from Xerces for file impl/xpath/regex/TokenRange.java. For details, please refer to: https://bugs.openjdk.java.net/browse/JDK-8035577. >> >> Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035577/webrev/ >> >> Existing tests: JAXP SQE and unit tests passed. >> >> Test cases added for typo fix in RangeToken.intersectRanges. Code also updated to fix a bug where regular expression intersection returns incorrect value when first range ends later than second range. Example below. Test cases have been added to cover any scenarios that the code changes affect. >> >> new RegularExpression("(?[b-d]&[a-r])"); -> returns [b-d] (Correct) >> new RegularExpression("(?[a-r]&[b-d])"); -> returns [b-de-r] (Incorrect) >> >> Thanks, >> David >> >> P.S. Notes on bug fixes. >> 1) Line 404 removal of while loop. >> This fixes a new bug where incorrect results are given when first range ends later than second range. In the old code we got >> (?[a-r]&[b-d]) -> returns [b-de-r] >> By removing the while loop, we get [b-d]. >> This while loop looks like a copy-paste error from subtractRanges. In subtractRanges we need to keep the leftover portion from the first range, but this does not apply to intersection. >> >> 2) Line 388, addition of src2 += 2; >> This code change affects anything of the form (?[a-r]&[b-eg-j]). The code execution is diagrammed below. >> o------------o (src1) >> o--o o--o (src2) >> For the first match we get >> o------------o (src1) >> o--o (src2) >> Next we want to run src2+=2 to get the second pair of endpoints (since the first two endpoints are already used). Notice how src1begin has been updated to this.ranges[src1] = src2end+1, which is directly from the code. >> o------o (src1) >> o--o (src2) >> The src2+=2 statement was left out of the old code, and is added in this webrev. If we leave out the src2+=2 at line 388, on the next iteration of the large while loop we will reach case "} else if (src2end < src1begin) {" which also executes "src2+=2". This means the correct final result is generated, but on a later loop. We want to add the new code because it's better to have all associated variable updated in the sameloop. In addition, all the other conditions have similar src1 or src2 updates. >> > > > 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 chris.hegarty at oracle.com Thu Mar 20 19:06:57 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 20 Mar 2014 19:06:57 +0000 Subject: RFR: JDK-8033662 DateTimeFormatter parsing ignores withZone() In-Reply-To: References: Message-ID: <02A71FD6-98A7-4ACD-905A-422CD7F8A685@oracle.com> The changes look ok to me Stephen. I defer to others for the handling of the test/TCK changes. -Chris. > On 20 Mar 2014, at 18:24, Stephen Colebourne wrote: > > Hi there, > It would be great if I could get a review please. > > The patch is viewable in plain text at JIRA (for IP reasons): > https://bugs.openjdk.java.net/secure/attachment/19216/ParseWithZone.patch > > The same patch is viewable in a nice format at GitHub > https://gist.github.com/jodastephen/9505761 > > This really needs to make 8u20 IMO, so I need to get it into jdk9 first > thanks > Stephen > > > >> On 12 March 2014 12:29, Stephen Colebourne wrote: >> This is a request for review of this bug: >> https://bugs.openjdk.java.net/browse/JDK-8033662 >> and the duplicate: >> https://bugs.openjdk.java.net/browse/JDK-8033659 >> >> The javadoc of the method java.time.format.DateTimeFormatter::withZone says: >> "If no zone has been parsed, then this override zone will be included >> in the result of the parse where it can be used to build instants and >> date-times." >> However, the implementation doesn't obey this. >> >> This is a very unfortunate bug that makes some date-time parsing a lot harder. >> >> A second related bug in an egde case - not properly handling a >> ChronoZonedDateTime from TemporalField.resolve - is also tested for >> and fixed. >> >> >> Proposed patch: >> https://gist.github.com/jodastephen/9505761 >> The patch includes no spec changes. >> The patch includes new and refactored TCK tests. The new tests for >> withZone() and withChronology() are based on the spec. >> >> I need a reviewer and a committer please. >> thanks From lance.andersen at oracle.com Thu Mar 20 19:50:38 2014 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 20 Mar 2014 15:50:38 -0400 Subject: RFR: 8037507: broken links in javax/sql/rowset/package.html Message-ID: <3CF49131-6C0B-44ED-9DB6-E7301BA9AD89@oracle.com> Hi, Looking for a quick review of the following javadoc clean-up ljanders-mac:rowset ljanders$ hg diff diff -r 95e72182e615 src/share/classes/javax/sql/rowset/package.html --- a/src/share/classes/javax/sql/rowset/package.html Thu Mar 20 16:19:08 2014 +0000 +++ b/src/share/classes/javax/sql/rowset/package.html Thu Mar 20 15:46:30 2014 -0400 @@ -295,14 +295,13 @@

4.0 Related Specifications

5.0 Related Documentation

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 fw at deneb.enyo.de Thu Mar 20 19:51:59 2014 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 20 Mar 2014 20:51:59 +0100 Subject: Javadoc in 9 seems to treat all interfaces with only one method as functional interfaces In-Reply-To: <53272291.7030501@oracle.com> (Daniel Fuchs's message of "Mon, 17 Mar 2014 17:28:01 +0100") References: <53272291.7030501@oracle.com> Message-ID: <87fvmc1wdc.fsf@mid.deneb.enyo.de> * Daniel Fuchs: > While playing with JDK 9 javadoc command I noticed that it > seems to treat all single method interfaces as if they were > functional interfaces - even though they don't have the > @FunctionalInterface annotation. Does it take inheritence into account? If yes, why is this even a bug? From pbenedict at apache.org Thu Mar 20 20:19:04 2014 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 20 Mar 2014 15:19:04 -0500 Subject: Javadoc in 9 seems to treat all interfaces with only one method as functional interfaces In-Reply-To: <87fvmc1wdc.fsf@mid.deneb.enyo.de> References: <53272291.7030501@oracle.com> <87fvmc1wdc.fsf@mid.deneb.enyo.de> Message-ID: It's a bug because it was an early decision in JDK 8 that got changed: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-November/002379.html And then the change: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-January/024165.html On Thu, Mar 20, 2014 at 2:51 PM, Florian Weimer wrote: > * Daniel Fuchs: > > > While playing with JDK 9 javadoc command I noticed that it > > seems to treat all single method interfaces as if they were > > functional interfaces - even though they don't have the > > @FunctionalInterface annotation. > > Does it take inheritence into account? If yes, why is this even a > bug? > -- Cheers, Paul From fw at deneb.enyo.de Thu Mar 20 20:30:59 2014 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 20 Mar 2014 21:30:59 +0100 Subject: Javadoc in 9 seems to treat all interfaces with only one method as functional interfaces In-Reply-To: (Paul Benedict's message of "Thu, 20 Mar 2014 15:19:04 -0500") References: <53272291.7030501@oracle.com> <87fvmc1wdc.fsf@mid.deneb.enyo.de> Message-ID: <87a9ck1ukc.fsf@mid.deneb.enyo.de> * Paul Benedict: > It's a bug because it was an early decision in JDK 8 that got changed: > http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-November/002379.html > > And then the change: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-January/024165.html So it's a functional interface, but the documentation doesn't say so because we don't want it to be a functional interface? That's rather odd and suggests that something went wrong with the design. :-) From pbenedict at apache.org Thu Mar 20 20:34:03 2014 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 20 Mar 2014 15:34:03 -0500 Subject: Javadoc in 9 seems to treat all interfaces with only one method as functional interfaces In-Reply-To: <87a9ck1ukc.fsf@mid.deneb.enyo.de> References: <53272291.7030501@oracle.com> <87fvmc1wdc.fsf@mid.deneb.enyo.de> <87a9ck1ukc.fsf@mid.deneb.enyo.de> Message-ID: It's about design intent. The annotation conveys the intent and the compiler enforces it by ensuring one abstract method exists. As you noted, there are such things as "implicit functional interfaces", but use them at your own risk. In theory, an interface not annotated with @FI can gain additional methods in the future, which would then break any implicit use you relied on. Paul On Thu, Mar 20, 2014 at 3:30 PM, Florian Weimer wrote: > * Paul Benedict: > > > It's a bug because it was an early decision in JDK 8 that got changed: > > > http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-November/002379.html > > > > And then the change: > > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-January/024165.html > > So it's a functional interface, but the documentation doesn't say so > because we don't want it to be a functional interface? That's rather > odd and suggests that something went wrong with the design. :-) > -- Cheers, Paul From joe.darcy at oracle.com Thu Mar 20 22:04:11 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 20 Mar 2014 15:04:11 -0700 Subject: RFR: 8037507: broken links in javax/sql/rowset/package.html In-Reply-To: <3CF49131-6C0B-44ED-9DB6-E7301BA9AD89@oracle.com> References: <3CF49131-6C0B-44ED-9DB6-E7301BA9AD89@oracle.com> Message-ID: <532B65DB.4090001@oracle.com> Looks fine Lance, -Joe On 3/20/2014 12:50 PM, Lance Andersen wrote: > Hi, > > Looking for a quick review of the following javadoc clean-up > > > ljanders-mac:rowset ljanders$ hg diff > diff -r 95e72182e615 src/share/classes/javax/sql/rowset/package.html > --- a/src/share/classes/javax/sql/rowset/package.html Thu Mar 20 16:19:08 2014 +0000 > +++ b/src/share/classes/javax/sql/rowset/package.html Thu Mar 20 15:46:30 2014 -0400 > @@ -295,14 +295,13 @@ > >

4.0 Related Specifications

> > >

5.0 Related Documentation

> > > > > 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 xueming.shen at oracle.com Thu Mar 20 22:45:27 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 20 Mar 2014 15:45:27 -0700 Subject: RFR: JDK-8033662 DateTimeFormatter parsing ignores withZone() In-Reply-To: References: Message-ID: <532B6F87.3000007@oracle.com> Hi Stephen, Given the fact that the parser context is no longer public, the parsed from the formatter is either unresolved or resolved, just wonder if we really need those "effective" chrono and zone fields in Parsed. It appears perfect for me to simply keep these info inside the parser context and return the unresolved and resolved based on the formatter's request, for example http://cr.openjdk.java.net/~sherman/8033662/webrev2/ -Sherman On 03/20/2014 11:24 AM, Stephen Colebourne wrote: > Hi there, > It would be great if I could get a review please. > > The patch is viewable in plain text at JIRA (for IP reasons): > https://bugs.openjdk.java.net/secure/attachment/19216/ParseWithZone.patch > > The same patch is viewable in a nice format at GitHub > https://gist.github.com/jodastephen/9505761 > > This really needs to make 8u20 IMO, so I need to get it into jdk9 first > thanks > Stephen > > > > On 12 March 2014 12:29, Stephen Colebourne wrote: >> This is a request for review of this bug: >> https://bugs.openjdk.java.net/browse/JDK-8033662 >> and the duplicate: >> https://bugs.openjdk.java.net/browse/JDK-8033659 >> >> The javadoc of the method java.time.format.DateTimeFormatter::withZone says: >> "If no zone has been parsed, then this override zone will be included >> in the result of the parse where it can be used to build instants and >> date-times." >> However, the implementation doesn't obey this. >> >> This is a very unfortunate bug that makes some date-time parsing a lot harder. >> >> A second related bug in an egde case - not properly handling a >> ChronoZonedDateTime from TemporalField.resolve - is also tested for >> and fixed. >> >> >> Proposed patch: >> https://gist.github.com/jodastephen/9505761 >> The patch includes no spec changes. >> The patch includes new and refactored TCK tests. The new tests for >> withZone() and withChronology() are based on the spec. >> >> I need a reviewer and a committer please. >> thanks From mandy.chung at oracle.com Thu Mar 20 22:48:21 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 20 Mar 2014 15:48:21 -0700 Subject: Review request for 8035807: Convert use of sun.misc.BASE64Encoder/Decoder with java.util.Base64 In-Reply-To: <5329EFF4.9060008@oracle.com> References: <5329E3F7.6070007@oracle.com> <5329EFF4.9060008@oracle.com> Message-ID: <532B7035.9030905@oracle.com> On 3/19/14 12:28 PM, Xueming Shen wrote: > On 03/19/2014 11:37 AM, Mandy Chung wrote: >> https://bugs.openjdk.java.net/browse/JDK-8035807 >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.00/ >> >> This patch converts the last 2 references to >> sun.misc.BASE64Encoder/Decoder from the jdk repo with >> java.util.Base64. We should also update the tests and I have filed >> JDK-8037873 for that. >> >> Thanks >> Mandy > > The sun.misc.BASE64En/Decoder is MIME type, so it outputs the \r\n per 76 > characters during encoding, and ignores/skip \r or \n when decoding. > The new > Base64.getEncoder/Decoder() returns the "basic" Base64 coder, which it > never > inserts line separator when output, and throws exception for any > non-base64- > alphabet character, including \r and \n. > > The only disadvantage/incompatibility (j.u.Base64.getMimeDecoer() vs > sun.misc.BASE64Decoder) of switching to j.u.Base64 MIME type en/decoder > is that the Base64 Mime decoder ignores/skips any non-base64-alphabet > (including \r and \n), while sun.misc.BASE64Decoder appears to simply > use the init value "-1" for any non-base64-alphabet character for > decoding. > > I'm not familiar with the use scenario of ldap's Obj class, so I'm not > sure if > it matters (if it ever outputs/inputs > 76 character data, or even it > does,if > the difference matters). > > Btw, except getMimeEncoder(int ...) all other Base64.getXXXEn/Decoder() > returns singleton, so the de/encoder cache might not be necessary. Thanks Sherman. Vinnie confirms that it should retain the current behavior as there could be long-lived Java object in LDAP encoded with JDK 8 for example and then retrieved with JDK 9. Here is the updated webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.01/ Thanks Mandy From xueming.shen at oracle.com Fri Mar 21 05:54:21 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 20 Mar 2014 22:54:21 -0700 Subject: Review request for 8035807: Convert use of sun.misc.BASE64Encoder/Decoder with java.util.Base64 In-Reply-To: <532B7035.9030905@oracle.com> References: <5329E3F7.6070007@oracle.com> <5329EFF4.9060008@oracle.com> <532B7035.9030905@oracle.com> Message-ID: <532BD40D.60506@oracle.com> Obj.java:#482 It appears sun.misc.BASE64Decoder.decodeBuffer(String) uses String's deprecated String.getBytes(int srcBegin, int srcEnd, byte[] dst, int dstBegin). The proposed change now uses the jvm's default charset. It might trigger incompatible behavior if the default charset is not an ASCII compatible charset. But if the "Java object in LDAP was encoded with the platform default charset" (as the new comment suggested), the old implementation actually did not work on platform that the default encoding is not ASCII compatible, such as the IBM ebcdic. -Sherman On 3/20/14 3:48 PM, Mandy Chung wrote: > On 3/19/14 12:28 PM, Xueming Shen wrote: >> On 03/19/2014 11:37 AM, Mandy Chung wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8035807 >>> >>> Webrev at: >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.00/ >>> >>> This patch converts the last 2 references to >>> sun.misc.BASE64Encoder/Decoder from the jdk repo with >>> java.util.Base64. We should also update the tests and I have filed >>> JDK-8037873 for that. >>> >>> Thanks >>> Mandy >> >> The sun.misc.BASE64En/Decoder is MIME type, so it outputs the \r\n >> per 76 >> characters during encoding, and ignores/skip \r or \n when decoding. >> The new >> Base64.getEncoder/Decoder() returns the "basic" Base64 coder, which >> it never >> inserts line separator when output, and throws exception for any >> non-base64- >> alphabet character, including \r and \n. >> >> The only disadvantage/incompatibility (j.u.Base64.getMimeDecoer() vs >> sun.misc.BASE64Decoder) of switching to j.u.Base64 MIME type en/decoder >> is that the Base64 Mime decoder ignores/skips any non-base64-alphabet >> (including \r and \n), while sun.misc.BASE64Decoder appears to simply >> use the init value "-1" for any non-base64-alphabet character for >> decoding. >> >> I'm not familiar with the use scenario of ldap's Obj class, so I'm >> not sure if >> it matters (if it ever outputs/inputs > 76 character data, or even it >> does,if >> the difference matters). >> >> Btw, except getMimeEncoder(int ...) all other Base64.getXXXEn/Decoder() >> returns singleton, so the de/encoder cache might not be necessary. > > Thanks Sherman. Vinnie confirms that it should retain the current > behavior as there could be long-lived Java object in LDAP encoded with > JDK 8 for example and then retrieved with JDK 9. > > Here is the updated webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.01/ > > Thanks > Mandy From magnus.ihse.bursie at oracle.com Fri Mar 21 08:14:28 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 21 Mar 2014 09:14:28 +0100 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <532ADE09.7050602@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <53280AF0.5000502@oracle.com> <532ADE09.7050602@oracle.com> Message-ID: <532BF4E4.5080003@oracle.com> > I don't think this quite works as there are other variations not > captured here. Rather than "zipped" it should just be "external". > Whether the debuginfo files are zipped or not is then an additional > build time option. Additionally we still have to be able to control > the degree of stripping that is carried out. It doesn't make sense to > me to try and enumerate all possible combinations as top-level > configure options. > > Further, as Dan was saying, this doesn't capture the overlap between > "internal" and "external" because we still leave some symbols internal > even when creating the debuginfo file. > > So I don't think this proposed categorization works. We still have > three aspects: > - generating symbols into the object files > - stripping symbols from the final binaries > - saving symbols into an external form > > Each of which can potentally be varied (of course if you don't > generate symbols in the obj files stripping and saving are non issues). But they are not independent on each other! Unless you generate debug symbols, you can't strip them, nor save them elsewhere. So generating debug symbols (your item #1) is a prerequisite for the rest of your items. And while, technically, you can save symbols externally, and at the same time keep them in the binary, that does not make sense. So, in a practical sense, you are going to do #2 if you are going to do #3. And you can't zip external symbols unless you create a non-zipped version. And if you zip them, it does not make sense to keep the non-zipped version. And yes, we do not strip all debug information when creating external debug info. But there seems to be no real use case (not even for IcedTea, as it turned out) to want a completely stripped binary, I don't think that's worth discussing much. That's just part of how the external debuginfo scheme works. Can you give a more concrete example of the variations of your "aspects" that you think my suggested solution would not capture? /Magnus From david.holmes at oracle.com Fri Mar 21 08:57:06 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 21 Mar 2014 18:57:06 +1000 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <532BF4E4.5080003@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <53280AF0.5000502@oracle.com> <532ADE09.7050602@oracle.com> <532BF4E4.5080003@oracle.com> Message-ID: <532BFEE2.6080802@oracle.com> On 21/03/2014 6:14 PM, Magnus Ihse Bursie wrote: > >> I don't think this quite works as there are other variations not >> captured here. Rather than "zipped" it should just be "external". >> Whether the debuginfo files are zipped or not is then an additional >> build time option. Additionally we still have to be able to control >> the degree of stripping that is carried out. It doesn't make sense to >> me to try and enumerate all possible combinations as top-level >> configure options. >> >> Further, as Dan was saying, this doesn't capture the overlap between >> "internal" and "external" because we still leave some symbols internal >> even when creating the debuginfo file. >> >> So I don't think this proposed categorization works. We still have >> three aspects: >> - generating symbols into the object files >> - stripping symbols from the final binaries >> - saving symbols into an external form >> >> Each of which can potentally be varied (of course if you don't >> generate symbols in the obj files stripping and saving are non issues). > > But they are not independent on each other! > > Unless you generate debug symbols, you can't strip them, nor save them > elsewhere. So generating debug symbols (your item #1) is a prerequisite > for the rest of your items. Yes I just said that. :) > And while, technically, you can save symbols externally, and at the same > time keep them in the binary, that does not make sense. So, in a > practical sense, you are going to do #2 if you are going to do #3. But you can vary what is kept internally independent of what is made external. > And you can't zip external symbols unless you create a non-zipped > version. And if you zip them, it does not make sense to keep the > non-zipped version. zip vs non-zip is just an issue of disk space. It is not a fundamental configuration choice, just a variation on how external symbols are packaged. > And yes, we do not strip all debug information when creating external > debug info. But there seems to be no real use case (not even for > IcedTea, as it turned out) to want a completely stripped binary, I don't > think that's worth discussing much. That's just part of how the external > debuginfo scheme works. Umm we fully strip all our binaries in embedded. > Can you give a more concrete example of the variations of your "aspects" > that you think my suggested solution would not capture? I think I already have. There aren't tree simple choices here, there are three aspects, each of which could have different variants. If I could draw a flow chart easily I would but basically if you generate debug symbols you can then select what symbols are kept internally (the strip policy) and what are put externally (objcopy options), then for the external symbol file you can choose zipped or unzipped. Multiple inter-connected choices, not just three (or four if you add zipped) David > /Magnus From vincent.x.ryan at oracle.com Fri Mar 21 09:23:40 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 21 Mar 2014 09:23:40 +0000 Subject: Review request for 8035807: Convert use of sun.misc.BASE64Encoder/Decoder with java.util.Base64 In-Reply-To: <532BD40D.60506@oracle.com> References: <5329E3F7.6070007@oracle.com> <5329EFF4.9060008@oracle.com> <532B7035.9030905@oracle.com> <532BD40D.60506@oracle.com> Message-ID: <15E560D8-8B5B-4CC9-8DBA-DABEDBD81952@oracle.com> You?re right but we?ve never received a report of any charset interop. issues. Probably such a scenario has never been encountered by customers. On 21 Mar 2014, at 05:54, Xueming Shen wrote: > Obj.java:#482 > It appears sun.misc.BASE64Decoder.decodeBuffer(String) uses String's deprecated > String.getBytes(int srcBegin, int srcEnd, byte[] dst, int dstBegin). The proposed change > now uses the jvm's default charset. It might trigger incompatible behavior if the default > charset is not an ASCII compatible charset. But if the "Java object in LDAP was encoded > with the platform default charset" (as the new comment suggested), the old implementation > actually did not work on platform that the default encoding is not ASCII compatible, such > as the IBM ebcdic. > > -Sherman > > On 3/20/14 3:48 PM, Mandy Chung wrote: >> On 3/19/14 12:28 PM, Xueming Shen wrote: >>> On 03/19/2014 11:37 AM, Mandy Chung wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8035807 >>>> >>>> Webrev at: >>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.00/ >>>> >>>> This patch converts the last 2 references to sun.misc.BASE64Encoder/Decoder from the jdk repo with java.util.Base64. We should also update the tests and I have filed JDK-8037873 for that. >>>> >>>> Thanks >>>> Mandy >>> >>> The sun.misc.BASE64En/Decoder is MIME type, so it outputs the \r\n per 76 >>> characters during encoding, and ignores/skip \r or \n when decoding. The new >>> Base64.getEncoder/Decoder() returns the "basic" Base64 coder, which it never >>> inserts line separator when output, and throws exception for any non-base64- >>> alphabet character, including \r and \n. >>> >>> The only disadvantage/incompatibility (j.u.Base64.getMimeDecoer() vs >>> sun.misc.BASE64Decoder) of switching to j.u.Base64 MIME type en/decoder >>> is that the Base64 Mime decoder ignores/skips any non-base64-alphabet >>> (including \r and \n), while sun.misc.BASE64Decoder appears to simply >>> use the init value "-1" for any non-base64-alphabet character for decoding. >>> >>> I'm not familiar with the use scenario of ldap's Obj class, so I'm not sure if >>> it matters (if it ever outputs/inputs > 76 character data, or even it does,if >>> the difference matters). >>> >>> Btw, except getMimeEncoder(int ...) all other Base64.getXXXEn/Decoder() >>> returns singleton, so the de/encoder cache might not be necessary. >> >> Thanks Sherman. Vinnie confirms that it should retain the current behavior as there could be long-lived Java object in LDAP encoded with JDK 8 for example and then retrieved with JDK 9. >> >> Here is the updated webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.01/ >> >> Thanks >> Mandy > From dmitry.samersoff at oracle.com Fri Mar 21 09:36:10 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 21 Mar 2014 13:36:10 +0400 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <532BFEE2.6080802@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <53280AF0.5000502@oracle.com> <532ADE09.7050602@oracle.com> <532BF4E4.5080003@oracle.com> <532BFEE2.6080802@oracle.com> Message-ID: <532C080A.9020002@oracle.com> David, In practice, we don't have to much to keep internally. There are no reason to copy out some of .debug_* sections but keep other ones. So we have a matrix: (a) Strip mode: 1. full 2. keep symbols 3. keep symbols and .debug_* (b) Copy mode: 1. Copy all to ext file 2. Copy none to ext file (c) Compression mode: 1. none 2. per-section compression, SHF_GNU_COMPRESSED [1] 3. zip entire file Where *a2 + b2 + c2* have perfect sense, *a1 + b1 + c3* have no sense etc. -Dmitry Refs: 1. https://sourceware.org/bugzilla/show_bug.cgi?id=11819 http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01780.html -Dmitry On 2014-03-21 12:57, David Holmes wrote: > On 21/03/2014 6:14 PM, Magnus Ihse Bursie wrote: >> >>> I don't think this quite works as there are other variations not >>> captured here. Rather than "zipped" it should just be "external". >>> Whether the debuginfo files are zipped or not is then an additional >>> build time option. Additionally we still have to be able to control >>> the degree of stripping that is carried out. It doesn't make sense to >>> me to try and enumerate all possible combinations as top-level >>> configure options. >>> >>> Further, as Dan was saying, this doesn't capture the overlap between >>> "internal" and "external" because we still leave some symbols internal >>> even when creating the debuginfo file. >>> >>> So I don't think this proposed categorization works. We still have >>> three aspects: >>> - generating symbols into the object files >>> - stripping symbols from the final binaries >>> - saving symbols into an external form >>> >>> Each of which can potentally be varied (of course if you don't >>> generate symbols in the obj files stripping and saving are non issues). >> >> But they are not independent on each other! >> >> Unless you generate debug symbols, you can't strip them, nor save them >> elsewhere. So generating debug symbols (your item #1) is a prerequisite >> for the rest of your items. > > Yes I just said that. :) > >> And while, technically, you can save symbols externally, and at the same >> time keep them in the binary, that does not make sense. So, in a >> practical sense, you are going to do #2 if you are going to do #3. > > But you can vary what is kept internally independent of what is made > external. > >> And you can't zip external symbols unless you create a non-zipped >> version. And if you zip them, it does not make sense to keep the >> non-zipped version. > > zip vs non-zip is just an issue of disk space. It is not a fundamental > configuration choice, just a variation on how external symbols are > packaged. > >> And yes, we do not strip all debug information when creating external >> debug info. But there seems to be no real use case (not even for >> IcedTea, as it turned out) to want a completely stripped binary, I don't >> think that's worth discussing much. That's just part of how the external >> debuginfo scheme works. > > Umm we fully strip all our binaries in embedded. > >> Can you give a more concrete example of the variations of your "aspects" >> that you think my suggested solution would not capture? > > I think I already have. There aren't tree simple choices here, there are > three aspects, each of which could have different variants. > > If I could draw a flow chart easily I would but basically if you > generate debug symbols you can then select what symbols are kept > internally (the strip policy) and what are put externally (objcopy > options), then for the external symbol file you can choose zipped or > unzipped. > > Multiple inter-connected choices, not just three (or four if you add > zipped) > > David > >> /Magnus -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code. From david.holmes at oracle.com Fri Mar 21 11:13:48 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 21 Mar 2014 21:13:48 +1000 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <532C080A.9020002@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <53280AF0.5000502@oracle.com> <532ADE09.7050602@oracle.com> <532BF4E4.5080003@oracle.com> <532BFEE2.6080802@oracle.com> <532C080A.9020002@oracle.com> Message-ID: <532C1EEC.7040404@oracle.com> On 21/03/2014 7:36 PM, Dmitry Samersoff wrote: > David, > > In practice, we don't have to much to keep internally. > > There are no reason to copy out some of .debug_* sections but keep other > ones. I'm not familiar with exactly what the different strip options do but the point is this is covered by the strip-policy. > So we have a matrix: > > (a) Strip mode: > > 1. full > 2. keep symbols > 3. keep symbols and .debug_* > > > (b) Copy mode: > > 1. Copy all to ext file > 2. Copy none to ext file > > > (c) Compression mode: > > 1. none > 2. per-section compression, SHF_GNU_COMPRESSED [1] > 3. zip entire file > > Where > *a2 + b2 + c2* have perfect sense, So now your compression mode may apply to either the external file or the original? That's even more permutations. > *a1 + b1 + c3* have no sense etc. Why does full strip + copy-all + zip make no sense? It is exactly what we do with embedded builds. (Naturally you have to copy before you strip) David ----- > > -Dmitry > > > Refs: > 1. > https://sourceware.org/bugzilla/show_bug.cgi?id=11819 > http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01780.html > > > -Dmitry > > On 2014-03-21 12:57, David Holmes wrote: >> On 21/03/2014 6:14 PM, Magnus Ihse Bursie wrote: >>> >>>> I don't think this quite works as there are other variations not >>>> captured here. Rather than "zipped" it should just be "external". >>>> Whether the debuginfo files are zipped or not is then an additional >>>> build time option. Additionally we still have to be able to control >>>> the degree of stripping that is carried out. It doesn't make sense to >>>> me to try and enumerate all possible combinations as top-level >>>> configure options. >>>> >>>> Further, as Dan was saying, this doesn't capture the overlap between >>>> "internal" and "external" because we still leave some symbols internal >>>> even when creating the debuginfo file. >>>> >>>> So I don't think this proposed categorization works. We still have >>>> three aspects: >>>> - generating symbols into the object files >>>> - stripping symbols from the final binaries >>>> - saving symbols into an external form >>>> >>>> Each of which can potentally be varied (of course if you don't >>>> generate symbols in the obj files stripping and saving are non issues). >>> >>> But they are not independent on each other! >>> >>> Unless you generate debug symbols, you can't strip them, nor save them >>> elsewhere. So generating debug symbols (your item #1) is a prerequisite >>> for the rest of your items. >> >> Yes I just said that. :) >> >>> And while, technically, you can save symbols externally, and at the same >>> time keep them in the binary, that does not make sense. So, in a >>> practical sense, you are going to do #2 if you are going to do #3. >> >> But you can vary what is kept internally independent of what is made >> external. >> >>> And you can't zip external symbols unless you create a non-zipped >>> version. And if you zip them, it does not make sense to keep the >>> non-zipped version. >> >> zip vs non-zip is just an issue of disk space. It is not a fundamental >> configuration choice, just a variation on how external symbols are >> packaged. >> >>> And yes, we do not strip all debug information when creating external >>> debug info. But there seems to be no real use case (not even for >>> IcedTea, as it turned out) to want a completely stripped binary, I don't >>> think that's worth discussing much. That's just part of how the external >>> debuginfo scheme works. >> >> Umm we fully strip all our binaries in embedded. >> >>> Can you give a more concrete example of the variations of your "aspects" >>> that you think my suggested solution would not capture? >> >> I think I already have. There aren't tree simple choices here, there are >> three aspects, each of which could have different variants. >> >> If I could draw a flow chart easily I would but basically if you >> generate debug symbols you can then select what symbols are kept >> internally (the strip policy) and what are put externally (objcopy >> options), then for the external symbol file you can choose zipped or >> unzipped. >> >> Multiple inter-connected choices, not just three (or four if you add >> zipped) >> >> David >> >>> /Magnus > > From dmitry.samersoff at oracle.com Fri Mar 21 11:20:58 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 21 Mar 2014 15:20:58 +0400 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <532C1EEC.7040404@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <53280AF0.5000502@oracle.com> <532ADE09.7050602@oracle.com> <532BF4E4.5080003@oracle.com> <532BFEE2.6080802@oracle.com> <532C080A.9020002@oracle.com> <532C1EEC.7040404@oracle.com> Message-ID: <532C209A.7000609@oracle.com> David, My point was that we don't need in fine grained selection of elf sections on strip - three options are enough. > Why does full strip + copy-all + zip make no sense? It is exactly what > we do with embedded builds. (Naturally you have to copy before you > strip) Sorry! it should be: full strip + copy-none + zip -Dmitry On 2014-03-21 15:13, David Holmes wrote: > On 21/03/2014 7:36 PM, Dmitry Samersoff wrote: >> David, >> >> In practice, we don't have to much to keep internally. >> >> There are no reason to copy out some of .debug_* sections but keep other >> ones. > > I'm not familiar with exactly what the different strip options do but > the point is this is covered by the strip-policy. > >> So we have a matrix: >> >> (a) Strip mode: >> >> 1. full >> 2. keep symbols >> 3. keep symbols and .debug_* >> >> >> (b) Copy mode: >> >> 1. Copy all to ext file >> 2. Copy none to ext file >> >> >> (c) Compression mode: >> >> 1. none >> 2. per-section compression, SHF_GNU_COMPRESSED [1] >> 3. zip entire file >> >> Where >> *a2 + b2 + c2* have perfect sense, > > So now your compression mode may apply to either the external file or > the original? That's even more permutations. > >> *a1 + b1 + c3* have no sense etc. > > Why does full strip + copy-all + zip make no sense? It is exactly what > we do with embedded builds. (Naturally you have to copy before you strip) > > David > ----- > >> >> -Dmitry >> >> >> Refs: >> 1. >> https://sourceware.org/bugzilla/show_bug.cgi?id=11819 >> http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01780.html >> >> >> -Dmitry >> >> On 2014-03-21 12:57, David Holmes wrote: >>> On 21/03/2014 6:14 PM, Magnus Ihse Bursie wrote: >>>> >>>>> I don't think this quite works as there are other variations not >>>>> captured here. Rather than "zipped" it should just be "external". >>>>> Whether the debuginfo files are zipped or not is then an additional >>>>> build time option. Additionally we still have to be able to control >>>>> the degree of stripping th > *Subject:* Fwd: Re: Compute sizes of classes loat is carried out. It doesn't make sense to >>>>> me to try and enumerate all possible combinations as top-level >>>>> configure options. >>>>> >>>>> Further, as Dan was saying, this doesn't capture the overlap between >>>>> "internal" and "external" because we still leave some symbols internal >>>>> even when creating the debuginfo file. >>>>> >>>>> So I don't think this proposed categorization works. We still have >>>>> three aspects: >>>>> - generating symbols into the object files >>>>> - stripping symbols from the final binaries >>>>> - saving symbols into an external form >>>>> >>>>> Each of which can potentally be varied (of course if you don't >>>>> generate symbols in the obj files stripping and saving are non >>>>> issues). >>>> >>>> But they are not independent on each other! >>>> >>>> Unless you generate debug symbols, you can't strip them, nor save them >>>> elsewhere. So generating debug symbols (your item #1) is a prerequisite >>>> for the rest of your items. >>> >>> Yes I just said that. :) >>> >>>> And while, technically, you can save symbols externally, and at the >>>> same >>>> time keep them in the binary, that does not make sense. So, in a >>>> practical sense, you are going to do #2 if you are going to do #3. >>> >>> But you can vary what is kept internally independent of what is made >>> external. >>> >>>> And you can't zip external symbols unless you create a non-zipped >>>> version. And if you zip them, it does not make sense to keep the >>>> non-zipped version. >>> >>> zip vs non-zip is just an issue of disk space. It is not a fundamental >>> configuration choice, just a variation on how external symbols are >>> packaged. >>> >>>> And yes, we do not strip all debug information when creating external >>>> debug info. But there seems to be no real use case (not even for >>>> IcedTea, as it turned out) to want a completely stripped binary, I >>>> don't >>>> think that's worth discussing much. That's just part of how the >>>> external >>>> debuginfo scheme works. >>> >>> Umm we fully strip all our binaries in embedded. >>> >>>> Can you give a more concrete example of the variations of your >>>> "aspects" >>>> that you think my suggested solution would not capture? >>> >>> I think I already have. There aren't tree simple choices here, there are >>> three aspects, each of which could have different variants. >>> >>> If I could draw a flow chart easily I would but basically if you >>> generate debug symbols you can then select what symbols are kept >>> internally (the strip policy) and what are put externally (objcopy >>> options), then for the external symbol file you can choose zipped or >>> unzipped. >>> >>> Multiple inter-connected choices, not just three (or four if you add >>> zipped) >>> >>> David >>> >>>> /Magnus >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code. From roger.riggs at oracle.com Fri Mar 21 15:10:16 2014 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 21 Mar 2014 11:10:16 -0400 Subject: [9] Review request: new macro for conversion to jboolean In-Reply-To: <532A2B8E.9040707@oracle.com> References: <53270E65.4070001@oracle.com> <53273F9A.3080403@oracle.com> <5329E3B7.7000000@oracle.com> <5329F8A4.6030908@oracle.com> <5329F93A.2010205@oracle.com> <5329F91E.4050703@oracle.com> <532A2B8E.9040707@oracle.com> Message-ID: <532C5658.6050601@oracle.com> Hi Sergey, I didn't see any examples of the use case in this thread. The proposed name seems bulky and clumsy. In the snippet provided, it did not seem necessary to force the cast to jboolean. Both JNI_TRUE and JNI_FALSE are untyped constants. The macro would just as useful (if I understand the cases) without the cast. How useful is a simple definition as: #define IS_TRUE(obj) ((obj) ? JNI_TRUE : JNI_FALSE) then it would look ok to see these in sources: return IS_TRUE(obj); if (IS_TRUE(obj)) {....} jboolean ret = IS_TRUE(obj); The general purpose usage matches the general C conventions for true and false and match the JNI semantics. Roger On 3/19/2014 7:43 PM, Sergey Bylokhov wrote: > Thanks. > So if nobody objects, the final version will be: > > #define IS_NULL(obj) ((obj) == NULL) > #define JNU_IsNull(env,obj) ((obj) == NULL) > +#define TO_JBOOLEAN(obj) (jboolean) ((obj) ? JNI_TRUE : JNI_FALSE) > > > On 3/20/14 12:07 AM, roger riggs wrote: >> Hi, >> >> Well... When JNU_RETURN was added, there was a long discussion about >> NOT using JNU unless the JNI environment was an argument to the macro. >> >> So, the simple name is preferred. >> >> Roger >> >> On 3/19/2014 4:08 PM, Phil Race wrote: >>> PS .. so maybe whilst you are touching this file you could do >>> #define JNU_CHECK_NULL CHECK_NULL >>> #define JNU_CHECK_NULL_RETURN CHECK_NULL_RETURN >>> >>> so we could migrate to these (clearer) ones >>> >>> -phil. >>> >>> On 3/19/2014 1:05 PM, Phil Race wrote: >>>> I think having it start with "JNU_" is a good suggestion. >>>> I've been wondering over the last week or so if it would not have been >>>> better to have CHECK_NULL called JNU_CHECK_NULL to reduce collision >>>> chances >>>> and to make it clearer where it comes from .. >>>> >>>> -phil. >>>> >>>> On 3/19/2014 12:49 PM, Mike Duigou wrote: >>>>> Definitely a useful macro. >>>>> >>>>> I too would prefer a name like TO_JBOOLEAN since it reveals the >>>>> result type. Also all uppercase to identify it as a macro. If we >>>>> are paranoid and want to reduce the chance of a name collision >>>>> then JNU_TO_JBOOLEAN perhaps. >>>>> >>>>> I would also define the macro as: >>>>> >>>>> #define JNU_TO_JBOOLEAN(obj) (jboolean) ((obj) ? JNI_TRUE : >>>>> JNI_FALSE) >>>>> >>>>> so that the type of the result is explicit. Unfortunately jni.h >>>>> doesn't define JNI_TRUE or false with a cast to jboolean as they >>>>> probably should. >>>>> >>>>> Mike >>>>> >>>>> On Mar 19 2014, at 11:36 , Sergey Bylokhov >>>>> wrote: >>>>> >>>>>> Thanks Anthony! >>>>>> >>>>>> Can somebody from the core-libs team take a look? >>>>>> >>>>>> On 3/17/14 10:31 PM, Anthony Petrov wrote: >>>>>>> Personally, I'd call it to_jboolean(obj), but IS_TRUE(obj) >>>>>>> sounds good to me too. Either way, I'm fine with the fix. >>>>>>> >>>>>>> -- >>>>>>> best regards, >>>>>>> Anthony >>>>>>> >>>>>>> On 3/17/2014 7:01 PM, Sergey Bylokhov wrote: >>>>>>>> Hello. >>>>>>>> This review request is for the new macro, which simplify >>>>>>>> conversion to >>>>>>>> jboolean. It will be useful for fixing parfait warnings. >>>>>>>> >>>>>>>> We have a lot of places, where we cast some type to jboolean: >>>>>>>> >>>>>>>> BOOL = retVal; >>>>>>>> return (jboolean) retVal; >>>>>>>> >>>>>>>> WARNING: Expecting value of JNI primitive type jboolean: >>>>>>>> mismatched >>>>>>>> value retVal with size 32 bits, retVal used for conversion to >>>>>>>> int8 in return >>>>>>>> >>>>>>>> >>>>>>>> +++ b/src/share/native/common/jni_util.h Mon Mar 17 18:28:48 >>>>>>>> 2014 +0400 >>>>>>>> @@ -277,6 +277,7 @@ >>>>>>>> >>>>>>>> #define IS_NULL(obj) ((obj) == NULL) >>>>>>>> #define JNU_IsNull(env,obj) ((obj) == NULL) >>>>>>>> +#define IS_TRUE(obj) ((obj) ? JNI_TRUE : JNI_FALSE) >>>>>>>> >>>>>>>> I am not sure about the name, probably someone have a better >>>>>>>> suggestion? >>>>>>>> >>>>>>>> The fix is for jdk9/dev. >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, Sergey. >>>>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, Sergey. >>>>>> >>>> >>> >> > > From Sergey.Bylokhov at oracle.com Fri Mar 21 15:22:22 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 21 Mar 2014 19:22:22 +0400 Subject: [9] Review request: new macro for conversion to jboolean In-Reply-To: <532C5658.6050601@oracle.com> References: <53270E65.4070001@oracle.com> <53273F9A.3080403@oracle.com> <5329E3B7.7000000@oracle.com> <5329F8A4.6030908@oracle.com> <5329F93A.2010205@oracle.com> <5329F91E.4050703@oracle.com> <532A2B8E.9040707@oracle.com> <532C5658.6050601@oracle.com> Message-ID: <532C592E.1070205@oracle.com> On 3/21/14 7:10 PM, roger riggs wrote: > The macro would just as useful (if I understand the cases) without the > cast. > > How useful is a simple definition as: > > #define IS_TRUE(obj) ((obj) ? JNI_TRUE : JNI_FALSE) > > then it would look ok to see these in sources: > > return IS_TRUE(obj); > > if (IS_TRUE(obj)) {....} > > jboolean ret = IS_TRUE(obj); > > The general purpose usage matches the general C conventions for > true and false and match the JNI semantics. Actually that was my initial suggestion(name and usage). > > Roger > > > > On 3/19/2014 7:43 PM, Sergey Bylokhov wrote: >> Thanks. >> So if nobody objects, the final version will be: >> >> #define IS_NULL(obj) ((obj) == NULL) >> #define JNU_IsNull(env,obj) ((obj) == NULL) >> +#define TO_JBOOLEAN(obj) (jboolean) ((obj) ? JNI_TRUE : JNI_FALSE) >> >> >> On 3/20/14 12:07 AM, roger riggs wrote: >>> Hi, >>> >>> Well... When JNU_RETURN was added, there was a long discussion about >>> NOT using JNU unless the JNI environment was an argument to the macro. >>> >>> So, the simple name is preferred. >>> >>> Roger >>> >>> On 3/19/2014 4:08 PM, Phil Race wrote: >>>> PS .. so maybe whilst you are touching this file you could do >>>> #define JNU_CHECK_NULL CHECK_NULL >>>> #define JNU_CHECK_NULL_RETURN CHECK_NULL_RETURN >>>> >>>> so we could migrate to these (clearer) ones >>>> >>>> -phil. >>>> >>>> On 3/19/2014 1:05 PM, Phil Race wrote: >>>>> I think having it start with "JNU_" is a good suggestion. >>>>> I've been wondering over the last week or so if it would not have >>>>> been >>>>> better to have CHECK_NULL called JNU_CHECK_NULL to reduce >>>>> collision chances >>>>> and to make it clearer where it comes from .. >>>>> >>>>> -phil. >>>>> >>>>> On 3/19/2014 12:49 PM, Mike Duigou wrote: >>>>>> Definitely a useful macro. >>>>>> >>>>>> I too would prefer a name like TO_JBOOLEAN since it reveals the >>>>>> result type. Also all uppercase to identify it as a macro. If we >>>>>> are paranoid and want to reduce the chance of a name collision >>>>>> then JNU_TO_JBOOLEAN perhaps. >>>>>> >>>>>> I would also define the macro as: >>>>>> >>>>>> #define JNU_TO_JBOOLEAN(obj) (jboolean) ((obj) ? JNI_TRUE : >>>>>> JNI_FALSE) >>>>>> >>>>>> so that the type of the result is explicit. Unfortunately jni.h >>>>>> doesn't define JNI_TRUE or false with a cast to jboolean as they >>>>>> probably should. >>>>>> >>>>>> Mike >>>>>> >>>>>> On Mar 19 2014, at 11:36 , Sergey Bylokhov >>>>>> wrote: >>>>>> >>>>>>> Thanks Anthony! >>>>>>> >>>>>>> Can somebody from the core-libs team take a look? >>>>>>> >>>>>>> On 3/17/14 10:31 PM, Anthony Petrov wrote: >>>>>>>> Personally, I'd call it to_jboolean(obj), but IS_TRUE(obj) >>>>>>>> sounds good to me too. Either way, I'm fine with the fix. >>>>>>>> >>>>>>>> -- >>>>>>>> best regards, >>>>>>>> Anthony >>>>>>>> >>>>>>>> On 3/17/2014 7:01 PM, Sergey Bylokhov wrote: >>>>>>>>> Hello. >>>>>>>>> This review request is for the new macro, which simplify >>>>>>>>> conversion to >>>>>>>>> jboolean. It will be useful for fixing parfait warnings. >>>>>>>>> >>>>>>>>> We have a lot of places, where we cast some type to jboolean: >>>>>>>>> >>>>>>>>> BOOL = retVal; >>>>>>>>> return (jboolean) retVal; >>>>>>>>> >>>>>>>>> WARNING: Expecting value of JNI primitive type jboolean: >>>>>>>>> mismatched >>>>>>>>> value retVal with size 32 bits, retVal used for conversion to >>>>>>>>> int8 in return >>>>>>>>> >>>>>>>>> >>>>>>>>> +++ b/src/share/native/common/jni_util.h Mon Mar 17 >>>>>>>>> 18:28:48 2014 +0400 >>>>>>>>> @@ -277,6 +277,7 @@ >>>>>>>>> >>>>>>>>> #define IS_NULL(obj) ((obj) == NULL) >>>>>>>>> #define JNU_IsNull(env,obj) ((obj) == NULL) >>>>>>>>> +#define IS_TRUE(obj) ((obj) ? JNI_TRUE : JNI_FALSE) >>>>>>>>> >>>>>>>>> I am not sure about the name, probably someone have a better >>>>>>>>> suggestion? >>>>>>>>> >>>>>>>>> The fix is for jdk9/dev. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Best regards, Sergey. >>>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, Sergey. >>>>>>> >>>>> >>>> >>> >> >> > -- Best regards, Sergey. From vladimir.x.ivanov at oracle.com Fri Mar 21 15:49:01 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 21 Mar 2014 19:49:01 +0400 Subject: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types In-Reply-To: References: <5322E7C6.3050603@oracle.com> <659B1DAF-A57F-457F-9F68-8856795555BF@oracle.com> Message-ID: <532C5F6D.30500@oracle.com> Chris, Thanks for the feedback. What do you think about the following: http://cr.openjdk.java.net/~vlivanov/8037210/webrev.01/ Best regards, Vladimir Ivanov On 3/19/14 5:18 AM, Christian Thalinger wrote: > > On Mar 18, 2014, at 2:35 PM, John Rose > wrote: > >> On Mar 18, 2014, at 1:36 PM, Christian Thalinger >> > > wrote: >> >>> Why are we not using an Enum instead of an "untyped" byte? >> >> Byte is moderately typed, in the sense (which I rely on during >> development) that you can't assign an int or char to a byte w/o a cast. >> That's why it is not just a plain int. >> >> But those values (L_TYPE etc.) are used a lot as numbers, and >> specifically as low-level array indexes, and also comparisons (x < >> V_TYPE). >> >> To turn them into enums, we'd have to add lots of calls to >> '.ordinal()' to turn them right back to numbers. That dilutes >> (completely IMO) the value they have as enums to raise the level of >> the code. > > But without being strongly typed we get bugs like this one: > > @Override > - MethodHandle bindArgument(int pos, char basicType, Object value) { > + MethodHandle bindArgument(int pos, byte basicType, Object value) { > // If the member needs dispatching, do so. > if (pos == 0 && basicType == 'L') { > > I?m just saying that for the sake of maintainability and correctness an > Enum would be better. > >> >> ? John >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From rob.mckenna at oracle.com Fri Mar 21 17:43:12 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 21 Mar 2014 17:43:12 +0000 Subject: RFR: 8034944: (process) Improve subprocess handling on Solaris Message-ID: <532C7A30.6060904@oracle.com> Hi folks, I'd like to push this change into JDK8 & 7. There is other work going on in 9 which will supersede this fix so there is likely no point in pushing to that release. This is backport of the threadpool specific changes from https://bugs.openjdk.java.net/browse/JDK-6944584 along with some cosmetic changes in order to keep the code somewhat similar. In a nutshell a new process reaper thread was spawned for every Process created by the JDK. This fix runs these reaper threads in a thread pool to save on thread creation when creating a lot of new processes. http://cr.openjdk.java.net/~robm/8034944/webrev.01/ -Rob From rob.mckenna at oracle.com Fri Mar 21 18:23:20 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 21 Mar 2014 18:23:20 +0000 Subject: RFR: 8034944: (process) Improve subprocess handling on Solaris In-Reply-To: <532C7A30.6060904@oracle.com> References: <532C7A30.6060904@oracle.com> Message-ID: <532C8398.7030605@oracle.com> ..just realised I had an out of date webrev up there, I've just updated in place in case anyone is looking at it. -Rob On 21/03/14 17:43, Rob McKenna wrote: > Hi folks, > > I'd like to push this change into JDK8 & 7. There is other work going > on in 9 which will supersede this fix so there is likely no point in > pushing to that release. > > This is backport of the threadpool specific changes from > https://bugs.openjdk.java.net/browse/JDK-6944584 along with some > cosmetic changes in order to keep the code somewhat similar. > > In a nutshell a new process reaper thread was spawned for every > Process created by the JDK. This fix runs these reaper threads in a > thread pool to save on thread creation when creating a lot of new > processes. > > http://cr.openjdk.java.net/~robm/8034944/webrev.01/ > > -Rob > From martinrb at google.com Fri Mar 21 18:24:51 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 21 Mar 2014 11:24:51 -0700 Subject: RFR: 8034944: (process) Improve subprocess handling on Solaris In-Reply-To: <532C7A30.6060904@oracle.com> References: <532C7A30.6060904@oracle.com> Message-ID: Hi Rob, Thanks for doing this. In future, could you include a link to the bug URL? This is not really a "backport", but a ... sideport (?) from Linux to Solaris. My intent was always that such a change is valuable, but I didn't have the computing/testing resources to do it myself. Can you explain why Basic.java no longer needs to test the deferred close handling on Solaris? On Fri, Mar 21, 2014 at 10:43 AM, Rob McKenna wrote: > Hi folks, > > I'd like to push this change into JDK8 & 7. There is other work going on > in 9 which will supersede this fix so there is likely no point in pushing > to that release. > > This is backport of the threadpool specific changes from > https://bugs.openjdk.java.net/browse/JDK-6944584 along with some cosmetic > changes in order to keep the code somewhat similar. > > In a nutshell a new process reaper thread was spawned for every Process > created by the JDK. This fix runs these reaper threads in a thread pool to > save on thread creation when creating a lot of new processes. > > http://cr.openjdk.java.net/~robm/8034944/webrev.01/ > > -Rob > > From martinrb at google.com Fri Mar 21 18:32:02 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 21 Mar 2014 11:32:02 -0700 Subject: RFR: 8034944: (process) Improve subprocess handling on Solaris In-Reply-To: <532C8398.7030605@oracle.com> References: <532C7A30.6060904@oracle.com> <532C8398.7030605@oracle.com> Message-ID: OK, latest webrev looks much smaller, and appears to have only a port of changes from my changes to Linux from a few years ago. (please confirm). If so, Looks Good To Me. While looking at this, I think bumping the thread stack size by a factor of 2 (32k => 64k) seems timely, since native stack requirements (native sizes, alignments and overhead) seem to increase over time. But I'd put that into a separate change. On Fri, Mar 21, 2014 at 11:23 AM, Rob McKenna wrote: > ..just realised I had an out of date webrev up there, I've just updated in > place in case anyone is looking at it. > > -Rob > > > On 21/03/14 17:43, Rob McKenna wrote: > >> Hi folks, >> >> I'd like to push this change into JDK8 & 7. There is other work going on >> in 9 which will supersede this fix so there is likely no point in pushing >> to that release. >> >> This is backport of the threadpool specific changes from >> https://bugs.openjdk.java.net/browse/JDK-6944584 along with some >> cosmetic changes in order to keep the code somewhat similar. >> >> In a nutshell a new process reaper thread was spawned for every Process >> created by the JDK. This fix runs these reaper threads in a thread pool to >> save on thread creation when creating a lot of new processes. >> >> http://cr.openjdk.java.net/~robm/8034944/webrev.01/ >> >> -Rob >> >> > From rob.mckenna at oracle.com Fri Mar 21 18:40:41 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 21 Mar 2014 18:40:41 +0000 Subject: RFR: 8034944: (process) Improve subprocess handling on Solaris In-Reply-To: References: <532C7A30.6060904@oracle.com> <532C8398.7030605@oracle.com> Message-ID: <532C87A9.1000104@oracle.com> Just when I thought I beat you to it Martin. :) On 21/03/14 18:32, Martin Buchholz wrote: > OK, latest webrev looks much smaller, and appears to have only a port > of changes from my changes to Linux from a few years ago. (please > confirm). If so, Looks Good To Me. Yup, everything that is in this webrev comes from your port. (though conversely not everything from your fix was ported over) And yep, this is a "sideport". > > While looking at this, I think bumping the thread stack size by a > factor of 2 (32k => 64k) seems timely, since native stack requirements > (native sizes, alignments and overhead) seem to increase over time. > But I'd put that into a separate change. Thanks for the comment, I'll take an AI. -Rob > > > On Fri, Mar 21, 2014 at 11:23 AM, Rob McKenna > wrote: > > ..just realised I had an out of date webrev up there, I've just > updated in place in case anyone is looking at it. > > -Rob > > > On 21/03/14 17:43, Rob McKenna wrote: > > Hi folks, > > I'd like to push this change into JDK8 & 7. There is other > work going on in 9 which will supersede this fix so there is > likely no point in pushing to that release. > > This is backport of the threadpool specific changes from > https://bugs.openjdk.java.net/browse/JDK-6944584 along with > some cosmetic changes in order to keep the code somewhat similar. > > In a nutshell a new process reaper thread was spawned for > every Process created by the JDK. This fix runs these reaper > threads in a thread pool to save on thread creation when > creating a lot of new processes. > > http://cr.openjdk.java.net/~robm/8034944/webrev.01/ > > > -Rob > > > From john.r.rose at oracle.com Fri Mar 21 18:54:27 2014 From: john.r.rose at oracle.com (John Rose) Date: Fri, 21 Mar 2014 11:54:27 -0700 Subject: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types In-Reply-To: <532C5F6D.30500@oracle.com> References: <5322E7C6.3050603@oracle.com> <659B1DAF-A57F-457F-9F68-8856795555BF@oracle.com> <532C5F6D.30500@oracle.com> Message-ID: <0C91BFD6-57CA-47B1-8DD3-88E0E4B9D252@oracle.com> On Mar 21, 2014, at 8:49 AM, Vladimir Ivanov wrote: > Thanks for the feedback. > > What do you think about the following: > http://cr.openjdk.java.net/~vlivanov/8037210/webrev.01/ That looks nice. Strong typing; who woulda' thunk it. :-) The uses of ".ordinal()" are the extra cost relative to using just small integers. They seem totally reasonable in the code. I suggest either wrapping "ordinal" as something like "id" or else changing temp names like "id" to "ord", to reinforce the use of a common name. Don't make the enum class public. And especially don't make the mutable arrays public: + public static final BasicType[] ALL_TYPES = { L_TYPE, I_TYPE, J_TYPE, F_TYPE, D_TYPE, V_TYPE }; + public static final BasicType[] ARG_TYPES = { L_TYPE, I_TYPE, J_TYPE, F_TYPE, D_TYPE }; ? John P.S. That would only be safe if we had (what we don't yet) a notion of frozen arrays like: + public static final BasicType final[] ALL_TYPES = { L_TYPE, I_TYPE, J_TYPE, F_TYPE, D_TYPE, V_TYPE }; + public static final BasicType final[] ARG_TYPES = { L_TYPE, I_TYPE, J_TYPE, F_TYPE, D_TYPE }; From forax at univ-mlv.fr Fri Mar 21 19:18:13 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 21 Mar 2014 20:18:13 +0100 Subject: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types In-Reply-To: <0C91BFD6-57CA-47B1-8DD3-88E0E4B9D252@oracle.com> References: <5322E7C6.3050603@oracle.com> <659B1DAF-A57F-457F-9F68-8856795555BF@oracle.com> <532C5F6D.30500@oracle.com> <0C91BFD6-57CA-47B1-8DD3-88E0E4B9D252@oracle.com> Message-ID: <532C9075.70103@univ-mlv.fr> On 03/21/2014 07:54 PM, John Rose wrote: > On Mar 21, 2014, at 8:49 AM, Vladimir Ivanov > > > wrote: > >> Thanks for the feedback. >> >> What do you think about the following: >> http://cr.openjdk.java.net/~vlivanov/8037210/webrev.01/ >> > > That looks nice. Strong typing; who woulda' thunk it. :-) > > The uses of ".ordinal()" are the extra cost relative to using just > small integers. They seem totally reasonable in the code. > > I suggest either wrapping "ordinal" as something like "id" or else > changing temp names like "id" to "ord", to reinforce the use of a > common name. > > Don't make the enum class public. And especially don't make the > mutable arrays public: > > + public static final BasicType[] ALL_TYPES = { L_TYPE, I_TYPE, > J_TYPE, F_TYPE, D_TYPE, V_TYPE }; > + public static final BasicType[] ARG_TYPES = { L_TYPE, I_TYPE, > J_TYPE, F_TYPE, D_TYPE }; > > ? John > > P.S. That would only be safe if we had (what we don't yet) a notion of > frozen arrays like: > > + public static final BasicType final[] ALL_TYPES = { L_TYPE, I_TYPE, > J_TYPE, F_TYPE, D_TYPE, V_TYPE }; > + public static final BasicType final[] ARG_TYPES = { L_TYPE, I_TYPE, > J_TYPE, F_TYPE, D_TYPE }; or public static final BasicType[] ARG_TYPES = { L_TYPE, I_TYPE, J_TYPE, F_TYPE, D_TYPE }.frozen(); because frozen() is a dynamic property. R?mi From brian.burkhalter at oracle.com Fri Mar 21 19:41:27 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 21 Mar 2014 12:41:27 -0700 Subject: JDK 9 RFR of 8038163: Build failure on Mac OS 10.9.2 (Mavericks) due to warning treated as error Message-ID: Please review at your convenience: Issue: https://bugs.openjdk.java.net/browse/JDK-8038163 Patch: http://cr.openjdk.java.net/~bpb/8038163/ My only question would be whether the changed line 291 should instead be this: return (major > 1 || (major == 1 && minor >= 2)) ? JNI_TRUE : JNI_FALSE; Thanks, Brian From staffan.larsen at oracle.com Fri Mar 21 19:44:48 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 21 Mar 2014 20:44:48 +0100 Subject: JDK 9 RFR of 8038163: Build failure on Mac OS 10.9.2 (Mavericks) due to warning treated as error In-Reply-To: References: Message-ID: <50358464-31ED-4261-8A45-4CB6C66EB0D0@oracle.com> Looks good to me. The version with JNI_TRUE/JNI_FALSE is more correct, but I?m fine with either one. (note: this review request should have been sent to serviceability-dev). Thanks, /Staffan On 21 mar 2014, at 20:41, Brian Burkhalter wrote: > Please review at your convenience: > > Issue: https://bugs.openjdk.java.net/browse/JDK-8038163 > Patch: http://cr.openjdk.java.net/~bpb/8038163/ > > My only question would be whether the changed line 291 should instead be this: > > return (major > 1 || (major == 1 && minor >= 2)) ? JNI_TRUE : JNI_FALSE; > > Thanks, > > Brian From brian.burkhalter at oracle.com Fri Mar 21 19:50:39 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 21 Mar 2014 12:50:39 -0700 Subject: JDK 9 RFR of 8038163: Build failure on Mac OS 10.9.2 (Mavericks) due to warning treated as error In-Reply-To: <50358464-31ED-4261-8A45-4CB6C66EB0D0@oracle.com> References: <50358464-31ED-4261-8A45-4CB6C66EB0D0@oracle.com> Message-ID: <2D518DB1-EA2B-4C03-8BAF-6AE1C6BAFF7E@oracle.com> On Mar 21, 2014, at 12:44 PM, Staffan Larsen wrote: > Looks good to me. Thanks. > The version with JNI_TRUE/JNI_FALSE is more correct, but I?m fine with either one. Updated to this form: http://cr.openjdk.java.net/~bpb/8038163/webrev.01/ > (note: this review request should have been sent to serviceability-dev). I had no clue to which comp/sub-comp it belongs. What test would I run to verify this change (other than that if fixes the build)? Brian From Alan.Bateman at oracle.com Fri Mar 21 20:03:06 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 21 Mar 2014 20:03:06 +0000 Subject: JDK 9 RFR of 8038163: Build failure on Mac OS 10.9.2 (Mavericks) due to warning treated as error In-Reply-To: <2D518DB1-EA2B-4C03-8BAF-6AE1C6BAFF7E@oracle.com> References: <50358464-31ED-4261-8A45-4CB6C66EB0D0@oracle.com> <2D518DB1-EA2B-4C03-8BAF-6AE1C6BAFF7E@oracle.com> Message-ID: <532C9AFA.5000101@oracle.com> On 21/03/2014 19:50, Brian Burkhalter wrote: > On Mar 21, 2014, at 12:44 PM, Staffan Larsen wrote: > >> Looks good to me. > Thanks. > >> The version with JNI_TRUE/JNI_FALSE is more correct, but I?m fine with either one. > Updated to this form: > > http://cr.openjdk.java.net/~bpb/8038163/webrev.01/ > >> (note: this review request should have been sent to serviceability-dev). > I had no clue to which comp/sub-comp it belongs. > > What test would I run to verify this change (other than that if fixes the build)? > Looks good to me too. The tests to run are the Java Debug Interface (JDI) tests, they are in the jdk_jdi jtreg group. -Alan. From Alan.Bateman at oracle.com Fri Mar 21 20:38:21 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 21 Mar 2014 20:38:21 +0000 Subject: RFR: 8034944: (process) Improve subprocess handling on Solaris In-Reply-To: <532C7A30.6060904@oracle.com> References: <532C7A30.6060904@oracle.com> Message-ID: <532CA33D.3030502@oracle.com> On 21/03/2014 17:43, Rob McKenna wrote: > : > > In a nutshell a new process reaper thread was spawned for every > Process created by the JDK. This fix runs these reaper threads in a > thread pool to save on thread creation when creating a lot of new > processes. > > http://cr.openjdk.java.net/~robm/8034944/webrev.01/ Thanks Rob, it's good to get this change into the Solaris implementation. I looked through Martin's original changes in JDK-6944584 and the "side-port" as you've called it looks good. -Alan. From mandy.chung at oracle.com Fri Mar 21 21:28:20 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 21 Mar 2014 14:28:20 -0700 Subject: Review request for 8038177 Eliminate unnecessary dependency to sun.security.action Message-ID: <532CAEF4.30407@oracle.com> This is the second patch to eliminate the dependencies to sun.security.action: https://bugs.openjdk.java.net/browse/JDK-8038177 Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8038177/webrev.00/ Mandy From mike.duigou at oracle.com Fri Mar 21 21:38:26 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 21 Mar 2014 14:38:26 -0700 Subject: [9] Review request: new macro for conversion to jboolean In-Reply-To: <532C5658.6050601@oracle.com> References: <53270E65.4070001@oracle.com> <53273F9A.3080403@oracle.com> <5329E3B7.7000000@oracle.com> <5329F8A4.6030908@oracle.com> <5329F93A.2010205@oracle.com> <5329F91E.4050703@oracle.com> <532A2B8E.9040707@oracle.com> <532C5658.6050601@oracle.com> Message-ID: What if we just abandon adding an IS_TRUE / TO_JBOOLEAN macro for now. I would like to address adding (jboolean) casts to jni.h which I suspect would help with the static analysis issues encountered. For now just use the explicit ? JNI_TRUE : JNI_FALSE whenever a jboolean value is needed and we can refactor the naming of the macro, if any is required, later. Mike On Mar 21 2014, at 08:10 , roger riggs wrote: > Hi Sergey, > > I didn't see any examples of the use case in this thread. The proposed name seems bulky and clumsy. > > In the snippet provided, it did not seem necessary to force the cast to jboolean. > Both JNI_TRUE and JNI_FALSE are untyped constants. > > The macro would just as useful (if I understand the cases) without the cast. > > How useful is a simple definition as: > > #define IS_TRUE(obj) ((obj) ? JNI_TRUE : JNI_FALSE) > > then it would look ok to see these in sources: > > return IS_TRUE(obj); > > if (IS_TRUE(obj)) {....} > > jboolean ret = IS_TRUE(obj); > > The general purpose usage matches the general C conventions for > true and false and match the JNI semantics. > > Roger > > > > On 3/19/2014 7:43 PM, Sergey Bylokhov wrote: >> Thanks. >> So if nobody objects, the final version will be: >> >> #define IS_NULL(obj) ((obj) == NULL) >> #define JNU_IsNull(env,obj) ((obj) == NULL) >> +#define TO_JBOOLEAN(obj) (jboolean) ((obj) ? JNI_TRUE : JNI_FALSE) >> >> >> On 3/20/14 12:07 AM, roger riggs wrote: >>> Hi, >>> >>> Well... When JNU_RETURN was added, there was a long discussion about >>> NOT using JNU unless the JNI environment was an argument to the macro. >>> >>> So, the simple name is preferred. >>> >>> Roger >>> >>> On 3/19/2014 4:08 PM, Phil Race wrote: >>>> PS .. so maybe whilst you are touching this file you could do >>>> #define JNU_CHECK_NULL CHECK_NULL >>>> #define JNU_CHECK_NULL_RETURN CHECK_NULL_RETURN >>>> >>>> so we could migrate to these (clearer) ones >>>> >>>> -phil. >>>> >>>> On 3/19/2014 1:05 PM, Phil Race wrote: >>>>> I think having it start with "JNU_" is a good suggestion. >>>>> I've been wondering over the last week or so if it would not have been >>>>> better to have CHECK_NULL called JNU_CHECK_NULL to reduce collision chances >>>>> and to make it clearer where it comes from .. >>>>> >>>>> -phil. >>>>> >>>>> On 3/19/2014 12:49 PM, Mike Duigou wrote: >>>>>> Definitely a useful macro. >>>>>> >>>>>> I too would prefer a name like TO_JBOOLEAN since it reveals the result type. Also all uppercase to identify it as a macro. If we are paranoid and want to reduce the chance of a name collision then JNU_TO_JBOOLEAN perhaps. >>>>>> >>>>>> I would also define the macro as: >>>>>> >>>>>> #define JNU_TO_JBOOLEAN(obj) (jboolean) ((obj) ? JNI_TRUE : JNI_FALSE) >>>>>> >>>>>> so that the type of the result is explicit. Unfortunately jni.h doesn't define JNI_TRUE or false with a cast to jboolean as they probably should. >>>>>> >>>>>> Mike >>>>>> >>>>>> On Mar 19 2014, at 11:36 , Sergey Bylokhov wrote: >>>>>> >>>>>>> Thanks Anthony! >>>>>>> >>>>>>> Can somebody from the core-libs team take a look? >>>>>>> >>>>>>> On 3/17/14 10:31 PM, Anthony Petrov wrote: >>>>>>>> Personally, I'd call it to_jboolean(obj), but IS_TRUE(obj) sounds good to me too. Either way, I'm fine with the fix. >>>>>>>> >>>>>>>> -- >>>>>>>> best regards, >>>>>>>> Anthony >>>>>>>> >>>>>>>> On 3/17/2014 7:01 PM, Sergey Bylokhov wrote: >>>>>>>>> Hello. >>>>>>>>> This review request is for the new macro, which simplify conversion to >>>>>>>>> jboolean. It will be useful for fixing parfait warnings. >>>>>>>>> >>>>>>>>> We have a lot of places, where we cast some type to jboolean: >>>>>>>>> >>>>>>>>> BOOL = retVal; >>>>>>>>> return (jboolean) retVal; >>>>>>>>> >>>>>>>>> WARNING: Expecting value of JNI primitive type jboolean: mismatched >>>>>>>>> value retVal with size 32 bits, retVal used for conversion to int8 in return >>>>>>>>> >>>>>>>>> >>>>>>>>> +++ b/src/share/native/common/jni_util.h Mon Mar 17 18:28:48 2014 +0400 >>>>>>>>> @@ -277,6 +277,7 @@ >>>>>>>>> >>>>>>>>> #define IS_NULL(obj) ((obj) == NULL) >>>>>>>>> #define JNU_IsNull(env,obj) ((obj) == NULL) >>>>>>>>> +#define IS_TRUE(obj) ((obj) ? JNI_TRUE : JNI_FALSE) >>>>>>>>> >>>>>>>>> I am not sure about the name, probably someone have a better suggestion? >>>>>>>>> >>>>>>>>> The fix is for jdk9/dev. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Best regards, Sergey. >>>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, Sergey. >>>>>>> >>>>> >>>> >>> >> >> > From vladimir.x.ivanov at oracle.com Fri Mar 21 22:08:07 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Sat, 22 Mar 2014 02:08:07 +0400 Subject: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types In-Reply-To: <0C91BFD6-57CA-47B1-8DD3-88E0E4B9D252@oracle.com> References: <5322E7C6.3050603@oracle.com> <659B1DAF-A57F-457F-9F68-8856795555BF@oracle.com> <532C5F6D.30500@oracle.com> <0C91BFD6-57CA-47B1-8DD3-88E0E4B9D252@oracle.com> Message-ID: <532CB847.3080809@oracle.com> John, thanks for the feedback. Updated webrev: http://cr.openjdk.java.net/~vlivanov/8037210/webrev.02 Also moved LambdaForm.testShortenSignature() into a stand-alone unit test. Best regards, Vladimir Ivanov On 3/21/14 10:54 PM, John Rose wrote: > On Mar 21, 2014, at 8:49 AM, Vladimir Ivanov > > wrote: > >> Thanks for the feedback. >> >> What do you think about the following: >> http://cr.openjdk.java.net/~vlivanov/8037210/webrev.01/ > > That looks nice. Strong typing; who woulda' thunk it. :-) > > The uses of ".ordinal()" are the extra cost relative to using just small > integers. They seem totally reasonable in the code. > > I suggest either wrapping "ordinal" as something like "id" or else > changing temp names like "id" to "ord", to reinforce the use of a common > name. > > Don't make the enum class public. And especially don't make the mutable > arrays public: > > + public static final BasicType[] ALL_TYPES = { L_TYPE, I_TYPE, > J_TYPE, F_TYPE, D_TYPE, V_TYPE }; > + public static final BasicType[] ARG_TYPES = { L_TYPE, I_TYPE, > J_TYPE, F_TYPE, D_TYPE }; > > ? John > > P.S. That would only be safe if we had (what we don't yet) a notion of > frozen arrays like: > > + public static final BasicType final[] ALL_TYPES = { L_TYPE, > I_TYPE, J_TYPE, F_TYPE, D_TYPE, V_TYPE }; > + public static final BasicType final[] ARG_TYPES = { L_TYPE, > I_TYPE, J_TYPE, F_TYPE, D_TYPE }; > > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From jeremymanson at google.com Sat Mar 22 00:18:52 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Fri, 21 Mar 2014 17:18:52 -0700 Subject: StringBuilder version of java.util.regex.Matcher.append* In-Reply-To: References: <532AA782.5030809@gmail.com> <532B246F.20302@oracle.com> Message-ID: So, this is all a little opaque to me. How do we make the go/no-go decision on something like this? Everyone who has chimed in seems to think it is a good idea. Jeremy On Thu, Mar 20, 2014 at 10:38 AM, Jeremy Manson wrote: > Sherman, > > If you had released it then (which you wouldn't have been able to do, > because you would have to wait another two years for Java 7), you would > have found that it improved performance even with C2. It is only > post-escape-analysis that the performance in C2 equalized. > > Anyway, I think adding the StringBuilder variant and deferring / dealing > with the Appendable differently is the right approach, FWIW. > > Jeremy > > > On Thu, Mar 20, 2014 at 10:25 AM, Xueming Shen wrote: > >> 2009? I do have something similar back to 2009 :-) >> >> http://cr.openjdk.java.net/~sherman/regex_replace/webrev/ >> >> Then the ball was dropped around the discussion of whether or not >> the IOE should be thrown. >> >> But if we are going to/have to have explicit StringBuilder/Buffer pair >> anyway, then we can keep the Appendable version as private for now >> and deal with the StringBuilder and Appendable as two separate >> issues. >> >> -Sherman >> >> >> On 03/20/2014 09:52 AM, Jeremy Manson wrote: >> >>> That's definitely an improvement - I think that when I wrote this (circa >>> 2009), I didn't think about Appendable. >>> >>> I take it my argument convinced someone? :) >>> >>> Jeremy >>> >>> >>> On Thu, Mar 20, 2014 at 1:32 AM, Peter Levart >>> wrote: >>> >>> On 03/19/2014 06:51 PM, Jeremy Manson wrote: >>>> >>>> I'm told that the diff didn't make it. I've put it in a Google drive >>>>> folder... >>>>> >>>>> https://drive.google.com/file/d/0B_GaXa6O4K5LY3Y0aHpranM3aEU/ >>>>> edit?usp=sharing >>>>> >>>>> Jeremy >>>>> >>>>> Hi Jeremy, >>>> >>>> Your factoring-out of expandReplacement() method exposed an opportunity >>>> to >>>> further optimize the code. Instead of creating intermediate >>>> StringBuilder >>>> instance for each expandReplacement() call, this method could append >>>> directly to resulting StringBuffer/StringBuilder, like in the following: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/MatcherWithStringBuilder/ >>>> webrev.01/ >>>> >>>> >>>> Regards, Peter >>>> >>>> >>>> >>>> On Wed, Mar 19, 2014 at 10:41 AM, Jeremy Manson< >>>>> jeremymanson at google.com> >>>>> wrote: >>>>> >>>>> Hi folks, >>>>> >>>>>> We've had this internally for a while, and I keep meaning to bring it >>>>>> up >>>>>> here. The Matcher class has a few public methods that take >>>>>> StringBuffers, >>>>>> and we've found it useful to add similar versions that take >>>>>> StringBuilders. >>>>>> >>>>>> It has two benefits: >>>>>> >>>>>> - Users don't have to convert from one to the other when they want to >>>>>> use >>>>>> the method in question. The symmetry is nice. >>>>>> >>>>>> - The StringBuilder variants are faster (if lock optimizations don't >>>>>> kick >>>>>> in, which happens in the interpreter and the client compiler). For >>>>>> interpreted / client-compiled code, we saw something like a 25% >>>>>> speedup >>>>>> on >>>>>> String.replaceAll(), which calls into this code. >>>>>> >>>>>> Any interest? Diff attached. >>>>>> >>>>>> Jeremy >>>>>> >>>>>> >>>>>> >> > From Sergey.Bylokhov at oracle.com Sat Mar 22 00:30:58 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 22 Mar 2014 04:30:58 +0400 Subject: [9] Review request: new macro for conversion to jboolean In-Reply-To: References: <53270E65.4070001@oracle.com> <53273F9A.3080403@oracle.com> <5329E3B7.7000000@oracle.com> <5329F8A4.6030908@oracle.com> <5329F93A.2010205@oracle.com> <5329F91E.4050703@oracle.com> <532A2B8E.9040707@oracle.com> <532C5658.6050601@oracle.com> Message-ID: <532CD9C2.6070108@oracle.com> On 3/22/14 1:38 AM, Mike Duigou wrote: > What if we just abandon adding an IS_TRUE / TO_JBOOLEAN macro for now. > > I would like to address adding (jboolean) casts to jni.h which I suspect would help with the static analysis issues encountered. The problem, which I try to solve occurs, when we try to cast some things like BOOL(int32) to jboolean(int8) and we have a chance to invert result from true to false. I am not sure, that I understand how new (jboolean) cast in jni.h solve the problem? Parfait does not warn about assignments from JNI_TRUE to jboolean, so I think it smart enough > For now just use the explicit ? JNI_TRUE : JNI_FALSE whenever a jboolean value is needed and we can refactor the naming of the macro, if any is required, later. Sure, but I don't want to copy this across the files, and want to use macro at least. The question is where to place it. > > Mike > > On Mar 21 2014, at 08:10 , roger riggs wrote: > >> Hi Sergey, >> >> I didn't see any examples of the use case in this thread. The proposed name seems bulky and clumsy. >> >> In the snippet provided, it did not seem necessary to force the cast to jboolean. >> Both JNI_TRUE and JNI_FALSE are untyped constants. >> >> The macro would just as useful (if I understand the cases) without the cast. >> >> How useful is a simple definition as: >> >> #define IS_TRUE(obj) ((obj) ? JNI_TRUE : JNI_FALSE) >> >> then it would look ok to see these in sources: >> >> return IS_TRUE(obj); >> >> if (IS_TRUE(obj)) {....} >> >> jboolean ret = IS_TRUE(obj); >> >> The general purpose usage matches the general C conventions for >> true and false and match the JNI semantics. >> >> Roger >> >> >> >> On 3/19/2014 7:43 PM, Sergey Bylokhov wrote: >>> Thanks. >>> So if nobody objects, the final version will be: >>> >>> #define IS_NULL(obj) ((obj) == NULL) >>> #define JNU_IsNull(env,obj) ((obj) == NULL) >>> +#define TO_JBOOLEAN(obj) (jboolean) ((obj) ? JNI_TRUE : JNI_FALSE) >>> >>> >>> On 3/20/14 12:07 AM, roger riggs wrote: >>>> Hi, >>>> >>>> Well... When JNU_RETURN was added, there was a long discussion about >>>> NOT using JNU unless the JNI environment was an argument to the macro. >>>> >>>> So, the simple name is preferred. >>>> >>>> Roger >>>> >>>> On 3/19/2014 4:08 PM, Phil Race wrote: >>>>> PS .. so maybe whilst you are touching this file you could do >>>>> #define JNU_CHECK_NULL CHECK_NULL >>>>> #define JNU_CHECK_NULL_RETURN CHECK_NULL_RETURN >>>>> >>>>> so we could migrate to these (clearer) ones >>>>> >>>>> -phil. >>>>> >>>>> On 3/19/2014 1:05 PM, Phil Race wrote: >>>>>> I think having it start with "JNU_" is a good suggestion. >>>>>> I've been wondering over the last week or so if it would not have been >>>>>> better to have CHECK_NULL called JNU_CHECK_NULL to reduce collision chances >>>>>> and to make it clearer where it comes from .. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 3/19/2014 12:49 PM, Mike Duigou wrote: >>>>>>> Definitely a useful macro. >>>>>>> >>>>>>> I too would prefer a name like TO_JBOOLEAN since it reveals the result type. Also all uppercase to identify it as a macro. If we are paranoid and want to reduce the chance of a name collision then JNU_TO_JBOOLEAN perhaps. >>>>>>> >>>>>>> I would also define the macro as: >>>>>>> >>>>>>> #define JNU_TO_JBOOLEAN(obj) (jboolean) ((obj) ? JNI_TRUE : JNI_FALSE) >>>>>>> >>>>>>> so that the type of the result is explicit. Unfortunately jni.h doesn't define JNI_TRUE or false with a cast to jboolean as they probably should. >>>>>>> >>>>>>> Mike >>>>>>> >>>>>>> On Mar 19 2014, at 11:36 , Sergey Bylokhov wrote: >>>>>>> >>>>>>>> Thanks Anthony! >>>>>>>> >>>>>>>> Can somebody from the core-libs team take a look? >>>>>>>> >>>>>>>> On 3/17/14 10:31 PM, Anthony Petrov wrote: >>>>>>>>> Personally, I'd call it to_jboolean(obj), but IS_TRUE(obj) sounds good to me too. Either way, I'm fine with the fix. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> best regards, >>>>>>>>> Anthony >>>>>>>>> >>>>>>>>> On 3/17/2014 7:01 PM, Sergey Bylokhov wrote: >>>>>>>>>> Hello. >>>>>>>>>> This review request is for the new macro, which simplify conversion to >>>>>>>>>> jboolean. It will be useful for fixing parfait warnings. >>>>>>>>>> >>>>>>>>>> We have a lot of places, where we cast some type to jboolean: >>>>>>>>>> >>>>>>>>>> BOOL = retVal; >>>>>>>>>> return (jboolean) retVal; >>>>>>>>>> >>>>>>>>>> WARNING: Expecting value of JNI primitive type jboolean: mismatched >>>>>>>>>> value retVal with size 32 bits, retVal used for conversion to int8 in return >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> +++ b/src/share/native/common/jni_util.h Mon Mar 17 18:28:48 2014 +0400 >>>>>>>>>> @@ -277,6 +277,7 @@ >>>>>>>>>> >>>>>>>>>> #define IS_NULL(obj) ((obj) == NULL) >>>>>>>>>> #define JNU_IsNull(env,obj) ((obj) == NULL) >>>>>>>>>> +#define IS_TRUE(obj) ((obj) ? JNI_TRUE : JNI_FALSE) >>>>>>>>>> >>>>>>>>>> I am not sure about the name, probably someone have a better suggestion? >>>>>>>>>> >>>>>>>>>> The fix is for jdk9/dev. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Best regards, Sergey. >>>>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, Sergey. >>>>>>>> >>> -- Best regards, Sergey. From brian.burkhalter at oracle.com Sat Mar 22 01:01:17 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 21 Mar 2014 18:01:17 -0700 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: <532A9DA6.6080707@oracle.com> References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <531EC6BF.4050701@oracle.com> <4742E0AD-8D87-4F22-8F23-779BDF3A58FE@oracle.com> <5320240C.60304@gmail.com> <5322DC66.5070003@gmail.com> <96B8A54B-77FC-4973-8A92-2344A1621F43@oracle.com> <532A290A.7090307@gmail.com> <532A935C.2060604@gmail.com> <532A9DA6.6080707@oracle.com> Message-ID: <26843449-4DCC-4A74-BE32-29836D5FC9F2@oracle.com> On Mar 20, 2014, at 12:49 AM, Aleksey Shipilev wrote: > On 03/20/2014 11:06 AM, Peter Levart wrote: >> I was thinking about last night, for question: "Why is this >> double-checked non-volatile-then-volatile trick not any faster than pure >> volatile variant even on ARM platform where volatile read should have >> some penalty compared to normal read?", might be in the fact that >> Raspberry Pi is a single-core/single-thread "machine". Would anyone with >> JVM JIT compiler expertise care to share some insight? I suspect that on >> such platform, the compiler optimizes volatile accesses so that they are >> performed without otherwise necessary memory fences... > > Yes, at least C2 is known to not emit memory fences on uniprocessor > machines. You need to have a multicore ARM. If you are still interested, > contact me privately and I can arrange the access to my personal > quad-core Cortex-A9. This is all very interesting but I would like to have closure so to speak on the patches that I posted. I think the questions still unresolved are: 1) Is a change of toString() necessary? 2) If #1 is ?yes? then which version of the patch? (I think the most recent) 3) Are the other changes OK which are unrelated to toString()? Thanks, Brian From xueming.shen at oracle.com Sat Mar 22 02:34:02 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 21 Mar 2014 19:34:02 -0700 Subject: StringBuilder version of java.util.regex.Matcher.append* In-Reply-To: References: <532AA782.5030809@gmail.com> <532B246F.20302@oracle.com> Message-ID: <532CF69A.3060301@oracle.com> let's add the StringBuilder method(s), if you can provide an updated version, I can run the rest (since it's to add new api, there is an internal CCC process need to go through). -Sherman On 3/21/14 5:18 PM, Jeremy Manson wrote: > So, this is all a little opaque to me. How do we make the go/no-go > decision on something like this? Everyone who has chimed in seems to > think it is a good idea. > > Jeremy > > > On Thu, Mar 20, 2014 at 10:38 AM, Jeremy Manson > > wrote: > > Sherman, > > If you had released it then (which you wouldn't have been able to > do, because you would have to wait another two years for Java 7), > you would have found that it improved performance even with C2. > It is only post-escape-analysis that the performance in C2 equalized. > > Anyway, I think adding the StringBuilder variant and deferring / > dealing with the Appendable differently is the right approach, FWIW. > > Jeremy > > > On Thu, Mar 20, 2014 at 10:25 AM, Xueming Shen > > wrote: > > 2009? I do have something similar back to 2009 :-) > > http://cr.openjdk.java.net/~sherman/regex_replace/webrev/ > > > Then the ball was dropped around the discussion of whether or not > the IOE should be thrown. > > But if we are going to/have to have explicit > StringBuilder/Buffer pair > anyway, then we can keep the Appendable version as private for now > and deal with the StringBuilder and Appendable as two separate > issues. > > -Sherman > > > On 03/20/2014 09:52 AM, Jeremy Manson wrote: > > That's definitely an improvement - I think that when I > wrote this (circa > 2009), I didn't think about Appendable. > > I take it my argument convinced someone? :) > > Jeremy > > > On Thu, Mar 20, 2014 at 1:32 AM, Peter > Levart >wrote: > > On 03/19/2014 06:51 PM, Jeremy Manson wrote: > > I'm told that the diff didn't make it. I've put > it in a Google drive > folder... > > https://drive.google.com/file/d/0B_GaXa6O4K5LY3Y0aHpranM3aEU/ > edit?usp=sharing > > Jeremy > > Hi Jeremy, > > Your factoring-out of expandReplacement() method > exposed an opportunity to > further optimize the code. Instead of creating > intermediate StringBuilder > instance for each expandReplacement() call, this > method could append > directly to resulting StringBuffer/StringBuilder, like > in the following: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/MatcherWithStringBuilder/ > > webrev.01/ > > > Regards, Peter > > > > On Wed, Mar 19, 2014 at 10:41 AM, Jeremy > Manson > > wrote: > > Hi folks, > > We've had this internally for a while, and I > keep meaning to bring it up > here. The Matcher class has a few public > methods that take > StringBuffers, > and we've found it useful to add similar > versions that take > StringBuilders. > > It has two benefits: > > - Users don't have to convert from one to the > other when they want to use > the method in question. The symmetry is nice. > > - The StringBuilder variants are faster (if > lock optimizations don't kick > in, which happens in the interpreter and the > client compiler). For > interpreted / client-compiled code, we saw > something like a 25% speedup > on > String.replaceAll(), which calls into this code. > > Any interest? Diff attached. > > Jeremy > > > > > From mandy.chung at oracle.com Sat Mar 22 03:22:17 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 21 Mar 2014 20:22:17 -0700 Subject: Review request for 8035807: Convert use of sun.misc.BASE64Encoder/Decoder with java.util.Base64 In-Reply-To: <15E560D8-8B5B-4CC9-8DBA-DABEDBD81952@oracle.com> References: <5329E3F7.6070007@oracle.com> <5329EFF4.9060008@oracle.com> <532B7035.9030905@oracle.com> <532BD40D.60506@oracle.com> <15E560D8-8B5B-4CC9-8DBA-DABEDBD81952@oracle.com> Message-ID: <532D01E9.70001@oracle.com> Good catch Sherman. Vinnie - what's your recommendation for this LDAP change having both encode/decode uses the platform default charset (rather than retaining the old interop issue)? It's an incompatible change and I'll file a CCC to track this. Mandy On 3/21/2014 2:23 AM, Vincent Ryan wrote: > You?re right but we?ve never received a report of any charset interop. issues. > Probably such a scenario has never been encountered by customers. > > > On 21 Mar 2014, at 05:54, Xueming Shen wrote: > >> Obj.java:#482 >> It appears sun.misc.BASE64Decoder.decodeBuffer(String) uses String's deprecated >> String.getBytes(int srcBegin, int srcEnd, byte[] dst, int dstBegin). The proposed change >> now uses the jvm's default charset. It might trigger incompatible behavior if the default >> charset is not an ASCII compatible charset. But if the "Java object in LDAP was encoded >> with the platform default charset" (as the new comment suggested), the old implementation >> actually did not work on platform that the default encoding is not ASCII compatible, such >> as the IBM ebcdic. >> >> -Sherman >> >> On 3/20/14 3:48 PM, Mandy Chung wrote: >>> On 3/19/14 12:28 PM, Xueming Shen wrote: >>>> On 03/19/2014 11:37 AM, Mandy Chung wrote: >>>>> https://bugs.openjdk.java.net/browse/JDK-8035807 >>>>> >>>>> Webrev at: >>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.00/ >>>>> >>>>> This patch converts the last 2 references to sun.misc.BASE64Encoder/Decoder from the jdk repo with java.util.Base64. We should also update the tests and I have filed JDK-8037873 for that. >>>>> >>>>> Thanks >>>>> Mandy >>>> The sun.misc.BASE64En/Decoder is MIME type, so it outputs the \r\n per 76 >>>> characters during encoding, and ignores/skip \r or \n when decoding. The new >>>> Base64.getEncoder/Decoder() returns the "basic" Base64 coder, which it never >>>> inserts line separator when output, and throws exception for any non-base64- >>>> alphabet character, including \r and \n. >>>> >>>> The only disadvantage/incompatibility (j.u.Base64.getMimeDecoer() vs >>>> sun.misc.BASE64Decoder) of switching to j.u.Base64 MIME type en/decoder >>>> is that the Base64 Mime decoder ignores/skips any non-base64-alphabet >>>> (including \r and \n), while sun.misc.BASE64Decoder appears to simply >>>> use the init value "-1" for any non-base64-alphabet character for decoding. >>>> >>>> I'm not familiar with the use scenario of ldap's Obj class, so I'm not sure if >>>> it matters (if it ever outputs/inputs > 76 character data, or even it does,if >>>> the difference matters). >>>> >>>> Btw, except getMimeEncoder(int ...) all other Base64.getXXXEn/Decoder() >>>> returns singleton, so the de/encoder cache might not be necessary. >>> Thanks Sherman. Vinnie confirms that it should retain the current behavior as there could be long-lived Java object in LDAP encoded with JDK 8 for example and then retrieved with JDK 9. >>> >>> Here is the updated webrev: >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.01/ >>> >>> Thanks >>> Mandy From peter.levart at gmail.com Sat Mar 22 09:01:10 2014 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 22 Mar 2014 10:01:10 +0100 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: <26843449-4DCC-4A74-BE32-29836D5FC9F2@oracle.com> References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <531EC6BF.4050701@oracle.com> <4742E0AD-8D87-4F22-8F23-779BDF3A58FE@oracle.com> <5320240C.60304@gmail.com> <5322DC66.5070003@gmail.com> <96B8A54B-77FC-4973-8A92-2344A1621F43@oracle.com> <532A290A.7090307@gmail.com> <532A935C.2060604@gmail.com> <532A9DA6.6080707@oracle.com> <26843449-4DCC-4A74-BE32-29836D5FC9F2@oracle.com> Message-ID: <532D5156.7090904@gmail.com> On 03/22/2014 02:01 AM, Brian Burkhalter wrote: > On Mar 20, 2014, at 12:49 AM, Aleksey Shipilev > > wrote: > >> On 03/20/2014 11:06 AM, Peter Levart wrote: >>> I was thinking about last night, for question: "Why is this >>> double-checked non-volatile-then-volatile trick not any faster than pure >>> volatile variant even on ARM platform where volatile read should have >>> some penalty compared to normal read?", might be in the fact that >>> Raspberry Pi is a single-core/single-thread "machine". Would anyone with >>> JVM JIT compiler expertise care to share some insight? I suspect that on >>> such platform, the compiler optimizes volatile accesses so that they are >>> performed without otherwise necessary memory fences... >> >> Yes, at least C2 is known to not emit memory fences on uniprocessor >> machines. You need to have a multicore ARM. If you are still interested, >> contact me privately and I can arrange the access to my personal >> quad-core Cortex-A9. > > This is all very interesting but I would like to have closure so to > speak on the patches that I posted. Hi Brian, > I think the questions still unresolved are: > > 1) Is a change of toString() necessary? I can't speak of that since I don't have empirical data in what proportion of code it would be beneficial. I can imagine situations where returned strings are used as keys in HashMap and String's equals is optimized for same-instance comparison, but I don't know if such situations happen in practice... > 2) If #1 is ?yes? then which version of the patch? (I think the most > recent) Aleksey Shipilev kindly let me access it's quad-code ARM "Big Iron" and before the connection to it broke yesterday, I managed to get the results of a single-threaded run of the microbenchmark. While differences were not spectacular, they were measurable (sorry I haven't saved the results). The variant with volatile stringCache field and CAS was a little slower than the double-checked nonvolatile-then-volatile-read-and-CAS trick. It's also important that the fast-path method does not exceed the maximum bytecode size for inlining (35 bytes by default, I think) so the variant with two methods toString/toStringSlow is necessary to avoid performance regression. > 3) Are the other changes OK which are unrelated to toString()? Looks good. Just a nit. In the following method: 3726 private static void matchScale(BigDecimal[] val) { 3727 if (val[0].scale == val[1].scale) { 3728 // return 3729 } else if (val[0].scale < val[1].scale) { 3730 val[0] = val[0].setScale(val[1].scale, ROUND_UNNECESSARY); 3731 } else if (val[1].scale < val[0].scale) { 3732 val[1] = val[1].setScale(val[0].scale, ROUND_UNNECESSARY); 3733 } 3734 } One of 3 ifs is superfluous. Either the 1st one: private static void matchScale(BigDecimal[] val) { */* if (val[0].scale == val[1].scale) { // return } else */* if (val[0].scale < val[1].scale) { val[0] = val[0].setScale(val[1].scale, ROUND_UNNECESSARY); } else if (val[1].scale < val[0].scale) { val[1] = val[1].setScale(val[0].scale, ROUND_UNNECESSARY); } } ...or the last one: private static void matchScale(BigDecimal[] val) { if (val[0].scale == val[1].scale) { // return } else if (val[0].scale < val[1].scale) { val[0] = val[0].setScale(val[1].scale, ROUND_UNNECESSARY); } else*/* if (val[1].scale < val[0].scale) */* { val[1] = val[1].setScale(val[0].scale, ROUND_UNNECESSARY); } } Regards, Peter > > Thanks, > > Brian From peter.levart at gmail.com Sat Mar 22 23:47:31 2014 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 23 Mar 2014 00:47:31 +0100 Subject: RFR: 8034944: (process) Improve subprocess handling on Solaris In-Reply-To: <532CA33D.3030502@oracle.com> References: <532C7A30.6060904@oracle.com> <532CA33D.3030502@oracle.com> Message-ID: <532E2113.6040903@gmail.com> On 03/21/2014 09:38 PM, Alan Bateman wrote: > On 21/03/2014 17:43, Rob McKenna wrote: >> : >> >> In a nutshell a new process reaper thread was spawned for every >> Process created by the JDK. This fix runs these reaper threads in a >> thread pool to save on thread creation when creating a lot of new >> processes. >> >> http://cr.openjdk.java.net/~robm/8034944/webrev.01/ > Thanks Rob, it's good to get this change into the Solaris > implementation. I looked through Martin's original changes in > JDK-6944584 and the "side-port" as you've called it looks good. > > -Alan. Hi, I wanted to take a look at sources to find out what is the purpose of special "process reaper" threads that get started when child processes are spawned from Java and see it if the API could be implemented without them. I found out that there are two basic implementations. One for Windows and one for UNIX OSes. The UNIX implementation has 4 variants maintained in 4 more or less equal files that represent the same UNIXProcess class. These 4 files have the UNIX OS variant encoded in the extension so it's hard to maintain them with an IDE. Wouldn't it be nicer to have one common UNIXProcess.java file for all 4 UNIX OS variants? I took an exercise in re-factoring to see what it would take to merge all 4 files into one. Here's what I came up with: http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.01/ This is just a preview. It doesn't incorporate the fix for 8034944 yet (when incorporated the code would get even simpler since there would be less differences). It's still missing the runtime logic to resolve the correct OS (currently only Linux), but it works on Linux (all 8 jtreg tests for ProcessBuilder pass) and it should behave the same as original code in every respect. I think this could be a starting point for making code more maintainable. What do you think? Regards, Peter From martinrb at google.com Sun Mar 23 09:34:43 2014 From: martinrb at google.com (Martin Buchholz) Date: Sun, 23 Mar 2014 02:34:43 -0700 Subject: RFR: 8034944: (process) Improve subprocess handling on Solaris In-Reply-To: <532E2113.6040903@gmail.com> References: <532C7A30.6060904@oracle.com> <532CA33D.3030502@oracle.com> <532E2113.6040903@gmail.com> Message-ID: TL;DR - I support Peter's refactoring. It would indeed be nice to keep the very similar Unix implementations in one source file. Once upon a time, such a unification was done with UNIXProcess_md.c, but there we had a C preprocessor to help. Unifying the Solaris and Linux java sources as you have done was indeed a goal back in 2006. I was saddened that the bsd/macosx ports added to the divergence. Standing in the way is that few engineers have easy access to all the systems involved for testing, and it's very easy to introduce a subtle bug. We have also thought about whether having reaper threads is necessary. The Unix rule is that child processes should be waited for, and some thread needs to do that. There's no way to wait for a set of child pids, or to specify a "completion handler". Well, you might be able to get the newish waitid() to do what you want, but it looks like it's not sufficient when java is running inside a process that might do independent subprocess creation outside of the JVM. On Sat, Mar 22, 2014 at 4:47 PM, Peter Levart wrote: > > On 03/21/2014 09:38 PM, Alan Bateman wrote: > > On 21/03/2014 17:43, Rob McKenna wrote: > > : > > In a nutshell a new process reaper thread was spawned for every Process > created by the JDK. This fix runs these reaper threads in a thread pool to > save on thread creation when creating a lot of new processes. > > http://cr.openjdk.java.net/~robm/8034944/webrev.01/ > > Thanks Rob, it's good to get this change into the Solaris implementation. > I looked through Martin's original changes in JDK-6944584 and the > "side-port" as you've called it looks good. > > -Alan. > > > Hi, > > I wanted to take a look at sources to find out what is the purpose of > special "process reaper" threads that get started when child processes are > spawned from Java and see it if the API could be implemented without them. > I found out that there are two basic implementations. One for Windows and > one for UNIX OSes. The UNIX implementation has 4 variants maintained in 4 > more or less equal files that represent the same UNIXProcess class. These 4 > files have the UNIX OS variant encoded in the extension so it's hard to > maintain them with an IDE. Wouldn't it be nicer to have one common > UNIXProcess.java file for all 4 UNIX OS variants? > > I took an exercise in re-factoring to see what it would take to merge all > 4 files into one. Here's what I came up with: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.01/ > > This is just a preview. It doesn't incorporate the fix for 8034944 yet > (when incorporated the code would get even simpler since there would be > less differences). It's still missing the runtime logic to resolve the > correct OS (currently only Linux), but it works on Linux (all 8 jtreg tests > for ProcessBuilder pass) and it should behave the same as original code in > every respect. I think this could be a starting point for making code more > maintainable. What do you think? > > Regards, Peter > > From martinrb at google.com Sun Mar 23 09:39:41 2014 From: martinrb at google.com (Martin Buchholz) Date: Sun, 23 Mar 2014 02:39:41 -0700 Subject: RFR: 8034944: (process) Improve subprocess handling on Solaris In-Reply-To: References: <532C7A30.6060904@oracle.com> <532CA33D.3030502@oracle.com> <532E2113.6040903@gmail.com> Message-ID: https://bugs.openjdk.java.net/browse/JDK-8000975 (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux On Sun, Mar 23, 2014 at 2:34 AM, Martin Buchholz wrote: > TL;DR - I support Peter's refactoring. > > It would indeed be nice to keep the very similar Unix implementations in > one source file. Once upon a time, such a unification was done with > UNIXProcess_md.c, but there we had a C preprocessor to help. Unifying the > Solaris and Linux java sources as you have done was indeed a goal back in > 2006. I was saddened that the bsd/macosx ports added to the divergence. > Standing in the way is that few engineers have easy access to all the > systems involved for testing, and it's very easy to introduce a subtle bug. > > We have also thought about whether having reaper threads is necessary. > The Unix rule is that child processes should be waited for, and some > thread needs to do that. There's no way to wait for a set of child pids, > or to specify a "completion handler". Well, you might be able to get the > newish waitid() to do what you want, but it looks like it's not sufficient > when java is running inside a process that might do independent subprocess > creation outside of the JVM. > > > On Sat, Mar 22, 2014 at 4:47 PM, Peter Levart wrote: > >> >> On 03/21/2014 09:38 PM, Alan Bateman wrote: >> >> On 21/03/2014 17:43, Rob McKenna wrote: >> >> : >> >> In a nutshell a new process reaper thread was spawned for every Process >> created by the JDK. This fix runs these reaper threads in a thread pool to >> save on thread creation when creating a lot of new processes. >> >> http://cr.openjdk.java.net/~robm/8034944/webrev.01/ >> >> Thanks Rob, it's good to get this change into the Solaris implementation. >> I looked through Martin's original changes in JDK-6944584 and the >> "side-port" as you've called it looks good. >> >> -Alan. >> >> >> Hi, >> >> I wanted to take a look at sources to find out what is the purpose of >> special "process reaper" threads that get started when child processes are >> spawned from Java and see it if the API could be implemented without them. >> I found out that there are two basic implementations. One for Windows and >> one for UNIX OSes. The UNIX implementation has 4 variants maintained in 4 >> more or less equal files that represent the same UNIXProcess class. These 4 >> files have the UNIX OS variant encoded in the extension so it's hard to >> maintain them with an IDE. Wouldn't it be nicer to have one common >> UNIXProcess.java file for all 4 UNIX OS variants? >> >> I took an exercise in re-factoring to see what it would take to merge all >> 4 files into one. Here's what I came up with: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.01/ >> >> This is just a preview. It doesn't incorporate the fix for 8034944 yet >> (when incorporated the code would get even simpler since there would be >> less differences). It's still missing the runtime logic to resolve the >> correct OS (currently only Linux), but it works on Linux (all 8 jtreg tests >> for ProcessBuilder pass) and it should behave the same as original code in >> every respect. I think this could be a starting point for making code more >> maintainable. What do you think? >> >> Regards, Peter >> >> > From tbuktu at hotmail.com Sun Mar 23 10:06:14 2014 From: tbuktu at hotmail.com (Tim Buktu) Date: Sun, 23 Mar 2014 11:06:14 +0100 Subject: #8014320 would benefit from #5100935 Message-ID: Posting to the list because I can't add comments on http://bugs.openjdk.java.net. I just wanted to point out that if #5100935 were implemented, it would allow for a speed improvement of an estimated 20% for SS multiplication in the 20,000 - 80,000 digit range. There are other improvements to 8014320 that could be done now, but they would only make a difference well into the 100,000s of digits. Tim From Alan.Bateman at oracle.com Sun Mar 23 17:11:00 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 23 Mar 2014 17:11:00 +0000 Subject: RFR: 8034944: (process) Improve subprocess handling on Solaris In-Reply-To: <532E2113.6040903@gmail.com> References: <532C7A30.6060904@oracle.com> <532CA33D.3030502@oracle.com> <532E2113.6040903@gmail.com> Message-ID: <532F15A4.6020303@oracle.com> On 22/03/2014 23:47, Peter Levart wrote: > : > > I took an exercise in re-factoring to see what it would take to merge > all 4 files into one. There is a long standing bug proposing that the implementations be merged (Martin will remember some of the history on this). I would prefer that we keep this separate to avoid complicating Rob's side port (Rob's side port is for 7u and 8u, not 9). -Alan From joe.darcy at oracle.com Sun Mar 23 18:09:44 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 23 Mar 2014 11:09:44 -0700 Subject: #8014320 would benefit from #5100935 In-Reply-To: References: Message-ID: <532F2368.8030103@oracle.com> Hello, The description of 5100935 is: JDK-5100935 No way to access the 64-bit integer multiplication of 64-bit CPUs efficiently From the most recent comment in the bug, the straw-man API for this is something like: > > For the (int, int) -> long case, "multiplyFull". > > For the high bits of (long, long) -> long, "multiplyHigh with expected VM intrinsification. FWIW, I'd like to see this API included in JDK 9. -Joe On 3/23/2014 3:06 AM, Tim Buktu wrote: > Posting to the list because I can't add comments on > http://bugs.openjdk.java.net. > > I just wanted to point out that if #5100935 were implemented, it would > allow for a speed improvement of an estimated 20% for SS multiplication > in the 20,000 - 80,000 digit range. > > There are other improvements to 8014320 that could be done now, but they > would only make a difference well into the 100,000s of digits. > > Tim From Alan.Bateman at oracle.com Sun Mar 23 18:10:37 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 23 Mar 2014 18:10:37 +0000 Subject: [9] Review request: new macro for conversion to jboolean In-Reply-To: <532C592E.1070205@oracle.com> References: <53270E65.4070001@oracle.com> <53273F9A.3080403@oracle.com> <5329E3B7.7000000@oracle.com> <5329F8A4.6030908@oracle.com> <5329F93A.2010205@oracle.com> <5329F91E.4050703@oracle.com> <532A2B8E.9040707@oracle.com> <532C5658.6050601@oracle.com> <532C592E.1070205@oracle.com> Message-ID: <532F239D.2030203@oracle.com> On 21/03/2014 15:22, Sergey Bylokhov wrote: > On 3/21/14 7:10 PM, roger riggs wrote: >> The macro would just as useful (if I understand the cases) without >> the cast. >> >> How useful is a simple definition as: >> >> #define IS_TRUE(obj) ((obj) ? JNI_TRUE : JNI_FALSE) >> >> then it would look ok to see these in sources: >> >> return IS_TRUE(obj); >> >> if (IS_TRUE(obj)) {....} >> >> jboolean ret = IS_TRUE(obj); >> >> The general purpose usage matches the general C conventions for >> true and false and match the JNI semantics. > Actually that was my initial suggestion(name and usage). I think the concern with IS_TRUE is that it's not obvious that it's a jboolean. Also just the potential for it to easily collide with a macro that casts to bool or (or Windows's BOOL). I can't tell from the JNI spec if JNI_FALSE/JNI_TRUE are guaranteed to be defined as 0/1 but even if they are then I guess there is still a concern that a jboolean is defined as an unsigned 8 bits whereas a bool might not (and a Windows's BOOL is an int I think). So if a macro is really needed then I think it will need another name. I thought MIke's original proposal for JNU_TO_JBOOLEAN wasn't too bad. I see Mike's mail about adding the cases to the definitions but that isn't going to help with the cases that I think you are running into where you need to go from Window's BOOL to jboolean. -Alan. From martinrb at google.com Sun Mar 23 22:30:56 2014 From: martinrb at google.com (Martin Buchholz) Date: Sun, 23 Mar 2014 15:30:56 -0700 Subject: RFR: 8034944: (process) Improve subprocess handling on Solaris In-Reply-To: References: <532C7A30.6060904@oracle.com> <532CA33D.3030502@oracle.com> <532E2113.6040903@gmail.com> Message-ID: On Sun, Mar 23, 2014 at 2:34 AM, Martin Buchholz wrote: > > We have also thought about whether having reaper threads is necessary. > The Unix rule is that child processes should be waited for, and some > thread needs to do that. There's no way to wait for a set of child pids, > or to specify a "completion handler". Well, you might be able to get the > newish waitid() to do what you want, but it looks like it's not sufficient > when java is running inside a process that might do independent subprocess > creation outside of the JVM. > > Actually, I take it back. With sufficient work, it looks like you can get SIGCHLD to give you pid information in siginfo_t si_pid, and that can be used to trigger the reaping. It looks like waitpid is "async-signal-safe", so we can call it from our signal handler. While we're at it we can fix SIGCHLD handling to do signal chaining, as with other signals. From rob.mckenna at oracle.com Mon Mar 24 04:38:12 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 24 Mar 2014 04:38:12 +0000 Subject: RFR: 8034944: (process) Improve subprocess handling on Solaris In-Reply-To: References: <532C7A30.6060904@oracle.com> <532CA33D.3030502@oracle.com> <532E2113.6040903@gmail.com> Message-ID: <532FB6B4.7010300@oracle.com> Hi folks, Roger Riggs (cc'd) may want to chip in here as he's looking at the reaper thread arrangement in 9 at the moment. On another note, I too support the merging of those files. I didn't think there was much appetite for it at the time so I must admit this fell down my todo list. Looking at this bug did remind me that its something worth trying though. As per Alan's mail, I'm going to tackle it separately if you folks don't mind. I'll have a look at Peter's changes (thanks Peter!) as soon as I can and see about getting them in. -Rob On 23/03/14 22:30, Martin Buchholz wrote: > > > > On Sun, Mar 23, 2014 at 2:34 AM, Martin Buchholz > wrote: > > > We have also thought about whether having reaper threads is > necessary. The Unix rule is that child processes should be waited > for, and some thread needs to do that. There's no way to wait for > a set of child pids, or to specify a "completion handler". Well, > you might be able to get the newish waitid() to do what you want, > but it looks like it's not sufficient when java is running inside > a process that might do independent subprocess creation outside of > the JVM. > > > Actually, I take it back. With sufficient work, it looks like you can > get SIGCHLD to give you pid information in siginfo_t si_pid, and that > can be used to trigger the reaping. It looks like waitpid is > "async-signal-safe", so we can call it from our signal handler. > > While we're at it we can fix SIGCHLD handling to do signal chaining, > as with other signals. From weijun.wang at oracle.com Mon Mar 24 07:43:23 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 24 Mar 2014 15:43:23 +0800 Subject: Reflection.getCallerClass() and @CallerSensitive for a constructor? Message-ID: <5CA8C244-2078-4DC1-AAB2-4C69F5CAD982@oracle.com> Reflection.getCallerClass(3) seems work but the method is deprecated. Thanks Max From forax at univ-mlv.fr Mon Mar 24 08:36:51 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 24 Mar 2014 09:36:51 +0100 Subject: Reflection.getCallerClass() and @CallerSensitive for a constructor? In-Reply-To: <5CA8C244-2078-4DC1-AAB2-4C69F5CAD982@oracle.com> References: <5CA8C244-2078-4DC1-AAB2-4C69F5CAD982@oracle.com> Message-ID: <532FEEA3.10606@univ-mlv.fr> On 03/24/2014 08:43 AM, Wang Weijun wrote: > Reflection.getCallerClass(3) seems work but the method is deprecated. > > Thanks > Max > what is your the question ? cheers, R?mi From weijun.wang at oracle.com Mon Mar 24 08:41:42 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 24 Mar 2014 16:41:42 +0800 Subject: Reflection.getCallerClass() and @CallerSensitive for a constructor? In-Reply-To: <532FEEA3.10606@univ-mlv.fr> References: <5CA8C244-2078-4DC1-AAB2-4C69F5CAD982@oracle.com> <532FEEA3.10606@univ-mlv.fr> Message-ID: <3AF09BCA-A03A-4F8E-B5AC-EAE0AC9747F2@oracle.com> Calling Reflection.getCallerClass() needs the @CallerSensitive annotation, but it cannot be applied to a constructor. --Max On Mar 24, 2014, at 16:36, Remi Forax wrote: > On 03/24/2014 08:43 AM, Wang Weijun wrote: >> Reflection.getCallerClass(3) seems work but the method is deprecated. >> >> Thanks >> Max >> > > what is your the question ? > > cheers, > R?mi > From peter.levart at gmail.com Mon Mar 24 09:21:55 2014 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 24 Mar 2014 10:21:55 +0100 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: <532A9DA6.6080707@oracle.com> References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <531EC6BF.4050701@oracle.com> <4742E0AD-8D87-4F22-8F23-779BDF3A58FE@oracle.com> <5320240C.60304@gmail.com> <5322DC66.5070003@gmail.com> <96B8A54B-77FC-4973-8A92-2344A1621F43@oracle.com> <532A290A.7090307@gmail.com> <532A935C.2060604@gmail.com> <532A9DA6.6080707@oracle.com> Message-ID: <532FF933.1040900@gmail.com> On 03/20/2014 08:49 AM, Aleksey Shipilev wrote: > On 03/20/2014 11:06 AM, Peter Levart wrote: >> I was thinking about last night, for question: "Why is this >> double-checked non-volatile-then-volatile trick not any faster than pure >> volatile variant even on ARM platform where volatile read should have >> some penalty compared to normal read?", might be in the fact that >> Raspberry Pi is a single-core/single-thread "machine". Would anyone with >> JVM JIT compiler expertise care to share some insight? I suspect that on >> such platform, the compiler optimizes volatile accesses so that they are >> performed without otherwise necessary memory fences... > Yes, at least C2 is known to not emit memory fences on uniprocessor > machines. You need to have a multicore ARM. If you are still interested, > contact me privately and I can arrange the access to my personal > quad-core Cortex-A9. > > -Aleksey. Hi, Thanks to Aleksey for re-establishing the access, I bring you results of the microbenchmark from his quad-core Cortex-A9: JDK 8 options: -client, org.openjdk.jmh.Main parameters: ".*" -i 10 -r 5 -wi 5 -w 1 -f 1 [-t 1|max] --- Baseline, 1-thread --- Benchmark Mode Samples Mean Mean error Units o.t.Bench6375303.testFirstToString avgt 10 69292.305 299.516 ns/op o.t.Bench6375303.testToString avgt 10*20.003* 0.433 ns/op --- Baseline, 4-threads --- Benchmark Mode Samples Mean Mean error Units o.t.Bench6375303.testFirstToString avgt 10 100390.024 2158.132 ns/op o.t.Bench6375303.testToString avgt 10*20.151* 0.677 ns/op --- double-checked nonvolatile-then-volatile-read+CAS, 1-thread --- Benchmark Mode Samples Mean Mean error Units o.t.Bench6375303.testFirstToString avgt 10 69951.406 221.516 ns/op o.t.Bench6375303.testToString avgt 10*19.681* 0.025 ns/op --- double-checked nonvolatile-then-volatile-read+CAS, 4-threads --- Benchmark Mode Samples Mean Mean error Units o.t.Bench6375303.testFirstToString avgt 10 104231.335 3842.095 ns/op o.t.Bench6375303.testToString avgt 10*20.030* 0.595 ns/op --- classic volatile read+CAS, 1-thread --- Benchmark Mode Samples Mean Mean error Units o.t.Bench6375303.testFirstToString avgt 10 69753.542 180.110 ns/op o.t.Bench6375303.testToString avgt 10*23.285* 0.267 ns/op --- classic volatile read+CAS, 4-threads --- Benchmark Mode Samples Mean Mean error Units o.t.Bench6375303.testFirstToString avgt 10 99664.256 1814.090 ns/op o.t.Bench6375303.testToString avgt 10*23.491* 0.606 ns/op ...as can be seen, the double-checked read-then-volatile-read+CAS trick is about 15% faster than classic volatile-read+CAS in this case. Regards, Peter From vincent.x.ryan at oracle.com Mon Mar 24 10:13:37 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 24 Mar 2014 10:13:37 +0000 Subject: Review request for 8035807: Convert use of sun.misc.BASE64Encoder/Decoder with java.util.Base64 In-Reply-To: <532D01E9.70001@oracle.com> References: <5329E3F7.6070007@oracle.com> <5329EFF4.9060008@oracle.com> <532B7035.9030905@oracle.com> <532BD40D.60506@oracle.com> <15E560D8-8B5B-4CC9-8DBA-DABEDBD81952@oracle.com> <532D01E9.70001@oracle.com> Message-ID: On 22 Mar 2014, at 03:22, Mandy Chung wrote: > Good catch Sherman. > > Vinnie - what's your recommendation for this LDAP change having both encode/decode uses the platform default charset (rather than retaining the old interop issue)? It's an incompatible change and I'll file a CCC to track this. Yes. I think that?s the right approach as the compatibility risk is low. > > Mandy > > On 3/21/2014 2:23 AM, Vincent Ryan wrote: >> You?re right but we?ve never received a report of any charset interop. issues. >> Probably such a scenario has never been encountered by customers. >> >> >> On 21 Mar 2014, at 05:54, Xueming Shen wrote: >> >>> Obj.java:#482 >>> It appears sun.misc.BASE64Decoder.decodeBuffer(String) uses String's deprecated >>> String.getBytes(int srcBegin, int srcEnd, byte[] dst, int dstBegin). The proposed change >>> now uses the jvm's default charset. It might trigger incompatible behavior if the default >>> charset is not an ASCII compatible charset. But if the "Java object in LDAP was encoded >>> with the platform default charset" (as the new comment suggested), the old implementation >>> actually did not work on platform that the default encoding is not ASCII compatible, such >>> as the IBM ebcdic. >>> >>> -Sherman >>> >>> On 3/20/14 3:48 PM, Mandy Chung wrote: >>>> On 3/19/14 12:28 PM, Xueming Shen wrote: >>>>> On 03/19/2014 11:37 AM, Mandy Chung wrote: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8035807 >>>>>> >>>>>> Webrev at: >>>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.00/ >>>>>> >>>>>> This patch converts the last 2 references to sun.misc.BASE64Encoder/Decoder from the jdk repo with java.util.Base64. We should also update the tests and I have filed JDK-8037873 for that. >>>>>> >>>>>> Thanks >>>>>> Mandy >>>>> The sun.misc.BASE64En/Decoder is MIME type, so it outputs the \r\n per 76 >>>>> characters during encoding, and ignores/skip \r or \n when decoding. The new >>>>> Base64.getEncoder/Decoder() returns the "basic" Base64 coder, which it never >>>>> inserts line separator when output, and throws exception for any non-base64- >>>>> alphabet character, including \r and \n. >>>>> >>>>> The only disadvantage/incompatibility (j.u.Base64.getMimeDecoer() vs >>>>> sun.misc.BASE64Decoder) of switching to j.u.Base64 MIME type en/decoder >>>>> is that the Base64 Mime decoder ignores/skips any non-base64-alphabet >>>>> (including \r and \n), while sun.misc.BASE64Decoder appears to simply >>>>> use the init value "-1" for any non-base64-alphabet character for decoding. >>>>> >>>>> I'm not familiar with the use scenario of ldap's Obj class, so I'm not sure if >>>>> it matters (if it ever outputs/inputs > 76 character data, or even it does,if >>>>> the difference matters). >>>>> >>>>> Btw, except getMimeEncoder(int ...) all other Base64.getXXXEn/Decoder() >>>>> returns singleton, so the de/encoder cache might not be necessary. >>>> Thanks Sherman. Vinnie confirms that it should retain the current behavior as there could be long-lived Java object in LDAP encoded with JDK 8 for example and then retrieved with JDK 9. >>>> >>>> Here is the updated webrev: >>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.01/ >>>> >>>> Thanks >>>> Mandy > From anthony.petrov at oracle.com Mon Mar 24 11:11:16 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 24 Mar 2014 15:11:16 +0400 Subject: [9] Review request: new macro for conversion to jboolean In-Reply-To: <532F239D.2030203@oracle.com> References: <53270E65.4070001@oracle.com> <53273F9A.3080403@oracle.com> <5329E3B7.7000000@oracle.com> <5329F8A4.6030908@oracle.com> <5329F93A.2010205@oracle.com> <5329F91E.4050703@oracle.com> <532A2B8E.9040707@oracle.com> <532C5658.6050601@oracle.com> <532C592E.1070205@oracle.com> <532F239D.2030203@oracle.com> Message-ID: <533012D4.6030708@oracle.com> How does IS_JNI_TRUE sound? -- best regards, Anthony On 3/23/2014 10:10 PM, Alan Bateman wrote: > On 21/03/2014 15:22, Sergey Bylokhov wrote: >> On 3/21/14 7:10 PM, roger riggs wrote: >>> The macro would just as useful (if I understand the cases) without >>> the cast. >>> >>> How useful is a simple definition as: >>> >>> #define IS_TRUE(obj) ((obj) ? JNI_TRUE : JNI_FALSE) >>> >>> then it would look ok to see these in sources: >>> >>> return IS_TRUE(obj); >>> >>> if (IS_TRUE(obj)) {....} >>> >>> jboolean ret = IS_TRUE(obj); >>> >>> The general purpose usage matches the general C conventions for >>> true and false and match the JNI semantics. >> Actually that was my initial suggestion(name and usage). > I think the concern with IS_TRUE is that it's not obvious that it's a > jboolean. Also just the potential for it to easily collide with a macro > that casts to bool or (or Windows's BOOL). I can't tell from the JNI > spec if JNI_FALSE/JNI_TRUE are guaranteed to be defined as 0/1 but even > if they are then I guess there is still a concern that a jboolean is > defined as an unsigned 8 bits whereas a bool might not (and a Windows's > BOOL is an int I think). So if a macro is really needed then I think it > will need another name. I thought MIke's original proposal for > JNU_TO_JBOOLEAN wasn't too bad. I see Mike's mail about adding the cases > to the definitions but that isn't going to help with the cases that I > think you are running into where you need to go from Window's BOOL to > jboolean. > > -Alan. From magnus.ihse.bursie at oracle.com Mon Mar 24 11:18:16 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 24 Mar 2014 12:18:16 +0100 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <532C080A.9020002@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <53280AF0.5000502@oracle.com> <532ADE09.7050602@oracle.com> <532BF4E4.5080003@oracle.com> <532BFEE2.6080802@oracle.com> <532C080A.9020002@oracle.com> Message-ID: <53301478.8000809@oracle.com> On 2014-03-21 10:36, Dmitry Samersoff wrote: > > (c) Compression mode: > > 1. none > 2. per-section compression, SHF_GNU_COMPRESSED [1] > 3. zip entire file > Is 2 something we're doing? I couldn't find any references to it in the code. Or is it something we're planning to do? /Magnus From magnus.ihse.bursie at oracle.com Mon Mar 24 11:33:19 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 24 Mar 2014 12:33:19 +0100 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <532BFEE2.6080802@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <53280AF0.5000502@oracle.com> <532ADE09.7050602@oracle.com> <532BF4E4.5080003@oracle.com> <532BFEE2.6080802@oracle.com> Message-ID: <533017FF.7010400@oracle.com> On 2014-03-21 09:57, David Holmes wrote: > >> And while, technically, you can save symbols externally, and at the same >> time keep them in the binary, that does not make sense. So, in a >> practical sense, you are going to do #2 if you are going to do #3. > > But you can vary what is kept internally independent of what is made > external. While that technically is correct, not all combinations does make sense. > >> And you can't zip external symbols unless you create a non-zipped >> version. And if you zip them, it does not make sense to keep the >> non-zipped version. > > zip vs non-zip is just an issue of disk space. It is not a fundamental > configuration choice, just a variation on how external symbols are > packaged. So can we agree that for external symbols, there are three ways to deal with them: no external symbols unzipped external symbols zipped external symbols ? >> Can you give a more concrete example of the variations of your "aspects" >> that you think my suggested solution would not capture? > > I think I already have. There aren't tree simple choices here, there > are three aspects, each of which could have different variants. > > If I could draw a flow chart easily I would but basically if you > generate debug symbols you can then select what symbols are kept > internally (the strip policy) and what are put externally (objcopy > options), then for the external symbol file you can choose zipped or > unzipped. > > Multiple inter-connected choices, not just three (or four if you add > zipped) And then there's the aspect that got this bug started, that you need to compile with -g to be able to have any useful symbols at all. While technically you can compile without -g and then run strip, it's a combination that does not make sense. In the end, it all boils down to a few sensible ways to handle all debug information. 1) The Oracle way -- copying debug information into an external format (that by default is zipped), and stripping the binary as much as reasonable. 2) The community way -- keep everything in the binary, and not creating a separate external format. 3) The hardcore way -- ignore debug information alltogether. Instead of providing a lots of handles and knobs to configure, that will allow the user to configure invalid (e.g. zip-external=true, produce-external=false), or meaningless (compile-with-debug-flag=yes, strip=everything, produce-external=false), I'd rather provide a high-level option (or two, if it's not possible to condense into a single option) that allows the user to express the intent. And for all practical purposes, it's going to be set to either "oracle mode" or "community mode". /Magnus From paul.sandoz at oracle.com Mon Mar 24 11:44:45 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 24 Mar 2014 12:44:45 +0100 Subject: RFR 8037857: Methods j.u.Arrays.spliterator/stream(X[], int, int) throw IAE instead of specified AIOOBE when endIndex < startIndex Message-ID: Hi, Simple patch to align code with spec for stream/spliterator factory methods on Arrays and spliterator methods on Spliterators, and make the next release of the JCK happy: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8037857-spliterator-aioob/webrev/ After 9 it should go back to 8u20. Paul. From Alan.Bateman at oracle.com Mon Mar 24 12:28:41 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 24 Mar 2014 12:28:41 +0000 Subject: RFR 8037857: Methods j.u.Arrays.spliterator/stream(X[], int, int) throw IAE instead of specified AIOOBE when endIndex < startIndex In-Reply-To: References: Message-ID: <533024F9.4040302@oracle.com> On 24/03/2014 11:44, Paul Sandoz wrote: > Hi, > > Simple patch to align code with spec for stream/spliterator factory methods on Arrays and spliterator methods on Spliterators, and make the next release of the JCK happy: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8037857-spliterator-aioob/webrev/ > > After 9 it should go back to 8u20. > This looks good to me. The test looks useful too, a minor comment is that I think it's more common to put the test tags at the top after the copyright header. -Alan From paul.sandoz at oracle.com Mon Mar 24 12:49:53 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 24 Mar 2014 13:49:53 +0100 Subject: RFR 8037857: Methods j.u.Arrays.spliterator/stream(X[], int, int) throw IAE instead of specified AIOOBE when endIndex < startIndex In-Reply-To: <533024F9.4040302@oracle.com> References: <533024F9.4040302@oracle.com> Message-ID: <0D057EAC-646E-4627-9354-84A0C87C93AF@oracle.com> On Mar 24, 2014, at 1:28 PM, Alan Bateman wrote: > On 24/03/2014 11:44, Paul Sandoz wrote: >> Hi, >> >> Simple patch to align code with spec for stream/spliterator factory methods on Arrays and spliterator methods on Spliterators, and make the next release of the JCK happy: >> >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8037857-spliterator-aioob/webrev/ >> >> After 9 it should go back to 8u20. >> > This looks good to me. Thanks. > The test looks useful too, a minor comment is that I think it's more common to put the test tags at the top after the copyright header. > I like to ensure the first block comment is collapsed in the IDE (as it is usually just the license), but that has the unfortunate effect of including any directly following blocks (not sure if i can configure it...). In any case i will move it up. Paul. From tom.hawtin at oracle.com Mon Mar 24 13:28:35 2014 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Mon, 24 Mar 2014 13:28:35 +0000 Subject: Reflection.getCallerClass() and @CallerSensitive for a constructor? In-Reply-To: <3AF09BCA-A03A-4F8E-B5AC-EAE0AC9747F2@oracle.com> References: <5CA8C244-2078-4DC1-AAB2-4C69F5CAD982@oracle.com> <532FEEA3.10606@univ-mlv.fr> <3AF09BCA-A03A-4F8E-B5AC-EAE0AC9747F2@oracle.com> Message-ID: <53303303.4010303@oracle.com> On 24/03/2014 08:41, Wang Weijun wrote: > Calling Reflection.getCallerClass() needs the @CallerSensitive annotation, but it cannot be applied to a constructor. Ah, I see your message from 2012-11-26 05:46. > This is very nice but it does not mention Constructor.newInstance(). > In fact, I do see the following entries if I'm creating an object > thru reflection: And Class.newInstance. Which gives a clue to a problem. Any code that is using Constructor.newInstance has to be as careful with it as they are with Method.invoke. Slightly more so, as constructors lean on overloading rather than having names like all self-respecting methods. As we know from experience, existing code does automatically take into account bizarre new requirements. I think we have a sufficient quantity of caller-sensitive stuff without taking it into new directions. (From reading the HotSpot sources some time ago (may have changed), in particular circumstances some, but not all, constructor reflection frames may disappear.) Tom From chris.hegarty at oracle.com Mon Mar 24 14:12:05 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 24 Mar 2014 14:12:05 +0000 Subject: Review request for 8038177 Eliminate unnecessary dependency to sun.security.action In-Reply-To: <532CAEF4.30407@oracle.com> References: <532CAEF4.30407@oracle.com> Message-ID: <53303D35.80600@oracle.com> The changes look good to me Mandy. -Chris. On 21/03/14 21:28, Mandy Chung wrote: > This is the second patch to eliminate the dependencies to > sun.security.action: > https://bugs.openjdk.java.net/browse/JDK-8038177 > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8038177/webrev.00/ > > Mandy From Alan.Bateman at oracle.com Mon Mar 24 15:15:55 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 24 Mar 2014 15:15:55 +0000 Subject: Review request for 8038177 Eliminate unnecessary dependency to sun.security.action In-Reply-To: <532CAEF4.30407@oracle.com> References: <532CAEF4.30407@oracle.com> Message-ID: <53304C2B.7030402@oracle.com> On 21/03/2014 21:28, Mandy Chung wrote: > This is the second patch to eliminate the dependencies to > sun.security.action: > https://bugs.openjdk.java.net/browse/JDK-8038177 > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8038177/webrev.00/ > It looks good to me too. The only one that I wonder about is ExtendedCharsets and whether this might run early in the startup on some locales. -Alan. From vladimir.x.ivanov at oracle.com Mon Mar 24 16:29:42 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 24 Mar 2014 20:29:42 +0400 Subject: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types In-Reply-To: <532CB847.3080809@oracle.com> References: <5322E7C6.3050603@oracle.com> <659B1DAF-A57F-457F-9F68-8856795555BF@oracle.com> <532C5F6D.30500@oracle.com> <0C91BFD6-57CA-47B1-8DD3-88E0E4B9D252@oracle.com> <532CB847.3080809@oracle.com> Message-ID: <53305D76.7080009@oracle.com> Updated version: http://cr.openjdk.java.net/~vlivanov/8037210/webrev.03/ - changed the way how arrays of types are created: static final BasicType[] ALL_TYPES = BasicType.values(); static final BasicType[] ARG_TYPES = Arrays.copyOf(ALL_TYPES, ALL_TYPES.length-1); - added a test for BasicType (LambdaFormTest.testBasicType). Best regards, Vladimir Ivanov On 3/22/14 2:08 AM, Vladimir Ivanov wrote: > John, thanks for the feedback. > > Updated webrev: > http://cr.openjdk.java.net/~vlivanov/8037210/webrev.02 > > Also moved LambdaForm.testShortenSignature() into a stand-alone unit test. > > Best regards, > Vladimir Ivanov > > On 3/21/14 10:54 PM, John Rose wrote: >> On Mar 21, 2014, at 8:49 AM, Vladimir Ivanov >> > >> wrote: >> >>> Thanks for the feedback. >>> >>> What do you think about the following: >>> http://cr.openjdk.java.net/~vlivanov/8037210/webrev.01/ >> >> That looks nice. Strong typing; who woulda' thunk it. :-) >> >> The uses of ".ordinal()" are the extra cost relative to using just small >> integers. They seem totally reasonable in the code. >> >> I suggest either wrapping "ordinal" as something like "id" or else >> changing temp names like "id" to "ord", to reinforce the use of a common >> name. >> >> Don't make the enum class public. And especially don't make the mutable >> arrays public: >> >> + public static final BasicType[] ALL_TYPES = { L_TYPE, I_TYPE, >> J_TYPE, F_TYPE, D_TYPE, V_TYPE }; >> + public static final BasicType[] ARG_TYPES = { L_TYPE, I_TYPE, >> J_TYPE, F_TYPE, D_TYPE }; >> >> ? John >> >> P.S. That would only be safe if we had (what we don't yet) a notion of >> frozen arrays like: >> >> + public static final BasicType final[] ALL_TYPES = { L_TYPE, >> I_TYPE, J_TYPE, F_TYPE, D_TYPE, V_TYPE }; >> + public static final BasicType final[] ARG_TYPES = { L_TYPE, >> I_TYPE, J_TYPE, F_TYPE, D_TYPE }; >> >> >> >> _______________________________________________ >> 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 Mar 24 16:33:22 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 24 Mar 2014 20:33:22 +0400 Subject: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms In-Reply-To: <53232FF3.9020803@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> Message-ID: <53305E52.2060001@oracle.com> 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 paul.sandoz at oracle.com Mon Mar 24 16:42:50 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 24 Mar 2014 17:42:50 +0100 Subject: The s.m.Unsafe representation in hotspot and method registration Message-ID: <5689350D-66BA-474F-9FB7-E008823FE220@oracle.com> I started working on a patch to remove the monitor related methods on Unsafe, and was thinking this is gonna be easy, it kind of is, but there is some curious code for the registration of the native methods: http://hg.openjdk.java.net/jdk9/dev/hotspot/file/tip/src/share/vm/prims/unsafe.cpp#l1685 JVM_ENTRY(void, JVM_RegisterUnsafeMethods(JNIEnv *env, jclass unsafecls)) UnsafeWrapper("JVM_RegisterUnsafeMethods"); { ThreadToNativeFromVM ttnfv(thread); // Unsafe methods { bool success = false; // We need to register the 1.6 methods first because the 1.8 methods would register fine on 1.7 and 1.6 if (!success) { success = register_natives("1.6 methods", env, unsafecls, methods_16, sizeof(methods_16)/sizeof(JNINativeMethod)); } if (!success) { success = register_natives("1.8 methods", env, unsafecls, methods_18, sizeof(methods_18)/sizeof(JNINativeMethod)); } if (!success) { success = register_natives("1.5 methods", env, unsafecls, methods_15, sizeof(methods_15)/sizeof(JNINativeMethod)); } if (!success) { success = register_natives("1.4.1 methods", env, unsafecls, methods_141, sizeof(methods_141)/sizeof(JNINativeMethod)); } if (!success) { success = register_natives("1.4.0 methods", env, unsafecls, methods_140, sizeof(methods_140)/sizeof(JNINativeMethod)); } guarantee(success, "register unsafe natives"); } And there are multiple declarations of the same methods in various arrays. What is the rational for this kind of registration? I presume when removing methods one removes entries from all arrays? -- One a separate note i think we can also remove all methods marked with @Deprecated (which according to the comments were done so in 1.4.1). Paul. From joel.franck at oracle.com Mon Mar 24 17:37:48 2014 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Mon, 24 Mar 2014 18:37:48 +0100 Subject: The s.m.Unsafe representation in hotspot and method registration In-Reply-To: <5689350D-66BA-474F-9FB7-E008823FE220@oracle.com> References: <5689350D-66BA-474F-9FB7-E008823FE220@oracle.com> Message-ID: <313D6EFC-5DA4-48A6-8544-C34D52960072@oracle.com> Hi Paul, I would guess this is because of the HSX model where we could use the same VM with different majors of the JDK. Would that make sense? cheers /Joel On 24 Mar 2014, at 17:42, Paul Sandoz wrote: > I started working on a patch to remove the monitor related methods on Unsafe, and was thinking this is gonna be easy, it kind of is, but there is some curious code for the registration of the native methods: > > http://hg.openjdk.java.net/jdk9/dev/hotspot/file/tip/src/share/vm/prims/unsafe.cpp#l1685 > > JVM_ENTRY(void, JVM_RegisterUnsafeMethods(JNIEnv *env, jclass unsafecls)) > UnsafeWrapper("JVM_RegisterUnsafeMethods"); > { > ThreadToNativeFromVM ttnfv(thread); > > // Unsafe methods > { > bool success = false; > // We need to register the 1.6 methods first because the 1.8 methods would register fine on 1.7 and 1.6 > if (!success) { > success = register_natives("1.6 methods", env, unsafecls, methods_16, sizeof(methods_16)/sizeof(JNINativeMethod)); > } > if (!success) { > success = register_natives("1.8 methods", env, unsafecls, methods_18, sizeof(methods_18)/sizeof(JNINativeMethod)); > } > if (!success) { > success = register_natives("1.5 methods", env, unsafecls, methods_15, sizeof(methods_15)/sizeof(JNINativeMethod)); > } > if (!success) { > success = register_natives("1.4.1 methods", env, unsafecls, methods_141, sizeof(methods_141)/sizeof(JNINativeMethod)); > } > if (!success) { > success = register_natives("1.4.0 methods", env, unsafecls, methods_140, sizeof(methods_140)/sizeof(JNINativeMethod)); > } > guarantee(success, "register unsafe natives"); > } > > > And there are multiple declarations of the same methods in various arrays. What is the rational for this kind of registration? > > I presume when removing methods one removes entries from all arrays? > > -- > > One a separate note i think we can also remove all methods marked with @Deprecated (which according to the comments were done so in 1.4.1). > > Paul. > > > From brian.burkhalter at oracle.com Mon Mar 24 17:44:00 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 24 Mar 2014 10:44:00 -0700 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: <532D5156.7090904@gmail.com> References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <531EC6BF.4050701@oracle.com> <4742E0AD-8D87-4F22-8F23-779BDF3A58FE@oracle.com> <5320240C.60304@gmail.com> <5322DC66.5070003@gmail.com> <96B8A54B-77FC-4973-8A92-2344A1621F43@oracle.com> <532A290A.7090307@gmail.com> <532A935C.2060604@gmail.com> <532A9DA6.6080707@oracle.com> <26843449-4DCC-4A74-BE32-29836D5FC9F2@oracle.com> <532D5156.7090904@gmail.com> Message-ID: Hi Peter, On Mar 22, 2014, at 2:01 AM, Peter Levart wrote: > Looks good. Just a nit. In the following method: > > 3726 private static void matchScale(BigDecimal[] val) { I concur. > One of 3 ifs is superfluous. Either the 1st one: > > private static void matchScale(BigDecimal[] val) { > /* if (val[0].scale == val[1].scale) { > // return > } else */ if (val[0].scale < val[1].scale) { > val[0] = val[0].setScale(val[1].scale, ROUND_UNNECESSARY); > } else if (val[1].scale < val[0].scale) { > val[1] = val[1].setScale(val[0].scale, ROUND_UNNECESSARY); > } > } I think this one. I?ll update the patch accordingly. Thanks, Brian From brian.burkhalter at oracle.com Mon Mar 24 17:48:13 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 24 Mar 2014 10:48:13 -0700 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: <532FF933.1040900@gmail.com> References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <531EC6BF.4050701@oracle.com> <4742E0AD-8D87-4F22-8F23-779BDF3A58FE@oracle.com> <5320240C.60304@gmail.com> <5322DC66.5070003@gmail.com> <96B8A54B-77FC-4973-8A92-2344A1621F43@oracle.com> <532A290A.7090307@gmail.com> <532A935C.2060604@gmail.com> <532A9DA6.6080707@oracle.com> <532FF933.1040900@gmail.com> Message-ID: Hi Peter, On Mar 24, 2014, at 2:21 AM, Peter Levart wrote: > Thanks to Aleksey for re-establishing the access, I bring you results of the microbenchmark from his quad-core Cortex-A9: Thanks to you and Aleksey for taking the initiative to test on that platform. > ...as can be seen, the double-checked read-then-volatile-read+CAS trick is about 15% faster than classic volatile-read+CAS in this case. Just to be sure, by ?double-checked read-then-volaite-read+CAS trick? you intend "the variant with two methods toString/toStringSlow?? Thanks, Brian From martinrb at google.com Mon Mar 24 17:52:59 2014 From: martinrb at google.com (Martin Buchholz) Date: Mon, 24 Mar 2014 10:52:59 -0700 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: <53201EA5.9090702@gmail.com> References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <5315EDAA.5020801@gmail.com> <531EC3BD.9050605@oracle.com> <53201EA5.9090702@gmail.com> Message-ID: On Wed, Mar 12, 2014 at 1:45 AM, Peter Levart wrote: > > What would the following cost? > > > private transient String stringCache; > > public String toString() { > String sc = stringCache; > if (sc == null) { > sc = (String) U.getObjectVolatile(this, STRING_CACHE_OFFSET); > if (sc == null) { > sc = layoutChars(true); > if (!U.compareAndSwapObject(this, STRING_CACHE_OFFSET, > null, sc)) { > sc = (String) U.getObjectVolatile(this, > STRING_CACHE_OFFSET); > } > } > } > return sc; > } > I feel I'm missing something. If read -> volatile read -> CAS works, then why wouldn't read -> CAS work and be slightly preferable, because "races are unlikely"? public String toString() { String sc = stringCache; if (sc == null) { sc = layoutChars(true); if (!U.compareAndSwapObject(this, STRING_CACHE_OFFSET, null, sc)) { sc = (String) U.getObjectVolatile(this, STRING_CACHE_OFFSET); } } return sc; } From paul.sandoz at oracle.com Mon Mar 24 18:02:10 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 24 Mar 2014 19:02:10 +0100 Subject: The s.m.Unsafe representation in hotspot and method registration In-Reply-To: <313D6EFC-5DA4-48A6-8544-C34D52960072@oracle.com> References: <5689350D-66BA-474F-9FB7-E008823FE220@oracle.com> <313D6EFC-5DA4-48A6-8544-C34D52960072@oracle.com> Message-ID: On Mar 24, 2014, at 6:37 PM, Joel Borggr?n-Franck wrote: > Hi Paul, > > I would guess this is because of the HSX model where we could use the same VM with different majors of the JDK. Would that make sense? > I was wondering about too, but does that still apply to JDKs 1.4.0, 1.4.1, 1.5 and 1.6? Paul. From martinrb at google.com Mon Mar 24 18:03:07 2014 From: martinrb at google.com (Martin Buchholz) Date: Mon, 24 Mar 2014 11:03:07 -0700 Subject: RFR: 8034944: (process) Improve subprocess handling on Solaris In-Reply-To: <532FB6B4.7010300@oracle.com> References: <532C7A30.6060904@oracle.com> <532CA33D.3030502@oracle.com> <532E2113.6040903@gmail.com> <532FB6B4.7010300@oracle.com> Message-ID: On Sun, Mar 23, 2014 at 9:38 PM, Rob McKenna wrote: > > On another note, I too support the merging of those files. I didn't think > there was much appetite for it at the time so I must admit this fell down > my todo list. > Moi aussi. I recall preparing to do this back in 2007, and seeing that it would be more than 10 minutes work ... From vladimir.x.ivanov at oracle.com Mon Mar 24 18:10:52 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 24 Mar 2014 22:10:52 +0400 Subject: [9] RFR (S): 8038261: JSR292: cache and reuse typed array accessors Message-ID: <5330752C.3010700@oracle.com> 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 Mon Mar 24 18:13:34 2014 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 24 Mar 2014 19:13:34 +0100 Subject: The s.m.Unsafe representation in hotspot and method registration In-Reply-To: References: <5689350D-66BA-474F-9FB7-E008823FE220@oracle.com> <313D6EFC-5DA4-48A6-8544-C34D52960072@oracle.com> Message-ID: <533075CE.40205@gmail.com> On 03/24/2014 07:02 PM, Paul Sandoz wrote: > On Mar 24, 2014, at 6:37 PM, Joel Borggr?n-Franck wrote: > >> Hi Paul, >> >> I would guess this is because of the HSX model where we could use the same VM with different majors of the JDK. Would that make sense? >> > I was wondering about too, but does that still apply to JDKs 1.4.0, 1.4.1, 1.5 and 1.6? > > Paul. This seems very shaky. Couldn't VM find out more reliably what major JDK it is running with? Regards, Peter From xueming.shen at oracle.com Mon Mar 24 18:24:36 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 24 Mar 2014 11:24:36 -0700 Subject: RFR: JDK-8033662 DateTimeFormatter parsing ignores withZone() In-Reply-To: References: <532B6F87.3000007@oracle.com> <53304898.7000104@oracle.com> Message-ID: <53307864.8020609@oracle.com> Hi Stephen, The webrev has been updated accordingly. http://cr.openjdk.java.net/~sherman/8033662/webrev/ Thanks! -Sherman On 03/24/2014 08:59 AM, Stephen Colebourne wrote: > I don't think think email was delivered to me. (And I think another from you also wasn't). The email is in the core-libs-dev archive though. > > I think the approach you changed it to is fine in principal although whether the tidy up should be in jdk8u is a different matter. > > In your changes I think that toParsed() should be renamed to toUnresolved(). And there still seem to be instance variables for effectiveZone and effectiveChrono (which I thought you were trying to remove). > > thanks > Stephen > > > > > > On 24 March 2014 15:00, Xueming Shen > wrote: > > > Stephen, > > I commented on this one last week. I did not see the response, is it something worth considering? or > you believe the original approach is the right way to go. > > Thanks! > -Sherman > > -------- Original Message -------- > Message-ID: <532B6F87.3000007 at oracle.com> > Date: Thu, 20 Mar 2014 15:45:27 -0700 > From: Xueming Shen > User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 > MIME-Version: 1.0 > To: core-libs-dev at openjdk.java.net > Subject: Re: RFR: JDK-8033662 DateTimeFormatter parsing ignores withZone() > References: > In-Reply-To: > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > > > Hi Stephen, > > Given the fact that the parser context is no longer public, the parsed from the > formatter is either unresolved or resolved, just wonder if we really need those > "effective" chrono and zone fields in Parsed. It appears perfect for me to simply > keep these info inside the parser context and return the unresolved and resolved > based on the formatter's request, for example > > http://cr.openjdk.java.net/~sherman/8033662/webrev2/ > > -Sherman > > On 03/20/2014 11:24 AM, Stephen Colebourne wrote: > > Hi there, > > It would be great if I could get a review please. > > > > The patch is viewable in plain text at JIRA (for IP reasons): > > https://bugs.openjdk.java.net/secure/attachment/19216/ParseWithZone.patch > > > The same patch is viewable in a nice format at GitHub > https://gist.github.com/jodastephen/9505761 > > This really needs to make 8u20 IMO, so I need to get it into jdk9 first > thanks > Stephen > > > > On 12 March 2014 12:29, Stephen Colebourne wrote: >> This is a request for review of this bug: >> https://bugs.openjdk.java.net/browse/JDK-8033662 >> and the duplicate: >> https://bugs.openjdk.java.net/browse/JDK-8033659 >> >> The javadoc of the method java.time.format.DateTimeFormatter::withZone says: >> "If no zone has been parsed, then this override zone will be included >> in the result of the parse where it can be used to build instants and >> date-times." >> However, the implementation doesn't obey this. >> >> This is a very unfortunate bug that makes some date-time parsing a lot harder. >> >> A second related bug in an egde case - not properly handling a >> ChronoZonedDateTime from TemporalField.resolve - is > also tested for >> and fixed. >> >> >> Proposed patch: >> https://gist.github.com/jodastephen/9505761 >> The patch includes no spec changes. >> The patch includes new and refactored TCK tests. The new tests for >> withZone() and withChronology() are based on the spec. >> >> I need a reviewer and a committer please. >> thanks > > > > From peter.levart at gmail.com Mon Mar 24 18:25:22 2014 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 24 Mar 2014 19:25:22 +0100 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <5315EDAA.5020801@gmail.com> <531EC3BD.9050605@oracle.com> <53201EA5.9090702@gmail.com> Message-ID: <53307892.4020805@gmail.com> On 03/24/2014 06:52 PM, Martin Buchholz wrote: > > > > On Wed, Mar 12, 2014 at 1:45 AM, Peter Levart > wrote: > > > What would the following cost? > > > private transient String stringCache; > > public String toString() { > String sc = stringCache; > if (sc == null) { > sc = (String) U.getObjectVolatile(this, > STRING_CACHE_OFFSET); > if (sc == null) { > sc = layoutChars(true); > if (!U.compareAndSwapObject(this, > STRING_CACHE_OFFSET, null, sc)) { > sc = (String) U.getObjectVolatile(this, > STRING_CACHE_OFFSET); > } > } > } > return sc; > } > > > I feel I'm missing something. If read -> volatile read -> CAS works, > then why wouldn't read -> CAS work and be slightly preferable, because > "races are unlikely"? > > public String toString() { > String sc = stringCache; > if (sc == null) { > sc = layoutChars(true); > if (!U.compareAndSwapObject(this, STRING_CACHE_OFFSET, null, > sc)) { > sc = (String) U.getObjectVolatile(this, > STRING_CACHE_OFFSET); > } > } > return sc; > } ...yeah, I thought about that too. In any case, the overhead of volatile re-read is negligible in this case, since it happens on slow-path and it might reduce the chance of superfluos calls to layoutChars. Regards, Peter From staffan.larsen at oracle.com Mon Mar 24 18:49:14 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 24 Mar 2014 19:49:14 +0100 Subject: The s.m.Unsafe representation in hotspot and method registration In-Reply-To: <533075CE.40205@gmail.com> References: <5689350D-66BA-474F-9FB7-E008823FE220@oracle.com> <313D6EFC-5DA4-48A6-8544-C34D52960072@oracle.com> <533075CE.40205@gmail.com> Message-ID: We have abandoned the HSX model. From JDK 8 one version of Hotspot will be tied to one version of the JDK. This looks like old code that has not been cleaned up. /Staffan On 24 mar 2014, at 19:13, Peter Levart wrote: > > On 03/24/2014 07:02 PM, Paul Sandoz wrote: >> On Mar 24, 2014, at 6:37 PM, Joel Borggr?n-Franck wrote: >> >>> Hi Paul, >>> >>> I would guess this is because of the HSX model where we could use the same VM with different majors of the JDK. Would that make sense? >>> >> I was wondering about too, but does that still apply to JDKs 1.4.0, 1.4.1, 1.5 and 1.6? >> >> Paul. > This seems very shaky. Couldn't VM find out more reliably what major JDK it is running with? > > Regards, Peter > From scolebourne at joda.org Mon Mar 24 18:55:44 2014 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 24 Mar 2014 18:55:44 +0000 Subject: RFR: JDK-8033662 DateTimeFormatter parsing ignores withZone() In-Reply-To: <53307864.8020609@oracle.com> References: <532B6F87.3000007@oracle.com> <53304898.7000104@oracle.com> <53307864.8020609@oracle.com> Message-ID: I'm happy with this updated patch. Stephen On 24 March 2014 18:24, Xueming Shen wrote: > Hi Stephen, > > The webrev has been updated accordingly. > > http://cr.openjdk.java.net/~sherman/8033662/webrev/ > > Thanks! > -Sherman > > > On 03/24/2014 08:59 AM, Stephen Colebourne wrote: > > I don't think think email was delivered to me. (And I think another from > you also wasn't). The email is in the core-libs-dev archive though. > > I think the approach you changed it to is fine in principal although > whether the tidy up should be in jdk8u is a different matter. > > In your changes I think that toParsed() should be renamed to > toUnresolved(). And there still seem to be instance variables for > effectiveZone and effectiveChrono (which I thought you were trying to > remove). > > thanks > Stephen > > > > > > On 24 March 2014 15:00, Xueming Shen wrote: > >> >> Stephen, >> >> I commented on this one last week. I did not see the response, is it >> something worth considering? or >> you believe the original approach is the right way to go. >> >> Thanks! >> -Sherman >> >> -------- Original Message -------- Message-ID: >> <532B6F87.3000007 at oracle.com> <532B6F87.3000007 at oracle.com> Date: Thu, >> 20 Mar 2014 15:45:27 -0700 From: Xueming Shen User-Agent: >> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110414 >> Thunderbird/3.1.10 MIME-Version: 1.0 To: core-libs-dev at openjdk.java.net Subject: >> Re: RFR: JDK-8033662 DateTimeFormatter parsing ignores withZone() References: >> >> In-Reply-To: >> Content-Type: >> text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: >> 7bit >> >> Hi Stephen, >> >> Given the fact that the parser context is no longer public, the parsed from the >> formatter is either unresolved or resolved, just wonder if we really need those >> "effective" chrono and zone fields in Parsed. It appears perfect for me to simply >> keep these info inside the parser context and return the unresolved and resolved >> based on the formatter's request, for example >> http://cr.openjdk.java.net/~sherman/8033662/webrev2/ >> >> -Sherman >> >> On 03/20/2014 11:24 AM, Stephen Colebourne wrote: >> > Hi there, >> > It would be great if I could get a review please. >> > >> > The patch is viewable in plain text at JIRA (for IP reasons): >> > https://bugs.openjdk.java.net/secure/attachment/19216/ParseWithZone.patch >> >> > >> > The same patch is viewable in a nice format at GitHub >> > https://gist.github.com/jodastephen/9505761 >> > >> > This really needs to make 8u20 IMO, so I need to get it into jdk9 first >> > thanks >> > Stephen >> > >> > >> > >> > On 12 March 2014 12:29, Stephen Colebourne wrote: >> >> This is a request for review of this bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8033662 >> >> and the duplicate: >> >> https://bugs.openjdk.java.net/browse/JDK-8033659 >> >> >> >> The javadoc of the method java.time.format.DateTimeFormatter::withZone says: >> >> "If no zone has been parsed, then this override zone will be included >> >> in the result of the parse where it can be used to build instants and >> >> date-times." >> >> However, the implementation doesn't obey this. >> >> >> >> This is a very unfortunate bug that makes some date-time parsing a lot harder. >> >> >> >> A second related bug in an egde case - not properly handling a >> >> ChronoZonedDateTime from TemporalField.resolve - is also tested for >> >> and fixed. >> >> >> >> >> >> Proposed patch: >> >> https://gist.github.com/jodastephen/9505761 >> >> The patch includes no spec changes. >> >> The patch includes new and refactored TCK tests. The new tests for >> >> withZone() and withChronology() are based on the spec. >> >> >> >> I need a reviewer and a committer please. >> >> thanks >> >> >> >> >> > > From martinrb at google.com Mon Mar 24 19:25:31 2014 From: martinrb at google.com (Martin Buchholz) Date: Mon, 24 Mar 2014 12:25:31 -0700 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: <53307892.4020805@gmail.com> References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <5315EDAA.5020801@gmail.com> <531EC3BD.9050605@oracle.com> <53201EA5.9090702@gmail.com> <53307892.4020805@gmail.com> Message-ID: On Mon, Mar 24, 2014 at 11:25 AM, Peter Levart wrote: > > On 03/24/2014 06:52 PM, Martin Buchholz wrote: > > > > > On Wed, Mar 12, 2014 at 1:45 AM, Peter Levart wrote: > >> >> What would the following cost? >> >> >> private transient String stringCache; >> >> public String toString() { >> String sc = stringCache; >> if (sc == null) { >> sc = (String) U.getObjectVolatile(this, STRING_CACHE_OFFSET); >> if (sc == null) { >> sc = layoutChars(true); >> if (!U.compareAndSwapObject(this, STRING_CACHE_OFFSET, >> null, sc)) { >> sc = (String) U.getObjectVolatile(this, >> STRING_CACHE_OFFSET); >> } >> } >> } >> return sc; >> } >> > > I feel I'm missing something. If read -> volatile read -> CAS works, > then why wouldn't read -> CAS work and be slightly preferable, because > "races are unlikely"? > > public String toString() { > String sc = stringCache; > if (sc == null) { > sc = layoutChars(true); > if (!U.compareAndSwapObject(this, STRING_CACHE_OFFSET, null, > sc)) { > sc = (String) U.getObjectVolatile(this, > STRING_CACHE_OFFSET); > } > } > return sc; > } > > > ...yeah, I thought about that too. In any case, the overhead of volatile > re-read is negligible in this case, since it happens on slow-path and it > might reduce the chance of superfluos calls to layoutChars. > Hmmm OK. I still slightly prefer my version, but I can see there is a tradeoff, and the difference is very small. From mike.duigou at oracle.com Mon Mar 24 19:30:55 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 24 Mar 2014 12:30:55 -0700 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <5315EDAA.5020801@gmail.com> <531EC3BD.9050605@oracle.com> <53201EA5.9090702@gmail.com> <53307892.4020805@gmail.com> Message-ID: On Mar 24 2014, at 12:25 , Martin Buchholz wrote: > > > > On Mon, Mar 24, 2014 at 11:25 AM, Peter Levart wrote: > > On 03/24/2014 06:52 PM, Martin Buchholz wrote: >> >> >> >> On Wed, Mar 12, 2014 at 1:45 AM, Peter Levart wrote: >> >> What would the following cost? >> >> >> private transient String stringCache; >> >> public String toString() { >> String sc = stringCache; >> if (sc == null) { >> sc = (String) U.getObjectVolatile(this, STRING_CACHE_OFFSET); >> if (sc == null) { >> sc = layoutChars(true); >> if (!U.compareAndSwapObject(this, STRING_CACHE_OFFSET, null, sc)) { >> sc = (String) U.getObjectVolatile(this, STRING_CACHE_OFFSET); >> } >> } >> } >> return sc; >> } >> >> I feel I'm missing something. If read -> volatile read -> CAS works, then why wouldn't read -> CAS work and be slightly preferable, because "races are unlikely"? >> >> public String toString() { >> String sc = stringCache; >> if (sc == null) { >> sc = layoutChars(true); >> if (!U.compareAndSwapObject(this, STRING_CACHE_OFFSET, null, sc)) { >> sc = (String) U.getObjectVolatile(this, STRING_CACHE_OFFSET); >> } >> } >> return sc; >> } > > ...yeah, I thought about that too. In any case, the overhead of volatile re-read is negligible in this case, since it happens on slow-path and it might reduce the chance of superfluos calls to layoutChars. > > Hmmm OK. I still slightly prefer my version, but I can see there is a tradeoff, and the difference is very small. The other issue here, and why this thread has gone on so long, is that we've been trying to establish what the best idiom is (for 2014-????) for this lazy initialization situation so that we can reuse it with less thought and review. In this case the chances of race are fairly low and the cost of extra layoutChars is bearable. In other cases where we are likely to use the same idiom this is less likely true. Peter's current implementation has the advantage that is the best-right answer for lazy initialization even in the contended/expensive case. I look forward to revisiting this again when the new JMM primitives are available. :-) Mike From igor.ignatyev at oracle.com Mon Mar 24 20:33:44 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 25 Mar 2014 00:33:44 +0400 Subject: RFR(S) : 8038186 : [TESTBUG] improvements of test j.l.i.MethodHandles Message-ID: <533096A8.1020405@oracle.com> Hi all, Please review the patch: Problems: - MethodHandlesTest::testCatchException() doesn't provide enough testing of j.l.i.MethodHandles::catchException(). - MethodHandlesTest contains more than 3k lines, an auxiliary code together w/ a test code, many methods aren't connected w/ each other, etc. All this leads to that it is very very hard to understand, maintain. Fix: - the auxiliary code was moved to testlibray - the test code was moved to a separate subpackage - random signature is used for target and handler - added scenarios w/ different return types webrev: http://cr.openjdk.java.net/~iignatyev/8038186/webrev.01/ jbs: https://bugs.openjdk.java.net/browse/JDK-8038186 -- Igor From roger.riggs at oracle.com Mon Mar 24 20:55:48 2014 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 24 Mar 2014 16:55:48 -0400 Subject: [9] Review request: new macro for conversion to jboolean In-Reply-To: References: <53270E65.4070001@oracle.com> <53273F9A.3080403@oracle.com> <5329E3B7.7000000@oracle.com> <5329F8A4.6030908@oracle.com> <5329F93A.2010205@oracle.com> <5329F91E.4050703@oracle.com> <532A2B8E.9040707@oracle.com> <532C5658.6050601@oracle.com> Message-ID: <53309BD4.2080902@oracle.com> Hi, For now I would just use the explicit ternary operator. The macro would have a very narrow use. Improving the ability to do static checking on JNI types would be a larger undertaking. Roger On 3/21/2014 5:38 PM, Mike Duigou wrote: > What if we just abandon adding an IS_TRUE / TO_JBOOLEAN macro for now. > > I would like to address adding (jboolean) casts to jni.h which I suspect would help with the static analysis issues encountered. > > For now just use the explicit ? JNI_TRUE : JNI_FALSE whenever a jboolean value is needed and we can refactor the naming of the macro, if any is required, later. > > Mike > > On Mar 21 2014, at 08:10 , roger riggs wrote: > >> Hi Sergey, >> >> I didn't see any examples of the use case in this thread. The proposed name seems bulky and clumsy. >> >> In the snippet provided, it did not seem necessary to force the cast to jboolean. >> Both JNI_TRUE and JNI_FALSE are untyped constants. >> >> The macro would just as useful (if I understand the cases) without the cast. >> >> How useful is a simple definition as: >> >> #define IS_TRUE(obj) ((obj) ? JNI_TRUE : JNI_FALSE) >> >> then it would look ok to see these in sources: >> >> return IS_TRUE(obj); >> >> if (IS_TRUE(obj)) {....} >> >> jboolean ret = IS_TRUE(obj); >> >> The general purpose usage matches the general C conventions for >> true and false and match the JNI semantics. >> >> Roger >> >> >> >> On 3/19/2014 7:43 PM, Sergey Bylokhov wrote: >>> Thanks. >>> So if nobody objects, the final version will be: >>> >>> #define IS_NULL(obj) ((obj) == NULL) >>> #define JNU_IsNull(env,obj) ((obj) == NULL) >>> +#define TO_JBOOLEAN(obj) (jboolean) ((obj) ? JNI_TRUE : JNI_FALSE) >>> >>> >>> On 3/20/14 12:07 AM, roger riggs wrote: >>>> Hi, >>>> >>>> Well... When JNU_RETURN was added, there was a long discussion about >>>> NOT using JNU unless the JNI environment was an argument to the macro. >>>> >>>> So, the simple name is preferred. >>>> >>>> Roger >>>> >>>> On 3/19/2014 4:08 PM, Phil Race wrote: >>>>> PS .. so maybe whilst you are touching this file you could do >>>>> #define JNU_CHECK_NULL CHECK_NULL >>>>> #define JNU_CHECK_NULL_RETURN CHECK_NULL_RETURN >>>>> >>>>> so we could migrate to these (clearer) ones >>>>> >>>>> -phil. >>>>> >>>>> On 3/19/2014 1:05 PM, Phil Race wrote: >>>>>> I think having it start with "JNU_" is a good suggestion. >>>>>> I've been wondering over the last week or so if it would not have been >>>>>> better to have CHECK_NULL called JNU_CHECK_NULL to reduce collision chances >>>>>> and to make it clearer where it comes from .. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 3/19/2014 12:49 PM, Mike Duigou wrote: >>>>>>> Definitely a useful macro. >>>>>>> >>>>>>> I too would prefer a name like TO_JBOOLEAN since it reveals the result type. Also all uppercase to identify it as a macro. If we are paranoid and want to reduce the chance of a name collision then JNU_TO_JBOOLEAN perhaps. >>>>>>> >>>>>>> I would also define the macro as: >>>>>>> >>>>>>> #define JNU_TO_JBOOLEAN(obj) (jboolean) ((obj) ? JNI_TRUE : JNI_FALSE) >>>>>>> >>>>>>> so that the type of the result is explicit. Unfortunately jni.h doesn't define JNI_TRUE or false with a cast to jboolean as they probably should. >>>>>>> >>>>>>> Mike >>>>>>> >>>>>>> On Mar 19 2014, at 11:36 , Sergey Bylokhov wrote: >>>>>>> >>>>>>>> Thanks Anthony! >>>>>>>> >>>>>>>> Can somebody from the core-libs team take a look? >>>>>>>> >>>>>>>> On 3/17/14 10:31 PM, Anthony Petrov wrote: >>>>>>>>> Personally, I'd call it to_jboolean(obj), but IS_TRUE(obj) sounds good to me too. Either way, I'm fine with the fix. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> best regards, >>>>>>>>> Anthony >>>>>>>>> >>>>>>>>> On 3/17/2014 7:01 PM, Sergey Bylokhov wrote: >>>>>>>>>> Hello. >>>>>>>>>> This review request is for the new macro, which simplify conversion to >>>>>>>>>> jboolean. It will be useful for fixing parfait warnings. >>>>>>>>>> >>>>>>>>>> We have a lot of places, where we cast some type to jboolean: >>>>>>>>>> >>>>>>>>>> BOOL = retVal; >>>>>>>>>> return (jboolean) retVal; >>>>>>>>>> >>>>>>>>>> WARNING: Expecting value of JNI primitive type jboolean: mismatched >>>>>>>>>> value retVal with size 32 bits, retVal used for conversion to int8 in return >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> +++ b/src/share/native/common/jni_util.h Mon Mar 17 18:28:48 2014 +0400 >>>>>>>>>> @@ -277,6 +277,7 @@ >>>>>>>>>> >>>>>>>>>> #define IS_NULL(obj) ((obj) == NULL) >>>>>>>>>> #define JNU_IsNull(env,obj) ((obj) == NULL) >>>>>>>>>> +#define IS_TRUE(obj) ((obj) ? JNI_TRUE : JNI_FALSE) >>>>>>>>>> >>>>>>>>>> I am not sure about the name, probably someone have a better suggestion? >>>>>>>>>> >>>>>>>>>> The fix is for jdk9/dev. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Best regards, Sergey. >>>>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, Sergey. >>>>>>>> >>> From roger.riggs at oracle.com Mon Mar 24 21:05:25 2014 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 24 Mar 2014 17:05:25 -0400 Subject: RFR: 8034944: (process) Improve subprocess handling on Solaris In-Reply-To: <532FB6B4.7010300@oracle.com> References: <532C7A30.6060904@oracle.com> <532CA33D.3030502@oracle.com> <532E2113.6040903@gmail.com> <532FB6B4.7010300@oracle.com> Message-ID: <53309E15.2060405@oracle.com> Hi Rob, Martin, et.al. I've prototyped (for 9) a thread reaper[1] that uses a single thread to wait for exiting processes and calling back to the process with the exit status. the interesting part is getting the exit status back to the Process that needs it It needs more testing and hardening. I had not considered using a signal handler for SIGCHLD but that's an option, though we need to be very careful about thread usage. Roger p.s. comments on the single thread reaper appreciated (in a new thread) [1] http://cr.openjdk.java.net/~rriggs/webrev-waitpid/ On 3/24/2014 12:38 AM, Rob McKenna wrote: > Hi folks, > > Roger Riggs (cc'd) may want to chip in here as he's looking at the > reaper thread arrangement in 9 at the moment. > > On another note, I too support the merging of those files. I didn't > think there was much appetite for it at the time so I must admit this > fell down my todo list. Looking at this bug did remind me that its > something worth trying though. As per Alan's mail, I'm going to tackle > it separately if you folks don't mind. I'll have a look at Peter's > changes (thanks Peter!) as soon as I can and see about getting them in. > > -Rob > > On 23/03/14 22:30, Martin Buchholz wrote: >> >> >> >> On Sun, Mar 23, 2014 at 2:34 AM, Martin Buchholz > > wrote: >> >> >> We have also thought about whether having reaper threads is >> necessary. The Unix rule is that child processes should be >> waited for, and some thread needs to do that. There's no way to >> wait for a set of child pids, or to specify a "completion >> handler". Well, you might be able to get the newish waitid() to >> do what you want, but it looks like it's not sufficient when java >> is running inside a process that might do independent subprocess >> creation outside of the JVM. >> >> >> Actually, I take it back. With sufficient work, it looks like you >> can get SIGCHLD to give you pid information in siginfo_t si_pid, and >> that can be used to trigger the reaping. It looks like waitpid is >> "async-signal-safe", so we can call it from our signal handler. >> >> While we're at it we can fix SIGCHLD handling to do signal chaining, >> as with other signals. > From roger.riggs at oracle.com Mon Mar 24 21:11:06 2014 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 24 Mar 2014 17:11:06 -0400 Subject: Process API Updates (JEP 102) In-Reply-To: References: <52FD3897.7070903@oracle.com> <52FE7931.4020408@oracle.com> Message-ID: <53309F6A.1050002@oracle.com> Hi, I'm starting to work on JEP 102, Process API Updates for JDK 9. The use cases identified include test execution and build systems such as Jtreg and Hudson/Jenkins. And there is a use-case for using Java to monitor the health of a more complex system where the processes are not spawned by the same manager. The current API of Process itself is pretty complete with the addition of a getPid method to enable identification of subprocesses spawned by the application and allow external identification. It will not be possible to intercept the input, output and error streams of an arbitrary process. From the scope of the JEP, a fairly simple API seems sufficient. - Enumerate the direct children - The rest of the functions are similar to Process - to terminate a process, forcibly and normally - to destroy a process and all of its children recursively - to check if one is alive - to waitFor for termination and retrieve the exit status Are there use cases for which this is insufficient? Please comment. Thanks, Roger From peter.levart at gmail.com Tue Mar 25 08:33:22 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 25 Mar 2014 09:33:22 +0100 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <531EC6BF.4050701@oracle.com> <4742E0AD-8D87-4F22-8F23-779BDF3A58FE@oracle.com> <5320240C.60304@gmail.com> <5322DC66.5070003@gmail.com> <96B8A54B-77FC-4973-8A92-2344A1621F43@oracle.com> <532A290A.7090307@gmail.com> <532A935C.2060604@gmail.com> <532A9DA6.6080707@oracle.com> <532FF933.1040900@gmail.com> Message-ID: <53313F52.5010507@gmail.com> On 03/24/2014 06:48 PM, Brian Burkhalter wrote: > Hi Peter, > > On Mar 24, 2014, at 2:21 AM, Peter Levart > wrote: > >> Thanks to Aleksey for re-establishing the access, I bring you results >> of the microbenchmark from his quad-core Cortex-A9: > > Thanks to you and Aleksey for taking the initiative to test on that > platform. > >> ...as can be seen, the double-checked read-then-volatile-read+CAS >> trick is about 15% faster than classic volatile-read+CAS in this case. > > Just to be sure, by ?double-checked read-then-volaite-read+CAS trick? > you intend "the variant with two methods toString/toStringSlow?? That's right. I split the code into two methods in both cases to make sure it gets inlined for fast-path. The variant in your webrev with single method has been demonstrated to exceed the maximum inline bytecode size. Regards, Peter > > Thanks, > > Brian From paul.sandoz at oracle.com Tue Mar 25 08:34:51 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 25 Mar 2014 09:34:51 +0100 Subject: The s.m.Unsafe representation in hotspot and method registration In-Reply-To: References: <5689350D-66BA-474F-9FB7-E008823FE220@oracle.com> <313D6EFC-5DA4-48A6-8544-C34D52960072@oracle.com> <533075CE.40205@gmail.com> Message-ID: <60AA9737-22FB-4957-B3B8-EA4E3E6838AD@oracle.com> On Mar 24, 2014, at 7:49 PM, Staffan Larsen wrote: > We have abandoned the HSX model. From JDK 8 one version of Hotspot will be tied to one version of the JDK. This looks like old code that has not been cleaned up. > Thanks, yes, looks like we can clean this up and also remove the deprecated methods at the same time. Paul. From kasperni at gmail.com Tue Mar 25 08:45:54 2014 From: kasperni at gmail.com (Kasper Nielsen) Date: Tue, 25 Mar 2014 09:45:54 +0100 Subject: Process API Updates (JEP 102) In-Reply-To: <53309F6A.1050002@oracle.com> References: <52FD3897.7070903@oracle.com> <52FE7931.4020408@oracle.com> <53309F6A.1050002@oracle.com> Message-ID: On Mon, Mar 24, 2014 at 10:11 PM, roger riggs wrote: > Hi, > > I'm starting to work on JEP 102, Process API Updates for JDK 9. > > Are there use cases for which this is insufficient? Please comment. > > What about a non-blocking waitFor mechanism such as void onTerminate(IntConsumer consumer) or CompletionStage onTerminate(); Would be useful for spawning many small processes. Also a waitFor method taking a timeout parameter. So you, for example, can wait for the subprocess to exit within 10 seconds. And if not kill it. - Kasper From martijnverburg at gmail.com Tue Mar 25 08:54:27 2014 From: martijnverburg at gmail.com (Martijn Verburg) Date: Tue, 25 Mar 2014 08:54:27 +0000 Subject: Process API Updates (JEP 102) In-Reply-To: <53309F6A.1050002@oracle.com> References: <52FD3897.7070903@oracle.com> <52FE7931.4020408@oracle.com> <53309F6A.1050002@oracle.com> Message-ID: Hi Roger, Is there a short survey we could send out to the wider dev community on this one? I think just about every day to day Java developer has had to use Process at some stage in their career. Cheers, Martijn On 24 March 2014 21:11, roger riggs wrote: > Hi, > > I'm starting to work on JEP 102, Process API Updates for JDK 9. > The use cases identified include test execution and build systems such > as Jtreg and Hudson/Jenkins. And there is a use-case for using Java > to monitor the health of a more complex system where the processes > are not spawned by the same manager. > > The current API of Process itself is pretty complete with the addition of > a getPid > method to enable identification of subprocesses spawned by the application > and allow external identification. It will not be possible to intercept > the input, > output and error streams of an arbitrary process. > > From the scope of the JEP, a fairly simple API seems sufficient. > - Enumerate the direct children > - The rest of the functions are similar to Process > - to terminate a process, forcibly and normally > - to destroy a process and all of its children recursively > - to check if one is alive > - to waitFor for termination and retrieve the exit status > > Are there use cases for which this is insufficient? Please comment. > > Thanks, Roger > > From snazy at snazy.de Tue Mar 25 08:56:00 2014 From: snazy at snazy.de (Robert Stupp) Date: Tue, 25 Mar 2014 09:56:00 +0100 Subject: Process API Updates (JEP 102) In-Reply-To: References: <52FD3897.7070903@oracle.com> <52FE7931.4020408@oracle.com> <53309F6A.1050002@oracle.com> Message-ID: <58A1C17C-F25C-4A60-83C5-99A145341442@snazy.de> Would be nice to have some kind of "async" process I/O streaming. And an event mechanism to receive notifications when the process terminates or input is available from stdout/stderr. > Am 25.03.2014 um 09:45 schrieb Kasper Nielsen : > > On Mon, Mar 24, 2014 at 10:11 PM, roger riggs wrote: > >> Hi, >> >> I'm starting to work on JEP 102, Process API Updates for JDK 9. >> >> Are there use cases for which this is insufficient? Please comment. > What about a non-blocking waitFor mechanism such as > > void onTerminate(IntConsumer consumer) or > CompletionStage onTerminate(); > > Would be useful for spawning many small processes. > > > Also a waitFor method taking a timeout parameter. So you, for example, can > wait for the subprocess to exit within 10 seconds. And if not kill it. > > - Kasper From paul.sandoz at oracle.com Tue Mar 25 08:58:58 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 25 Mar 2014 09:58:58 +0100 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <5315EDAA.5020801@gmail.com> <531EC3BD.9050605@oracle.com> <53201EA5.9090702@gmail.com> <53307892.4020805@gmail.com> Message-ID: On Mar 24, 2014, at 8:30 PM, Mike Duigou wrote: > The other issue here, and why this thread has gone on so long, is that we've been trying to establish what the best idiom is (for 2014-????) for this lazy initialization situation so that we can reuse it with less thought and review. In this case the chances of race are fairly low and the cost of extra layoutChars is bearable. In other cases where we are likely to use the same idiom this is less likely true. Peter's current implementation has the advantage that is the best-right answer for lazy initialization even in the contended/expensive case. I look forward to revisiting this again when the new JMM primitives are available. :-) > This is another example of a stable variable. I would like to re-iterate my scepticism that such changes are necessary in this case (i am not sure if it is possible to create a benchmark that could better exacerbate the concurrent overlap of calls to layoutChars). But, i do agree the discussion has been useful and interesting. Paul. From chris.hegarty at oracle.com Tue Mar 25 09:06:59 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 25 Mar 2014 09:06:59 +0000 Subject: Process API Updates (JEP 102) In-Reply-To: References: <52FD3897.7070903@oracle.com> <52FE7931.4020408@oracle.com> <53309F6A.1050002@oracle.com> Message-ID: <3D785D36-2599-453E-BEDF-973808D1DF0C@oracle.com> On 25 Mar 2014, at 08:45, Kasper Nielsen wrote: > On Mon, Mar 24, 2014 at 10:11 PM, roger riggs wrote: > >> Hi, >> >> I'm starting to work on JEP 102, Process API Updates for JDK 9. >> >> Are there use cases for which this is insufficient? Please comment. >> >> > What about a non-blocking waitFor mechanism such as > > void onTerminate(IntConsumer consumer) or > CompletionStage onTerminate(); > > Would be useful for spawning many small processes. > > > Also a waitFor method taking a timeout parameter. So you, for example, can > wait for the subprocess to exit within 10 seconds. And if not kill it. Have you looked at these new methods in Java 8? Or are you looking for something different? http://download.java.net/jdk8/docs/api/java/lang/Process.html#waitFor-long-java.util.concurrent.TimeUnit- http://download.java.net/jdk8/docs/api/java/lang/Process.html#destroyForcibly-- -Chris. > > - Kasper From mattis.castegren at oracle.com Tue Mar 25 09:45:54 2014 From: mattis.castegren at oracle.com (Mattis Castegren) Date: Tue, 25 Mar 2014 02:45:54 -0700 (PDT) Subject: RFR: 8036786: Update jdk7 testlibrary to match jdk8 In-Reply-To: <53231533.9010908@oracle.com> References: <5318956F.1020603@oracle.com> <53231533.9010908@oracle.com> Message-ID: <6cd9d82e-79fc-4e3e-ba41-5a8842250d59@default> This is becoming URGENT as we have other high priority cases pending the backport of these test libraries. We could backport these fixes without the tests and then file a separate bug to backport the tests, but it would be great if we could just get a review of this, as it is a pretty straight forward backport Kind Regards /Mattis -----Original Message----- From: Alan Bateman Sent: den 14 mars 2014 15:42 To: Mattis Castegren Cc: Vladimir Kempik; core-libs-dev at openjdk.java.net; Ekaterina Medvedeva; serviceability-dev at openjdk.java.net Subject: Re: RFR: 8036786: Update jdk7 testlibrary to match jdk8 Adding serviceability-dev to the CC list as this seems to be where this testlibrary has mostly been developed and maintained. -Alan. On 13/03/2014 14:02, Mattis Castegren wrote: > Hi > > Could we have someone review this change. This is just a backport from JDK8, but there were some small changes so we want to get a proper review here. > > We have several other backports waiting for this change (fixes using the new test libraries), so it would be good to get this going. > > Kind Regards > /Mattis > > -----Original Message----- > From: Vladimir Kempik > Sent: den 6 mars 2014 16:34 > To: core-libs-dev at openjdk.java.net > Cc: Mattis Castegren > Subject: RFR: 8036786: Update jdk7 testlibrary to match jdk8 > > Please review this change to update jdk part of testlibrary in jdk7. > > It updates testlibrary with new apis from jdk8's testlibrary. > > When porting jdk8's testlibrary to jdk7, I had to make few changes: > > 1) rewrite one lambda usage in StreamPumper.java to non-lambda version. > > 2) get rid of predicate functionality in ProcessTools.java: startProcess > as it wasn't used anyway and unsupported in jdk7. > > Every test in open part of jdk that uses testlibrary still works after > update (in fact there are 3 of them). > > Webrev: > http://cr.openjdk.java.net/~vkempik/8036786/webrev.00/ > > Thanks, Vladimir. From peter.levart at gmail.com Tue Mar 25 09:50:41 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 25 Mar 2014 10:50:41 +0100 Subject: Process API Updates (JEP 102) In-Reply-To: <53309F6A.1050002@oracle.com> References: <52FD3897.7070903@oracle.com> <52FE7931.4020408@oracle.com> <53309F6A.1050002@oracle.com> Message-ID: <53315171.6090707@gmail.com> On 03/24/2014 10:11 PM, roger riggs wrote: > Hi, > > I'm starting to work on JEP 102, Process API Updates for JDK 9. > The use cases identified include test execution and build systems such > as Jtreg and Hudson/Jenkins. And there is a use-case for using Java > to monitor the health of a more complex system where the processes > are not spawned by the same manager. > > The current API of Process itself is pretty complete with the addition > of a getPid > method to enable identification of subprocesses spawned by the > application > and allow external identification. It will not be possible to > intercept the input, > output and error streams of an arbitrary process. > > From the scope of the JEP, a fairly simple API seems sufficient. > - Enumerate the direct children What about self? An application might want to communicate it's own PID to some other process (write it into a file, for example). Other Process API methods are not sensible for "self" process so this might as well be just simple static getSelfPid() method. > - The rest of the functions are similar to Process > - to terminate a process, forcibly and normally > - to destroy a process and all of its children recursively > - to check if one is alive > - to waitFor for termination and retrieve the exit status > > Are there use cases for which this is insufficient? Please comment. It would be nice if this new API interoperated with old Process API in a way that using both interchangeably for the same child process would be possible. For example: spawning a child with old Process API and enumerating/waiting/checking it with new API in some thread while waiting for termination using old API in another thread... I wonder if an approach to just add getPid() (and maybe some other method) to old Process class together with some static methods to enumerate child processes would be possible? It would just require the API specification to strengthen it's guarantees on some methods: for example destroyForcibly() would guarantee forcible termination. It might require an additional method like destroyNicely() or terminateNicely() which would guarantee a kind of termination where victim process could clean-up. The specification already allows getInputStream()/getOutputStream()/getErrorStream() to return special "null streams" when spawned process IO is redirected to/from file. The enumeration methods could simply return Process object which would: - be same instances of Process objects created with ProcessBuilder API for processes spawned by the Process API. This would require an internal registry of live Process objects. We already have reaper threads which could be used to clean-up this registry on process termination. - be new Process objects for child processes spawned in some other way (or by children) and which would return special "null streams" from their getInputStream()/getOutputStream()/getErrorStream() methods. These Process objects could be instantiated lazily on first request and then registered in the same internal registry. They might still require reaper threads to enable waiting on them from multiple Java threads and cleaning-up registry, but they could probably be created lazily. The worst thing is to have an entirely separate API that does not interoperate with old API. I think the old API is not so bad. It just lacks some features and it's implementation could be revamped a bit. What do you think? Regards, Peter > > Thanks, Roger > From staffan.larsen at oracle.com Tue Mar 25 10:17:24 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 25 Mar 2014 11:17:24 +0100 Subject: RFR: 8036786: Update jdk7 testlibrary to match jdk8 In-Reply-To: <5318956F.1020603@oracle.com> References: <5318956F.1020603@oracle.com> Message-ID: <2F628FEC-D4EE-481C-ADED-CD68773C0215@oracle.com> I?ve looked at the changes in StreamPumper and ProcessTools: they look good. Since the rest of the code is a straight backport, I didn?t look at it. Reviewed. Thanks, /Staffan On 6 mar 2014, at 16:34, Vladimir Kempik wrote: > Please review this change to update jdk part of testlibrary in jdk7. > > It updates testlibrary with new apis from jdk8's testlibrary. > > When porting jdk8's testlibrary to jdk7, I had to make few changes: > > 1) rewrite one lambda usage in StreamPumper.java to non-lambda version. > > 2) get rid of predicate functionality in ProcessTools.java: startProcess as it wasn't used anyway and unsupported in jdk7. > > Every test in open part of jdk that uses testlibrary still works after update (in fact there are 3 of them). > > Webrev: > http://cr.openjdk.java.net/~vkempik/8036786/webrev.00/ > > Thanks, Vladimir. From staffan.larsen at oracle.com Tue Mar 25 12:14:57 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 25 Mar 2014 13:14:57 +0100 Subject: RFR(S): 8034960: Serviceability tests using @library failing with java.lang.NoClassDefFoundError In-Reply-To: <5331718B.2020909@oracle.com> References: <5331718B.2020909@oracle.com> Message-ID: <920D97EC-4782-46BC-BFE9-6B3800DB6C27@oracle.com> I?ve looked at a random sample of these changes and they look ok. Since some of the changes are in non-serviceability code I have also added core-libs to the review thread. I?m sure you know this, but for the record: please don?t push this until jtreg with the fix has been promoted. Thanks, /Staffan On 25 mar 2014, at 13:07, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > webrev: http://cr.openjdk.java.net/~ykantser/8034960/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8034960 > > When using @library in a JTreg test even @build need to be specify for all library files used by the test. If @build is not specified it can lead to intermittent failures when running tests concurrently, since javac implicit compilation and @library and -concurrency don't play well together. > > Verified locally since no JTreg with fix has been promoted yet. > > > Thanks, > Katja From david.lloyd at redhat.com Tue Mar 25 12:17:06 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 25 Mar 2014 07:17:06 -0500 Subject: Process API Updates (JEP 102) In-Reply-To: <53309F6A.1050002@oracle.com> References: <52FD3897.7070903@oracle.com> <52FE7931.4020408@oracle.com> <53309F6A.1050002@oracle.com> Message-ID: <533173C2.5080007@redhat.com> On 03/24/2014 04:11 PM, roger riggs wrote: > Hi, > > I'm starting to work on JEP 102, Process API Updates for JDK 9. > The use cases identified include test execution and build systems such > as Jtreg and Hudson/Jenkins. And there is a use-case for using Java > to monitor the health of a more complex system where the processes > are not spawned by the same manager. > > The current API of Process itself is pretty complete with the addition > of a getPid > method to enable identification of subprocesses spawned by the application > and allow external identification. It will not be possible to intercept > the input, > output and error streams of an arbitrary process. > > From the scope of the JEP, a fairly simple API seems sufficient. > - Enumerate the direct children > - The rest of the functions are similar to Process > - to terminate a process, forcibly and normally > - to destroy a process and all of its children recursively > - to check if one is alive > - to waitFor for termination and retrieve the exit status > > Are there use cases for which this is insufficient? Please comment. There are two features we would definitely like to see added: 1) NIO Channel interface for process streams 2) The ability to pass additional channels to child processes #1 seems relatively straightforward, but admittedly it's not clear how #2 might be possible from the child process side. -- - DML From fweimer at redhat.com Tue Mar 25 12:18:10 2014 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 25 Mar 2014 13:18:10 +0100 Subject: Process API Updates (JEP 102) In-Reply-To: <53309F6A.1050002@oracle.com> References: <52FD3897.7070903@oracle.com> <52FE7931.4020408@oracle.com> <53309F6A.1050002@oracle.com> Message-ID: <53317402.9040007@redhat.com> On 03/24/2014 10:11 PM, roger riggs wrote: > From the scope of the JEP, a fairly simple API seems sufficient. > - Enumerate the direct children > - The rest of the functions are similar to Process > - to terminate a process, forcibly and normally > - to destroy a process and all of its children recursively > - to check if one is alive > - to waitFor for termination and retrieve the exit status On Linux, I think you need to use obscure mechanisms to make this iteration reliable (cgroups perhaps). There is no openpid() or similar mechanism that allows you to obtain a stable handle. Somewhat relatedly, it would make sense to make Process auto-closeable, so that you can make sure that no non-Java resources are retained. Right now, this seems to require calling destroyForcibly().waitFor(). It would be nice if there was a way to directly pipe the output of one process to the input of another process. I think that even with Java 8, this still needs an explicit copy loop. -- Florian Weimer / Red Hat Product Security Team From paul.sandoz at oracle.com Tue Mar 25 13:20:30 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 25 Mar 2014 14:20:30 +0100 Subject: Experimental patches for unsafe cleanup Re: The s.m.Unsafe representation in hotspot and method registration In-Reply-To: <60AA9737-22FB-4957-B3B8-EA4E3E6838AD@oracle.com> References: <5689350D-66BA-474F-9FB7-E008823FE220@oracle.com> <313D6EFC-5DA4-48A6-8544-C34D52960072@oracle.com> <533075CE.40205@gmail.com> <60AA9737-22FB-4957-B3B8-EA4E3E6838AD@oracle.com> Message-ID: On Mar 25, 2014, at 9:34 AM, Paul Sandoz wrote: > > On Mar 24, 2014, at 7:49 PM, Staffan Larsen wrote: > >> We have abandoned the HSX model. From JDK 8 one version of Hotspot will be tied to one version of the JDK. This looks like old code that has not been cleaned up. >> > > Thanks, yes, looks like we can clean this up and also remove the deprecated methods at the same time. > Here are some preliminary webrevs to clean up unsafe and also remove all old, deprecated and monitor-related methods: http://cr.openjdk.java.net/~psandoz/jdk9/jdk-unsafe-cleanup/webrev/jdk.patch http://cr.openjdk.java.net/~psandoz/jdk9/hotspot-unsafe-cleanup/webrev/ Passes all tests i have thrown at it locally. There is some additional clean up that could be done to remove prefetch read/write intrinsics hooked up to older versions of Unsafe: do_intrinsic(_prefetchRead, sun_misc_Unsafe, prefetchRead_name, prefetch_signature, F_RN) \ do_name( prefetchRead_name, "prefetchRead") \ do_intrinsic(_prefetchWrite, sun_misc_Unsafe, prefetchWrite_name, prefetch_signature, F_RN) \ do_name( prefetchWrite_name, "prefetchWrite") \ do_intrinsic(_prefetchReadStatic, sun_misc_Unsafe, prefetchReadStatic_name, prefetch_signature, F_SN) \ do_name( prefetchReadStatic_name, "prefetchReadStatic") \ do_intrinsic(_prefetchWriteStatic, sun_misc_Unsafe, prefetchWriteStatic_name, prefetch_signature, F_SN) \ do_name( prefetchWriteStatic_name, "prefetchWriteStatic") \ That will also require updates in various other files. I presume these prefetch methods are never used throughout the runtime? Paul. From Roger.Riggs at Oracle.com Tue Mar 25 13:28:28 2014 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 25 Mar 2014 06:28:28 -0700 Subject: Process API Updates (JEP 102) In-Reply-To: References: <52FD3897.7070903@oracle.com> <52FE7931.4020408@oracle.com> <53309F6A.1050002@oracle.com> Message-ID: <5331847C.3010001@Oracle.com> Hi Martin, Good idea, I'll put something together in the next couple of weeks. Roger On 3/25/14 1:54 AM, Martijn Verburg wrote: > Hi Roger, > > Is there a short survey we could send out to the wider dev community > on this one? I think just about every day to day Java developer has > had to use Process at some stage in their career. > > Cheers, > Martijn > > > On 24 March 2014 21:11, roger riggs > wrote: > > Hi, > > I'm starting to work on JEP 102, Process API Updates for JDK 9. > The use cases identified include test execution and build systems such > as Jtreg and Hudson/Jenkins. And there is a use-case for using Java > to monitor the health of a more complex system where the processes > are not spawned by the same manager. > > The current API of Process itself is pretty complete with the > addition of a getPid > method to enable identification of subprocesses spawned by the > application > and allow external identification. It will not be possible to > intercept the input, > output and error streams of an arbitrary process. > > From the scope of the JEP, a fairly simple API seems sufficient. > - Enumerate the direct children > - The rest of the functions are similar to Process > - to terminate a process, forcibly and normally > - to destroy a process and all of its children recursively > - to check if one is alive > - to waitFor for termination and retrieve the exit status > > Are there use cases for which this is insufficient? Please comment. > > Thanks, Roger > > From Alan.Bateman at oracle.com Tue Mar 25 13:30:58 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 25 Mar 2014 13:30:58 +0000 Subject: Process API Updates (JEP 102) In-Reply-To: <53315171.6090707@gmail.com> References: <52FD3897.7070903@oracle.com> <52FE7931.4020408@oracle.com> <53309F6A.1050002@oracle.com> <53315171.6090707@gmail.com> Message-ID: <53318512.9060602@oracle.com> On 25/03/2014 09:50, Peter Levart wrote: > : > > It would just require the API specification to strengthen it's > guarantees on some methods: for example destroyForcibly() would > guarantee forcible termination. It might require an additional method > like destroyNicely() or terminateNicely() which would guarantee a kind > of termination where victim process could clean-up. This is something that has been looked a few times. When we added destroyForcibly then we had to allow for the possibility that it might not be immediate so this is the reason for the current wording in the javadoc. It's not too bad when used with the timed waitFor. I had hoped we would also add a destroyGracefully but we didn't come up with a good solution on Windows at the time. > : > > The worst thing is to have an entirely separate API that does not > interoperate with old API. I think the old API is not so bad. It just > lacks some features and it's implementation could be revamped a bit. I agree but I know that Roger has been trying out a few API approaches with a view to coming up with a nice solution. -Alan. From staffan.larsen at oracle.com Tue Mar 25 13:37:55 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 25 Mar 2014 14:37:55 +0100 Subject: Experimental patches for unsafe cleanup Re: The s.m.Unsafe representation in hotspot and method registration In-Reply-To: References: <5689350D-66BA-474F-9FB7-E008823FE220@oracle.com> <313D6EFC-5DA4-48A6-8544-C34D52960072@oracle.com> <533075CE.40205@gmail.com> <60AA9737-22FB-4957-B3B8-EA4E3E6838AD@oracle.com> Message-ID: <20966E69-4795-406E-A120-7C751AB3A812@oracle.com> (Adding hotspot-runtime-dev since some changes are in hotspot code). On 25 mar 2014, at 14:20, Paul Sandoz wrote: > > On Mar 25, 2014, at 9:34 AM, Paul Sandoz wrote: > >> >> On Mar 24, 2014, at 7:49 PM, Staffan Larsen wrote: >> >>> We have abandoned the HSX model. From JDK 8 one version of Hotspot will be tied to one version of the JDK. This looks like old code that has not been cleaned up. >>> >> >> Thanks, yes, looks like we can clean this up and also remove the deprecated methods at the same time. >> > > Here are some preliminary webrevs to clean up unsafe and also remove all old, deprecated and monitor-related methods: > > http://cr.openjdk.java.net/~psandoz/jdk9/jdk-unsafe-cleanup/webrev/jdk.patch > > http://cr.openjdk.java.net/~psandoz/jdk9/hotspot-unsafe-cleanup/webrev/ > > Passes all tests i have thrown at it locally. > > There is some additional clean up that could be done to remove prefetch read/write intrinsics hooked up to older versions of Unsafe: > > do_intrinsic(_prefetchRead, sun_misc_Unsafe, prefetchRead_name, prefetch_signature, F_RN) \ > do_name( prefetchRead_name, "prefetchRead") \ > do_intrinsic(_prefetchWrite, sun_misc_Unsafe, prefetchWrite_name, prefetch_signature, F_RN) \ > do_name( prefetchWrite_name, "prefetchWrite") \ > do_intrinsic(_prefetchReadStatic, sun_misc_Unsafe, prefetchReadStatic_name, prefetch_signature, F_SN) \ > do_name( prefetchReadStatic_name, "prefetchReadStatic") \ > do_intrinsic(_prefetchWriteStatic, sun_misc_Unsafe, prefetchWriteStatic_name, prefetch_signature, F_SN) \ > do_name( prefetchWriteStatic_name, "prefetchWriteStatic") \ > > That will also require updates in various other files. I presume these prefetch methods are never used throughout the runtime? > > Paul. From Alan.Bateman at oracle.com Tue Mar 25 13:44:36 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 25 Mar 2014 13:44:36 +0000 Subject: Process API Updates (JEP 102) In-Reply-To: <533173C2.5080007@redhat.com> References: <52FD3897.7070903@oracle.com> <52FE7931.4020408@oracle.com> <53309F6A.1050002@oracle.com> <533173C2.5080007@redhat.com> Message-ID: <53318844.90801@oracle.com> On 25/03/2014 12:17, David M. Lloyd wrote: > > There are two features we would definitely like to see added: > > 1) NIO Channel interface for process streams > 2) The ability to pass additional channels to child processes > > #1 seems relatively straightforward, Assuming #1 means non-blocking and multiplexing then it has been looked into a few times. The main challenge is Windows where there are challenges multiplexing socket and handles to process streams at the same time. There have been a number of proposals and would need more investigating to come up with something that scales and is clean. -Alan From Alan.Bateman at oracle.com Tue Mar 25 13:53:35 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 25 Mar 2014 13:53:35 +0000 Subject: RFR(S): 8034960: Serviceability tests using @library failing with java.lang.NoClassDefFoundError In-Reply-To: <920D97EC-4782-46BC-BFE9-6B3800DB6C27@oracle.com> References: <5331718B.2020909@oracle.com> <920D97EC-4782-46BC-BFE9-6B3800DB6C27@oracle.com> Message-ID: <53318A5F.9030509@oracle.com> On 25/03/2014 12:14, Staffan Larsen wrote: > I?ve looked at a random sample of these changes and they look ok. > > Since some of the changes are in non-serviceability code I have also added core-libs to the review thread. > > I?m sure you know this, but for the record: please don?t push this until jtreg with the fix has been promoted. > > Thanks, > /Staffan Katja - the changes look okay but I wonder about tests that didn't previously have @build or @compile tags. Take TestJcmdDefaults as an example, it now has: @build jdk.testlibrary.* and I just wonder if it should be: @build TestJcmdDefaults jdk.testlibrary.* so that it compiles the test in addition to the test library. This could be a misunderstanding on my part of course, maybe the source file with @test is always compiled if it's a java test? -Alan From yekaterina.kantserova at oracle.com Tue Mar 25 14:00:18 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 25 Mar 2014 15:00:18 +0100 Subject: RFR(S): 8034960: Serviceability tests using @library failing with java.lang.NoClassDefFoundError In-Reply-To: <920D97EC-4782-46BC-BFE9-6B3800DB6C27@oracle.com> References: <5331718B.2020909@oracle.com> <920D97EC-4782-46BC-BFE9-6B3800DB6C27@oracle.com> Message-ID: <53318BF2.5040409@oracle.com> On 03/25/2014 01:14 PM, Staffan Larsen wrote: > I?ve looked at a random sample of these changes and they look ok. > > Since some of the changes are in non-serviceability code I have also added core-libs to the review thread. > > I?m sure you know this, but for the record: please don?t push this until jtreg with the fix has been promoted. I would not. My thought was to be done with review process and be ready to push when JTreg is promoted. Thank you for adding other groups! Katja > > Thanks, > /Staffan > > On 25 mar 2014, at 13:07, Yekaterina Kantserova wrote: > >> Hi, >> >> Could I please have a review of this fix. >> >> webrev: http://cr.openjdk.java.net/~ykantser/8034960/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8034960 >> >> When using @library in a JTreg test even @build need to be specify for all library files used by the test. If @build is not specified it can lead to intermittent failures when running tests concurrently, since javac implicit compilation and @library and -concurrency don't play well together. >> >> Verified locally since no JTreg with fix has been promoted yet. >> >> >> Thanks, >> Katja From peter.levart at gmail.com Tue Mar 25 14:05:16 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 25 Mar 2014 15:05:16 +0100 Subject: ProcessReaper: single thread reaper In-Reply-To: <53309E15.2060405@oracle.com> References: <532C7A30.6060904@oracle.com> <532CA33D.3030502@oracle.com> <532E2113.6040903@gmail.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> Message-ID: <53318D1C.3060104@gmail.com> On 03/24/2014 10:05 PM, roger riggs wrote: > Hi Rob, Martin, et.al. > > I've prototyped (for 9) a thread reaper[1] that uses a single thread > to wait for exiting > processes and calling back to the process with the exit status. > the interesting part is getting the exit status back to the Process > that needs it > It needs more testing and hardening. > > I had not considered using a signal handler for SIGCHLD but that's an > option, > though we need to be very careful about thread usage. > > Roger > > p.s. comments on the single thread reaper appreciated (in a new thread) > [1] http://cr.openjdk.java.net/~rriggs/webrev-waitpid/ > > Hi Roger, I think I found a little race. Suppose reaper task is still alive and that all consumers have been serviced (consumerCount is 0). The reaper task waits for 500 millis for next consumer to be registered, but times out. Before calling "reaperThread.release()", new consumer comes around and registers itself, also calling runReaper(), but since reaperThread.release() has not yet been called by old reaper task, new reaper task is not submitted to commonPool. The old reaper task finishes, leaving one consumer on the waitingList with no reaper task to service it. If no new consumers get registered, the waiting consumer will never be notified... The simplest solution for this race, I think, would be to have a dedicated long-running thread. It could be spawned lazily, but then it would never finish. Otherwise a nice solution with two lists (exitList/waitList) and avoidance of race with reversed orders between - consumer registration: register on waitList 1st then check exitList, and - exit event dispatch: register on exitList 1st then check waitList ...but the check you use with consumeCount local variable to detect processes spawned by other means (for purposes of logging only) has a race: thread1: Suppose a new consumer is being registered with onExitCall(...), is added on the waitList, but before checking exitList().size() and iterating the exitList, ... thread2: the reaper task detects that the very same process has finished (gets it's pid from waitpid) and adds it's pid to exitList. Then before iterating waitList, ... thread1: iterates the exitList, finds a match and consumes the pid, removing the matching entries from both exitList and waitList. Then ... thread2: the reaper task iterates waitList, doesn't find a matching entry for exitPid, doesn't increment consumeCount and voila: debug log("Unexpected process exit for pid:..."). That's enough races for today. Regards, Peter > > > On 3/24/2014 12:38 AM, Rob McKenna wrote: >> Hi folks, >> >> Roger Riggs (cc'd) may want to chip in here as he's looking at the >> reaper thread arrangement in 9 at the moment. >> >> On another note, I too support the merging of those files. I didn't >> think there was much appetite for it at the time so I must admit this >> fell down my todo list. Looking at this bug did remind me that its >> something worth trying though. As per Alan's mail, I'm going to >> tackle it separately if you folks don't mind. I'll have a look at >> Peter's changes (thanks Peter!) as soon as I can and see about >> getting them in. >> >> -Rob >> >> On 23/03/14 22:30, Martin Buchholz wrote: >>> >>> >>> >>> On Sun, Mar 23, 2014 at 2:34 AM, Martin Buchholz >>> > wrote: >>> >>> >>> We have also thought about whether having reaper threads is >>> necessary. The Unix rule is that child processes should be >>> waited for, and some thread needs to do that. There's no way to >>> wait for a set of child pids, or to specify a "completion >>> handler". Well, you might be able to get the newish waitid() to >>> do what you want, but it looks like it's not sufficient when >>> java is running inside a process that might do independent >>> subprocess creation outside of the JVM. >>> >>> >>> Actually, I take it back. With sufficient work, it looks like you >>> can get SIGCHLD to give you pid information in siginfo_t si_pid, and >>> that can be used to trigger the reaping. It looks like waitpid is >>> "async-signal-safe", so we can call it from our signal handler. >>> >>> While we're at it we can fix SIGCHLD handling to do signal chaining, >>> as with other signals. >> > From brian.burkhalter at oracle.com Tue Mar 25 14:19:15 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 25 Mar 2014 07:19:15 -0700 Subject: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <5315EDAA.5020801@gmail.com> <531EC3BD.9050605@oracle.com> <53201EA5.9090702@gmail.com> <53307892.4020805@gmail.com> Message-ID: On Mar 25, 2014, at 1:58 AM, Paul Sandoz wrote: > This is another example of a stable variable. > > I would like to re-iterate my scepticism that such changes are necessary in this case (i am not sure if it is possible to create a benchmark that could better exacerbate the concurrent overlap of calls to layoutChars). But, i do agree the discussion has been useful and interesting. I am happy either to leave the toString() code as it is or to change it to the variant with toStringSlow(). There is however other cleanup in the patch to consider. So it would be good to get consensus on the two points: 1) Change toString() to variant using toStringSlow() or leave it as-is. 2) Change non-toString() code as indicated in the patch or leave it as-is. If ?as-is? is the answer in both cases, then it?s simply a matter of resolving the enhancement as ?not an issue.? Thanks, Brian From peter.levart at gmail.com Tue Mar 25 14:21:38 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 25 Mar 2014 15:21:38 +0100 Subject: ProcessReaper: single thread reaper In-Reply-To: <53318D1C.3060104@gmail.com> References: <532C7A30.6060904@oracle.com> <532CA33D.3030502@oracle.com> <532E2113.6040903@gmail.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> Message-ID: <533190F2.3010708@gmail.com> On 03/25/2014 03:05 PM, Peter Levart wrote: > That's enough races for today. Or just one more... The debug log("Unexpected process exit for pid:...") could also be reached when new process is spawned by UNIXProcess constructor and before the constructor manages to register new consumer for it's pid, the child process finishes and gets processed by reaper task, which does not find a registration for the pid and reports unexpected process exit. But that's just logging. What's important is that when consumer finally manages to be registered, it will be called synchronously from the same thread that registers it (from UNIXProcess constructor)... Regards, Peter From yekaterina.kantserova at oracle.com Tue Mar 25 14:31:09 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 25 Mar 2014 15:31:09 +0100 Subject: RFR(S): 8034960: Serviceability tests using @library failing with java.lang.NoClassDefFoundError In-Reply-To: <53318A5F.9030509@oracle.com> References: <5331718B.2020909@oracle.com> <920D97EC-4782-46BC-BFE9-6B3800DB6C27@oracle.com> <53318A5F.9030509@oracle.com> Message-ID: <5331932D.8020806@oracle.com> On 03/25/2014 02:53 PM, Alan Bateman wrote: > On 25/03/2014 12:14, Staffan Larsen wrote: >> I?ve looked at a random sample of these changes and they look ok. >> >> Since some of the changes are in non-serviceability code I have also >> added core-libs to the review thread. >> >> I?m sure you know this, but for the record: please don?t push this >> until jtreg with the fix has been promoted. >> >> Thanks, >> /Staffan > Katja - the changes look okay but I wonder about tests that didn't > previously have @build or @compile tags. Take TestJcmdDefaults as an > example, it now has: > > @build jdk.testlibrary.* > > and I just wonder if it should be: > > @build TestJcmdDefaults jdk.testlibrary.* > > so that it compiles the test in addition to the test library. This > could be a misunderstanding on my part of course, maybe the source > file with @test is always compiled if it's a java test? My assumption is the test itself is always compiled. If it's false, I'm afraid we need to change a bunch of other tests. Jon, could you please explain? // Katja > > -Alan From Roger.Riggs at Oracle.com Tue Mar 25 16:25:12 2014 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 25 Mar 2014 09:25:12 -0700 Subject: ProcessReaper: single thread reaper In-Reply-To: <53318D1C.3060104@gmail.com> References: <532C7A30.6060904@oracle.com> <532CA33D.3030502@oracle.com> <532E2113.6040903@gmail.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> Message-ID: <5331ADE8.5000102@Oracle.com> Hi Peter, Thanks for the comments, I'll fix the races conditions, I intended to go back to the dedicated thread but wanted to check for scalability in the case of a large number of threads and non-trivial termination overheads where the streams had to be drained. Thanks, Roger On 3/25/14 7:05 AM, Peter Levart wrote: > On 03/24/2014 10:05 PM, roger riggs wrote: >> Hi Rob, Martin, et.al. >> >> I've prototyped (for 9) a thread reaper[1] that uses a single thread >> to wait for exiting >> processes and calling back to the process with the exit status. >> the interesting part is getting the exit status back to the Process >> that needs it >> It needs more testing and hardening. >> >> I had not considered using a signal handler for SIGCHLD but that's an >> option, >> though we need to be very careful about thread usage. >> >> Roger >> >> p.s. comments on the single thread reaper appreciated (in a new thread) >> [1] http://cr.openjdk.java.net/~rriggs/webrev-waitpid/ >> >> > Hi Roger, > > I think I found a little race. Suppose reaper task is still alive and > that all consumers have been serviced (consumerCount is 0). The reaper > task waits for 500 millis for next consumer to be registered, but > times out. Before calling "reaperThread.release()", new consumer comes > around and registers itself, also calling runReaper(), but since > reaperThread.release() has not yet been called by old reaper task, new > reaper task is not submitted to commonPool. The old reaper task > finishes, leaving one consumer on the waitingList with no reaper task > to service it. If no new consumers get registered, the waiting > consumer will never be notified... > > The simplest solution for this race, I think, would be to have a > dedicated long-running thread. It could be spawned lazily, but then it > would never finish. > > Otherwise a nice solution with two lists (exitList/waitList) and > avoidance of race with reversed orders between > - consumer registration: register on waitList 1st then check exitList, > and > - exit event dispatch: register on exitList 1st then check waitList > > ...but the check you use with consumeCount local variable to detect > processes spawned by other means (for purposes of logging only) has a > race: > > thread1: Suppose a new consumer is being registered with > onExitCall(...), is added on the waitList, but before checking > exitList().size() and iterating the exitList, ... > thread2: the reaper task detects that the very same process has > finished (gets it's pid from waitpid) and adds it's pid to exitList. > Then before iterating waitList, ... > thread1: iterates the exitList, finds a match and consumes the pid, > removing the matching entries from both exitList and waitList. Then ... > thread2: the reaper task iterates waitList, doesn't find a matching > entry for exitPid, doesn't increment consumeCount and voila: debug > log("Unexpected process exit for pid:..."). > > > That's enough races for today. > > Regards, Peter > >> >> >> On 3/24/2014 12:38 AM, Rob McKenna wrote: >>> Hi folks, >>> >>> Roger Riggs (cc'd) may want to chip in here as he's looking at the >>> reaper thread arrangement in 9 at the moment. >>> >>> On another note, I too support the merging of those files. I didn't >>> think there was much appetite for it at the time so I must admit >>> this fell down my todo list. Looking at this bug did remind me that >>> its something worth trying though. As per Alan's mail, I'm going to >>> tackle it separately if you folks don't mind. I'll have a look at >>> Peter's changes (thanks Peter!) as soon as I can and see about >>> getting them in. >>> >>> -Rob >>> >>> On 23/03/14 22:30, Martin Buchholz wrote: >>>> >>>> >>>> >>>> On Sun, Mar 23, 2014 at 2:34 AM, Martin Buchholz >>>> > wrote: >>>> >>>> >>>> We have also thought about whether having reaper threads is >>>> necessary. The Unix rule is that child processes should be >>>> waited for, and some thread needs to do that. There's no way >>>> to wait for a set of child pids, or to specify a "completion >>>> handler". Well, you might be able to get the newish waitid() >>>> to do what you want, but it looks like it's not sufficient when >>>> java is running inside a process that might do independent >>>> subprocess creation outside of the JVM. >>>> >>>> >>>> Actually, I take it back. With sufficient work, it looks like you >>>> can get SIGCHLD to give you pid information in siginfo_t si_pid, >>>> and that can be used to trigger the reaping. It looks like waitpid >>>> is "async-signal-safe", so we can call it from our signal handler. >>>> >>>> While we're at it we can fix SIGCHLD handling to do signal >>>> chaining, as with other signals. >>> >> > From peter.levart at gmail.com Tue Mar 25 16:50:57 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 25 Mar 2014 17:50:57 +0100 Subject: ProcessReaper: single thread reaper In-Reply-To: <5331ADE8.5000102@Oracle.com> References: <532C7A30.6060904@oracle.com> <532CA33D.3030502@oracle.com> <532E2113.6040903@gmail.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> <5331ADE8.5000102@Oracle.com> Message-ID: <5331B3F1.6010009@gmail.com> On 03/25/2014 05:25 PM, Roger Riggs wrote: > Hi Peter, > > Thanks for the comments, I'll fix the races conditions, I intended > to go back to the dedicated thread but wanted to check for scalability > in the case of a large number of threads and non-trivial termination > overheads > where the streams had to be drained. > Why does stream need to be drained right away (in reaper thread)? Isn't it enough for child pid to be waited upon and let the client of the stream pull from the stream until it reaches the EOF or not if it doesn't need the data... Is this just to be able to reclaim the file descriptor of the pipe right away? Wouldn't FileInputStream's close() method do the job (or finalize() if user forgets to call close())? There would be a native resource leakage if user forgets to call close() AND retains the reference to InputStream, but this is the same with all normal streams like FileInputStream... Regards, Peter > Thanks, Roger > > > > On 3/25/14 7:05 AM, Peter Levart wrote: >> On 03/24/2014 10:05 PM, roger riggs wrote: >>> Hi Rob, Martin, et.al. >>> >>> I've prototyped (for 9) a thread reaper[1] that uses a single thread >>> to wait for exiting >>> processes and calling back to the process with the exit status. >>> the interesting part is getting the exit status back to the Process >>> that needs it >>> It needs more testing and hardening. >>> >>> I had not considered using a signal handler for SIGCHLD but that's >>> an option, >>> though we need to be very careful about thread usage. >>> >>> Roger >>> >>> p.s. comments on the single thread reaper appreciated (in a new thread) >>> [1] http://cr.openjdk.java.net/~rriggs/webrev-waitpid/ >>> >>> >> Hi Roger, >> >> I think I found a little race. Suppose reaper task is still alive and >> that all consumers have been serviced (consumerCount is 0). The >> reaper task waits for 500 millis for next consumer to be registered, >> but times out. Before calling "reaperThread.release()", new consumer >> comes around and registers itself, also calling runReaper(), but >> since reaperThread.release() has not yet been called by old reaper >> task, new reaper task is not submitted to commonPool. The old reaper >> task finishes, leaving one consumer on the waitingList with no reaper >> task to service it. If no new consumers get registered, the waiting >> consumer will never be notified... >> >> The simplest solution for this race, I think, would be to have a >> dedicated long-running thread. It could be spawned lazily, but then >> it would never finish. >> >> Otherwise a nice solution with two lists (exitList/waitList) and >> avoidance of race with reversed orders between >> - consumer registration: register on waitList 1st then check >> exitList, and >> - exit event dispatch: register on exitList 1st then check waitList >> >> ...but the check you use with consumeCount local variable to detect >> processes spawned by other means (for purposes of logging only) has a >> race: >> >> thread1: Suppose a new consumer is being registered with >> onExitCall(...), is added on the waitList, but before checking >> exitList().size() and iterating the exitList, ... >> thread2: the reaper task detects that the very same process has >> finished (gets it's pid from waitpid) and adds it's pid to exitList. >> Then before iterating waitList, ... >> thread1: iterates the exitList, finds a match and consumes the pid, >> removing the matching entries from both exitList and waitList. Then ... >> thread2: the reaper task iterates waitList, doesn't find a matching >> entry for exitPid, doesn't increment consumeCount and voila: debug >> log("Unexpected process exit for pid:..."). >> >> >> That's enough races for today. >> >> Regards, Peter >> >>> >>> >>> On 3/24/2014 12:38 AM, Rob McKenna wrote: >>>> Hi folks, >>>> >>>> Roger Riggs (cc'd) may want to chip in here as he's looking at the >>>> reaper thread arrangement in 9 at the moment. >>>> >>>> On another note, I too support the merging of those files. I didn't >>>> think there was much appetite for it at the time so I must admit >>>> this fell down my todo list. Looking at this bug did remind me that >>>> its something worth trying though. As per Alan's mail, I'm going to >>>> tackle it separately if you folks don't mind. I'll have a look at >>>> Peter's changes (thanks Peter!) as soon as I can and see about >>>> getting them in. >>>> >>>> -Rob >>>> >>>> On 23/03/14 22:30, Martin Buchholz wrote: >>>>> >>>>> >>>>> >>>>> On Sun, Mar 23, 2014 at 2:34 AM, Martin Buchholz >>>>> > wrote: >>>>> >>>>> >>>>> We have also thought about whether having reaper threads is >>>>> necessary. The Unix rule is that child processes should be >>>>> waited for, and some thread needs to do that. There's no way >>>>> to wait for a set of child pids, or to specify a "completion >>>>> handler". Well, you might be able to get the newish waitid() >>>>> to do what you want, but it looks like it's not sufficient >>>>> when java is running inside a process that might do >>>>> independent subprocess creation outside of the JVM. >>>>> >>>>> >>>>> Actually, I take it back. With sufficient work, it looks like you >>>>> can get SIGCHLD to give you pid information in siginfo_t si_pid, >>>>> and that can be used to trigger the reaping. It looks like >>>>> waitpid is "async-signal-safe", so we can call it from our signal >>>>> handler. >>>>> >>>>> While we're at it we can fix SIGCHLD handling to do signal >>>>> chaining, as with other signals. >>>> >>> >> > From paul.sandoz at oracle.com Tue Mar 25 17:05:04 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 25 Mar 2014 18:05:04 +0100 Subject: Experimental patches for unsafe cleanup Re: The s.m.Unsafe representation in hotspot and method registration In-Reply-To: <20966E69-4795-406E-A120-7C751AB3A812@oracle.com> References: <5689350D-66BA-474F-9FB7-E008823FE220@oracle.com> <313D6EFC-5DA4-48A6-8544-C34D52960072@oracle.com> <533075CE.40205@gmail.com> <60AA9737-22FB-4957-B3B8-EA4E3E6838AD@oracle.com> <20966E69-4795-406E-A120-7C751AB3A812@oracle.com> Message-ID: <5DE5CF7A-5628-46E5-A44C-370076BEEF5C@oracle.com> On Mar 25, 2014, at 2:37 PM, Staffan Larsen wrote: > (Adding hotspot-runtime-dev since some changes are in hotspot code). > > > On 25 mar 2014, at 14:20, Paul Sandoz wrote: > >> >> On Mar 25, 2014, at 9:34 AM, Paul Sandoz wrote: >> >>> >>> On Mar 24, 2014, at 7:49 PM, Staffan Larsen wrote: >>> >>>> We have abandoned the HSX model. From JDK 8 one version of Hotspot will be tied to one version of the JDK. This looks like old code that has not been cleaned up. >>>> >>> >>> Thanks, yes, looks like we can clean this up and also remove the deprecated methods at the same time. >>> >> >> Here are some preliminary webrevs to clean up unsafe and also remove all old, deprecated and monitor-related methods: >> >> http://cr.openjdk.java.net/~psandoz/jdk9/jdk-unsafe-cleanup/webrev/jdk.patch >> >> http://cr.openjdk.java.net/~psandoz/jdk9/hotspot-unsafe-cleanup/webrev/ >> >> Passes all tests i have thrown at it locally. >> >> There is some additional clean up that could be done to remove prefetch read/write intrinsics hooked up to older versions of Unsafe: >> >> do_intrinsic(_prefetchRead, sun_misc_Unsafe, prefetchRead_name, prefetch_signature, F_RN) \ >> do_name( prefetchRead_name, "prefetchRead") \ >> do_intrinsic(_prefetchWrite, sun_misc_Unsafe, prefetchWrite_name, prefetch_signature, F_RN) \ >> do_name( prefetchWrite_name, "prefetchWrite") \ >> do_intrinsic(_prefetchReadStatic, sun_misc_Unsafe, prefetchReadStatic_name, prefetch_signature, F_SN) \ >> do_name( prefetchReadStatic_name, "prefetchReadStatic") \ >> do_intrinsic(_prefetchWriteStatic, sun_misc_Unsafe, prefetchWriteStatic_name, prefetch_signature, F_SN) \ >> do_name( prefetchWriteStatic_name, "prefetchWriteStatic") \ >> >> That will also require updates in various other files. I presume these prefetch methods are never used throughout the runtime? >> Here is that removal: http://cr.openjdk.java.net/~psandoz/jdk9/hotspot-unsafe-prefetch-cleanup/webrev/ Again all tests i threw at it passed. Paul. From mark.sheppard at oracle.com Tue Mar 25 17:20:34 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Tue, 25 Mar 2014 17:20:34 +0000 Subject: Process API Updates (JEP 102) In-Reply-To: <53309F6A.1050002@oracle.com> References: <52FD3897.7070903@oracle.com> <52FE7931.4020408@oracle.com> <53309F6A.1050002@oracle.com> Message-ID: <5331BAE2.6020906@oracle.com> Hi Roger, I have a few questions for your consideration, hopefully they make sense! Is this API to be available to the plug-in/applet? Even with appropriate permissions? What permissions are required to invoke operations on the API? Do you need to differentiate between "spawning" a Java process and a process that will execute a non Java executable? Is this part of the model? If a Java subprocess is created should it be "instrumented" with a remote control interface object to enable "fine grained" process control? Is the current Process abstraction to remain or be depecrated? If it remains why not extend its API rather introduce a second abtraction? Will the Runtime and ProcessBuilder be adapted to new ProcessHandle abstraction? i.e.they will return ProcessHandle? Why not refactor the Process abstraction to be a final class rather than an abstract class as part of this work? ProcessHandle.children() returns a Stream, why not return a Collection and the Stream can be obained from the Collection? What will the children method return when invoked on the ProcessHandle of a subprocess? the subprocesses may, in turn, have subprocesses but they will not be known within the context of the parent. What should be the security and permission model for invoking a destroy operation? What about encapsulating additional information in ProcessHandle, e.g. uid or owner, start time, process name, target executable If it is possible to invoke ProcessHandle somePidPh = ProcessHandle.get(somePid), where pid is an arbitrary value then what will happen if an attempt is made to subsequently invoke somePidPh.destroyForcibly(). somePidPh is not a sub-process of the invoker. should it just silently fail? Or to re-phrase, how will the OS level restrictions on killing a process be encapsulated in the ProcessHandle model? Are the ProcessHandles of all processes created within a single JVM available to all threads with that JVM, or is there to be any levels of isolation and visibility imposed within the calling JVM? WRT waitFor() method could take "callback argument" which is invoked when the sub-processed is finally reaped? regards Mark On 24/03/2014 21:11, roger riggs wrote: > Hi, > > I'm starting to work on JEP 102, Process API Updates for JDK 9. > The use cases identified include test execution and build systems such > as Jtreg and Hudson/Jenkins. And there is a use-case for using Java > to monitor the health of a more complex system where the processes > are not spawned by the same manager. > > The current API of Process itself is pretty complete with the addition > of a getPid > method to enable identification of subprocesses spawned by the > application > and allow external identification. It will not be possible to > intercept the input, > output and error streams of an arbitrary process. > > From the scope of the JEP, a fairly simple API seems sufficient. > - Enumerate the direct children > - The rest of the functions are similar to Process > - to terminate a process, forcibly and normally > - to destroy a process and all of its children recursively > - to check if one is alive > - to waitFor for termination and retrieve the exit status > > Are there use cases for which this is insufficient? Please comment. > > Thanks, Roger > From jonathan.gibbons at oracle.com Tue Mar 25 18:12:15 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 25 Mar 2014 11:12:15 -0700 Subject: RFR(S): 8034960: Serviceability tests using @library failing with java.lang.NoClassDefFoundError In-Reply-To: <5331932D.8020806@oracle.com> References: <5331718B.2020909@oracle.com> <920D97EC-4782-46BC-BFE9-6B3800DB6C27@oracle.com> <53318A5F.9030509@oracle.com> <5331932D.8020806@oracle.com> Message-ID: <5331C6FF.6090907@oracle.com> On 03/25/2014 07:31 AM, Yekaterina Kantserova wrote: > On 03/25/2014 02:53 PM, Alan Bateman wrote: >> On 25/03/2014 12:14, Staffan Larsen wrote: >>> I?ve looked at a random sample of these changes and they look ok. >>> >>> Since some of the changes are in non-serviceability code I have also >>> added core-libs to the review thread. >>> >>> I?m sure you know this, but for the record: please don?t push this >>> until jtreg with the fix has been promoted. >>> >>> Thanks, >>> /Staffan >> Katja - the changes look okay but I wonder about tests that didn't >> previously have @build or @compile tags. Take TestJcmdDefaults as an >> example, it now has: >> >> @build jdk.testlibrary.* >> >> and I just wonder if it should be: >> >> @build TestJcmdDefaults jdk.testlibrary.* >> >> so that it compiles the test in addition to the test library. This >> could be a misunderstanding on my part of course, maybe the source >> file with @test is always compiled if it's a java test? > > My assumption is the test itself is always compiled. If it's false, > I'm afraid we need to change a bunch of other tests. > > Jon, could you please explain? > > // Katja > > >> >> -Alan > There is no such thing as "the source file with @test". Those words don't make sense. The class specified in an "@run main" directive is subject to an implicit "@build" meaning that it will be compiled if needed. -- Jon From victor2 at ukr.net Tue Mar 25 20:19:56 2014 From: victor2 at ukr.net (Victor Polischuk) Date: Tue, 25 Mar 2014 22:19:56 +0200 Subject: Implicit 'this' return for void methods Message-ID: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> Good day, everyone, I have a question regarding a proposal I found some time ago: http://tech.puredanger.com/java7#chained. In a word, it is all about replacing 'void' behavior to always return 'this' and I think for static methods it would be nice to return Class instance. I have not found any mentions in JEPs and just wonder if the idea is rejected or still somewhere in pipeline for Java 1.x. (or perhaps it is just waiting to be filed by someone in brand new JEP). --- Regards, Victor Polischuk From christian.thalinger at oracle.com Tue Mar 25 20:24:58 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 25 Mar 2014 13:24:58 -0700 Subject: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types In-Reply-To: <53305D76.7080009@oracle.com> References: <5322E7C6.3050603@oracle.com> <659B1DAF-A57F-457F-9F68-8856795555BF@oracle.com> <532C5F6D.30500@oracle.com> <0C91BFD6-57CA-47B1-8DD3-88E0E4B9D252@oracle.com> <532CB847.3080809@oracle.com> <53305D76.7080009@oracle.com> Message-ID: + enum BasicType { + L_TYPE('L', Object.class, Wrapper.OBJECT), // all reference types + I_TYPE('I', int.class, Wrapper.INT), + J_TYPE('J', long.class, Wrapper.LONG), + F_TYPE('F', float.class, Wrapper.FLOAT), + D_TYPE('D', double.class, Wrapper.DOUBLE), // all primitive types + V_TYPE('V', void.class, Wrapper.VOID); // not valid in all contexts I would suggest to not name them X_TYPE but give them meaningful names like Int, Float, Void. The enum BasicType already infers that it?s a type. If you think it?s not clear that it?s a type just use BasicType.Double in that places. On Mar 24, 2014, at 9:29 AM, Vladimir Ivanov wrote: > Updated version: > http://cr.openjdk.java.net/~vlivanov/8037210/webrev.03/ > > - changed the way how arrays of types are created: > static final BasicType[] ALL_TYPES = BasicType.values(); > static final BasicType[] ARG_TYPES = Arrays.copyOf(ALL_TYPES, ALL_TYPES.length-1); > > - added a test for BasicType (LambdaFormTest.testBasicType). > > Best regards, > Vladimir Ivanov > > On 3/22/14 2:08 AM, Vladimir Ivanov wrote: >> John, thanks for the feedback. >> >> Updated webrev: >> http://cr.openjdk.java.net/~vlivanov/8037210/webrev.02 >> >> Also moved LambdaForm.testShortenSignature() into a stand-alone unit test. >> >> Best regards, >> Vladimir Ivanov >> >> On 3/21/14 10:54 PM, John Rose wrote: >>> On Mar 21, 2014, at 8:49 AM, Vladimir Ivanov >>> > >>> wrote: >>> >>>> Thanks for the feedback. >>>> >>>> What do you think about the following: >>>> http://cr.openjdk.java.net/~vlivanov/8037210/webrev.01/ >>> >>> That looks nice. Strong typing; who woulda' thunk it. :-) >>> >>> The uses of ".ordinal()" are the extra cost relative to using just small >>> integers. They seem totally reasonable in the code. >>> >>> I suggest either wrapping "ordinal" as something like "id" or else >>> changing temp names like "id" to "ord", to reinforce the use of a common >>> name. >>> >>> Don't make the enum class public. And especially don't make the mutable >>> arrays public: >>> >>> + public static final BasicType[] ALL_TYPES = { L_TYPE, I_TYPE, >>> J_TYPE, F_TYPE, D_TYPE, V_TYPE }; >>> + public static final BasicType[] ARG_TYPES = { L_TYPE, I_TYPE, >>> J_TYPE, F_TYPE, D_TYPE }; >>> >>> ? John >>> >>> P.S. That would only be safe if we had (what we don't yet) a notion of >>> frozen arrays like: >>> >>> + public static final BasicType final[] ALL_TYPES = { L_TYPE, >>> I_TYPE, J_TYPE, F_TYPE, D_TYPE, V_TYPE }; >>> + public static final BasicType final[] ARG_TYPES = { L_TYPE, >>> I_TYPE, J_TYPE, F_TYPE, D_TYPE }; >>> >>> >>> >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>> > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From mike.duigou at oracle.com Tue Mar 25 20:37:21 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 25 Mar 2014 13:37:21 -0700 Subject: 8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour Message-ID: Hello all; Recently HotSpot gained additional support for transactional memory, . This patch is a libraries followon to that change. RTM and other transactional memory implementations benefit from clustering writes towards the end of the transaction whenever possible. This change optimizes the behaviour of two collection classes, Hashtable and Vector by moving several field updates to cluster them together near the end of the transaction. Yes, we know, these are obsolete collections but these two classes were used as the basis for the original benchmarking and evaluation during the development of the transactional memory JVM features. Future changes providing similar optimizations to other collections will be pursued when it can be shown they offer value and don't add a cost to non TM performance (TM is not yet a mainstream feature). https://bugs.openjdk.java.net/browse/JDK-8020860 http://cr.openjdk.java.net/~mduigou/JDK-8020860/0/webrev/ It is not expected that this change will have any meaningful impact upon performance (either positive or negative) outside of TM-enabled configurations. The main change is to move existing field updates towards the end of the transaction and avoid conditionals between field updates. There is a slight behaviour change introduced in this changeset. Previously some methods updated the modcount unconditionally updated even when an ArrayIndexOutOfBoundsException was subsequently thrown for an invalid index and the Vector was not modified. With this change the modcount will only be updated if the Vector is actually changed. It is not expected that applications will have relied or should have relied on this behaviour. Mike From martinrb at google.com Tue Mar 25 20:41:51 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 25 Mar 2014 13:41:51 -0700 Subject: Process API Updates (JEP 102) In-Reply-To: <53309F6A.1050002@oracle.com> References: <52FD3897.7070903@oracle.com> <52FE7931.4020408@oracle.com> <53309F6A.1050002@oracle.com> Message-ID: We still have the conflict between providing portable pure Java programs and providing real access to the underlying OS (except for APIs like chdir that mutate global process state - too unsafe for Java). JDK seems to be more willing these days to create portable access to non-portable features (like symlinks). More pragmatism, less religion. I expected to find a getpid for java, but I don't see it there yet. There's a new trend to provide non-blocking (CompletableFuture-style) access to everything, but the OS may not be cooperative. Users want to send arbitrary Unix signals, e.g. be able to access all signals as a Map and send those signals to arbitrary other processes. Users want to access all attributes of all processes on the system. Thinking about features missing to implement a proper Emacs in java, top of the list is pty support, so one can implement interactive shells in Emacs buffers. I don't actually expect these to happen, and they're very hard to do, but will be happy if they do. On Mon, Mar 24, 2014 at 2:11 PM, roger riggs wrote: > Hi, > > I'm starting to work on JEP 102, Process API Updates for JDK 9. > The use cases identified include test execution and build systems such > as Jtreg and Hudson/Jenkins. And there is a use-case for using Java > to monitor the health of a more complex system where the processes > are not spawned by the same manager. > > The current API of Process itself is pretty complete with the addition of > a getPid > method to enable identification of subprocesses spawned by the application > and allow external identification. It will not be possible to intercept > the input, > output and error streams of an arbitrary process. > > From the scope of the JEP, a fairly simple API seems sufficient. > - Enumerate the direct children > - The rest of the functions are similar to Process > - to terminate a process, forcibly and normally > - to destroy a process and all of its children recursively > - to check if one is alive > - to waitFor for termination and retrieve the exit status > > Are there use cases for which this is insufficient? Please comment. > > Thanks, Roger > > From mandy.chung at oracle.com Tue Mar 25 20:41:40 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 25 Mar 2014 13:41:40 -0700 Subject: Review request for 8038177 Eliminate unnecessary dependency to sun.security.action In-Reply-To: <53304C2B.7030402@oracle.com> References: <532CAEF4.30407@oracle.com> <53304C2B.7030402@oracle.com> Message-ID: <5331EA04.4090808@oracle.com> On 3/24/2014 8:15 AM, Alan Bateman wrote: > On 21/03/2014 21:28, Mandy Chung wrote: >> This is the second patch to eliminate the dependencies to >> sun.security.action: >> https://bugs.openjdk.java.net/browse/JDK-8038177 >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8038177/webrev.00/ >> > It looks good to me too. The only one that I wonder about is > ExtendedCharsets and whether this might run early in the startup on > some locales. The ExtendedCharsets.init method has a check to ensure that the VM has been booted. Sherman can confirm that. 1170 protected void init() { 1171 if (initialized) 1172 return; 1173 if (!sun.misc.VM.isBooted()) 1174 return; Mandy From Alan.Bateman at oracle.com Tue Mar 25 20:50:10 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 25 Mar 2014 20:50:10 +0000 Subject: Review request for 8038177 Eliminate unnecessary dependency to sun.security.action In-Reply-To: <5331EA04.4090808@oracle.com> References: <532CAEF4.30407@oracle.com> <53304C2B.7030402@oracle.com> <5331EA04.4090808@oracle.com> Message-ID: <5331EC02.80901@oracle.com> On 25/03/2014 20:41, Mandy Chung wrote: > : > > The ExtendedCharsets.init method has a check to ensure that the VM has > been booted. Sherman can confirm that. > > 1170 protected void init() { > 1171 if (initialized) > 1172 return; > 1173 if (!sun.misc.VM.isBooted()) > 1174 return; Thanks, that covers my concern. -Alan. From martinrb at google.com Tue Mar 25 20:50:01 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 25 Mar 2014 13:50:01 -0700 Subject: Process API Updates (JEP 102) In-Reply-To: References: <52FD3897.7070903@oracle.com> <52FE7931.4020408@oracle.com> <53309F6A.1050002@oracle.com> Message-ID: People want a higher-level synchronous API that runs a command, captures the stderr, stdout and exit code, waits for the process to finish, and returns the result. Maybe even throws if exit code is non-zero or stderr is non-empty. Like the $(...) operator in bash, but more flexible... and not quite that convenient!. From martinrb at google.com Tue Mar 25 20:59:24 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 25 Mar 2014 13:59:24 -0700 Subject: 8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour In-Reply-To: References: Message-ID: On Tue, Mar 25, 2014 at 1:37 PM, Mike Duigou wrote: > > There is a slight behaviour change introduced in this changeset. > Previously some methods updated the modcount unconditionally updated even > when an ArrayIndexOutOfBoundsException was subsequently thrown for an > invalid index and the Vector was not modified. With this change the > modcount will only be updated if the Vector is actually changed. It is not > expected that applications will have relied or should have relied on this > behaviour. > > I don't think the modCount behavior should be changed. Although no one should be relying on the current behavior and few people are, any change in behavior needs a good reason, and I don't see a good enough one here - it's not clear which behavior is actually better. From jeremymanson at google.com Tue Mar 25 21:07:59 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 25 Mar 2014 14:07:59 -0700 Subject: StringBuilder version of java.util.regex.Matcher.append* In-Reply-To: <532CF69A.3060301@oracle.com> References: <532AA782.5030809@gmail.com> <532B246F.20302@oracle.com> <532CF69A.3060301@oracle.com> Message-ID: Okay. Thanks, Sherman. Here's an updated version. I've diverged a bit from Peter's version. In this version, appendExpandedReplacement takes a StringBuilder. The implications is that In the StringBuilder case, it saves creating a new StringBuilder object. In the StringBuffer case, it creates a new StringBuilder, but it doesn't have to acquire and release all of those locks. I also noticed a redundant cast to (int), which I removed. Jeremy On Fri, Mar 21, 2014 at 7:34 PM, Xueming Shen wrote: > let's add the StringBuilder method(s), if you can provide an updated > version, I can run the rest (since it's > to add new api, there is an internal CCC process need to go through). > > -Sherman > > > On 3/21/14 5:18 PM, Jeremy Manson wrote: > > So, this is all a little opaque to me. How do we make the go/no-go > decision on something like this? Everyone who has chimed in seems to think > it is a good idea. > > Jeremy > > > On Thu, Mar 20, 2014 at 10:38 AM, Jeremy Manson wrote: > >> Sherman, >> >> If you had released it then (which you wouldn't have been able to do, >> because you would have to wait another two years for Java 7), you would >> have found that it improved performance even with C2. It is only >> post-escape-analysis that the performance in C2 equalized. >> >> Anyway, I think adding the StringBuilder variant and deferring / >> dealing with the Appendable differently is the right approach, FWIW. >> >> Jeremy >> >> >> On Thu, Mar 20, 2014 at 10:25 AM, Xueming Shen wrote: >> >>> 2009? I do have something similar back to 2009 :-) >>> >>> http://cr.openjdk.java.net/~sherman/regex_replace/webrev/ >>> >>> Then the ball was dropped around the discussion of whether or not >>> the IOE should be thrown. >>> >>> But if we are going to/have to have explicit StringBuilder/Buffer pair >>> anyway, then we can keep the Appendable version as private for now >>> and deal with the StringBuilder and Appendable as two separate >>> issues. >>> >>> -Sherman >>> >>> >>> On 03/20/2014 09:52 AM, Jeremy Manson wrote: >>> >>>> That's definitely an improvement - I think that when I wrote this (circa >>>> 2009), I didn't think about Appendable. >>>> >>>> I take it my argument convinced someone? :) >>>> >>>> Jeremy >>>> >>>> >>>> On Thu, Mar 20, 2014 at 1:32 AM, Peter Levart>>> >wrote: >>>> >>>> On 03/19/2014 06:51 PM, Jeremy Manson wrote: >>>>> >>>>> I'm told that the diff didn't make it. I've put it in a Google drive >>>>>> folder... >>>>>> >>>>>> https://drive.google.com/file/d/0B_GaXa6O4K5LY3Y0aHpranM3aEU/ >>>>>> edit?usp=sharing >>>>>> >>>>>> Jeremy >>>>>> >>>>>> Hi Jeremy, >>>>> >>>>> Your factoring-out of expandReplacement() method exposed an >>>>> opportunity to >>>>> further optimize the code. Instead of creating intermediate >>>>> StringBuilder >>>>> instance for each expandReplacement() call, this method could append >>>>> directly to resulting StringBuffer/StringBuilder, like in the >>>>> following: >>>>> >>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/MatcherWithStringBuilder/ >>>>> webrev.01/ >>>>> >>>>> >>>>> Regards, Peter >>>>> >>>>> >>>>> >>>>> On Wed, Mar 19, 2014 at 10:41 AM, Jeremy Manson< >>>>>> jeremymanson at google.com> >>>>>> wrote: >>>>>> >>>>>> Hi folks, >>>>>> >>>>>>> We've had this internally for a while, and I keep meaning to bring >>>>>>> it up >>>>>>> here. The Matcher class has a few public methods that take >>>>>>> StringBuffers, >>>>>>> and we've found it useful to add similar versions that take >>>>>>> StringBuilders. >>>>>>> >>>>>>> It has two benefits: >>>>>>> >>>>>>> - Users don't have to convert from one to the other when they want >>>>>>> to use >>>>>>> the method in question. The symmetry is nice. >>>>>>> >>>>>>> - The StringBuilder variants are faster (if lock optimizations don't >>>>>>> kick >>>>>>> in, which happens in the interpreter and the client compiler). For >>>>>>> interpreted / client-compiled code, we saw something like a 25% >>>>>>> speedup >>>>>>> on >>>>>>> String.replaceAll(), which calls into this code. >>>>>>> >>>>>>> Any interest? Diff attached. >>>>>>> >>>>>>> Jeremy >>>>>>> >>>>>>> >>>>>>> >>> >> > > -------------- next part -------------- diff --git a/src/share/classes/java/util/regex/Matcher.java b/src/share/classes/java/util/regex/Matcher.java --- a/src/share/classes/java/util/regex/Matcher.java +++ b/src/share/classes/java/util/regex/Matcher.java @@ -65,7 +65,8 @@ * new strings whose contents can, if desired, be computed from the match * result. The {@link #appendReplacement appendReplacement} and {@link * #appendTail appendTail} methods can be used in tandem in order to collect - * the result into an existing string buffer, or the more convenient {@link + * the result into an existing string buffer or + * string builder. Alternatively, the more convenient {@link * #replaceAll replaceAll} method can be used to create a string in which every * matching subsequence in the input sequence is replaced. * @@ -792,14 +793,118 @@ * that does not exist in the pattern */ public Matcher appendReplacement(StringBuffer sb, String replacement) { - // If no match, return error if (first < 0) throw new IllegalStateException("No match available"); - // Process substitution string to replace group references with groups + StringBuilder result = new StringBuilder(); + appendExpandedReplacement(replacement, result); + + // Append the intervening text + sb.append(text, lastAppendPosition, first); + // Append the match substitution + sb.append(result); + + lastAppendPosition = last; + return this; + } + + /** + * Implements a non-terminal append-and-replace step. + * + *

This method performs the following actions:

+ * + *
    + * + *

  1. It reads characters from the input sequence, starting at the + * append position, and appends them to the given string builder. It + * stops after reading the last character preceding the previous match, + * that is, the character at index {@link + * #start()} - 1.

    2. + * + *

  2. It appends the given replacement string to the string builder. + *

    3. + * + *

  3. It sets the append position of this matcher to the index of + * the last character matched, plus one, that is, to {@link #end()}. + *

    4. + * + *
+ * + *

The replacement string may contain references to subsequences + * captured during the previous match: Each occurrence of + * $g will be replaced by the result of + * evaluating {@link #group(int) group}(g). + * The first number after the $ is always treated as part of + * the group reference. Subsequent numbers are incorporated into g if + * they would form a legal group reference. Only the numerals '0' + * through '9' are considered as potential components of the group + * reference. If the second group matched the string "foo", for + * example, then passing the replacement string "$2bar" would + * cause "foobar" to be appended to the string builder. A dollar + * sign ($) may be included as a literal in the replacement + * string by preceding it with a backslash (\$). + * + *

Note that backslashes (\) and dollar signs ($) in + * the replacement string may cause the results to be different than if it + * were being treated as a literal replacement string. Dollar signs may be + * treated as references to captured subsequences as described above, and + * backslashes are used to escape literal characters in the replacement + * string. + * + *

This method is intended to be used in a loop together with the + * {@link #appendTail appendTail} and {@link #find find} methods. The + * following code, for example, writes one dog two dogs in the + * yard to the standard-output stream:

+ * + * 
+     * Pattern p = Pattern.compile("cat");
+     * Matcher m = p.matcher("one cat two cats in the yard");
+     * StringBuilder sb = new StringBuilder();
+     * while (m.find()) {
+     *     m.appendReplacement(sb, "dog");
+     * }
+     * m.appendTail(sb);
+     * System.out.println(sb.toString());
+ * + * @param sb + * The target string builder + * + * @param replacement + * The replacement string + * + * @return This matcher + * + * @throws IllegalStateException + * If no match has yet been attempted, + * or if the previous match operation failed + * + * @throws IndexOutOfBoundsException + * If the replacement string refers to a capturing group + * that does not exist in the pattern + */ + public Matcher appendReplacement(StringBuilder sb, String replacement) { + // If no match, return error + if (first < 0) + throw new IllegalStateException("No match available"); + + // Append the intervening text + sb.append(text, lastAppendPosition, first); + + // Append the match substitution + appendExpandedReplacement(replacement, sb); + + lastAppendPosition = last; + return this; + } + + /** + * Processes replacement string to replace group references with + * groups. + */ + private StringBuilder appendExpandedReplacement( + String replacement, StringBuilder result) { int cursor = 0; - StringBuilder result = new StringBuilder(); while (cursor < replacement.length()) { char nextChar = replacement.charAt(cursor); @@ -852,8 +957,8 @@ cursor++; } else { // The first number is always a group - refNum = (int)nextChar - '0'; - if ((refNum < 0)||(refNum > 9)) + refNum = nextChar - '0'; + if ((refNum < 0) || (refNum > 9)) throw new IllegalArgumentException( "Illegal group reference"); cursor++; @@ -864,7 +969,7 @@ break; } int nextDigit = replacement.charAt(cursor) - '0'; - if ((nextDigit < 0)||(nextDigit > 9)) { // not a number + if ((nextDigit < 0) || (nextDigit > 9)) { // not a number break; } int newRefNum = (refNum * 10) + nextDigit; @@ -884,13 +989,7 @@ cursor++; } } - // Append the intervening text - sb.append(text, lastAppendPosition, first); - // Append the match substitution - sb.append(result); - - lastAppendPosition = last; - return this; + return result; } /** @@ -913,6 +1012,25 @@ } /** + * Implements a terminal append-and-replace step. + * + *

This method reads characters from the input sequence, starting at + * the append position, and appends them to the given string builder. It is + * intended to be invoked after one or more invocations of the {@link + * #appendReplacement appendReplacement} method in order to copy the + * remainder of the input sequence.

+ * + * @param sb + * The target string builder + * + * @return The target string builder + */ + public StringBuilder appendTail(StringBuilder sb) { + sb.append(text, lastAppendPosition, getTextLength()); + return sb; + } + + /** * Replaces every subsequence of the input sequence that matches the * pattern with the given replacement string. * @@ -950,7 +1068,7 @@ reset(); boolean result = find(); if (result) { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); do { appendReplacement(sb, replacement); result = find(); @@ -1000,7 +1118,7 @@ reset(); if (!find()) return text.toString(); - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); appendReplacement(sb, replacement); appendTail(sb); return sb.toString(); From martinrb at google.com Tue Mar 25 21:39:42 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 25 Mar 2014 14:39:42 -0700 Subject: ProcessReaper: single thread reaper In-Reply-To: <53318D1C.3060104@gmail.com> References: <532C7A30.6060904@oracle.com> <532CA33D.3030502@oracle.com> <532E2113.6040903@gmail.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> Message-ID: What happens if the pid you get back is a subprocess not created by ProcessBuilder? + pid = waitpid(-1, &exitValue, 0); --- What is the advantage of having a single thread? Are you just trying to save threads? The cost of the reaper threads is much lower than usual because of the small stack size. On Tue, Mar 25, 2014 at 7:05 AM, Peter Levart wrote: > On 03/24/2014 10:05 PM, roger riggs wrote: > > Hi Rob, Martin, et.al. > > I've prototyped (for 9) a thread reaper[1] that uses a single thread to > wait for exiting > processes and calling back to the process with the exit status. > the interesting part is getting the exit status back to the Process that > needs it > It needs more testing and hardening. > > I had not considered using a signal handler for SIGCHLD but that's an > option, > though we need to be very careful about thread usage. > > Roger > > p.s. comments on the single thread reaper appreciated (in a new thread) > [1] http://cr.openjdk.java.net/~rriggs/webrev-waitpid/ > > > Hi Roger, > > I think I found a little race. Suppose reaper task is still alive and that > all consumers have been serviced (consumerCount is 0). The reaper task > waits for 500 millis for next consumer to be registered, but times out. > Before calling "reaperThread.release()", new consumer comes around and > registers itself, also calling runReaper(), but since > reaperThread.release() has not yet been called by old reaper task, new > reaper task is not submitted to commonPool. The old reaper task finishes, > leaving one consumer on the waitingList with no reaper task to service it. > If no new consumers get registered, the waiting consumer will never be > notified... > > The simplest solution for this race, I think, would be to have a dedicated > long-running thread. It could be spawned lazily, but then it would never > finish. > > Otherwise a nice solution with two lists (exitList/waitList) and avoidance > of race with reversed orders between > - consumer registration: register on waitList 1st then check exitList, and > - exit event dispatch: register on exitList 1st then check waitList > > ...but the check you use with consumeCount local variable to detect > processes spawned by other means (for purposes of logging only) has a race: > > thread1: Suppose a new consumer is being registered with onExitCall(...), > is added on the waitList, but before checking exitList().size() and > iterating the exitList, ... > thread2: the reaper task detects that the very same process has finished > (gets it's pid from waitpid) and adds it's pid to exitList. Then before > iterating waitList, ... > thread1: iterates the exitList, finds a match and consumes the pid, > removing the matching entries from both exitList and waitList. Then ... > thread2: the reaper task iterates waitList, doesn't find a matching entry > for exitPid, doesn't increment consumeCount and voila: debug > log("Unexpected process exit for pid:..."). > > > That's enough races for today. > > Regards, Peter > > > > On 3/24/2014 12:38 AM, Rob McKenna wrote: > > Hi folks, > > Roger Riggs (cc'd) may want to chip in here as he's looking at the reaper > thread arrangement in 9 at the moment. > > On another note, I too support the merging of those files. I didn't think > there was much appetite for it at the time so I must admit this fell down > my todo list. Looking at this bug did remind me that its something worth > trying though. As per Alan's mail, I'm going to tackle it separately if you > folks don't mind. I'll have a look at Peter's changes (thanks Peter!) as > soon as I can and see about getting them in. > > -Rob > > On 23/03/14 22:30, Martin Buchholz wrote: > > > > > On Sun, Mar 23, 2014 at 2:34 AM, Martin Buchholz wrote: > >> >> We have also thought about whether having reaper threads is necessary. >> The Unix rule is that child processes should be waited for, and some >> thread needs to do that. There's no way to wait for a set of child pids, >> or to specify a "completion handler". Well, you might be able to get the >> newish waitid() to do what you want, but it looks like it's not sufficient >> when java is running inside a process that might do independent subprocess >> creation outside of the JVM. >> >> > Actually, I take it back. With sufficient work, it looks like you can > get SIGCHLD to give you pid information in siginfo_t si_pid, and that can > be used to trigger the reaping. It looks like waitpid is > "async-signal-safe", so we can call it from our signal handler. > > While we're at it we can fix SIGCHLD handling to do signal chaining, as > with other signals. > > > > > From Roger.Riggs at Oracle.com Tue Mar 25 21:47:37 2014 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 25 Mar 2014 14:47:37 -0700 Subject: ProcessReaper: single thread reaper In-Reply-To: References: <532C7A30.6060904@oracle.com> <532CA33D.3030502@oracle.com> <532E2113.6040903@gmail.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> Message-ID: <5331F979.4070308@Oracle.com> Hi Martin, Two cases, one current and one future. In the current case, Process can spawn a process and the process can exit before Process can register the callback to get the exitValue. Peter pointed out this race in his comments. The exitValue needs to be saved (for some time yet to be determined) to allow the Process to register and get its callback with the exitValue. The second case is future looking to the case where a child process not spawned by Process is exiting. It might be due to a child being inherited from a dieing child or due to some different subprocess launcher. When the JEP 102 process work happens, it should be possible to wait or get called back for those non-spawned processes. The single (smaller) number of threads has been requested to handle processes that control a large number of children. It could be from a thread pool, either dedicated or common. The common threadpool does not expect its tasks to hang for an indefinite period as might occur when waiting for along running process to exit. Thanks, Roger On 3/25/14 2:39 PM, Martin Buchholz wrote: > What happens if the pid you get back is a subprocess not created by ProcessBuilder? > + pid = waitpid(-1, &exitValue, 0); > --- > > What is the advantage of having a single thread? Are you just trying > to save threads? The cost of the reaper threads is much lower than > usual because of the small stack size. > > > > On Tue, Mar 25, 2014 at 7:05 AM, Peter Levart > wrote: > > On 03/24/2014 10:05 PM, roger riggs wrote: >> Hi Rob, Martin, et.al . >> >> I've prototyped (for 9) a thread reaper[1] that uses a single >> thread to wait for exiting >> processes and calling back to the process with the exit status. >> the interesting part is getting the exit status back to the >> Process that needs it >> It needs more testing and hardening. >> >> I had not considered using a signal handler for SIGCHLD but >> that's an option, >> though we need to be very careful about thread usage. >> >> Roger >> >> p.s. comments on the single thread reaper appreciated (in a new >> thread) >> [1] http://cr.openjdk.java.net/~rriggs/webrev-waitpid/ >> >> >> > Hi Roger, > > I think I found a little race. Suppose reaper task is still alive > and that all consumers have been serviced (consumerCount is 0). > The reaper task waits for 500 millis for next consumer to be > registered, but times out. Before calling > "reaperThread.release()", new consumer comes around and registers > itself, also calling runReaper(), but since reaperThread.release() > has not yet been called by old reaper task, new reaper task is not > submitted to commonPool. The old reaper task finishes, leaving one > consumer on the waitingList with no reaper task to service it. If > no new consumers get registered, the waiting consumer will never > be notified... > > The simplest solution for this race, I think, would be to have a > dedicated long-running thread. It could be spawned lazily, but > then it would never finish. > > Otherwise a nice solution with two lists (exitList/waitList) and > avoidance of race with reversed orders between > - consumer registration: register on waitList 1st then check > exitList, and > - exit event dispatch: register on exitList 1st then check waitList > > ...but the check you use with consumeCount local variable to > detect processes spawned by other means (for purposes of logging > only) has a race: > > thread1: Suppose a new consumer is being registered with > onExitCall(...), is added on the waitList, but before checking > exitList().size() and iterating the exitList, ... > thread2: the reaper task detects that the very same process has > finished (gets it's pid from waitpid) and adds it's pid to > exitList. Then before iterating waitList, ... > thread1: iterates the exitList, finds a match and consumes the > pid, removing the matching entries from both exitList and > waitList. Then ... > thread2: the reaper task iterates waitList, doesn't find a > matching entry for exitPid, doesn't increment consumeCount and > voila: debug log("Unexpected process exit for pid:..."). > > > That's enough races for today. > > Regards, Peter > >> >> >> On 3/24/2014 12:38 AM, Rob McKenna wrote: >>> Hi folks, >>> >>> Roger Riggs (cc'd) may want to chip in here as he's looking at >>> the reaper thread arrangement in 9 at the moment. >>> >>> On another note, I too support the merging of those files. I >>> didn't think there was much appetite for it at the time so I >>> must admit this fell down my todo list. Looking at this bug did >>> remind me that its something worth trying though. As per Alan's >>> mail, I'm going to tackle it separately if you folks don't mind. >>> I'll have a look at Peter's changes (thanks Peter!) as soon as I >>> can and see about getting them in. >>> >>> -Rob >>> >>> On 23/03/14 22:30, Martin Buchholz wrote: >>>> >>>> >>>> >>>> On Sun, Mar 23, 2014 at 2:34 AM, Martin Buchholz >>>> > wrote: >>>> >>>> >>>> We have also thought about whether having reaper threads is >>>> necessary. The Unix rule is that child processes should be >>>> waited for, and some thread needs to do that. There's no >>>> way to wait for a set of child pids, or to specify a >>>> "completion handler". Well, you might be able to get the >>>> newish waitid() to do what you want, but it looks like it's >>>> not sufficient when java is running inside a process that >>>> might do independent subprocess creation outside of the JVM. >>>> >>>> >>>> Actually, I take it back. With sufficient work, it looks like >>>> you can get SIGCHLD to give you pid information in siginfo_t >>>> si_pid, and that can be used to trigger the reaping. It looks >>>> like waitpid is "async-signal-safe", so we can call it from our >>>> signal handler. >>>> >>>> While we're at it we can fix SIGCHLD handling to do signal >>>> chaining, as with other signals. >>> >> > > From Roger.Riggs at Oracle.com Tue Mar 25 21:59:34 2014 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 25 Mar 2014 14:59:34 -0700 Subject: ProcessReaper: single thread reaper In-Reply-To: <5331B3F1.6010009@gmail.com> References: <532C7A30.6060904@oracle.com> <532CA33D.3030502@oracle.com> <532E2113.6040903@gmail.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> <5331ADE8.5000102@Oracle.com> <5331B3F1.6010009@gmail.com> Message-ID: <5331FC46.7000308@Oracle.com> Hi Peter, The stream draining code was added in 2011 to address resource exhaustion due to poor hygiene. * JDK-6944584 Improvements to subprocess handling on Unix Moves the resource 'leak' from the OS kernel/process space to the heap and allows the process to be cleaned up sooner. Roger On 3/25/14 9:50 AM, Peter Levart wrote: > On 03/25/2014 05:25 PM, Roger Riggs wrote: >> Hi Peter, >> >> Thanks for the comments, I'll fix the races conditions, I intended >> to go back to the dedicated thread but wanted to check for scalability >> in the case of a large number of threads and non-trivial termination >> overheads >> where the streams had to be drained. >> > > Why does stream need to be drained right away (in reaper thread)? > Isn't it enough for child pid to be waited upon and let the client of > the stream pull from the stream until it reaches the EOF or not if it > doesn't need the data... Is this just to be able to reclaim the file > descriptor of the pipe right away? Wouldn't FileInputStream's close() > method do the job (or finalize() if user forgets to call close())? > There would be a native resource leakage if user forgets to call > close() AND retains the reference to InputStream, but this is the same > with all normal streams like FileInputStream... > > Regards, Peter > >> Thanks, Roger >> >> >> >> On 3/25/14 7:05 AM, Peter Levart wrote: >>> On 03/24/2014 10:05 PM, roger riggs wrote: >>>> Hi Rob, Martin, et.al. >>>> >>>> I've prototyped (for 9) a thread reaper[1] that uses a single >>>> thread to wait for exiting >>>> processes and calling back to the process with the exit status. >>>> the interesting part is getting the exit status back to the Process >>>> that needs it >>>> It needs more testing and hardening. >>>> >>>> I had not considered using a signal handler for SIGCHLD but that's >>>> an option, >>>> though we need to be very careful about thread usage. >>>> >>>> Roger >>>> >>>> p.s. comments on the single thread reaper appreciated (in a new thread) >>>> [1] http://cr.openjdk.java.net/~rriggs/webrev-waitpid/ >>>> >>>> >>> Hi Roger, >>> >>> I think I found a little race. Suppose reaper task is still alive >>> and that all consumers have been serviced (consumerCount is 0). The >>> reaper task waits for 500 millis for next consumer to be registered, >>> but times out. Before calling "reaperThread.release()", new consumer >>> comes around and registers itself, also calling runReaper(), but >>> since reaperThread.release() has not yet been called by old reaper >>> task, new reaper task is not submitted to commonPool. The old reaper >>> task finishes, leaving one consumer on the waitingList with no >>> reaper task to service it. If no new consumers get registered, the >>> waiting consumer will never be notified... >>> >>> The simplest solution for this race, I think, would be to have a >>> dedicated long-running thread. It could be spawned lazily, but then >>> it would never finish. >>> >>> Otherwise a nice solution with two lists (exitList/waitList) and >>> avoidance of race with reversed orders between >>> - consumer registration: register on waitList 1st then check >>> exitList, and >>> - exit event dispatch: register on exitList 1st then check waitList >>> >>> ...but the check you use with consumeCount local variable to detect >>> processes spawned by other means (for purposes of logging only) has >>> a race: >>> >>> thread1: Suppose a new consumer is being registered with >>> onExitCall(...), is added on the waitList, but before checking >>> exitList().size() and iterating the exitList, ... >>> thread2: the reaper task detects that the very same process has >>> finished (gets it's pid from waitpid) and adds it's pid to exitList. >>> Then before iterating waitList, ... >>> thread1: iterates the exitList, finds a match and consumes the pid, >>> removing the matching entries from both exitList and waitList. Then ... >>> thread2: the reaper task iterates waitList, doesn't find a matching >>> entry for exitPid, doesn't increment consumeCount and voila: debug >>> log("Unexpected process exit for pid:..."). >>> >>> >>> That's enough races for today. >>> >>> Regards, Peter >>> >>>> >>>> >>>> On 3/24/2014 12:38 AM, Rob McKenna wrote: >>>>> Hi folks, >>>>> >>>>> Roger Riggs (cc'd) may want to chip in here as he's looking at the >>>>> reaper thread arrangement in 9 at the moment. >>>>> >>>>> On another note, I too support the merging of those files. I >>>>> didn't think there was much appetite for it at the time so I must >>>>> admit this fell down my todo list. Looking at this bug did remind >>>>> me that its something worth trying though. As per Alan's mail, I'm >>>>> going to tackle it separately if you folks don't mind. I'll have a >>>>> look at Peter's changes (thanks Peter!) as soon as I can and see >>>>> about getting them in. >>>>> >>>>> -Rob >>>>> >>>>> On 23/03/14 22:30, Martin Buchholz wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Sun, Mar 23, 2014 at 2:34 AM, Martin Buchholz >>>>>> > wrote: >>>>>> >>>>>> >>>>>> We have also thought about whether having reaper threads is >>>>>> necessary. The Unix rule is that child processes should be >>>>>> waited for, and some thread needs to do that. There's no way >>>>>> to wait for a set of child pids, or to specify a "completion >>>>>> handler". Well, you might be able to get the newish waitid() >>>>>> to do what you want, but it looks like it's not sufficient >>>>>> when java is running inside a process that might do >>>>>> independent subprocess creation outside of the JVM. >>>>>> >>>>>> >>>>>> Actually, I take it back. With sufficient work, it looks like >>>>>> you can get SIGCHLD to give you pid information in siginfo_t >>>>>> si_pid, and that can be used to trigger the reaping. It looks >>>>>> like waitpid is "async-signal-safe", so we can call it from our >>>>>> signal handler. >>>>>> >>>>>> While we're at it we can fix SIGCHLD handling to do signal >>>>>> chaining, as with other signals. >>>>> >>>> >>> >> > From forax at univ-mlv.fr Tue Mar 25 22:25:01 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 25 Mar 2014 23:25:01 +0100 Subject: 8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour In-Reply-To: References: Message-ID: <5332023D.2090508@univ-mlv.fr> On 03/25/2014 09:37 PM, Mike Duigou wrote: > Hello all; > > Recently HotSpot gained additional support for transactional memory, . This patch is a libraries followon to that change. RTM and other transactional memory implementations benefit from clustering writes towards the end of the transaction whenever possible. This change optimizes the behaviour of two collection classes, Hashtable and Vector by moving several field updates to cluster them together near the end of the transaction. Yes, we know, these are obsolete collections but these two classes were used as the basis for the original benchmarking and evaluation during the development of the transactional memory JVM features. Future changes providing similar optimizations to other collections will be pursued when it can be shown they offer value and don't add a cost to non TM performance (TM is not yet a mainstream feature). > > https://bugs.openjdk.java.net/browse/JDK-8020860 > http://cr.openjdk.java.net/~mduigou/JDK-8020860/0/webrev/ > > It is not expected that this change will have any meaningful impact upon performance (either positive or negative) outside of TM-enabled configurations. The main change is to move existing field updates towards the end of the transaction and avoid conditionals between field updates. > > There is a slight behaviour change introduced in this changeset. Previously some methods updated the modcount unconditionally updated even when an ArrayIndexOutOfBoundsException was subsequently thrown for an invalid index and the Vector was not modified. With this change the modcount will only be updated if the Vector is actually changed. It is not expected that applications will have relied or should have relied on this behaviour. > > Mike Hi Mike, I don't like the principle behind this patch. Your changing the behavior because it's better with the current state of the implementation of the RTM. First, as Martin said, you need a very good reason to do that and it's a kind of black magic change, when the RTM code will change you will have to update the JDK code too. It's better that the VM cluster the write itself by pushing the writes at the end of every code path if RTM is enabled (I don't say that this is easy to implement that but it will benefit to more code). regards, R?mi From martinrb at google.com Tue Mar 25 22:45:55 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 25 Mar 2014 15:45:55 -0700 Subject: ProcessReaper: single thread reaper In-Reply-To: References: <532C7A30.6060904@oracle.com> <532CA33D.3030502@oracle.com> <532E2113.6040903@gmail.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> Message-ID: On Tue, Mar 25, 2014 at 2:39 PM, Martin Buchholz wrote: > What happens if the pid you get back is a subprocess not created by ProcessBuilder? > > + pid = waitpid(-1, &exitValue, 0); > > Let me state this more strongly - when I thought about this problem years ago, this bug (not all subprocesses belong to ProcessBuilder) was a showstopper, that I didn't see any way to get around. From martinrb at google.com Tue Mar 25 22:50:49 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 25 Mar 2014 15:50:49 -0700 Subject: ProcessReaper: single thread reaper In-Reply-To: <5331F979.4070308@Oracle.com> References: <532C7A30.6060904@oracle.com> <532CA33D.3030502@oracle.com> <532E2113.6040903@gmail.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> Message-ID: Roger, are you saying there's a race in the currently shipping implementation? --- I believe It's possible to use ManagedBlocker to run tasks on FJ threads. But the current reaper thread pool is probably better because of the small stack sizes and there's no benefit running these reaper tasks that do nothing but wait on the common FJ pool. From Roger.Riggs at Oracle.com Tue Mar 25 23:11:43 2014 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 25 Mar 2014 16:11:43 -0700 Subject: ProcessReaper: single thread reaper In-Reply-To: References: <532C7A30.6060904@oracle.com> <532CA33D.3030502@oracle.com> <532E2113.6040903@gmail.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> Message-ID: <53320D2F.1030903@Oracle.com> No, in the prototype only. The current shipping implementation dedicates a thread to each Process and waits only for a specific pid to exit. Roger On 3/25/14 3:50 PM, Martin Buchholz wrote: > > Roger, are you saying there's a race in the currently shipping > implementation? > > --- > > I believe It's possible to use ManagedBlocker to run tasks on FJ threads. > > But the current reaper thread pool is probably better because of the > small stack sizes and there's no benefit running these reaper tasks > that do nothing but wait on the common FJ pool. ok, will look at that again. From Roger.Riggs at Oracle.com Wed Mar 26 00:21:51 2014 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 25 Mar 2014 17:21:51 -0700 Subject: Process API Updates (JEP 102) In-Reply-To: <53315171.6090707@gmail.com> References: <52FD3897.7070903@oracle.com> <52FE7931.4020408@oracle.com> <53309F6A.1050002@oracle.com> <53315171.6090707@gmail.com> Message-ID: <53321D9F.8000008@Oracle.com> Hi Peter, On 3/25/14 2:50 AM, Peter Levart wrote: > On 03/24/2014 10:11 PM, roger riggs wrote: >> Hi, >> >> I'm starting to work on JEP 102, Process API Updates for JDK 9. >> The use cases identified include test execution and build systems such >> as Jtreg and Hudson/Jenkins. And there is a use-case for using Java >> to monitor the health of a more complex system where the processes >> are not spawned by the same manager. >> >> The current API of Process itself is pretty complete with the >> addition of a getPid >> method to enable identification of subprocesses spawned by the >> application >> and allow external identification. It will not be possible to >> intercept the input, >> output and error streams of an arbitrary process. >> >> From the scope of the JEP, a fairly simple API seems sufficient. >> - Enumerate the direct children > > What about self? An application might want to communicate it's own PID > to some other process (write it into a file, for example). Other > Process API methods are not sensible for "self" process so this might > as well be just simple static getSelfPid() method. yes, I assume getPid() for the current process and Process.getPid(). > >> - The rest of the functions are similar to Process >> - to terminate a process, forcibly and normally >> - to destroy a process and all of its children recursively >> - to check if one is alive >> - to waitFor for termination and retrieve the exit status >> >> Are there use cases for which this is insufficient? Please comment. > > It would be nice if this new API interoperated with old Process API in > a way that using both interchangeably for the same child process would > be possible. For example: spawning a child with old Process API and > enumerating/waiting/checking it with new API in some thread while > waiting for termination using old API in another thread... Why make it more complex. What's the value? The current Process object is a capability, no one can control it unless they have the instance. Security is based on the permission to execute the binary. SM.checkExec(). Having an interface with the common function may be useful but the usefulness of the polymorphism needs to be validated. > I wonder if an approach to just add getPid() (and maybe some other > method) to old Process class together with some static methods to > enumerate child processes would be possible? That makes sense to extend the current API but is not sufficient for processes not spawned by Process. The enumeration of the children would not be Processes, a different type of process handle is needed. > > It would just require the API specification to strengthen it's > guarantees on some methods: for example destroyForcibly() would > guarantee forcible termination. It might require an additional method > like destroyNicely() or terminateNicely() which would guarantee a kind > of termination where victim process could clean-up. The specification > already allows getInputStream()/getOutputStream()/getErrorStream() to > return special "null streams" when spawned process IO is redirected > to/from file. The enumeration methods could simply return Process > object which would: > > - be same instances of Process objects created with ProcessBuilder API > for processes spawned by the Process API. This would require an > internal registry of live Process objects. We already have reaper > threads which could be used to clean-up this registry on process > termination. > - be new Process objects for child processes spawned in some other way > (or by children) and which would return special "null streams" from > their getInputStream()/getOutputStream()/getErrorStream() methods. > These Process objects could be instantiated lazily on first request > and then registered in the same internal registry. They might still > require reaper threads to enable waiting on them from multiple Java > threads and cleaning-up registry, but they could probably be created > lazily. > > The worst thing is to have an entirely separate API that does not > interoperate with old API. I think the old API is not so bad. It just > lacks some features and it's implementation could be revamped a bit. I'm quite leery of just glombing on new functions to Process especially those forcing the Process API semantics to be weakened and diluted; it is likely to make the implementation even more complex and hard to maintain. I think there are distinct functions for managing non-spawned processes. There are also security issues to consider, an application that might have permission to launch and control specific other programs should not be able (without other permissions) to control those processes children or other processes. Roger > > What do you think? > > Regards, Peter > >> >> Thanks, Roger >> > From Roger.Riggs at Oracle.com Wed Mar 26 00:27:01 2014 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 25 Mar 2014 17:27:01 -0700 Subject: Process API Updates (JEP 102) In-Reply-To: <53317402.9040007@redhat.com> References: <52FD3897.7070903@oracle.com> <52FE7931.4020408@oracle.com> <53309F6A.1050002@oracle.com> <53317402.9040007@redhat.com> Message-ID: <53321ED5.3010602@Oracle.com> Hi Florian, On 3/25/14 5:18 AM, Florian Weimer wrote: > On 03/24/2014 10:11 PM, roger riggs wrote: > >> From the scope of the JEP, a fairly simple API seems sufficient. >> - Enumerate the direct children >> - The rest of the functions are similar to Process >> - to terminate a process, forcibly and normally >> - to destroy a process and all of its children recursively >> - to check if one is alive >> - to waitFor for termination and retrieve the exit status > > On Linux, I think you need to use obscure mechanisms to make this > iteration reliable (cgroups perhaps). There is no openpid() or > similar mechanism that allows you to obtain a stable handle. Given that processes are asynchronous in creation and termination, I don't think 'reliable' listing is possible. In a pathological case, processes can be created as fast/faster than they can be terminated. > > Somewhat relatedly, it would make sense to make Process > auto-closeable, so that you can make sure that no non-Java resources > are retained. Right now, this seems to require calling > destroyForcibly().waitFor(). That's worth looking at a close() method could have that compound behavior. > > It would be nice if there was a way to directly pipe the output of one > process to the input of another process. I think that even with Java > 8, this still needs an explicit copy loop. That's similar to other requests to directly feed or consume from the subprocess from a file or pipe. Thanks, Roger From david.holmes at oracle.com Wed Mar 26 04:21:05 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Mar 2014 14:21:05 +1000 Subject: 8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour In-Reply-To: References: Message-ID: <533255B1.7020400@oracle.com> Mike, On 26/03/2014 6:37 AM, Mike Duigou wrote: > Hello all; > > Recently HotSpot gained additional support for transactional memory, . This patch is a libraries followon to that change. RTM and other transactional memory implementations benefit from clustering writes towards the end of the transaction whenever possible. This change optimizes the behaviour of two collection classes, Hashtable and Vector by moving several field updates to cluster them together near the end of the transaction. Yes, we know, these are obsolete collections but these two classes were used as the basis for the original benchmarking and evaluation during the development of the transactional memory JVM features. Future changes providing similar optimizations to other collections will be pursued when it can be shown they offer value and don't add a cost to non TM performance (TM is not yet a mainstream feature). > > https://bugs.openjdk.java.net/browse/JDK-8020860 > http://cr.openjdk.java.net/~mduigou/JDK-8020860/0/webrev/ > > It is not expected that this change will have any meaningful impact upon performance (either positive or negative) outside of TM-enabled configurations. The main change is to move existing field updates towards the end of the transaction and avoid conditionals between field updates. > > There is a slight behaviour change introduced in this changeset. Previously some methods updated the modcount unconditionally updated even when an ArrayIndexOutOfBoundsException was subsequently thrown for an invalid index and the Vector was not modified. With this change the modcount will only be updated if the Vector is actually changed. It is not expected that applications will have relied or should have relied on this behaviour. I could live with that change in behaviour, but this change completely breaks the fail-fast semantics of the iterators in some cases! If you don't update modCount until after the change is complete, the iterator may access the updated state and not throw CME!. I think this change is misguided. David ----- > Mike > From david.holmes at oracle.com Wed Mar 26 04:28:39 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Mar 2014 14:28:39 +1000 Subject: Implicit 'this' return for void methods In-Reply-To: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> Message-ID: <53325777.80204@oracle.com> On 26/03/2014 6:19 AM, Victor Polischuk wrote: > Good day, everyone, > > I have a question regarding a proposal I found some time ago: http://tech.puredanger.com/java7#chained. More direct original link: http://www.mernst.org/blog/rss.xml#AModestLanguageProposal > In a word, it is all about replacing 'void' behavior to always return 'this' and I think for static methods it would be nice to return Class instance. I have not found any mentions in JEPs and just wonder if the idea is rejected or still somewhere in pipeline for Java 1.x. (or perhaps it is just waiting to be filed by someone in brand new JEP). I don't think this has gone beyond a blog post from 2007. I don't recall any attempt at turning this into a JEP but perhaps it was discussed as part of Project Coin for Java 7? David > --- > Regards, > Victor Polischuk > From luchsh at linux.vnet.ibm.com Wed Mar 26 06:47:04 2014 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Wed, 26 Mar 2014 14:47:04 +0800 Subject: Improve timezone mapping for AIX platform Message-ID: Hi ppc-aix-port-dev, core-libs-dev, Here's a patch for JDK-8034220, http://cr.openjdk.java.net/~luchsh/JDK-8034220/ It is trying to add the a more complete timezone mapping mechanism for AIX platform. the changes are primarily based on IBM's commercial JDK code, which includes: - A new timezone mapping file added under directory jdk/src/aix/lib/ - Code to parse above config file, changed file is src/solaris/native/java/util/TimeZone_md.c - And also makefile change in make/CopyFiles.gmk to copy the config file Could you pls help to review and give comments ? Cheers - Jonathan From Alan.Bateman at oracle.com Wed Mar 26 07:26:51 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 26 Mar 2014 07:26:51 +0000 Subject: Improve timezone mapping for AIX platform In-Reply-To: References: Message-ID: <5332813B.8090501@oracle.com> Adding i18n-dev to the thread as i18n-dev is where the TZ code is maintained. On 26/03/2014 06:47, Jonathan Lu wrote: > Hi ppc-aix-port-dev, core-libs-dev, > > Here's a patch for JDK-8034220, > > http://cr.openjdk.java.net/~luchsh/JDK-8034220/ > > It is trying to add the a more complete timezone mapping mechanism for AIX > platform. > the changes are primarily based on IBM's commercial JDK code, which > includes: > > - A new timezone mapping file added under directory jdk/src/aix/lib/ > - Code to parse above config file, changed file is > src/solaris/native/java/util/TimeZone_md.c > - And also makefile change in make/CopyFiles.gmk to copy the config file > > Could you pls help to review and give comments ? > > Cheers > - Jonathan From Ulf.Zibis at CoSoCo.de Wed Mar 26 07:51:46 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Wed, 26 Mar 2014 08:51:46 +0100 Subject: Implicit 'this' return for void methods In-Reply-To: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> Message-ID: <53328712.8080405@CoSoCo.de> See: https://bugs.openjdk.java.net/browse/JDK-6472931 https://bugs.openjdk.java.net/browse/JDK-6373386 https://bugs.openjdk.java.net/browse/JDK-6479372 https://bugs.openjdk.java.net/browse/JDK-4774077 https://bugs.openjdk.java.net/browse/JDK-6451131 https://bugs.openjdk.java.net/browse/JDK-5082736 -Ulf Am 25.03.2014 21:19, schrieb Victor Polischuk: > Good day, everyone, > > I have a question regarding a proposal I found some time ago: http://tech.puredanger.com/java7#chained. > > In a word, it is all about replacing 'void' behavior to always return 'this' and I think for static methods it would be nice to return Class instance. I have not found any mentions in JEPs and just wonder if the idea is rejected or still somewhere in pipeline for Java 1.x. (or perhaps it is just waiting to be filed by someone in brand new JEP). > > --- > Regards, > Victor Polischuk > From Ulf.Zibis at CoSoCo.de Wed Mar 26 08:17:12 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Wed, 26 Mar 2014 09:17:12 +0100 Subject: Implicit 'this' return for void methods In-Reply-To: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> Message-ID: <53328D08.1000307@CoSoCo.de> See also: http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-April/001512.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-April/001365.html http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001180.html -Ulf Am 25.03.2014 21:19, schrieb Victor Polischuk: > Good day, everyone, > > I have a question regarding a proposal I found some time ago: http://tech.puredanger.com/java7#chained. > > In a word, it is all about replacing 'void' behavior to always return 'this' and I think for static methods it would be nice to return Class instance. I have not found any mentions in JEPs and just wonder if the idea is rejected or still somewhere in pipeline for Java 1.x. (or perhaps it is just waiting to be filed by someone in brand new JEP). > > --- > Regards, > Victor Polischuk > From paul.sandoz at oracle.com Wed Mar 26 09:02:26 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 26 Mar 2014 10:02:26 +0100 Subject: 8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour In-Reply-To: <533255B1.7020400@oracle.com> References: <533255B1.7020400@oracle.com> Message-ID: On Mar 26, 2014, at 5:21 AM, David Holmes wrote: > Mike, > > On 26/03/2014 6:37 AM, Mike Duigou wrote: >> Hello all; >> >> Recently HotSpot gained additional support for transactional memory, . This patch is a libraries followon to that change. RTM and other transactional memory implementations benefit from clustering writes towards the end of the transaction whenever possible. This change optimizes the behaviour of two collection classes, Hashtable and Vector by moving several field updates to cluster them together near the end of the transaction. Yes, we know, these are obsolete collections but these two classes were used as the basis for the original benchmarking and evaluation during the development of the transactional memory JVM features. Future changes providing similar optimizations to other collections will be pursued when it can be shown they offer value and don't add a cost to non TM performance (TM is not yet a mainstream feature). >> >> https://bugs.openjdk.java.net/browse/JDK-8020860 >> http://cr.openjdk.java.net/~mduigou/JDK-8020860/0/webrev/ >> >> It is not expected that this change will have any meaningful impact upon performance (either positive or negative) outside of TM-enabled configurations. The main change is to move existing field updates towards the end of the transaction and avoid conditionals between field updates. >> >> There is a slight behaviour change introduced in this changeset. Previously some methods updated the modcount unconditionally updated even when an ArrayIndexOutOfBoundsException was subsequently thrown for an invalid index and the Vector was not modified. With this change the modcount will only be updated if the Vector is actually changed. It is not expected that applications will have relied or should have relied on this behaviour. > > I could live with that change in behaviour, but this change completely breaks the fail-fast semantics of the iterators in some cases! If you don't update modCount until after the change is complete, the iterator may access the updated state and not throw CME!. > There is a possibility that a method could barf before the modCount is updated e.g. before the fix the modCount was aggressively updated, but now it is possible to say throw an exception and the modCount will not be updated (see addAll if the collection is null or the index is out of bounds). > I think this change is misguided. > I too share concerns about this. I would have hoped that the compiler (both javac and the runtime) might be able to automatically move code around to group writes. In the interim of getting such good compiler support i can understand the need for certain updates to improve performance. Do we have access to the perf results? Paul. From masayoshi.okutsu at oracle.com Wed Mar 26 09:27:52 2014 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Wed, 26 Mar 2014 18:27:52 +0900 Subject: Improve timezone mapping for AIX platform In-Reply-To: References: Message-ID: <53329D98.6040002@oracle.com> Hi Jonathan, The AIX specific code looks OK to me. But I'd suggest the code be moved to getPlatformTimeZoneID() for AIX, which just returns NULL currently. Also there's a function for producing a fallback ID in "GMT?hh:mm", getGMTOffsetID() which can be called in tzerr. Thanks, Masayoshi On 3/26/2014 3:47 PM, Jonathan Lu wrote: > Hi ppc-aix-port-dev, core-libs-dev, > > Here's a patch for JDK-8034220, > > http://cr.openjdk.java.net/~luchsh/JDK-8034220/ > > It is trying to add the a more complete timezone mapping mechanism for AIX > platform. > the changes are primarily based on IBM's commercial JDK code, which > includes: > > - A new timezone mapping file added under directory jdk/src/aix/lib/ > - Code to parse above config file, changed file is > src/solaris/native/java/util/TimeZone_md.c > - And also makefile change in make/CopyFiles.gmk to copy the config file > > Could you pls help to review and give comments ? > > Cheers > - Jonathan From ivan.gerasimov at oracle.com Wed Mar 26 13:15:09 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 26 Mar 2014 17:15:09 +0400 Subject: RFR [8038333] java/lang/ref/EarlyTimeout.java failed Message-ID: <5332D2DD.3080207@oracle.com> Hello! The test java/lang/ref/EarlyTimeout.java, which has been recently added to the repository with the fix for 6853696 has failed. The error message of the failure "more than one references were removed from queue" seems to be misguiding. I suspect that the real cause of the failure could have been that both child thread failed to get the reference during the specified timeout. Thus, nonNullRefCount may have been zero and not some value > 1. Here's the trivial fix: http://cr.openjdk.java.net/~igerasim/8038333/0/webrev/ Sincerely yours, Ivan Gerasimov From vladimir.x.ivanov at oracle.com Wed Mar 26 15:01:41 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 26 Mar 2014 19:01:41 +0400 Subject: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types In-Reply-To: References: <5322E7C6.3050603@oracle.com> <659B1DAF-A57F-457F-9F68-8856795555BF@oracle.com> <532C5F6D.30500@oracle.com> <0C91BFD6-57CA-47B1-8DD3-88E0E4B9D252@oracle.com> <532CB847.3080809@oracle.com> <53305D76.7080009@oracle.com> Message-ID: <5332EBD5.8090100@oracle.com> Here's a version with the new naming scheme: http://cr.openjdk.java.net/~vlivanov/8037210/webrev.03.naming I like existing naming scheme and OBJECT/VOID/LONG/etc names are quite popular(e.g. Wrapper & ASM (Opcodes) use them). So, I'm in favor of leaving it as is. Best regards, Vladimir Ivanov On 3/26/14 12:24 AM, Christian Thalinger wrote: > + enum BasicType { > + L_TYPE('L', Object.class, Wrapper.OBJECT), // all reference types > + I_TYPE('I', int.class, Wrapper.INT), > + J_TYPE('J', long.class, Wrapper.LONG), > + F_TYPE('F', float.class, Wrapper.FLOAT), > + D_TYPE('D', double.class, Wrapper.DOUBLE), // all primitive types > + V_TYPE('V', void.class, Wrapper.VOID); // not valid in all contexts > > I would suggest to not name them X_TYPE but give them meaningful names like Int, Float, Void. The enum BasicType already infers that it?s a type. If you think it?s not clear that it?s a type just use BasicType.Double in that places. > > On Mar 24, 2014, at 9:29 AM, Vladimir Ivanov wrote: > >> Updated version: >> http://cr.openjdk.java.net/~vlivanov/8037210/webrev.03/ >> >> - changed the way how arrays of types are created: >> static final BasicType[] ALL_TYPES = BasicType.values(); >> static final BasicType[] ARG_TYPES = Arrays.copyOf(ALL_TYPES, ALL_TYPES.length-1); >> >> - added a test for BasicType (LambdaFormTest.testBasicType). >> >> Best regards, >> Vladimir Ivanov >> >> On 3/22/14 2:08 AM, Vladimir Ivanov wrote: >>> John, thanks for the feedback. >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~vlivanov/8037210/webrev.02 >>> >>> Also moved LambdaForm.testShortenSignature() into a stand-alone unit test. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 3/21/14 10:54 PM, John Rose wrote: >>>> On Mar 21, 2014, at 8:49 AM, Vladimir Ivanov >>>> > >>>> wrote: >>>> >>>>> Thanks for the feedback. >>>>> >>>>> What do you think about the following: >>>>> http://cr.openjdk.java.net/~vlivanov/8037210/webrev.01/ >>>> >>>> That looks nice. Strong typing; who woulda' thunk it. :-) >>>> >>>> The uses of ".ordinal()" are the extra cost relative to using just small >>>> integers. They seem totally reasonable in the code. >>>> >>>> I suggest either wrapping "ordinal" as something like "id" or else >>>> changing temp names like "id" to "ord", to reinforce the use of a common >>>> name. >>>> >>>> Don't make the enum class public. And especially don't make the mutable >>>> arrays public: >>>> >>>> + public static final BasicType[] ALL_TYPES = { L_TYPE, I_TYPE, >>>> J_TYPE, F_TYPE, D_TYPE, V_TYPE }; >>>> + public static final BasicType[] ARG_TYPES = { L_TYPE, I_TYPE, >>>> J_TYPE, F_TYPE, D_TYPE }; >>>> >>>> ? John >>>> >>>> P.S. That would only be safe if we had (what we don't yet) a notion of >>>> frozen arrays like: >>>> >>>> + public static final BasicType final[] ALL_TYPES = { L_TYPE, >>>> I_TYPE, J_TYPE, F_TYPE, D_TYPE, V_TYPE }; >>>> + public static final BasicType final[] ARG_TYPES = { L_TYPE, >>>> I_TYPE, J_TYPE, F_TYPE, D_TYPE }; >>>> >>>> >>>> >>>> _______________________________________________ >>>> mlvm-dev mailing list >>>> mlvm-dev at openjdk.java.net >>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > _______________________________________________ > 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 Wed Mar 26 15:19:41 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 26 Mar 2014 16:19:41 +0100 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) Message-ID: <5332F00D.1020806@gmail.com> Hi, This is a preview of the effort to merge all 4 variants of UNIXProcess class into one source. Here's the bug: https://bugs.openjdk.java.net/browse/JDK-8000975 And here's the webrev: http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.02/ Per Alan's suggestion I have made the merged source (UNIXProcess.java) be a descendant of UNIXProcess.java.linux in mercurial history. This webrev also incorporates reaper thread pool changes for Solaris variant (this was the only variant not yet using thread pool) so that the changes are even simpler. Still missing is UNIX OS resolving based on os.name system property (Os.get() method). I couldn't find any official document about possible os.name values for different supported OSes. Does anyone have a pointer? Regards, Peter From guy.steele at oracle.com Wed Mar 26 15:51:49 2014 From: guy.steele at oracle.com (Guy Steele) Date: Wed, 26 Mar 2014 11:51:49 -0400 Subject: Implicit 'this' return for void methods In-Reply-To: <53328D08.1000307@CoSoCo.de> References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> <53328D08.1000307@CoSoCo.de> Message-ID: On Mar 26, 2014, at 4:17 AM, Ulf Zibis wrote: > See also: > . . . > http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001180.html This last one has a specific proposal, which is simple and quite nice. The important idea is that we don?t actually make any change to the code of void methods or make them actually return anything; instead, the caller takes notice of situations where an invocation of a void method is used as a subexpression whose value is required (heretofore forbidden by the language) and gives it a special interpretation. I note that Ulf?s proposal applies only to method invocations, but I note that the same technique could be used to include field references if desired. I am wholeheartedly in favor of allowing ?chaining? of dotted expressions such as CharBuffer.allocate(26).position(2).put("C").position(25).put("Z?) I am a bit more skeptical about expressions that begin with a dot because of potential confusion about which expression is referred to: myVeryLongNamedString.subString(.indexOf("C?), .indexOf("Q?)) seems clear enough, but what about: myVeryLongNamedString.subString(.indexOf("C?) + otherString.length(), .indexOf("Q?)) Does the second occurrence of .indexOf use myVeryLongNamedString or otherString? A compromise would be to allow leading-dot expressions to occur only within the arguments of the method call whose target is the object which the leading-dot expressions are expected to use as their target, and if there are such leading-dot expressions within the arguments then the arguments must not contain any non-leading-dot field references or method calls. Just a thought for discussion. This would be considered a separate mechanism from the chaining-of-void-methods mechanism (it was a very clever idea to try to unify them in Ulf's original proposal, though). ?Guy From Alan.Bateman at oracle.com Wed Mar 26 16:18:29 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 26 Mar 2014 16:18:29 +0000 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <5332F00D.1020806@gmail.com> References: <5332F00D.1020806@gmail.com> Message-ID: <5332FDD5.8030801@oracle.com> On 26/03/2014 15:19, Peter Levart wrote: > I couldn't find any official document about possible os.name values > for different supported OSes. Does anyone have a pointer? I don't know if there is a definite list but I assume we don't need to be concerned with anything beyond the 4 that we have in OpenJDK, which is "Linux", "SunOS", "AIX" and contains("OS X"). If we get to the point in JDK 9 where src/solaris is renamed to src/unix (or something equivalent) then it could mean that the Os enum can be replaced with an OS specific class in src/linux, src/solaris, ... and this would avoid the need for an os.name check at runtime. -Alan. From pbenedict at apache.org Wed Mar 26 16:20:47 2014 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 26 Mar 2014 11:20:47 -0500 Subject: Implicit 'this' return for void methods In-Reply-To: References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> <53328D08.1000307@CoSoCo.de> Message-ID: It would be nice to make this language change. In the past years, it's pretty clear many JSR EE spec leads have gone on to make their APIs return the same object because they strongly prefer to see object chaining in code. I sympathize with those designers, but I don't agree; I wouldn't affect my API just for the sake of chaining. For the sake of clarity, I prefer functions that don't compute anything to return void. So +1 for the language to figure this out. On Wed, Mar 26, 2014 at 10:51 AM, Guy Steele wrote: > > On Mar 26, 2014, at 4:17 AM, Ulf Zibis wrote: > > > See also: > > . . . > > http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001180.html > > This last one has a specific proposal, which is simple and quite nice. > The important idea is > that we don't actually make any change to the code of void methods or make > them actually > return anything; instead, the caller takes notice of situations where an > invocation of > a void method is used as a subexpression whose value is required > (heretofore forbidden > by the language) and gives it a special interpretation. > > I note that Ulf's proposal applies only to method invocations, but I note > that the same > technique could be used to include field references if desired. > > I am wholeheartedly in favor of allowing "chaining" of dotted expressions > such as > > CharBuffer.allocate(26).position(2).put("C").position(25).put("Z") > > I am a bit more skeptical about expressions that begin with a dot because > of potential > confusion about which expression is referred to: > > myVeryLongNamedString.subString(.indexOf("C"), .indexOf("Q")) > > seems clear enough, but what about: > > myVeryLongNamedString.subString(.indexOf("C") + otherString.length(), > .indexOf("Q")) > > Does the second occurrence of .indexOf use myVeryLongNamedString or > otherString? > > A compromise would be to allow leading-dot expressions to occur only > within the arguments > of the method call whose target is the object which the leading-dot > expressions are expected > to use as their target, and if there are such leading-dot expressions > within the arguments > then the arguments must not contain any non-leading-dot field references > or method calls. > Just a thought for discussion. This would be considered a separate > mechanism from the > chaining-of-void-methods mechanism (it was a very clever idea to try to > unify them in Ulf's > original proposal, though). > > --Guy > > -- Cheers, Paul From aleksej.efimov at oracle.com Wed Mar 26 16:39:57 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Wed, 26 Mar 2014 20:39:57 +0400 Subject: RFR (JAXP): 8035437: Xerces Update: xml/serialize/DOMSerializerImpl Message-ID: <533302DD.2090005@oracle.com> Hello, Can I ask for a review for the update of DOMSerializerImpl class [1] to the latest Apache Xerces implementation. The following changes were made: 1. The DOMSerializerImpl update: The Xerces class was used as a base [2]; the 476047 and 473125 revisions from Xerces was excluded (they will be resolved as a part of JDK-8035467 - move to Xalan serializer bug); the jaxp 632 revision was applied to new version of this class. 2. The DOMSerializerImpl.java file was reformated, because of not-good formatting in original file from Apache repo [2]. 3. Other changes related to the DOMSerializerImpl update were applied from Xerces repo to JDK(the full revisions list can be found in the JBS [1]). 4. All license headers were updated to the latest version of Apache header in modified files. 5. New regression test was added to reproduce a problem described in Apache bug XERCESJ-1007 [3]. Webrevs for these changes: http://cr.openjdk.java.net/~aefimov/8035437/webrev.00/jaxp http://cr.openjdk.java.net/~aefimov/8035437/webrev.00/jdk Testing: JCK tests (api/xsl api/xinclude api/javax_xml api/org_xml xml_schema): pass JTREG tests (javax/xml, jdk_other): pass Thank you, Aleksej [1] https://bugs.openjdk.java.net/browse/JDK-6339023 [2] http://svn.apache.org/viewvc/xerces/java/trunk/src/org/apache/xml/serialize/DOMSerializerImpl.java?revision=944789&view=markup [3] https://issues.apache.org/jira/browse/XERCESJ-1007 From lance.andersen at oracle.com Wed Mar 26 16:54:00 2014 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 26 Mar 2014 12:54:00 -0400 Subject: RFR (JAXP): 8035437: Xerces Update: xml/serialize/DOMSerializerImpl In-Reply-To: <533302DD.2090005@oracle.com> References: <533302DD.2090005@oracle.com> Message-ID: <155CED84-F9D2-4EF8-9AC2-18A7AA7C0E68@oracle.com> Hi Aleksej, Do you really need to use run.sh? If possible it would be better to try and avoid providing a script and use the jtreg keywords. Best Lance On Mar 26, 2014, at 12:39 PM, Aleksej Efimov wrote: > Hello, > > Can I ask for a review for the update of DOMSerializerImpl class [1] to the latest Apache Xerces implementation. > The following changes were made: > 1. The DOMSerializerImpl update: The Xerces class was used as a base [2]; the 476047 and 473125 revisions from Xerces was excluded (they will be resolved as a part of JDK-8035467 - move to Xalan serializer bug); the jaxp 632 revision was applied to new version of this class. > 2. The DOMSerializerImpl.java file was reformated, because of not-good formatting in original file from Apache repo [2]. > 3. Other changes related to the DOMSerializerImpl update were applied from Xerces repo to JDK(the full revisions list can be found in the JBS [1]). > 4. All license headers were updated to the latest version of Apache header in modified files. > 5. New regression test was added to reproduce a problem described in Apache bug XERCESJ-1007 [3]. > > Webrevs for these changes: > http://cr.openjdk.java.net/~aefimov/8035437/webrev.00/jaxp > http://cr.openjdk.java.net/~aefimov/8035437/webrev.00/jdk > > Testing: > JCK tests (api/xsl api/xinclude api/javax_xml api/org_xml xml_schema): pass > JTREG tests (javax/xml, jdk_other): pass > > Thank you, > Aleksej > > [1] https://bugs.openjdk.java.net/browse/JDK-6339023 > [2] http://svn.apache.org/viewvc/xerces/java/trunk/src/org/apache/xml/serialize/DOMSerializerImpl.java?revision=944789&view=markup > [3] https://issues.apache.org/jira/browse/XERCESJ-1007 > 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 Mar 26 17:04:20 2014 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 26 Mar 2014 13:04:20 -0400 Subject: RFR (JAXP): 8035437: Xerces Update: xml/serialize/DOMSerializerImpl In-Reply-To: <155CED84-F9D2-4EF8-9AC2-18A7AA7C0E68@oracle.com> References: <533302DD.2090005@oracle.com> <155CED84-F9D2-4EF8-9AC2-18A7AA7C0E68@oracle.com> Message-ID: <95ECB6AF-B918-4812-92C8-6915A3EDE98D@oracle.com> Any reason not to use StringBuilder in place of StringBuffer in XMLEntityManager.java other than the above and my question on the need of using run.sh, it is OK On Mar 26, 2014, at 12:54 PM, Lance Andersen wrote: > Hi Aleksej, > > Do you really need to use run.sh? If possible it would be better to try and avoid providing a script and use the jtreg keywords. > > Best > Lance > On Mar 26, 2014, at 12:39 PM, Aleksej Efimov wrote: > >> Hello, >> >> Can I ask for a review for the update of DOMSerializerImpl class [1] to the latest Apache Xerces implementation. >> The following changes were made: >> 1. The DOMSerializerImpl update: The Xerces class was used as a base [2]; the 476047 and 473125 revisions from Xerces was excluded (they will be resolved as a part of JDK-8035467 - move to Xalan serializer bug); the jaxp 632 revision was applied to new version of this class. >> 2. The DOMSerializerImpl.java file was reformated, because of not-good formatting in original file from Apache repo [2]. >> 3. Other changes related to the DOMSerializerImpl update were applied from Xerces repo to JDK(the full revisions list can be found in the JBS [1]). >> 4. All license headers were updated to the latest version of Apache header in modified files. >> 5. New regression test was added to reproduce a problem described in Apache bug XERCESJ-1007 [3]. >> >> Webrevs for these changes: >> http://cr.openjdk.java.net/~aefimov/8035437/webrev.00/jaxp >> http://cr.openjdk.java.net/~aefimov/8035437/webrev.00/jdk >> >> Testing: >> JCK tests (api/xsl api/xinclude api/javax_xml api/org_xml xml_schema): pass >> JTREG tests (javax/xml, jdk_other): pass >> >> Thank you, >> Aleksej >> >> [1] https://bugs.openjdk.java.net/browse/JDK-6339023 >> [2] http://svn.apache.org/viewvc/xerces/java/trunk/src/org/apache/xml/serialize/DOMSerializerImpl.java?revision=944789&view=markup >> [3] https://issues.apache.org/jira/browse/XERCESJ-1007 >> > > > > 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 > > > 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 Wed Mar 26 17:04:51 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 26 Mar 2014 10:04:51 -0700 Subject: RFR [8038333] java/lang/ref/EarlyTimeout.java failed In-Reply-To: <5332D2DD.3080207@oracle.com> References: <5332D2DD.3080207@oracle.com> Message-ID: <533308B3.2030605@oracle.com> Hi Ivan, On 3/26/2014 6:15 AM, Ivan Gerasimov wrote: > Hello! > > The test java/lang/ref/EarlyTimeout.java, which has been recently > added to the repository with the fix for 6853696 has failed. > The error message of the failure "more than one references were > removed from queue" seems to be misguiding. > > I suspect that the real cause of the failure could have been that both > child thread failed to get the reference during the specified timeout. > Thus, nonNullRefCount may have been zero and not some value > 1. > Are you able to reproduce the test failure? I think the test verifies that only one thread gets the reference is a good test. I think the race is due to the threads get to call queue.remove as soon as both threads decrement the count of the latch that can be well before the reference is enqueued. It'd be good to add additional information in the test to help diagnosing test failure. Mandy > Here's the trivial fix: > http://cr.openjdk.java.net/~igerasim/8038333/0/webrev/ > > Sincerely yours, > Ivan Gerasimov From aleksej.efimov at oracle.com Wed Mar 26 17:44:06 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Wed, 26 Mar 2014 21:44:06 +0400 Subject: RFR (JAXP): 8035437: Xerces Update: xml/serialize/DOMSerializerImpl In-Reply-To: <95ECB6AF-B918-4812-92C8-6915A3EDE98D@oracle.com> References: <533302DD.2090005@oracle.com> <155CED84-F9D2-4EF8-9AC2-18A7AA7C0E68@oracle.com> <95ECB6AF-B918-4812-92C8-6915A3EDE98D@oracle.com> Message-ID: <533311E6.2090500@oracle.com> Lance, The document implementation (DocumentImpl) returned by 'builder.newDocument()' should implement org.w3c.dom.Node and org.w3c.dom.Document interfaces, but shouldn't have the 'getXmlVersion' method (in Node, Document and DocumentImpl) - it's a main item required by Apache bug. So it means, that we need to substitute all three classes (Document,Node and DocumentImpl). The test should be executed with JDKs Node, Document, but DocumentImpl should be compiled against incorrect interfaces. I don't see, how I can implement it with jtreg keywords (the main problem is splitting the compilation of DocumentImpl (fake Node, Document) and the test run (only fake DocumentImpl). The only reason why StringBuffer is not used here - the process of how updates were moved from Xerces to JAXP: revision by revision. And I don't think that it should prevent us from replacing it with faster StringBuilder =). Will change it to StringBuilder. Thank you, Aleksej On 03/26/2014 09:04 PM, Lance Andersen wrote: > Any reason not to use StringBuilder in place of StringBuffer > in XMLEntityManager.java > > other than the above and my question on the need of using run.sh, it is OK > > On Mar 26, 2014, at 12:54 PM, Lance Andersen > > wrote: > >> Hi Aleksej, >> >> Do you really need to use run.sh? If possible it would be better to >> try and avoid providing a script and use the jtreg keywords. >> >> Best >> Lance >> On Mar 26, 2014, at 12:39 PM, Aleksej Efimov >> > wrote: >> >>> Hello, >>> >>> Can I ask for a review for the update of DOMSerializerImpl class [1] >>> to the latest Apache Xerces implementation. >>> The following changes were made: >>> 1. The DOMSerializerImpl update: The Xerces class was used as a base >>> [2]; the 476047 and 473125 revisions from Xerces was excluded (they >>> will be resolved as a part of JDK-8035467 - move to Xalan serializer >>> bug); the jaxp 632 revision was applied to new version of this class. >>> 2. The DOMSerializerImpl.java file was reformated, because of >>> not-good formatting in original file from Apache repo [2]. >>> 3. Other changes related to the DOMSerializerImpl update were >>> applied from Xerces repo to JDK(the full revisions list can be found >>> in the JBS [1]). >>> 4. All license headers were updated to the latest version of Apache >>> header in modified files. >>> 5. New regression test was added to reproduce a problem described in >>> Apache bug XERCESJ-1007 [3]. >>> >>> Webrevs for these changes: >>> http://cr.openjdk.java.net/~aefimov/8035437/webrev.00/jaxp >>> >>> http://cr.openjdk.java.net/~aefimov/8035437/webrev.00/jdk >>> >>> >>> Testing: >>> JCK tests (api/xsl api/xinclude api/javax_xml api/org_xml >>> xml_schema): pass >>> JTREG tests (javax/xml, jdk_other): pass >>> >>> Thank you, >>> Aleksej >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-6339023 >>> [2] >>> http://svn.apache.org/viewvc/xerces/java/trunk/src/org/apache/xml/serialize/DOMSerializerImpl.java?revision=944789&view=markup >>> [3] https://issues.apache.org/jira/browse/XERCESJ-1007 >>> >> >> >> >> 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 >> >> >> > > > > 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 volker.simonis at gmail.com Wed Mar 26 17:48:26 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 26 Mar 2014 18:48:26 +0100 Subject: Improve timezone mapping for AIX platform In-Reply-To: <53329D98.6040002@oracle.com> References: <53329D98.6040002@oracle.com> Message-ID: Hi Jonathan, thanks for doing this change. Please find some comments below: 1. please update the copyright year to 2014 in every file you touch 2. in CopyFiles.gmk you can simplify the change by joining the windows and aix cases because on Windows OPENJDK_TARGET_OS is the same like OPENJDK_TARGET_OS_API_DIR. So you can write: ifneq ($(findstring $(OPENJDK_TARGET_OS), windows aix), ) TZMAPPINGS_SRC := $(JDK_TOPDIR)/src/$(OPENJDK_TARGET_OS)/lib $(LIBDIR)/tzmappings: $(TZMAPPINGS_SRC)/tzmappings $(call install-file) COPY_FILES += $(LIBDIR)/tzmappings endif 3. regarding the changes proposed by Masayoshi: I agree that we should put the AIX timezone mapping code in its own function, but I don't think that getPlatformTimeZoneID() would be the right place. As far as I understand, getPlatformTimeZoneID() is used to get a platform time zone id if the environment variable "TZ" is not set. I don't know a way how this could be done on AIX (@Jonathan: maybe you know?). If there would be a way to get the time zone from some system files or so, then we should put this code into the AIX version of getPlatformTimeZoneID(). But the current AIX code contributed by Jonathan, actually uses the time zone id from the "TZ" environment variable and just maps it to a Java compatible time zone id. So I'd suggest to refactor this code into a function like for example "static const char* mapPlatformToJavaTimzone(const char* tz)" and call that from findJavaTZ_md(). I think that would make the code easier to understand. @Masayoshi: what do you think, would you agree with such a solution. 4. I agree with Masayoshi that you should use the existing getGMTOffsetID() 5. Please notice that your change breaks all Unix builds except AIX because of: 759 } 760 tzerr: 761 if (javatz == NULL) { 762 time_t offset; ... 782 } 783 #endif I think that should read: 759 760 tzerr: 761 if (javatz == NULL) { 762 time_t offset; ... 782 } 783 #endif 784 } Refactoring the code in an extra function will make that error more evident anyway. But please always build at least on one different platform (i.e. Linux) to prevent such errors in the future. Regards, Volker On Wed, Mar 26, 2014 at 10:27 AM, Masayoshi Okutsu wrote: > Hi Jonathan, > > The AIX specific code looks OK to me. But I'd suggest the code be moved to > getPlatformTimeZoneID() for AIX, which just returns NULL currently. Also > there's a function for producing a fallback ID in "GMT?hh:mm", > getGMTOffsetID() which can be called in tzerr. > > Thanks, > Masayoshi > > > On 3/26/2014 3:47 PM, Jonathan Lu wrote: >> >> Hi ppc-aix-port-dev, core-libs-dev, >> >> Here's a patch for JDK-8034220, >> >> http://cr.openjdk.java.net/~luchsh/JDK-8034220/ >> >> It is trying to add the a more complete timezone mapping mechanism for AIX >> platform. >> the changes are primarily based on IBM's commercial JDK code, which >> includes: >> >> - A new timezone mapping file added under directory jdk/src/aix/lib/ >> - Code to parse above config file, changed file is >> src/solaris/native/java/util/TimeZone_md.c >> - And also makefile change in make/CopyFiles.gmk to copy the config file >> >> Could you pls help to review and give comments ? >> >> Cheers >> - Jonathan > > From peter.levart at gmail.com Wed Mar 26 17:49:07 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 26 Mar 2014 18:49:07 +0100 Subject: ProcessReaper: single thread reaper In-Reply-To: <5331F979.4070308@Oracle.com> References: <532C7A30.6060904@oracle.com> <532CA33D.3030502@oracle.com> <532E2113.6040903@gmail.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> Message-ID: <53331313.8060804@gmail.com> Hi Roger, Your current implementation works for the demostrated use case in UNIXProcess, where a single call-back is registered for a pid. If you wanted to register another, the waitList and exitList might have already removed the pid from them as a result of the 1st call-back already been serviced before registering the 2nd one. So you might want to keep the entry in exitList for a while, to accommodate for 2nd and subsequent call-back registration if such usage is to be needed. This is what I tried to do in the following code: http://cr.openjdk.java.net/~plevart/jdk9-dev/ProcessWaiter/webrev.01/ I leveraged ConcurrentHashMap and CompletableFuture for the task. As an example of usage in UNIXProcess, I modified the linux variant only. A single waiter thread is dispatching exit statuses from exited children to CompletableFutures. Various waitFor() etc. methods in UNIXProcess are implemented in terms of Future.get()/isDone() methods and clean-up is implemented by dispatching asynchronously a cleanup task to the thread pool, so that multiple threads can help draining buffers. Children that are collected by waiter thread but nobody has asked to be notified about get expunged from the map after a time-out. I haven't done any checking for live pids as you did in checkLiveness() because in current usage, a pid that registers a Future entry in the map is taken from a successful forkAndExec() call so it will definitely be collected by the waitLoop() when the child process exits. The only possibility that this does not happen is if the same pid was waited for somewhere else (not in the waitLoop()). So if this is to be supported, a scan of live pids will be necessary from time to time and not only when there're no unwaited children (suppose there is a long-lived child running indefinitely). What do you think? Regards, Peter On 03/25/2014 10:47 PM, Roger Riggs wrote: > Hi Martin, > > Two cases, one current and one future. > > In the current case, Process can spawn a process and the process > can exit before Process can register the callback to get the exitValue. > Peter pointed out this race in his comments. > The exitValue needs to be saved (for some time yet to be determined) > to allow the Process to register and get its callback with the exitValue. > > The second case is future looking to the case where a child process > not spawned by Process is exiting. It might be due to a child being > inherited from a dieing child or due to some different subprocess > launcher. > > When the JEP 102 process work happens, it should be possible to > wait or get called back for those non-spawned processes. > > The single (smaller) number of threads has been requested to handle > processes that control a large number of children. It could be from > a thread pool, either dedicated or common. The common threadpool > does not expect its tasks to hang for an indefinite period as might > occur when waiting for along running process to exit. > > Thanks, Roger > > > On 3/25/14 2:39 PM, Martin Buchholz wrote: >> What happens if the pid you get back is a subprocess not created by ProcessBuilder? >> + pid = waitpid(-1, &exitValue, 0); >> --- >> >> What is the advantage of having a single thread? Are you just trying >> to save threads? The cost of the reaper threads is much lower than >> usual because of the small stack size. >> >> >> >> On Tue, Mar 25, 2014 at 7:05 AM, Peter Levart > > wrote: >> >> On 03/24/2014 10:05 PM, roger riggs wrote: >>> Hi Rob, Martin, et.al . >>> >>> I've prototyped (for 9) a thread reaper[1] that uses a single >>> thread to wait for exiting >>> processes and calling back to the process with the exit status. >>> the interesting part is getting the exit status back to the >>> Process that needs it >>> It needs more testing and hardening. >>> >>> I had not considered using a signal handler for SIGCHLD but >>> that's an option, >>> though we need to be very careful about thread usage. >>> >>> Roger >>> >>> p.s. comments on the single thread reaper appreciated (in a new >>> thread) >>> [1] http://cr.openjdk.java.net/~rriggs/webrev-waitpid/ >>> >>> >>> >> Hi Roger, >> >> I think I found a little race. Suppose reaper task is still alive >> and that all consumers have been serviced (consumerCount is 0). >> The reaper task waits for 500 millis for next consumer to be >> registered, but times out. Before calling >> "reaperThread.release()", new consumer comes around and registers >> itself, also calling runReaper(), but since >> reaperThread.release() has not yet been called by old reaper >> task, new reaper task is not submitted to commonPool. The old >> reaper task finishes, leaving one consumer on the waitingList >> with no reaper task to service it. If no new consumers get >> registered, the waiting consumer will never be notified... >> >> The simplest solution for this race, I think, would be to have a >> dedicated long-running thread. It could be spawned lazily, but >> then it would never finish. >> >> Otherwise a nice solution with two lists (exitList/waitList) and >> avoidance of race with reversed orders between >> - consumer registration: register on waitList 1st then check >> exitList, and >> - exit event dispatch: register on exitList 1st then check waitList >> >> ...but the check you use with consumeCount local variable to >> detect processes spawned by other means (for purposes of logging >> only) has a race: >> >> thread1: Suppose a new consumer is being registered with >> onExitCall(...), is added on the waitList, but before checking >> exitList().size() and iterating the exitList, ... >> thread2: the reaper task detects that the very same process has >> finished (gets it's pid from waitpid) and adds it's pid to >> exitList. Then before iterating waitList, ... >> thread1: iterates the exitList, finds a match and consumes the >> pid, removing the matching entries from both exitList and >> waitList. Then ... >> thread2: the reaper task iterates waitList, doesn't find a >> matching entry for exitPid, doesn't increment consumeCount and >> voila: debug log("Unexpected process exit for pid:..."). >> >> >> That's enough races for today. >> >> Regards, Peter >> >>> >>> >>> On 3/24/2014 12:38 AM, Rob McKenna wrote: >>>> Hi folks, >>>> >>>> Roger Riggs (cc'd) may want to chip in here as he's looking at >>>> the reaper thread arrangement in 9 at the moment. >>>> >>>> On another note, I too support the merging of those files. I >>>> didn't think there was much appetite for it at the time so I >>>> must admit this fell down my todo list. Looking at this bug did >>>> remind me that its something worth trying though. As per Alan's >>>> mail, I'm going to tackle it separately if you folks don't >>>> mind. I'll have a look at Peter's changes (thanks Peter!) as >>>> soon as I can and see about getting them in. >>>> >>>> -Rob >>>> >>>> On 23/03/14 22:30, Martin Buchholz wrote: >>>>> >>>>> >>>>> >>>>> On Sun, Mar 23, 2014 at 2:34 AM, Martin Buchholz >>>>> > wrote: >>>>> >>>>> >>>>> We have also thought about whether having reaper threads >>>>> is necessary. The Unix rule is that child processes >>>>> should be waited for, and some thread needs to do that. >>>>> There's no way to wait for a set of child pids, or to >>>>> specify a "completion handler". Well, you might be able >>>>> to get the newish waitid() to do what you want, but it >>>>> looks like it's not sufficient when java is running inside >>>>> a process that might do independent subprocess creation >>>>> outside of the JVM. >>>>> >>>>> >>>>> Actually, I take it back. With sufficient work, it looks like >>>>> you can get SIGCHLD to give you pid information in siginfo_t >>>>> si_pid, and that can be used to trigger the reaping. It looks >>>>> like waitpid is "async-signal-safe", so we can call it from >>>>> our signal handler. >>>>> >>>>> While we're at it we can fix SIGCHLD handling to do signal >>>>> chaining, as with other signals. >>>> >>> >> >> > From martinrb at google.com Wed Mar 26 17:54:36 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 26 Mar 2014 10:54:36 -0700 Subject: ProcessReaper: single thread reaper In-Reply-To: <53331313.8060804@gmail.com> References: <532C7A30.6060904@oracle.com> <532CA33D.3030502@oracle.com> <532E2113.6040903@gmail.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> Message-ID: Peter and Roger, please stop going down this road until you have a solution for my show-stopper problem, that in the below you are reaping children that don't belong to java.lang.Process + pid = waitpid(-1, &exitValue, 0); On Wed, Mar 26, 2014 at 10:49 AM, Peter Levart wrote: > Hi Roger, > > Your current implementation works for the demostrated use case in > UNIXProcess, where a single call-back is registered for a pid. If you > wanted to register another, the waitList and exitList might have already > removed the pid from them as a result of the 1st call-back already been > serviced before registering the 2nd one. > > So you might want to keep the entry in exitList for a while, to > accommodate for 2nd and subsequent call-back registration if such usage is > to be needed. > > This is what I tried to do in the following code: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/ProcessWaiter/webrev.01/ > > I leveraged ConcurrentHashMap and CompletableFuture for the task. As an > example of usage in UNIXProcess, I modified the linux variant only. A > single waiter thread is dispatching exit statuses from exited children to > CompletableFutures. Various waitFor() etc. methods in UNIXProcess are > implemented in terms of Future.get()/isDone() methods and clean-up is > implemented by dispatching asynchronously a cleanup task to the thread > pool, so that multiple threads can help draining buffers. Children that are > collected by waiter thread but nobody has asked to be notified about get > expunged from the map after a time-out. > > I haven't done any checking for live pids as you did in checkLiveness() > because in current usage, a pid that registers a Future entry in the map is > taken from a successful forkAndExec() call so it will definitely be > collected by the waitLoop() when the child process exits. The only > possibility that this does not happen is if the same pid was waited for > somewhere else (not in the waitLoop()). So if this is to be supported, a > scan of live pids will be necessary from time to time and not only when > there're no unwaited children (suppose there is a long-lived child running > indefinitely). > > What do you think? > > Regards, Peter > > > > On 03/25/2014 10:47 PM, Roger Riggs wrote: > > Hi Martin, > > Two cases, one current and one future. > > In the current case, Process can spawn a process and the process > can exit before Process can register the callback to get the exitValue. > Peter pointed out this race in his comments. > The exitValue needs to be saved (for some time yet to be determined) > to allow the Process to register and get its callback with the exitValue. > > The second case is future looking to the case where a child process > not spawned by Process is exiting. It might be due to a child being > inherited from a dieing child or due to some different subprocess launcher. > > When the JEP 102 process work happens, it should be possible to > wait or get called back for those non-spawned processes. > > The single (smaller) number of threads has been requested to handle > processes that control a large number of children. It could be from > a thread pool, either dedicated or common. The common threadpool > does not expect its tasks to hang for an indefinite period as might > occur when waiting for along running process to exit. > > Thanks, Roger > > > On 3/25/14 2:39 PM, Martin Buchholz wrote: > > What happens if the pid you get back is a subprocess not created by ProcessBuilder? > > + pid = waitpid(-1, &exitValue, 0); > > --- > > What is the advantage of having a single thread? Are you just trying to > save threads? The cost of the reaper threads is much lower than usual > because of the small stack size. > > > > On Tue, Mar 25, 2014 at 7:05 AM, Peter Levart wrote: > >> On 03/24/2014 10:05 PM, roger riggs wrote: >> >> Hi Rob, Martin, et.al. >> >> I've prototyped (for 9) a thread reaper[1] that uses a single thread to >> wait for exiting >> processes and calling back to the process with the exit status. >> the interesting part is getting the exit status back to the Process that >> needs it >> It needs more testing and hardening. >> >> I had not considered using a signal handler for SIGCHLD but that's an >> option, >> though we need to be very careful about thread usage. >> >> Roger >> >> p.s. comments on the single thread reaper appreciated (in a new thread) >> [1] http://cr.openjdk.java.net/~rriggs/webrev-waitpid/ >> >> >> Hi Roger, >> >> I think I found a little race. Suppose reaper task is still alive and >> that all consumers have been serviced (consumerCount is 0). The reaper task >> waits for 500 millis for next consumer to be registered, but times out. >> Before calling "reaperThread.release()", new consumer comes around and >> registers itself, also calling runReaper(), but since >> reaperThread.release() has not yet been called by old reaper task, new >> reaper task is not submitted to commonPool. The old reaper task finishes, >> leaving one consumer on the waitingList with no reaper task to service it. >> If no new consumers get registered, the waiting consumer will never be >> notified... >> >> The simplest solution for this race, I think, would be to have a >> dedicated long-running thread. It could be spawned lazily, but then it >> would never finish. >> >> Otherwise a nice solution with two lists (exitList/waitList) and >> avoidance of race with reversed orders between >> - consumer registration: register on waitList 1st then check exitList, >> and >> - exit event dispatch: register on exitList 1st then check waitList >> >> ...but the check you use with consumeCount local variable to detect >> processes spawned by other means (for purposes of logging only) has a race: >> >> thread1: Suppose a new consumer is being registered with onExitCall(...), >> is added on the waitList, but before checking exitList().size() and >> iterating the exitList, ... >> thread2: the reaper task detects that the very same process has finished >> (gets it's pid from waitpid) and adds it's pid to exitList. Then before >> iterating waitList, ... >> thread1: iterates the exitList, finds a match and consumes the pid, >> removing the matching entries from both exitList and waitList. Then ... >> thread2: the reaper task iterates waitList, doesn't find a matching entry >> for exitPid, doesn't increment consumeCount and voila: debug >> log("Unexpected process exit for pid:..."). >> >> >> That's enough races for today. >> >> Regards, Peter >> >> >> >> On 3/24/2014 12:38 AM, Rob McKenna wrote: >> >> Hi folks, >> >> Roger Riggs (cc'd) may want to chip in here as he's looking at the reaper >> thread arrangement in 9 at the moment. >> >> On another note, I too support the merging of those files. I didn't think >> there was much appetite for it at the time so I must admit this fell down >> my todo list. Looking at this bug did remind me that its something worth >> trying though. As per Alan's mail, I'm going to tackle it separately if you >> folks don't mind. I'll have a look at Peter's changes (thanks Peter!) as >> soon as I can and see about getting them in. >> >> -Rob >> >> On 23/03/14 22:30, Martin Buchholz wrote: >> >> >> >> >> On Sun, Mar 23, 2014 at 2:34 AM, Martin Buchholz wrote: >> >>> >>> We have also thought about whether having reaper threads is necessary. >>> The Unix rule is that child processes should be waited for, and some >>> thread needs to do that. There's no way to wait for a set of child pids, >>> or to specify a "completion handler". Well, you might be able to get the >>> newish waitid() to do what you want, but it looks like it's not sufficient >>> when java is running inside a process that might do independent subprocess >>> creation outside of the JVM. >>> >>> >> Actually, I take it back. With sufficient work, it looks like you can >> get SIGCHLD to give you pid information in siginfo_t si_pid, and that can >> be used to trigger the reaping. It looks like waitpid is >> "async-signal-safe", so we can call it from our signal handler. >> >> While we're at it we can fix SIGCHLD handling to do signal chaining, as >> with other signals. >> >> >> >> >> > > > From Roger.Riggs at Oracle.com Wed Mar 26 18:01:16 2014 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 26 Mar 2014 11:01:16 -0700 Subject: ProcessReaper: single thread reaper In-Reply-To: References: <532C7A30.6060904@oracle.com> <532CA33D.3030502@oracle.com> <532E2113.6040903@gmail.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> Message-ID: <533315EC.3000601@Oracle.com> Hi Martin, My solution to that is to export a public API that can be used by other subsystems that fork processes. Some peaceful cooperation is required. Roger On 3/26/14 10:54 AM, Martin Buchholz wrote: > Peter and Roger, please stop going down this road until you have a > solution for my show-stopper problem, that in the below you are > reaping children that don't belong to java.lang.Process > > + pid = waitpid(-1, &exitValue, 0); > > > > On Wed, Mar 26, 2014 at 10:49 AM, Peter Levart > wrote: > > Hi Roger, > > Your current implementation works for the demostrated use case in > UNIXProcess, where a single call-back is registered for a pid. If > you wanted to register another, the waitList and exitList might > have already removed the pid from them as a result of the 1st > call-back already been serviced before registering the 2nd one. > > So you might want to keep the entry in exitList for a while, to > accommodate for 2nd and subsequent call-back registration if such > usage is to be needed. > > This is what I tried to do in the following code: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/ProcessWaiter/webrev.01/ > > > I leveraged ConcurrentHashMap and CompletableFuture for the task. > As an example of usage in UNIXProcess, I modified the linux > variant only. A single waiter thread is dispatching exit statuses > from exited children to CompletableFutures. Various waitFor() etc. > methods in UNIXProcess are implemented in terms of > Future.get()/isDone() methods and clean-up is implemented by > dispatching asynchronously a cleanup task to the thread pool, so > that multiple threads can help draining buffers. Children that are > collected by waiter thread but nobody has asked to be notified > about get expunged from the map after a time-out. > > I haven't done any checking for live pids as you did in > checkLiveness() because in current usage, a pid that registers a > Future entry in the map is taken from a successful forkAndExec() > call so it will definitely be collected by the waitLoop() when the > child process exits. The only possibility that this does not > happen is if the same pid was waited for somewhere else (not in > the waitLoop()). So if this is to be supported, a scan of live > pids will be necessary from time to time and not only when > there're no unwaited children (suppose there is a long-lived child > running indefinitely). > > What do you think? > > Regards, Peter > > > > On 03/25/2014 10:47 PM, Roger Riggs wrote: >> Hi Martin, >> >> Two cases, one current and one future. >> >> In the current case, Process can spawn a process and the process >> can exit before Process can register the callback to get the >> exitValue. >> Peter pointed out this race in his comments. >> The exitValue needs to be saved (for some time yet to be determined) >> to allow the Process to register and get its callback with the >> exitValue. >> >> The second case is future looking to the case where a child process >> not spawned by Process is exiting. It might be due to a child being >> inherited from a dieing child or due to some different subprocess >> launcher. >> >> When the JEP 102 process work happens, it should be possible to >> wait or get called back for those non-spawned processes. >> >> The single (smaller) number of threads has been requested to handle >> processes that control a large number of children. It could be from >> a thread pool, either dedicated or common. The common threadpool >> does not expect its tasks to hang for an indefinite period as might >> occur when waiting for along running process to exit. >> >> Thanks, Roger >> >> >> On 3/25/14 2:39 PM, Martin Buchholz wrote: >>> What happens if the pid you get back is a subprocess not created by ProcessBuilder? >>> + pid = waitpid(-1, &exitValue, 0); >>> --- >>> >>> What is the advantage of having a single thread? Are you just >>> trying to save threads? The cost of the reaper threads is much >>> lower than usual because of the small stack size. >>> >>> >>> >>> On Tue, Mar 25, 2014 at 7:05 AM, Peter Levart >>> > wrote: >>> >>> On 03/24/2014 10:05 PM, roger riggs wrote: >>>> Hi Rob, Martin, et.al . >>>> >>>> I've prototyped (for 9) a thread reaper[1] that uses a >>>> single thread to wait for exiting >>>> processes and calling back to the process with the exit >>>> status. >>>> the interesting part is getting the exit status back to the >>>> Process that needs it >>>> It needs more testing and hardening. >>>> >>>> I had not considered using a signal handler for SIGCHLD but >>>> that's an option, >>>> though we need to be very careful about thread usage. >>>> >>>> Roger >>>> >>>> p.s. comments on the single thread reaper appreciated (in a >>>> new thread) >>>> [1] http://cr.openjdk.java.net/~rriggs/webrev-waitpid/ >>>> >>>> >>>> >>> Hi Roger, >>> >>> I think I found a little race. Suppose reaper task is still >>> alive and that all consumers have been serviced >>> (consumerCount is 0). The reaper task waits for 500 millis >>> for next consumer to be registered, but times out. Before >>> calling "reaperThread.release()", new consumer comes around >>> and registers itself, also calling runReaper(), but since >>> reaperThread.release() has not yet been called by old reaper >>> task, new reaper task is not submitted to commonPool. The >>> old reaper task finishes, leaving one consumer on the >>> waitingList with no reaper task to service it. If no new >>> consumers get registered, the waiting consumer will never be >>> notified... >>> >>> The simplest solution for this race, I think, would be to >>> have a dedicated long-running thread. It could be spawned >>> lazily, but then it would never finish. >>> >>> Otherwise a nice solution with two lists (exitList/waitList) >>> and avoidance of race with reversed orders between >>> - consumer registration: register on waitList 1st then check >>> exitList, and >>> - exit event dispatch: register on exitList 1st then check >>> waitList >>> >>> ...but the check you use with consumeCount local variable to >>> detect processes spawned by other means (for purposes of >>> logging only) has a race: >>> >>> thread1: Suppose a new consumer is being registered with >>> onExitCall(...), is added on the waitList, but before >>> checking exitList().size() and iterating the exitList, ... >>> thread2: the reaper task detects that the very same process >>> has finished (gets it's pid from waitpid) and adds it's pid >>> to exitList. Then before iterating waitList, ... >>> thread1: iterates the exitList, finds a match and consumes >>> the pid, removing the matching entries from both exitList >>> and waitList. Then ... >>> thread2: the reaper task iterates waitList, doesn't find a >>> matching entry for exitPid, doesn't increment consumeCount >>> and voila: debug log("Unexpected process exit for pid:..."). >>> >>> >>> That's enough races for today. >>> >>> Regards, Peter >>> >>>> >>>> >>>> On 3/24/2014 12:38 AM, Rob McKenna wrote: >>>>> Hi folks, >>>>> >>>>> Roger Riggs (cc'd) may want to chip in here as he's >>>>> looking at the reaper thread arrangement in 9 at the moment. >>>>> >>>>> On another note, I too support the merging of those files. >>>>> I didn't think there was much appetite for it at the time >>>>> so I must admit this fell down my todo list. Looking at >>>>> this bug did remind me that its something worth trying >>>>> though. As per Alan's mail, I'm going to tackle it >>>>> separately if you folks don't mind. I'll have a look at >>>>> Peter's changes (thanks Peter!) as soon as I can and see >>>>> about getting them in. >>>>> >>>>> -Rob >>>>> >>>>> On 23/03/14 22:30, Martin Buchholz wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Sun, Mar 23, 2014 at 2:34 AM, Martin Buchholz >>>>>> > wrote: >>>>>> >>>>>> >>>>>> We have also thought about whether having reaper >>>>>> threads is necessary. The Unix rule is that child >>>>>> processes should be waited for, and some thread needs >>>>>> to do that. There's no way to wait for a set of >>>>>> child pids, or to specify a "completion handler". >>>>>> Well, you might be able to get the newish waitid() >>>>>> to do what you want, but it looks like it's not >>>>>> sufficient when java is running inside a process that >>>>>> might do independent subprocess creation outside of >>>>>> the JVM. >>>>>> >>>>>> >>>>>> Actually, I take it back. With sufficient work, it looks >>>>>> like you can get SIGCHLD to give you pid information in >>>>>> siginfo_t si_pid, and that can be used to trigger the >>>>>> reaping. It looks like waitpid is "async-signal-safe", >>>>>> so we can call it from our signal handler. >>>>>> >>>>>> While we're at it we can fix SIGCHLD handling to do >>>>>> signal chaining, as with other signals. >>>>> >>>> >>> >>> >> > > From martinrb at google.com Wed Mar 26 18:09:26 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 26 Mar 2014 11:09:26 -0700 Subject: ProcessReaper: single thread reaper In-Reply-To: <533315EC.3000601@Oracle.com> References: <532C7A30.6060904@oracle.com> <532CA33D.3030502@oracle.com> <532E2113.6040903@gmail.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> Message-ID: On Wed, Mar 26, 2014 at 11:01 AM, Roger Riggs wrote: > Hi Martin, > > My solution to that is to export a public API that can be used > by other subsystems that fork processes. Some peaceful cooperation is > required. > Roger, I don't think cooperation is possible - your solution must be compatible. Other folks may have written native library code 20 years ago that starts a subprocess and then waits for it, not even designed to coexist with a JVM. From peter.levart at gmail.com Wed Mar 26 19:07:46 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 26 Mar 2014 20:07:46 +0100 Subject: ProcessReaper: single thread reaper In-Reply-To: References: <532C7A30.6060904@oracle.com> <532CA33D.3030502@oracle.com> <532E2113.6040903@gmail.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> Message-ID: <53332582.50102@gmail.com> On 03/26/2014 07:09 PM, Martin Buchholz wrote: > On Wed, Mar 26, 2014 at 11:01 AM, Roger Riggswrote: > >> Hi Martin, >> >> My solution to that is to export a public API that can be used >> by other subsystems that fork processes. Some peaceful cooperation is >> required. >> > Roger, > > I don't think cooperation is possible - your solution must be compatible. > Other folks may have written native library code 20 years ago that starts > a subprocess and then waits for it, not even designed to coexist with a JVM. SIGCHLD then... In theory, if registered with sigaction(), the handler could chain the old handler so that a 3rd party library code written 20 years ago, registering it's own SIGCHLD handler, could co-exist, provided that it registers it's handler 1st or that it chains the old handler as well. The handler already gets all the data we need (from Linux man page): * SIGCHLD fills in si_pid, si_uid, si_status, si_utime and si_stime, providing information about the child. The si_pid field is the process ID of the child; si_uid is the child's real user ID. The si_status field contains the exit status of the child (if si_code is CLD_EXITED), or the signal number that caused the process to change state. The si_utime and si_stime contain the user and system CPU time used by the child process; these fields do not include the times used by waited-for children (unlike getrusage(2) and time(2)). In kernels up to 2.6, and since 2.6.27, these fields report CPU time in units of sysconf(_SC_CLK_TCK). In 2.6 kernels before 2.6.27, a bug meant that these fields reported time in units of the (configurable) system jiffy (see time(7)). This seems to be POSIX api. So it should be present on Solaris/OS X/AIX too? Regards, Peter From martinrb at google.com Wed Mar 26 19:32:29 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 26 Mar 2014 12:32:29 -0700 Subject: ProcessReaper: single thread reaper In-Reply-To: <53332582.50102@gmail.com> References: <532C7A30.6060904@oracle.com> <532CA33D.3030502@oracle.com> <532E2113.6040903@gmail.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> Message-ID: SIGCHLD should be chained to ambient signal handlers, as other handlers in the JDK do. A general improvement would be supporting arbitrary user-defined signal handlers pre-existing when the JVM is started. In the current implementation, the code that sets the signal handler for SIGCHLD to SIG_DFL should probably have first checked whether the inherited value is SIG_IGN. As for relying on SIGCHLD correctly reporting info in siginfo, you are replacing a time-immemorial API with a relatively recent one. I would expect portability problems. Latest standard seems to be: http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03 http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigaction.html There's enough wiggle room for implementations to say they're standard-compliant and not give you the data you want. On Wed, Mar 26, 2014 at 12:07 PM, Peter Levart wrote: > On 03/26/2014 07:09 PM, Martin Buchholz wrote: > >> On Wed, Mar 26, 2014 at 11:01 AM, Roger Riggs >> wrote: >> >> Hi Martin, >>> >>> My solution to that is to export a public API that can be used >>> by other subsystems that fork processes. Some peaceful cooperation is >>> required. >>> >>> Roger, >> >> I don't think cooperation is possible - your solution must be compatible. >> Other folks may have written native library code 20 years ago that >> starts >> a subprocess and then waits for it, not even designed to coexist with a >> JVM. >> > > SIGCHLD then... > > In theory, if registered with sigaction(), the handler could chain the old > handler so that a 3rd party library code written 20 years ago, registering > it's own SIGCHLD handler, could co-exist, provided that it registers it's > handler 1st or that it chains the old handler as well. > > The handler already gets all the data we need (from Linux man page): > > * SIGCHLD fills in si_pid, si_uid, si_status, si_utime and > si_stime, providing information about the child. The si_pid field is the > process ID of the child; si_uid is the > child's real user ID. The si_status field contains the exit > status of the child (if si_code is CLD_EXITED), or the signal number that > caused the process to change state. The > si_utime and si_stime contain the user and system CPU time used > by the child process; these fields do not include the times used by > waited-for children (unlike getrusage(2) > and time(2)). In kernels up to 2.6, and since 2.6.27, these > fields report CPU time in units of sysconf(_SC_CLK_TCK). In 2.6 kernels > before 2.6.27, a bug meant that these > fields reported time in units of the (configurable) system jiffy > (see time(7)). > > This seems to be POSIX api. So it should be present on Solaris/OS X/AIX > too? > > Regards, Peter > > From ivan.gerasimov at oracle.com Wed Mar 26 20:18:10 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 27 Mar 2014 00:18:10 +0400 Subject: RFR [8038333] java/lang/ref/EarlyTimeout.java failed In-Reply-To: <533308B3.2030605@oracle.com> References: <5332D2DD.3080207@oracle.com> <533308B3.2030605@oracle.com> Message-ID: <53333602.701@oracle.com> Thank you Mandy! > Are you able to reproduce the test failure? Yes, I could easily reproduce the failure when I reduced the timeout to 10 ms. With the timeout reduced, the test fails every third time on my machine. > I think the test verifies that only one thread gets the reference is a > good test. > But if none of the threads could get the reference, it should not cause the failure of the test. It only means that during this particular run we could not have tested what we needed. We could retry, but I'm not sure it's worth complicating the test. It's easier to ignore the failure, taking into account that it happens rarely. > I think the race is due to the threads get to call queue.remove as > soon as both threads decrement the count of the latch that can be well > before the reference is enqueued. > The problem is that we have no way to block the main thread until there is a reference in the queue. I improved the situation a bit, having moved the await() after the call of gc(). > It'd be good to add additional information in the test to help > diagnosing test failure. > I added reporting to stderr about being unable to remove a reference from the queue. I believe we shouldn't treat it as an error, and should simply ignore it. Would you please have a look at the updated webrev: http://cr.openjdk.java.net/~igerasim/8038333/1/webrev/ Sincerely yours, Ivan From christian.thalinger at oracle.com Wed Mar 26 20:38:46 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 26 Mar 2014 13:38:46 -0700 Subject: RFR(S) : 8038186 : [TESTBUG] improvements of test j.l.i.MethodHandles In-Reply-To: <533096A8.1020405@oracle.com> References: <533096A8.1020405@oracle.com> Message-ID: <8068D25C-AA39-4012-83BC-0A2F09309EF8@oracle.com> On Mar 24, 2014, at 1:33 PM, Igor Ignatyev wrote: > Hi all, > > Please review the patch: > > Problems: > - MethodHandlesTest::testCatchException() doesn't provide enough testing of j.l.i.MethodHandles::catchException(). > - MethodHandlesTest contains more than 3k lines, an auxiliary code together w/ a test code, many methods aren't connected w/ each other, etc. All this leads to that it is very very hard to understand, maintain. Yes, it is. > > Fix: > - the auxiliary code was moved to testlibray > - the test code was moved to a separate subpackage This is very nice. Are there plans to do this for the other existing tests as well? > - random signature is used for target and handler > - added scenarios w/ different return types > > webrev: http://cr.openjdk.java.net/~iignatyev/8038186/webrev.01/ > jbs: https://bugs.openjdk.java.net/browse/JDK-8038186 > -- > Igor > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From igor.ignatyev at oracle.com Wed Mar 26 20:46:37 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 27 Mar 2014 00:46:37 +0400 Subject: RFR(S) : 8038186 : [TESTBUG] improvements of test j.l.i.MethodHandles In-Reply-To: <8068D25C-AA39-4012-83BC-0A2F09309EF8@oracle.com> References: <533096A8.1020405@oracle.com> <8068D25C-AA39-4012-83BC-0A2F09309EF8@oracle.com> Message-ID: <53333CAD.8080309@oracle.com> Hi Chris, > This is very nice. Are there plans to do this for the other existing tests as well? sure, but we didn't have enough time to do it in 8u20 timeframe. So I'd like to push these changes 1st, since we need this to cover 'Speedup catch exceptions'. Other tests will be rewrite later. I hope we'll have time in jdk 9 to refactor all tests in MethodHandles. Thanks, Igor On 03/27/2014 12:38 AM, Christian Thalinger wrote: > > On Mar 24, 2014, at 1:33 PM, Igor Ignatyev wrote: > >> Hi all, >> >> Please review the patch: >> >> Problems: >> - MethodHandlesTest::testCatchException() doesn't provide enough testing of j.l.i.MethodHandles::catchException(). >> - MethodHandlesTest contains more than 3k lines, an auxiliary code together w/ a test code, many methods aren't connected w/ each other, etc. All this leads to that it is very very hard to understand, maintain. > > Yes, it is. > >> >> Fix: >> - the auxiliary code was moved to testlibray >> - the test code was moved to a separate subpackage > > This is very nice. Are there plans to do this for the other existing tests as well? > >> - random signature is used for target and handler >> - added scenarios w/ different return types >> >> webrev: http://cr.openjdk.java.net/~iignatyev/8038186/webrev.01/ >> jbs: https://bugs.openjdk.java.net/browse/JDK-8038186 >> -- >> Igor >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From aleksej.efimov at oracle.com Wed Mar 26 21:23:17 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Thu, 27 Mar 2014 00:23:17 +0300 Subject: RFR (JAXP): 8035437: Xerces Update: xml/serialize/DOMSerializerImpl In-Reply-To: <533311E6.2090500@oracle.com> References: <533302DD.2090005@oracle.com> <155CED84-F9D2-4EF8-9AC2-18A7AA7C0E68@oracle.com> <95ECB6AF-B918-4812-92C8-6915A3EDE98D@oracle.com> <533311E6.2090500@oracle.com> Message-ID: <53334545.2090904@oracle.com> The link to the JBS bug is incorrect in original review request. This one is a correct one: https://bugs.openjdk.java.net/browse/JDK-8035437. Sorry for the confusion, Aleksej On 26.03.2014 20:44, Aleksej Efimov wrote: > Lance, > The document implementation (DocumentImpl) returned by > 'builder.newDocument()' should implement org.w3c.dom.Node and > org.w3c.dom.Document interfaces, but shouldn't have the > 'getXmlVersion' method (in Node, Document and DocumentImpl) - it's a > main item required by Apache bug. So it means, that we need to > substitute all three classes (Document,Node and DocumentImpl). The > test should be executed with JDKs Node, Document, but DocumentImpl > should be compiled against incorrect interfaces. I don't see, how I > can implement it with jtreg keywords (the main problem is splitting > the compilation of DocumentImpl (fake Node, Document) and the test run > (only fake DocumentImpl). > > The only reason why StringBuffer is not used here - the process of how > updates were moved from Xerces to JAXP: revision by revision. And I > don't think that it should prevent us from replacing it with faster > StringBuilder =). Will change it to StringBuilder. > > Thank you, > Aleksej > > On 03/26/2014 09:04 PM, Lance Andersen wrote: >> Any reason not to use StringBuilder in place of StringBuffer in >> XMLEntityManager.java >> >> other than the above and my question on the need of using run.sh, it >> is OK >> >> On Mar 26, 2014, at 12:54 PM, Lance Andersen >> > wrote: >> >>> Hi Aleksej, >>> >>> Do you really need to use run.sh? If possible it would be better to >>> try and avoid providing a script and use the jtreg keywords. >>> >>> Best >>> Lance >>> On Mar 26, 2014, at 12:39 PM, Aleksej Efimov >>> > wrote: >>> >>>> Hello, >>>> >>>> Can I ask for a review for the update of DOMSerializerImpl class >>>> [1] to the latest Apache Xerces implementation. >>>> The following changes were made: >>>> 1. The DOMSerializerImpl update: The Xerces class was used as a >>>> base [2]; the 476047 and 473125 revisions from Xerces was excluded >>>> (they will be resolved as a part of JDK-8035467 - move to Xalan >>>> serializer bug); the jaxp 632 revision was applied to new version >>>> of this class. >>>> 2. The DOMSerializerImpl.java file was reformated, because of >>>> not-good formatting in original file from Apache repo [2]. >>>> 3. Other changes related to the DOMSerializerImpl update were >>>> applied from Xerces repo to JDK(the full revisions list can be >>>> found in the JBS [1]). >>>> 4. All license headers were updated to the latest version of Apache >>>> header in modified files. >>>> 5. New regression test was added to reproduce a problem described >>>> in Apache bug XERCESJ-1007 [3]. >>>> >>>> Webrevs for these changes: >>>> http://cr.openjdk.java.net/~aefimov/8035437/webrev.00/jaxp >>>> >>>> http://cr.openjdk.java.net/~aefimov/8035437/webrev.00/jdk >>>> >>>> >>>> Testing: >>>> JCK tests (api/xsl api/xinclude api/javax_xml api/org_xml >>>> xml_schema): pass >>>> JTREG tests (javax/xml, jdk_other): pass >>>> >>>> Thank you, >>>> Aleksej >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-6339023 >>>> [2] >>>> http://svn.apache.org/viewvc/xerces/java/trunk/src/org/apache/xml/serialize/DOMSerializerImpl.java?revision=944789&view=markup >>>> [3] https://issues.apache.org/jira/browse/XERCESJ-1007 >>>> >>> >>> >>> >>> 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 >>> >>> >>> >> >> >> >> >> 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 david.holmes at oracle.com Wed Mar 26 22:57:14 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 27 Mar 2014 08:57:14 +1000 Subject: RFR [8038333] java/lang/ref/EarlyTimeout.java failed In-Reply-To: <53333602.701@oracle.com> References: <5332D2DD.3080207@oracle.com> <533308B3.2030605@oracle.com> <53333602.701@oracle.com> Message-ID: <53335B4A.6060100@oracle.com> Ivan, I think the problem is that the EarlyTimeout threads can complete their remove(TIMEOUT) before the main thread has started them all, cleared the reference and called System.gc(). Depending on exactly what is being tested, the EarlyTimeout threads may need to wait on another latch that is signalled by the main thread after the gc() call returns. Still no guarantee that the gc will do its work before the timeout elapses. David On 27/03/2014 6:18 AM, Ivan Gerasimov wrote: > Thank you Mandy! > >> Are you able to reproduce the test failure? > > Yes, I could easily reproduce the failure when I reduced the timeout to > 10 ms. > With the timeout reduced, the test fails every third time on my machine. > >> I think the test verifies that only one thread gets the reference is a >> good test. >> > But if none of the threads could get the reference, it should not cause > the failure of the test. > It only means that during this particular run we could not have tested > what we needed. > We could retry, but I'm not sure it's worth complicating the test. > It's easier to ignore the failure, taking into account that it happens > rarely. > >> I think the race is due to the threads get to call queue.remove as >> soon as both threads decrement the count of the latch that can be well >> before the reference is enqueued. >> > The problem is that we have no way to block the main thread until there > is a reference in the queue. > I improved the situation a bit, having moved the await() after the call > of gc(). > >> It'd be good to add additional information in the test to help >> diagnosing test failure. >> > I added reporting to stderr about being unable to remove a reference > from the queue. > I believe we shouldn't treat it as an error, and should simply ignore it. > > Would you please have a look at the updated webrev: > http://cr.openjdk.java.net/~igerasim/8038333/1/webrev/ > > Sincerely yours, > Ivan > > From xueming.shen at oracle.com Wed Mar 26 23:02:48 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 26 Mar 2014 16:02:48 -0700 Subject: RFR: JDK-8036818: DateTimeFormatter withResolverFields() fails to accept null In-Reply-To: References: Message-ID: <53335C98.2030609@oracle.com> Stephen, public DateTimeFormatter withResolverFields(TemporalField... resolverFields) { - Objects.requireNonNull(resolverFields, "resolverFields"); - Set fields = new HashSet<>(Arrays.asList(resolverFields)); + Set fields = null; + if (resolverFields != null) { + fields = Collections.unmodifiableSet(new HashSet<>(Arrays.asList(resolverFields))); + } if (Objects.equals(this.resolverFields, fields)) { return this; } - fields = Collections.unmodifiableSet(fields); return new DateTimeFormatter(printerParser, locale, decimalStyle, resolverStyle, fields, chrono, zone); } Isn't it better to do + if (resolverFields != null && resolverFields.length != 0) { + fields = Collections.unmodifiableSet(new HashSet<>(Arrays.asList(resolverFields))); + } (similar size check for the set version) ? -Sherman On 03/12/2014 03:45 AM, Stephen Colebourne wrote: > This is a request for review of this bug: > https://bugs.openjdk.java.net/browse/JDK-8036818 > > The method DateTimeFormatter withResolverFields() is supposed to > accept null. This is to allow a coy of the formatter to be returned > reset to the original state of having no resolver fields. The docs > say: > "@param resolverFields the new set of resolver fields, null if no fields" > which was written to indicate that resetting to null is permitted. > > The fix is to check for null and return a copy of the formatter. Note > that there are two variations of the method which need fixing. > > Proposed patch: > https://gist.github.com/jodastephen/9395197 > The patch includes no spec changes. > The patch fixes the broken TCK tests. > > I need a reviewer and a committer please. > thanks > Stephen From mandy.chung at oracle.com Thu Mar 27 00:30:34 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 26 Mar 2014 17:30:34 -0700 Subject: RFR [8038333] java/lang/ref/EarlyTimeout.java failed In-Reply-To: <53335B4A.6060100@oracle.com> References: <5332D2DD.3080207@oracle.com> <533308B3.2030605@oracle.com> <53333602.701@oracle.com> <53335B4A.6060100@oracle.com> Message-ID: <5333712A.2060908@oracle.com> On 3/26/2014 3:57 PM, David Holmes wrote: > Ivan, > > I think the problem is that the EarlyTimeout threads can complete > their remove(TIMEOUT) before the main thread has started them all, > cleared the reference and called System.gc(). > > Depending on exactly what is being tested, the EarlyTimeout threads > may need to wait on another latch that is signalled by the main thread > after the gc() call returns. Still no guarantee that the gc will do > its work before the timeout elapses. > This is similar to what I have been thinking. I believe the EarlyTimeout threads don't need the startedSignal.countDown; instead it can have a signal latch with 1 count. The EarlyTimeout threads awaits on the signal latch. The main thread will call signal.countDown after System.gc() and we can add a check weakReference.isEnqueued to make sure before we awake the threads to proceed the queue.remove call. Ivan - for the error message, perhaps you can simply do this: if (nonNullRefCount != 1) { throw new RuntimeException(nonNullRefCount + " references were removed from queue"); } Mandy > David > > On 27/03/2014 6:18 AM, Ivan Gerasimov wrote: >> Thank you Mandy! >> >>> Are you able to reproduce the test failure? >> >> Yes, I could easily reproduce the failure when I reduced the timeout to >> 10 ms. >> With the timeout reduced, the test fails every third time on my machine. >> >>> I think the test verifies that only one thread gets the reference is a >>> good test. >>> >> But if none of the threads could get the reference, it should not cause >> the failure of the test. >> It only means that during this particular run we could not have tested >> what we needed. >> We could retry, but I'm not sure it's worth complicating the test. >> It's easier to ignore the failure, taking into account that it happens >> rarely. >> >>> I think the race is due to the threads get to call queue.remove as >>> soon as both threads decrement the count of the latch that can be well >>> before the reference is enqueued. >>> >> The problem is that we have no way to block the main thread until there >> is a reference in the queue. >> I improved the situation a bit, having moved the await() after the call >> of gc(). >> >>> It'd be good to add additional information in the test to help >>> diagnosing test failure. >>> >> I added reporting to stderr about being unable to remove a reference >> from the queue. >> I believe we shouldn't treat it as an error, and should simply ignore >> it. >> >> Would you please have a look at the updated webrev: >> http://cr.openjdk.java.net/~igerasim/8038333/1/webrev/ >> >> Sincerely yours, >> Ivan >> >> From ivan.gerasimov at oracle.com Thu Mar 27 07:26:19 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 27 Mar 2014 11:26:19 +0400 Subject: RFR [8038333] java/lang/ref/EarlyTimeout.java failed In-Reply-To: <5333712A.2060908@oracle.com> References: <5332D2DD.3080207@oracle.com> <533308B3.2030605@oracle.com> <53333602.701@oracle.com> <53335B4A.6060100@oracle.com> <5333712A.2060908@oracle.com> Message-ID: <5333D29B.7080504@oracle.com> David, Mandy, thank you for comments! Here's what we want to achieve in the test: Two EarlyTimeout child threads should both be blocked in remove(TIMEOUT) at the moment the weakReference gets enqueued. This is the situation, when the bug 6853696 manifests itself. If we made sure the weakReference is enqueued before remove() is called by the child threads, then they both would wait for specified amount of time even without the fix. That's why we make the main thread wait for the children to start before calling System.gc(). I understand it may seem strange at the first glance. But we want the child thread to be inside the remove() function when the main thread is unblocked, that's why it is done this way. Unfortunately, we cannot easily make sure that remove() was called by the child threads at the moment the GC decides to enqueue the weakReference. Therefore, the test is probabilistic by its nature, and we cannot be absolutely sure that at least one child thread will get non-null reference returned from remove(). I'm withdrawing the second webrev: While moving startedSignal.await() after System.gc() reduces the number of cases when nonNullRefCount == 0, it also greatly decreases the chances of occurring the situation the test was designed for. I believe the correct fix here is to ignore the (quite rare) situation when nonNullRefCount upon the completion. I suggest to return to the very first trivial fix: http://cr.openjdk.java.net/~igerasim/8038333/1/webrev/ Sincerely yours, Ivan On 27.03.2014 4:30, Mandy Chung wrote: > On 3/26/2014 3:57 PM, David Holmes wrote: >> Ivan, >> >> I think the problem is that the EarlyTimeout threads can complete >> their remove(TIMEOUT) before the main thread has started them all, >> cleared the reference and called System.gc(). >> >> Depending on exactly what is being tested, the EarlyTimeout threads >> may need to wait on another latch that is signalled by the main >> thread after the gc() call returns. Still no guarantee that the gc >> will do its work before the timeout elapses. >> > > This is similar to what I have been thinking. I believe the > EarlyTimeout threads don't need the startedSignal.countDown; instead > it can have a signal latch with 1 count. The EarlyTimeout threads > awaits on the signal latch. The main thread will call > signal.countDown after System.gc() and we can add a check > weakReference.isEnqueued to make sure before we awake the threads to > proceed the queue.remove call. > > Ivan - for the error message, perhaps you can simply do this: > > if (nonNullRefCount != 1) { > throw new RuntimeException(nonNullRefCount + " references > were removed from queue"); > } > > > Mandy > >> David >> >> On 27/03/2014 6:18 AM, Ivan Gerasimov wrote: >>> Thank you Mandy! >>> >>>> Are you able to reproduce the test failure? >>> >>> Yes, I could easily reproduce the failure when I reduced the timeout to >>> 10 ms. >>> With the timeout reduced, the test fails every third time on my >>> machine. >>> >>>> I think the test verifies that only one thread gets the reference is a >>>> good test. >>>> >>> But if none of the threads could get the reference, it should not cause >>> the failure of the test. >>> It only means that during this particular run we could not have tested >>> what we needed. >>> We could retry, but I'm not sure it's worth complicating the test. >>> It's easier to ignore the failure, taking into account that it happens >>> rarely. >>> >>>> I think the race is due to the threads get to call queue.remove as >>>> soon as both threads decrement the count of the latch that can be well >>>> before the reference is enqueued. >>>> >>> The problem is that we have no way to block the main thread until there >>> is a reference in the queue. >>> I improved the situation a bit, having moved the await() after the call >>> of gc(). >>> >>>> It'd be good to add additional information in the test to help >>>> diagnosing test failure. >>>> >>> I added reporting to stderr about being unable to remove a reference >>> from the queue. >>> I believe we shouldn't treat it as an error, and should simply >>> ignore it. >>> >>> Would you please have a look at the updated webrev: >>> http://cr.openjdk.java.net/~igerasim/8038333/1/webrev/ >>> >>> Sincerely yours, >>> Ivan >>> >>> > > > From volker.simonis at gmail.com Thu Mar 27 10:18:12 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 27 Mar 2014 11:18:12 +0100 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <5332FDD5.8030801@oracle.com> References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> Message-ID: Hi Peter, thanks for applying these changes to the AIX files as well. With the additional line: if (osName.equals("AIX")) { return AIX; } in Os.get() your change compiles cleanly on AIX and runs the java/lang/ProcessBuilder tests without any errors. So from an AIX perspective, thumbs up. Regards, Volker On Wed, Mar 26, 2014 at 5:18 PM, Alan Bateman wrote: > On 26/03/2014 15:19, Peter Levart wrote: >> >> I couldn't find any official document about possible os.name values for >> different supported OSes. Does anyone have a pointer? > > I don't know if there is a definite list but I assume we don't need to be > concerned with anything beyond the 4 that we have in OpenJDK, which is > "Linux", "SunOS", "AIX" and contains("OS X"). > > If we get to the point in JDK 9 where src/solaris is renamed to src/unix (or > something equivalent) then it could mean that the Os enum can be replaced > with an OS specific class in src/linux, src/solaris, ... and this would > avoid the need for an os.name check at runtime. > > -Alan. > From peter.levart at gmail.com Thu Mar 27 12:38:54 2014 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 27 Mar 2014 13:38:54 +0100 Subject: RFR [8038333] java/lang/ref/EarlyTimeout.java failed In-Reply-To: <5333D29B.7080504@oracle.com> References: <5332D2DD.3080207@oracle.com> <533308B3.2030605@oracle.com> <53333602.701@oracle.com> <53335B4A.6060100@oracle.com> <5333712A.2060908@oracle.com> <5333D29B.7080504@oracle.com> Message-ID: <53341BDE.5040907@gmail.com> Hi Ivan, On 03/27/2014 08:26 AM, Ivan Gerasimov wrote: > David, Mandy, thank you for comments! > > Here's what we want to achieve in the test: > Two EarlyTimeout child threads should both be blocked in > remove(TIMEOUT) at the moment the weakReference gets enqueued. > This is the situation, when the bug 6853696 manifests itself. > > If we made sure the weakReference is enqueued before remove() is > called by the child threads, then they both would wait for specified > amount of time even without the fix. > > That's why we make the main thread wait for the children to start > before calling System.gc(). > I understand it may seem strange at the first glance. > But we want the child thread to be inside the remove() function when > the main thread is unblocked, that's why it is done this way. > > Unfortunately, we cannot easily make sure that remove() was called by > the child threads at the moment the GC decides to enqueue the > weakReference. There could be a little delay (say half the timeout: 500ms) specified after main thread returns from the startedSignal.await(); and before setting referent = null; and doing System.gc(). This would decrease the chance that the reference is enqueued before EarlyTimeout threads enter queue.remove(1000), thus making the test more reliable in failing with unpatched code. Now even if the referent is released and System.gc() is called, that does not guarantee that a WeakReference is going to be enqueued before the EarlyTimeout threads timeout and the result could as well be 0 collected references. To increase the chance that the reference is enqueued in a timely manner, main thread could, immediately after System.gc(), call: SharedSecrets.getJavaLangRefAccess().tryHandlePendingReference(); (since SharedSecrets is in sun.misc protected package, JavaLangRefAccess instance would have to be obtained using reflection unfortunately). > Therefore, the test is probabilistic by its nature, and we cannot be > absolutely sure that at least one child thread will get non-null > reference returned from remove(). > > I'm withdrawing the second webrev: While moving startedSignal.await() > after System.gc() reduces the number of cases when nonNullRefCount == > 0, it also greatly decreases the chances of occurring the situation > the test was designed for. > > I believe the correct fix here is to ignore the (quite rare) situation > when nonNullRefCount upon the completion. > I suggest to return to the very first trivial fix: > http://cr.openjdk.java.net/~igerasim/8038333/1/webrev/ But this webrev *is moving startedSignal.await() after System.gc()* ... Regards, Peter > > Sincerely yours, > Ivan > > On 27.03.2014 4:30, Mandy Chung wrote: >> On 3/26/2014 3:57 PM, David Holmes wrote: >>> Ivan, >>> >>> I think the problem is that the EarlyTimeout threads can complete >>> their remove(TIMEOUT) before the main thread has started them all, >>> cleared the reference and called System.gc(). >>> >>> Depending on exactly what is being tested, the EarlyTimeout threads >>> may need to wait on another latch that is signalled by the main >>> thread after the gc() call returns. Still no guarantee that the gc >>> will do its work before the timeout elapses. >>> >> >> This is similar to what I have been thinking. I believe the >> EarlyTimeout threads don't need the startedSignal.countDown; instead >> it can have a signal latch with 1 count. The EarlyTimeout threads >> awaits on the signal latch. The main thread will call >> signal.countDown after System.gc() and we can add a check >> weakReference.isEnqueued to make sure before we awake the threads to >> proceed the queue.remove call. >> >> Ivan - for the error message, perhaps you can simply do this: >> >> if (nonNullRefCount != 1) { >> throw new RuntimeException(nonNullRefCount + " references >> were removed from queue"); >> } >> >> >> Mandy >> >>> David >>> >>> On 27/03/2014 6:18 AM, Ivan Gerasimov wrote: >>>> Thank you Mandy! >>>> >>>>> Are you able to reproduce the test failure? >>>> >>>> Yes, I could easily reproduce the failure when I reduced the >>>> timeout to >>>> 10 ms. >>>> With the timeout reduced, the test fails every third time on my >>>> machine. >>>> >>>>> I think the test verifies that only one thread gets the reference >>>>> is a >>>>> good test. >>>>> >>>> But if none of the threads could get the reference, it should not >>>> cause >>>> the failure of the test. >>>> It only means that during this particular run we could not have tested >>>> what we needed. >>>> We could retry, but I'm not sure it's worth complicating the test. >>>> It's easier to ignore the failure, taking into account that it happens >>>> rarely. >>>> >>>>> I think the race is due to the threads get to call queue.remove as >>>>> soon as both threads decrement the count of the latch that can be >>>>> well >>>>> before the reference is enqueued. >>>>> >>>> The problem is that we have no way to block the main thread until >>>> there >>>> is a reference in the queue. >>>> I improved the situation a bit, having moved the await() after the >>>> call >>>> of gc(). >>>> >>>>> It'd be good to add additional information in the test to help >>>>> diagnosing test failure. >>>>> >>>> I added reporting to stderr about being unable to remove a reference >>>> from the queue. >>>> I believe we shouldn't treat it as an error, and should simply >>>> ignore it. >>>> >>>> Would you please have a look at the updated webrev: >>>> http://cr.openjdk.java.net/~igerasim/8038333/1/webrev/ >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> >> >> >> > From ivan.gerasimov at oracle.com Thu Mar 27 13:36:50 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 27 Mar 2014 17:36:50 +0400 Subject: RFR [8038333] java/lang/ref/EarlyTimeout.java failed In-Reply-To: <53341BDE.5040907@gmail.com> References: <5332D2DD.3080207@oracle.com> <533308B3.2030605@oracle.com> <53333602.701@oracle.com> <53335B4A.6060100@oracle.com> <5333712A.2060908@oracle.com> <5333D29B.7080504@oracle.com> <53341BDE.5040907@gmail.com> Message-ID: <53342972.3090209@oracle.com> Thank you Peter! > There could be a little delay (say half the timeout: 500ms) specified > after main thread returns from the startedSignal.await(); and before > setting referent = null; and doing System.gc(). This would decrease > the chance that the reference is enqueued before EarlyTimeout threads > enter queue.remove(1000), thus making the test more reliable in > failing with unpatched code. > Yes, you're right. I've checked the test against jdk9-b01 (no fix for 6853696 yet). It gives 2.5% of false negatives (i.e. in 5 out of 200 runs the reference was enqueued before calling to remove()). With an additional delay of TIMEOUT / 2 this number dropped to 0%. With jdk9-b05 (with fix for 6853696) no false positives were shown with or without this additional delay. > Now even if the referent is released and System.gc() is called, that > does not guarantee that a WeakReference is going to be enqueued before > the EarlyTimeout threads timeout and the result could as well be 0 > collected references. To increase the chance that the reference is > enqueued in a timely manner, main thread could, immediately after > System.gc(), call: > > SharedSecrets.getJavaLangRefAccess().tryHandlePendingReference(); > > (since SharedSecrets is in sun.misc protected package, > JavaLangRefAccess instance would have to be obtained using reflection > unfortunately). > I would prefer not to complicate the test too much, if you don't mind. I think the test already shows reliable reproducibility. >> I suggest to return to the very first trivial fix: >> http://cr.openjdk.java.net/~igerasim/8038333/1/webrev/ > > But this webrev *is moving startedSignal.await() after System.gc()* ... > Oops, sorry. It was meant to be /8038333/*0*/webrev/, of course! Now, I updated the webrev with the additional delay as you suggested: http://cr.openjdk.java.net/~igerasim/8038333/2/webrev/ Would you please have a look? Sincerely yours, Ivan From peter.levart at gmail.com Thu Mar 27 14:00:55 2014 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 27 Mar 2014 15:00:55 +0100 Subject: RFR [8038333] java/lang/ref/EarlyTimeout.java failed In-Reply-To: <53342972.3090209@oracle.com> References: <5332D2DD.3080207@oracle.com> <533308B3.2030605@oracle.com> <53333602.701@oracle.com> <53335B4A.6060100@oracle.com> <5333712A.2060908@oracle.com> <5333D29B.7080504@oracle.com> <53341BDE.5040907@gmail.com> <53342972.3090209@oracle.com> Message-ID: <53342F17.5030007@gmail.com> On 03/27/2014 02:36 PM, Ivan Gerasimov wrote: > Thank you Peter! > >> There could be a little delay (say half the timeout: 500ms) specified >> after main thread returns from the startedSignal.await(); and before >> setting referent = null; and doing System.gc(). This would decrease >> the chance that the reference is enqueued before EarlyTimeout threads >> enter queue.remove(1000), thus making the test more reliable in >> failing with unpatched code. >> > Yes, you're right. > I've checked the test against jdk9-b01 (no fix for 6853696 yet). > It gives 2.5% of false negatives (i.e. in 5 out of 200 runs the > reference was enqueued before calling to remove()). > With an additional delay of TIMEOUT / 2 this number dropped to 0%. > > With jdk9-b05 (with fix for 6853696) no false positives were shown > with or without this additional delay. > >> Now even if the referent is released and System.gc() is called, that >> does not guarantee that a WeakReference is going to be enqueued >> before the EarlyTimeout threads timeout and the result could as well >> be 0 collected references. To increase the chance that the reference >> is enqueued in a timely manner, main thread could, immediately after >> System.gc(), call: >> >> SharedSecrets.getJavaLangRefAccess().tryHandlePendingReference(); >> >> (since SharedSecrets is in sun.misc protected package, >> JavaLangRefAccess instance would have to be obtained using reflection >> unfortunately). >> > > I would prefer not to complicate the test too much, if you don't mind. > I think the test already shows reliable reproducibility. > >>> I suggest to return to the very first trivial fix: >>> http://cr.openjdk.java.net/~igerasim/8038333/1/webrev/ >> >> But this webrev *is moving startedSignal.await() after System.gc()* ... >> > > Oops, sorry. It was meant to be /8038333/*0*/webrev/, of course! > > Now, I updated the webrev with the additional delay as you suggested: > http://cr.openjdk.java.net/~igerasim/8038333/2/webrev/ > > Would you please have a look? That looks good. So no warning if nonNullRefCount == 0 ... It is probably not particularly useful if nobody is going to look at it, right? Regards, Peter > > Sincerely yours, > Ivan > From ivan.gerasimov at oracle.com Thu Mar 27 14:49:06 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 27 Mar 2014 18:49:06 +0400 Subject: RFR [8038333] java/lang/ref/EarlyTimeout.java failed In-Reply-To: <53342F17.5030007@gmail.com> References: <5332D2DD.3080207@oracle.com> <533308B3.2030605@oracle.com> <53333602.701@oracle.com> <53335B4A.6060100@oracle.com> <5333712A.2060908@oracle.com> <5333D29B.7080504@oracle.com> <53341BDE.5040907@gmail.com> <53342972.3090209@oracle.com> <53342F17.5030007@gmail.com> Message-ID: <53343A62.3010308@oracle.com> On 27.03.2014 18:00, Peter Levart wrote: > On 03/27/2014 02:36 PM, Ivan Gerasimov wrote: >> Thank you Peter! >> >>> There could be a little delay (say half the timeout: 500ms) >>> specified after main thread returns from the startedSignal.await(); >>> and before setting referent = null; and doing System.gc(). This >>> would decrease the chance that the reference is enqueued before >>> EarlyTimeout threads enter queue.remove(1000), thus making the test >>> more reliable in failing with unpatched code. >>> >> Yes, you're right. >> I've checked the test against jdk9-b01 (no fix for 6853696 yet). >> It gives 2.5% of false negatives (i.e. in 5 out of 200 runs the >> reference was enqueued before calling to remove()). >> With an additional delay of TIMEOUT / 2 this number dropped to 0%. >> >> With jdk9-b05 (with fix for 6853696) no false positives were shown >> with or without this additional delay. >> >>> Now even if the referent is released and System.gc() is called, that >>> does not guarantee that a WeakReference is going to be enqueued >>> before the EarlyTimeout threads timeout and the result could as well >>> be 0 collected references. To increase the chance that the reference >>> is enqueued in a timely manner, main thread could, immediately after >>> System.gc(), call: >>> >>> SharedSecrets.getJavaLangRefAccess().tryHandlePendingReference(); >>> >>> (since SharedSecrets is in sun.misc protected package, >>> JavaLangRefAccess instance would have to be obtained using >>> reflection unfortunately). >>> >> >> I would prefer not to complicate the test too much, if you don't >> mind. I think the test already shows reliable reproducibility. >> >>>> I suggest to return to the very first trivial fix: >>>> http://cr.openjdk.java.net/~igerasim/8038333/1/webrev/ >>> >>> But this webrev *is moving startedSignal.await() after System.gc()* ... >>> >> >> Oops, sorry. It was meant to be /8038333/*0*/webrev/, of course! >> >> Now, I updated the webrev with the additional delay as you suggested: >> http://cr.openjdk.java.net/~igerasim/8038333/2/webrev/ >> >> Would you please have a look? > > That looks good. So no warning if nonNullRefCount == 0 ... It is > probably not particularly useful if nobody is going to look at it, right? > Yeah. I think that the test will only bring attention if it fails. > Regards, Peter > >> >> Sincerely yours, >> Ivan >> > From masayoshi.okutsu at oracle.com Thu Mar 27 15:36:50 2014 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Fri, 28 Mar 2014 00:36:50 +0900 Subject: Improve timezone mapping for AIX platform In-Reply-To: References: <53329D98.6040002@oracle.com> Message-ID: <53344592.90508@oracle.com> Hi Volker, You are right. The `tz' value needs to be given to getPlatformTimeZoneID() or the getenv() call should be moved to the function. Your mapPlatformToJavaTimzone(const char* tz) sounds good to me. In any case TimeZone_md.c has become too messy by accumulating platform/release-specific code. I guess it's time to clean up... Thanks, Masayoshi On 3/27/2014 2:48 AM, Volker Simonis wrote: > Hi Jonathan, > > thanks for doing this change. Please find some comments below: > > 1. please update the copyright year to 2014 in every file you touch > > 2. in CopyFiles.gmk you can simplify the change by joining the windows > and aix cases because on Windows OPENJDK_TARGET_OS is the same like > OPENJDK_TARGET_OS_API_DIR. So you can write: > > ifneq ($(findstring $(OPENJDK_TARGET_OS), windows aix), ) > > TZMAPPINGS_SRC := $(JDK_TOPDIR)/src/$(OPENJDK_TARGET_OS)/lib > > $(LIBDIR)/tzmappings: $(TZMAPPINGS_SRC)/tzmappings > $(call install-file) > > COPY_FILES += $(LIBDIR)/tzmappings > > endif > > 3. regarding the changes proposed by Masayoshi: I agree that we should > put the AIX timezone mapping code in its own function, but I don't > think that getPlatformTimeZoneID() would be the right place. As far as > I understand, getPlatformTimeZoneID() is used to get a platform time > zone id if the environment variable "TZ" is not set. I don't know a > way how this could be done on AIX (@Jonathan: maybe you know?). If > there would be a way to get the time zone from some system files or > so, then we should put this code into the AIX version of > getPlatformTimeZoneID(). > > But the current AIX code contributed by Jonathan, actually uses the > time zone id from the "TZ" environment variable and just maps it to a > Java compatible time zone id. So I'd suggest to refactor this code > into a function like for example "static const char* > mapPlatformToJavaTimzone(const char* tz)" and call that from > findJavaTZ_md(). I think that would make the code easier to > understand. > > @Masayoshi: what do you think, would you agree with such a solution. > > 4. I agree with Masayoshi that you should use the existing getGMTOffsetID() > > 5. Please notice that your change breaks all Unix builds except AIX because of: > > 759 } > 760 tzerr: > 761 if (javatz == NULL) { > 762 time_t offset; > ... > 782 } > 783 #endif > > I think that should read: > > 759 > 760 tzerr: > 761 if (javatz == NULL) { > 762 time_t offset; > ... > 782 } > 783 #endif > 784 } > > Refactoring the code in an extra function will make that error more > evident anyway. > > But please always build at least on one different platform (i.e. > Linux) to prevent such errors in the future. > > Regards, > Volker > > > On Wed, Mar 26, 2014 at 10:27 AM, Masayoshi Okutsu > wrote: >> Hi Jonathan, >> >> The AIX specific code looks OK to me. But I'd suggest the code be moved to >> getPlatformTimeZoneID() for AIX, which just returns NULL currently. Also >> there's a function for producing a fallback ID in "GMT?hh:mm", >> getGMTOffsetID() which can be called in tzerr. >> >> Thanks, >> Masayoshi >> >> >> On 3/26/2014 3:47 PM, Jonathan Lu wrote: >>> Hi ppc-aix-port-dev, core-libs-dev, >>> >>> Here's a patch for JDK-8034220, >>> >>> http://cr.openjdk.java.net/~luchsh/JDK-8034220/ >>> >>> It is trying to add the a more complete timezone mapping mechanism for AIX >>> platform. >>> the changes are primarily based on IBM's commercial JDK code, which >>> includes: >>> >>> - A new timezone mapping file added under directory jdk/src/aix/lib/ >>> - Code to parse above config file, changed file is >>> src/solaris/native/java/util/TimeZone_md.c >>> - And also makefile change in make/CopyFiles.gmk to copy the config file >>> >>> Could you pls help to review and give comments ? >>> >>> Cheers >>> - Jonathan >> From Ulf.Zibis at CoSoCo.de Thu Mar 27 16:24:35 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 27 Mar 2014 17:24:35 +0100 Subject: Implicit 'this' return for void methods In-Reply-To: References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> <53328D08.1000307@CoSoCo.de> Message-ID: <533450C3.8070307@CoSoCo.de> Hi Guy and Paul, thanks for liking my proposal. What can we do to convince the "officials" ? -Ulf Am 26.03.2014 17:20, schrieb Paul Benedict: > It would be nice to make this language change. In the past years, it's pretty clear many JSR EE > spec leads have gone on to make their APIs return the same object because they strongly prefer to > see object chaining in code. I sympathize with those designers, but I don't agree; I wouldn't > affect my API just for the sake of chaining. For the sake of clarity, I prefer functions that > don't compute anything to return void. So +1 for the language to figure this out. > > > On Wed, Mar 26, 2014 at 10:51 AM, Guy Steele > wrote: > > > On Mar 26, 2014, at 4:17 AM, Ulf Zibis wrote: > > > See also: > > . . . > > http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001180.html > > This last one has a specific proposal, which is simple and quite nice. The important idea is > that we don't actually make any change to the code of void methods or make them actually > return anything; instead, the caller takes notice of situations where an invocation of > a void method is used as a subexpression whose value is required (heretofore forbidden > by the language) and gives it a special interpretation. > > I note that Ulf's proposal applies only to method invocations, but I note that the same > technique could be used to include field references if desired. > > I am wholeheartedly in favor of allowing "chaining" of dotted expressions such as > > CharBuffer.allocate(26).position(2).put("C").position(25).put("Z") > > I am a bit more skeptical about expressions that begin with a dot because of potential > confusion about which expression is referred to: > > myVeryLongNamedString.subString(.indexOf("C"), .indexOf("Q")) > > seems clear enough, but what about: > > myVeryLongNamedString.subString(.indexOf("C") + otherString.length(), .indexOf("Q")) > > Does the second occurrence of .indexOf use myVeryLongNamedString or otherString? > > A compromise would be to allow leading-dot expressions to occur only within the arguments > of the method call whose target is the object which the leading-dot expressions are expected > to use as their target, and if there are such leading-dot expressions within the arguments > then the arguments must not contain any non-leading-dot field references or method calls. > Just a thought for discussion. This would be considered a separate mechanism from the > chaining-of-void-methods mechanism (it was a very clever idea to try to unify them in Ulf's > original proposal, though). > > ---Guy > > > > > -- > Cheers, > Paul From blackdrag at gmx.org Thu Mar 27 16:35:41 2014 From: blackdrag at gmx.org (Jochen Theodorou) Date: Thu, 27 Mar 2014 17:35:41 +0100 Subject: Implicit 'this' return for void methods In-Reply-To: References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> <53328D08.1000307@CoSoCo.de> Message-ID: <5334535D.7050402@gmx.org> Am 26.03.2014 16:51, schrieb Guy Steele: [...] > I am wholeheartedly in favor of allowing ?chaining? of dotted expressions such as > > CharBuffer.allocate(26).position(2).put("C").position(25).put("Z?) this also shows a potential point of critic this proposal will have to find arguments against. This style highly encourages mutation of the object, which is not very functional. Since java8 java tries to be more functional, thus this idea would be totally against this new line. I leave it to you guys if this is even a valid argument ;) bye Jochen -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org From volker.simonis at gmail.com Thu Mar 27 18:08:51 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 27 Mar 2014 19:08:51 +0100 Subject: RFR(S): 8038233 : Fix unsafe strcpy in Java_sun_tools_attach_{Aix, Bsd, Linux}VirtualMachine_connect() Message-ID: Hi, a security audit for the PPC64/AIX port revealed an unsecure useage of 'strcpy' in Java_sun_tools_attach_AixVirtualMachine_connect(). Because the same coding is also used in the Linux and BSD implementations, the following change fixes them all together: http://cr.openjdk.java.net/~simonis/webrevs/8038233/ https://bugs.openjdk.java.net/browse/JDK-8038233 Compiled and tested (with the com/sun/jdi, com/sun/tools/attach, com/sun/management and sun/management JTreg tests) on Linux, MacOS X and AIX. Please notice that this fix is also intended for backporting tu 8u. Thank you and best regards, Volker From Alan.Bateman at oracle.com Thu Mar 27 18:31:09 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 27 Mar 2014 18:31:09 +0000 Subject: RFR(S): 8038233 : Fix unsafe strcpy in Java_sun_tools_attach_{Aix, Bsd, Linux}VirtualMachine_connect() In-Reply-To: References: Message-ID: <53346E6D.20900@oracle.com> On 27/03/2014 18:08, Volker Simonis wrote: > Hi, > > a security audit for the PPC64/AIX port revealed an unsecure useage of > 'strcpy' in Java_sun_tools_attach_AixVirtualMachine_connect(). Because > the same coding is also used in the Linux and BSD implementations, the > following change fixes them all together: > > http://cr.openjdk.java.net/~simonis/webrevs/8038233/ > https://bugs.openjdk.java.net/browse/JDK-8038233 > > Compiled and tested (with the com/sun/jdi, com/sun/tools/attach, > com/sun/management and sun/management JTreg tests) on Linux, MacOS X > and AIX. > > Please notice that this fix is also intended for backporting tu 8u. > As we now have 3 implementations using socket pairs then there might be an opportunity to consolidate the implementations, not for this patch of course. Your changes looks okay and it's good to memset the sockaddr_un structure. As regards the issue is a concern or not then it's important to note thaht the Attach API is in tools.jar, it's not in a JRE build. Also an attach requires a Permission check if running with a security manager and I likely vert rare for tools to do this. Also to cause a problem then it would require the temporary directory to be unusually long. -Alan. From stevenschlansker at gmail.com Thu Mar 27 19:22:13 2014 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Thu, 27 Mar 2014 12:22:13 -0700 Subject: Implicit 'this' return for void methods In-Reply-To: <5334535D.7050402@gmx.org> References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> <53328D08.1000307@CoSoCo.de> <5334535D.7050402@gmx.org> Message-ID: On Mar 27, 2014, at 9:35 AM, Jochen Theodorou wrote: > Am 26.03.2014 16:51, schrieb Guy Steele: > [...] >> I am wholeheartedly in favor of allowing ?chaining? of dotted expressions such as >> >> CharBuffer.allocate(26).position(2).put("C").position(25).put("Z?) > > this also shows a potential point of critic this proposal will have to find arguments against. This style highly encourages mutation of the object, which is not very functional. Since java8 java tries to be more functional, thus this idea would be totally against this new line. > > I leave it to you guys if this is even a valid argument ;) It would be much easier to convince people to do less mutation if the language had support for the Builder pattern or freezing objects. Currently working with nontrivial immutable objects quickly leads to a lot of boilerplate code that requires frustrating maintenance every time the object definition changes. Adding both the implicit ?this? proposal as well as some syntax enhancements for immutable objects would strengthen the Java language quite a bit, in my opinion :) From igor.ignatyev at oracle.com Thu Mar 27 19:46:50 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 27 Mar 2014 23:46:50 +0400 Subject: RFR(S) : 8038186 : [TESTBUG] improvements of test j.l.i.MethodHandles In-Reply-To: <53333CAD.8080309@oracle.com> References: <533096A8.1020405@oracle.com> <8068D25C-AA39-4012-83BC-0A2F09309EF8@oracle.com> <53333CAD.8080309@oracle.com> Message-ID: <5334802A.9050003@oracle.com> After an offline conversation w/ VladimirI, I've done several changes: - placed all classes into one file (but I don't like it) - changed package name - extracted creating tests code from test execution code I hope the code's still quite readable and understandable. Also I've added array return type. http://cr.openjdk.java.net/~iignatyev/8038186/webrev.02/ Thanks, Igor On 03/27/2014 12:46 AM, Igor Ignatyev wrote: > Hi Chris, > >> This is very nice. Are there plans to do this for the other existing >> tests as well? > sure, but we didn't have enough time to do it in 8u20 timeframe. So I'd > like to push these changes 1st, since we need this to cover 'Speedup > catch exceptions'. Other tests will be rewrite later. I hope we'll have > time in jdk 9 to refactor all tests in MethodHandles. > > Thanks, > Igor > > On 03/27/2014 12:38 AM, Christian Thalinger wrote: >> >> On Mar 24, 2014, at 1:33 PM, Igor Ignatyev >> wrote: >> >>> Hi all, >>> >>> Please review the patch: >>> >>> Problems: >>> - MethodHandlesTest::testCatchException() doesn't provide enough >>> testing of j.l.i.MethodHandles::catchException(). >>> - MethodHandlesTest contains more than 3k lines, an auxiliary code >>> together w/ a test code, many methods aren't connected w/ each other, >>> etc. All this leads to that it is very very hard to understand, >>> maintain. >> >> Yes, it is. >> >>> >>> Fix: >>> - the auxiliary code was moved to testlibray >>> - the test code was moved to a separate subpackage >> >> This is very nice. Are there plans to do this for the other existing >> tests as well? >> >>> - random signature is used for target and handler >>> - added scenarios w/ different return types >>> >>> webrev: http://cr.openjdk.java.net/~iignatyev/8038186/webrev.01/ >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8038186 >>> -- >>> Igor >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From forax at univ-mlv.fr Thu Mar 27 20:16:58 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 27 Mar 2014 21:16:58 +0100 Subject: Implicit 'this' return for void methods In-Reply-To: References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> <53328D08.1000307@CoSoCo.de> <5334535D.7050402@gmx.org> Message-ID: <5334873A.6030908@univ-mlv.fr> On 03/27/2014 08:22 PM, Steven Schlansker wrote: > On Mar 27, 2014, at 9:35 AM, Jochen Theodorou wrote: > >> Am 26.03.2014 16:51, schrieb Guy Steele: >> [...] >>> I am wholeheartedly in favor of allowing ?chaining? of dotted expressions such as >>> >>> CharBuffer.allocate(26).position(2).put("C").position(25).put("Z?) >> this also shows a potential point of critic this proposal will have to find arguments against. This style highly encourages mutation of the object, which is not very functional. Since java8 java tries to be more functional, thus this idea would be totally against this new line. >> >> I leave it to you guys if this is even a valid argument ;) > It would be much easier to convince people to do less mutation if the language had support for the Builder pattern or freezing objects. Currently working with nontrivial immutable objects quickly leads to a lot of boilerplate code that requires frustrating maintenance every time the object definition changes. > > Adding both the implicit ?this? proposal as well as some syntax enhancements for immutable objects would strengthen the Java language quite a bit, in my opinion :) I fully agree. R?mi From blackdrag at gmx.org Thu Mar 27 20:26:50 2014 From: blackdrag at gmx.org (Jochen Theodorou) Date: Thu, 27 Mar 2014 21:26:50 +0100 Subject: Implicit 'this' return for void methods In-Reply-To: References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> <53328D08.1000307@CoSoCo.de> <5334535D.7050402@gmx.org> Message-ID: <5334898A.3080002@gmx.org> Am 27.03.2014 20:22, schrieb Steven Schlansker: > > On Mar 27, 2014, at 9:35 AM, Jochen Theodorou wrote: > >> Am 26.03.2014 16:51, schrieb Guy Steele: >> [...] >>> I am wholeheartedly in favor of allowing ?chaining? of dotted expressions such as >>> >>> CharBuffer.allocate(26).position(2).put("C").position(25).put("Z?) >> >> this also shows a potential point of critic this proposal will have to find arguments against. This style highly encourages mutation of the object, which is not very functional. Since java8 java tries to be more functional, thus this idea would be totally against this new line. >> >> I leave it to you guys if this is even a valid argument ;) > > It would be much easier to convince people to do less mutation if the language had support for the Builder pattern or freezing objects. I wanted to counter that people would probably complain about the huge amount of objects you create, but actually you can do this with a helper class producing a dummy, that then becomes the final object of the real class once you freeze or otherwise fixate it. Well, the details don't really matter. But yes, I agree... some language support here would help, though not sure how that would look like... > Currently working with nontrivial immutable objects quickly leads to a lot of boilerplate code that requires frustrating maintenance every time the object definition changes. yeah, with the approach I sketched I can totally see that. > Adding both the implicit ?this? proposal as well as some syntax enhancements for immutable objects would strengthen the Java language quite a bit, in my opinion :) And here I fail. If you need special support for the builder and freezer to produce some helper or something already, then you don't need the return 'this' for void at all. The helper would be generated and thus already have all the bits you want. Right now I am actually wondering if I should add that as a transform to Groovy. But well, this is Java. For the part with immutable I agree again of course. byeJochen -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org From mandy.chung at oracle.com Thu Mar 27 20:49:44 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 27 Mar 2014 13:49:44 -0700 Subject: JDK-8038451: Incorrect initialization order of static fields in sun.nio.cs.ext.JISAutoDetect$Decoder Message-ID: <53348EE8.1060805@oracle.com> This fixes the regression introduced by JDK-8038177 in which the osName field should be initialized before it's accessed in the class static initializer. https://bugs.openjdk.java.net/browse/JDK-8038451 Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8038451/webrev.00/ Thanks Mandy From eirik.lygre at gmail.com Thu Mar 27 20:52:21 2014 From: eirik.lygre at gmail.com (Eirik Lygre) Date: Thu, 27 Mar 2014 21:52:21 +0100 Subject: Implicit 'this' return for void methods In-Reply-To: <5334535D.7050402@gmx.org> References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> <53328D08.1000307@CoSoCo.de> <5334535D.7050402@gmx.org> Message-ID: On Thu, Mar 27, 2014 at 5:35 PM, Jochen Theodorou wrote: > Am 26.03.2014 16:51, schrieb Guy Steele: > [...] > > I am wholeheartedly in favor of allowing "chaining" of dotted expressions >> such as >> >> CharBuffer.allocate(26).position(2).put("C").position(25).put("Z") >> > > this also shows a potential point of critic this proposal will have to > find arguments against. This style highly encourages mutation of the > object, which is not very functional. Since java8 java tries to be more > functional, thus this idea would be totally against this new line. > The JavaBean specification, with it's "void setSomething()" functions are fundamental to so many things Java that they will never go away (good thing, too!).The suggested language change builds on top of that, is beneficial to a large body of existing code and does not invalidate any existing practices. It is, I think, a great example of bang for the buck -- low cost, high return. No changes needed in the VM; everything can be done by the compiler. Almost too sweet. I should have paid more attention to the dragon book, so that I could have taken a shot at the compiler myself :-/ Eirik From Alan.Bateman at oracle.com Thu Mar 27 21:06:10 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 27 Mar 2014 21:06:10 +0000 Subject: JDK-8038451: Incorrect initialization order of static fields in sun.nio.cs.ext.JISAutoDetect$Decoder In-Reply-To: <53348EE8.1060805@oracle.com> References: <53348EE8.1060805@oracle.com> Message-ID: <533492C2.4010208@oracle.com> On 27/03/2014 20:49, Mandy Chung wrote: > This fixes the regression introduced by JDK-8038177 in which the > osName field should be initialized before it's accessed in the class > static initializer. > > https://bugs.openjdk.java.net/browse/JDK-8038451 > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8038451/webrev.00/ Easily done, moving it to the top looks okay to me. -Alan. From blackdrag at gmx.org Thu Mar 27 21:02:56 2014 From: blackdrag at gmx.org (Jochen Theodorou) Date: Thu, 27 Mar 2014 22:02:56 +0100 Subject: Implicit 'this' return for void methods In-Reply-To: References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> <53328D08.1000307@CoSoCo.de> <5334535D.7050402@gmx.org> Message-ID: <53349200.7030005@gmx.org> Am 27.03.2014 21:52, schrieb Eirik Lygre: [...] > The JavaBean specification, with it's "void setSomething()" functions > are fundamental to so many things Java that they will never go away > (good thing, too!).The suggested language change builds on top of that, > is beneficial to a large body of existing code and does not invalidate > any existing practices. > > It is, I think, a great example of bang for the buck -- low cost, high > return. No changes needed in the VM; everything can be done by the > compiler. Almost too sweet. Hmm... isn't it a problem if I change "void setSomething()" to "MyClass setSomething()". In example, is that still a valid setter in terms of the JavaBean Spec? I might be wrong, but afaik there are bean based tools out there, not recognizing setters like that. At least I remember having such cases in the past. If I am right, then there is quite a chance of invalidating working code. > I should have paid more attention to the dragon book, so that I could > have taken a shot at the compiler myself :-/ I think you won't need it for that kind of change. You don't change the grammar, or any first level rules. You would change the internal AST, or even the bytecode generation part for this. You need to know javac internals instead... bad enough imho bye blackdrag -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org From xueming.shen at oracle.com Thu Mar 27 21:48:57 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 27 Mar 2014 14:48:57 -0700 Subject: JDK-8038451: Incorrect initialization order of static fields in sun.nio.cs.ext.JISAutoDetect$Decoder In-Reply-To: <53348EE8.1060805@oracle.com> References: <53348EE8.1060805@oracle.com> Message-ID: <53349CC9.7080400@oracle.com> On 03/27/2014 01:49 PM, Mandy Chung wrote: > This fixes the regression introduced by JDK-8038177 in which the osName field should be initialized before it's accessed in the class static initializer. > > https://bugs.openjdk.java.net/browse/JDK-8038451 > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8038451/webrev.00/ > > Thanks > Mandy looks fine. From eirik.lygre at gmail.com Thu Mar 27 22:05:23 2014 From: eirik.lygre at gmail.com (Eirik Lygre) Date: Thu, 27 Mar 2014 23:05:23 +0100 Subject: Implicit 'this' return for void methods In-Reply-To: <53349200.7030005@gmx.org> References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> <53328D08.1000307@CoSoCo.de> <5334535D.7050402@gmx.org> <53349200.7030005@gmx.org> Message-ID: On Thu, Mar 27, 2014 at 10:02 PM, Jochen Theodorou wrote: > Am 27.03.2014 21:52, schrieb Eirik Lygre: > [...] > > The JavaBean specification, with it's "void setSomething()" functions >> are fundamental to so many things Java that they will never go away >> (good thing, too!).The suggested language change builds on top of that, >> is beneficial to a large body of existing code and does not invalidate >> any existing practices. >> >> Hmm... isn't it a problem if I change "void setSomething()" to "MyClass > setSomething()". In example, is that still a valid setter in terms of the > JavaBean Spec? I might be wrong, but afaik there are bean based tools out > there, not recognizing setters like that. At least I remember having such > cases in the past. If I am right, then there is quite a chance of > invalidating working code. In terms of the JavaBeans specification, the setters must be void. If you change the return type, it is no longer a JavaBeans setter, and many tools will not see it. However, the above mentioned suggestion does not require a change of the return type, so the bean methods and all their signatures will be 100% backwards compatible. With this suggested change, the only behavior that will change is that some code which used to not compile will start compiling, with a reasonable result. No code that used to compile will change. From Ulf.Zibis at CoSoCo.de Thu Mar 27 22:29:16 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 27 Mar 2014 23:29:16 +0100 Subject: Implicit 'this' return for void methods In-Reply-To: References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> <53328D08.1000307@CoSoCo.de> <5334535D.7050402@gmx.org> <53349200.7030005@gmx.org> Message-ID: <5334A63C.1010503@CoSoCo.de> Am 27.03.2014 23:05, schrieb Eirik Lygre: > With this suggested change, the only behavior that will change is that some code which used to not > compile will start compiling, with a reasonable result. No code that used to compile will change. Yes, this is one of the great advantages of this "simple" _language_ change proposal ! -Ulf From victor2 at ukr.net Fri Mar 28 04:57:08 2014 From: victor2 at ukr.net (Victor Polischuk) Date: Fri, 28 Mar 2014 06:57:08 +0200 Subject: Implicit 'this' return for void methods In-Reply-To: <5334A63C.1010503@CoSoCo.de> References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> <53328D08.1000307@CoSoCo.de> <5334535D.7050402@gmx.org> <53349200.7030005@gmx.org> <5334A63C.1010503@CoSoCo.de> Message-ID: <1395981008.345530629.yzzvig6g@frv39.fwdcdn.com> Ulf, I think that point leading style is something which can be easily mistreat. If we complicate the example: String mySub = myVeryLongNamedString.substring(.indexOf("C"),.indexOf("Q")); to something like: String mySub = myVeryLongNamedString.concat("BLAH").substring(.indexOf("C"),.indexOf("Q")); it is not 100% clear which object will be applied for ".indexOf" method, either (myVeryLongNamedString) or (myVeryLongNamedString + "BLAH"). Also I believe that the need of executing the instance methods to get parameter values for its another method is an API issue. Helpers like StringUtils from commons-lang resolve this particular case and many similar. Moreover, the helper correctly takes care of the situation when Q meets before C which means you would not use the feature like in above (even if it is implemented). However, I totally agree that the "chaining" feature should be done as a compiler time AST modification to allow using legacy APIs without recompilation and keep byte-code, existing APIs and various conventions untouched. --- Regards, Victor Polischuk --- Original message --- From: "Ulf Zibis" Date: 28 March 2014, 00:30:45 > > Am 27.03.2014 23:05, schrieb Eirik Lygre: > > With this suggested change, the only behavior that will change is that some code which used to not > > compile will start compiling, with a reasonable result. No code that used to compile will change. > > Yes, this is one of the great advantages of this "simple" _language_ change proposal ! > > -Ulf > > From eirik.lygre at gmail.com Fri Mar 28 08:46:22 2014 From: eirik.lygre at gmail.com (Eirik Lygre) Date: Fri, 28 Mar 2014 09:46:22 +0100 Subject: Implicit 'this' return for void methods In-Reply-To: <1395981008.345530629.yzzvig6g@frv39.fwdcdn.com> References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> <53328D08.1000307@CoSoCo.de> <5334535D.7050402@gmx.org> <53349200.7030005@gmx.org> <5334A63C.1010503@CoSoCo.de> <1395981008.345530629.yzzvig6g@frv39.fwdcdn.com> Message-ID: On Fri, Mar 28, 2014 at 5:57 AM, Victor Polischuk wrote: > Ulf, > > I think that point leading style is something which can be easily > mistreat. If we complicate the example: > > String mySub = > myVeryLongNamedString.substring(.indexOf("C"),.indexOf("Q")); > > to something like: > > String mySub = > myVeryLongNamedString.concat("BLAH").substring(.indexOf("C"),.indexOf("Q")); > > it is not 100% clear which object will be applied for ".indexOf" method, > either (myVeryLongNamedString) or (myVeryLongNamedString + "BLAH"). Also I > believe that the need of executing the instance methods to get parameter > values for its another method is an API issue. Helpers like StringUtils > from commons-lang resolve this particular case and many similar. Moreover, > the helper correctly takes care of the situation when Q meets before C > which means you would not use the feature like in above (even if it is > implemented).. I think the concept of "expressions starting with the period" is not going to happen, because the code is not easy enough to read (ref "Reading is more important than writing" in http://www.oracle.com/technetwork/articles/javase/jpl-proposals-140227.html), so I'm not going there. It may or may not be reasonable from a technical point of view, but my gut feeling says that it won't pass the process, so it is better to focus on the core feature. The core feature, to me, is "syntactic sugar to allow chaining of void methods". This feature should be easy to specify, understand, read and write: * myObject.setSomething(...).setSomething(...).setSomething(...) This feature will make the use of a large body of existing libraries much easier (all things JavaBeans), at a low cost. From chris.hegarty at oracle.com Fri Mar 28 09:14:59 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 28 Mar 2014 09:14:59 +0000 Subject: RFR: 8036030: Update JAX-WS RI integration to latest version In-Reply-To: <5319F223.4090106@oracle.com> References: <5319F223.4090106@oracle.com> Message-ID: <53353D93.4000607@oracle.com> Hi Miran, I have skimmed the webrev, and it looks ok to me. You seem to have some files with changes for 8029237, which is already integrated into jdk9/dev. Can you remove this, then I will sponsor the change for you. -Chris. On 07/03/14 16:21, Miroslav Kos wrote: > Hi, > there is a bulk update of JAX-B/WS from upstream projects - > webrev: http://cr.openjdk.java.net/~mkos/8036030/jaxws.00/ > more details in issue desc: > https://bugs.openjdk.java.net/browse/JDK-8036030 > > Thanks > Miran From vladimir.x.ivanov at oracle.com Fri Mar 28 09:29:29 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 28 Mar 2014 13:29:29 +0400 Subject: RFR(S) : 8038186 : [TESTBUG] improvements of test j.l.i.MethodHandles In-Reply-To: <5334802A.9050003@oracle.com> References: <533096A8.1020405@oracle.com> <8068D25C-AA39-4012-83BC-0A2F09309EF8@oracle.com> <53333CAD.8080309@oracle.com> <5334802A.9050003@oracle.com> Message-ID: <533540F9.2070900@oracle.com> Igor, thanks for improving the tests on method handles! > After an offline conversation w/ VladimirI, I've done several changes: > - placed all classes into one file (but I don't like it) You can convert TestCase & TestFactory to inner classes and move ThrowMode into TestCase since it's usage is confined to TestCase. > - changed package name > - extracted creating tests code from test execution code These changes look good. Other comments: - why don't you remove TestCase.assertEQ and enhance Asserts.assertEquals for arrays? - regarding CatchExceptionTest name: there's already TestCatchException test. Have you considered merging them into one test or removing TestCatchException, if your test already covers that cases? Best regards, Vladimir Ivanov PS: John mentioned recently that there's a convention for java/lang/invoke tests to be in JUnit format. I'm not sure it'll improve the code in any way (maybe TestNG will?). I hope John will express his opinion on this, if it's important. > > I hope the code's still quite readable and understandable. > > Also I've added array return type. > > http://cr.openjdk.java.net/~iignatyev/8038186/webrev.02/ > > Thanks, > Igor > > On 03/27/2014 12:46 AM, Igor Ignatyev wrote: >> Hi Chris, >> >>> This is very nice. Are there plans to do this for the other existing >>> tests as well? >> sure, but we didn't have enough time to do it in 8u20 timeframe. So I'd >> like to push these changes 1st, since we need this to cover 'Speedup >> catch exceptions'. Other tests will be rewrite later. I hope we'll have >> time in jdk 9 to refactor all tests in MethodHandles. >> >> Thanks, >> Igor >> >> On 03/27/2014 12:38 AM, Christian Thalinger wrote: >>> >>> On Mar 24, 2014, at 1:33 PM, Igor Ignatyev >>> wrote: >>> >>>> Hi all, >>>> >>>> Please review the patch: >>>> >>>> Problems: >>>> - MethodHandlesTest::testCatchException() doesn't provide enough >>>> testing of j.l.i.MethodHandles::catchException(). >>>> - MethodHandlesTest contains more than 3k lines, an auxiliary code >>>> together w/ a test code, many methods aren't connected w/ each other, >>>> etc. All this leads to that it is very very hard to understand, >>>> maintain. >>> >>> Yes, it is. >>> >>>> >>>> Fix: >>>> - the auxiliary code was moved to testlibray >>>> - the test code was moved to a separate subpackage >>> >>> This is very nice. Are there plans to do this for the other existing >>> tests as well? >>> >>>> - random signature is used for target and handler >>>> - added scenarios w/ different return types >>>> >>>> webrev: http://cr.openjdk.java.net/~iignatyev/8038186/webrev.01/ >>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8038186 >>>> -- >>>> Igor >>>> _______________________________________________ >>>> mlvm-dev mailing list >>>> mlvm-dev at openjdk.java.net >>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>> >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From fweimer at redhat.com Fri Mar 28 10:05:59 2014 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 28 Mar 2014 11:05:59 +0100 Subject: Implicit 'this' return for void methods In-Reply-To: <1395981008.345530629.yzzvig6g@frv39.fwdcdn.com> References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> <53328D08.1000307@CoSoCo.de> <5334535D.7050402@gmx.org> <53349200.7030005@gmx.org> <5334A63C.1010503@CoSoCo.de> <1395981008.345530629.yzzvig6g@frv39.fwdcdn.com> Message-ID: <53354987.5050701@redhat.com> On 03/28/2014 05:57 AM, Victor Polischuk wrote: > Ulf, > > I think that point leading style is something which can be easily mistreat. If we complicate the example: > > String mySub = myVeryLongNamedString.substring(.indexOf("C"),.indexOf("Q")); > > to something like: > > String mySub = myVeryLongNamedString.concat("BLAH").substring(.indexOf("C"),.indexOf("Q")); You can already write String mySub = apply(myVeryLongNamedString, (s) -> s.substring(s.indexOf("C"), s.indexOf("Q"))) with a helper function like this: public static R apply(T value, Function func) { return func.apply(value); } You don't even need to repeat the type. But the explicit version isn't too bad, either: String mySub; { String s = myVeryLongNamedString; mySub = s.substring(s.indexOf("C"), s.indexOf("Q")); } So I'm not sure if leading dot expressions are all that helpful. -- Florian Weimer / Red Hat Product Security Team From alexander.v.stepanov at oracle.com Fri Mar 28 10:58:25 2014 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Fri, 28 Mar 2014 14:58:25 +0400 Subject: [9] Review Request for 8038493: tidy warnings cleanup for java.sql Message-ID: <533555D1.2060900@oracle.com> Hello, Could you please review the fix for the following bug: https://bugs.openjdk.java.net/browse/JDK-8038493 Webrev corresponding: http://cr.openjdk.java.net/~yan/8038493/webrev.00/ Just a minor cleanup of javadoc to avoid tidy warnings; no other code affected. Thanks. Regards, Alexander From lance.andersen at oracle.com Fri Mar 28 11:16:04 2014 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Fri, 28 Mar 2014 07:16:04 -0400 Subject: [9] Review Request for 8038493: tidy warnings cleanup for java.sql In-Reply-To: <533555D1.2060900@oracle.com> References: <533555D1.2060900@oracle.com> Message-ID: <2BF075F0-C539-466D-A097-D37199C4936F@oracle.com> Looks fine 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 Sent from my iPad On Mar 28, 2014, at 6:58 AM, alexander stepanov wrote: > Hello, > > Could you please review the fix for the following bug: > https://bugs.openjdk.java.net/browse/JDK-8038493 > > Webrev corresponding: > http://cr.openjdk.java.net/~yan/8038493/webrev.00/ > > Just a minor cleanup of javadoc to avoid tidy warnings; no other code affected. > > Thanks. > > Regards, > Alexander From chris.hegarty at oracle.com Fri Mar 28 11:27:21 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 28 Mar 2014 11:27:21 +0000 Subject: [9] Review Request for 8038493: tidy warnings cleanup for java.sql In-Reply-To: <2BF075F0-C539-466D-A097-D37199C4936F@oracle.com> References: <533555D1.2060900@oracle.com> <2BF075F0-C539-466D-A097-D37199C4936F@oracle.com> Message-ID: <53355C99.30006@oracle.com> On 28/03/14 11:16, Lance @ Oracle wrote: > Looks fine Looks good to me too. -Chris. > > 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 > Sent from my iPad > > On Mar 28, 2014, at 6:58 AM, alexander stepanov wrote: > >> Hello, >> >> Could you please review the fix for the following bug: >> https://bugs.openjdk.java.net/browse/JDK-8038493 >> >> Webrev corresponding: >> http://cr.openjdk.java.net/~yan/8038493/webrev.00/ >> >> Just a minor cleanup of javadoc to avoid tidy warnings; no other code affected. >> >> Thanks. >> >> Regards, >> Alexander From igor.ignatyev at oracle.com Fri Mar 28 11:31:07 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 28 Mar 2014 15:31:07 +0400 Subject: RFR(S) : 8038186 : [TESTBUG] improvements of test j.l.i.MethodHandles In-Reply-To: <533540F9.2070900@oracle.com> References: <533096A8.1020405@oracle.com> <8068D25C-AA39-4012-83BC-0A2F09309EF8@oracle.com> <53333CAD.8080309@oracle.com> <5334802A.9050003@oracle.com> <533540F9.2070900@oracle.com> Message-ID: <53355D7B.8030408@oracle.com> Vladimir, thanks for review, please my comments inline. On 03/28/2014 01:29 PM, Vladimir Ivanov wrote: > Igor, thanks for improving the tests on method handles! > >> After an offline conversation w/ VladimirI, I've done several changes: >> - placed all classes into one file (but I don't like it) > You can convert TestCase & TestFactory to inner classes and move > ThrowMode into TestCase since it's usage is confined to TestCase. > I don't like using of inner classes, from my point of view, it makes code less readable. But if you insists, I can do it. >> - changed package name >> - extracted creating tests code from test execution code > These changes look good. > > Other comments: > - why don't you remove TestCase.assertEQ and enhance > Asserts.assertEquals for arrays? I'm not sure that this doesn't break the other tests which use 'Asserts.assertEquals', and since I want to push this patch to 8u20, I consider it's too risky to change now. I'll do it in my next improvements of MH tests in jdk9 TF. > - regarding CatchExceptionTest name: there's already > TestCatchException test. Have you considered merging them into one test > or removing TestCatchException, if your test already covers that cases? I didn't remove TestCatchException, since I'm not pretty sure that all cases are covered and don't have enough time to check it, also this test's a regression test which cover some particular test cases. I plan to add the test cases from TestCatchException to 'MANDATORY_TEST_CASES' in CatchExceptionTest and remove TestCatchException in jdk9 TF. > Best regards, > Vladimir Ivanov > > PS: John mentioned recently that there's a convention for > java/lang/invoke tests to be in JUnit format. I'm not sure it'll improve > the code in any way (maybe TestNG will?). I hope John will express his > opinion on this, if it's important. > >> >> I hope the code's still quite readable and understandable. >> >> Also I've added array return type. >> >> http://cr.openjdk.java.net/~iignatyev/8038186/webrev.02/ >> >> Thanks, >> Igor >> >> On 03/27/2014 12:46 AM, Igor Ignatyev wrote: >>> Hi Chris, >>> >>>> This is very nice. Are there plans to do this for the other existing >>>> tests as well? >>> sure, but we didn't have enough time to do it in 8u20 timeframe. So I'd >>> like to push these changes 1st, since we need this to cover 'Speedup >>> catch exceptions'. Other tests will be rewrite later. I hope we'll have >>> time in jdk 9 to refactor all tests in MethodHandles. >>> >>> Thanks, >>> Igor >>> >>> On 03/27/2014 12:38 AM, Christian Thalinger wrote: >>>> >>>> On Mar 24, 2014, at 1:33 PM, Igor Ignatyev >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> Please review the patch: >>>>> >>>>> Problems: >>>>> - MethodHandlesTest::testCatchException() doesn't provide enough >>>>> testing of j.l.i.MethodHandles::catchException(). >>>>> - MethodHandlesTest contains more than 3k lines, an auxiliary code >>>>> together w/ a test code, many methods aren't connected w/ each other, >>>>> etc. All this leads to that it is very very hard to understand, >>>>> maintain. >>>> >>>> Yes, it is. >>>> >>>>> >>>>> Fix: >>>>> - the auxiliary code was moved to testlibray >>>>> - the test code was moved to a separate subpackage >>>> >>>> This is very nice. Are there plans to do this for the other existing >>>> tests as well? >>>> >>>>> - random signature is used for target and handler >>>>> - added scenarios w/ different return types >>>>> >>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8038186/webrev.01/ >>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8038186 >>>>> -- >>>>> Igor >>>>> _______________________________________________ >>>>> mlvm-dev mailing list >>>>> mlvm-dev at openjdk.java.net >>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>> >>>> _______________________________________________ >>>> mlvm-dev mailing list >>>> mlvm-dev at openjdk.java.net >>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>> >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From lance.andersen at oracle.com Fri Mar 28 11:33:02 2014 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Fri, 28 Mar 2014 07:33:02 -0400 Subject: RFR (JAXP): 8035437: Xerces Update: xml/serialize/DOMSerializerImpl In-Reply-To: <533311E6.2090500@oracle.com> References: <533302DD.2090005@oracle.com> <155CED84-F9D2-4EF8-9AC2-18A7AA7C0E68@oracle.com> <95ECB6AF-B918-4812-92C8-6915A3EDE98D@oracle.com> <533311E6.2090500@oracle.com> Message-ID: With the change to stringbuilder I am ok with it 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 Sent from my iPad On Mar 26, 2014, at 1:44 PM, Aleksej Efimov wrote: > Lance, > The document implementation (DocumentImpl) returned by 'builder.newDocument()' should implement org.w3c.dom.Node and org.w3c.dom.Document interfaces, but shouldn't have the 'getXmlVersion' method (in Node, Document and DocumentImpl) - it's a main item required by Apache bug. So it means, that we need to substitute all three classes (Document,Node and DocumentImpl). The test should be executed with JDKs Node, Document, but DocumentImpl should be compiled against incorrect interfaces. I don't see, how I can implement it with jtreg keywords (the main problem is splitting the compilation of DocumentImpl (fake Node, Document) and the test run (only fake DocumentImpl). > > The only reason why StringBuffer is not used here - the process of how updates were moved from Xerces to JAXP: revision by revision. And I don't think that it should prevent us from replacing it with faster StringBuilder =). Will change it to StringBuilder. > > Thank you, > Aleksej > > On 03/26/2014 09:04 PM, Lance Andersen wrote: >> Any reason not to use StringBuilder in place of StringBuffer in XMLEntityManager.java >> >> other than the above and my question on the need of using run.sh, it is OK >> >> On Mar 26, 2014, at 12:54 PM, Lance Andersen wrote: >> >>> Hi Aleksej, >>> >>> Do you really need to use run.sh? If possible it would be better to try and avoid providing a script and use the jtreg keywords. >>> >>> Best >>> Lance >>> On Mar 26, 2014, at 12:39 PM, Aleksej Efimov wrote: >>> >>>> Hello, >>>> >>>> Can I ask for a review for the update of DOMSerializerImpl class [1] to the latest Apache Xerces implementation. >>>> The following changes were made: >>>> 1. The DOMSerializerImpl update: The Xerces class was used as a base [2]; the 476047 and 473125 revisions from Xerces was excluded (they will be resolved as a part of JDK-8035467 - move to Xalan serializer bug); the jaxp 632 revision was applied to new version of this class. >>>> 2. The DOMSerializerImpl.java file was reformated, because of not-good formatting in original file from Apache repo [2]. >>>> 3. Other changes related to the DOMSerializerImpl update were applied from Xerces repo to JDK(the full revisions list can be found in the JBS [1]). >>>> 4. All license headers were updated to the latest version of Apache header in modified files. >>>> 5. New regression test was added to reproduce a problem described in Apache bug XERCESJ-1007 [3]. >>>> >>>> Webrevs for these changes: >>>> http://cr.openjdk.java.net/~aefimov/8035437/webrev.00/jaxp >>>> http://cr.openjdk.java.net/~aefimov/8035437/webrev.00/jdk >>>> >>>> Testing: >>>> JCK tests (api/xsl api/xinclude api/javax_xml api/org_xml xml_schema): pass >>>> JTREG tests (javax/xml, jdk_other): pass >>>> >>>> Thank you, >>>> Aleksej >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-6339023 >>>> [2] http://svn.apache.org/viewvc/xerces/java/trunk/src/org/apache/xml/serialize/DOMSerializerImpl.java?revision=944789&view=markup >>>> [3] https://issues.apache.org/jira/browse/XERCESJ-1007 >>> >>> >>> >>> 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 >> >> >> >> 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 pavel.rappo at oracle.com Fri Mar 28 11:35:58 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 28 Mar 2014 11:35:58 +0000 Subject: RFR JDK-8037781: Remove sun.misc.Regexp* classes Message-ID: <3E564EE1-86DD-4CDE-B83F-BD7547E3FDFB@oracle.com> Hi everyone, could you please review my change for JDK-8037781: http://cr.openjdk.java.net/~chegar/8037781/webrev.00/ After JDK-8035158 was fixed we freed our hands to remove these 4 classes: 1. sun.misc.RegexpPool, 2. sun.misc.RegexpTarget, 3. sun.misc.Regexp, 4. sun.misc.REException The sole client class sun.net.spi.DefaultProxySelector relied on this private regex implementation for years. Now we broke this dependency and used public API instead: java.util.regex.* Thus those classes have no reasons to stay in jdk any more. Thanks -Pavel From Ulf.Zibis at CoSoCo.de Fri Mar 28 11:37:29 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Fri, 28 Mar 2014 12:37:29 +0100 Subject: Implicit 'this' return for void methods In-Reply-To: <53354987.5050701@redhat.com> References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> <53328D08.1000307@CoSoCo.de> <5334535D.7050402@gmx.org> <53349200.7030005@gmx.org> <5334A63C.1010503@CoSoCo.de> <1395981008.345530629.yzzvig6g@frv39.fwdcdn.com> <53354987.5050701@redhat.com> Message-ID: <53355EF9.9080605@CoSoCo.de> Am 28.03.2014 11:05, schrieb Florian Weimer: >> String mySub = myVeryLongNamedString.substring(.indexOf("C"),.indexOf("Q")); > > You can already write > > String mySub = apply(myVeryLongNamedString, > (s) -> s.substring(s.indexOf("C"), s.indexOf("Q"))) > > with a helper function like this: > > public static R apply(T value, Function func) { > return func.apply(value); > } > > > You don't even need to repeat the type. But the explicit version isn't too bad, either: > > String mySub; > { > String s = myVeryLongNamedString; > mySub = s.substring(s.indexOf("C"), s.indexOf("Q")); > } > > So I'm not sure if leading dot expressions are all that helpful. Hm, nice hacks, but don't you notice the difference in readability and total amount of code lines in comparison to my proposed one-liner? IMHO the more lines/characters a code has, the more effort is needed to (1) read it and (2) understand it's sense. BTW, our 2nd example wouldn't work as expression in for loop arguments. But what for do we discuss the "leading dot expressions" such exhaustive, if there still is no conviction to add the simple "chaining syntax" to the Java language at all? -Ulf From Alan.Bateman at oracle.com Fri Mar 28 11:42:02 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 28 Mar 2014 11:42:02 +0000 Subject: RFR JDK-8037781: Remove sun.misc.Regexp* classes In-Reply-To: <3E564EE1-86DD-4CDE-B83F-BD7547E3FDFB@oracle.com> References: <3E564EE1-86DD-4CDE-B83F-BD7547E3FDFB@oracle.com> Message-ID: <5335600A.50409@oracle.com> On 28/03/2014 11:35, Pavel Rappo wrote: > Hi everyone, > > could you please review my change for JDK-8037781: http://cr.openjdk.java.net/~chegar/8037781/webrev.00/ > > After JDK-8035158 was fixed we freed our hands to remove these 4 classes: > > 1. sun.misc.RegexpPool, > 2. sun.misc.RegexpTarget, > 3. sun.misc.Regexp, > 4. sun.misc.REException > > The sole client class sun.net.spi.DefaultProxySelector relied on this private regex implementation for years. Now we broke this dependency and used public API instead: java.util.regex.* Thus those classes have no reasons to stay in jdk any more. > It's good to get rid of these, nothing out of the JDK should be using these classes directly (and they have no reason to it). So thanks for doing this. -Alan From volker.simonis at gmail.com Fri Mar 28 13:44:32 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 28 Mar 2014 14:44:32 +0100 Subject: RFR(S): 8038233 : Fix unsafe strcpy in Java_sun_tools_attach_{Aix, Bsd, Linux}VirtualMachine_connect() In-Reply-To: <53346E6D.20900@oracle.com> References: <53346E6D.20900@oracle.com> Message-ID: Hi Alan, thanks for the review. On Thu, Mar 27, 2014 at 7:31 PM, Alan Bateman wrote: > On 27/03/2014 18:08, Volker Simonis wrote: >> >> Hi, >> >> a security audit for the PPC64/AIX port revealed an unsecure useage of >> 'strcpy' in Java_sun_tools_attach_AixVirtualMachine_connect(). Because >> the same coding is also used in the Linux and BSD implementations, the >> following change fixes them all together: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8038233/ >> https://bugs.openjdk.java.net/browse/JDK-8038233 >> >> Compiled and tested (with the com/sun/jdi, com/sun/tools/attach, >> com/sun/management and sun/management JTreg tests) on Linux, MacOS X >> and AIX. >> >> Please notice that this fix is also intended for backporting tu 8u. >> > As we now have 3 implementations using socket pairs then there might be an > opportunity to consolidate the implementations, not for this patch of > course. > I agree, there's a lot of common code in the three implementations. > Your changes looks okay and it's good to memset the sockaddr_un structure. > As regards the issue is a concern or not then it's important to note thaht > the Attach API is in tools.jar, it's not in a JRE build. Also an attach > requires a Permission check if running with a security manager and I likely > vert rare for tools to do this. Also to cause a problem then it would > require the temporary directory to be unusually long. > You're right. I was initially concerned a little more because the Linux implementation also uses the process' current working directory. But that's just for the attach file, not for the actual sockets - so no problem. Regards, Volker > -Alan. From dmitry.samersoff at oracle.com Fri Mar 28 13:46:26 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 28 Mar 2014 17:46:26 +0400 Subject: RFR(S): 8038233 : Fix unsafe strcpy in Java_sun_tools_attach_{Aix, Bsd, Linux}VirtualMachine_connect() In-Reply-To: References: Message-ID: <53357D32.9020806@oracle.com> Volker, I think we should check the length of passed filename and throw an exception if filename is too long. Otherwise we can end up opening wrong file with possibly not expected permissions. -Dmitry On 2014-03-27 22:08, Volker Simonis wrote: > Hi, > > a security audit for the PPC64/AIX port revealed an unsecure useage of > 'strcpy' in Java_sun_tools_attach_AixVirtualMachine_connect(). Because > the same coding is also used in the Linux and BSD implementations, the > following change fixes them all together: > > http://cr.openjdk.java.net/~simonis/webrevs/8038233/ > https://bugs.openjdk.java.net/browse/JDK-8038233 > > Compiled and tested (with the com/sun/jdi, com/sun/tools/attach, > com/sun/management and sun/management JTreg tests) on Linux, MacOS X > and AIX. > > Please notice that this fix is also intended for backporting tu 8u. > > Thank you and best regards, > Volker > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From chris.hegarty at oracle.com Fri Mar 28 14:14:14 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 28 Mar 2014 14:14:14 +0000 Subject: RFR JDK-8037781: Remove sun.misc.Regexp* classes In-Reply-To: <3E564EE1-86DD-4CDE-B83F-BD7547E3FDFB@oracle.com> References: <3E564EE1-86DD-4CDE-B83F-BD7547E3FDFB@oracle.com> Message-ID: <533583B6.1050402@oracle.com> This looks good to me also. Thanks Pavel. I can sponsor this change for you. -Chris. On 28/03/14 11:35, Pavel Rappo wrote: > Hi everyone, > > could you please review my change for JDK-8037781: http://cr.openjdk.java.net/~chegar/8037781/webrev.00/ > > After JDK-8035158 was fixed we freed our hands to remove these 4 classes: > > 1. sun.misc.RegexpPool, > 2. sun.misc.RegexpTarget, > 3. sun.misc.Regexp, > 4. sun.misc.REException > > The sole client class sun.net.spi.DefaultProxySelector relied on this private regex implementation for years. Now we broke this dependency and used public API instead: java.util.regex.* Thus those classes have no reasons to stay in jdk any more. > > Thanks > -Pavel > From volker.simonis at gmail.com Fri Mar 28 15:41:27 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 28 Mar 2014 16:41:27 +0100 Subject: RFR(S): 8038233 : Fix unsafe strcpy in Java_sun_tools_attach_{Aix, Bsd, Linux}VirtualMachine_connect() In-Reply-To: <53357D32.9020806@oracle.com> References: <53357D32.9020806@oracle.com> Message-ID: Hi Dimitry, sorry, but I already pushed the change. However I don't think this is a big problem because: - if the file does not exist, connect will fail with "No such file or directory" - if the file exists by chance (but is not a socket) connect will fail with "Connection refused" - if the file exists and is a socket but from another user or with wrong permissions, connect will fail with "Connection refused" The only problematic case would be if the file is a listening socket of another process with appropriate permissions which should be extremely unlikely. But in theory you're right - we may want to fix that as well. Regards, Volker On Fri, Mar 28, 2014 at 2:46 PM, Dmitry Samersoff wrote: > Volker, > > I think we should check the length of passed filename and > throw an exception if filename is too long. > > Otherwise we can end up opening wrong file with possibly not expected > permissions. > > -Dmitry > > On 2014-03-27 22:08, Volker Simonis wrote: >> Hi, >> >> a security audit for the PPC64/AIX port revealed an unsecure useage of >> 'strcpy' in Java_sun_tools_attach_AixVirtualMachine_connect(). Because >> the same coding is also used in the Linux and BSD implementations, the >> following change fixes them all together: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8038233/ >> https://bugs.openjdk.java.net/browse/JDK-8038233 >> >> Compiled and tested (with the com/sun/jdi, com/sun/tools/attach, >> com/sun/management and sun/management JTreg tests) on Linux, MacOS X >> and AIX. >> >> Please notice that this fix is also intended for backporting tu 8u. >> >> Thank you and best regards, >> Volker >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From develop4lasu at gmail.com Fri Mar 28 15:52:30 2014 From: develop4lasu at gmail.com (=?UTF-8?Q?Marek_Kozie=C5=82?=) Date: Fri, 28 Mar 2014 16:52:30 +0100 Subject: Implicit 'this' return for void methods Message-ID: Hi, I really do not know why some proposals are restored back from the grave, without answering for questions that was already made: http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-December/000382.html 2014-03-28 12:37 GMT+01:00 Ulf Zibis : > > Am 28.03.2014 11:05, schrieb Florian Weimer: >>> >>> String mySub = >>> myVeryLongNamedString.substring(.indexOf("C"),.indexOf("Q")); >> >> >> You can already write >> >> String mySub = apply(myVeryLongNamedString, >> (s) -> s.substring(s.indexOf("C"), s.indexOf("Q"))) >> >> with a helper function like this: >> >> public static R apply(T value, Function func) { >> return func.apply(value); >> } >> >> >> You don't even need to repeat the type. But the explicit version isn't >> too bad, either: >> >> String mySub; >> { >> String s = myVeryLongNamedString; >> mySub = s.substring(s.indexOf("C"), s.indexOf("Q")); >> } >> >> So I'm not sure if leading dot expressions are all that helpful. > > > Hm, nice hacks, but don't you notice the difference in readability and total > amount of code lines in comparison to my proposed one-liner? > IMHO the more lines/characters a code has, the more effort is needed to (1) > read it and (2) understand it's sense. > > BTW, our 2nd example wouldn't work as expression in for loop arguments. > > But what for do we discuss the "leading dot expressions" such exhaustive, if > there still is no conviction to add the simple "chaining syntax" to the Java > language at all? > > -Ulf > -- Pozdrawiam Marek Kozie? ( Lasu ) http://na-chlodno.blogspot.com/ http://lasu2string.blogspot.com/ From igor.ignatyev at oracle.com Fri Mar 28 16:04:53 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 28 Mar 2014 20:04:53 +0400 Subject: RFR(S) : 8038186 : [TESTBUG] improvements of test j.l.i.MethodHandles In-Reply-To: <53355D7B.8030408@oracle.com> References: <533096A8.1020405@oracle.com> <8068D25C-AA39-4012-83BC-0A2F09309EF8@oracle.com> <53333CAD.8080309@oracle.com> <5334802A.9050003@oracle.com> <533540F9.2070900@oracle.com> <53355D7B.8030408@oracle.com> Message-ID: <53359DA5.6010503@oracle.com> Vladimir, as we'd arranged, I moved ThrowMode into TestCase and give my word that I'll > remove TestCase.assertEQ and enhance Asserts.assertEquals for arrays > add the test cases from TestCatchException to 'MANDATORY_TEST_CASES' in CatchExceptionTest and remove TestCatchException in JDK9 TF. updated webrev: http://cr.openjdk.java.net/~iignatyev/8038186/webrev.03/ Thanks, Igor On 03/28/2014 03:31 PM, Igor Ignatyev wrote: > Vladimir, thanks for review, please my comments inline. > > On 03/28/2014 01:29 PM, Vladimir Ivanov wrote: >> Igor, thanks for improving the tests on method handles! >> >>> After an offline conversation w/ VladimirI, I've done several changes: >>> - placed all classes into one file (but I don't like it) >> You can convert TestCase & TestFactory to inner classes and move >> ThrowMode into TestCase since it's usage is confined to TestCase. >> > I don't like using of inner classes, from my point of view, it makes > code less readable. But if you insists, I can do it. > >>> - changed package name >>> - extracted creating tests code from test execution code >> These changes look good. >> >> Other comments: >> - why don't you remove TestCase.assertEQ and enhance >> Asserts.assertEquals for arrays? > I'm not sure that this doesn't break the other tests which use > 'Asserts.assertEquals', and since I want to push this patch to 8u20, I > consider it's too risky to change now. > > I'll do it in my next improvements of MH tests in jdk9 TF. > >> - regarding CatchExceptionTest name: there's already >> TestCatchException test. Have you considered merging them into one test >> or removing TestCatchException, if your test already covers that cases? > I didn't remove TestCatchException, since I'm not pretty sure that all > cases are covered and don't have enough time to check it, also this > test's a regression test which cover some particular test cases. > > I plan to add the test cases from TestCatchException to > 'MANDATORY_TEST_CASES' in CatchExceptionTest and remove > TestCatchException in jdk9 TF. > >> Best regards, >> Vladimir Ivanov >> >> PS: John mentioned recently that there's a convention for >> java/lang/invoke tests to be in JUnit format. I'm not sure it'll improve >> the code in any way (maybe TestNG will?). I hope John will express his >> opinion on this, if it's important. >> >>> >>> I hope the code's still quite readable and understandable. >>> >>> Also I've added array return type. >>> >>> http://cr.openjdk.java.net/~iignatyev/8038186/webrev.02/ >>> >>> Thanks, >>> Igor >>> >>> On 03/27/2014 12:46 AM, Igor Ignatyev wrote: >>>> Hi Chris, >>>> >>>>> This is very nice. Are there plans to do this for the other existing >>>>> tests as well? >>>> sure, but we didn't have enough time to do it in 8u20 timeframe. So I'd >>>> like to push these changes 1st, since we need this to cover 'Speedup >>>> catch exceptions'. Other tests will be rewrite later. I hope we'll have >>>> time in jdk 9 to refactor all tests in MethodHandles. >>>> >>>> Thanks, >>>> Igor >>>> >>>> On 03/27/2014 12:38 AM, Christian Thalinger wrote: >>>>> >>>>> On Mar 24, 2014, at 1:33 PM, Igor Ignatyev >>>>> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> Please review the patch: >>>>>> >>>>>> Problems: >>>>>> - MethodHandlesTest::testCatchException() doesn't provide enough >>>>>> testing of j.l.i.MethodHandles::catchException(). >>>>>> - MethodHandlesTest contains more than 3k lines, an auxiliary code >>>>>> together w/ a test code, many methods aren't connected w/ each other, >>>>>> etc. All this leads to that it is very very hard to understand, >>>>>> maintain. >>>>> >>>>> Yes, it is. >>>>> >>>>>> >>>>>> Fix: >>>>>> - the auxiliary code was moved to testlibray >>>>>> - the test code was moved to a separate subpackage >>>>> >>>>> This is very nice. Are there plans to do this for the other existing >>>>> tests as well? >>>>> >>>>>> - random signature is used for target and handler >>>>>> - added scenarios w/ different return types >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8038186/webrev.01/ >>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8038186 >>>>>> -- >>>>>> Igor >>>>>> _______________________________________________ >>>>>> mlvm-dev mailing list >>>>>> mlvm-dev at openjdk.java.net >>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>> >>>>> _______________________________________________ >>>>> mlvm-dev mailing list >>>>> mlvm-dev at openjdk.java.net >>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>> >>>> _______________________________________________ >>>> mlvm-dev mailing list >>>> mlvm-dev at openjdk.java.net >>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > _______________________________________________ > 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 Mar 28 16:14:29 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 28 Mar 2014 20:14:29 +0400 Subject: RFR(S) : 8038186 : [TESTBUG] improvements of test j.l.i.MethodHandles In-Reply-To: <53359DA5.6010503@oracle.com> References: <533096A8.1020405@oracle.com> <8068D25C-AA39-4012-83BC-0A2F09309EF8@oracle.com> <53333CAD.8080309@oracle.com> <5334802A.9050003@oracle.com> <533540F9.2070900@oracle.com> <53355D7B.8030408@oracle.com> <53359DA5.6010503@oracle.com> Message-ID: <53359FE5.2070309@oracle.com> Looks good to me. Best regards, Vladimir Ivanov On 3/28/14 8:04 PM, Igor Ignatyev wrote: > Vladimir, > > as we'd arranged, I moved ThrowMode into TestCase and give my word that > I'll >> remove TestCase.assertEQ and enhance Asserts.assertEquals for arrays >> add the test cases from TestCatchException to 'MANDATORY_TEST_CASES' >> in CatchExceptionTest and remove TestCatchException > in JDK9 TF. > > updated webrev: http://cr.openjdk.java.net/~iignatyev/8038186/webrev.03/ > > Thanks, > Igor > > On 03/28/2014 03:31 PM, Igor Ignatyev wrote: >> Vladimir, thanks for review, please my comments inline. >> >> On 03/28/2014 01:29 PM, Vladimir Ivanov wrote: >>> Igor, thanks for improving the tests on method handles! >>> >>>> After an offline conversation w/ VladimirI, I've done several changes: >>>> - placed all classes into one file (but I don't like it) >>> You can convert TestCase & TestFactory to inner classes and move >>> ThrowMode into TestCase since it's usage is confined to TestCase. >>> >> I don't like using of inner classes, from my point of view, it makes >> code less readable. But if you insists, I can do it. >> >>>> - changed package name >>>> - extracted creating tests code from test execution code >>> These changes look good. >>> >>> Other comments: >>> - why don't you remove TestCase.assertEQ and enhance >>> Asserts.assertEquals for arrays? >> I'm not sure that this doesn't break the other tests which use >> 'Asserts.assertEquals', and since I want to push this patch to 8u20, I >> consider it's too risky to change now. >> >> I'll do it in my next improvements of MH tests in jdk9 TF. >> >>> - regarding CatchExceptionTest name: there's already >>> TestCatchException test. Have you considered merging them into one test >>> or removing TestCatchException, if your test already covers that cases? >> I didn't remove TestCatchException, since I'm not pretty sure that all >> cases are covered and don't have enough time to check it, also this >> test's a regression test which cover some particular test cases. >> >> I plan to add the test cases from TestCatchException to >> 'MANDATORY_TEST_CASES' in CatchExceptionTest and remove >> TestCatchException in jdk9 TF. >> >>> Best regards, >>> Vladimir Ivanov >>> >>> PS: John mentioned recently that there's a convention for >>> java/lang/invoke tests to be in JUnit format. I'm not sure it'll improve >>> the code in any way (maybe TestNG will?). I hope John will express his >>> opinion on this, if it's important. >>> >>>> >>>> I hope the code's still quite readable and understandable. >>>> >>>> Also I've added array return type. >>>> >>>> http://cr.openjdk.java.net/~iignatyev/8038186/webrev.02/ >>>> >>>> Thanks, >>>> Igor >>>> >>>> On 03/27/2014 12:46 AM, Igor Ignatyev wrote: >>>>> Hi Chris, >>>>> >>>>>> This is very nice. Are there plans to do this for the other existing >>>>>> tests as well? >>>>> sure, but we didn't have enough time to do it in 8u20 timeframe. So >>>>> I'd >>>>> like to push these changes 1st, since we need this to cover 'Speedup >>>>> catch exceptions'. Other tests will be rewrite later. I hope we'll >>>>> have >>>>> time in jdk 9 to refactor all tests in MethodHandles. >>>>> >>>>> Thanks, >>>>> Igor >>>>> >>>>> On 03/27/2014 12:38 AM, Christian Thalinger wrote: >>>>>> >>>>>> On Mar 24, 2014, at 1:33 PM, Igor Ignatyev >>>>>> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Please review the patch: >>>>>>> >>>>>>> Problems: >>>>>>> - MethodHandlesTest::testCatchException() doesn't provide enough >>>>>>> testing of j.l.i.MethodHandles::catchException(). >>>>>>> - MethodHandlesTest contains more than 3k lines, an auxiliary code >>>>>>> together w/ a test code, many methods aren't connected w/ each >>>>>>> other, >>>>>>> etc. All this leads to that it is very very hard to understand, >>>>>>> maintain. >>>>>> >>>>>> Yes, it is. >>>>>> >>>>>>> >>>>>>> Fix: >>>>>>> - the auxiliary code was moved to testlibray >>>>>>> - the test code was moved to a separate subpackage >>>>>> >>>>>> This is very nice. Are there plans to do this for the other existing >>>>>> tests as well? >>>>>> >>>>>>> - random signature is used for target and handler >>>>>>> - added scenarios w/ different return types >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8038186/webrev.01/ >>>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8038186 >>>>>>> -- >>>>>>> Igor >>>>>>> _______________________________________________ >>>>>>> mlvm-dev mailing list >>>>>>> mlvm-dev at openjdk.java.net >>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>>> >>>>>> _______________________________________________ >>>>>> mlvm-dev mailing list >>>>>> mlvm-dev at openjdk.java.net >>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>>> >>>>> _______________________________________________ >>>>> mlvm-dev mailing list >>>>> mlvm-dev at openjdk.java.net >>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>> _______________________________________________ >>>> mlvm-dev mailing list >>>> mlvm-dev at openjdk.java.net >>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From miroslav.kos at oracle.com Fri Mar 28 16:43:17 2014 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Fri, 28 Mar 2014 17:43:17 +0100 Subject: RFR: 8036030: Update JAX-WS RI integration to latest version In-Reply-To: <53353D93.4000607@oracle.com> References: <5319F223.4090106@oracle.com> <53353D93.4000607@oracle.com> Message-ID: <5335A6A5.9040405@oracle.com> Hi Chris, I regenerated webrev against current hg tip - the copyright changes should be ok now. patch file is attached, the new webrev is uploading just now: http://cr.openjdk.java.net/~mkos/8036030/jaxws.01/ JBS: https://bugs.openjdk.java.net/browse/JDK-8036030 Let me know if it is ok now. Thanks Miran On 28/03/14 10:14, Chris Hegarty wrote: > Hi Miran, > > I have skimmed the webrev, and it looks ok to me. > > You seem to have some files with changes for 8029237, which is already > integrated into jdk9/dev. Can you remove this, then I will sponsor the > change for you. > > -Chris. > > On 07/03/14 16:21, Miroslav Kos wrote: >> Hi, >> there is a bulk update of JAX-B/WS from upstream projects - >> webrev: http://cr.openjdk.java.net/~mkos/8036030/jaxws.00/ >> more details in issue desc: >> https://bugs.openjdk.java.net/browse/JDK-8036030 >> >> Thanks >> Miran From Sergey.Bylokhov at oracle.com Fri Mar 28 19:23:58 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 28 Mar 2014 23:23:58 +0400 Subject: [9] Review request: new macro for conversion to jboolean In-Reply-To: <533012D4.6030708@oracle.com> References: <53270E65.4070001@oracle.com> <53273F9A.3080403@oracle.com> <5329E3B7.7000000@oracle.com> <5329F8A4.6030908@oracle.com> <5329F93A.2010205@oracle.com> <5329F91E.4050703@oracle.com> <532A2B8E.9040707@oracle.com> <532C5658.6050601@oracle.com> <532C592E.1070205@oracle.com> <532F239D.2030203@oracle.com> <533012D4.6030708@oracle.com> Message-ID: <5335CC4E.1050407@oracle.com> On 3/24/14 3:11 PM, Anthony Petrov wrote: > How does IS_JNI_TRUE sound? It looks good. If nobody objects, the final version will be: #define IS_NULL(obj) ((obj) == NULL) #define JNU_IsNull(env,obj) ((obj) == NULL) +#define IS_JNI_TRUE(obj) ((obj) ? JNI_TRUE : JNI_FALSE) without additional cast. > -- > best regards, > Anthony > > On 3/23/2014 10:10 PM, Alan Bateman wrote: >> On 21/03/2014 15:22, Sergey Bylokhov wrote: >>> On 3/21/14 7:10 PM, roger riggs wrote: >>>> The macro would just as useful (if I understand the cases) without >>>> the cast. >>>> >>>> How useful is a simple definition as: >>>> >>>> #define IS_TRUE(obj) ((obj) ? JNI_TRUE : JNI_FALSE) >>>> >>>> then it would look ok to see these in sources: >>>> >>>> return IS_TRUE(obj); >>>> >>>> if (IS_TRUE(obj)) {....} >>>> >>>> jboolean ret = IS_TRUE(obj); >>>> >>>> The general purpose usage matches the general C conventions for >>>> true and false and match the JNI semantics. >>> Actually that was my initial suggestion(name and usage). >> I think the concern with IS_TRUE is that it's not obvious that it's a >> jboolean. Also just the potential for it to easily collide with a macro >> that casts to bool or (or Windows's BOOL). I can't tell from the JNI >> spec if JNI_FALSE/JNI_TRUE are guaranteed to be defined as 0/1 but even >> if they are then I guess there is still a concern that a jboolean is >> defined as an unsigned 8 bits whereas a bool might not (and a Windows's >> BOOL is an int I think). So if a macro is really needed then I think it >> will need another name. I thought MIke's original proposal for >> JNU_TO_JBOOLEAN wasn't too bad. I see Mike's mail about adding the cases >> to the definitions but that isn't going to help with the cases that I >> think you are running into where you need to go from Window's BOOL to >> jboolean. >> >> -Alan. -- Best regards, Sergey. From stevenschlansker at gmail.com Sat Mar 29 04:48:04 2014 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Fri, 28 Mar 2014 23:48:04 -0500 Subject: Implicit 'this' return for void methods In-Reply-To: References: Message-ID: <0EFE68B5-0F74-4D0B-971F-FDDD05C00981@gmail.com> On Mar 28, 2014, at 10:52 AM, Marek Kozie? wrote: > Hi, > I really do not know why some proposals are restored back from the > grave, without answering for questions that was already made: > http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-December/000382.html > > Problem lay on interfaces/classes that already exists. > 'void' have more than one meaning now time: > 1st: there is no need to return anything. Sure, but in this case it seems harmless to allow chaining. In fact that is the entire point of the proposal. Is there a specific counterpoint where chaining (when used tastefully) is harmful? I do not think ?but some people might misuse it? is a strong enough counter; you could nix almost any useful feature by that argument. > 2nd: creator wanted to prevent from chaining - to force one line-one > call formatting. Why should the creator choose whether I can chain void methods or not? I am writing the code that is using your library ? it is up to me to choose whether chaining methods increases or decreases readability. At the end of the day if the developer does not have good taste towards readability, there is little the language can do to save him/her. The number of cases that this dramatically increases readability are well described. A single concrete counterexample would help. > 3rd: space for future return type was left. You can?t (shouldn?t) do this. Changing method return types is a breaking change and will invalidate previously compiled code. So this is broken already anyway. However, it is true that this elevates a binary incompatibility to a source incompatibility. > 2014-03-28 12:37 GMT+01:00 Ulf Zibis : >> >> Am 28.03.2014 11:05, schrieb Florian Weimer: >>>> >>>> String mySub = >>>> myVeryLongNamedString.substring(.indexOf("C"),.indexOf("Q")); >>> >>> >>> You can already write >>> >>> String mySub = apply(myVeryLongNamedString, >>> (s) -> s.substring(s.indexOf("C"), s.indexOf("Q"))) >>> >>> with a helper function like this: >>> >>> public static R apply(T value, Function func) { >>> return func.apply(value); >>> } >>> >>> >>> You don't even need to repeat the type. But the explicit version isn't >>> too bad, either: >>> >>> String mySub; >>> { >>> String s = myVeryLongNamedString; >>> mySub = s.substring(s.indexOf("C"), s.indexOf("Q")); >>> } >>> >>> So I'm not sure if leading dot expressions are all that helpful. >> >> >> Hm, nice hacks, but don't you notice the difference in readability and total >> amount of code lines in comparison to my proposed one-liner? >> IMHO the more lines/characters a code has, the more effort is needed to (1) >> read it and (2) understand it's sense. >> >> BTW, our 2nd example wouldn't work as expression in for loop arguments. >> >> But what for do we discuss the "leading dot expressions" such exhaustive, if >> there still is no conviction to add the simple "chaining syntax" to the Java >> language at all? >> >> -Ulf >> > > > > -- > Pozdrawiam > Marek Kozie? ( Lasu ) > > http://na-chlodno.blogspot.com/ > http://lasu2string.blogspot.com/ From igor.ignatyev at oracle.com Sat Mar 29 08:27:15 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Sat, 29 Mar 2014 12:27:15 +0400 Subject: RFR(S) : 8038186 : [TESTBUG] improvements of test j.l.i.MethodHandles In-Reply-To: <663BF01A-E71B-4B01-94F2-EF98A4F2E96F@oracle.com> References: <533096A8.1020405@oracle.com> <8068D25C-AA39-4012-83BC-0A2F09309EF8@oracle.com> <53333CAD.8080309@oracle.com> <5334802A.9050003@oracle.com> <533540F9.2070900@oracle.com> <53355D7B.8030408@oracle.com> <53359DA5.6010503@oracle.com> <663BF01A-E71B-4B01-94F2-EF98A4F2E96F@oracle.com> Message-ID: <533683E3.3080805@oracle.com> Igor, Thanks for review. > Should be ?dropped?. fixed > But more comments would be appreciated. It?s huge and really hard to understand. sure, I'll add them during future improvements. Igor On 03/29/2014 05:07 AM, Igor Veresov wrote: > Typo in CatchExceptionTest.java: > 66 private int droped; > > Should be ?dropped?. > > Otherwise seems ok... But more comments would be appreciated. It?s huge and really hard to understand. > > igor > > > On Mar 28, 2014, at 9:04 AM, Igor Ignatyev wrote: > >> Vladimir, >> >> as we'd arranged, I moved ThrowMode into TestCase and give my word that I'll >>> remove TestCase.assertEQ and enhance Asserts.assertEquals for arrays >>> add the test cases from TestCatchException to 'MANDATORY_TEST_CASES' in CatchExceptionTest and remove TestCatchException >> in JDK9 TF. >> >> updated webrev: http://cr.openjdk.java.net/~iignatyev/8038186/webrev.03/ >> >> Thanks, >> Igor >> >> On 03/28/2014 03:31 PM, Igor Ignatyev wrote: >>> Vladimir, thanks for review, please my comments inline. >>> >>> On 03/28/2014 01:29 PM, Vladimir Ivanov wrote: >>>> Igor, thanks for improving the tests on method handles! >>>> >>>>> After an offline conversation w/ VladimirI, I've done several changes: >>>>> - placed all classes into one file (but I don't like it) >>>> You can convert TestCase & TestFactory to inner classes and move >>>> ThrowMode into TestCase since it's usage is confined to TestCase. >>>> >>> I don't like using of inner classes, from my point of view, it makes >>> code less readable. But if you insists, I can do it. >>> >>>>> - changed package name >>>>> - extracted creating tests code from test execution code >>>> These changes look good. >>>> >>>> Other comments: >>>> - why don't you remove TestCase.assertEQ and enhance >>>> Asserts.assertEquals for arrays? >>> I'm not sure that this doesn't break the other tests which use >>> 'Asserts.assertEquals', and since I want to push this patch to 8u20, I >>> consider it's too risky to change now. >>> >>> I'll do it in my next improvements of MH tests in jdk9 TF. >>> >>>> - regarding CatchExceptionTest name: there's already >>>> TestCatchException test. Have you considered merging them into one test >>>> or removing TestCatchException, if your test already covers that cases? >>> I didn't remove TestCatchException, since I'm not pretty sure that all >>> cases are covered and don't have enough time to check it, also this >>> test's a regression test which cover some particular test cases. >>> >>> I plan to add the test cases from TestCatchException to >>> 'MANDATORY_TEST_CASES' in CatchExceptionTest and remove >>> TestCatchException in jdk9 TF. >>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> PS: John mentioned recently that there's a convention for >>>> java/lang/invoke tests to be in JUnit format. I'm not sure it'll improve >>>> the code in any way (maybe TestNG will?). I hope John will express his >>>> opinion on this, if it's important. >>>> >>>>> >>>>> I hope the code's still quite readable and understandable. >>>>> >>>>> Also I've added array return type. >>>>> >>>>> http://cr.openjdk.java.net/~iignatyev/8038186/webrev.02/ >>>>> >>>>> Thanks, >>>>> Igor >>>>> >>>>> On 03/27/2014 12:46 AM, Igor Ignatyev wrote: >>>>>> Hi Chris, >>>>>> >>>>>>> This is very nice. Are there plans to do this for the other existing >>>>>>> tests as well? >>>>>> sure, but we didn't have enough time to do it in 8u20 timeframe. So I'd >>>>>> like to push these changes 1st, since we need this to cover 'Speedup >>>>>> catch exceptions'. Other tests will be rewrite later. I hope we'll have >>>>>> time in jdk 9 to refactor all tests in MethodHandles. >>>>>> >>>>>> Thanks, >>>>>> Igor >>>>>> >>>>>> On 03/27/2014 12:38 AM, Christian Thalinger wrote: >>>>>>> >>>>>>> On Mar 24, 2014, at 1:33 PM, Igor Ignatyev >>>>>>> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Please review the patch: >>>>>>>> >>>>>>>> Problems: >>>>>>>> - MethodHandlesTest::testCatchException() doesn't provide enough >>>>>>>> testing of j.l.i.MethodHandles::catchException(). >>>>>>>> - MethodHandlesTest contains more than 3k lines, an auxiliary code >>>>>>>> together w/ a test code, many methods aren't connected w/ each other, >>>>>>>> etc. All this leads to that it is very very hard to understand, >>>>>>>> maintain. >>>>>>> >>>>>>> Yes, it is. >>>>>>> >>>>>>>> >>>>>>>> Fix: >>>>>>>> - the auxiliary code was moved to testlibray >>>>>>>> - the test code was moved to a separate subpackage >>>>>>> >>>>>>> This is very nice. Are there plans to do this for the other existing >>>>>>> tests as well? >>>>>>> >>>>>>>> - random signature is used for target and handler >>>>>>>> - added scenarios w/ different return types >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8038186/webrev.01/ >>>>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8038186 >>>>>>>> -- >>>>>>>> Igor >>>>>>>> _______________________________________________ >>>>>>>> mlvm-dev mailing list >>>>>>>> mlvm-dev at openjdk.java.net >>>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>>>> >>>>>>> _______________________________________________ >>>>>>> mlvm-dev mailing list >>>>>>> mlvm-dev at openjdk.java.net >>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>>>> >>>>>> _______________________________________________ >>>>>> mlvm-dev mailing list >>>>>> mlvm-dev at openjdk.java.net >>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>> _______________________________________________ >>>>> mlvm-dev mailing list >>>>> mlvm-dev at openjdk.java.net >>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>> _______________________________________________ >>>> mlvm-dev mailing list >>>> mlvm-dev at openjdk.java.net >>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From roger.riggs at oracle.com Sat Mar 29 15:52:40 2014 From: roger.riggs at oracle.com (roger riggs) Date: Sat, 29 Mar 2014 11:52:40 -0400 Subject: [9] Review request: new macro for conversion to jboolean In-Reply-To: <5335CC4E.1050407@oracle.com> References: <53270E65.4070001@oracle.com> <53273F9A.3080403@oracle.com> <5329E3B7.7000000@oracle.com> <5329F8A4.6030908@oracle.com> <5329F93A.2010205@oracle.com> <5329F91E.4050703@oracle.com> <532A2B8E.9040707@oracle.com> <532C5658.6050601@oracle.com> <532C592E.1070205@oracle.com> <532F239D.2030203@oracle.com> <533012D4.6030708@oracle.com> <5335CC4E.1050407@oracle.com> Message-ID: <5336EC48.2060504@oracle.com> Hi Sergey, I recall seeing two recommendations (Mine and Mikes) not to add the macro and just use the ternary form where it is needed. How many places in the code (presumed to be AWT) is this needed? With the name IS_JNI_TRUE, I would expect it to expand to: #define IS_JNI_TRUE(obj) ((obj ==*JNI_TRUE*) ? JNI_TRUE : JNI_FALSE) Roger On 3/28/2014 3:23 PM, Sergey Bylokhov wrote: > On 3/24/14 3:11 PM, Anthony Petrov wrote: >> How does IS_JNI_TRUE sound? > It looks good. If nobody objects, the final version will be: > > #define IS_NULL(obj) ((obj) == NULL) > #define JNU_IsNull(env,obj) ((obj) == NULL) > +#define IS_JNI_TRUE(obj) ((obj) ? JNI_TRUE : JNI_FALSE) > > without additional cast. > >> -- >> best regards, >> Anthony >> >> On 3/23/2014 10:10 PM, Alan Bateman wrote: >>> On 21/03/2014 15:22, Sergey Bylokhov wrote: >>>> On 3/21/14 7:10 PM, roger riggs wrote: >>>>> The macro would just as useful (if I understand the cases) without >>>>> the cast. >>>>> >>>>> How useful is a simple definition as: >>>>> >>>>> #define IS_TRUE(obj) ((obj) ? JNI_TRUE : JNI_FALSE) >>>>> >>>>> then it would look ok to see these in sources: >>>>> >>>>> return IS_TRUE(obj); >>>>> >>>>> if (IS_TRUE(obj)) {....} >>>>> >>>>> jboolean ret = IS_TRUE(obj); >>>>> >>>>> The general purpose usage matches the general C conventions for >>>>> true and false and match the JNI semantics. >>>> Actually that was my initial suggestion(name and usage). >>> I think the concern with IS_TRUE is that it's not obvious that it's a >>> jboolean. Also just the potential for it to easily collide with a macro >>> that casts to bool or (or Windows's BOOL). I can't tell from the JNI >>> spec if JNI_FALSE/JNI_TRUE are guaranteed to be defined as 0/1 but even >>> if they are then I guess there is still a concern that a jboolean is >>> defined as an unsigned 8 bits whereas a bool might not (and a Windows's >>> BOOL is an int I think). So if a macro is really needed then I think it >>> will need another name. I thought MIke's original proposal for >>> JNU_TO_JBOOLEAN wasn't too bad. I see Mike's mail about adding the >>> cases >>> to the definitions but that isn't going to help with the cases that I >>> think you are running into where you need to go from Window's BOOL to >>> jboolean. >>> >>> -Alan. > > From develop4lasu at gmail.com Sat Mar 29 16:00:39 2014 From: develop4lasu at gmail.com (=?UTF-8?Q?Marek_Kozie=C5=82?=) Date: Sat, 29 Mar 2014 17:00:39 +0100 Subject: Implicit 'this' return for void methods In-Reply-To: <0EFE68B5-0F74-4D0B-971F-FDDD05C00981@gmail.com> References: <0EFE68B5-0F74-4D0B-971F-FDDD05C00981@gmail.com> Message-ID: > The number of cases that this dramatically increases readability are well described. A single concrete counterexample would help. > I Use Builders which are created especially to be called in chain mode, so even after a while code is 100% readable. But when we assume that void could be replaced with this call like: Thing thing = new Factory() .setSomething(something) .setOther(other) .result(); Main problem is fact that in long chain you cannot be sure if type changed and on which object you executing method. Now chain constructions are so rare that you remember them all. After such change every call could be considered to be chained so each code would required more analysis.. Because in one instruction there will be more chance to meet code that modify and move between classes, and in-line constructions like a.getB().dosmf().backtoA().doSmf()... would occur. What more even if chains occurs then there is single logic space in current calls. StringBuilder.append().append.append; While change on void would bring multiple logic spaces take place in line: generate .writetofile.generatemore.sendbymail.savetostring... >> 3rd: space for future return type was left. > > You can?t (shouldn?t) do this. Changing method return types is a breaking change and will invalidate previously compiled code. So this is broken already anyway. However, it is true that this elevates a binary incompatibility to a source incompatibility. > > There are interfaces that are not allowed to change mostly between two modules, but most of methods change types quite often in real-life. I do not like looking at code from /good developer/ point of view, i like to look at language with question /how many time good developer time will be used to help weaker ones/ Don't get me wrong i like chains but not if language readability would suffer, that why i suggested return 'this' : http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000523.html But this change is not so easy to introduce. -- Pozdrawiam Marek Kozie? ( Lasu ) http://na-chlodno.blogspot.com/ http://lasu2string.blogspot.com/ From victor2 at ukr.net Sat Mar 29 17:42:28 2014 From: victor2 at ukr.net (Victor Polischuk) Date: Sat, 29 Mar 2014 19:42:28 +0200 Subject: Implicit 'this' return for void methods In-Reply-To: References: <0EFE68B5-0F74-4D0B-971F-FDDD05C00981@gmail.com> Message-ID: <1396113604.229343390.ozv0hsr6@frv39.fwdcdn.com> --- Original message --- From: "Marek Kozie?" Date: 29 March 2014, 18:02:06 > Main problem is fact that in long chain you cannot be sure if type > changed and on which object you executing method. Now chain > constructions are so rare that you remember them all. > After such change every call could be considered to be chained so each > code would required more analysis.. Even the most simple or advanced tool can be misused. Builders usually mean extra layer which you need to support and adapt in case of underline object has changed. Moreover, just imagine the hell when every object has a proper builder in a separate class or additional methods to JavaBeans properties. > While change on void would bring multiple logic spaces take place in line: > generate .writetofile.generatemore.sendbymail.savetostring... It looks like function composition and is already used in Stream API and many other places. I really cannot comprehend what is wrong with it. > I do not like looking at code from /good developer/ point of view, i > like to look at language with question /how many time good developer > time will be used to help weaker ones/ Is that a problem to explain once for "weaker ones" that void methods now MAY be chained? > Don't get me wrong i like chains but not if language readability would > suffer, that why i suggested return 'this' : > http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000523.html > But this change is not so easy to introduce. The change you propose cannot be applied to already compiled legacy code and therefore less useful. Java already has huge code database and rejecting the fact makes the feature unpopular. Imagine some people can desire something like: LOG.error("An error occurs: " + e.getMessage()).debug("Print stack trace: ", e); ---- Regards, Victor Polischuk From n-roeser at gmx.net Sat Mar 29 16:01:12 2014 From: n-roeser at gmx.net (Nico R.) Date: Sat, 29 Mar 2014 17:01:12 +0100 Subject: Wrong encoding after XML identity transformation Message-ID: <5336EE48.8070008@gmx.net> Hello! I?m using IcedTea 2.4.5 for OpenJDK 7 on Gentoo. This includes JAXP revision 8fe156ad49e2 (in the IcedTea repos) which again seems to contain jdk7u51-b31[0] ? which again is revision 626e76f127a4 in the OpenJDK repo jdk7u, as far as I can see. Oh well, you?ll probably know better about all these version numbers than I do. Anyway, after a painful debugging session I found that the default XML transformer implementation (via XSLTC) handles encodings improperly when writing in-memory DOM Documents (which had an encoding other than UTF-8 specified when being parsed) to a stream. I?m attaching my test code, which I hope is correct and readable. What it does: ? read a document with encoding="ISO-8859-1" from an input stream into a DOM Document. The input document itself does not contain any characters outside US-ASCII, which is a subset of ISO-8859-1. ? Add a text node with text ?sch?n? (=nice in German) to the document. The ??? in ?sch?n? is LATIN SMALL LETTER O WITH DIAERESIS (U+00F6). This can, of course, be stored in the in-memory document tree, but may need character conversions when storing it later. ? Use a Transformer with output properties set to XML in UTF-8 for writing the document into a stream using an identity transformation. I compared Xalan-J 2.7.1 and the internal implementation (older Xalan?) in my JRE installed with my version of OpenJDK (see above). External Xalan produces documents with XML encoding="UTF-8", while the JRE-internal Xalan keeps encoding="ISO-8859-1", *but writes the ??? encoded in UTF-8*! This produces wrong content in the document when processing it with an XML parser later. The transformer should use UTF-8, as I requested in the code. If I did not specificially request anything, it might also have used ISO-8859-1 if transcoding all characters into that encoding. In order to use the attached test program, put xalan.jar and xsltc.jar from Xalan-J into your classpath. Even XSLTC from Xalan-J 2.7.1 works, just not the JRE-internal one. My default locale has UTF-8 encoding, in case that matters. [0] http://icedtea.classpath.org/hg/release/icedtea7-forest-2.4/jaxp/rev/8fe156ad49e2 [1] http://hg.openjdk.java.net/jdk7u/jdk7u/rev/a831c212ee26 -- Nico From john.r.rose at oracle.com Sat Mar 29 18:58:49 2014 From: john.r.rose at oracle.com (John Rose) Date: Sat, 29 Mar 2014 11:58:49 -0700 Subject: RFR(S) : 8038186 : [TESTBUG] improvements of test j.l.i.MethodHandles In-Reply-To: <533540F9.2070900@oracle.com> References: <533096A8.1020405@oracle.com> <8068D25C-AA39-4012-83BC-0A2F09309EF8@oracle.com> <53333CAD.8080309@oracle.com> <5334802A.9050003@oracle.com> <533540F9.2070900@oracle.com> Message-ID: <8B768158-77D8-4BDB-A26C-B3AAF9F1DD63@oracle.com> On Mar 28, 2014, at 2:29 AM, Vladimir Ivanov wrote: > PS: John mentioned recently that there's a convention for java/lang/invoke tests to be in JUnit format. I'm not sure it'll improve the code in any way (maybe TestNG will?). I hope John will express his opinion on this, if it's important. If a test is in JUnit format, please keep it that way. I (at least) run these tests from NetBeans which knows about JUnit. Extracting logic from MHT and changing the test framework directly dilutes my interactive testing workflow. If my IDE had a jtreg plugin, I wouldn't need to worry about which jtreg tests use which style, but the world isn't perfect, yet. ? John P.S. Same comment to the people that are eager to change JUnit to TestNG apparently just because it's the new thing. TestNG was a step backwards in my workflow because the CLI *stinks* compared to JUnit, making it nigh-impossible to manually perform one-off runs. I assume that will be fixed but for now I patch my workspace back to JUnit in order to work in my IDE. From n-roeser at gmx.net Sat Mar 29 19:47:40 2014 From: n-roeser at gmx.net (Nico R.) Date: Sat, 29 Mar 2014 20:47:40 +0100 Subject: Wrong encoding after XML identity transformation In-Reply-To: <5336EE48.8070008@gmx.net> References: <5336EE48.8070008@gmx.net> Message-ID: <5337235C.7070302@gmx.net> Hello again! A few hours ago, I wrote: [?] > > I?m attaching my test code, which I hope is correct and readable. It seems that the list software stripped off the attachment with the test program, so here it is again, inline: :-/ // This document is encoded in UTF-8, with no BOM and with LF line endings. import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.PrintStream; import java.util.ArrayList; import java.util.List; import javax.xml.parsers.DocumentBuilder; import javax.xml.parsers.DocumentBuilderFactory; import javax.xml.transform.OutputKeys; import javax.xml.transform.Transformer; import javax.xml.transform.TransformerFactory; import javax.xml.transform.TransformerFactoryConfigurationError; import javax.xml.transform.dom.DOMSource; import javax.xml.transform.stream.StreamResult; import org.w3c.dom.Document; import org.w3c.dom.Element; import org.w3c.dom.Text; public class TransformerTest { /** convenience method, prints a byte array in human-readable ASCII chars */ private static void printArray(byte[] data, PrintStream out) { if (data == null) { out.println("(null)"); return; } if (data.length == 0) { out.println("(empty array)"); return; } for (int i = 0; ; ) { byte b = data[i]; if (b >= 0x20 && b <= 0x7F) { out.print(" '" + (char)b + "'"); } else { out.format("0x%02X", (int)b & 0xFF); } if (++i == data.length) break; if ((i % 16) == 0) { out.println(','); } else { out.print(", "); } } out.println(); } /** * parses a {@code Document} from an {@code InputStream} (and not from a * {@code StringReader}, in order to make sure it?s not a problem when * parsing internal Unicode {@code String}s) */ private static Document makeDocument() throws Exception { DocumentBuilder builder = DocumentBuilderFactory.newInstance().newDocumentBuilder(); byte[] docBytes = { '<', '?', 'x', 'm', 'l', ' ', 'v', 'e', 'r', 's', 'i', 'o', 'n', '=', '"', '1', '.', '0', '"', ' ', // document is encoded in US-ASCII, but labelled as a superset 'e', 'n', 'c', 'o', 'd', 'i', 'n', 'g', '=', '"', 'I', 'S', 'O', '-', '8', '8', '5', '9', '-', '1', '"', '?', '>', '<', 'x', '/', '>' }; return builder.parse(new ByteArrayInputStream(docBytes)); } /** prepares a list of transformer factories to test */ private static List makeTransformerFactories() { String[] facNames = { "org.apache.xalan.processor.TransformerFactoryImpl", "org.apache.xalan.xsltc.trax.TransformerFactoryImpl", "com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl" }; List transFactories = new ArrayList<>(); for (String facName : facNames) { try { TransformerFactory factory = TransformerFactory.newInstance(facName, null); transFactories.add(factory); } catch (TransformerFactoryConfigurationError ex) { System.out.println("cannot build instance of " + facName); } } //transFactories.add(TransformerFactory.newInstance()); // default impl return transFactories; } private static byte[] transformWith(TransformerFactory transFac, Document doc) throws Exception { Transformer trans = transFac.newTransformer(); trans.setOutputProperty(OutputKeys.METHOD, "xml"); trans.setOutputProperty(OutputKeys.ENCODING, "UTF-8"); System.out.println("transformer factory: " + transFac.getClass().getName()); System.out.println("transformer: " + trans.getClass().getName()); ByteArrayOutputStream bout = new ByteArrayOutputStream(128); trans.transform(new DOMSource(doc), new StreamResult(bout)); byte[] data = bout.toByteArray(); return data; } public static void main(String[] t) throws Exception { Document doc = makeDocument(); System.out.println( "encoding declared in document : " + doc.getXmlEncoding()); // now insert a text node containing a character which can be // represented in ISO-8859-1, as well as (differently) in UTF-8, but not // in US-ASCII Element dstRoot = doc.getDocumentElement(); Text text = doc.createTextNode("sch?n"); dstRoot.insertBefore(text, null); System.out.println("root element text: " + dstRoot.getTextContent()); List factories = makeTransformerFactories(); for (TransformerFactory factory : factories) { System.out.println(); byte[] bytes = transformWith(factory, doc); System.out.println("resulting bytes:"); printArray(bytes, System.out); } } } -- Nico From igor.ignatyev at oracle.com Sat Mar 29 23:07:54 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Sun, 30 Mar 2014 03:07:54 +0400 Subject: RFR(S) : 8038186 : [TESTBUG] improvements of test j.l.i.MethodHandles In-Reply-To: <8B768158-77D8-4BDB-A26C-B3AAF9F1DD63@oracle.com> References: <533096A8.1020405@oracle.com> <8068D25C-AA39-4012-83BC-0A2F09309EF8@oracle.com> <53333CAD.8080309@oracle.com> <5334802A.9050003@oracle.com> <533540F9.2070900@oracle.com> <8B768158-77D8-4BDB-A26C-B3AAF9F1DD63@oracle.com> Message-ID: <5337524A.7020206@oracle.com> John, unfortunately, I've already pushed my changes w/o junit annotation. But I have the dirty patch which adds "jtreg support" to netbeans: 1. add test.single action for test folder to 'ide-actions' section in JDK project -- jdk/make/netbeans/j2se/nbproject/project.xml: > > > test-selected-file-in-test > > run.files > ${root}/test > \.java$ > relative-path > > > > > 2. create jdk/make/netbeans/j2se/nbproject/ide-file-targets.xml file (it's partially generated by netbeans): > > > > > > > > > > > > > > > > > > > Must set property 'run.class' > > > > > > > > Must set property 'run.files' > > > > > > > > 3. open jdk/make/netbeans/j2se/nbproject 4. select your favorite tests in 'Tests' fileset 5. click 'Test File(s)' in a context menu or in 'Run' menu or press Ctrl-F6 6. ... 7. PROFIT Hope you'll find it useful. PS you have to set 'JT_HOME' environment variable, it should point to jtreg-root directory. Igor On 03/29/2014 10:58 PM, John Rose wrote: > On Mar 28, 2014, at 2:29 AM, Vladimir Ivanov > > wrote: > >> PS: John mentioned recently that there's a convention for >> java/lang/invoke tests to be in JUnit format. I'm not sure it'll >> improve the code in any way (maybe TestNG will?). I hope John will >> express his opinion on this, if it's important. > > If a test is in JUnit format, please keep it that way. I (at least) run > these tests from NetBeans which knows about JUnit. Extracting logic > from MHT and changing the test framework directly dilutes my interactive > testing workflow. > > If my IDE had a jtreg plugin, I wouldn't need to worry about which jtreg > tests use which style, but the world isn't perfect, yet. > > ? John > > P.S. Same comment to the people that are eager to change JUnit to TestNG > apparently just because it's the new thing. TestNG was a step backwards > in my workflow because the CLI *stinks* compared to JUnit, making it > nigh-impossible to manually perform one-off runs. I assume that will be > fixed but for now I patch my workspace back to JUnit in order to work in > my IDE. > > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From mandy.chung at oracle.com Sun Mar 30 04:20:44 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 29 Mar 2014 21:20:44 -0700 Subject: RFR [8038333] java/lang/ref/EarlyTimeout.java failed In-Reply-To: <53342972.3090209@oracle.com> References: <5332D2DD.3080207@oracle.com> <533308B3.2030605@oracle.com> <53333602.701@oracle.com> <53335B4A.6060100@oracle.com> <5333712A.2060908@oracle.com> <5333D29B.7080504@oracle.com> <53341BDE.5040907@gmail.com> <53342972.3090209@oracle.com> Message-ID: <53379B9C.3090502@oracle.com> On 3/27/2014 6:36 AM, Ivan Gerasimov wrote: > Now, I updated the webrev with the additional delay as you suggested: > http://cr.openjdk.java.net/~igerasim/8038333/2/webrev/ Thanks for the updated patch, Ivan and also Peter for the suggestion to delay to give a chance for the threads to wait on the lock. Ivan - I agree with you that there is no guarantee that one thread can remove the reference before the timeout. With this patch, basically the test can only verify that the remove(timeout) must be >= timeout if no reference is in the queue. That makes the test less interesting but it's a tradeoff with test stability. I wonder if running this test in othervm would help increase the chance of enqueuing the reference after System.gc. I think it's okay with your proposed patcht. We should revisit this test in the future to see how we can improve the test for example something similar to what Peter suggests. Can you file a bug for the test improvement so that we can look into that in the future? BTW there is a typo in line 40 s/System.gs()/System.gc()/. It'd be good to add a comment in line 66 to make it clear that the main thread waits until the threads has started and give it a chance for the threads to block on the queue.remove(timeout) call. thanks Mandy From ivan.gerasimov at oracle.com Sun Mar 30 09:04:12 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sun, 30 Mar 2014 13:04:12 +0400 Subject: RFR [8038333] java/lang/ref/EarlyTimeout.java failed In-Reply-To: <53379B9C.3090502@oracle.com> References: <5332D2DD.3080207@oracle.com> <533308B3.2030605@oracle.com> <53333602.701@oracle.com> <53335B4A.6060100@oracle.com> <5333712A.2060908@oracle.com> <5333D29B.7080504@oracle.com> <53341BDE.5040907@gmail.com> <53342972.3090209@oracle.com> <53379B9C.3090502@oracle.com> Message-ID: <5337DE0C.1020105@oracle.com> Thank you Mandy for review! On 30.03.2014 8:20, Mandy Chung wrote: > On 3/27/2014 6:36 AM, Ivan Gerasimov wrote: >> Now, I updated the webrev with the additional delay as you suggested: >> http://cr.openjdk.java.net/~igerasim/8038333/2/webrev/ > > Thanks for the updated patch, Ivan and also Peter for the suggestion > to delay to give a chance for the threads to wait on the lock. > > Ivan - I agree with you that there is no guarantee that one thread can > remove the reference before the timeout. With this patch, basically > the test can only verify that the remove(timeout) must be >= timeout > if no reference is in the queue. That makes the test less > interesting but it's a tradeoff with test stability. I wonder if > running this test in othervm would help increase the chance of > enqueuing the reference after System.gc. > > I think it's okay with your proposed patcht. We should revisit this > test in the future to see how we can improve the test for example > something similar to what Peter suggests. Can you file a bug for the > test improvement so that we can look into that in the future? > Okey. Will do. > BTW there is a typo in line 40 s/System.gs()/System.gc()/. It'd be > good to add a comment in line 66 to make it clear that the main thread > waits until the threads has started and give it a chance for the > threads to block on the queue.remove(timeout) call. > Yes, I will update the comment as you suggest before pushing. Sincerely yours, Ivan From mandy.chung at oracle.com Sun Mar 30 23:02:19 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Sun, 30 Mar 2014 16:02:19 -0700 Subject: Draft JEP: Efficient Stack Walking API Message-ID: <5338A27B.1010309@oracle.com> 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 igor.veresov at oracle.com Sat Mar 29 01:07:31 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 28 Mar 2014 18:07:31 -0700 Subject: RFR(S) : 8038186 : [TESTBUG] improvements of test j.l.i.MethodHandles In-Reply-To: <53359DA5.6010503@oracle.com> References: <533096A8.1020405@oracle.com> <8068D25C-AA39-4012-83BC-0A2F09309EF8@oracle.com> <53333CAD.8080309@oracle.com> <5334802A.9050003@oracle.com> <533540F9.2070900@oracle.com> <53355D7B.8030408@oracle.com> <53359DA5.6010503@oracle.com> Message-ID: <663BF01A-E71B-4B01-94F2-EF98A4F2E96F@oracle.com> Typo in CatchExceptionTest.java: 66 private int droped; Should be ?dropped?. Otherwise seems ok... But more comments would be appreciated. It?s huge and really hard to understand. igor On Mar 28, 2014, at 9:04 AM, Igor Ignatyev wrote: > Vladimir, > > as we'd arranged, I moved ThrowMode into TestCase and give my word that I'll >> remove TestCase.assertEQ and enhance Asserts.assertEquals for arrays >> add the test cases from TestCatchException to 'MANDATORY_TEST_CASES' in CatchExceptionTest and remove TestCatchException > in JDK9 TF. > > updated webrev: http://cr.openjdk.java.net/~iignatyev/8038186/webrev.03/ > > Thanks, > Igor > > On 03/28/2014 03:31 PM, Igor Ignatyev wrote: >> Vladimir, thanks for review, please my comments inline. >> >> On 03/28/2014 01:29 PM, Vladimir Ivanov wrote: >>> Igor, thanks for improving the tests on method handles! >>> >>>> After an offline conversation w/ VladimirI, I've done several changes: >>>> - placed all classes into one file (but I don't like it) >>> You can convert TestCase & TestFactory to inner classes and move >>> ThrowMode into TestCase since it's usage is confined to TestCase. >>> >> I don't like using of inner classes, from my point of view, it makes >> code less readable. But if you insists, I can do it. >> >>>> - changed package name >>>> - extracted creating tests code from test execution code >>> These changes look good. >>> >>> Other comments: >>> - why don't you remove TestCase.assertEQ and enhance >>> Asserts.assertEquals for arrays? >> I'm not sure that this doesn't break the other tests which use >> 'Asserts.assertEquals', and since I want to push this patch to 8u20, I >> consider it's too risky to change now. >> >> I'll do it in my next improvements of MH tests in jdk9 TF. >> >>> - regarding CatchExceptionTest name: there's already >>> TestCatchException test. Have you considered merging them into one test >>> or removing TestCatchException, if your test already covers that cases? >> I didn't remove TestCatchException, since I'm not pretty sure that all >> cases are covered and don't have enough time to check it, also this >> test's a regression test which cover some particular test cases. >> >> I plan to add the test cases from TestCatchException to >> 'MANDATORY_TEST_CASES' in CatchExceptionTest and remove >> TestCatchException in jdk9 TF. >> >>> Best regards, >>> Vladimir Ivanov >>> >>> PS: John mentioned recently that there's a convention for >>> java/lang/invoke tests to be in JUnit format. I'm not sure it'll improve >>> the code in any way (maybe TestNG will?). I hope John will express his >>> opinion on this, if it's important. >>> >>>> >>>> I hope the code's still quite readable and understandable. >>>> >>>> Also I've added array return type. >>>> >>>> http://cr.openjdk.java.net/~iignatyev/8038186/webrev.02/ >>>> >>>> Thanks, >>>> Igor >>>> >>>> On 03/27/2014 12:46 AM, Igor Ignatyev wrote: >>>>> Hi Chris, >>>>> >>>>>> This is very nice. Are there plans to do this for the other existing >>>>>> tests as well? >>>>> sure, but we didn't have enough time to do it in 8u20 timeframe. So I'd >>>>> like to push these changes 1st, since we need this to cover 'Speedup >>>>> catch exceptions'. Other tests will be rewrite later. I hope we'll have >>>>> time in jdk 9 to refactor all tests in MethodHandles. >>>>> >>>>> Thanks, >>>>> Igor >>>>> >>>>> On 03/27/2014 12:38 AM, Christian Thalinger wrote: >>>>>> >>>>>> On Mar 24, 2014, at 1:33 PM, Igor Ignatyev >>>>>> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Please review the patch: >>>>>>> >>>>>>> Problems: >>>>>>> - MethodHandlesTest::testCatchException() doesn't provide enough >>>>>>> testing of j.l.i.MethodHandles::catchException(). >>>>>>> - MethodHandlesTest contains more than 3k lines, an auxiliary code >>>>>>> together w/ a test code, many methods aren't connected w/ each other, >>>>>>> etc. All this leads to that it is very very hard to understand, >>>>>>> maintain. >>>>>> >>>>>> Yes, it is. >>>>>> >>>>>>> >>>>>>> Fix: >>>>>>> - the auxiliary code was moved to testlibray >>>>>>> - the test code was moved to a separate subpackage >>>>>> >>>>>> This is very nice. Are there plans to do this for the other existing >>>>>> tests as well? >>>>>> >>>>>>> - random signature is used for target and handler >>>>>>> - added scenarios w/ different return types >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8038186/webrev.01/ >>>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8038186 >>>>>>> -- >>>>>>> Igor >>>>>>> _______________________________________________ >>>>>>> mlvm-dev mailing list >>>>>>> mlvm-dev at openjdk.java.net >>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>>> >>>>>> _______________________________________________ >>>>>> mlvm-dev mailing list >>>>>> mlvm-dev at openjdk.java.net >>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>>> >>>>> _______________________________________________ >>>>> mlvm-dev mailing list >>>>> mlvm-dev at openjdk.java.net >>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>> _______________________________________________ >>>> mlvm-dev mailing list >>>> mlvm-dev at openjdk.java.net >>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From miroslav.kos at oracle.com Mon Mar 31 13:19:45 2014 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Mon, 31 Mar 2014 15:19:45 +0200 Subject: RFR: 8038307: JAX-WS conformance tests fail when running JCK-devtools-8 suite against RI in EBCDIC emulation mode Message-ID: <53396B71.5010104@oracle.com> Hi there, please review folowing simple fix - Bug: https://bugs.openjdk.java.net/browse/JDK-8038307 Fix: http://cr.openjdk.java.net/~mkos/8038307/jaxws.01/ Test: http://cr.openjdk.java.net/~mkos/8038307/jdk.01/ Issue related to EBCDIC encoding/WsImport tool. Thanks Miran From chris.hegarty at oracle.com Mon Mar 31 13:34:49 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 31 Mar 2014 14:34:49 +0100 Subject: RFR: 8038307: JAX-WS conformance tests fail when running JCK-devtools-8 suite against RI in EBCDIC emulation mode In-Reply-To: <53396B71.5010104@oracle.com> References: <53396B71.5010104@oracle.com> Message-ID: <53396EF9.7050500@oracle.com> Looks ok to me Miran. You can use String.getBytes(StandardCharsets.UTF_8) if you don't want to handle UnsupportedEncodingException. I can sponsor this for you, if you need a sponsor. -Chris. [1] http://docs.oracle.com/javase/8/docs/api/java/nio/charset/StandardCharsets.html#UTF_8 On 31/03/14 14:19, Miroslav Kos wrote: > Hi there, > please review folowing simple fix - > Bug: https://bugs.openjdk.java.net/browse/JDK-8038307 > Fix: http://cr.openjdk.java.net/~mkos/8038307/jaxws.01/ > Test: http://cr.openjdk.java.net/~mkos/8038307/jdk.01/ > > Issue related to EBCDIC encoding/WsImport tool. > > Thanks > Miran > > From miroslav.kos at oracle.com Mon Mar 31 14:05:03 2014 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Mon, 31 Mar 2014 16:05:03 +0200 Subject: RFR: 8038307: JAX-WS conformance tests fail when running JCK-devtools-8 suite against RI in EBCDIC emulation mode In-Reply-To: <53396EF9.7050500@oracle.com> References: <53396B71.5010104@oracle.com> <53396EF9.7050500@oracle.com> Message-ID: <5339760F.5040703@oracle.com> Thanks Chris, the code adjusted: http://cr.openjdk.java.net/~mkos/8038307/jaxws.02/ Glad, if you can sponsor it for me. Regards Miran On 31/03/14 15:34, Chris Hegarty wrote: > Looks ok to me Miran. > > You can use String.getBytes(StandardCharsets.UTF_8) if you don't want > to handle UnsupportedEncodingException. > > I can sponsor this for you, if you need a sponsor. > > -Chris. > > [1] > http://docs.oracle.com/javase/8/docs/api/java/nio/charset/StandardCharsets.html#UTF_8 > > On 31/03/14 14:19, Miroslav Kos wrote: >> Hi there, >> please review folowing simple fix - >> Bug: https://bugs.openjdk.java.net/browse/JDK-8038307 >> Fix: http://cr.openjdk.java.net/~mkos/8038307/jaxws.01/ >> Test: http://cr.openjdk.java.net/~mkos/8038307/jdk.01/ >> >> Issue related to EBCDIC encoding/WsImport tool. >> >> Thanks >> Miran >> >> From chris.hegarty at oracle.com Mon Mar 31 14:33:35 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 31 Mar 2014 15:33:35 +0100 Subject: RFR: 8038307: JAX-WS conformance tests fail when running JCK-devtools-8 suite against RI in EBCDIC emulation mode In-Reply-To: <5339760F.5040703@oracle.com> References: <53396B71.5010104@oracle.com> <53396EF9.7050500@oracle.com> <5339760F.5040703@oracle.com> Message-ID: <53397CBF.8090200@oracle.com> On 31/03/14 15:05, Miroslav Kos wrote: > Thanks Chris, the code adjusted: > http://cr.openjdk.java.net/~mkos/8038307/jaxws.02/ Approved. > Glad, if you can sponsor it for me. I'll push this later today. -Chris. > Regards > Miran > > On 31/03/14 15:34, Chris Hegarty wrote: >> Looks ok to me Miran. >> >> You can use String.getBytes(StandardCharsets.UTF_8) if you don't want >> to handle UnsupportedEncodingException. >> >> I can sponsor this for you, if you need a sponsor. >> >> -Chris. >> >> [1] >> http://docs.oracle.com/javase/8/docs/api/java/nio/charset/StandardCharsets.html#UTF_8 >> >> >> On 31/03/14 14:19, Miroslav Kos wrote: >>> Hi there, >>> please review folowing simple fix - >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038307 >>> Fix: http://cr.openjdk.java.net/~mkos/8038307/jaxws.01/ >>> Test: http://cr.openjdk.java.net/~mkos/8038307/jdk.01/ >>> >>> Issue related to EBCDIC encoding/WsImport tool. >>> >>> Thanks >>> Miran >>> >>> > From aleksej.efimov at oracle.com Mon Mar 31 15:09:41 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Mon, 31 Mar 2014 19:09:41 +0400 Subject: RFR (JAXP): 8035437: Xerces Update: xml/serialize/DOMSerializerImpl In-Reply-To: References: <533302DD.2090005@oracle.com> <155CED84-F9D2-4EF8-9AC2-18A7AA7C0E68@oracle.com> <95ECB6AF-B918-4812-92C8-6915A3EDE98D@oracle.com> <533311E6.2090500@oracle.com> Message-ID: <53398535.9030909@oracle.com> Lance, thank you for the review. Aleksej On 03/28/2014 03:33 PM, Lance @ Oracle wrote: > With the change to stringbuilder I am ok with it > > 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 > Sent from my iPad > > On Mar 26, 2014, at 1:44 PM, Aleksej Efimov > wrote: > >> Lance, >> The document implementation (DocumentImpl) returned by >> 'builder.newDocument()' should implement org.w3c.dom.Node and >> org.w3c.dom.Document interfaces, but shouldn't have the >> 'getXmlVersion' method (in Node, Document and DocumentImpl) - it's a >> main item required by Apache bug. So it means, that we need to >> substitute all three classes (Document,Node and DocumentImpl). The >> test should be executed with JDKs Node, Document, but DocumentImpl >> should be compiled against incorrect interfaces. I don't see, how I >> can implement it with jtreg keywords (the main problem is splitting >> the compilation of DocumentImpl (fake Node, Document) and the test >> run (only fake DocumentImpl). >> >> The only reason why StringBuffer is not used here - the process of >> how updates were moved from Xerces to JAXP: revision by revision. And >> I don't think that it should prevent us from replacing it with faster >> StringBuilder =). Will change it to StringBuilder. >> >> Thank you, >> Aleksej >> >> On 03/26/2014 09:04 PM, Lance Andersen wrote: >>> Any reason not to use StringBuilder in place of StringBuffer >>> in XMLEntityManager.java >>> >>> other than the above and my question on the need of using run.sh, it >>> is OK >>> >>> On Mar 26, 2014, at 12:54 PM, Lance Andersen >>> > wrote: >>> >>>> Hi Aleksej, >>>> >>>> Do you really need to use run.sh? If possible it would be better >>>> to try and avoid providing a script and use the jtreg keywords. >>>> >>>> Best >>>> Lance >>>> On Mar 26, 2014, at 12:39 PM, Aleksej Efimov >>>> > wrote: >>>> >>>>> Hello, >>>>> >>>>> Can I ask for a review for the update of DOMSerializerImpl class >>>>> [1] to the latest Apache Xerces implementation. >>>>> The following changes were made: >>>>> 1. The DOMSerializerImpl update: The Xerces class was used as a >>>>> base [2]; the 476047 and 473125 revisions from Xerces was >>>>> excluded (they will be resolved as a part of JDK-8035467 - move to >>>>> Xalan serializer bug); the jaxp 632 revision was applied to new >>>>> version of this class. >>>>> 2. The DOMSerializerImpl.java file was reformated, because of >>>>> not-good formatting in original file from Apache repo [2]. >>>>> 3. Other changes related to the DOMSerializerImpl update were >>>>> applied from Xerces repo to JDK(the full revisions list can be >>>>> found in the JBS [1]). >>>>> 4. All license headers were updated to the latest version of >>>>> Apache header in modified files. >>>>> 5. New regression test was added to reproduce a problem described >>>>> in Apache bug XERCESJ-1007 [3]. >>>>> >>>>> Webrevs for these changes: >>>>> http://cr.openjdk.java.net/~aefimov/8035437/webrev.00/jaxp >>>>> >>>>> http://cr.openjdk.java.net/~aefimov/8035437/webrev.00/jdk >>>>> >>>>> >>>>> Testing: >>>>> JCK tests (api/xsl api/xinclude api/javax_xml api/org_xml >>>>> xml_schema): pass >>>>> JTREG tests (javax/xml, jdk_other): pass >>>>> >>>>> Thank you, >>>>> Aleksej >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-6339023 >>>>> [2] >>>>> http://svn.apache.org/viewvc/xerces/java/trunk/src/org/apache/xml/serialize/DOMSerializerImpl.java?revision=944789&view=markup >>>>> [3] https://issues.apache.org/jira/browse/XERCESJ-1007 >>>>> >>>> >>>> >>>> >>>> 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 >>>> >>>> >>>> >>> >>> >>> >>> >>> 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 chris.hegarty at oracle.com Mon Mar 31 16:38:52 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 31 Mar 2014 17:38:52 +0100 Subject: RFR: 8038307: JAX-WS conformance tests fail when running JCK-devtools-8 suite against RI in EBCDIC emulation mode In-Reply-To: <53397CBF.8090200@oracle.com> References: <53396B71.5010104@oracle.com> <53396EF9.7050500@oracle.com> <5339760F.5040703@oracle.com> <53397CBF.8090200@oracle.com> Message-ID: Miran, If you agree, I would like to move the test ( before pushing ) to jdk/test/javax/xml/ws (/ebcdic). This is where other jaxws tests live, and will be picked up in the usual developer cycle by the jdk_other test group. -Chris. On 31 Mar 2014, at 15:33, Chris Hegarty wrote: > On 31/03/14 15:05, Miroslav Kos wrote: >> Thanks Chris, the code adjusted: >> http://cr.openjdk.java.net/~mkos/8038307/jaxws.02/ > > Approved. > >> Glad, if you can sponsor it for me. > > I'll push this later today. > > -Chris. > >> Regards >> Miran >> >> On 31/03/14 15:34, Chris Hegarty wrote: >>> Looks ok to me Miran. >>> >>> You can use String.getBytes(StandardCharsets.UTF_8) if you don't want >>> to handle UnsupportedEncodingException. >>> >>> I can sponsor this for you, if you need a sponsor. >>> >>> -Chris. >>> >>> [1] >>> http://docs.oracle.com/javase/8/docs/api/java/nio/charset/StandardCharsets.html#UTF_8 >>> >>> >>> On 31/03/14 14:19, Miroslav Kos wrote: >>>> Hi there, >>>> please review folowing simple fix - >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038307 >>>> Fix: http://cr.openjdk.java.net/~mkos/8038307/jaxws.01/ >>>> Test: http://cr.openjdk.java.net/~mkos/8038307/jdk.01/ >>>> >>>> Issue related to EBCDIC encoding/WsImport tool. >>>> >>>> Thanks >>>> Miran >>>> >>>> >> From develop4lasu at gmail.com Mon Mar 31 20:06:00 2014 From: develop4lasu at gmail.com (=?UTF-8?Q?Marek_Kozie=C5=82?=) Date: Mon, 31 Mar 2014 22:06:00 +0200 Subject: Implicit 'this' return for void methods In-Reply-To: <1396113604.229343390.ozv0hsr6@frv39.fwdcdn.com> References: <0EFE68B5-0F74-4D0B-971F-FDDD05C00981@gmail.com> <1396113604.229343390.ozv0hsr6@frv39.fwdcdn.com> Message-ID: Sorry for late answer, After some thought I came into conclusion, that both solutions are similar. For me void functionality it to great to be in 100% replaced, other reasons are not as important. So if we consider that void would be replaced with 'this' or keep as void, in additional some type would get void functionality and would be used as default return value instead of void. Then even with all confusion this change could be a little reasonable. void for static void mean next static call ? For me language should be incremental as much as possible for user as well for team. Use case 4 you: Team member changes void to other type. Difference between void and void as this is that when someone change this to other type a lot of work have to be done in order to prevent potential bugs, even when committed changes are checked there no easy way to ensure validity of all branches and uncommitted code. 2014-03-29 18:42 GMT+01:00 Victor Polischuk : > --- Original message --- > From: "Marek Kozie?" > Date: 29 March 2014, 18:02:06 > >> Main problem is fact that in long chain you cannot be sure if type >> changed and on which object you executing method. Now chain >> constructions are so rare that you remember them all. >> After such change every call could be considered to be chained so each >> code would required more analysis.. > > Even the most simple or advanced tool can be misused. Builders usually mean extra layer which you need to support and adapt in case of underline object has changed. Moreover, just imagine the hell when every object has a proper builder in a separate class or additional methods to JavaBeans properties. > >> While change on void would bring multiple logic spaces take place in line: >> generate .writetofile.generatemore.sendbymail.savetostring... > > It looks like function composition and is already used in Stream API and many other places. I really cannot comprehend what is wrong with it. > >> I do not like looking at code from /good developer/ point of view, i >> like to look at language with question /how many time good developer >> time will be used to help weaker ones/ > > Is that a problem to explain once for "weaker ones" that void methods now MAY be chained? > >> Don't get me wrong i like chains but not if language readability would >> suffer, that why i suggested return 'this' : >> http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000523.html >> But this change is not so easy to introduce. > > The change you propose cannot be applied to already compiled legacy code and therefore less useful. Java already has huge code database and rejecting the fact makes the feature unpopular. Imagine some people can desire something like: > > LOG.error("An error occurs: " + e.getMessage()).debug("Print stack trace: ", e); > > ---- > Regards, > Victor Polischuk -- Pozdrawiam Marek Kozie? ( Lasu ) http://na-chlodno.blogspot.com/ http://lasu2string.blogspot.com/ From pbenedict at apache.org Mon Mar 31 20:44:15 2014 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 31 Mar 2014 15:44:15 -0500 Subject: Implicit 'this' return for void methods In-Reply-To: References: <0EFE68B5-0F74-4D0B-971F-FDDD05C00981@gmail.com> <1396113604.229343390.ozv0hsr6@frv39.fwdcdn.com> Message-ID: What about opting in? By that, I mean that these void methods must have a specific TYPE_USE annotation on them at compile time to allow chaining. This idea would require a JLS update to allow type annotations on void return values -- perhaps exclusive to this annotation. On Mon, Mar 31, 2014 at 3:06 PM, Marek Kozie? wrote: > Sorry for late answer, > > After some thought I came into conclusion, that both solutions are similar. > For me void functionality it to great to be in 100% replaced, other > reasons are not as important. > So if we consider that void would be replaced with 'this' or keep as > void, in additional some type would get void functionality and would > be used as default return value instead of void. Then even with all > confusion this change could be a little reasonable. > void for static void mean next static call ? > > For me language should be incremental as much as possible for user as > well for team. > Use case 4 you: > Team member changes void to other type. > Difference between void and void as this is that when someone change > this to other type a lot of work have to be done in order to prevent > potential bugs, even when committed changes are checked there no easy > way to ensure validity of all branches and uncommitted code. > > 2014-03-29 18:42 GMT+01:00 Victor Polischuk : > > --- Original message --- > > From: "Marek Kozie?" > > Date: 29 March 2014, 18:02:06 > > > >> Main problem is fact that in long chain you cannot be sure if type > >> changed and on which object you executing method. Now chain > >> constructions are so rare that you remember them all. > >> After such change every call could be considered to be chained so each > >> code would required more analysis.. > > > > Even the most simple or advanced tool can be misused. Builders usually > mean extra layer which you need to support and adapt in case of underline > object has changed. Moreover, just imagine the hell when every object has a > proper builder in a separate class or additional methods to JavaBeans > properties. > > > >> While change on void would bring multiple logic spaces take place in > line: > >> generate .writetofile.generatemore.sendbymail.savetostring... > > > > It looks like function composition and is already used in Stream API and > many other places. I really cannot comprehend what is wrong with it. > > > >> I do not like looking at code from /good developer/ point of view, i > >> like to look at language with question /how many time good developer > >> time will be used to help weaker ones/ > > > > Is that a problem to explain once for "weaker ones" that void methods > now MAY be chained? > > > >> Don't get me wrong i like chains but not if language readability would > >> suffer, that why i suggested return 'this' : > >> http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000523.html > >> But this change is not so easy to introduce. > > > > The change you propose cannot be applied to already compiled legacy code > and therefore less useful. Java already has huge code database and > rejecting the fact makes the feature unpopular. Imagine some people can > desire something like: > > > > LOG.error("An error occurs: " + e.getMessage()).debug("Print stack > trace: ", e); > > > > ---- > > Regards, > > Victor Polischuk > > > > -- > Pozdrawiam > Marek Kozie? ( Lasu ) > > http://na-chlodno.blogspot.com/ > http://lasu2string.blogspot.com/ > -- Cheers, Paul From develop4lasu at gmail.com Mon Mar 31 22:25:25 2014 From: develop4lasu at gmail.com (=?UTF-8?Q?Marek_Kozie=C5=82?=) Date: Tue, 1 Apr 2014 00:25:25 +0200 Subject: Implicit 'this' return for void methods In-Reply-To: References: <0EFE68B5-0F74-4D0B-971F-FDDD05C00981@gmail.com> <1396113604.229343390.ozv0hsr6@frv39.fwdcdn.com> Message-ID: 2014-03-31 22:44 GMT+02:00 Paul Benedict : > What about opting in? By that, I mean that these void methods must have a > specific TYPE_USE annotation on them at compile time to allow chaining. > > This idea would require a JLS update to allow type annotations on void > return values -- perhaps exclusive to this annotation. > > I was thinking about : void method() to be equivalent, or maybe noted as : this method() And void function to be replaced with specific class like(I use this here and there when direct use of void is not possible and this work pretty well): java.lang.Void methid(); or maybe noted as: null method(); So hopefully this would fit language peaty well. Any way it's to early for me to comprehend influence of such big change. I do not like such know-how solutions. -- Pozdrawiam Marek Kozie? ( Lasu ) http://na-chlodno.blogspot.com/ http://lasu2string.blogspot.com/