From steve.drach at oracle.com Thu Oct 1 00:21:39 2015 From: steve.drach at oracle.com (Steve Drach) Date: Wed, 30 Sep 2015 17:21:39 -0700 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <22FF6E94-59B4-4D76-8024-56DB34BA328F@oracle.com> References: <7659C060-0EBC-4FC2-B20E-9CCB3B93A2C5@oracle.com> <3FAC60D0-97D6-46E5-A235-075317989275@oracle.com> <560C2F28.8020603@oracle.com> <22FF6E94-59B4-4D76-8024-56DB34BA328F@oracle.com> Message-ID: <3587735D-D62C-4EDA-B5F6-D159BA98491A@oracle.com> >>> The jarsigner from jdk9/dev can not, giving me the error >>> >>> jarsigner: unable to sign jar: javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty >>> >>> I?m unsure what that means, and searching for it has not turned up anything useful except that it might be limited to Mac OS/X. If anyone can help me here, I?d appreciate it. >> >> This means it could not find a trusted root CA from the cacerts file to validate the certificate chain. By default, OpenJDK includes an empty cacerts file. You need to do a jdk9 build with the closed sources, as that is where the trusted roots are. > > If this is the problem, I think it's a bug. When jarsigner is signing it uses a key pair inside a keystone specified by -keystore. I don't see a reason why cacerts must be populated. I copied a cacerts file from an official Oracle early access release of JDK 9 and it started working. > > Can you add a -debug option to show the full exception stack info? I even could not see how SSL is involved here. Would you still like me to do this? From stuart.marks at oracle.com Thu Oct 1 01:16:32 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 30 Sep 2015 18:16:32 -0700 Subject: P.S.: RFR [9] 8133651: automated replacing of old-style tags in docs In-Reply-To: References: <740a3bdd-3a72-44ec-b51f-83c98cac07ca@default> <560A6628.5010807@oracle.com> Message-ID: <560C8970.50805@oracle.com> Hi Alexander, Martin, The challenge of Perl file slurping and Emacs one-liners was too much to bear. This is Java, so one-liners are hardly possible. Still, there are a bunch of improvements that can be made to the Java version. (OK, and I'm showing off a bit.) Take a look at this: http://cr.openjdk.java.net/~smarks/misc/SimpleTagEditorSmarks1.java I haven't studied the output exhaustively, but it seems to do a reasonably good job for the common cases. I ran it over java.lang and I noticed a few cases where there is markup embedded within text, which should be looked at more closely. I don't particularly care if you use my version, but there are some techniques that I'd strongly recommend that you consider using in any such tool. In particular: - Pattern.DOTALL to do multi-line matches - Pattern.CASE_INSENSITIVE - try-with-resources to ensure that files are closed properly - NIO instead of old java.io APIs, particularly Files.walk() and streams - use Scanner to deal with input file buffering - Scanner's stream support (I recently added this to JDK 9) Enjoy, s'marks On 9/29/15 2:23 PM, Martin Buchholz wrote: > Hi Alexander, > > your change looks good. It's OK to have manual corrections for automated > mega-changes like this, as long as they all revert changes. > > Random comments: > > Should you publish your specdiff? I guess not - it would be empty! > > while((s = br.readLine()) != null) { > > by matching only one line at a time, you lose the ability to make > replacements that span lines. Perlers like to "slurp" in the entire file > as a single string. > > s = s.replace( "", tag1); > s = s.replace( "", tag1); > s = s.replace("", tag2); > s = s.replace("", tag2); > > Why not use case-insensitive regex? > > Here's an emacs-lisp one-liner I've been known to use: > > (defun tt-code () > (interactive) > (query-replace-regexp "<\\(tt\\|code\\)>\\([^&<>\\\\]+\\)" "{@code > \\2}")) > > With more work, one can automate transformation of embedded things like < > > But of course, it's not even possible to transform ALL uses of to > {@code, if there was imaginative use of nested html tags. > > > On Tue, Sep 29, 2015 at 3:21 AM, Alexander Stepanov < > alexander.v.stepanov at oracle.com> wrote: > >> Updated: a few manual corrections were made (as @linkplain tags displays >> nested {@code } literally): >> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch >> -checked with specdiff (which of course does not cover documentation for >> internal packages), no unexpected diffs detected. >> >> Regards, >> Alexander >> >> >> On 9/27/2015 4:52 PM, Alexander Stepanov wrote: >> >>> Hello Martin, >>> >>> Here is some simple app. to replace tags with a new-style >>> {@code } one (which is definitely not so elegant as the Perl one-liners): >>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/SimpleTagEditor.java >>> >>> Corresponding patch for jdk and replacement log (~62k of the tag changes): >>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch >>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/replace.log >>> (sorry, I have to check the correctness of the patch with specdiff yet, >>> so this is rather demo at the moment). >>> >>> Don't know if these changes (cosmetic by nature) are desired for now or >>> not. Moreover, probably some part of them should go to another repos (e.g., >>> awt, swing -> "client" instead of "dev"). >>> >>> Regards, >>> Alexander >>> >>> >>> >>> ----- ???????? ????????? ----- >>> ??: alexander.v.stepanov at oracle.com >>> ????: martinrb at google.com >>> ?????: core-libs-dev at openjdk.java.net >>> ????????????: ???????, 24 ???????? 2015 ? 16:06:56 GMT +03:00 ??????, >>> ?????-?????????, ????????? >>> ????: Re: RFR [9] 8133651: replace some tags (obsolete in html5) in >>> core-libs docs >>> >>> Hello Martin, >>> >>> Thank you for review and for the notes! >>> >>> > I'm biased of course, but I like the approach I took with >>> blessed-modifier-order: >>> > - make the change completely automated >>> > - leave "human editing" for a separate change >>> > - publish the code used to make the automated change (in my case, >>> typically a perl one-liner) >>> >>> Automated replacement has an obvious advantage: it is fast and massive. >>> But there are some disadvantages at the same time (just IMHO). >>> >>> Using script it is quite easy to miss some not very trivial cases, e.g.: >>> - remove unnecessary linebreaks, like >>> * someCode >>> * >>> (which would be better to replace with single-line {@code someCode}; >>> - joining of successive terms, like "ONE, TWO, >>> THREE" -> "{@code ONE, TWO, THREE}"; >>> - errors like extra or missing "<" or ">": * Collection >>> <T>", - there were a lot of them; >>> - some cases when should be replaced with , not >>> {@code } (e.g. because of unicode characters inside of code etc.); >>> - extra tags inside of or which should be moved outside of >>> {@code }, like someCode or someCode; >>> - simple removing of needless tags, like "{@link ...}" -> >>> "{@link ...}"; >>> - replace HTML codes with symbols ('<', '>', '@', ...) >>> - etc. >>> - plus some other formatting changes and fixes for misprints which would >>> be omitted during the automated replacement (and wouldn't be done in >>> future manually because there is no motivation for repeated processing). >>> >>> So sometimes it may be difficult to say where is the border between >>> "trivial" and "human-editing" cases (and the portion of "non-trivial >>> cases" is definitely not minor); moreover, even the automated >>> replacement requires the subsequent careful review before publishing of >>> webrev (as well as by reviewers who probably wouldn't be happy to review >>> hundreds of files at the same time) and iterative checks/corrections. >>> specdiff is very useful for this task but also cannot fully cover the >>> diffs (as some changes are situated in the internal com/... sun/... >>> packages). >>> >>> Moreover, I'm sure that some reviewers would be annoyed with the fact >>> that some (quite simple) changes were postponed because they are "not >>> too trivial to be fixed just now" (because they will suspect they would >>> be postponed forever). So the patch creator would (probably) receive >>> some advices during the review like "please fix also fix this and that" >>> (which is normal, of course). >>> >>> So my preference was to make the changes package by package (in some >>> reasonable amount of files) not postponing part of the changes for the >>> future (sorry for these boring repeating review requests). Please note >>> that all the above mentioned is *rather explanation of my motivation >>> than objection* :) (and of course I used some text editor replace >>> automation which is surely not so advanced as Perl). >>> >>> > It's probably correct, but I would have left it out of this change >>> Yes, I see. Reverted (please update the web page): >>> http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/index.html >>> >>> Thanks, >>> Alexander >>> >>> P.S. The replacement job is mostly (I guess, ~80%) complete. But >>> probably this approach should be used if some similar replacement task >>> for, e.g., tags would be planned in future (there are >>> thousands of them). >>> >>> >>> On 9/24/2015 6:10 AM, Martin Buchholz wrote: >>> >>>> >>>> On Sat, Sep 19, 2015 at 6:58 AM, Alexander Stepanov >>>> >>> > wrote: >>>> >>>> Hello, >>>> >>>> Could you please review the following fix >>>> http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/ >>>> >>>> http://cr.openjdk.java.net/~avstepan/8133651/jaxws.00/index.html >>>> >>>> >>>> for >>>> https://bugs.openjdk.java.net/browse/JDK-8133651 >>>> >>>> Just another portion of deprecated (and ) tags replaced >>>> with {@code }. Some misprints were also fixed. >>>> >>>> >>>> I'm biased of course, but I like the approach I took with >>>> blessed-modifier-order: >>>> - make the change completely automated >>>> - leave "human editing" for a separate change >>>> - publish the code used to make the automated change (in my case, >>>> typically a perl one-liner) >>>> >>>> >>>> The following (expected) changes were detected by specdiff: >>>> - removed needless dashes in java.util.Locale, >>>> - removed needless curly brace in xml.bind.annotation.XmlElementRef >>>> >>>> >>>> I would do a separate automated "removed needless dashes" changeset. >>>> >>>> >>>> Please let me know if the following changes are desirable or not: >>>> >>>> http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html >>>> < >>>> http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html >>>>> >>>> >>>> >>>> This is an actual change to the behavior of this code - the >>>> maintainers of jconsole need to approve it. It's probably correct, >>>> but I would have left it out of this change. If you remove it, then I >>>> approve this change. >>>> >>> >> From weijun.wang at oracle.com Thu Oct 1 02:58:17 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 1 Oct 2015 10:58:17 +0800 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <3587735D-D62C-4EDA-B5F6-D159BA98491A@oracle.com> References: <A12C71A8-59AB-4271-873F-4F3435EB2493@oracle.com> <7659C060-0EBC-4FC2-B20E-9CCB3B93A2C5@oracle.com> <3FAC60D0-97D6-46E5-A235-075317989275@oracle.com> <560C2F28.8020603@oracle.com> <22FF6E94-59B4-4D76-8024-56DB34BA328F@oracle.com> <3587735D-D62C-4EDA-B5F6-D159BA98491A@oracle.com> Message-ID: <FCA5B559-4423-45E6-BAF5-8A2CD4BC70EC@oracle.com> > ? 2015?10?1????8:21?Steve Drach <steve.drach at oracle.com> ??? > >> Can you add a -debug option to show the full exception stack info? I even could not see how SSL is involved here. > > Would you still like me to do this? Yes, please. I cannot reproduce the problem in my jdk9 repo using a public cacerts file. If possible, can you also show me the jar file? Although I cannot figure out how special a jar file can be. --Max From martinrb at google.com Thu Oct 1 06:54:15 2015 From: martinrb at google.com (Martin Buchholz) Date: Wed, 30 Sep 2015 23:54:15 -0700 Subject: P.S.: RFR [9] 8133651: automated replacing of old-style tags in docs In-Reply-To: <560C8970.50805@oracle.com> References: <740a3bdd-3a72-44ec-b51f-83c98cac07ca@default> <560A6628.5010807@oracle.com> <CA+kOe0_RoiEvvquZ-5aJ401b1oePuDG+7vd0ufzgctpFhUfaLA@mail.gmail.com> <560C8970.50805@oracle.com> Message-ID: <CA+kOe0-YkE_886K0b_OY4G7kmunx9eTG0rxhaoVt8YKUsixFHA@mail.gmail.com> Hi s'marks, You probably don't need to absolutify paths. And you can easily handle multiple args. (just for fun!) Checks for javadoc comment; handles popular html entities; handles multiple lines; handles both tt and code: #!/bin/bash find "$@" -name '*.java' | \ xargs -r perl -p0777i -e \ 'do {} while s~^ *\*.*\K<(tt|code)>((?:[^<>{}\&\@]|&(?:lt|gt|amp);)*)</\1>~$_=$2; s/&lt;/</g; s/&gt;/>/g; s/&amp;/&/g; "{\@code $_}"~mgie' On Wed, Sep 30, 2015 at 6:16 PM, Stuart Marks <stuart.marks at oracle.com> wrote: > Hi Alexander, Martin, > > The challenge of Perl file slurping and Emacs one-liners was too much to > bear. > > This is Java, so one-liners are hardly possible. Still, there are a bunch > of improvements that can be made to the Java version. (OK, and I'm showing > off a bit.) > > Take a look at this: > > http://cr.openjdk.java.net/~smarks/misc/SimpleTagEditorSmarks1.java > > I haven't studied the output exhaustively, but it seems to do a reasonably > good job for the common cases. I ran it over java.lang and I noticed a few > cases where there is markup embedded within <code></code> text, which > should be looked at more closely. > > I don't particularly care if you use my version, but there are some > techniques that I'd strongly recommend that you consider using in any such > tool. In particular: > > - Pattern.DOTALL to do multi-line matches > - Pattern.CASE_INSENSITIVE > - try-with-resources to ensure that files are closed properly > - NIO instead of old java.io APIs, particularly Files.walk() and streams > - use Scanner to deal with input file buffering > - Scanner's stream support (I recently added this to JDK 9) > > Enjoy, > > s'marks > > > > On 9/29/15 2:23 PM, Martin Buchholz wrote: > >> Hi Alexander, >> >> your change looks good. It's OK to have manual corrections for automated >> mega-changes like this, as long as they all revert changes. >> >> Random comments: >> >> Should you publish your specdiff? I guess not - it would be empty! >> >> while((s = br.readLine()) != null) { >> >> by matching only one line at a time, you lose the ability to make >> replacements that span lines. Perlers like to "slurp" in the entire file >> as a single string. >> >> s = s.replace( "<CODE>", tag1); >> s = s.replace( "<Code>", tag1); >> s = s.replace("</CODE>", tag2); >> s = s.replace("</Code>", tag2); >> >> Why not use case-insensitive regex? >> >> Here's an emacs-lisp one-liner I've been known to use: >> >> (defun tt-code () >> (interactive) >> (query-replace-regexp "<\\(tt\\|code\\)>\\([^&<>\\\\]+\\)</\\1>" >> "{@code >> \\2}")) >> >> With more work, one can automate transformation of embedded things like >> &lt; >> >> But of course, it's not even possible to transform ALL uses of <code> to >> {@code, if there was imaginative use of nested html tags. >> >> >> On Tue, Sep 29, 2015 at 3:21 AM, Alexander Stepanov < >> alexander.v.stepanov at oracle.com> wrote: >> >> Updated: a few manual corrections were made (as @linkplain tags displays >>> nested {@code } literally): >>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch >>> -checked with specdiff (which of course does not cover documentation for >>> internal packages), no unexpected diffs detected. >>> >>> Regards, >>> Alexander >>> >>> >>> On 9/27/2015 4:52 PM, Alexander Stepanov wrote: >>> >>> Hello Martin, >>>> >>>> Here is some simple app. to replace <code></code> tags with a new-style >>>> {@code } one (which is definitely not so elegant as the Perl >>>> one-liners): >>>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/SimpleTagEditor.java >>>> >>>> Corresponding patch for jdk and replacement log (~62k of the tag >>>> changes): >>>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch >>>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/replace.log >>>> (sorry, I have to check the correctness of the patch with specdiff yet, >>>> so this is rather demo at the moment). >>>> >>>> Don't know if these changes (cosmetic by nature) are desired for now or >>>> not. Moreover, probably some part of them should go to another repos >>>> (e.g., >>>> awt, swing -> "client" instead of "dev"). >>>> >>>> Regards, >>>> Alexander >>>> >>>> >>>> >>>> ----- ???????? ????????? ----- >>>> ??: alexander.v.stepanov at oracle.com >>>> ????: martinrb at google.com >>>> ?????: core-libs-dev at openjdk.java.net >>>> ????????????: ???????, 24 ???????? 2015 ? 16:06:56 GMT +03:00 ??????, >>>> ?????-?????????, ????????? >>>> ????: Re: RFR [9] 8133651: replace some <tt> tags (obsolete in html5) in >>>> core-libs docs >>>> >>>> Hello Martin, >>>> >>>> Thank you for review and for the notes! >>>> >>>> > I'm biased of course, but I like the approach I took with >>>> blessed-modifier-order: >>>> > - make the change completely automated >>>> > - leave "human editing" for a separate change >>>> > - publish the code used to make the automated change (in my case, >>>> typically a perl one-liner) >>>> >>>> Automated replacement has an obvious advantage: it is fast and massive. >>>> But there are some disadvantages at the same time (just IMHO). >>>> >>>> Using script it is quite easy to miss some not very trivial cases, e.g.: >>>> - remove unnecessary linebreaks, like >>>> * <tt>someCode >>>> * </tt> >>>> (which would be better to replace with single-line {@code someCode}; >>>> - joining of successive terms, like "<tt>ONE</tt>, <tt>TWO</tt>, >>>> <tt>THREE</tt>" -> "{@code ONE, TWO, THREE}"; >>>> - errors like extra or missing "&lt;" or "&gt;": * <tt>Collection >>>> &lt;T></tt>", - there were a lot of them; >>>> - some cases when <tt></tt> should be replaced with <code></code>, not >>>> {@code } (e.g. because of unicode characters inside of code etc.); >>>> - extra tags inside of <tt> or <code> which should be moved outside of >>>> {@code }, like <tt><i>someCode</i></tt> or <tt><b>someCode</b></tt>; >>>> - simple removing of needless tags, like "<tt>{@link ...}</tt>" -> >>>> "{@link ...}"; >>>> - replace HTML codes with symbols ('<', '>', '@', ...) >>>> - etc. >>>> - plus some other formatting changes and fixes for misprints which would >>>> be omitted during the automated replacement (and wouldn't be done in >>>> future manually because there is no motivation for repeated processing). >>>> >>>> So sometimes it may be difficult to say where is the border between >>>> "trivial" and "human-editing" cases (and the portion of "non-trivial >>>> cases" is definitely not minor); moreover, even the automated >>>> replacement requires the subsequent careful review before publishing of >>>> webrev (as well as by reviewers who probably wouldn't be happy to review >>>> hundreds of files at the same time) and iterative checks/corrections. >>>> specdiff is very useful for this task but also cannot fully cover the >>>> diffs (as some changes are situated in the internal com/... sun/... >>>> packages). >>>> >>>> Moreover, I'm sure that some reviewers would be annoyed with the fact >>>> that some (quite simple) changes were postponed because they are "not >>>> too trivial to be fixed just now" (because they will suspect they would >>>> be postponed forever). So the patch creator would (probably) receive >>>> some advices during the review like "please fix also fix this and that" >>>> (which is normal, of course). >>>> >>>> So my preference was to make the changes package by package (in some >>>> reasonable amount of files) not postponing part of the changes for the >>>> future (sorry for these boring repeating review requests). Please note >>>> that all the above mentioned is *rather explanation of my motivation >>>> than objection* :) (and of course I used some text editor replace >>>> automation which is surely not so advanced as Perl). >>>> >>>> > It's probably correct, but I would have left it out of this change >>>> Yes, I see. Reverted (please update the web page): >>>> http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/index.html >>>> >>>> Thanks, >>>> Alexander >>>> >>>> P.S. The <tt> replacement job is mostly (I guess, ~80%) complete. But >>>> probably this approach should be used if some similar replacement task >>>> for, e.g., <code></code> tags would be planned in future (there are >>>> thousands of them). >>>> >>>> >>>> On 9/24/2015 6:10 AM, Martin Buchholz wrote: >>>> >>>> >>>>> On Sat, Sep 19, 2015 at 6:58 AM, Alexander Stepanov >>>>> <alexander.v.stepanov at oracle.com >>>>> <mailto:alexander.v.stepanov at oracle.com>> wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you please review the following fix >>>>> http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/ >>>>> <http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/> >>>>> http://cr.openjdk.java.net/~avstepan/8133651/jaxws.00/index.html >>>>> < >>>>> http://cr.openjdk.java.net/%7Eavstepan/8133651/jaxws.00/index.html >>>>> >>>>>> >>>>>> for >>>>> https://bugs.openjdk.java.net/browse/JDK-8133651 >>>>> >>>>> Just another portion of deprecated <tt> (and <xmp>) tags replaced >>>>> with {@code }. Some misprints were also fixed. >>>>> >>>>> >>>>> I'm biased of course, but I like the approach I took with >>>>> blessed-modifier-order: >>>>> - make the change completely automated >>>>> - leave "human editing" for a separate change >>>>> - publish the code used to make the automated change (in my case, >>>>> typically a perl one-liner) >>>>> >>>>> >>>>> The following (expected) changes were detected by specdiff: >>>>> - removed needless dashes in java.util.Locale, >>>>> - removed needless curly brace in >>>>> xml.bind.annotation.XmlElementRef >>>>> >>>>> >>>>> I would do a separate automated "removed needless dashes" changeset. >>>>> >>>>> >>>>> Please let me know if the following changes are desirable or not: >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html >>>>> < >>>>> >>>>> http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html >>>>> >>>>>> >>>>>> >>>>> >>>>> This is an actual change to the behavior of this code - the >>>>> maintainers of jconsole need to approve it. It's probably correct, >>>>> but I would have left it out of this change. If you remove it, then I >>>>> approve this change. >>>>> >>>>> >>>> >>> From miroslav.kos at oracle.com Thu Oct 1 08:26:03 2015 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Thu, 1 Oct 2015 10:26:03 +0200 Subject: [9] Review request JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader In-Reply-To: <560C003F.8070801@oracle.com> References: <55D5E163.6090905@oracle.com> <55F2F9F4.5090309@oracle.com> <56054D74.3070903@oracle.com> <560BF6AD.60204@oracle.com> <560C003F.8070801@oracle.com> Message-ID: <560CEE1B.5090304@oracle.com> On 30/09/15 17:31, Miroslav Kos wrote: > On 30/09/15 16:50, Georgiy Rakov wrote: >> 2. This is not related to ServiceLoader feature, but anyway - >> SAAJMetaFactory.java: >> >> 30 * SAAJ API./_*All *_//_*of the {@code newInstance} methods defined on factories*_/ in >> 31 * SAAJ 1.3 defer to instances of this class to do the actual object creation. >> >> Namely it says that /_*all*_/**the newInstance methods defined on >> factories delegate factory creation to SAAJMetaFactory instances, but >> this seems to be not exactly true because SOAPConnectionFactory is >> not created by SAAJMetaFactory instance. > Yes, good catch. To fix it, it would be good to add a new abstract method > public abstract SOAPConnectionFactory newSOAPConnectionFactory() > throws SOAPException, UnsupportedOperationException > > Would you agree, Deva, Chen? There is a problem with backwards > compatibility here ... More defensive would be to name the two > factories instead of saying "all"? Any opinion on this, anybody? Thanks Miran > > Thanks > Miran > > Btw. I sent this RFR initially to wrong mailing lists, would you check > when answering that it's to Core-Libs-Dev > <core-libs-dev at openjdk.java.net> ? > >> >> Thank you, >> Georgiy. >> > From weijun.wang at oracle.com Thu Oct 1 09:10:47 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 1 Oct 2015 17:10:47 +0800 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <BE0A18A1-CA02-472C-9C61-31982CE4AC0D@oracle.com> References: <A12C71A8-59AB-4271-873F-4F3435EB2493@oracle.com> <7659C060-0EBC-4FC2-B20E-9CCB3B93A2C5@oracle.com> <BE0A18A1-CA02-472C-9C61-31982CE4AC0D@oracle.com> Message-ID: <B4B78415-1428-45CE-9E06-7D16F3969806@oracle.com> > ? 2015?10?1????7:53?Steve Drach <steve.drach at oracle.com> ??? > > - JDK 8 jar signer does not work with a JDK 9 created keystore > - JDK 8 signed jar with JDK 8 created keystore is not the same size as JDK 9 signed jar with JDK 9 keystore > - JDK 8 signed jar with JDK 8 created keystore is not the same size as JDK 9 signed jar with the same JDK 8 keystore The default keystore type in jdk9 is pkcs12. I guess this is why jarsigner in jdk8 does not recognize it. As for the size, I guess the default signature algorithm or key size might not be the same, say, SHA1withRSA -> SHA256withRSA or 1024 to 2048. --Max From georgiy.rakov at oracle.com Thu Oct 1 11:17:51 2015 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Thu, 1 Oct 2015 14:17:51 +0300 Subject: [9] Review request JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader In-Reply-To: <560BFAED.4070802@oracle.com> References: <55D5E163.6090905@oracle.com> <55F2F9F4.5090309@oracle.com> <56054D74.3070903@oracle.com> <56059161.2010808@oracle.com> <560A95E8.30907@oracle.com> <47E51B07-4FA1-4C13-9F8C-450B44C8FE20@oracle.com> <560BE098.7090809@oracle.com> <1ACCA360-ED4B-4A06-B0AD-52F14E604FCD@oracle.com> <560BFAED.4070802@oracle.com> Message-ID: <560D165F.4030808@oracle.com> On 30.09.2015 18:08, Miroslav Kos wrote: > > > On 30/09/15 16:20, Deva Sagar wrote: >> Hi Georgiy, >> >> I think both Miran and I are referring to the mention of >> SAAJMetaFactory in the bullet list about the public newInstance() >> method. The Javadoc of the SAAJMetaFactory class still describes it >> as an SPI and it is accessible from package-info. This is no >> different from the current public Javadocs. >> >> Thanks, >> Deva >> >> >>> On Sep 30, 2015, at 9:16 AM, Georgiy Rakov <georgiy.rakov at oracle.com >>> <mailto:georgiy.rakov at oracle.com>> wrote: >>> >>> >>> >>> On 29.09.2015 17:43, Deva Sagar wrote: >>>> Hi Miran, >>>> >>>> Sorry for the delay in responding to this - I was busy with WLS >>>> release close down, and now I have moved to a different job in the >>>> cloud organization outside of WLS and web services. >>>> >>>> Regarding your question in #3 - I think Georgiy made a good >>>> observation about SAAJMetaFactory - making a public newInstance >>>> method as you suggest would make it agree with the package-info, >>>> but does not correspond to the API specification. The package-info >>>> in Java SE 8 API docs says "SAAJMetaFactory is a service provider >>>> interface. There are no public methods on this class.? If we put in >>>> a public newInstance() method, it does not agree with this >>>> statement in API Javadoc. It might be better in my opinion to >>>> remove SAAJMetaFactory mention from package-info.java unless there >>>> is a good reason to keep it. >>>> >>> Hello, >>> >>> according to my understanding the idea of SAAJMetaFactory is for SPI >>> developer to subclass it and thus to create a custom SAAJMetaFactory >>> implementation. > Yes, it's current state - the only description of lookup/instantiation > user SAAJMetaFactory is statement that it is service provider > interaface (stays unchanged): > https://docs.oracle.com/javase/8/docs/api/javax/xml/soap/SAAJMetaFactory.html > Service loader is the only specification here. >>> Afterwards user should configure SAAJ API in order it could use that >>> custom implementation. > User configuration controls discovery of implementation when used > newInstance method on other factories (MessageFactory, SOAPFactory, > SOAPConnectionFactory). If no implementation found, the fallback is > user (or default) SAAJMetaFactory.newXXXFactory() >>> But if SAAJMetaFactory mention from package-info.java is removed >>> there will be actually no spec defining how to configure SAAJ API >>> for using custom SAAJMetaFactory, or do I miss spec defining it? > No, there is still statement about service provider interface. I believe then some link or hint should given in order it would be clear that ServiceLoader mechanism is used as a lookup procedure of SAAJMetaFactory implementation. Because for inexperienced user it's far from obvious that mentioning SPI means that ServiceLoader is used to discover SAAJMetaFactory implementation (even for me it wasn't :) ). Besides, do I understand correctly that other steps of lookup procedure will still be used by JDK in order to discover SAAJMetaFactory implementation? If this is true I don't think it's a good idea to hide them by not displaying in spec, since external Java SE implementers like IBM and others are required to implement just those steps which are provided by spec, as well as Java SE compatible application is required to use just those steps which are in spec. So if an Oracle JDK user writes an application using this "hidden" feature, which he is aware of for some reason, there is no guarantee that such application will work fine with an external Java SE implementation. However I understand that removing this from spec simplifies SAAJ API I'm not sure that this simplifying is worthwhile for the reasons presented above. Thanks, Georgiy. >>> BTW: from this perspective referring to SAAJMetaFactory newInstance >>> method in spec is not relevant since it's SAAJ API implementation >>> internal machinery. > Yes, it is internal. > > Actually I thing SAAJ API is pretty complicated already, so not adding > another spec for SAAJMetaFactory discovery is good idea ... > > Thanks > Miran > > >>> >>> So I believe if SAAJMetaFactory mention from package-info.java is >>> removed the process of SAAJMetaFactory instantiation should be >>> described somehow in another place and without mentioning >>> newInstance method. Maybe it's worth rather modifying than removing >>> this mentioning in package-info.java? >>> >>> Thanks, >>> Georgiy. >>> >>>> The rest of your changes look ok to me. Also cc?ing Chen for any >>>> additional comments >>>> >>>> Deva >>>> >>>> >>>> >>>>> On Sep 29, 2015, at 9:45 AM, Miroslav Kos >>>>> <miroslav.kos at oracle.com> wrote: >>>>> >>>>> On 25/09/15 20:24, Georgiy Rakov wrote: >>>>>> Hello Miroslav, >>>>>> >>>>>> sorry for delay, was busy due to deadlines. >>>>>> >>>>>> I think it's just spec I am to review. Some comments for the >>>>>> moment please see below: >>>>>> >>>>>> 1. package-info.java: >>>>>> >>>>>> * <li>Checks if a system property with the same name as the factory class is set (/_*i.e.*_/ >>>>>> * {@code javax.xml.soap.SOAPFactory}). >>>>>> >>>>>> I guess "e.g." is meant, that is "for example"? >>>>> Sure, thanks. >>>>>> >>>>>> 2. SAAJMetaFactory.java: >>>>>> >>>>>> Following is specified normatively: >>>>>> 62 * <p>Property {@code javax.xml.soap.MetaFactory} used in previous >>>>>> 63 * specifications (up to 1.3) is still supported, but it is strongly recommended to migrate to new property >>>>>> 64 * {@code javax.xml.soap.SAAJMetaFactory}. >>>>>> while in package-info.java: the same idea is specified as API >>>>>> note that is non-normatively: >>>>>> * @apiNote >>>>>> * <p>For {@link javax.xml.soap.SAAJMetaFactory}, property {@code javax.xml.soap.MetaFactory} used in previous >>>>>> * specifications (up to 1.3) is still supported, but it is strongly recommended to migrate to new property >>>>>> * {@code javax.xml.soap.SAAJMetaFactory}. >>>>>> */ >>>>>> I believe this idea should be specified everywhere the same way >>>>>> that is either normatively or non-normatively. If it's to be >>>>>> defined normatively more details should be specified I believe. >>>>> Made non-normative. >>>>>> >>>>>> 3. SAAJMetaFactory.getInstance method is package private. So: >>>>>> - This method is not supposed to be used by users, is it? >>>>>> - The javadoc of this method isn't actually a public >>>>>> specification. Thus Oracle claims nothing by it and external Java >>>>>> SE implementers are not required to follow this JavaDoc, that is >>>>>> this JavaDoc is intended to be used internally only, isn't it? >>>>>> I understand that this was before, but It looks very strange. Is >>>>>> this really not a mistake? BTW: this method and spec are not >>>>>> visible in API JavaDoc >>>>>> <https://docs.oracle.com/javase/8/docs/api/javax/xml/soap/SAAJMetaFactory.html>. >>>>>> >>>>>> It looks like a mistake moreover because public specification >>>>>> defined in package-info.java being reviewed refers to it: >>>>>> * There are several factories defined in the SAAJ API to discover and load specific implementation: >>>>>> * >>>>>> * <ul> >>>>>> * <li>{@link javax.xml.soap.SOAPFactory} >>>>>> * <li>{@link javax.xml.soap.MessageFactory} >>>>>> * <li>{@link javax.xml.soap.SOAPConnectionFactory} >>>>>> /_** <li>{@link javax.xml.soap.SAAJMetaFactory}*_/ >>>>>> * </ul> >>>>>> * >>>>>> * These factories define {@code/_*newInstance()*_/} method which uses a common lookup procedure to determine >>>>>> * the implementation class: >>>>> It's good catch - it looks like error. An easy fix would be change >>>>> the method to newInstance and make it public - Deva, would you agree? >>>>> http://cr.openjdk.java.net/~mkos/8131334/specdiff.04/index.html >>>>> >>>>> Anyway those are changes to API - should I withdraw >>>>> http://ccc.us.oracle.com/8131334 and create new one? >>>>> >>>>> Thanks >>>>> Miran >>>>> >>>>> >>>>> >>>>>> Thank you, >>>>>> Goergiy. >>>>>> >>>>>> On 25.09.2015 16:34, Miroslav Kos wrote: >>>>>>> Ping ... >>>>>>> >>>>>>> On 11/09/15 17:57, Miroslav Kos wrote: >>>>>>>> Hi again, >>>>>>>> would somebody find a time to review? >>>>>>>> >>>>>>>> Thanks >>>>>>>> Miran >>>>>>>> >>>>>>>> On 20/08/15 16:17, Miroslav Kos wrote: >>>>>>>>> Hi everybody, >>>>>>>>> >>>>>>>>> I am sending changes for review for >>>>>>>>> JDK-8131334: SAAJ Plugability Layer: using >>>>>>>>> java.util.ServiceLoader >>>>>>>>> >>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8131334 >>>>>>>>> webrev: http://cr.openjdk.java.net/~mkos/8131334/jaxws.01/ >>>>>>>>> >>>>>>>>> It's about migrating to standard java.util.ServiceLoader. This >>>>>>>>> part of service discovery was implemented previously "own" >>>>>>>>> way. There are some changes in javadoc and implementation has >>>>>>>>> been refactored in order to use same code as in JAX-WS and JAX-B. >>>>>>>>> >>>>>>>>> Testing - I run JAX-WS unit tests (JAX-WS standalone repo), >>>>>>>>> JCK9 + new tests specificaly developed for testing service >>>>>>>>> discovery in SAAJ. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Miran >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From alexander.v.stepanov at oracle.com Thu Oct 1 11:31:39 2015 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Thu, 1 Oct 2015 14:31:39 +0300 Subject: P.S.: RFR [9] 8133651: automated replacing of old-style tags in docs In-Reply-To: <CA+kOe0-YkE_886K0b_OY4G7kmunx9eTG0rxhaoVt8YKUsixFHA@mail.gmail.com> References: <740a3bdd-3a72-44ec-b51f-83c98cac07ca@default> <560A6628.5010807@oracle.com> <CA+kOe0_RoiEvvquZ-5aJ401b1oePuDG+7vd0ufzgctpFhUfaLA@mail.gmail.com> <560C8970.50805@oracle.com> <CA+kOe0-YkE_886K0b_OY4G7kmunx9eTG0rxhaoVt8YKUsixFHA@mail.gmail.com> Message-ID: <560D199B.30708@oracle.com> Hello Martin, Stuart, Thank you for the notes, Yes, the initial utility is quite ugly, I just tried to prepare it as quickly as possible hoping that it covers the majority of "trivial" replace cases. Yes, it does not process multi-line <code> inclusions. > s = s.replace( "<CODE>", tag1); > s = s.replace( "<Code>", tag1); > s = s.replace("</CODE>", tag2); > s = s.replace("</Code>", tag2); - replaced with "s = ln.replaceAll("(?i)<code>", "<code>").replaceAll("(?i)</code>", "</code>");" Unfortunately my Perl/lisp knowledge are zero :) > Should you publish your specdiff? I guess not - it would be empty! For now it contains a single fixed misprint diff, but there are a few another misprints at the moment which I'd like to include in the patch as well. So if you don't have objections, I'll delay for a several days and then publish a final RFR (probably containing changes in some other repos like jaxws, corba or jaxp) which would be more formal (containing bug # and the final specdiff report). Thanks again, Alexander On 10/1/2015 9:54 AM, Martin Buchholz wrote: > Hi s'marks, > You probably don't need to absolutify paths. > And you can easily handle multiple args. > > (just for fun!) > Checks for javadoc comment; handles popular html entities; handles > multiple lines; handles both tt and code: > > #!/bin/bash > find "$@" -name '*.java' | \ > xargs -r perl -p0777i -e \ > 'do {} while s~^ > *\*.*\K<(tt|code)>((?:[^<>{}\&\@]|&(?:lt|gt|amp);)*)</\1>~$_=$2; > s/&lt;/</g; s/&gt;/>/g; s/&amp;/&/g; "{\@code $_}"~mgie' > > > On Wed, Sep 30, 2015 at 6:16 PM, Stuart Marks <stuart.marks at oracle.com > <mailto:stuart.marks at oracle.com>> wrote: > > Hi Alexander, Martin, > > The challenge of Perl file slurping and Emacs one-liners was too > much to bear. > > This is Java, so one-liners are hardly possible. Still, there are > a bunch of improvements that can be made to the Java version. (OK, > and I'm showing off a bit.) > > Take a look at this: > > http://cr.openjdk.java.net/~smarks/misc/SimpleTagEditorSmarks1.java <http://cr.openjdk.java.net/%7Esmarks/misc/SimpleTagEditorSmarks1.java> > > I haven't studied the output exhaustively, but it seems to do a > reasonably good job for the common cases. I ran it over java.lang > and I noticed a few cases where there is markup embedded within > <code></code> text, which should be looked at more closely. > > I don't particularly care if you use my version, but there are > some techniques that I'd strongly recommend that you consider > using in any such tool. In particular: > > - Pattern.DOTALL to do multi-line matches > - Pattern.CASE_INSENSITIVE > - try-with-resources to ensure that files are closed properly > - NIO instead of old java.io <http://java.io> APIs, particularly > Files.walk() and streams > - use Scanner to deal with input file buffering > - Scanner's stream support (I recently added this to JDK 9) > > Enjoy, > > s'marks > > > > On 9/29/15 2:23 PM, Martin Buchholz wrote: > > Hi Alexander, > > your change looks good. It's OK to have manual corrections > for automated > mega-changes like this, as long as they all revert changes. > > Random comments: > > Should you publish your specdiff? I guess not - it would be > empty! > > while((s = br.readLine()) != null) { > > by matching only one line at a time, you lose the ability to make > replacements that span lines. Perlers like to "slurp" in the > entire file > as a single string. > > s = s.replace( "<CODE>", tag1); > s = s.replace( "<Code>", tag1); > s = s.replace("</CODE>", tag2); > s = s.replace("</Code>", tag2); > > Why not use case-insensitive regex? > > Here's an emacs-lisp one-liner I've been known to use: > > (defun tt-code () > (interactive) > (query-replace-regexp > "<\\(tt\\|code\\)>\\([^&<>\\\\]+\\)</\\1>" "{@code > \\2}")) > > With more work, one can automate transformation of embedded > things like &lt; > > But of course, it's not even possible to transform ALL uses of > <code> to > {@code, if there was imaginative use of nested html tags. > > > On Tue, Sep 29, 2015 at 3:21 AM, Alexander Stepanov < > alexander.v.stepanov at oracle.com > <mailto:alexander.v.stepanov at oracle.com>> wrote: > > Updated: a few manual corrections were made (as @linkplain > tags displays > nested {@code } literally): > http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/jdk.patch> > -checked with specdiff (which of course does not cover > documentation for > internal packages), no unexpected diffs detected. > > Regards, > Alexander > > > On 9/27/2015 4:52 PM, Alexander Stepanov wrote: > > Hello Martin, > > Here is some simple app. to replace <code></code> tags > with a new-style > {@code } one (which is definitely not so elegant as > the Perl one-liners): > http://cr.openjdk.java.net/~avstepan/tmp/codeTags/SimpleTagEditor.java > <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/SimpleTagEditor.java> > > Corresponding patch for jdk and replacement log (~62k > of the tag changes): > http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch > <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/jdk.patch> > http://cr.openjdk.java.net/~avstepan/tmp/codeTags/replace.log > <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/replace.log> > (sorry, I have to check the correctness of the patch > with specdiff yet, > so this is rather demo at the moment). > > Don't know if these changes (cosmetic by nature) are > desired for now or > not. Moreover, probably some part of them should go to > another repos (e.g., > awt, swing -> "client" instead of "dev"). > > Regards, > Alexander > > > > ----- ???????? ????????? ----- > ??: alexander.v.stepanov at oracle.com > <mailto:alexander.v.stepanov at oracle.com> > ????: martinrb at google.com <mailto:martinrb at google.com> > ?????: core-libs-dev at openjdk.java.net > <mailto:core-libs-dev at openjdk.java.net> > ????????????: ???????, 24 ???????? 2015 ? 16:06:56 GMT > +03:00 ??????, > ?????-?????????, ????????? > ????: Re: RFR [9] 8133651: replace some <tt> tags > (obsolete in html5) in > core-libs docs > > Hello Martin, > > Thank you for review and for the notes! > > > I'm biased of course, but I like the approach I > took with > blessed-modifier-order: > > - make the change completely automated > > - leave "human editing" for a separate change > > - publish the code used to make the automated > change (in my case, > typically a perl one-liner) > > Automated replacement has an obvious advantage: it is > fast and massive. > But there are some disadvantages at the same time > (just IMHO). > > Using script it is quite easy to miss some not very > trivial cases, e.g.: > - remove unnecessary linebreaks, like > * <tt>someCode > * </tt> > (which would be better to replace with single-line > {@code someCode}; > - joining of successive terms, like "<tt>ONE</tt>, > <tt>TWO</tt>, > <tt>THREE</tt>" -> "{@code ONE, TWO, THREE}"; > - errors like extra or missing "&lt;" or "&gt;": * > <tt>Collection > &lt;T></tt>", - there were a lot of them; > - some cases when <tt></tt> should be replaced with > <code></code>, not > {@code } (e.g. because of unicode characters inside of > code etc.); > - extra tags inside of <tt> or <code> which should be > moved outside of > {@code }, like <tt><i>someCode</i></tt> or > <tt><b>someCode</b></tt>; > - simple removing of needless tags, like "<tt>{@link > ...}</tt>" -> > "{@link ...}"; > - replace HTML codes with symbols ('<', '>', '@', ...) > - etc. > - plus some other formatting changes and fixes for > misprints which would > be omitted during the automated replacement (and > wouldn't be done in > future manually because there is no motivation for > repeated processing). > > So sometimes it may be difficult to say where is the > border between > "trivial" and "human-editing" cases (and the portion > of "non-trivial > cases" is definitely not minor); moreover, even the > automated > replacement requires the subsequent careful review > before publishing of > webrev (as well as by reviewers who probably wouldn't > be happy to review > hundreds of files at the same time) and iterative > checks/corrections. > specdiff is very useful for this task but also cannot > fully cover the > diffs (as some changes are situated in the internal > com/... sun/... > packages). > > Moreover, I'm sure that some reviewers would be > annoyed with the fact > that some (quite simple) changes were postponed > because they are "not > too trivial to be fixed just now" (because they will > suspect they would > be postponed forever). So the patch creator would > (probably) receive > some advices during the review like "please fix also > fix this and that" > (which is normal, of course). > > So my preference was to make the changes package by > package (in some > reasonable amount of files) not postponing part of the > changes for the > future (sorry for these boring repeating review > requests). Please note > that all the above mentioned is *rather explanation of > my motivation > than objection* :) (and of course I used some text > editor replace > automation which is surely not so advanced as Perl). > > > It's probably correct, but I would have left it > out of this change > Yes, I see. Reverted (please update the web page): > http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/index.html > <http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/index.html> > > Thanks, > Alexander > > P.S. The <tt> replacement job is mostly (I guess, > ~80%) complete. But > probably this approach should be used if some similar > replacement task > for, e.g., <code></code> tags would be planned in > future (there are > thousands of them). > > > On 9/24/2015 6:10 AM, Martin Buchholz wrote: > > > On Sat, Sep 19, 2015 at 6:58 AM, Alexander Stepanov > <alexander.v.stepanov at oracle.com > <mailto:alexander.v.stepanov at oracle.com> > <mailto:alexander.v.stepanov at oracle.com > <mailto:alexander.v.stepanov at oracle.com>>> wrote: > > Hello, > > Could you please review the following fix > http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/ > <http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/> > > <http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/> > http://cr.openjdk.java.net/~avstepan/8133651/jaxws.00/index.html > <http://cr.openjdk.java.net/%7Eavstepan/8133651/jaxws.00/index.html> > > <http://cr.openjdk.java.net/%7Eavstepan/8133651/jaxws.00/index.html > > > for > https://bugs.openjdk.java.net/browse/JDK-8133651 > > Just another portion of deprecated <tt> (and > <xmp>) tags replaced > with {@code }. Some misprints were also fixed. > > > I'm biased of course, but I like the approach I > took with > blessed-modifier-order: > - make the change completely automated > - leave "human editing" for a separate change > - publish the code used to make the automated > change (in my case, > typically a perl one-liner) > > > The following (expected) changes were > detected by specdiff: > - removed needless dashes in java.util.Locale, > - removed needless curly brace in > xml.bind.annotation.XmlElementRef > > > I would do a separate automated "removed needless > dashes" changeset. > > > Please let me know if the following changes > are desirable or not: > > http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html > <http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html> > < > http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html > > > > > This is an actual change to the behavior of this > code - the > maintainers of jconsole need to approve it. It's > probably correct, > but I would have left it out of this change. If > you remove it, then I > approve this change. > > > > From sean.mullan at oracle.com Thu Oct 1 11:36:06 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 1 Oct 2015 07:36:06 -0400 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <B4B78415-1428-45CE-9E06-7D16F3969806@oracle.com> References: <A12C71A8-59AB-4271-873F-4F3435EB2493@oracle.com> <7659C060-0EBC-4FC2-B20E-9CCB3B93A2C5@oracle.com> <BE0A18A1-CA02-472C-9C61-31982CE4AC0D@oracle.com> <B4B78415-1428-45CE-9E06-7D16F3969806@oracle.com> Message-ID: <560D1AA6.5010807@oracle.com> On 10/1/15 5:10 AM, Wang Weijun wrote: > >> ? 2015?10?1????7:53?Steve Drach <steve.drach at oracle.com> ??? >> >> - JDK 8 jar signer does not work with a JDK 9 created keystore >> - JDK 8 signed jar with JDK 8 created keystore is not the same size as JDK 9 signed jar with JDK 9 keystore >> - JDK 8 signed jar with JDK 8 created keystore is not the same size as JDK 9 signed jar with the same JDK 8 keystore > > The default keystore type in jdk9 is pkcs12. I guess this is why jarsigner in jdk8 does not recognize it. It should work if you are using 8u60. What JDK 8 version are you using? --Sean From weijun.wang at oracle.com Thu Oct 1 12:31:54 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 1 Oct 2015 20:31:54 +0800 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <560D1AA6.5010807@oracle.com> References: <A12C71A8-59AB-4271-873F-4F3435EB2493@oracle.com> <7659C060-0EBC-4FC2-B20E-9CCB3B93A2C5@oracle.com> <BE0A18A1-CA02-472C-9C61-31982CE4AC0D@oracle.com> <B4B78415-1428-45CE-9E06-7D16F3969806@oracle.com> <560D1AA6.5010807@oracle.com> Message-ID: <3A51C7BE-463B-435B-BAA2-76BF7E8BF99B@oracle.com> > ? 2015?10?1????7:36?Sean Mullan <sean.mullan at oracle.com> ??? > > > > On 10/1/15 5:10 AM, Wang Weijun wrote: >> >>> ? 2015?10?1????7:53?Steve Drach <steve.drach at oracle.com> ??? >>> >>> - JDK 8 jar signer does not work with a JDK 9 created keystore >>> - JDK 8 signed jar with JDK 8 created keystore is not the same size as JDK 9 signed jar with JDK 9 keystore >>> - JDK 8 signed jar with JDK 8 created keystore is not the same size as JDK 9 signed jar with the same JDK 8 keystore >> >> The default keystore type in jdk9 is pkcs12. I guess this is why jarsigner in jdk8 does not recognize it. > > It should work if you are using 8u60. What JDK 8 version are you using? Steve is using 8u51. > > --Sean From lance.andersen at oracle.com Thu Oct 1 12:40:22 2015 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 1 Oct 2015 08:40:22 -0400 Subject: P.S.: RFR [9] 8133651: automated replacing of old-style tags in docs In-Reply-To: <560D199B.30708@oracle.com> References: <740a3bdd-3a72-44ec-b51f-83c98cac07ca@default> <560A6628.5010807@oracle.com> <CA+kOe0_RoiEvvquZ-5aJ401b1oePuDG+7vd0ufzgctpFhUfaLA@mail.gmail.com> <560C8970.50805@oracle.com> <CA+kOe0-YkE_886K0b_OY4G7kmunx9eTG0rxhaoVt8YKUsixFHA@mail.gmail.com> <560D199B.30708@oracle.com> Message-ID: <26045557-3AB1-450F-9D7D-571C7B39F2E8@oracle.com> Hi Alexander, Personally, I would find it easier to review if the changes were sent out by category/module vs one large patch as it is easier to miss things. Also for technologies such as jaxws, these will need to go to the external workspace at the same time for the technology so these should definitely be kept separate. Best Lance On Oct 1, 2015, at 7:31 AM, Alexander Stepanov <alexander.v.stepanov at oracle.com> wrote: > > > So if you don't have objections, I'll delay for a several days and then publish a final RFR (probably containing changes in some other repos like jaxws, corba or jaxp) which would be more formal (containing bug # and the final specdiff report). > > Thanks again, > Alexander > > > On 10/1/2015 9:54 AM, Martin Buchholz wrote: >> Hi s'marks, >> You probably don't need to absolutify paths. >> And you can easily handle multiple args. >> >> (just for fun!) >> Checks for javadoc comment; handles popular html entities; handles multiple lines; handles both tt and code: >> >> #!/bin/bash >> find "$@" -name '*.java' | \ >> xargs -r perl -p0777i -e \ >> 'do {} while s~^ *\*.*\K<(tt|code)>((?:[^<>{}\&\@]|&(?:lt|gt|amp);)*)</\1>~$_=$2; s/&lt;/</g; s/&gt;/>/g; s/&amp;/&/g; "{\@code $_}"~mgie' >> >> >> On Wed, Sep 30, 2015 at 6:16 PM, Stuart Marks <stuart.marks at oracle.com <mailto:stuart.marks at oracle.com>> wrote: >> >> Hi Alexander, Martin, >> >> The challenge of Perl file slurping and Emacs one-liners was too >> much to bear. >> >> This is Java, so one-liners are hardly possible. Still, there are >> a bunch of improvements that can be made to the Java version. (OK, >> and I'm showing off a bit.) >> >> Take a look at this: >> >> http://cr.openjdk.java.net/~smarks/misc/SimpleTagEditorSmarks1.java <http://cr.openjdk.java.net/%7Esmarks/misc/SimpleTagEditorSmarks1.java> >> >> I haven't studied the output exhaustively, but it seems to do a >> reasonably good job for the common cases. I ran it over java.lang >> and I noticed a few cases where there is markup embedded within >> <code></code> text, which should be looked at more closely. >> >> I don't particularly care if you use my version, but there are >> some techniques that I'd strongly recommend that you consider >> using in any such tool. In particular: >> >> - Pattern.DOTALL to do multi-line matches >> - Pattern.CASE_INSENSITIVE >> - try-with-resources to ensure that files are closed properly >> - NIO instead of old java.io <http://java.io> APIs, particularly >> Files.walk() and streams >> - use Scanner to deal with input file buffering >> - Scanner's stream support (I recently added this to JDK 9) >> >> Enjoy, >> >> s'marks >> >> >> >> On 9/29/15 2:23 PM, Martin Buchholz wrote: >> >> Hi Alexander, >> >> your change looks good. It's OK to have manual corrections >> for automated >> mega-changes like this, as long as they all revert changes. >> >> Random comments: >> >> Should you publish your specdiff? I guess not - it would be >> empty! >> >> while((s = br.readLine()) != null) { >> >> by matching only one line at a time, you lose the ability to make >> replacements that span lines. Perlers like to "slurp" in the >> entire file >> as a single string. >> >> s = s.replace( "<CODE>", tag1); >> s = s.replace( "<Code>", tag1); >> s = s.replace("</CODE>", tag2); >> s = s.replace("</Code>", tag2); >> >> Why not use case-insensitive regex? >> >> Here's an emacs-lisp one-liner I've been known to use: >> >> (defun tt-code () >> (interactive) >> (query-replace-regexp >> "<\\(tt\\|code\\)>\\([^&<>\\\\]+\\)</\\1>" "{@code >> \\2}")) >> >> With more work, one can automate transformation of embedded >> things like &lt; >> >> But of course, it's not even possible to transform ALL uses of >> <code> to >> {@code, if there was imaginative use of nested html tags. >> >> >> On Tue, Sep 29, 2015 at 3:21 AM, Alexander Stepanov < >> alexander.v.stepanov at oracle.com >> <mailto:alexander.v.stepanov at oracle.com>> wrote: >> >> Updated: a few manual corrections were made (as @linkplain >> tags displays >> nested {@code } literally): >> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/jdk.patch> >> -checked with specdiff (which of course does not cover >> documentation for >> internal packages), no unexpected diffs detected. >> >> Regards, >> Alexander >> >> >> On 9/27/2015 4:52 PM, Alexander Stepanov wrote: >> >> Hello Martin, >> >> Here is some simple app. to replace <code></code> tags >> with a new-style >> {@code } one (which is definitely not so elegant as >> the Perl one-liners): >> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/SimpleTagEditor.java >> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/SimpleTagEditor.java> >> >> Corresponding patch for jdk and replacement log (~62k >> of the tag changes): >> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch >> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/jdk.patch> >> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/replace.log >> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/replace.log> >> (sorry, I have to check the correctness of the patch >> with specdiff yet, >> so this is rather demo at the moment). >> >> Don't know if these changes (cosmetic by nature) are >> desired for now or >> not. Moreover, probably some part of them should go to >> another repos (e.g., >> awt, swing -> "client" instead of "dev"). >> >> Regards, >> Alexander >> >> >> >> ----- ???????? ????????? ----- >> ??: alexander.v.stepanov at oracle.com >> <mailto:alexander.v.stepanov at oracle.com> >> ????: martinrb at google.com <mailto:martinrb at google.com> >> ?????: core-libs-dev at openjdk.java.net >> <mailto:core-libs-dev at openjdk.java.net> >> ????????????: ???????, 24 ???????? 2015 ? 16:06:56 GMT >> +03:00 ??????, >> ?????-?????????, ????????? >> ????: Re: RFR [9] 8133651: replace some <tt> tags >> (obsolete in html5) in >> core-libs docs >> >> Hello Martin, >> >> Thank you for review and for the notes! >> >> > I'm biased of course, but I like the approach I >> took with >> blessed-modifier-order: >> > - make the change completely automated >> > - leave "human editing" for a separate change >> > - publish the code used to make the automated >> change (in my case, >> typically a perl one-liner) >> >> Automated replacement has an obvious advantage: it is >> fast and massive. >> But there are some disadvantages at the same time >> (just IMHO). >> >> Using script it is quite easy to miss some not very >> trivial cases, e.g.: >> - remove unnecessary linebreaks, like >> * <tt>someCode >> * </tt> >> (which would be better to replace with single-line >> {@code someCode}; >> - joining of successive terms, like "<tt>ONE</tt>, >> <tt>TWO</tt>, >> <tt>THREE</tt>" -> "{@code ONE, TWO, THREE}"; >> - errors like extra or missing "&lt;" or "&gt;": * >> <tt>Collection >> &lt;T></tt>", - there were a lot of them; >> - some cases when <tt></tt> should be replaced with >> <code></code>, not >> {@code } (e.g. because of unicode characters inside of >> code etc.); >> - extra tags inside of <tt> or <code> which should be >> moved outside of >> {@code }, like <tt><i>someCode</i></tt> or >> <tt><b>someCode</b></tt>; >> - simple removing of needless tags, like "<tt>{@link >> ...}</tt>" -> >> "{@link ...}"; >> - replace HTML codes with symbols ('<', '>', '@', ...) >> - etc. >> - plus some other formatting changes and fixes for >> misprints which would >> be omitted during the automated replacement (and >> wouldn't be done in >> future manually because there is no motivation for >> repeated processing). >> >> So sometimes it may be difficult to say where is the >> border between >> "trivial" and "human-editing" cases (and the portion >> of "non-trivial >> cases" is definitely not minor); moreover, even the >> automated >> replacement requires the subsequent careful review >> before publishing of >> webrev (as well as by reviewers who probably wouldn't >> be happy to review >> hundreds of files at the same time) and iterative >> checks/corrections. >> specdiff is very useful for this task but also cannot >> fully cover the >> diffs (as some changes are situated in the internal >> com/... sun/... >> packages). >> >> Moreover, I'm sure that some reviewers would be >> annoyed with the fact >> that some (quite simple) changes were postponed >> because they are "not >> too trivial to be fixed just now" (because they will >> suspect they would >> be postponed forever). So the patch creator would >> (probably) receive >> some advices during the review like "please fix also >> fix this and that" >> (which is normal, of course). >> >> So my preference was to make the changes package by >> package (in some >> reasonable amount of files) not postponing part of the >> changes for the >> future (sorry for these boring repeating review >> requests). Please note >> that all the above mentioned is *rather explanation of >> my motivation >> than objection* :) (and of course I used some text >> editor replace >> automation which is surely not so advanced as Perl). >> >> > It's probably correct, but I would have left it >> out of this change >> Yes, I see. Reverted (please update the web page): >> http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/index.html >> <http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/index.html> >> >> Thanks, >> Alexander >> >> P.S. The <tt> replacement job is mostly (I guess, >> ~80%) complete. But >> probably this approach should be used if some similar >> replacement task >> for, e.g., <code></code> tags would be planned in >> future (there are >> thousands of them). >> >> >> On 9/24/2015 6:10 AM, Martin Buchholz wrote: >> >> >> On Sat, Sep 19, 2015 at 6:58 AM, Alexander Stepanov >> <alexander.v.stepanov at oracle.com >> <mailto:alexander.v.stepanov at oracle.com> >> <mailto:alexander.v.stepanov at oracle.com >> <mailto:alexander.v.stepanov at oracle.com>>> wrote: >> >> Hello, >> >> Could you please review the following fix >> http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/ >> <http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/> >> <http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/> >> http://cr.openjdk.java.net/~avstepan/8133651/jaxws.00/index.html >> <http://cr.openjdk.java.net/%7Eavstepan/8133651/jaxws.00/index.html> >> <http://cr.openjdk.java.net/%7Eavstepan/8133651/jaxws.00/index.html >> >> >> for >> https://bugs.openjdk.java.net/browse/JDK-8133651 >> >> Just another portion of deprecated <tt> (and >> <xmp>) tags replaced >> with {@code }. Some misprints were also fixed. >> >> >> I'm biased of course, but I like the approach I >> took with >> blessed-modifier-order: >> - make the change completely automated >> - leave "human editing" for a separate change >> - publish the code used to make the automated >> change (in my case, >> typically a perl one-liner) >> >> >> The following (expected) changes were >> detected by specdiff: >> - removed needless dashes in java.util.Locale, >> - removed needless curly brace in >> xml.bind.annotation.XmlElementRef >> >> >> I would do a separate automated "removed needless >> dashes" changeset. >> >> >> Please let me know if the following changes >> are desirable or not: >> >> http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html >> <http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html> >> < >> http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html >> >> >> >> >> This is an actual change to the behavior of this >> code - the >> maintainers of jconsole need to approve it. It's >> probably correct, >> but I would have left it out of this change. If >> you remove it, then I >> approve this change. >> >> >> >> > 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 Roger.Riggs at Oracle.com Thu Oct 1 13:00:59 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 1 Oct 2015 09:00:59 -0400 Subject: P.S.: RFR [9] 8133651: automated replacing of old-style tags in docs In-Reply-To: <26045557-3AB1-450F-9D7D-571C7B39F2E8@oracle.com> References: <740a3bdd-3a72-44ec-b51f-83c98cac07ca@default> <560A6628.5010807@oracle.com> <CA+kOe0_RoiEvvquZ-5aJ401b1oePuDG+7vd0ufzgctpFhUfaLA@mail.gmail.com> <560C8970.50805@oracle.com> <CA+kOe0-YkE_886K0b_OY4G7kmunx9eTG0rxhaoVt8YKUsixFHA@mail.gmail.com> <560D199B.30708@oracle.com> <26045557-3AB1-450F-9D7D-571C7B39F2E8@oracle.com> Message-ID: <560D2E8B.3000507@Oracle.com> +1 for manageable sized and per repo code-reviews. (unless someone has a tool that checks the patch to confirm that the only difference between the old and the new is the same small number of substitutions; another quick program perhaps...). On 10/1/2015 8:40 AM, Lance Andersen wrote: > Hi Alexander, > > Personally, I would find it easier to review if the changes were sent out by category/module vs one large patch as it is easier to miss things. > > Also for technologies such as jaxws, these will need to go to the external workspace at the same time for the technology so these should definitely be kept separate. > > Best > Lance > On Oct 1, 2015, at 7:31 AM, Alexander Stepanov <alexander.v.stepanov at oracle.com> wrote: > >> >> So if you don't have objections, I'll delay for a several days and then publish a final RFR (probably containing changes in some other repos like jaxws, corba or jaxp) which would be more formal (containing bug # and the final specdiff report). >> >> Thanks again, >> Alexander >> >> >> On 10/1/2015 9:54 AM, Martin Buchholz wrote: >>> Hi s'marks, >>> You probably don't need to absolutify paths. >>> And you can easily handle multiple args. >>> >>> (just for fun!) >>> Checks for javadoc comment; handles popular html entities; handles multiple lines; handles both tt and code: >>> >>> #!/bin/bash >>> find "$@" -name '*.java' | \ >>> xargs -r perl -p0777i -e \ >>> 'do {} while s~^ *\*.*\K<(tt|code)>((?:[^<>{}\&\@]|&(?:lt|gt|amp);)*)</\1>~$_=$2; s/&lt;/</g; s/&gt;/>/g; s/&amp;/&/g; "{\@code $_}"~mgie' >>> >>> >>> On Wed, Sep 30, 2015 at 6:16 PM, Stuart Marks <stuart.marks at oracle.com <mailto:stuart.marks at oracle.com>> wrote: >>> >>> Hi Alexander, Martin, >>> >>> The challenge of Perl file slurping and Emacs one-liners was too >>> much to bear. >>> >>> This is Java, so one-liners are hardly possible. Still, there are >>> a bunch of improvements that can be made to the Java version. (OK, >>> and I'm showing off a bit.) >>> >>> Take a look at this: >>> >>> http://cr.openjdk.java.net/~smarks/misc/SimpleTagEditorSmarks1.java <http://cr.openjdk.java.net/%7Esmarks/misc/SimpleTagEditorSmarks1.java> >>> >>> I haven't studied the output exhaustively, but it seems to do a >>> reasonably good job for the common cases. I ran it over java.lang >>> and I noticed a few cases where there is markup embedded within >>> <code></code> text, which should be looked at more closely. >>> >>> I don't particularly care if you use my version, but there are >>> some techniques that I'd strongly recommend that you consider >>> using in any such tool. In particular: >>> >>> - Pattern.DOTALL to do multi-line matches >>> - Pattern.CASE_INSENSITIVE >>> - try-with-resources to ensure that files are closed properly >>> - NIO instead of old java.io <http://java.io> APIs, particularly >>> Files.walk() and streams >>> - use Scanner to deal with input file buffering >>> - Scanner's stream support (I recently added this to JDK 9) >>> >>> Enjoy, >>> >>> s'marks >>> >>> >>> >>> On 9/29/15 2:23 PM, Martin Buchholz wrote: >>> >>> Hi Alexander, >>> >>> your change looks good. It's OK to have manual corrections >>> for automated >>> mega-changes like this, as long as they all revert changes. >>> >>> Random comments: >>> >>> Should you publish your specdiff? I guess not - it would be >>> empty! >>> >>> while((s = br.readLine()) != null) { >>> >>> by matching only one line at a time, you lose the ability to make >>> replacements that span lines. Perlers like to "slurp" in the >>> entire file >>> as a single string. >>> >>> s = s.replace( "<CODE>", tag1); >>> s = s.replace( "<Code>", tag1); >>> s = s.replace("</CODE>", tag2); >>> s = s.replace("</Code>", tag2); >>> >>> Why not use case-insensitive regex? >>> >>> Here's an emacs-lisp one-liner I've been known to use: >>> >>> (defun tt-code () >>> (interactive) >>> (query-replace-regexp >>> "<\\(tt\\|code\\)>\\([^&<>\\\\]+\\)</\\1>" "{@code >>> \\2}")) >>> >>> With more work, one can automate transformation of embedded >>> things like &lt; >>> >>> But of course, it's not even possible to transform ALL uses of >>> <code> to >>> {@code, if there was imaginative use of nested html tags. >>> >>> >>> On Tue, Sep 29, 2015 at 3:21 AM, Alexander Stepanov < >>> alexander.v.stepanov at oracle.com >>> <mailto:alexander.v.stepanov at oracle.com>> wrote: >>> >>> Updated: a few manual corrections were made (as @linkplain >>> tags displays >>> nested {@code } literally): >>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/jdk.patch> >>> -checked with specdiff (which of course does not cover >>> documentation for >>> internal packages), no unexpected diffs detected. >>> >>> Regards, >>> Alexander >>> >>> >>> On 9/27/2015 4:52 PM, Alexander Stepanov wrote: >>> >>> Hello Martin, >>> >>> Here is some simple app. to replace <code></code> tags >>> with a new-style >>> {@code } one (which is definitely not so elegant as >>> the Perl one-liners): >>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/SimpleTagEditor.java >>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/SimpleTagEditor.java> >>> >>> Corresponding patch for jdk and replacement log (~62k >>> of the tag changes): >>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch >>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/jdk.patch> >>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/replace.log >>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/replace.log> >>> (sorry, I have to check the correctness of the patch >>> with specdiff yet, >>> so this is rather demo at the moment). >>> >>> Don't know if these changes (cosmetic by nature) are >>> desired for now or >>> not. Moreover, probably some part of them should go to >>> another repos (e.g., >>> awt, swing -> "client" instead of "dev"). >>> >>> Regards, >>> Alexander >>> >>> >>> >>> ----- ???????? ????????? ----- >>> ??: alexander.v.stepanov at oracle.com >>> <mailto:alexander.v.stepanov at oracle.com> >>> ????: martinrb at google.com <mailto:martinrb at google.com> >>> ?????: core-libs-dev at openjdk.java.net >>> <mailto:core-libs-dev at openjdk.java.net> >>> ????????????: ???????, 24 ???????? 2015 ? 16:06:56 GMT >>> +03:00 ??????, >>> ?????-?????????, ????????? >>> ????: Re: RFR [9] 8133651: replace some <tt> tags >>> (obsolete in html5) in >>> core-libs docs >>> >>> Hello Martin, >>> >>> Thank you for review and for the notes! >>> >>> > I'm biased of course, but I like the approach I >>> took with >>> blessed-modifier-order: >>> > - make the change completely automated >>> > - leave "human editing" for a separate change >>> > - publish the code used to make the automated >>> change (in my case, >>> typically a perl one-liner) >>> >>> Automated replacement has an obvious advantage: it is >>> fast and massive. >>> But there are some disadvantages at the same time >>> (just IMHO). >>> >>> Using script it is quite easy to miss some not very >>> trivial cases, e.g.: >>> - remove unnecessary linebreaks, like >>> * <tt>someCode >>> * </tt> >>> (which would be better to replace with single-line >>> {@code someCode}; >>> - joining of successive terms, like "<tt>ONE</tt>, >>> <tt>TWO</tt>, >>> <tt>THREE</tt>" -> "{@code ONE, TWO, THREE}"; >>> - errors like extra or missing "&lt;" or "&gt;": * >>> <tt>Collection >>> &lt;T></tt>", - there were a lot of them; >>> - some cases when <tt></tt> should be replaced with >>> <code></code>, not >>> {@code } (e.g. because of unicode characters inside of >>> code etc.); >>> - extra tags inside of <tt> or <code> which should be >>> moved outside of >>> {@code }, like <tt><i>someCode</i></tt> or >>> <tt><b>someCode</b></tt>; >>> - simple removing of needless tags, like "<tt>{@link >>> ...}</tt>" -> >>> "{@link ...}"; >>> - replace HTML codes with symbols ('<', '>', '@', ...) >>> - etc. >>> - plus some other formatting changes and fixes for >>> misprints which would >>> be omitted during the automated replacement (and >>> wouldn't be done in >>> future manually because there is no motivation for >>> repeated processing). >>> >>> So sometimes it may be difficult to say where is the >>> border between >>> "trivial" and "human-editing" cases (and the portion >>> of "non-trivial >>> cases" is definitely not minor); moreover, even the >>> automated >>> replacement requires the subsequent careful review >>> before publishing of >>> webrev (as well as by reviewers who probably wouldn't >>> be happy to review >>> hundreds of files at the same time) and iterative >>> checks/corrections. >>> specdiff is very useful for this task but also cannot >>> fully cover the >>> diffs (as some changes are situated in the internal >>> com/... sun/... >>> packages). >>> >>> Moreover, I'm sure that some reviewers would be >>> annoyed with the fact >>> that some (quite simple) changes were postponed >>> because they are "not >>> too trivial to be fixed just now" (because they will >>> suspect they would >>> be postponed forever). So the patch creator would >>> (probably) receive >>> some advices during the review like "please fix also >>> fix this and that" >>> (which is normal, of course). >>> >>> So my preference was to make the changes package by >>> package (in some >>> reasonable amount of files) not postponing part of the >>> changes for the >>> future (sorry for these boring repeating review >>> requests). Please note >>> that all the above mentioned is *rather explanation of >>> my motivation >>> than objection* :) (and of course I used some text >>> editor replace >>> automation which is surely not so advanced as Perl). >>> >>> > It's probably correct, but I would have left it >>> out of this change >>> Yes, I see. Reverted (please update the web page): >>> http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/index.html >>> <http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/index.html> >>> >>> Thanks, >>> Alexander >>> >>> P.S. The <tt> replacement job is mostly (I guess, >>> ~80%) complete. But >>> probably this approach should be used if some similar >>> replacement task >>> for, e.g., <code></code> tags would be planned in >>> future (there are >>> thousands of them). >>> >>> >>> On 9/24/2015 6:10 AM, Martin Buchholz wrote: >>> >>> >>> On Sat, Sep 19, 2015 at 6:58 AM, Alexander Stepanov >>> <alexander.v.stepanov at oracle.com >>> <mailto:alexander.v.stepanov at oracle.com> >>> <mailto:alexander.v.stepanov at oracle.com >>> <mailto:alexander.v.stepanov at oracle.com>>> wrote: >>> >>> Hello, >>> >>> Could you please review the following fix >>> http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/ >>> <http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/> >>> <http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/> >>> http://cr.openjdk.java.net/~avstepan/8133651/jaxws.00/index.html >>> <http://cr.openjdk.java.net/%7Eavstepan/8133651/jaxws.00/index.html> >>> <http://cr.openjdk.java.net/%7Eavstepan/8133651/jaxws.00/index.html >>> >>> >>> for >>> https://bugs.openjdk.java.net/browse/JDK-8133651 >>> >>> Just another portion of deprecated <tt> (and >>> <xmp>) tags replaced >>> with {@code }. Some misprints were also fixed. >>> >>> >>> I'm biased of course, but I like the approach I >>> took with >>> blessed-modifier-order: >>> - make the change completely automated >>> - leave "human editing" for a separate change >>> - publish the code used to make the automated >>> change (in my case, >>> typically a perl one-liner) >>> >>> >>> The following (expected) changes were >>> detected by specdiff: >>> - removed needless dashes in java.util.Locale, >>> - removed needless curly brace in >>> xml.bind.annotation.XmlElementRef >>> >>> >>> I would do a separate automated "removed needless >>> dashes" changeset. >>> >>> >>> Please let me know if the following changes >>> are desirable or not: >>> >>> http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html >>> <http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html> >>> < >>> http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html >>> >>> >>> >>> >>> This is an actual change to the behavior of this >>> code - the >>> maintainers of jconsole need to approve it. It's >>> probably correct, >>> but I would have left it out of this change. If >>> you remove it, then I >>> approve this change. >>> >>> >>> >>> > > > 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 alexander.v.stepanov at oracle.com Thu Oct 1 13:34:27 2015 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Thu, 1 Oct 2015 16:34:27 +0300 Subject: P.S.: RFR [9] 8133651: automated replacing of old-style tags in docs In-Reply-To: <26045557-3AB1-450F-9D7D-571C7B39F2E8@oracle.com> References: <740a3bdd-3a72-44ec-b51f-83c98cac07ca@default> <560A6628.5010807@oracle.com> <CA+kOe0_RoiEvvquZ-5aJ401b1oePuDG+7vd0ufzgctpFhUfaLA@mail.gmail.com> <560C8970.50805@oracle.com> <CA+kOe0-YkE_886K0b_OY4G7kmunx9eTG0rxhaoVt8YKUsixFHA@mail.gmail.com> <560D199B.30708@oracle.com> <26045557-3AB1-450F-9D7D-571C7B39F2E8@oracle.com> Message-ID: <560D3663.70601@oracle.com> Hello Lance, Yes, to be honest, I also fear to push at once a single changeset for jdk touching thousands of files. Moreover, I'm pretty sure that e.g. java.desktop part should go to a client repository instead of dev, changes for client and security libs should be approved by corresponding dev teams etc. Also, probably some of these cosmetic changes should be postponed for now to avoid potential merging issues for people who really do something valuable. So I'll try to split the initial overall fix for jdk part into some reasonable amount of sub-tasks and send RFRs one by one, as earlier. Thanks, Alexander On 10/1/2015 3:40 PM, Lance Andersen wrote: > Hi Alexander, > > Personally, I would find it easier to review if the changes were sent > out by category/module vs one large patch as it is easier to miss things. > > Also for technologies such as jaxws, these will need to go to the > external workspace at the same time for the technology so these should > definitely be kept separate. > > Best > Lance > On Oct 1, 2015, at 7:31 AM, Alexander Stepanov > <alexander.v.stepanov at oracle.com > <mailto:alexander.v.stepanov at oracle.com>> wrote: > >> >> >> So if you don't have objections, I'll delay for a several days and >> then publish a final RFR (probably containing changes in some other >> repos like jaxws, corba or jaxp) which would be more formal >> (containing bug # and the final specdiff report). >> >> Thanks again, >> Alexander >> >> >> On 10/1/2015 9:54 AM, Martin Buchholz wrote: >>> Hi s'marks, >>> You probably don't need to absolutify paths. >>> And you can easily handle multiple args. >>> >>> (just for fun!) >>> Checks for javadoc comment; handles popular html entities; handles >>> multiple lines; handles both tt and code: >>> >>> #!/bin/bash >>> find "$@" -name '*.java' | \ >>> xargs -r perl -p0777i -e \ >>> 'do {} while s~^ >>> *\*.*\K<(tt|code)>((?:[^<>{}\&\@]|&(?:lt|gt|amp);)*)</\1>~$_=$2; >>> s/&lt;/</g; s/&gt;/>/g; s/&amp;/&/g; "{\@code $_}"~mgie' >>> >>> >>> On Wed, Sep 30, 2015 at 6:16 PM, Stuart Marks >>> <stuart.marks at oracle.com <mailto:stuart.marks at oracle.com> >>> <mailto:stuart.marks at oracle.com>> wrote: >>> >>> Hi Alexander, Martin, >>> >>> The challenge of Perl file slurping and Emacs one-liners was too >>> much to bear. >>> >>> This is Java, so one-liners are hardly possible. Still, there are >>> a bunch of improvements that can be made to the Java version. (OK, >>> and I'm showing off a bit.) >>> >>> Take a look at this: >>> >>> http://cr.openjdk.java.net/~smarks/misc/SimpleTagEditorSmarks1.java >>> <http://cr.openjdk.java.net/%7Esmarks/misc/SimpleTagEditorSmarks1.java> >>> <http://cr.openjdk.java.net/%7Esmarks/misc/SimpleTagEditorSmarks1.java> >>> >>> I haven't studied the output exhaustively, but it seems to do a >>> reasonably good job for the common cases. I ran it over java.lang >>> and I noticed a few cases where there is markup embedded within >>> <code></code> text, which should be looked at more closely. >>> >>> I don't particularly care if you use my version, but there are >>> some techniques that I'd strongly recommend that you consider >>> using in any such tool. In particular: >>> >>> - Pattern.DOTALL to do multi-line matches >>> - Pattern.CASE_INSENSITIVE >>> - try-with-resources to ensure that files are closed properly >>> - NIO instead of old java.io <http://java.io> APIs, particularly >>> Files.walk() and streams >>> - use Scanner to deal with input file buffering >>> - Scanner's stream support (I recently added this to JDK 9) >>> >>> Enjoy, >>> >>> s'marks >>> >>> >>> >>> On 9/29/15 2:23 PM, Martin Buchholz wrote: >>> >>> Hi Alexander, >>> >>> your change looks good. It's OK to have manual corrections >>> for automated >>> mega-changes like this, as long as they all revert changes. >>> >>> Random comments: >>> >>> Should you publish your specdiff? I guess not - it would be >>> empty! >>> >>> while((s = br.readLine()) != null) { >>> >>> by matching only one line at a time, you lose the ability to make >>> replacements that span lines. Perlers like to "slurp" in the >>> entire file >>> as a single string. >>> >>> s = s.replace( "<CODE>", tag1); >>> s = s.replace( "<Code>", tag1); >>> s = s.replace("</CODE>", tag2); >>> s = s.replace("</Code>", tag2); >>> >>> Why not use case-insensitive regex? >>> >>> Here's an emacs-lisp one-liner I've been known to use: >>> >>> (defun tt-code () >>> (interactive) >>> (query-replace-regexp >>> "<\\(tt\\|code\\)>\\([^&<>\\\\]+\\)</\\1>" "{@code >>> \\2}")) >>> >>> With more work, one can automate transformation of embedded >>> things like &lt; >>> >>> But of course, it's not even possible to transform ALL uses of >>> <code> to >>> {@code, if there was imaginative use of nested html tags. >>> >>> >>> On Tue, Sep 29, 2015 at 3:21 AM, Alexander Stepanov < >>> alexander.v.stepanov at oracle.com <mailto:alexander.v.stepanov at oracle.com> >>> <mailto:alexander.v.stepanov at oracle.com>> wrote: >>> >>> Updated: a few manual corrections were made (as @linkplain >>> tags displays >>> nested {@code } literally): >>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch >>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/jdk.patch> >>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/jdk.patch> >>> -checked with specdiff (which of course does not cover >>> documentation for >>> internal packages), no unexpected diffs detected. >>> >>> Regards, >>> Alexander >>> >>> >>> On 9/27/2015 4:52 PM, Alexander Stepanov wrote: >>> >>> Hello Martin, >>> >>> Here is some simple app. to replace <code></code> tags >>> with a new-style >>> {@code } one (which is definitely not so elegant as >>> the Perl one-liners): >>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/SimpleTagEditor.java >>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/SimpleTagEditor.java> >>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/SimpleTagEditor.java> >>> >>> Corresponding patch for jdk and replacement log (~62k >>> of the tag changes): >>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch >>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/jdk.patch> >>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/jdk.patch> >>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/replace.log >>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/replace.log> >>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/replace.log> >>> (sorry, I have to check the correctness of the patch >>> with specdiff yet, >>> so this is rather demo at the moment). >>> >>> Don't know if these changes (cosmetic by nature) are >>> desired for now or >>> not. Moreover, probably some part of them should go to >>> another repos (e.g., >>> awt, swing -> "client" instead of "dev"). >>> >>> Regards, >>> Alexander >>> >>> >>> >>> ----- ???????? ????????? ----- >>> ??: alexander.v.stepanov at oracle.com >>> <mailto:alexander.v.stepanov at oracle.com> >>> <mailto:alexander.v.stepanov at oracle.com> >>> ????: martinrb at google.com >>> <mailto:martinrb at google.com> <mailto:martinrb at google.com> >>> ?????: core-libs-dev at openjdk.java.net >>> <mailto:core-libs-dev at openjdk.java.net> >>> <mailto:core-libs-dev at openjdk.java.net> >>> ????????????: ???????, 24 ???????? 2015 ? 16:06:56 GMT >>> +03:00 ??????, >>> ?????-?????????, ????????? >>> ????: Re: RFR [9] 8133651: replace some <tt> tags >>> (obsolete in html5) in >>> core-libs docs >>> >>> Hello Martin, >>> >>> Thank you for review and for the notes! >>> >>> > I'm biased of course, but I like the approach I >>> took with >>> blessed-modifier-order: >>> > - make the change completely automated >>> > - leave "human editing" for a separate change >>> > - publish the code used to make the automated >>> change (in my case, >>> typically a perl one-liner) >>> >>> Automated replacement has an obvious advantage: it is >>> fast and massive. >>> But there are some disadvantages at the same time >>> (just IMHO). >>> >>> Using script it is quite easy to miss some not very >>> trivial cases, e.g.: >>> - remove unnecessary linebreaks, like >>> * <tt>someCode >>> * </tt> >>> (which would be better to replace with single-line >>> {@code someCode}; >>> - joining of successive terms, like "<tt>ONE</tt>, >>> <tt>TWO</tt>, >>> <tt>THREE</tt>" -> "{@code ONE, TWO, THREE}"; >>> - errors like extra or missing "&lt;" or "&gt;": * >>> <tt>Collection >>> &lt;T></tt>", - there were a lot of them; >>> - some cases when <tt></tt> should be replaced with >>> <code></code>, not >>> {@code } (e.g. because of unicode characters inside of >>> code etc.); >>> - extra tags inside of <tt> or <code> which should be >>> moved outside of >>> {@code }, like <tt><i>someCode</i></tt> or >>> <tt><b>someCode</b></tt>; >>> - simple removing of needless tags, like "<tt>{@link >>> ...}</tt>" -> >>> "{@link ...}"; >>> - replace HTML codes with symbols ('<', '>', '@', ...) >>> - etc. >>> - plus some other formatting changes and fixes for >>> misprints which would >>> be omitted during the automated replacement (and >>> wouldn't be done in >>> future manually because there is no motivation for >>> repeated processing). >>> >>> So sometimes it may be difficult to say where is the >>> border between >>> "trivial" and "human-editing" cases (and the portion >>> of "non-trivial >>> cases" is definitely not minor); moreover, even the >>> automated >>> replacement requires the subsequent careful review >>> before publishing of >>> webrev (as well as by reviewers who probably wouldn't >>> be happy to review >>> hundreds of files at the same time) and iterative >>> checks/corrections. >>> specdiff is very useful for this task but also cannot >>> fully cover the >>> diffs (as some changes are situated in the internal >>> com/... sun/... >>> packages). >>> >>> Moreover, I'm sure that some reviewers would be >>> annoyed with the fact >>> that some (quite simple) changes were postponed >>> because they are "not >>> too trivial to be fixed just now" (because they will >>> suspect they would >>> be postponed forever). So the patch creator would >>> (probably) receive >>> some advices during the review like "please fix also >>> fix this and that" >>> (which is normal, of course). >>> >>> So my preference was to make the changes package by >>> package (in some >>> reasonable amount of files) not postponing part of the >>> changes for the >>> future (sorry for these boring repeating review >>> requests). Please note >>> that all the above mentioned is *rather explanation of >>> my motivation >>> than objection* :) (and of course I used some text >>> editor replace >>> automation which is surely not so advanced as Perl). >>> >>> > It's probably correct, but I would have left it >>> out of this change >>> Yes, I see. Reverted (please update the web page): >>> http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/index.html >>> <http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/index.html> >>> <http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/index.html> >>> >>> Thanks, >>> Alexander >>> >>> P.S. The <tt> replacement job is mostly (I guess, >>> ~80%) complete. But >>> probably this approach should be used if some similar >>> replacement task >>> for, e.g., <code></code> tags would be planned in >>> future (there are >>> thousands of them). >>> >>> >>> On 9/24/2015 6:10 AM, Martin Buchholz wrote: >>> >>> >>> On Sat, Sep 19, 2015 at 6:58 AM, Alexander Stepanov >>> <alexander.v.stepanov at oracle.com >>> <mailto:alexander.v.stepanov at oracle.com> >>> <mailto:alexander.v.stepanov at oracle.com> >>> <mailto:alexander.v.stepanov at oracle.com >>> <mailto:alexander.v.stepanov at oracle.com>>> wrote: >>> >>> Hello, >>> >>> Could you please review the following fix >>> http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/ >>> <http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/> >>> <http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/> >>> <http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/> >>> http://cr.openjdk.java.net/~avstepan/8133651/jaxws.00/index.html >>> <http://cr.openjdk.java.net/%7Eavstepan/8133651/jaxws.00/index.html> >>> <http://cr.openjdk.java.net/%7Eavstepan/8133651/jaxws.00/index.html> >>> <http://cr.openjdk.java.net/%7Eavstepan/8133651/jaxws.00/index.html >>> >>> >>> for >>> https://bugs.openjdk.java.net/browse/JDK-8133651 >>> >>> Just another portion of deprecated <tt> (and >>> <xmp>) tags replaced >>> with {@code }. Some misprints were also fixed. >>> >>> >>> I'm biased of course, but I like the approach I >>> took with >>> blessed-modifier-order: >>> - make the change completely automated >>> - leave "human editing" for a separate change >>> - publish the code used to make the automated >>> change (in my case, >>> typically a perl one-liner) >>> >>> >>> The following (expected) changes were >>> detected by specdiff: >>> - removed needless dashes in java.util.Locale, >>> - removed needless curly brace in >>> xml.bind.annotation.XmlElementRef >>> >>> >>> I would do a separate automated "removed needless >>> dashes" changeset. >>> >>> >>> Please let me know if the following changes >>> are desirable or not: >>> >>> http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html >>> <http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html> >>> <http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html> >>> < >>> http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html >>> >>> >>> >>> >>> This is an actual change to the behavior of this >>> code - the >>> maintainers of jconsole need to approve it. It's >>> probably correct, >>> but I would have left it out of this change. If >>> you remove it, then I >>> approve this change. >>> >>> >>> >>> >> > > <http://oracle.com/us/design/oracle-email-sig-198324.gif> > <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif> > <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com> > > > From Roger.Riggs at Oracle.com Thu Oct 1 14:12:49 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 1 Oct 2015 10:12:49 -0400 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization Message-ID: <560D3F61.6040607@Oracle.com> Please review a proposal for public Cleaner API: A Cleaner is proposed to provide an easy to use alternative to finalization. The service would provide easy registration and cancellation of cleanup functions for objects. Applications create a cleanup service for their own use and the service terminates when it is no longer in use. Finalization has a long history of issues both in usage and performance. PhantomReferences have been proposed as the alternative GC based mechanism for cleaning functions but it has been left as an exercise to the developer to construct the necessary mechanisms to handle ReferenceQueues, handle threading issues and robust termination. The Cleaner performs cleaning functions when objects are unreachable as found by garbage collection using the existing mechanisms of PhantomReference, WeakReference, SoftReferences, and ReferenceQueues. It manages a thread that dequeues references to unreachable objects and invokes the corresponding cleaning function. Registered cleaning functions can be cleared if no longer needed, can be invoked explicitly to perform the cleanup immediately, or be invoked when the object is not reachable (as detected by garbage collection) and handled by a cleanup thread. The java.lang.ref package is proposed for the Cleaner because it is complementary to the reference classes and reference queues and to make it easy to find. It is not a goal to replace all uses of finalization or sun.misc.Cleaner in the JDK. Investigation will evaluate if and in what cases the Cleaner can replace finalization. A subsequent task will examine uses of finalization and propose specific changes on a case by base basis. Please review and comment: Javadoc: http://cr.openjdk.java.net/~rriggs/cleaner-doc/ Webrev: http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ Issue: https://bugs.openjdk.java.net/browse/JDK-8138696 Thanks, Roger From Mohammad.Rezaei at gs.com Thu Oct 1 14:28:56 2015 From: Mohammad.Rezaei at gs.com (Rezaei, Mohammad A.) Date: Thu, 1 Oct 2015 10:28:56 -0400 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <560D3F61.6040607@Oracle.com> References: <560D3F61.6040607@Oracle.com> Message-ID: <6882C9A35DFB9B4FA2779F7BF5B9757D2083639BE3@GSCMAMP06EX.firmwide.corp.gs.com> The proposed API makes good sense for what I would consider coarse grained cleanup. There is another significant use case for Weak/Soft references that is not covered here: weak/soft references used in cache like data structures, e.g. WeakHashMap. Wouldn't there be significant code reuse if I could register a ReferenceQueue and get callbacks when appropriate? (Just like other uses of this cleaner, any user of this api has to pay attention to concurrency, so WeakHashMap, as is, is not a great candidate for this). Thanks Moh >-----Original Message----- >From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf >Of Roger Riggs >Sent: Thursday, October 01, 2015 10:13 AM >To: Core-Libs-Dev >Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative >to finalization > >Please review a proposal for public Cleaner API: > >A Cleaner is proposed to provide an easy to use alternative to >finalization. The service would provide easy registration and >cancellation of cleanup functions for objects. Applications create a >cleanup service for their own use and the service terminates when it is >no longer in use. > >Finalization has a long history of issues both in usage and performance. >PhantomReferences have been proposed as the alternative GC based >mechanism for cleaning functions but it has been left as an exercise to >the developer to construct the necessary mechanisms to handle >ReferenceQueues, handle threading issues and robust termination. > >The Cleaner performs cleaning functions when objects are unreachable as >found by garbage collection using the existing mechanisms of >PhantomReference, WeakReference, SoftReferences, and ReferenceQueues. It >manages a thread that dequeues references to unreachable objects and >invokes the corresponding cleaning function. Registered cleaning >functions can be cleared if no longer needed, can be invoked explicitly >to perform the cleanup immediately, or be invoked when the object is not >reachable (as detected by garbage collection) and handled by a cleanup >thread. > >The java.lang.ref package is proposed for the Cleaner because it is >complementary to the reference classes and reference queues and to make >it easy to find. > >It is not a goal to replace all uses of finalization or sun.misc.Cleaner >in the JDK. >Investigation will evaluate if and in what cases the Cleaner can replace >finalization. >A subsequent task will examine uses of finalization and propose specific >changes >on a case by base basis. > >Please review and comment: > >Javadoc: > http://cr.openjdk.java.net/~rriggs/cleaner-doc/ > >Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > >Issue: > https://bugs.openjdk.java.net/browse/JDK-8138696 > >Thanks, Roger From deva.sagar at oracle.com Thu Oct 1 14:53:48 2015 From: deva.sagar at oracle.com (Deva Sagar) Date: Thu, 1 Oct 2015 10:53:48 -0400 Subject: [9] Review request JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader In-Reply-To: <560CEE1B.5090304@oracle.com> References: <55D5E163.6090905@oracle.com> <55F2F9F4.5090309@oracle.com> <56054D74.3070903@oracle.com> <560BF6AD.60204@oracle.com> <560C003F.8070801@oracle.com> <560CEE1B.5090304@oracle.com> Message-ID: <5280BAEF-4A0E-4215-88CC-F2BD51BF0977@oracle.com> Hi Miran, My personal opinion is to prefer the more defensive approach instead of introducing a new abstract method, even though it would be more consistent with other factories to add the new abstract method. The spec doesn?t require _all_ factories to delegate to SAAJMetaFactory as I understand. Also the current API docs on SAAJMetaFactory explicitly refer only to the 2 factories mentioned. Thanks, Deva > On Oct 1, 2015, at 4:26 AM, Miroslav Kos <miroslav.kos at oracle.com> wrote: > > > > On 30/09/15 17:31, Miroslav Kos wrote: >> On 30/09/15 16:50, Georgiy Rakov wrote: >>> 2. This is not related to ServiceLoader feature, but anyway - SAAJMetaFactory.java: >>> 30 * SAAJ API. All of the {@code newInstance} methods defined on factories in >>> 31 * SAAJ 1.3 defer to instances of this class to do the actual object creation. >>> Namely it says that all the newInstance methods defined on factories delegate factory creation to SAAJMetaFactory instances, but this seems to be not exactly true because SOAPConnectionFactory is not created by SAAJMetaFactory instance. >> Yes, good catch. To fix it, it would be good to add a new abstract method >> public abstract SOAPConnectionFactory newSOAPConnectionFactory() >> throws SOAPException, UnsupportedOperationException >> >> Would you agree, Deva, Chen? There is a problem with backwards compatibility here ... More defensive would be to name the two factories instead of saying "all"? > Any opinion on this, anybody? > > Thanks > Miran > > >> >> Thanks >> Miran >> >> Btw. I sent this RFR initially to wrong mailing lists, would you check when answering that it's to Core-Libs-Dev <mailto:core-libs-dev at openjdk.java.net><core-libs-dev at openjdk.java.net> <mailto:core-libs-dev at openjdk.java.net> ? >> >>> >>> Thank you, >>> Georgiy. >>> >> > From Roger.Riggs at Oracle.com Thu Oct 1 14:59:04 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 1 Oct 2015 10:59:04 -0400 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <6882C9A35DFB9B4FA2779F7BF5B9757D2083639BE3@GSCMAMP06EX.firmwide.corp.gs.com> References: <560D3F61.6040607@Oracle.com> <6882C9A35DFB9B4FA2779F7BF5B9757D2083639BE3@GSCMAMP06EX.firmwide.corp.gs.com> Message-ID: <560D4A38.3060406@Oracle.com> Hi Moh, On 10/1/2015 10:28 AM, Rezaei, Mohammad A. wrote: > The proposed API makes good sense for what I would consider coarse grained cleanup. > > There is another significant use case for Weak/Soft references that is not covered here: weak/soft references used in cache like data structures, e.g. WeakHashMap. Correct, the existing implementation handles its WeakReferences without the need for a second thread to be involved and avoids any resulting concurrency issues. There is no need to reimplement classes that already handle weak and soft references, most have already been tuned for optimal behavior and performance. > > Wouldn't there be significant code reuse if I could register a ReferenceQueue and get callbacks when appropriate? > > (Just like other uses of this cleaner, any user of this api has to pay attention to concurrency, so WeakHashMap, as is, is not a great candidate for this). Right, any registration type of mechanism would need to be concerned with concurrency and with the robustness of the thread being shared to do the callbacks. Some thread would need to wait on multiple ReferenceQueues which would require a low level wait for multiple locks. Roger > > Thanks > Moh > >> - From miroslav.kos at oracle.com Thu Oct 1 15:10:34 2015 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Thu, 1 Oct 2015 17:10:34 +0200 Subject: [9] Review request JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader In-Reply-To: <560D165F.4030808@oracle.com> References: <55D5E163.6090905@oracle.com> <55F2F9F4.5090309@oracle.com> <56054D74.3070903@oracle.com> <56059161.2010808@oracle.com> <560A95E8.30907@oracle.com> <47E51B07-4FA1-4C13-9F8C-450B44C8FE20@oracle.com> <560BE098.7090809@oracle.com> <1ACCA360-ED4B-4A06-B0AD-52F14E604FCD@oracle.com> <560BFAED.4070802@oracle.com> <560D165F.4030808@oracle.com> Message-ID: <560D4CEA.4000808@oracle.com> Hi, there is a new version of specdiff: http://cr.openjdk.java.net/~mkos/8131334/specdiff.06/index.html To remind, there were two problems to be addressed, both related to SAAJMetaFactory: http://cr.openjdk.java.net/~mkos/8131334/specdiff.06/javax/xml/soap/SAAJMetaFactory.html 1) hidden feature of lookup mechanism for SAAJMetaFactory: I added two new paragraphs into javadoc - one references the service loader facility - the second one mentions additional steps and references the algorithm in javax.xml.soap package desc 2) SAAJMetaFactory supports only 2 of 3 SAAJ Factories - this is current state, we are not changing that - I am afraid adding a new abstract method into existing Factory class is too incompatible change for MR - just changed javadoc: AlloftheThe|newInstance|methods defined on factories|SOAPFactory| <http://cr.openjdk.java.net/%7Emkos/8131334/specdiff.06/javax/xml/soap/SOAPFactory.html>and|MessageFactory| <http://cr.openjdk.java.net/%7Emkos/8131334/specdiff.06/javax/xml/soap/MessageFactory.html> ... Thanks Miran From eamonn at mcmanus.net Thu Oct 1 15:11:39 2015 From: eamonn at mcmanus.net (Eamonn McManus) Date: Thu, 1 Oct 2015 08:11:39 -0700 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <560D3F61.6040607@Oracle.com> References: <560D3F61.6040607@Oracle.com> Message-ID: <CACBEn45fub01My4L_EhmicVe7YTTAO69RgPrx6c==RODkT6quw@mail.gmail.com> I think this is a great idea. In addition to the NetBeans precedent cited in the Issue, I'll note that Guava has FinalizableReferenceQueue. Like the NetBeans solution, that has proved tricky to make collectable in a context where its ClassLoader might become otherwise unreferenced. Having the facility in the JRE obviates that problem. As a minor note, the javadoc says "phantomCleanup registers the Runnable to be run when object is not phantom reachable", which I don't think is technically accurate. The java.lang.ref definition of reachability is that an object becomes (for example) phantom reachable when it is referenced by a phantom reference but no longer has any stronger level of reachability. So the text here should say "when the object becomes phantom reachable". Likewise the per-method text "when the object is unreachable by a PhantomReference" should say "becomes phantom reachable". And of course the same, mutatis mutandis, for the soft and weak equivalents. ?amonn 2015-10-01 7:12 GMT-07:00 Roger Riggs <Roger.Riggs at oracle.com>: > Please review a proposal for public Cleaner API: > > A Cleaner is proposed to provide an easy to use alternative to finalization. > The service would provide easy registration and cancellation of cleanup > functions for objects. Applications create a cleanup service for their own > use and the service terminates when it is no longer in use. > > Finalization has a long history of issues both in usage and performance. > PhantomReferences have been proposed as the alternative GC based mechanism > for cleaning functions but it has been left as an exercise to the developer > to construct the necessary mechanisms to handle ReferenceQueues, handle > threading issues and robust termination. > > The Cleaner performs cleaning functions when objects are unreachable as > found by garbage collection using the existing mechanisms of > PhantomReference, WeakReference, SoftReferences, and ReferenceQueues. It > manages a thread that dequeues references to unreachable objects and invokes > the corresponding cleaning function. Registered cleaning functions can be > cleared if no longer needed, can be invoked explicitly to perform the > cleanup immediately, or be invoked when the object is not reachable (as > detected by garbage collection) and handled by a cleanup thread. > > The java.lang.ref package is proposed for the Cleaner because it is > complementary to the reference classes and reference queues and to make it > easy to find. > > It is not a goal to replace all uses of finalization or sun.misc.Cleaner in > the JDK. > Investigation will evaluate if and in what cases the Cleaner can replace > finalization. > A subsequent task will examine uses of finalization and propose specific > changes > on a case by base basis. > > Please review and comment: > > Javadoc: > http://cr.openjdk.java.net/~rriggs/cleaner-doc/ > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8138696 > > Thanks, Roger > From zoltan.majo at oracle.com Thu Oct 1 15:31:09 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 1 Oct 2015 17:31:09 +0200 Subject: [9] RFR(XS): 8137173: @HotSpotIntrinsicCandidate is not Oracle-specific Message-ID: <560D51BD.6030108@oracle.com> Hi, please review the patch for JDK-8137173. https://bugs.openjdk.java.net/browse/JDK-8137173 Problem: Mark Rheinhold filed this bug and suggested the following: "The doc comment for the @jdk.internal.HotSpotIntrinsicCandidate annotation says that it is "specific to the Oracle Java HotSpot Virtual Machine implementation". That's not true. The annotation is defined in the open-source HotSpot repository, so it is in fact available in all implementations derived from that code, whether from Oracle or from other vendors." Solution: I adopted the solution proposed by Mark. Webrev: http://cr.openjdk.java.net/~zmajo/8137173/webrev.00/ Testing: JPRT run (build + tests). I intend to push this into jdk9/hs-comp/jdk, from there it will eventually propagate to all repositories. Thank you and best regards, Zoltan From zoltan.majo at oracle.com Thu Oct 1 15:34:57 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 1 Oct 2015 17:34:57 +0200 Subject: [9] RFR(XS): 8137173: @HotSpotIntrinsicCandidate is not Oracle-specific In-Reply-To: <560D51BD.6030108@oracle.com> References: <560D51BD.6030108@oracle.com> Message-ID: <560D52A1.80406@oracle.com> P.S.: On 10/01/2015 05:31 PM, Zolt?n Maj? wrote: > Problem: Mark Rheinhold filed this bug and suggested the following: I ment Mark Reinhold (w/o the 'h'). Sorry for the mistake. Best regards, Zoltan > > "The doc comment for the @jdk.internal.HotSpotIntrinsicCandidate > annotation says that it is "specific to the Oracle Java HotSpot Virtual > Machine implementation". That's not true. The annotation is defined > in the open-source HotSpot repository, so it is in fact available in all > implementations derived from that code, whether from Oracle or from other > vendors." > > Solution: I adopted the solution proposed by Mark. > > Webrev: http://cr.openjdk.java.net/~zmajo/8137173/webrev.00/ > > Testing: JPRT run (build + tests). > > I intend to push this into jdk9/hs-comp/jdk, from there it will > eventually propagate to all repositories. > > Thank you and best regards, > > > Zoltan > From Roger.Riggs at Oracle.com Thu Oct 1 15:40:26 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 1 Oct 2015 11:40:26 -0400 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <CACBEn45fub01My4L_EhmicVe7YTTAO69RgPrx6c==RODkT6quw@mail.gmail.com> References: <560D3F61.6040607@Oracle.com> <CACBEn45fub01My4L_EhmicVe7YTTAO69RgPrx6c==RODkT6quw@mail.gmail.com> Message-ID: <560D53EA.5060706@Oracle.com> Hi Eamonn, Thanks for the comments and correction, the intention was to describe the behavior consistently. (I updated the webrev in place with the editorial changes). Thanks, Roger On 10/1/2015 11:11 AM, Eamonn McManus wrote: > I think this is a great idea. In addition to the NetBeans precedent > cited in the Issue, I'll note that Guava has > FinalizableReferenceQueue. Like the NetBeans solution, that has proved > tricky to make collectable in a context where its ClassLoader might > become otherwise unreferenced. Having the facility in the JRE obviates > that problem. > > As a minor note, the javadoc says "phantomCleanup registers the > Runnable to be run when object is not phantom reachable", which I > don't think is technically accurate. The java.lang.ref definition of > reachability is that an object becomes (for example) phantom reachable > when it is referenced by a phantom reference but no longer has any > stronger level of reachability. So the text here should say "when the > object becomes phantom reachable". Likewise the per-method text "when > the object is unreachable by a PhantomReference" should say "becomes > phantom reachable". And of course the same, mutatis mutandis, for the > soft and weak equivalents. > ?amonn > > > 2015-10-01 7:12 GMT-07:00 Roger Riggs <Roger.Riggs at oracle.com>: >> Please review a proposal for public Cleaner API: >> >> A Cleaner is proposed to provide an easy to use alternative to finalization. >> The service would provide easy registration and cancellation of cleanup >> functions for objects. Applications create a cleanup service for their own >> use and the service terminates when it is no longer in use. >> >> Finalization has a long history of issues both in usage and performance. >> PhantomReferences have been proposed as the alternative GC based mechanism >> for cleaning functions but it has been left as an exercise to the developer >> to construct the necessary mechanisms to handle ReferenceQueues, handle >> threading issues and robust termination. >> >> The Cleaner performs cleaning functions when objects are unreachable as >> found by garbage collection using the existing mechanisms of >> PhantomReference, WeakReference, SoftReferences, and ReferenceQueues. It >> manages a thread that dequeues references to unreachable objects and invokes >> the corresponding cleaning function. Registered cleaning functions can be >> cleared if no longer needed, can be invoked explicitly to perform the >> cleanup immediately, or be invoked when the object is not reachable (as >> detected by garbage collection) and handled by a cleanup thread. >> >> The java.lang.ref package is proposed for the Cleaner because it is >> complementary to the reference classes and reference queues and to make it >> easy to find. >> >> It is not a goal to replace all uses of finalization or sun.misc.Cleaner in >> the JDK. >> Investigation will evaluate if and in what cases the Cleaner can replace >> finalization. >> A subsequent task will examine uses of finalization and propose specific >> changes >> on a case by base basis. >> >> Please review and comment: >> >> Javadoc: >> http://cr.openjdk.java.net/~rriggs/cleaner-doc/ >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8138696 >> >> Thanks, Roger >> From Alan.Bateman at oracle.com Thu Oct 1 15:41:02 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 01 Oct 2015 16:41:02 +0100 Subject: [9] RFR(XS): 8137173: @HotSpotIntrinsicCandidate is not Oracle-specific In-Reply-To: <560D51BD.6030108@oracle.com> References: <560D51BD.6030108@oracle.com> Message-ID: <560D540E.4090609@oracle.com> On 01/10/2015 16:31, Zolt?n Maj? wrote: > Hi, > > > please review the patch for JDK-8137173. > > https://bugs.openjdk.java.net/browse/JDK-8137173 > > Problem: Mark Rheinhold filed this bug and suggested the following: > > "The doc comment for the @jdk.internal.HotSpotIntrinsicCandidate > annotation says that it is "specific to the Oracle Java HotSpot Virtual > Machine implementation". That's not true. The annotation is defined > in the open-source HotSpot repository, so it is in fact available in all > implementations derived from that code, whether from Oracle or from other > vendors." > > Solution: I adopted the solution proposed by Mark. > > Webrev: http://cr.openjdk.java.net/~zmajo/8137173/webrev.00/ > This looks okay. Is it time to discuss moving the annotation to another package too? -Alan. From mark.reinhold at oracle.com Thu Oct 1 15:54:41 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 01 Oct 2015 08:54:41 -0700 Subject: [9] RFR(XS): 8137173: @HotSpotIntrinsicCandidate is not Oracle-specific In-Reply-To: <560D540E.4090609@oracle.com> References: <560D51BD.6030108@oracle.com>,<560D540E.4090609@oracle.com> Message-ID: <20151001085441.434440@eggemoggin.niobe.net> 2015/10/1 8:41 -0700, alan.bateman at oracle.com: > On 01/10/2015 16:31, Zolt?n Maj? wrote: >> please review the patch for JDK-8137173. >> >> https://bugs.openjdk.java.net/browse/JDK-8137173 >> >> ... >> >> Webrev: http://cr.openjdk.java.net/~zmajo/8137173/webrev.00/ >> > This looks okay. Is it time to discuss moving the annotation to > another package too? Yes. We don't want to create another sun.misc-like dumping ground with jdk.internal. We should prefer small, descriptive subpackages for things like this so that, when they are (inevitably) exposed via -XaddExports, their exposure can be limited. I suggest putting this into jdk.internal.vm.annotation, which is also a good place for the ReservedStackAccess annotation envisioned in JEP 270 (http://openjdk.java.net/jeps/270). - Mark From steve.drach at oracle.com Thu Oct 1 16:15:57 2015 From: steve.drach at oracle.com (Steve Drach) Date: Thu, 1 Oct 2015 09:15:57 -0700 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <560D1AA6.5010807@oracle.com> References: <A12C71A8-59AB-4271-873F-4F3435EB2493@oracle.com> <7659C060-0EBC-4FC2-B20E-9CCB3B93A2C5@oracle.com> <BE0A18A1-CA02-472C-9C61-31982CE4AC0D@oracle.com> <B4B78415-1428-45CE-9E06-7D16F3969806@oracle.com> <560D1AA6.5010807@oracle.com> Message-ID: <89ABA5EB-B69A-4BC4-BE3E-89333863466D@oracle.com> >>> - JDK 8 jar signer does not work with a JDK 9 created keystore >>> - JDK 8 signed jar with JDK 8 created keystore is not the same size as JDK 9 signed jar with JDK 9 keystore >>> - JDK 8 signed jar with JDK 8 created keystore is not the same size as JDK 9 signed jar with the same JDK 8 keystore >> >> The default keystore type in jdk9 is pkcs12. I guess this is why jarsigner in jdk8 does not recognize it. > > It should work if you are using 8u60. What JDK 8 version are you using? I upgraded to 8u60, now JDK 8 jar signer works with a JDK 9 created keystore. I also created a keystore with keytool -genkeypair -keyalg RSA -sigalg SHA1withRSA ... and signed with both JDK8 and JDK9 jarsigner -sigalg SHA1withRSA ? The jar file sizes are still different. The embedded .SF and .RSA entries are different sizes. I can see that the headers in the .SF files are different, accounting for some of the difference. I think I?m getting distracted here, not focusing on getting tests created. Is it okay to move on? From Alan.Bateman at oracle.com Thu Oct 1 16:46:57 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 01 Oct 2015 17:46:57 +0100 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <991FA3D3-851A-4912-8C71-80FD13C74496@oracle.com> References: <A12C71A8-59AB-4271-873F-4F3435EB2493@oracle.com> <560AD899.2020903@oracle.com> <991FA3D3-851A-4912-8C71-80FD13C74496@oracle.com> Message-ID: <560D6381.8070907@oracle.com> On 29/09/2015 21:46, Steve Drach wrote: >>> Please review the following webrev that adds support for >>> multi-release jars as specified in JEP-238. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 >>> <https://bugs.openjdk.java.net/browse/JDK-8132734> >>> JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305 >>> <https://bugs.openjdk.java.net/browse/JDK-8047305> >>> Webrev: >>> http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ >>> <http://cr.openjdk.java.net/%7Epsandoz/multiversion-jar/jar-webrev/> >>> <http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ >>> <http://cr.openjdk.java.net/%7Epsandoz/multiversion-jar/jar-webrev/>> >>> ? > >> Steve - is the webrev complete, just wondering as I don't see any tests. > > Yes it is complete. Oracle SQE has done the tests, and have tested > the changes. They will integrate the tests after this webrev is > integrated. I?ve been told that this is the way it?s done for new > features. No so so hopefully the tests will appear soon so that they can be pushed at the same time. One other question about this webrev. It doesn't include any changes to the tools. I guess I assumed there would be updates to jar and javac, maybe jdeps. The JEP did mention this but perhaps this work has been split out? -Alan From steve.drach at oracle.com Thu Oct 1 17:07:06 2015 From: steve.drach at oracle.com (Steve Drach) Date: Thu, 1 Oct 2015 10:07:06 -0700 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <560D6381.8070907@oracle.com> References: <A12C71A8-59AB-4271-873F-4F3435EB2493@oracle.com> <560AD899.2020903@oracle.com> <991FA3D3-851A-4912-8C71-80FD13C74496@oracle.com> <560D6381.8070907@oracle.com> Message-ID: <346ED951-5BD4-4F55-9C1E-2DB17353C83E@oracle.com> >>>> Please review the following webrev that adds support for multi-release jars as specified in JEP-238. >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 <https://bugs.openjdk.java.net/browse/JDK-8132734> <https://bugs.openjdk.java.net/browse/JDK-8132734 <https://bugs.openjdk.java.net/browse/JDK-8132734>> >>>> JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305 <https://bugs.openjdk.java.net/browse/JDK-8047305><https://bugs.openjdk.java.net/browse/JDK-8047305 <https://bugs.openjdk.java.net/browse/JDK-8047305>> >>>> Webrev: http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ <http://cr.openjdk.java.net/%7Epsandoz/multiversion-jar/jar-webrev/><http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ <http://cr.openjdk.java.net/%7Epsandoz/multiversion-jar/jar-webrev/>> >>>> ? >> >>> Steve - is the webrev complete, just wondering as I don't see any tests. >> >> Yes it is complete. Oracle SQE has done the tests, and have tested the changes. They will integrate the tests after this webrev is integrated. I?ve been told that this is the way it?s done for new features. > No so so hopefully the tests will appear soon so that they can be pushed at the same time. Yes. I?ve decided not to depend on SQE, but to do it the right way. > > One other question about this webrev. It doesn't include any changes to the tools. I guess I assumed there would be updates to jar and javac, maybe jdeps. The JEP did mention this but perhaps this work has been split out? Yes, the JEP issue has several subtasks. This one, 8132734, is just for java.util.jar.JarFile. There will be a separate webrev for jar tool and another one for enhancements to ZipFileSystem. And then there are several more pieces to the puzzle such as javac, etc. From Alan.Bateman at oracle.com Thu Oct 1 19:25:41 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 01 Oct 2015 20:25:41 +0100 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <346ED951-5BD4-4F55-9C1E-2DB17353C83E@oracle.com> References: <A12C71A8-59AB-4271-873F-4F3435EB2493@oracle.com> <560AD899.2020903@oracle.com> <991FA3D3-851A-4912-8C71-80FD13C74496@oracle.com> <560D6381.8070907@oracle.com> <346ED951-5BD4-4F55-9C1E-2DB17353C83E@oracle.com> Message-ID: <560D88B5.2000701@oracle.com> On 01/10/2015 18:07, Steve Drach wrote: > > Yes, the JEP issue has several subtasks. This one, 8132734, is just > for java.util.jar.JarFile. There will be a separate webrev for jar > tool and another one for enhancements to ZipFileSystem. And then > there are several more pieces to the puzzle such as javac, etc. > Okay. On the the ZipFileSystem then it would be good to get a summary on what you are proposing. I don't recall seeing that in the JEP and arguably it shouldn't need any changes as META-INF/versions is just a directory in the file system for anyone using the file system API. In any case, I looked through the current webrev and it looks mostly okay. One thing that wasn't very clear is whether JarEntry needs to override other methods so that they can be forwarded to the versioned entry. It would be good to add @since to Attributes#MULTI_RELEASE before this goes in. -Alan. From stuart.marks at oracle.com Thu Oct 1 19:34:37 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 1 Oct 2015 12:34:37 -0700 Subject: JEP 269: Convenience Factory Methods for Collections In-Reply-To: <CACzrW9BeVsgk7Oj6hW_oma3y6DFF+VvaTyRucPGraV=SSALHCg@mail.gmail.com> References: <20150924000217.D476B7A327@eggemoggin.niobe.net> <CAGKkBks7CKsJngvagV15C47E6zncdS-ag2m2OOKGoTtm-+YFFw@mail.gmail.com> <560B4A82.50506@oracle.com> <CACzrW9BeVsgk7Oj6hW_oma3y6DFF+VvaTyRucPGraV=SSALHCg@mail.gmail.com> Message-ID: <560D8ACD.1080609@oracle.com> On 9/29/15 11:32 PM, Stephen Colebourne wrote: > In my view, the proposal is pretty good. I too use Guava's immutable > classes as types, because of the extra value obtained. But that does > not mean these methods should not be in the JDK. (Not every project > uses Guava). Hi Stephen, Thanks for looking at the proposal. I'm glad you like it. > I'd argue for two changes to the JEP. > > Map.fromEntries() -> Map.ofEntries() > In JSR-310, we reserve "from" for factories with a high chance of > failure due to performing some kind of conversion, and use "of" for > factories that only fail if doing something stupid. It also means that > IDE users will easily see both choices when auto-completing, thus > easily learn how to go beyond the hard coded 6 entry factory. Ah, this is quite helpful. I was mostly focusing on the "shape" of the many-entries Map factory (varargs, builder, etc.) that I didn't think too much about the name. I'll adopt your suggest of ofEntries(). > Map.Entry.entry() -> Map.entry() > This would allow static imports to be focussed just on Map, and not > needing Map.Entry as well (helpful in Eclipse at least). If the method > were on Map.Entry, I'd expect it to be of(), whereas on Map itself, > entry() is a good name. There might be a case for having both > Map.entry() and Map.Entry.of(). Good. My current prototype already has the entry() convenience method on Map, not Map.Entry. (I'm not sure, but earlier prototypes might have had it on Map.Entry.) My rationale for having the entry() method on Map is that it actually returns an instance of Map.KeyValueHolder, a concrete implementation Map.Entry that's intended to become a value class. The other obvious candidate implementation to return is AbstractMap.SimpleImmutableEntry, which is problematic to turn into a value class, as it's subclassable, has public constructors, and is serializable. Soon, I'll post a webrev/specdiff/javadoc of the prototype so we can discuss things more concretely. s'marks > Stephen > > > > On 30 September 2015 at 03:35, Stuart Marks <stuart.marks at oracle.com> wrote: >> Hi all, I've been on vacation for a few days. Did anything happen while I >> was away? :-) >> >> I see this JEP was posted as a Candidate, and Kevin and Remi had some >> comments. I'll reply to Kevin's comments here and to Remi's separately. >> >> Kevin, >> >> I'm glad you don't think the proposal is bad. :-) >> >> I definitely see the value in having immutability in the type system. If >> your application is using Guava's immutable types, then it would certainly >> be a step backwards to stop using them in favor of the factories proposed >> here. >> >> However, I don't see this JEP as being in opposition to immutable collection >> types. This JEP isn't specifically about immutable collections; it's about >> convenience APIs (some of which create collection instances that happen to >> be immutable). Immutable collection types could be added later without too >> much difficulty. I'd be interested in seeing and even possibly working on >> such a proposal in the future. >> >>> Note that without permitting nulls, Map.of(key, Optional.of(value)) will >>> become >>> reasonably common, and that fact you can't serialize that will become even >>> more >>> strange than it already is. >> >> >> Interesting. Given that Guava's Maps disallow null values, do you see a lot >> of use of Optional for Map values in Guava? For the JDK, do you think it >> would be preferable to allow null values in Maps, or to make Optional >> serializable? (Note to readers: Guava's Optional is serializable but the >> JDK's is not.) Or is this one of those problems where all the solutions >> suck? >> >>> I think the example of "double-brace initialization" should be even more >>> clearly >>> labeled as pure evil. :-) You could also mention all the horrible >>> consequences >>> if anyone ever serializes such a collection. >> >> >> I'm not sure if one is allowed to say "evil" in a JEP, but I agree that the >> "double brace" "idiom" is definitely evil! I did mention the potential for >> memory leaks in the JEP, but you have a good point about serialization, not >> only of the enclosing instance, but also of all captured references. >> >> s'marks >> From stuart.marks at oracle.com Thu Oct 1 19:40:56 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 1 Oct 2015 12:40:56 -0700 Subject: P.S.: RFR [9] 8133651: automated replacing of old-style tags in docs In-Reply-To: <CA+kOe0-YkE_886K0b_OY4G7kmunx9eTG0rxhaoVt8YKUsixFHA@mail.gmail.com> References: <740a3bdd-3a72-44ec-b51f-83c98cac07ca@default> <560A6628.5010807@oracle.com> <CA+kOe0_RoiEvvquZ-5aJ401b1oePuDG+7vd0ufzgctpFhUfaLA@mail.gmail.com> <560C8970.50805@oracle.com> <CA+kOe0-YkE_886K0b_OY4G7kmunx9eTG0rxhaoVt8YKUsixFHA@mail.gmail.com> Message-ID: <560D8C48.3060108@oracle.com> Nice try Martin, but I'm not going to get sucked into a round of perl code golf with you. :-) I wasn't sure why the absolute path stuff was in there; I just carried it over from Alexander's code. I'll let Alexander fix this along with your point about handling multiple files, if he wants to. s'marks P.S. Note that in the mail log, http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035538.html the HTML entities in the s/a/b/g; expressions were evaluated, making the resulting script incorrect. Sigh. On 9/30/15 11:54 PM, Martin Buchholz wrote: > Hi s'marks, > You probably don't need to absolutify paths. > And you can easily handle multiple args. > > (just for fun!) > Checks for javadoc comment; handles popular html entities; handles multiple > lines; handles both tt and code: > > #!/bin/bash > find "$@" -name '*.java' | \ > xargs -r perl -p0777i -e \ > 'do {} while s~^ > *\*.*\K<(tt|code)>((?:[^<>{}\&\@]|&(?:lt|gt|amp);)*)</\1>~$_=$2; s/&lt;/</g; > s/&gt;/>/g; s/&amp;/&/g; "{\@code $_}"~mgie' > > > On Wed, Sep 30, 2015 at 6:16 PM, Stuart Marks <stuart.marks at oracle.com > <mailto:stuart.marks at oracle.com>> wrote: > > Hi Alexander, Martin, > > The challenge of Perl file slurping and Emacs one-liners was too much to bear. > > This is Java, so one-liners are hardly possible. Still, there are a bunch > of improvements that can be made to the Java version. (OK, and I'm showing > off a bit.) > > Take a look at this: > > http://cr.openjdk.java.net/~smarks/misc/SimpleTagEditorSmarks1.java > <http://cr.openjdk.java.net/%7Esmarks/misc/SimpleTagEditorSmarks1.java> > > I haven't studied the output exhaustively, but it seems to do a reasonably > good job for the common cases. I ran it over java.lang and I noticed a few > cases where there is markup embedded within <code></code> text, which > should be looked at more closely. > > I don't particularly care if you use my version, but there are some > techniques that I'd strongly recommend that you consider using in any such > tool. In particular: > > - Pattern.DOTALL to do multi-line matches > - Pattern.CASE_INSENSITIVE > - try-with-resources to ensure that files are closed properly > - NIO instead of old java.io <http://java.io> APIs, particularly > Files.walk() and streams > - use Scanner to deal with input file buffering > - Scanner's stream support (I recently added this to JDK 9) > > Enjoy, > > s'marks > > > > On 9/29/15 2:23 PM, Martin Buchholz wrote: > > Hi Alexander, > > your change looks good. It's OK to have manual corrections for automated > mega-changes like this, as long as they all revert changes. > > Random comments: > > Should you publish your specdiff? I guess not - it would be empty! > > while((s = br.readLine()) != null) { > > by matching only one line at a time, you lose the ability to make > replacements that span lines. Perlers like to "slurp" in the entire file > as a single string. > > s = s.replace( "<CODE>", tag1); > s = s.replace( "<Code>", tag1); > s = s.replace("</CODE>", tag2); > s = s.replace("</Code>", tag2); > > Why not use case-insensitive regex? > > Here's an emacs-lisp one-liner I've been known to use: > > (defun tt-code () > (interactive) > (query-replace-regexp "<\\(tt\\|code\\)>\\([^&<>\\\\]+\\)</\\1>" > "{@code > \\2}")) > > With more work, one can automate transformation of embedded things > like &lt; > > But of course, it's not even possible to transform ALL uses of <code> to > {@code, if there was imaginative use of nested html tags. > > > On Tue, Sep 29, 2015 at 3:21 AM, Alexander Stepanov < > alexander.v.stepanov at oracle.com > <mailto:alexander.v.stepanov at oracle.com>> wrote: > > Updated: a few manual corrections were made (as @linkplain tags > displays > nested {@code } literally): > http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch > <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/jdk.patch> > -checked with specdiff (which of course does not cover > documentation for > internal packages), no unexpected diffs detected. > > Regards, > Alexander > > > On 9/27/2015 4:52 PM, Alexander Stepanov wrote: > > Hello Martin, > > Here is some simple app. to replace <code></code> tags with a > new-style > {@code } one (which is definitely not so elegant as the Perl > one-liners): > http://cr.openjdk.java.net/~avstepan/tmp/codeTags/SimpleTagEditor.java > <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/SimpleTagEditor.java> > > Corresponding patch for jdk and replacement log (~62k of the > tag changes): > http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch > <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/jdk.patch> > http://cr.openjdk.java.net/~avstepan/tmp/codeTags/replace.log > <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/replace.log> > (sorry, I have to check the correctness of the patch with > specdiff yet, > so this is rather demo at the moment). > > Don't know if these changes (cosmetic by nature) are desired > for now or > not. Moreover, probably some part of them should go to another > repos (e.g., > awt, swing -> "client" instead of "dev"). > > Regards, > Alexander > > > > ----- ???????? ????????? ----- > ??: alexander.v.stepanov at oracle.com > <mailto:alexander.v.stepanov at oracle.com> > ????: martinrb at google.com <mailto:martinrb at google.com> > ?????: core-libs-dev at openjdk.java.net > <mailto:core-libs-dev at openjdk.java.net> > ????????????: ???????, 24 ???????? 2015 ? 16:06:56 GMT +03:00 > ??????, > ?????-?????????, ????????? > ????: Re: RFR [9] 8133651: replace some <tt> tags (obsolete in > html5) in > core-libs docs > > Hello Martin, > > Thank you for review and for the notes! > > > I'm biased of course, but I like the approach I took with > blessed-modifier-order: > > - make the change completely automated > > - leave "human editing" for a separate change > > - publish the code used to make the automated change (in > my case, > typically a perl one-liner) > > Automated replacement has an obvious advantage: it is fast and > massive. > But there are some disadvantages at the same time (just IMHO). > > Using script it is quite easy to miss some not very trivial > cases, e.g.: > - remove unnecessary linebreaks, like > * <tt>someCode > * </tt> > (which would be better to replace with single-line {@code > someCode}; > - joining of successive terms, like "<tt>ONE</tt>, <tt>TWO</tt>, > <tt>THREE</tt>" -> "{@code ONE, TWO, THREE}"; > - errors like extra or missing "&lt;" or "&gt;": * <tt>Collection > &lt;T></tt>", - there were a lot of them; > - some cases when <tt></tt> should be replaced with > <code></code>, not > {@code } (e.g. because of unicode characters inside of code etc.); > - extra tags inside of <tt> or <code> which should be moved > outside of > {@code }, like <tt><i>someCode</i></tt> or > <tt><b>someCode</b></tt>; > - simple removing of needless tags, like "<tt>{@link ...}</tt>" -> > "{@link ...}"; > - replace HTML codes with symbols ('<', '>', '@', ...) > - etc. > - plus some other formatting changes and fixes for misprints > which would > be omitted during the automated replacement (and wouldn't be > done in > future manually because there is no motivation for repeated > processing). > > So sometimes it may be difficult to say where is the border > between > "trivial" and "human-editing" cases (and the portion of > "non-trivial > cases" is definitely not minor); moreover, even the automated > replacement requires the subsequent careful review before > publishing of > webrev (as well as by reviewers who probably wouldn't be happy > to review > hundreds of files at the same time) and iterative > checks/corrections. > specdiff is very useful for this task but also cannot fully > cover the > diffs (as some changes are situated in the internal com/... > sun/... > packages). > > Moreover, I'm sure that some reviewers would be annoyed with > the fact > that some (quite simple) changes were postponed because they > are "not > too trivial to be fixed just now" (because they will suspect > they would > be postponed forever). So the patch creator would (probably) > receive > some advices during the review like "please fix also fix this > and that" > (which is normal, of course). > > So my preference was to make the changes package by package > (in some > reasonable amount of files) not postponing part of the changes > for the > future (sorry for these boring repeating review requests). > Please note > that all the above mentioned is *rather explanation of my > motivation > than objection* :) (and of course I used some text editor replace > automation which is surely not so advanced as Perl). > > > It's probably correct, but I would have left it out of > this change > Yes, I see. Reverted (please update the web page): > http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/index.html > <http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/index.html> > > Thanks, > Alexander > > P.S. The <tt> replacement job is mostly (I guess, ~80%) > complete. But > probably this approach should be used if some similar > replacement task > for, e.g., <code></code> tags would be planned in future > (there are > thousands of them). > > > On 9/24/2015 6:10 AM, Martin Buchholz wrote: > > > On Sat, Sep 19, 2015 at 6:58 AM, Alexander Stepanov > <alexander.v.stepanov at oracle.com > <mailto:alexander.v.stepanov at oracle.com> > <mailto:alexander.v.stepanov at oracle.com > <mailto:alexander.v.stepanov at oracle.com>>> wrote: > > Hello, > > Could you please review the following fix > http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/ > <http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/> > <http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/> > http://cr.openjdk.java.net/~avstepan/8133651/jaxws.00/index.html > <http://cr.openjdk.java.net/%7Eavstepan/8133651/jaxws.00/index.html> > > <http://cr.openjdk.java.net/%7Eavstepan/8133651/jaxws.00/index.html > > > for > https://bugs.openjdk.java.net/browse/JDK-8133651 > > Just another portion of deprecated <tt> (and <xmp>) > tags replaced > with {@code }. Some misprints were also fixed. > > > I'm biased of course, but I like the approach I took with > blessed-modifier-order: > - make the change completely automated > - leave "human editing" for a separate change > - publish the code used to make the automated change (in > my case, > typically a perl one-liner) > > > The following (expected) changes were detected by > specdiff: > - removed needless dashes in java.util.Locale, > - removed needless curly brace in > xml.bind.annotation.XmlElementRef > > > I would do a separate automated "removed needless dashes" > changeset. > > > Please let me know if the following changes are > desirable or not: > > http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html > <http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html> > < > http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html > > > > > This is an actual change to the behavior of this code - the > maintainers of jconsole need to approve it. It's probably > correct, > but I would have left it out of this change. If you remove > it, then I > approve this change. > > > > From weijun.wang at oracle.com Fri Oct 2 00:00:20 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 2 Oct 2015 08:00:20 +0800 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <89ABA5EB-B69A-4BC4-BE3E-89333863466D@oracle.com> References: <A12C71A8-59AB-4271-873F-4F3435EB2493@oracle.com> <7659C060-0EBC-4FC2-B20E-9CCB3B93A2C5@oracle.com> <BE0A18A1-CA02-472C-9C61-31982CE4AC0D@oracle.com> <B4B78415-1428-45CE-9E06-7D16F3969806@oracle.com> <560D1AA6.5010807@oracle.com> <89ABA5EB-B69A-4BC4-BE3E-89333863466D@oracle.com> Message-ID: <4342221B-838D-4EF1-953B-81B2608CA405@oracle.com> > ? 2015?10?2????12:15?Steve Drach <steve.drach at oracle.com> ??? > > I think I?m getting distracted here, not focusing on getting tests created. Is it okay to move on? Please move on. If you think anything is strange, just send me all related files. One last request about the SSLException, can you still generate the full debug output for jar signing with an empty cacerts? I think just adding a -debug option will print out a full stack trace showing where the exception is thrown. Thanks Max From steve.drach at oracle.com Fri Oct 2 00:14:38 2015 From: steve.drach at oracle.com (Steve Drach) Date: Thu, 1 Oct 2015 17:14:38 -0700 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <4342221B-838D-4EF1-953B-81B2608CA405@oracle.com> References: <A12C71A8-59AB-4271-873F-4F3435EB2493@oracle.com> <7659C060-0EBC-4FC2-B20E-9CCB3B93A2C5@oracle.com> <BE0A18A1-CA02-472C-9C61-31982CE4AC0D@oracle.com> <B4B78415-1428-45CE-9E06-7D16F3969806@oracle.com> <560D1AA6.5010807@oracle.com> <89ABA5EB-B69A-4BC4-BE3E-89333863466D@oracle.com> <4342221B-838D-4EF1-953B-81B2608CA405@oracle.com> Message-ID: <5E62B83C-5434-4B1F-9345-96A8E035532B@oracle.com> >> I think I?m getting distracted here, not focusing on getting tests created. Is it okay to move on? > > Please move on. If you think anything is strange, just send me all related files. > > One last request about the SSLException, can you still generate the full debug output for jar signing with an empty cacerts? I think just adding a -debug option will print out a full stack trace showing where the exception is thrown. Sent separately to avoid excessive noise on the mailing list From huizhe.wang at oracle.com Fri Oct 2 00:16:41 2015 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 01 Oct 2015 17:16:41 -0700 Subject: RFR (JAXP) 8138721 : ElementTraversal: javadoc warning; also, hasFeature shall return true Message-ID: <560DCCE9.2010301@oracle.com> Hi, Thanks Lance and Daniel for pointing out the javadoc warning! Here's the fix. Also, added ElementTraversal to the DOMImplementation supported feature list. JBS: https://bugs.openjdk.java.net/browse/JDK-8138721 http://cr.openjdk.java.net/~joehw/jdk9/8138721/webrev/ Thanks, Joe From weijun.wang at oracle.com Fri Oct 2 01:25:43 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 2 Oct 2015 09:25:43 +0800 Subject: Optional used as method argument? Message-ID: <57B3E0BE-64EC-44BC-9069-5558BEFA2EE0@oracle.com> I hear people saying Optional is usually used as return values. Can I use it as an argument, like this? void consume(Optional<String> value) This way, I don't need to add spec like "@param value can be null if there is no such value". Thanks Max From zoltan.majo at oracle.com Fri Oct 2 05:57:51 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 2 Oct 2015 07:57:51 +0200 Subject: [9] RFR(XS): 8137173: @HotSpotIntrinsicCandidate is not Oracle-specific In-Reply-To: <20151001085441.434440@eggemoggin.niobe.net> References: <560D51BD.6030108@oracle.com> <560D540E.4090609@oracle.com> <20151001085441.434440@eggemoggin.niobe.net> Message-ID: <560E1CDF.7070307@oracle.com> Hi Alan, Hi Mark, On 10/01/2015 05:54 PM, mark.reinhold at oracle.com wrote: > 2015/10/1 8:41 -0700, alan.bateman at oracle.com: >> On 01/10/2015 16:31, Zolt?n Maj? wrote: >>> please review the patch for JDK-8137173. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8137173 >>> >>> ... >>> >>> Webrev: http://cr.openjdk.java.net/~zmajo/8137173/webrev.00/ >>> >> This looks okay. Is it time to discuss moving the annotation to >> another package too? thank you for the review! > Yes. We don't want to create another sun.misc-like dumping ground > with jdk.internal. We should prefer small, descriptive subpackages > for things like this so that, when they are (inevitably) exposed via > -XaddExports, their exposure can be limited. > > I suggest putting this into jdk.internal.vm.annotation, which is > also a good place for the ReservedStackAccess annotation envisioned > in JEP 270 (http://openjdk.java.net/jeps/270). I filed an RFE, JDK-8138732: "move @HotSpotIntrinsicCandidate to the jdk.internal.vm.annotation package" [1], to track the issue of moving the annotation to a different package. I hope I can take care of it soon. Thank you and best regards, Zoltan [1] https://bugs.openjdk.java.net/browse/JDK-8138732 > > - Mark From forax at univ-mlv.fr Fri Oct 2 08:10:23 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 2 Oct 2015 10:10:23 +0200 (CEST) Subject: Optional used as method argument? In-Reply-To: <57B3E0BE-64EC-44BC-9069-5558BEFA2EE0@oracle.com> References: <57B3E0BE-64EC-44BC-9069-5558BEFA2EE0@oracle.com> Message-ID: <1265946042.2537314.1443773423877.JavaMail.zimbra@u-pem.fr> Hi Max, yes, It's usually not a good idea, creating an Optional is like a boxing, you create an object (and prey that escape analysis will work), usually null means there is no value so either you have two methods consume, something like consumeAValue(String) and consumeNoValue() or you have one method consumeAValue and you don't call it if there is no value. regards, R?mi ----- Mail original ----- > De: "Wang Weijun" <weijun.wang at oracle.com> > ?: core-libs-dev at openjdk.java.net > Envoy?: Vendredi 2 Octobre 2015 03:25:43 > Objet: Optional used as method argument? > > I hear people saying Optional is usually used as return values. Can I use it > as an argument, like this? > > void consume(Optional<String> value) > > This way, I don't need to add spec like "@param value can be null if there is > no such value". > > Thanks > Max > > From paul.sandoz at oracle.com Fri Oct 2 08:40:46 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 2 Oct 2015 10:40:46 +0200 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <560D88B5.2000701@oracle.com> References: <A12C71A8-59AB-4271-873F-4F3435EB2493@oracle.com> <560AD899.2020903@oracle.com> <991FA3D3-851A-4912-8C71-80FD13C74496@oracle.com> <560D6381.8070907@oracle.com> <346ED951-5BD4-4F55-9C1E-2DB17353C83E@oracle.com> <560D88B5.2000701@oracle.com> Message-ID: <87E13291-6EAF-4CBA-93A4-B9D21C0921E5@oracle.com> > On 1 Oct 2015, at 21:25, Alan Bateman <Alan.Bateman at oracle.com> wrote: > > On 01/10/2015 18:07, Steve Drach wrote: >> >> Yes, the JEP issue has several subtasks. This one, 8132734, is just for java.util.jar.JarFile. There will be a separate webrev for jar tool and another one for enhancements to ZipFileSystem. And then there are several more pieces to the puzzle such as javac, etc. >> > Okay. On the the ZipFileSystem then it would be good to get a summary on what you are proposing. Details of any JavacFileManager/ZipFileSystem support are still being hashed out. They are mentioned in the JEP and we can update once those details are finalized. Paul. > I don't recall seeing that in the JEP and arguably it shouldn't need any changes as META-INF/versions is just a directory in the file system for anyone using the file system API. > > In any case, I looked through the current webrev and it looks mostly okay. One thing that wasn't very clear is whether JarEntry needs to override other methods so that they can be forwarded to the versioned entry. It would be good to add @since to Attributes#MULTI_RELEASE before this goes in. > > -Alan. > From peter.levart at gmail.com Fri Oct 2 11:52:11 2015 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 2 Oct 2015 13:52:11 +0200 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <560D3F61.6040607@Oracle.com> References: <560D3F61.6040607@Oracle.com> Message-ID: <560E6FEB.60607@gmail.com> Hi Roger, This is a nice and clean API. I like the trick with embedding a private CleanerImpl in Cleaner and registering Cleaner itself as a tracked object so that automatic thread termination can be performed in a safe manner. You say the scope of this is not to replace internal usages of sun.misc.Cleaner. But if they ever get replaced, there are two differences between the implementations to note: - sun.misc.Cleaner thunks get executed by a ReferenceHandler thread directly and bypass ReferenceQueue-ing. This might be OK for internal use, but not appropriate for public API. I doubt this sun.misc.Cleaner exception in ReferenceHandler is necessary though. - With sun.misc.Cleaner one has to create a minimum of 2 additional objects per tracked object: the Cleaner object and a Runnable thunk. This API requires creation of 3 objects per tracked object: the Cleanup object, the internal Reference object and a Runnable thunk. Do you think Cleaner will not be used in scenarios where this additional footprint matters? It might be possible to merge the roles of Cleanup and Reference into one object, like this: http://cr.openjdk.java.net/~plevart/jdk9-dev/Cleaner/Cleaner.java Making Cleanup an interface, internal Reference(s) can implement it. One can cast a Cleanup instance to a Reference and invoke it's other methods, but this can be prevented by throwing UnsupportedOperationException from them, so nobody is tempted to employ this implementation detail. There might be utility in exposing Cleanup (or better named Cleanable) References as public abstract classes so that a footprint sensitive application (for example in a data structure with many elements) is possible. By subclassing such an abstract reference and implementing the abstract method, a single object is required per tracked object. Here I derived a proof of concept from your code: http://cr.openjdk.java.net/~plevart/jdk9-dev/Cleaner/webrev.01/ The simple API is unchanged and there is additional low-level API that can be used if footprint matters. What do you think? Regards, Peter On 10/01/2015 04:12 PM, Roger Riggs wrote: > Please review a proposal for public Cleaner API: > > A Cleaner is proposed to provide an easy to use alternative to > finalization. The service would provide easy registration and > cancellation of cleanup functions for objects. Applications create a > cleanup service for their own use and the service terminates when it > is no longer in use. > > Finalization has a long history of issues both in usage and > performance. PhantomReferences have been proposed as the alternative > GC based mechanism for cleaning functions but it has been left as an > exercise to the developer to construct the necessary mechanisms to > handle ReferenceQueues, handle threading issues and robust termination. > > The Cleaner performs cleaning functions when objects are unreachable > as found by garbage collection using the existing mechanisms of > PhantomReference, WeakReference, SoftReferences, and ReferenceQueues. > It manages a thread that dequeues references to unreachable objects > and invokes the corresponding cleaning function. Registered cleaning > functions can be cleared if no longer needed, can be invoked > explicitly to perform the cleanup immediately, or be invoked when the > object is not reachable (as detected by garbage collection) and > handled by a cleanup thread. > > The java.lang.ref package is proposed for the Cleaner because it is > complementary to the reference classes and reference queues and to > make it easy to find. > > It is not a goal to replace all uses of finalization or > sun.misc.Cleaner in the JDK. > Investigation will evaluate if and in what cases the Cleaner can > replace finalization. > A subsequent task will examine uses of finalization and propose > specific changes > on a case by base basis. > > Please review and comment: > > Javadoc: > http://cr.openjdk.java.net/~rriggs/cleaner-doc/ > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8138696 > > Thanks, Roger > From daniel.fuchs at oracle.com Fri Oct 2 12:35:05 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 2 Oct 2015 14:35:05 +0200 Subject: RFR (JAXP) 8138721 : ElementTraversal: javadoc warning; also, hasFeature shall return true In-Reply-To: <560DCCE9.2010301@oracle.com> References: <560DCCE9.2010301@oracle.com> Message-ID: <560E79F9.1070508@oracle.com> Looks fine to me Joe. Strange that a trailing '.' could produce such a warning. I have a question however about: (feature.equalsIgnoreCase("ElementTraversal") 128 && (anyVersion 129 || version.equals("1.0")) Does this means that ElementTraversal is only supported on DOM 1.0 - and not on DOM 2.0 and 3.0? best regards, -- daniel On 02/10/15 02:16, huizhe wang wrote: > Hi, > > Thanks Lance and Daniel for pointing out the javadoc warning! Here's the > fix. Also, added ElementTraversal to the DOMImplementation supported > feature list. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8138721 > http://cr.openjdk.java.net/~joehw/jdk9/8138721/webrev/ > > Thanks, > Joe > From miroslav.kos at oracle.com Fri Oct 2 12:41:17 2015 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Fri, 2 Oct 2015 14:41:17 +0200 Subject: [9] Review request JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader In-Reply-To: <560D4CEA.4000808@oracle.com> References: <55D5E163.6090905@oracle.com> <55F2F9F4.5090309@oracle.com> <56054D74.3070903@oracle.com> <56059161.2010808@oracle.com> <560A95E8.30907@oracle.com> <47E51B07-4FA1-4C13-9F8C-450B44C8FE20@oracle.com> <560BE098.7090809@oracle.com> <1ACCA360-ED4B-4A06-B0AD-52F14E604FCD@oracle.com> <560BFAED.4070802@oracle.com> <560D165F.4030808@oracle.com> <560D4CEA.4000808@oracle.com> Message-ID: <560E7B6D.8020508@oracle.com> Hi Georgiy, would you be ok with this defensive solution? Thanks Miran On 01/10/15 17:10, Miroslav Kos wrote: > Hi, > > there is a new version of specdiff: > http://cr.openjdk.java.net/~mkos/8131334/specdiff.06/index.html > > To remind, there were two problems to be addressed, both related to > SAAJMetaFactory: > http://cr.openjdk.java.net/~mkos/8131334/specdiff.06/javax/xml/soap/SAAJMetaFactory.html > > 1) hidden feature of lookup mechanism for SAAJMetaFactory: > I added two new paragraphs into javadoc > - one references the service loader facility > - the second one mentions additional steps and references the > algorithm in javax.xml.soap package desc > > 2) SAAJMetaFactory supports only 2 of 3 SAAJ Factories > - this is current state, we are not changing that - I am afraid adding > a new abstract method into existing Factory class is too incompatible > change for MR > - just changed javadoc: > AlloftheThe|newInstance|methods defined on factories|SOAPFactory| > <http://cr.openjdk.java.net/%7Emkos/8131334/specdiff.06/javax/xml/soap/SOAPFactory.html>and|MessageFactory| > <http://cr.openjdk.java.net/%7Emkos/8131334/specdiff.06/javax/xml/soap/MessageFactory.html> > ... > > Thanks > Miran > From daniel.fuchs at oracle.com Fri Oct 2 12:44:38 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 2 Oct 2015 14:44:38 +0200 Subject: RFR (jaxp) 8136778: SAXParser: support stopping a parsing process In-Reply-To: <560C584F.6040805@oracle.com> References: <560C584F.6040805@oracle.com> Message-ID: <560E7C36.7070403@oracle.com> Hi Joe, The spec for stop says: 561 * This method can be called anywhere from any event method of a SAX 562 * handler. Once called, it does not terminate the parsing process 563 * immediately. Instead, it will continue finishing and returning the 564 * current event, and marking the state before it stops parsing. The 565 * parsing state is maintained after the process is stopped. I wonder whether the step should be extended with some more testcases, calling stop() from various event methods, and not just endElement() - to validate that stop() resume() will work as expected. Also what will happen if resume() is called before the parser has finished flushing the current event? Will that work? Or should there be some guards against that? best regards, -- daniel On 30/09/15 23:46, huizhe wang wrote: > Hi, > > This is an enhancement to allow a SAX parsing process to be stopped and > resumed. A SAX process scans through an entire document while making > callbacks to its handler when defined events are met. The stop and > resume methods make it easy to stop and subsequently resume the process > as needed. Until now, the parsing process can only be stopped brutally > by throwing an Exception. > > JBS: http://ccc.us.oracle.com/8136778 > Webrev: http://cr.openjdk.java.net/~joehw/jdk9/8136778/webrev/ > > Thanks, > Joe > From Roger.Riggs at Oracle.com Fri Oct 2 12:49:36 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 2 Oct 2015 08:49:36 -0400 Subject: Optional used as method argument? In-Reply-To: <1265946042.2537314.1443773423877.JavaMail.zimbra@u-pem.fr> References: <57B3E0BE-64EC-44BC-9069-5558BEFA2EE0@oracle.com> <1265946042.2537314.1443773423877.JavaMail.zimbra@u-pem.fr> Message-ID: <560E7D60.9080201@Oracle.com> +1 The "no such value" makes me curious about the context. The @param tag really should be saying something about the parameter. The absence of an @throws (or class/package wide spec) documenting the NPE for nulls would indicate that null is allowed. Roger On 10/2/2015 4:10 AM, Remi Forax wrote: > Hi Max, > yes, It's usually not a good idea, > creating an Optional is like a boxing, you create an object (and prey that escape analysis will work), > usually null means there is no value so either you have two methods consume, something like consumeAValue(String) and consumeNoValue() or you have one method consumeAValue and you don't call it if there is no value. > > regards, > R?mi > > ----- Mail original ----- >> De: "Wang Weijun" <weijun.wang at oracle.com> >> ?: core-libs-dev at openjdk.java.net >> Envoy?: Vendredi 2 Octobre 2015 03:25:43 >> Objet: Optional used as method argument? >> >> I hear people saying Optional is usually used as return values. Can I use it >> as an argument, like this? >> >> void consume(Optional<String> value) >> >> This way, I don't need to add spec like "@param value can be null if there is >> no such value". >> >> Thanks >> Max >> >> From vitalyd at gmail.com Fri Oct 2 13:00:03 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 2 Oct 2015 09:00:03 -0400 Subject: Optional used as method argument? In-Reply-To: <560E7D60.9080201@Oracle.com> References: <57B3E0BE-64EC-44BC-9069-5558BEFA2EE0@oracle.com> <1265946042.2537314.1443773423877.JavaMail.zimbra@u-pem.fr> <560E7D60.9080201@Oracle.com> Message-ID: <CAHjP37HqPSNrm5Ci+x5drA4Eq9dcXFST-zvgFBrVsZHzoc4tOw@mail.gmail.com> Optional really needs value types to be used more widely in these contexts. Given a language that doesn't have non-null baked into the type system or language, the next best thing would be a library solution. It's much better to indicate nullability in the parameter type rather than javadoc; the javadoc should still explain what a null value would imply for the method, but it's a poor substitute for encoding that fact. Also, having consumeAValue vs consumeNoValue type of approach doesn't scale all that well with more than a single nullable parameter. Unfortunately, there's no good solution in java at the moment; before someone suggests using annotations, let me say they're helpful, but just a bandaid. On Fri, Oct 2, 2015 at 8:49 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote: > +1 > > The "no such value" makes me curious about the context. > The @param tag really should be saying something about the parameter. > > The absence of an @throws (or class/package wide spec) documenting the NPE > for nulls > would indicate that null is allowed. > > Roger > > > > On 10/2/2015 4:10 AM, Remi Forax wrote: > >> Hi Max, >> yes, It's usually not a good idea, >> creating an Optional is like a boxing, you create an object (and prey >> that escape analysis will work), >> usually null means there is no value so either you have two methods >> consume, something like consumeAValue(String) and consumeNoValue() or you >> have one method consumeAValue and you don't call it if there is no value. >> >> regards, >> R?mi >> >> ----- Mail original ----- >> >>> De: "Wang Weijun" <weijun.wang at oracle.com> >>> ?: core-libs-dev at openjdk.java.net >>> Envoy?: Vendredi 2 Octobre 2015 03:25:43 >>> Objet: Optional used as method argument? >>> >>> I hear people saying Optional is usually used as return values. Can I >>> use it >>> as an argument, like this? >>> >>> void consume(Optional<String> value) >>> >>> This way, I don't need to add spec like "@param value can be null if >>> there is >>> no such value". >>> >>> Thanks >>> Max >>> >>> >>> > From weijun.wang at oracle.com Fri Oct 2 13:27:19 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 2 Oct 2015 21:27:19 +0800 Subject: Optional used as method argument? In-Reply-To: <560E7D60.9080201@Oracle.com> References: <57B3E0BE-64EC-44BC-9069-5558BEFA2EE0@oracle.com> <1265946042.2537314.1443773423877.JavaMail.zimbra@u-pem.fr> <560E7D60.9080201@Oracle.com> Message-ID: <6A46E7CB-5CEF-483F-92ED-0153D639E12D@oracle.com> > ? 2015?10?2????8:49?Roger Riggs <Roger.Riggs at oracle.com> ??? > > +1 > > The "no such value" makes me curious about the context. > The @param tag really should be saying something about the parameter. In fact, I'm working on a method which is similar to /* * Generates some random bytes. * * @param n requested random value in bytes. * @param extraEntropy optional entropy caller can provide, null if none. */ byte[] getRandom(int n, byte[] extraEntropy) Most caller won't be able to provide extra entropy, but if one does have a dedicated device which can generate fresh entropy, it is welcome. Thanks Max From sean.mullan at oracle.com Fri Oct 2 13:51:46 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 2 Oct 2015 09:51:46 -0400 Subject: Optional used as method argument? In-Reply-To: <6A46E7CB-5CEF-483F-92ED-0153D639E12D@oracle.com> References: <57B3E0BE-64EC-44BC-9069-5558BEFA2EE0@oracle.com> <1265946042.2537314.1443773423877.JavaMail.zimbra@u-pem.fr> <560E7D60.9080201@Oracle.com> <6A46E7CB-5CEF-483F-92ED-0153D639E12D@oracle.com> Message-ID: <560E8BF2.1020405@oracle.com> On 10/2/15 9:27 AM, Wang Weijun wrote: > >> ? 2015?10?2????8:49?Roger Riggs <Roger.Riggs at oracle.com> ??? >> >> +1 >> >> The "no such value" makes me curious about the context. >> The @param tag really should be saying something about the parameter. > > In fact, I'm working on a method which is similar to > > /* > * Generates some random bytes. > * > * @param n requested random value in bytes. > * @param extraEntropy optional entropy caller can provide, null if none. > */ > byte[] getRandom(int n, byte[] extraEntropy) > > Most caller won't be able to provide extra entropy, but if one does have a dedicated device which can generate fresh entropy, it is welcome. Alternatively, you could just add an overloaded method, and not allow a null value for extraEntropy: byte[] getRandom(int n) byte[] getRandom(int n, byte[] extraEntropy) --Sean From lance.andersen at oracle.com Fri Oct 2 14:06:05 2015 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 2 Oct 2015 10:06:05 -0400 Subject: RFR (JAXP) 8138721 : ElementTraversal: javadoc warning; also, hasFeature shall return true In-Reply-To: <560E79F9.1070508@oracle.com> References: <560DCCE9.2010301@oracle.com> <560E79F9.1070508@oracle.com> Message-ID: <620FD6B9-28DE-48F7-853D-B2FB261CA485@oracle.com> On Oct 2, 2015, at 8:35 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote: > Looks fine to me Joe. > Strange that a trailing '.' could produce such a warning. Perhaps a javadoc bug? > > I have a question however about: > > (feature.equalsIgnoreCase("ElementTraversal") > 128 && (anyVersion > 129 || version.equals("1.0")) > > Does this means that ElementTraversal is only supported > on DOM 1.0 - and not on DOM 2.0 and 3.0? I am a little confused on this also as I looked at http://www.w3.org/TR/ElementTraversal/ and seems that it should be OK with DOM 2.0 and 3.0 unless I misunderstood the doc hasFeature() probably should check if feature is null to avoid an NPE? Best Lance > > best regards, > > -- daniel > > > On 02/10/15 02:16, huizhe wang wrote: >> Hi, >> >> Thanks Lance and Daniel for pointing out the javadoc warning! Here's the >> fix. Also, added ElementTraversal to the DOMImplementation supported >> feature list. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8138721 >> http://cr.openjdk.java.net/~joehw/jdk9/8138721/webrev/ >> >> Thanks, >> Joe >> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Roger.Riggs at Oracle.com Fri Oct 2 14:12:35 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 2 Oct 2015 10:12:35 -0400 Subject: Optional used as method argument? In-Reply-To: <560E8BF2.1020405@oracle.com> References: <57B3E0BE-64EC-44BC-9069-5558BEFA2EE0@oracle.com> <1265946042.2537314.1443773423877.JavaMail.zimbra@u-pem.fr> <560E7D60.9080201@Oracle.com> <6A46E7CB-5CEF-483F-92ED-0153D639E12D@oracle.com> <560E8BF2.1020405@oracle.com> Message-ID: <560E90D3.8020204@Oracle.com> +1 On 10/2/2015 9:51 AM, Sean Mullan wrote: > > > On 10/2/15 9:27 AM, Wang Weijun wrote: >> >>> ? 2015?10?2????8:49?Roger Riggs <Roger.Riggs at oracle.com> ??? >>> >>> +1 >>> >>> The "no such value" makes me curious about the context. >>> The @param tag really should be saying something about the parameter. >> >> In fact, I'm working on a method which is similar to >> >> /* >> * Generates some random bytes. >> * >> * @param n requested random value in bytes. >> * @param extraEntropy optional entropy caller can provide, null >> if none. >> */ >> byte[] getRandom(int n, byte[] extraEntropy) >> >> Most caller won't be able to provide extra entropy, but if one does >> have a dedicated device which can generate fresh entropy, it is welcome. > > Alternatively, you could just add an overloaded method, and not allow > a null value for extraEntropy: > > byte[] getRandom(int n) > byte[] getRandom(int n, byte[] extraEntropy) > > --Sean From jason_mehrens at hotmail.com Fri Oct 2 14:14:49 2015 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Fri, 2 Oct 2015 14:14:49 +0000 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <560D3F61.6040607@Oracle.com> References: <560D3F61.6040607@Oracle.com> Message-ID: <BN4PR13MB05948E56FCC318810D32D2D0834B0@BN4PR13MB0594.namprd13.prod.outlook.com> Roger, For custom thread factories, do we have to explictly set the CCL for the created thread or should that be a documented as a warning to all who use it? In web apps that can be a form of a memory leak. Jason _______________________________________ From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> on behalf of Roger Riggs <Roger.Riggs at Oracle.com> Sent: Thursday, October 1, 2015 9:12 AM To: Core-Libs-Dev Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization Please review a proposal for public Cleaner API: A Cleaner is proposed to provide an easy to use alternative to finalization. The service would provide easy registration and cancellation of cleanup functions for objects. Applications create a cleanup service for their own use and the service terminates when it is no longer in use. Finalization has a long history of issues both in usage and performance. PhantomReferences have been proposed as the alternative GC based mechanism for cleaning functions but it has been left as an exercise to the developer to construct the necessary mechanisms to handle ReferenceQueues, handle threading issues and robust termination. The Cleaner performs cleaning functions when objects are unreachable as found by garbage collection using the existing mechanisms of PhantomReference, WeakReference, SoftReferences, and ReferenceQueues. It manages a thread that dequeues references to unreachable objects and invokes the corresponding cleaning function. Registered cleaning functions can be cleared if no longer needed, can be invoked explicitly to perform the cleanup immediately, or be invoked when the object is not reachable (as detected by garbage collection) and handled by a cleanup thread. The java.lang.ref package is proposed for the Cleaner because it is complementary to the reference classes and reference queues and to make it easy to find. It is not a goal to replace all uses of finalization or sun.misc.Cleaner in the JDK. Investigation will evaluate if and in what cases the Cleaner can replace finalization. A subsequent task will examine uses of finalization and propose specific changes on a case by base basis. Please review and comment: Javadoc: http://cr.openjdk.java.net/~rriggs/cleaner-doc/ Webrev: http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ Issue: https://bugs.openjdk.java.net/browse/JDK-8138696 Thanks, Roger From weijun.wang at oracle.com Fri Oct 2 14:20:10 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 2 Oct 2015 22:20:10 +0800 Subject: Optional used as method argument? In-Reply-To: <560E8BF2.1020405@oracle.com> References: <57B3E0BE-64EC-44BC-9069-5558BEFA2EE0@oracle.com> <1265946042.2537314.1443773423877.JavaMail.zimbra@u-pem.fr> <560E7D60.9080201@Oracle.com> <6A46E7CB-5CEF-483F-92ED-0153D639E12D@oracle.com> <560E8BF2.1020405@oracle.com> Message-ID: <06CFEFC7-63F6-4E0A-815D-5180FF9BB00B@oracle.com> > ? 2015?10?2????9:51?Sean Mullan <sean.mullan at oracle.com> ??? > > > > On 10/2/15 9:27 AM, Wang Weijun wrote: >> >>> ? 2015?10?2????8:49?Roger Riggs <Roger.Riggs at oracle.com> ??? >>> >>> +1 >>> >>> The "no such value" makes me curious about the context. >>> The @param tag really should be saying something about the parameter. >> >> In fact, I'm working on a method which is similar to >> >> /* >> * Generates some random bytes. >> * >> * @param n requested random value in bytes. >> * @param extraEntropy optional entropy caller can provide, null if none. >> */ >> byte[] getRandom(int n, byte[] extraEntropy) >> >> Most caller won't be able to provide extra entropy, but if one does have a dedicated device which can generate fresh entropy, it is welcome. > > Alternatively, you could just add an overloaded method, and not allow a null value for extraEntropy: > > byte[] getRandom(int n) > byte[] getRandom(int n, byte[] extraEntropy) Accepted. Thanks Max > > --Sean From georgiy.rakov at oracle.com Fri Oct 2 14:21:19 2015 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Fri, 2 Oct 2015 17:21:19 +0300 Subject: [9] Review request JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader In-Reply-To: <560E7B6D.8020508@oracle.com> References: <55D5E163.6090905@oracle.com> <55F2F9F4.5090309@oracle.com> <56054D74.3070903@oracle.com> <56059161.2010808@oracle.com> <560A95E8.30907@oracle.com> <47E51B07-4FA1-4C13-9F8C-450B44C8FE20@oracle.com> <560BE098.7090809@oracle.com> <1ACCA360-ED4B-4A06-B0AD-52F14E604FCD@oracle.com> <560BFAED.4070802@oracle.com> <560D165F.4030808@oracle.com> <560D4CEA.4000808@oracle.com> <560E7B6D.8020508@oracle.com> Message-ID: <560E92DF.4000807@oracle.com> On 02.10.2015 15:41, Miroslav Kos wrote: > Hi Georgiy, > would you be ok with this defensive solution? > > Thanks > Miran > > > On 01/10/15 17:10, Miroslav Kos wrote: >> Hi, >> >> there is a new version of specdiff: >> http://cr.openjdk.java.net/~mkos/8131334/specdiff.06/index.html >> >> To remind, there were two problems to be addressed, both related to >> SAAJMetaFactory: >> http://cr.openjdk.java.net/~mkos/8131334/specdiff.06/javax/xml/soap/SAAJMetaFactory.html >> >> 1) hidden feature of lookup mechanism for SAAJMetaFactory: >> I added two new paragraphs into javadoc >> - one references the service loader facility >> - the second one mentions additional steps and references the >> algorithm in javax.xml.soap package desc >> According to the spec ofSAAJMetaFactory.newInstance method there is the last step of lookup procedure: * <LI>Default to com.sun.xml.internal.messaging.saaj.soap.SAAJMetaFactoryImpl. If this step is still performed, I believe this should be mentioned like it's made in the last step of the lookup procedure described in javax.xml.soap: "...or platform default implementation is used...". BTW it would be good to mention what newMessageFactory and newSOAPFactory of this default implementation return (I guess the default implementations of corresponding factories). Another point is that in the first review you sent there was a non-normative note you removed, maybe it's worth being restored(?) Just a stylistic note - wouldn't be easier just to create a list of SAAJMetaFactory lookup steps like it's done in |javax.xml.soap?| Another point - is it worth mentioning how custom SAAJMetaFactory is instantiated by SAAJ API? I mean is it instantiated only once and then the reference is stored, or is it instantiated each time user requests |SOAPFactory| or |MessageFactory| creation and SAAJMetaFactory instance is needed? Thank you, Georgiy.|| >> 2) SAAJMetaFactory supports only 2 of 3 SAAJ Factories >> - this is current state, we are not changing that - I am afraid >> adding a new abstract method into existing Factory class is too >> incompatible change for MR >> - just changed javadoc: >> AlloftheThe|newInstance|methods defined on factories|SOAPFactory| >> <http://cr.openjdk.java.net/%7Emkos/8131334/specdiff.06/javax/xml/soap/SOAPFactory.html>and|MessageFactory| >> <http://cr.openjdk.java.net/%7Emkos/8131334/specdiff.06/javax/xml/soap/MessageFactory.html> >> ... >> Ok, thanks. >> Thanks >> Miran >> > From steve.drach at oracle.com Fri Oct 2 14:52:30 2015 From: steve.drach at oracle.com (Steve Drach) Date: Fri, 2 Oct 2015 07:52:30 -0700 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <87E13291-6EAF-4CBA-93A4-B9D21C0921E5@oracle.com> References: <A12C71A8-59AB-4271-873F-4F3435EB2493@oracle.com> <560AD899.2020903@oracle.com> <991FA3D3-851A-4912-8C71-80FD13C74496@oracle.com> <560D6381.8070907@oracle.com> <346ED951-5BD4-4F55-9C1E-2DB17353C83E@oracle.com> <560D88B5.2000701@oracle.com> <87E13291-6EAF-4CBA-93A4-B9D21C0921E5@oracle.com> Message-ID: <9DC76D9F-A69C-49CB-A7D6-5A83DA6A9FBA@oracle.com> >> Okay. On the the ZipFileSystem then it would be good to get a summary on what you are proposing. > > Details of any JavacFileManager/ZipFileSystem support are still being hashed out. They are mentioned in the JEP and we can update once those details are finalized. To elaborate a bit, the implementation is quite straight forward. ZipFileSystem builds an Inode tree on open. That tree is implemented as a Map<Inode,Inode>. For regular zip/jar files both the key and the value are the same Inode. For multi-release jar files the value is the Inode of the appropriate versioned entry. Configuration is through the Map<String,?> env parameter to the FileSystems.newFileSystem parameter. From Roger.Riggs at Oracle.com Fri Oct 2 15:06:19 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 2 Oct 2015 11:06:19 -0400 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <BN4PR13MB05948E56FCC318810D32D2D0834B0@BN4PR13MB0594.namprd13.prod.outlook.com> References: <560D3F61.6040607@Oracle.com> <BN4PR13MB05948E56FCC318810D32D2D0834B0@BN4PR13MB0594.namprd13.prod.outlook.com> Message-ID: <560E9D6B.9080306@Oracle.com> Hi Jason, The caller that creates the Cleaner does contribute some of its state to the new Thread including the normal inheritance of the ContextClassLoader, InheritableThreadLocals, etc. So yes, if in your context the ThreadFactory would take precautions then the thread factory used for the Cleaner would be no different. The default factory uses sun.misc.InnocuousThread which explicitly sets the context classloader to the System class Loader and discards inheritable thread locals. Is there an example of the warning you suggest elsewhere in the JDK? Thanks, Roger On 10/2/2015 10:14 AM, Jason Mehrens wrote: > Roger, > > For custom thread factories, do we have to explictly set the CCL for the created thread or should that be a documented as a warning to all who use it? In web apps that can be a form of a memory leak. > > Jason > > _______________________________________ > From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> on behalf of Roger Riggs <Roger.Riggs at Oracle.com> > Sent: Thursday, October 1, 2015 9:12 AM > To: Core-Libs-Dev > Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization > > Please review a proposal for public Cleaner API: > > A Cleaner is proposed to provide an easy to use alternative to > finalization. The service would provide easy registration and > cancellation of cleanup functions for objects. Applications create a > cleanup service for their own use and the service terminates when it is > no longer in use. > > Finalization has a long history of issues both in usage and performance. > PhantomReferences have been proposed as the alternative GC based > mechanism for cleaning functions but it has been left as an exercise to > the developer to construct the necessary mechanisms to handle > ReferenceQueues, handle threading issues and robust termination. > > The Cleaner performs cleaning functions when objects are unreachable as > found by garbage collection using the existing mechanisms of > PhantomReference, WeakReference, SoftReferences, and ReferenceQueues. It > manages a thread that dequeues references to unreachable objects and > invokes the corresponding cleaning function. Registered cleaning > functions can be cleared if no longer needed, can be invoked explicitly > to perform the cleanup immediately, or be invoked when the object is not > reachable (as detected by garbage collection) and handled by a cleanup > thread. > > The java.lang.ref package is proposed for the Cleaner because it is > complementary to the reference classes and reference queues and to make > it easy to find. > > It is not a goal to replace all uses of finalization or sun.misc.Cleaner > in the JDK. > Investigation will evaluate if and in what cases the Cleaner can replace > finalization. > A subsequent task will examine uses of finalization and propose specific > changes > on a case by base basis. > > Please review and comment: > > Javadoc: > http://cr.openjdk.java.net/~rriggs/cleaner-doc/ > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8138696 > > Thanks, Roger > From Alan.Bateman at oracle.com Fri Oct 2 15:09:29 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 02 Oct 2015 16:09:29 +0100 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <9DC76D9F-A69C-49CB-A7D6-5A83DA6A9FBA@oracle.com> References: <A12C71A8-59AB-4271-873F-4F3435EB2493@oracle.com> <560AD899.2020903@oracle.com> <991FA3D3-851A-4912-8C71-80FD13C74496@oracle.com> <560D6381.8070907@oracle.com> <346ED951-5BD4-4F55-9C1E-2DB17353C83E@oracle.com> <560D88B5.2000701@oracle.com> <87E13291-6EAF-4CBA-93A4-B9D21C0921E5@oracle.com> <9DC76D9F-A69C-49CB-A7D6-5A83DA6A9FBA@oracle.com> Message-ID: <560E9E29.2000902@oracle.com> On 02/10/2015 15:52, Steve Drach wrote : > To elaborate a bit, the implementation is quite straight forward. ZipFileSystem builds an Inode tree on open. That tree is implemented as a Map<Inode,Inode>. For regular zip/jar files both the key and the value are the same Inode. For multi-release jar files the value is the Inode of the appropriate versioned entry. Configuration is through the Map<String,?> env parameter to the FileSystems.newFileSystem parameter. It sounds like you have a handle on this, the main thing is that by default it's just a file system, irrespective of whether META-INF/versions exists or not. If there is configuration specified via the env map then it can work multi-versioned, it just can't be the default because the file system provider has no knowledge as to how the API is being used. -Alan From steve.drach at oracle.com Fri Oct 2 15:14:52 2015 From: steve.drach at oracle.com (Steve Drach) Date: Fri, 2 Oct 2015 08:14:52 -0700 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <560E9E29.2000902@oracle.com> References: <A12C71A8-59AB-4271-873F-4F3435EB2493@oracle.com> <560AD899.2020903@oracle.com> <991FA3D3-851A-4912-8C71-80FD13C74496@oracle.com> <560D6381.8070907@oracle.com> <346ED951-5BD4-4F55-9C1E-2DB17353C83E@oracle.com> <560D88B5.2000701@oracle.com> <87E13291-6EAF-4CBA-93A4-B9D21C0921E5@oracle.com> <9DC76D9F-A69C-49CB-A7D6-5A83DA6A9FBA@oracle.com> <560E9E29.2000902@oracle.com> Message-ID: <DC28AD1C-D723-4B81-A0CF-AF1E413B940E@oracle.com> >> To elaborate a bit, the implementation is quite straight forward. ZipFileSystem builds an Inode tree on open. That tree is implemented as a Map<Inode,Inode>. For regular zip/jar files both the key and the value are the same Inode. For multi-release jar files the value is the Inode of the appropriate versioned entry. Configuration is through the Map<String,?> env parameter to the FileSystems.newFileSystem parameter. > It sounds like you have a handle on this, the main thing is that by default it's just a file system, irrespective of whether META-INF/versions exists or not. Yes > If there is configuration specified via the env map then it can work multi-versioned, it just can't be the default because the file system provider has no knowledge as to how the API is being used. Yes. one has to specially request multi-release processing when the file system is opened. From Roger.Riggs at Oracle.com Fri Oct 2 15:34:10 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 2 Oct 2015 11:34:10 -0400 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <560E6FEB.60607@gmail.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> Message-ID: <560EA3F2.7030108@Oracle.com> Hi Peter, Great comments, thanks for looking into this... On 10/2/2015 7:52 AM, Peter Levart wrote: > Hi Roger, > > This is a nice and clean API. I like the trick with embedding a > private CleanerImpl in Cleaner and registering Cleaner itself as a > tracked object so that automatic thread termination can be performed > in a safe manner. You say the scope of this is not to replace internal > usages of sun.misc.Cleaner. But if they ever get replaced, there are > two differences between the implementations to note: > > - sun.misc.Cleaner thunks get executed by a ReferenceHandler thread > directly and bypass ReferenceQueue-ing. This might be OK for internal > use, but not appropriate for public API. I doubt this sun.misc.Cleaner > exception in ReferenceHandler is necessary though. > - With sun.misc.Cleaner one has to create a minimum of 2 additional > objects per tracked object: the Cleaner object and a Runnable thunk. > This API requires creation of 3 objects per tracked object: the > Cleanup object, the internal Reference object and a Runnable thunk. > > Do you think Cleaner will not be used in scenarios where this > additional footprint matters? I don't have any particular data on that point. When used with lambda or method references for the thunk, it is likely there will be some binding overhead. > > It might be possible to merge the roles of Cleanup and Reference into > one object, like this: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/Cleaner/Cleaner.java > > Making Cleanup an interface, internal Reference(s) can implement it. > One can cast a Cleanup instance to a Reference and invoke it's other > methods, but this can be prevented by throwing > UnsupportedOperationException from them, so nobody is tempted to > employ this implementation detail. I prototyped a similar implementation but backed it out due to the code duplication and complexity. It also seemed a poor choice to break the contract of Reference by throwing UnsupportedOperationException on the unneeded but exposed methods since they could not be completely encapsulated. It seemed cleaner to have only a concrete type that was exposed to the clients. BTW, the code in you cleaner might be simpler if the cleaner lists for each of the three types were separate. (The entries don't need to be intermixed). That could simplify the virtual next/prev access but would still be duplicating the linked list management code). There could be multiple insertXXX methods so the casts were not necessary. > > There might be utility in exposing Cleanup (or better named Cleanable) > References as public abstract classes so that a footprint sensitive > application (for example in a data structure with many elements) is > possible. By subclassing such an abstract reference and implementing > the abstract method, a single object is required per tracked object. > Here I derived a proof of concept from your code: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/Cleaner/webrev.01/ > > The simple API is unchanged and there is additional low-level API that > can be used if footprint matters. > > What do you think? I see what you're getting at. I would probably try to rearrange it so that only the performMethod could be overridden. Overriding clean() and clear() might disable the list management and reduce the robustness. I'll take another look, I was most concerned with simplicity, but if the overhead for the number of the objects is a concern that can be traded off against a more complex implementation. Thanks, Roger > > Regards, Peter > > > On 10/01/2015 04:12 PM, Roger Riggs wrote: >> Please review a proposal for public Cleaner API: >> >> A Cleaner is proposed to provide an easy to use alternative to >> finalization. The service would provide easy registration and >> cancellation of cleanup functions for objects. Applications create a >> cleanup service for their own use and the service terminates when it >> is no longer in use. >> >> Finalization has a long history of issues both in usage and >> performance. PhantomReferences have been proposed as the alternative >> GC based mechanism for cleaning functions but it has been left as an >> exercise to the developer to construct the necessary mechanisms to >> handle ReferenceQueues, handle threading issues and robust termination. >> >> The Cleaner performs cleaning functions when objects are unreachable >> as found by garbage collection using the existing mechanisms of >> PhantomReference, WeakReference, SoftReferences, and ReferenceQueues. >> It manages a thread that dequeues references to unreachable objects >> and invokes the corresponding cleaning function. Registered cleaning >> functions can be cleared if no longer needed, can be invoked >> explicitly to perform the cleanup immediately, or be invoked when the >> object is not reachable (as detected by garbage collection) and >> handled by a cleanup thread. >> >> The java.lang.ref package is proposed for the Cleaner because it is >> complementary to the reference classes and reference queues and to >> make it easy to find. >> >> It is not a goal to replace all uses of finalization or >> sun.misc.Cleaner in the JDK. >> Investigation will evaluate if and in what cases the Cleaner can >> replace finalization. >> A subsequent task will examine uses of finalization and propose >> specific changes >> on a case by base basis. >> >> Please review and comment: >> >> Javadoc: >> http://cr.openjdk.java.net/~rriggs/cleaner-doc/ >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8138696 >> >> Thanks, Roger >> > From miroslav.kos at oracle.com Fri Oct 2 15:52:32 2015 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Fri, 2 Oct 2015 17:52:32 +0200 Subject: [9] Review request JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader In-Reply-To: <560E92DF.4000807@oracle.com> References: <55D5E163.6090905@oracle.com> <55F2F9F4.5090309@oracle.com> <56054D74.3070903@oracle.com> <56059161.2010808@oracle.com> <560A95E8.30907@oracle.com> <47E51B07-4FA1-4C13-9F8C-450B44C8FE20@oracle.com> <560BE098.7090809@oracle.com> <1ACCA360-ED4B-4A06-B0AD-52F14E604FCD@oracle.com> <560BFAED.4070802@oracle.com> <560D165F.4030808@oracle.com> <560D4CEA.4000808@oracle.com> <560E7B6D.8020508@oracle.com> <560E92DF.4000807@oracle.com> Message-ID: <560EA840.5000602@oracle.com> There is an updated version: http://cr.openjdk.java.net/~mkos/8131334/specdiff.07/index.html Two changes: 1) SAAJMetaFactory javadoc - new (self contained) paragraph describing the algorithm for the factory + apiNote 2) package javadoc: added back SAAJMetaFactory + "all these factories define newInstance method ..." changed to "first three ..." + sentence about instantiating SAAJMetaFactory On 02/10/15 16:21, Georgiy Rakov wrote: > According to the spec ofSAAJMetaFactory.newInstance method there is > the last step of lookup procedure: > * <LI>Default to > com.sun.xml.internal.messaging.saaj.soap.SAAJMetaFactoryImpl. I mentioned the default impl. I believe it's specific enough - in jdk8 version there is nothing regarding this ... > If this step is still performed, I believe this should be mentioned > like it's made in the last step of the lookup procedure described in > javax.xml.soap: "...or platform default implementation is used...". > BTW it would be good to mention what newMessageFactory and > newSOAPFactory of this default implementation return (I guess the > default implementations of corresponding factories). I don't think it's necessary. > > Another point is that in the first review you sent there was a > non-normative note you removed, maybe it's worth being restored(?) restored. > > Just a stylistic note - wouldn't be easier just to create a list of > SAAJMetaFactory lookup steps like it's done in |javax.xml.soap?| done. > > Another point - is it worth mentioning how custom SAAJMetaFactory is > instantiated by SAAJ API? I mean is it instantiated only once and then > the reference is stored, or is it instantiated each time user requests > |SOAPFactory| or |MessageFactory| creation and SAAJMetaFactory > instance is needed? I added a sentence about this to section "Discovery of SAAJ implementation": Whenever|SAAJMetaFactory| <http://cr.openjdk.java.net/%7Emkos/8131334/specdiff.07/javax/xml/soap/SAAJMetaFactory.html>isused,itslookupproceduretogetactualinstanceisperformed. Thanks Miran > > Thank you, > Georgiy.|| >>> 2) SAAJMetaFactory supports only 2 of 3 SAAJ Factories >>> - this is current state, we are not changing that - I am afraid >>> adding a new abstract method into existing Factory class is too >>> incompatible change for MR >>> - just changed javadoc: >>> AlloftheThe|newInstance|methods defined on factories|SOAPFactory| >>> <http://cr.openjdk.java.net/%7Emkos/8131334/specdiff.06/javax/xml/soap/SOAPFactory.html>and|MessageFactory| >>> <http://cr.openjdk.java.net/%7Emkos/8131334/specdiff.06/javax/xml/soap/MessageFactory.html> >>> ... >>> > Ok, thanks. >>> Thanks >>> Miran >>> >> > From kevinb at google.com Fri Oct 2 16:22:00 2015 From: kevinb at google.com (Kevin Bourrillion) Date: Fri, 2 Oct 2015 09:22:00 -0700 Subject: JEP 269: Convenience Factory Methods for Collections In-Reply-To: <1548646383.2640105.1443208816341.JavaMail.zimbra@u-pem.fr> References: <20150924000217.D476B7A327@eggemoggin.niobe.net> <CAGKkBks7CKsJngvagV15C47E6zncdS-ag2m2OOKGoTtm-+YFFw@mail.gmail.com> <1548646383.2640105.1443208816341.JavaMail.zimbra@u-pem.fr> Message-ID: <CAGKkBkveaKTmGbhYJ4J8NNzkD5DwMz+ZvhHufC5Q2tQHU5D3Jg@mail.gmail.com> Tangent: On Fri, Sep 25, 2015 at 12:20 PM, Remi Forax <forax at univ-mlv.fr> wrote: > Note that without permitting nulls, Map.of(key, Optional.of(value)) will > > become reasonably common, and that fact you can't serialize that will > > become even more strange than it already is. > > Please don't do that, if you have a mapping between a key and something > that doesn't exist, the best is to not have that mapping, > this is the semantics of java.util.concurrent (with null instead of > Optional) and this is the only sane semantics. > Optional should never appear in collections/maps, it makes the code that > deal with this kind of beast stupidly harder to read/write for no benefit. > If you had no need to distinguish between not-present and mapped-to-absent, then the idea of using a Map<K, Optional<V>> is so bizarre that I'm not sure why we would even discuss it. We have ~1800 occurrences of Optional-valued Maps or Caches in Google. They do this for an actual reason: a negative result is meaningfully different from no result. This is addressed in our Optional javadoc <http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/base/Optional.html> . -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com From huizhe.wang at oracle.com Fri Oct 2 17:18:55 2015 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 02 Oct 2015 10:18:55 -0700 Subject: RFR (JAXP) 8138721 : ElementTraversal: javadoc warning; also, hasFeature shall return true In-Reply-To: <620FD6B9-28DE-48F7-853D-B2FB261CA485@oracle.com> References: <560DCCE9.2010301@oracle.com> <560E79F9.1070508@oracle.com> <620FD6B9-28DE-48F7-853D-B2FB261CA485@oracle.com> Message-ID: <560EBC7F.8060204@oracle.com> Thanks Daniel, Lance! On 10/2/2015 7:06 AM, Lance Andersen wrote: > > On Oct 2, 2015, at 8:35 AM, Daniel Fuchs <daniel.fuchs at oracle.com > <mailto:daniel.fuchs at oracle.com>> wrote: > >> Looks fine to me Joe. >> Strange that a trailing '.' could produce such a warning. > Perhaps a javadoc bug? Seems to be, the message didn't make any sense. But it was reported before: https://bugs.openjdk.java.net/browse/JDK-4907024 -- although it was not because of the <cite> tag as reported. It's just that the message didn't reflect the true issue. >> >> I have a question however about: >> >> (feature.equalsIgnoreCase("ElementTraversal") >> 128 && (anyVersion >> 129 || version.equals("1.0")) >> >> Does this means that ElementTraversal is only supported >> on DOM 1.0 - and not on DOM 2.0 and 3.0? > > I am a little confused on this also as I looked at > http://www.w3.org/TR/ElementTraversal/ and seems that it should be OK > with DOM 2.0 and 3.0 unless I misunderstood the doc Element Traversal is a separate specification from core DOM 2.0 and 3.0. In the above statement, it reports that the ElementTraversal is supported without specifying a version or ElementTraversal Version 1.0. That was why I re-formatted it to make sure (feature.equals...) were lined up (refer to the Sdiff). > > hasFeature() probably should check if feature is null to avoid an NPE? Added, refer to DOMImplementationImpl. The spec for hasFeature didn't declare any exception, so I'm going to just let it return false. http://cr.openjdk.java.net/~joehw/jdk9/8138721/webrev/ -Joe > > Best > Lance >> >> best regards, >> >> -- daniel >> >> >> On 02/10/15 02:16, huizhe wang wrote: >>> Hi, >>> >>> Thanks Lance and Daniel for pointing out the javadoc warning! Here's the >>> fix. Also, added ElementTraversal to the DOMImplementation supported >>> feature list. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8138721 >>> http://cr.openjdk.java.net/~joehw/jdk9/8138721/webrev/ >>> <http://cr.openjdk.java.net/%7Ejoehw/jdk9/8138721/webrev/> >>> >>> Thanks, >>> Joe >>> >> > > <http://oracle.com/us/design/oracle-email-sig-198324.gif> > <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif> > <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com> > > > From georgiy.rakov at oracle.com Fri Oct 2 17:36:26 2015 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Fri, 2 Oct 2015 20:36:26 +0300 Subject: [9] Review request JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader In-Reply-To: <560EA840.5000602@oracle.com> References: <55D5E163.6090905@oracle.com> <55F2F9F4.5090309@oracle.com> <56054D74.3070903@oracle.com> <56059161.2010808@oracle.com> <560A95E8.30907@oracle.com> <47E51B07-4FA1-4C13-9F8C-450B44C8FE20@oracle.com> <560BE098.7090809@oracle.com> <1ACCA360-ED4B-4A06-B0AD-52F14E604FCD@oracle.com> <560BFAED.4070802@oracle.com> <560D165F.4030808@oracle.com> <560D4CEA.4000808@oracle.com> <560E7B6D.8020508@oracle.com> <560E92DF.4000807@oracle.com> <560EA840.5000602@oracle.com> Message-ID: <560EC09A.8080804@oracle.com> On 02.10.2015 18:52, Miroslav Kos wrote: > There is an updated version: > http://cr.openjdk.java.net/~mkos/8131334/specdiff.07/index.html > Two changes: > 1) SAAJMetaFactory javadoc - new (self contained) paragraph describing > the algorithm for the factory + apiNote > 2) package javadoc: added back SAAJMetaFactory + "all these factories > define newInstance method ..." changed to "first three ..." + sentence > about instantiating SAAJMetaFactory > > > On 02/10/15 16:21, Georgiy Rakov wrote: >> According to the spec ofSAAJMetaFactory.newInstance method there is >> the last step of lookup procedure: >> * <LI>Default to >> com.sun.xml.internal.messaging.saaj.soap.SAAJMetaFactoryImpl. > I mentioned the default impl. I believe it's specific enough - in jdk8 > version there is nothing regarding this ... >> If this step is still performed, I believe this should be mentioned >> like it's made in the last step of the lookup procedure described in >> javax.xml.soap: "...or platform default implementation is used...". >> BTW it would be good to mention what newMessageFactory and >> newSOAPFactory of this default implementation return (I guess the >> default implementations of corresponding factories). > I don't think it's necessary. From conformance testing perspective it's not clear what to expect from MessageFactory.newInstance and SOAPFactory.newInstance when there is no configuration at all (ServiceLoader is not configured, jaxm.properties is missing, corresponding system property is not set). For instance returning null doesn't contradict spec. Not specifying it actually means that this is left up to implementation. Any conformance tests written and expecting non-null result could be successfully challenged by an external implementer returning null since there is no spec about it. Thus we merely cannot write conformance tests verifying MessageFactory and SOAPFactory default implementations if this is the way how they are to be obtained. I'm telling about the way of obtaining the default implementation because there are actually another way that is to configure ServiceLoader to return default implementation. But I don't like this idea, since there are other questions arise, for instance if we should normatively specify that ServiceLoader should be configured to return default implementation. The rest looks great. Thanks, Georgiy. From aleksej.efimov at oracle.com Fri Oct 2 17:47:56 2015 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Fri, 2 Oct 2015 20:47:56 +0300 Subject: RFR: 8138716: (tz) Support tzdata2015g Message-ID: <560EC34C.6060100@oracle.com> Hi, Please, help to review the latest tzdata integration [1] fix to JDK9: http://cr.openjdk.java.net/~aefimov/tzdata/2015g/9/00/index.html Testing shows no failures in time zones related tests. With Best Regards, Aleksej [1] JBS: https://bugs.openjdk.java.net/browse/JDK-8138716 From openjdk at duigou.org Fri Oct 2 19:33:01 2015 From: openjdk at duigou.org (Mike Duigou) Date: Fri, 02 Oct 2015 12:33:01 -0700 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use > =?UTF-8?Q?=20=20=20=20=20=20alternative=09to=20finalization=20=28Roger=20?= =?UTF-8?Q?Riggs=29?= In-Reply-To: <mailman.7407.1443712301.25018.core-libs-dev@openjdk.java.net> References: <mailman.7407.1443712301.25018.core-libs-dev@openjdk.java.net> Message-ID: <2c3333ec8a1a5f9b132222de2e96386b@sonic.net> Hi Roger; This looks like an interesting proposal and would be a good replacement for alternative solutions. I am curious why the thread is run at max priority. Also, why not set priority and daemon status in the factory? You should clear the Thread intrerruption if you are going to ignore it. Thread.interrupted(); I would suggest surrounding the thunk.run() with a catch of Throwable or Exception. In the current implementation one bad egg spoils the party for everyone. There is a catch of RuntimeException described as "catch (RuntimeException e) { // ignore exceptions from the cleanup thunk }" but I would suggest that this is insufficiently paranoid. Consider a pattern like: private static final ReferenceQueue<Object> weakListeners = new ReferenceQueue<>(); private static class CleanerThread extends Thread { { setDaemon(true); setPriority(Thread.MIN_PRIORITY); } @Override @SuppressWarnings("unchecked") public void run() { // Using weak ref to queue allows shutdown if class is unloaded WeakReference<ReferenceQueue<Object>> weakQueue = new WeakReference<>(weakListeners); ReferenceQueue<Object> queue = null; while((queue = (queue == null ? weakQueue.get() : queue) != null) try { Object dead = queue.remove(10000); if(dead != null) { // do stuff with "dead" } else { queue = null; // recheck to see if queue is gone. } } catch(InterruptedException woken) { Thread.interrupted(); } } } When 'weakListeners' is cleared when the containing class is unloaded then the thread will shut down after roughly 10 seconds. I have been meaning to check whether CleanerThread needs to be in a separate class--an inner class, even a static one, may prevent it's containing class from being GCed. IDK. Mike From Roger.Riggs at Oracle.com Fri Oct 2 20:16:56 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 2 Oct 2015 16:16:56 -0400 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use > alternative to finalization (Roger Riggs) In-Reply-To: <2c3333ec8a1a5f9b132222de2e96386b@sonic.net> References: <mailman.7407.1443712301.25018.core-libs-dev@openjdk.java.net> <2c3333ec8a1a5f9b132222de2e96386b@sonic.net> Message-ID: <560EE638.3020300@Oracle.com> Hi Mike, Thanks for the review and comments... On 10/2/2015 3:33 PM, Mike Duigou wrote: > Hi Roger; > > This looks like an interesting proposal and would be a good > replacement for alternative solutions. > > I am curious why the thread is run at max priority. Also, why not set > priority and daemon status in the factory? Yes, that should probably be left to the factory and for built-in factory would be moved to the InnocuousThreadFactory. > > You should clear the Thread intrerruption if you are going to ignore > it. Thread.interrupted(); Will do. > > I would suggest surrounding the thunk.run() with a catch of Throwable > or Exception. In the current implementation one bad egg spoils the > party for everyone. There is a catch of RuntimeException described as > "catch (RuntimeException e) { // ignore exceptions from the cleanup > thunk }" but I would suggest that this is insufficiently paranoid. Good point, catches more bad eggs. > > Consider a pattern like: > > private static final ReferenceQueue<Object> weakListeners = new > ReferenceQueue<>(); > > > private static class CleanerThread extends Thread { > { setDaemon(true); setPriority(Thread.MIN_PRIORITY); } > @Override > @SuppressWarnings("unchecked") > public void run() { > // Using weak ref to queue allows shutdown if class is unloaded > WeakReference<ReferenceQueue<Object>> weakQueue = new > WeakReference<>(weakListeners); > ReferenceQueue<Object> queue = null; > while((queue = (queue == null ? weakQueue.get() : queue) != null) > try { > Object dead = queue.remove(10000); > if(dead != null) { > // do stuff with "dead" > } else { > queue = null; // recheck to see if queue is gone. > } > } catch(InterruptedException woken) { > Thread.interrupted(); > } > } > } > > When 'weakListeners' is cleared when the containing class is unloaded > then the thread will shut down after roughly 10 seconds. > > I have been meaning to check whether CleanerThread needs to be in a > separate class--an inner class, even a static one, may prevent it's > containing class from being GCed. IDK. I think that 'nested' classes aka static class has no links to the outer class and can be GC'ed but will check. Thanks, Roger From brian.burkhalter at oracle.com Fri Oct 2 20:41:41 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 2 Oct 2015 13:41:41 -0700 Subject: [9] RFR of 8032027: Add BigInteger square root methods Message-ID: <75C5170A-11B1-437A-A411-C125D54406E9@oracle.com> Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8032027 Patch: http://cr.openjdk.java.net/~bpb/8032027/webrev.00/ Summary: Add sqrt() and sqrtAndRemainder() methods. The square root calculated is the integer square root ?s? such that for a given integer ?n? the value of ?s? is the largest integer such that s*s <= n. In other words it is the floor of the mathematical square root of the value ?n' taken as a mathematical real number. The method of calculation is Newton iteration starting from a value larger than the square root which ensures that the convergence is monotonically decreasing to the result. An effort is made to make the implementation efficient in particular with respect to the amount of memory used. Any suggestions as to the improvement of the approach concerning memory use or any other aspect of the algorithm would be appreciated, as would be suggestions regarding the test. Thanks, Brian From jason_mehrens at hotmail.com Fri Oct 2 20:52:03 2015 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Fri, 2 Oct 2015 20:52:03 +0000 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <560E9D6B.9080306@Oracle.com> References: <560D3F61.6040607@Oracle.com> <BN4PR13MB05948E56FCC318810D32D2D0834B0@BN4PR13MB0594.namprd13.prod.outlook.com>, <560E9D6B.9080306@Oracle.com> Message-ID: <BN4PR13MB05948172A049D4899D4A0247834B0@BN4PR13MB0594.namprd13.prod.outlook.com> Hi Roger, Thinking more on it, the 'thunk' objects could pin a class loader too so pinning the CCL should be obvious. I'm just having flashbacks of https://bugs.openjdk.java.net/browse/JDK-8025251 and trying to find any pitfalls in this code. The InnocuousThread is interesting because the workaround of setting the CCL in the 'thunk' would never work. It would work with the Executors.defaultThreadFactory() so that seems like something to warn lib designers about. I don't know of a good example where such a warning in the JDK. The Runtime.addShutdownHook would be the only place but since the user is creating a thread an not just a runnable it doesn't apply there. Jason ________________________________ From: Roger Riggs <Roger.Riggs at Oracle.com> Sent: Friday, October 2, 2015 10:06 AM To: Jason Mehrens; Core-Libs-Dev Subject: Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization Hi Jason, The caller that creates the Cleaner does contribute some of its state to the new Thread including the normal inheritance of the ContextClassLoader, InheritableThreadLocals, etc. So yes, if in your context the ThreadFactory would take precautions then the thread factory used for the Cleaner would be no different. The default factory uses sun.misc.InnocuousThread which explicitly sets the context classloader to the System class Loader and discards inheritable thread locals. Is there an example of the warning you suggest elsewhere in the JDK? Thanks, Roger On 10/2/2015 10:14 AM, Jason Mehrens wrote: Roger, For custom thread factories, do we have to explictly set the CCL for the created thread or should that be a documented as a warning to all who use it? In web apps that can be a form of a memory leak. Jason _______________________________________ From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net><mailto:core-libs-dev-bounces at openjdk.java.net> on behalf of Roger Riggs <Roger.Riggs at Oracle.com><mailto:Roger.Riggs at Oracle.com> Sent: Thursday, October 1, 2015 9:12 AM To: Core-Libs-Dev Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization Please review a proposal for public Cleaner API: A Cleaner is proposed to provide an easy to use alternative to finalization. The service would provide easy registration and cancellation of cleanup functions for objects. Applications create a cleanup service for their own use and the service terminates when it is no longer in use. Finalization has a long history of issues both in usage and performance. PhantomReferences have been proposed as the alternative GC based mechanism for cleaning functions but it has been left as an exercise to the developer to construct the necessary mechanisms to handle ReferenceQueues, handle threading issues and robust termination. The Cleaner performs cleaning functions when objects are unreachable as found by garbage collection using the existing mechanisms of PhantomReference, WeakReference, SoftReferences, and ReferenceQueues. It manages a thread that dequeues references to unreachable objects and invokes the corresponding cleaning function. Registered cleaning functions can be cleared if no longer needed, can be invoked explicitly to perform the cleanup immediately, or be invoked when the object is not reachable (as detected by garbage collection) and handled by a cleanup thread. The java.lang.ref package is proposed for the Cleaner because it is complementary to the reference classes and reference queues and to make it easy to find. It is not a goal to replace all uses of finalization or sun.misc.Cleaner in the JDK. Investigation will evaluate if and in what cases the Cleaner can replace finalization. A subsequent task will examine uses of finalization and propose specific changes on a case by base basis. Please review and comment: Javadoc: http://cr.openjdk.java.net/~rriggs/cleaner-doc/ Webrev: http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ Issue: https://bugs.openjdk.java.net/browse/JDK-8138696 Thanks, Roger From lowasser at google.com Fri Oct 2 20:54:28 2015 From: lowasser at google.com (Louis Wasserman) Date: Fri, 02 Oct 2015 20:54:28 +0000 Subject: [9] RFR of 8032027: Add BigInteger square root methods In-Reply-To: <75C5170A-11B1-437A-A411-C125D54406E9@oracle.com> References: <75C5170A-11B1-437A-A411-C125D54406E9@oracle.com> Message-ID: <CAGB9EW8eK=oHejGAhh-4P8+zFgUbSkn+=wvcsRcQcPc3WA_trg@mail.gmail.com> Have you investigated Guava's really quite tightly optimized implementation here? https://github.com/google/guava/blob/master/guava/src/com/google/common/math/BigIntegerMath.java#L242 A few years back I submitted a patch (now applied) to make BigInteger.doubleValue() very fast. If I recall correctly, that patch was originally inspired by my attempt to optimize sqrt on BigIntegers at the time. Converting the BigInteger to a double, using Math.sqrt(double), and using that as a starting point for Newton's method (converting that floating point value back to a BigInteger) buys you many bits of precision very fast. That result isn't guaranteed to be >= the true result, but one iteration of Newton's method will fix that. I'm quite certain you could improve on Guava's implementation even further with access to MutableBigInteger. On Fri, Oct 2, 2015 at 1:42 PM Brian Burkhalter <brian.burkhalter at oracle.com> wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8032027 > Patch: http://cr.openjdk.java.net/~bpb/8032027/webrev.00/ > > Summary: Add sqrt() and sqrtAndRemainder() methods. The square root > calculated is the integer square root ?s? such that for a given integer ?n? > the value of ?s? is the largest integer such that s*s <= n. In other words > it is the floor of the mathematical square root of the value ?n' taken as a > mathematical real number. > > The method of calculation is Newton iteration starting from a value larger > than the square root which ensures that the convergence is monotonically > decreasing to the result. An effort is made to make the implementation > efficient in particular with respect to the amount of memory used. Any > suggestions as to the improvement of the approach concerning memory use or > any other aspect of the algorithm would be appreciated, as would be > suggestions regarding the test. > > Thanks, > > Brian From xueming.shen at oracle.com Fri Oct 2 21:02:18 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 02 Oct 2015 14:02:18 -0700 Subject: RFR: String Density/Compact String JEP 254 Message-ID: <560EF0DA.8020908@oracle.com> Hi, Please review the change for JEP 254/Compact String project. JPE 254: http://openjdk.java.net/jeps/254 Issue: https://bugs.openjdk.java.net/browse/JDK-8054307 Webrevs: http://cr.openjdk.java.net/~sherman/8054307/jdk/ http://cr.openjdk.java.net/~thartmann/compact_strings/webrev/hotspot Description: String Density project is to change the internal representation of the String class from a UTF-16 char array to a byte array plus an encoding flag field. The new String class stores characters encoded either as ISO-8859-1/Latin-1 (one byte per character), or as UTF-16 (two bytes per character), based upon the contents of the string. The encoding flag indicates which encoding is used. It offers reduced memory footprint while maintaining throughput performance. See JEP 254 for more additional information Implementation repo to try out: http://hg.openjdk.java.net/jdk9/sandbox/ branch: JDK-8054307-branch $ hg clone http://hg.openjdk.java.net/jdk9/sandbox/ $ cd sandbox $ sh ./get_source.sh $ sh ./common/bin/hgforest.sh up -r JDK-8054307-branch $ make configure $ make images Implementation Notes: - To change the internal representation of the String and the String builder classes (AbstractStringBuilder, StringBuilder and StringBuffer) from a UTF-16 char array to a byte array plus an encoding flag field. The new representation stores the String characters in a single byte format using the lower 8-bit of character's 16-bit UTF16 value, and sets the encoding flag as LATIN1, if all characters of the String object are Unicode Latin1 characters (with its UTF16 value < \u0100) It stores the String characters in 2-byte format with their UTF-16 value and sets the flag as UTF16, if any of the character inside the String object is NOT Unicode latin1 character. - To change the method implementation of the String class and its builders to function on the new internal character storage, mainly to delegate to two implementation classes StringUTF16 and StringLatin1 - To update the StringCoding class to decoding/encoding the String between String.byte[]/coder(LATIN1/UTF16) <-> byte[](native encoding) instead of the original String.char[] <-> byte[] (native encoding) - To update the hotSpot compiler (new and updated instrinsics), GC (String Deduplication mods) and Runtime to work with the new internal "byte[] + coder flag" representation. See Tobias's note for details of the hotspot changes: http://cr.openjdk.java.net/~thartmann/compact_strings/hotspot-impl-note - To add a vm option "CompactStrings" (default is true) to provide a switch-off mechanism to always store the String characters in UTF16 encoding (always 2 bytes, but still in a byte[], instead of the original char[]). Supporting performance artifacts: - Report(s) on memory footprint impact http://cr.openjdk.java.net/~shade/density/string-density-report.pdf Latest SPECjbb2005 footprint reduction and throughput numbers for both Intel (Linux) and SPARC, in which it shows the Compact String binaries use less memory and have higher throughput. latest:http://cr.openjdk.java.net/~sherman/8054307/specjbb2005 old: http://cr.openjdk.java.net/~huntch/string-density/reports/String-Density-SPARC-jbb2005-Report.pdf - Throughput performance impact via String API micro-benchmarks http://cr.openjdk.java.net/~thartmann/compact_strings/microbenchmarks/Haswell_090915.pdf http://cr.openjdk.java.net/~thartmann/compact_strings/microbenchmarks/IvyBridge_090915.pdf http://cr.openjdk.java.net/~thartmann/compact_strings/microbenchmarks/Sparc_090915.pdf http://cr.openjdk.java.net/~sherman/8054307/string-coding.txt Thanks, Sherman From brian.burkhalter at oracle.com Fri Oct 2 21:08:12 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 2 Oct 2015 14:08:12 -0700 Subject: [9] RFR of 8032027: Add BigInteger square root methods In-Reply-To: <CAGB9EW8eK=oHejGAhh-4P8+zFgUbSkn+=wvcsRcQcPc3WA_trg@mail.gmail.com> References: <75C5170A-11B1-437A-A411-C125D54406E9@oracle.com> <CAGB9EW8eK=oHejGAhh-4P8+zFgUbSkn+=wvcsRcQcPc3WA_trg@mail.gmail.com> Message-ID: <0AF5F403-D2C2-4D67-A302-955774FE3379@oracle.com> I am aware of the classes at http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/math/BigIntegerMath.html but have not looked at anything beyond the javadoc specification primarily in the interest of licensing purity. Perhaps that is not a problem but I preferred to stay clear of it for now. The implementation I have here is effectively the one from Hacker?s Delight (2nd ed.). The initial guess is intended to be larger than the true result in order to simplify the termination condition of that algorithm as the monotonic convergence cannot have any oscillation between potential terminal values. There is certainly some room here for improvement in the range of input values less than Double.MAX_VALUE but this is a first stab at the implementation so hopefully such improvement may be brought in later if it is not in the first pass. Thanks, Brian On Oct 2, 2015, at 1:54 PM, Louis Wasserman <lowasser at google.com> wrote: > Have you investigated Guava's really quite tightly optimized implementation here? https://github.com/google/guava/blob/master/guava/src/com/google/common/math/BigIntegerMath.java#L242 > > A few years back I submitted a patch (now applied) to make BigInteger.doubleValue() very fast. If I recall correctly, that patch was originally inspired by my attempt to optimize sqrt on BigIntegers at the time. > > Converting the BigInteger to a double, using Math.sqrt(double), and using that as a starting point for Newton's method (converting that floating point value back to a BigInteger) buys you many bits of precision very fast. That result isn't guaranteed to be >= the true result, but one iteration of Newton's method will fix that. > > I'm quite certain you could improve on Guava's implementation even further with access to MutableBigInteger. From xueming.shen at oracle.com Fri Oct 2 21:13:38 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 02 Oct 2015 14:13:38 -0700 Subject: RFR: String Density/Compact String JEP 254 Message-ID: <560EF382.3000507@oracle.com> Hi, Please review the change for JEP 254/Compact String project. JPE 254: http://openjdk.java.net/jeps/254 Issue: https://bugs.openjdk.java.net/browse/JDK-8054307 Webrevs: http://cr.openjdk.java.net/~sherman/8054307/jdk/ http://cr.openjdk.java.net/~thartmann/compact_strings/webrev/hotspot Description: String Density project is to change the internal representation of the String class from a UTF-16 char array to a byte array plus an encoding flag field. The new String class stores characters encoded either as ISO-8859-1/Latin-1 (one byte per character), or as UTF-16 (two bytes per character), based upon the contents of the string. The encoding flag indicates which encoding is used. It offers reduced memory footprint while maintaining throughput performance. See JEP 254 for more additional information Implementation repo/try out: http://hg.openjdk.java.net/jdk9/sandbox/ branch: JDK-8054307-branch $ hg clone http://hg.openjdk.java.net/jdk9/sandbox/ $ cd sandbox $ sh ./get_source.sh $ sh ./common/bin/hgforest.sh up -r JDK-8054307-branch $ make configure $ make images Implementation Notes: - To change the internal representation of the String and the String builder classes (AbstractStringBuilder, StringBuilder and StringBuffer) from a UTF-16 char array to a byte array plus an encoding flag field. The new representation stores the String characters in a single byte format using the lower 8-bit of character's 16-bit UTF16 value, and sets the encoding flag as LATIN1, if all characters of the String object are Unicode Latin1 characters (with its UTF16 value < \u0100) It stores the String characters in 2-byte format with their UTF-16 value and sets the flag as UTF16, if any of the character inside the String object is NOT Unicode latin1 character. - To change the method implementation of the String class and its builders to function on the new internal character storage, mainly to delegate to two implementation classes StringUTF16 and StringLatin1 - To update the StringCoding class to decoding/encoding the String between String.byte[]/coder(LATIN1/UTF16) <-> byte[](native encoding) instead of the original String.char[] <-> byte[] (native encoding) - To update the hotSpot compiler (new and updated instrinsics), GC (String Deduplication mods) and Runtime to work with the new internal "byte[] + coder flag" representation. See Tobias's note for details of the hotspot changes: http://cr.openjdk.java.net/~thartmann/compact_strings/hotspot-impl-note - To add a vm option "CompactStrings" (default is true) to provide a switch-off mechanism to always store the String characters in UTF16 encoding (always 2 bytes, but still in a byte[], instead of the original char[]). Supporting performance artifacts: - Report(s) on memory footprint impact http://cr.openjdk.java.net/~shade/density/string-density-report.pdf Latest SPECjbb2005 footprint reduction and throughput numbers for both Intel (Linux) and SPARC, in which it shows the Compact String binaries use less memory and have higher throughput. latest:http://cr.openjdk.java.net/~sherman/8054307/specjbb2005 old: http://cr.openjdk.java.net/~huntch/string-density/reports/String-Density-SPARC-jbb2005-Report.pdf - Throughput performance impact via String API micro-benchmarks http://cr.openjdk.java.net/~thartmann/compact_strings/microbenchmarks/Haswell_090915.pdf http://cr.openjdk.java.net/~thartmann/compact_strings/microbenchmarks/IvyBridge_090915.pdf http://cr.openjdk.java.net/~thartmann/compact_strings/microbenchmarks/Sparc_090915.pdf http://cr.openjdk.java.net/~sherman/8054307/string-coding.txt Thanks, Sherman From wasserman.louis at gmail.com Fri Oct 2 21:16:32 2015 From: wasserman.louis at gmail.com (Louis Wasserman) Date: Fri, 02 Oct 2015 21:16:32 +0000 Subject: [9] RFR of 8032027: Add BigInteger square root methods In-Reply-To: <0AF5F403-D2C2-4D67-A302-955774FE3379@oracle.com> References: <75C5170A-11B1-437A-A411-C125D54406E9@oracle.com> <CAGB9EW8eK=oHejGAhh-4P8+zFgUbSkn+=wvcsRcQcPc3WA_trg@mail.gmail.com> <0AF5F403-D2C2-4D67-A302-955774FE3379@oracle.com> Message-ID: <CA+tXMXMTTjyKCppCR-58nuyffbe5Appfs=mbJ8hDK9AJn5UjAg@mail.gmail.com> I'm pretty sure we could potentially public-domain our implementation, if that were an issue. > The implementation I have here is effectively the one from Hacker?s Delight (2nd ed.). The initial guess is intended to be larger than the true result in order to simplify the termination condition of that algorithm as the monotonic convergence cannot have any oscillation between potential terminal values. This isn't a problem. The arithmetic mean of *any* two nonnegative numbers is always greater than their geometric mean, so for *any* nonnegative a, (a + x/a)/2 >= sqrt(a * x/a) = sqrt(x). So once you do *one* Newton iteration, the convergence is guaranteed to be monotonically decreasing after that point. Newton's method doubles the number of correct digits with every iteration. So you're paying one extra Newton iteration, but in exchange you're getting -handwave- 50 correct bits to start out with. That *more* than pays for itself. > There is certainly some room here for improvement in the range of input values less than Double.MAX_VALUE but this is a first stab at the implementation so hopefully such improvement may be brought in later if it is not in the first pass. It doesn't matter whether the input is bigger than Double.MAX_VALUE. You can just find some even number, s, such that x.shiftRight(s) < 2^52. Then use doubleToBigInteger(Math.sqrt(x.shiftRight(s))).shiftLeft(s / 2) as your starting estimate. You're still getting ~50 correct bits to start your Newton iteration. On Fri, Oct 2, 2015 at 2:08 PM Brian Burkhalter <brian.burkhalter at oracle.com> wrote: > I am aware of the classes at > > > http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/math/BigIntegerMath.html > > but have not looked at anything beyond the javadoc specification primarily > in the interest of licensing purity. Perhaps that is not a problem but I > preferred to stay clear of it for now. > > The implementation I have here is effectively the one from Hacker?s > Delight (2nd ed.). The initial guess is intended to be larger than the true > result in order to simplify the termination condition of that algorithm as > the monotonic convergence cannot have any oscillation between potential > terminal values. > > There is certainly some room here for improvement in the range of input > values less than Double.MAX_VALUE but this is a first stab at the > implementation so hopefully such improvement may be brought in later if it > is not in the first pass. > > Thanks, > > Brian > > On Oct 2, 2015, at 1:54 PM, Louis Wasserman <lowasser at google.com> wrote: > > > Have you investigated Guava's really quite tightly optimized > implementation here? > https://github.com/google/guava/blob/master/guava/src/com/google/common/math/BigIntegerMath.java#L242 > > > > A few years back I submitted a patch (now applied) to make > BigInteger.doubleValue() very fast. If I recall correctly, that patch was > originally inspired by my attempt to optimize sqrt on BigIntegers at the > time. > > > > Converting the BigInteger to a double, using Math.sqrt(double), and > using that as a starting point for Newton's method (converting that > floating point value back to a BigInteger) buys you many bits of precision > very fast. That result isn't guaranteed to be >= the true result, but one > iteration of Newton's method will fix that. > > > > I'm quite certain you could improve on Guava's implementation even > further with access to MutableBigInteger. > > From lowasser at google.com Fri Oct 2 21:18:22 2015 From: lowasser at google.com (Louis Wasserman) Date: Fri, 02 Oct 2015 21:18:22 +0000 Subject: [9] RFR of 8032027: Add BigInteger square root methods In-Reply-To: <CA+tXMXMTTjyKCppCR-58nuyffbe5Appfs=mbJ8hDK9AJn5UjAg@mail.gmail.com> References: <75C5170A-11B1-437A-A411-C125D54406E9@oracle.com> <CAGB9EW8eK=oHejGAhh-4P8+zFgUbSkn+=wvcsRcQcPc3WA_trg@mail.gmail.com> <0AF5F403-D2C2-4D67-A302-955774FE3379@oracle.com> <CA+tXMXMTTjyKCppCR-58nuyffbe5Appfs=mbJ8hDK9AJn5UjAg@mail.gmail.com> Message-ID: <CAGB9EW-BuaZNf_ONdwdCnorJwXapdt=6QNYxdjkqrZ4O-mSujA@mail.gmail.com> (https://en.wikipedia.org/wiki/Inequality_of_arithmetic_and_geometric_means proves that the arithmetic mean is >= the geometric mean.) On Fri, Oct 2, 2015 at 2:16 PM Louis Wasserman <wasserman.louis at gmail.com> wrote: > I'm pretty sure we could potentially public-domain our implementation, if > that were an issue. > > > The implementation I have here is effectively the one from Hacker?s > Delight (2nd ed.). The initial guess is intended to be larger than the true > result in order to simplify the termination condition of that algorithm as > the monotonic convergence cannot have any oscillation between potential > terminal values. > > This isn't a problem. The arithmetic mean of *any* two nonnegative > numbers is always greater than their geometric mean, so for *any* > nonnegative a, (a + x/a)/2 >= sqrt(a * x/a) = sqrt(x). So once you do > *one* Newton iteration, the convergence is guaranteed to be monotonically > decreasing after that point. > > Newton's method doubles the number of correct digits with every > iteration. So you're paying one extra Newton iteration, but in exchange > you're getting -handwave- 50 correct bits to start out with. That *more* > than pays for itself. > > > There is certainly some room here for improvement in the range of input > values less than Double.MAX_VALUE but this is a first stab at the > implementation so hopefully such improvement may be brought in later if it > is not in the first pass. > > It doesn't matter whether the input is bigger than Double.MAX_VALUE. You > can just find some even number, s, such that x.shiftRight(s) < 2^52. Then > use > > doubleToBigInteger(Math.sqrt(x.shiftRight(s))).shiftLeft(s / 2) > > as your starting estimate. You're still getting ~50 correct bits to start > your Newton iteration. > > On Fri, Oct 2, 2015 at 2:08 PM Brian Burkhalter < > brian.burkhalter at oracle.com> wrote: > >> I am aware of the classes at >> >> >> http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/math/BigIntegerMath.html >> >> but have not looked at anything beyond the javadoc specification >> primarily in the interest of licensing purity. Perhaps that is not a >> problem but I preferred to stay clear of it for now. >> >> The implementation I have here is effectively the one from Hacker?s >> Delight (2nd ed.). The initial guess is intended to be larger than the true >> result in order to simplify the termination condition of that algorithm as >> the monotonic convergence cannot have any oscillation between potential >> terminal values. >> >> There is certainly some room here for improvement in the range of input >> values less than Double.MAX_VALUE but this is a first stab at the >> implementation so hopefully such improvement may be brought in later if it >> is not in the first pass. >> >> Thanks, >> >> Brian >> >> On Oct 2, 2015, at 1:54 PM, Louis Wasserman <lowasser at google.com> wrote: >> >> > Have you investigated Guava's really quite tightly optimized >> implementation here? >> https://github.com/google/guava/blob/master/guava/src/com/google/common/math/BigIntegerMath.java#L242 >> > >> > A few years back I submitted a patch (now applied) to make >> BigInteger.doubleValue() very fast. If I recall correctly, that patch was >> originally inspired by my attempt to optimize sqrt on BigIntegers at the >> time. >> > >> > Converting the BigInteger to a double, using Math.sqrt(double), and >> using that as a starting point for Newton's method (converting that >> floating point value back to a BigInteger) buys you many bits of precision >> very fast. That result isn't guaranteed to be >= the true result, but one >> iteration of Newton's method will fix that. >> > >> > I'm quite certain you could improve on Guava's implementation even >> further with access to MutableBigInteger. >> >> From brian.burkhalter at oracle.com Fri Oct 2 21:29:13 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 2 Oct 2015 14:29:13 -0700 Subject: [9] RFR of 8032027: Add BigInteger square root methods In-Reply-To: <CA+tXMXMTTjyKCppCR-58nuyffbe5Appfs=mbJ8hDK9AJn5UjAg@mail.gmail.com> References: <75C5170A-11B1-437A-A411-C125D54406E9@oracle.com> <CAGB9EW8eK=oHejGAhh-4P8+zFgUbSkn+=wvcsRcQcPc3WA_trg@mail.gmail.com> <0AF5F403-D2C2-4D67-A302-955774FE3379@oracle.com> <CA+tXMXMTTjyKCppCR-58nuyffbe5Appfs=mbJ8hDK9AJn5UjAg@mail.gmail.com> Message-ID: <C6D56082-1272-42B6-ACBD-9A03B839E116@oracle.com> On Oct 2, 2015, at 2:16 PM, Louis Wasserman <wasserman.louis at gmail.com> wrote: > I'm pretty sure we could potentially public-domain our implementation, if that were an issue. Personally, if it?s much better than mine (or what mine could be revised to be) I?d be happy to have the better outcome. > > The implementation I have here is effectively the one from Hacker?s Delight (2nd ed.). The initial guess is intended to be larger than the true result in order to simplify the termination condition of that algorithm as the monotonic convergence cannot have any oscillation between potential terminal values. > > This isn't a problem. The arithmetic mean of *any* two nonnegative numbers is always greater than their geometric mean, so for *any* nonnegative a, (a + x/a)/2 >= sqrt(a * x/a) = sqrt(x). On Oct 2, 2015, at 2:18 PM, Louis Wasserman <lowasser at google.com> wrote: > (https://en.wikipedia.org/wiki/Inequality_of_arithmetic_and_geometric_means proves that the arithmetic mean is >= the geometric mean.) Got it. > So once you do *one* Newton iteration, the convergence is guaranteed to be monotonically decreasing after that point. > > Newton's method doubles the number of correct digits with every iteration. So you're paying one extra Newton iteration, but in exchange you're getting -handwave- 50 correct bits to start out with. That *more* than pays for itself. > > > There is certainly some room here for improvement in the range of input values less than Double.MAX_VALUE but this is a first stab at the implementation so hopefully such improvement may be brought in later if it is not in the first pass. > > It doesn't matter whether the input is bigger than Double.MAX_VALUE. You can just find some even number, s, such that x.shiftRight(s) < 2^52. Then use > > doubleToBigInteger(Math.sqrt(x.shiftRight(s))).shiftLeft(s / 2) > > as your starting estimate. You're still getting ~50 correct bits to start your Newton iteration. Excellent suggestion. I?ll look into revising it accordingly. Initially I had the thing broken into three ranges: 4 <= x <= Long.MAX_VALUE, Long.MAX_VALUE < x <= Double.MAX_VALUE, and Double.MAX_VALUE < x but found that this was lame and pointless. Thanks, Brian From yuka.kamiya at oracle.com Sat Oct 3 00:43:14 2015 From: yuka.kamiya at oracle.com (Yuka Kamiya) Date: Sat, 3 Oct 2015 09:43:14 +0900 Subject: RFR: 8138716: (tz) Support tzdata2015g In-Reply-To: <560EC34C.6060100@oracle.com> References: <560EC34C.6060100@oracle.com> Message-ID: <560F24A2.1060704@oracle.com> Hi Aleksej, Looks good to me. Thanks, -- Yuka On 2015/10/03 2:47, Aleksej Efimov wrote: > Hi, > > Please, help to review the latest tzdata integration [1] fix to JDK9: > http://cr.openjdk.java.net/~aefimov/tzdata/2015g/9/00/index.html > Testing shows no failures in time zones related tests. > > With Best Regards, > Aleksej > > [1] JBS: https://bugs.openjdk.java.net/browse/JDK-8138716 From joe.darcy at oracle.com Sat Oct 3 02:26:31 2015 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 2 Oct 2015 19:26:31 -0700 Subject: JDK 9 RFR of JDK-8138823: Correct bug in port of fdlibm hypot to Java Message-ID: <560F3CD7.20900@oracle.com> Hello, Please review the changes for JDK-8138823: Correct bug in port of fdlibm hypot to Java http://cr.openjdk.java.net/~darcy/8138823.0/ The change to java/lang/FdLibm.java is to correct a problem analogous to one recently corrected in the port of the pow method. The testing includes a few improvements, including the addition of FdlibmTranslit.java to host transliteration ports of the fdlibm methods. That is, Java ports of the code that are as close to the C versions as possible while still being readable. For the code used for java.lang.StrictMath, it is desirable for the code to be faster and to be closer to idiomatic Java. Thanks, -Joe From aph at redhat.com Sat Oct 3 09:38:38 2015 From: aph at redhat.com (Andrew Haley) Date: Sat, 3 Oct 2015 10:38:38 +0100 Subject: [9] RFR of 8032027: Add BigInteger square root methods In-Reply-To: <75C5170A-11B1-437A-A411-C125D54406E9@oracle.com> References: <75C5170A-11B1-437A-A411-C125D54406E9@oracle.com> Message-ID: <560FA21E.7050300@redhat.com> On 02/10/15 21:41, Brian Burkhalter wrote: > Any suggestions as to the improvement of the approach concerning > memory use or any other aspect of the algorithm would be > appreciated, as would be suggestions regarding the test. This algorithm doesn't look like the best to me because it's got this slow division in the middle. If we calculate 1/sqrt(x) instead we can use a version of Newton's iteration which requires no division. Starting with an approximation y = 1/sqrt(x) using the first few digits, y = y * (3 - x*y^2) --------------- 2 ... and fix it all up with a single iteration of Heron's algorithm at the end. But even better is Karatsuba Square Root: https://hal.inria.fr/inria-00072854/document I guess it all depends on how much work we think this deserves. In general the core algorithms in BigInteger are among the best, and it would be nice to continue this tradition. Andrew. From forax at univ-mlv.fr Sat Oct 3 14:16:25 2015 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 3 Oct 2015 16:16:25 +0200 (CEST) Subject: JEP 269: Convenience Factory Methods for Collections In-Reply-To: <CAGKkBkveaKTmGbhYJ4J8NNzkD5DwMz+ZvhHufC5Q2tQHU5D3Jg@mail.gmail.com> References: <20150924000217.D476B7A327@eggemoggin.niobe.net> <CAGKkBks7CKsJngvagV15C47E6zncdS-ag2m2OOKGoTtm-+YFFw@mail.gmail.com> <1548646383.2640105.1443208816341.JavaMail.zimbra@u-pem.fr> <CAGKkBkveaKTmGbhYJ4J8NNzkD5DwMz+ZvhHufC5Q2tQHU5D3Jg@mail.gmail.com> Message-ID: <1536405490.3047562.1443881785146.JavaMail.zimbra@u-pem.fr> Hi Kevin, i'm glad you ask, ----- Mail original ----- > De: "Kevin Bourrillion" <kevinb at google.com> > ?: "Remi Forax" <forax at univ-mlv.fr> > Cc: "Core Libs Dev" <core-libs-dev at openjdk.java.net> > Envoy?: Vendredi 2 Octobre 2015 18:22:00 > Objet: Re: JEP 269: Convenience Factory Methods for Collections > Tangent: > On Fri, Sep 25, 2015 at 12:20 PM, Remi Forax < forax at univ-mlv.fr > wrote: > > > Note that without permitting nulls, Map.of(key, Optional.of(value)) will > > > > become reasonably common, and that fact you can't serialize that will > > > > become even more strange than it already is. > > > Please don't do that, if you have a mapping between a key and something > > that > > doesn't exist, the best is to not have that mapping, > > > this is the semantics of java.util.concurrent (with null instead of > > Optional) > > and this is the only sane semantics. > > > Optional should never appear in collections/maps, it makes the code that > > deal > > with this kind of beast stupidly harder to read/write for no benefit. > > If you had no need to distinguish between not-present and mapped-to-absent, > then the idea of using a Map<K, Optional<V>> is so bizarre that I'm not sure > why we would even discuss it. > We have ~1800 occurrences of Optional-valued Maps or Caches in Google. They > do this for an actual reason: a negative result is meaningfully different > from no result. This is addressed in our Optional javadoc . mapped-to-absent means that you know the keys you are waiting for, so you can store them in an external set (list, etc) and enjoy implementations like EnumMap or the couple JSObject/HiddenClass you found in most javascript engines. Using Optional for that seem inefficient. R?mi From joe.darcy at oracle.com Sat Oct 3 18:45:30 2015 From: joe.darcy at oracle.com (joe darcy) Date: Sat, 3 Oct 2015 11:45:30 -0700 Subject: [9] RFR of 8032027: Add BigInteger square root methods In-Reply-To: <560FA21E.7050300@redhat.com> References: <75C5170A-11B1-437A-A411-C125D54406E9@oracle.com> <560FA21E.7050300@redhat.com> Message-ID: <5610224A.4090905@oracle.com> On 10/3/2015 2:38 AM, Andrew Haley wrote: > On 02/10/15 21:41, Brian Burkhalter wrote: > >> Any suggestions as to the improvement of the approach concerning >> memory use or any other aspect of the algorithm would be >> appreciated, as would be suggestions regarding the test. > This algorithm doesn't look like the best to me because it's got this > slow division in the middle. If we calculate 1/sqrt(x) instead we can > use a version of Newton's iteration which requires no division. > > Starting with an approximation y = 1/sqrt(x) using the first few digits, > > y = y * (3 - x*y^2) > --------------- > 2 > > ... and fix it all up with a single iteration of Heron's algorithm at the > end. > > But even better is Karatsuba Square Root: > https://hal.inria.fr/inria-00072854/document > > I guess it all depends on how much work we think this deserves. In > general the core algorithms in BigInteger are among the best, and it > would be nice to continue this tradition. For an initial implementation, I think it is acceptable to use a simple algorithm that is clearly correct. That algorithm can then be replaced with faster ones once adequate tests are built up (with the original implementation perhaps retiring to the regression tests area where it can be used for comparison purposes). -Joe From joe.darcy at oracle.com Sat Oct 3 18:58:16 2015 From: joe.darcy at oracle.com (joe darcy) Date: Sat, 3 Oct 2015 11:58:16 -0700 Subject: [9] RFR of 8032027: Add BigInteger square root methods In-Reply-To: <C6D56082-1272-42B6-ACBD-9A03B839E116@oracle.com> References: <75C5170A-11B1-437A-A411-C125D54406E9@oracle.com> <CAGB9EW8eK=oHejGAhh-4P8+zFgUbSkn+=wvcsRcQcPc3WA_trg@mail.gmail.com> <0AF5F403-D2C2-4D67-A302-955774FE3379@oracle.com> <CA+tXMXMTTjyKCppCR-58nuyffbe5Appfs=mbJ8hDK9AJn5UjAg@mail.gmail.com> <C6D56082-1272-42B6-ACBD-9A03B839E116@oracle.com> Message-ID: <56102548.3030101@oracle.com> Here is a trick to consider for future performance tuning: all large floating-point numbers are integers. Once the size of the positive exponent exceeds the number of bits of precision, the value must be an integer. For double, that means values greater than 2^54 are integers and the full double exponent range goes out to 2^1023. Consequently, if a BigInteger is less than 2^1023 and the spread of 1 bits in the BigInteger is contained within a double , the result could be directly calculated as BigInteger(Math.floor(Math.sqrt(bi.doubleValue()))) without needing any iterations on the BigInteger side. The bit spread could be able to be calculated from something like bi.bitLenth() - bi.getLowestSetBit() HTH, -Joe On 10/2/2015 2:29 PM, Brian Burkhalter wrote: > On Oct 2, 2015, at 2:16 PM, Louis Wasserman <wasserman.louis at gmail.com> wrote: > >> I'm pretty sure we could potentially public-domain our implementation, if that were an issue. > Personally, if it?s much better than mine (or what mine could be revised to be) I?d be happy to have the better outcome. > >>> The implementation I have here is effectively the one from Hacker?s Delight (2nd ed.). The initial guess is intended to be larger than the true result in order to simplify the termination condition of that algorithm as the monotonic convergence cannot have any oscillation between potential terminal values. >> This isn't a problem. The arithmetic mean of *any* two nonnegative numbers is always greater than their geometric mean, so for *any* nonnegative a, (a + x/a)/2 >= sqrt(a * x/a) = sqrt(x). > On Oct 2, 2015, at 2:18 PM, Louis Wasserman <lowasser at google.com> wrote: > >> (https://en.wikipedia.org/wiki/Inequality_of_arithmetic_and_geometric_means proves that the arithmetic mean is >= the geometric mean.) > Got it. > >> So once you do *one* Newton iteration, the convergence is guaranteed to be monotonically decreasing after that point. >> >> Newton's method doubles the number of correct digits with every iteration. So you're paying one extra Newton iteration, but in exchange you're getting -handwave- 50 correct bits to start out with. That *more* than pays for itself. >> >>> There is certainly some room here for improvement in the range of input values less than Double.MAX_VALUE but this is a first stab at the implementation so hopefully such improvement may be brought in later if it is not in the first pass. >> It doesn't matter whether the input is bigger than Double.MAX_VALUE. You can just find some even number, s, such that x.shiftRight(s) < 2^52. Then use >> >> doubleToBigInteger(Math.sqrt(x.shiftRight(s))).shiftLeft(s / 2) >> >> as your starting estimate. You're still getting ~50 correct bits to start your Newton iteration. > Excellent suggestion. I?ll look into revising it accordingly. > > Initially I had the thing broken into three ranges: 4 <= x <= Long.MAX_VALUE, Long.MAX_VALUE < x <= Double.MAX_VALUE, and Double.MAX_VALUE < x but found that this was lame and pointless. > > Thanks, > > Brian From peter.levart at gmail.com Sat Oct 3 20:32:06 2015 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 3 Oct 2015 22:32:06 +0200 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use > alternative to finalization (Roger Riggs) In-Reply-To: <560EE638.3020300@Oracle.com> References: <mailman.7407.1443712301.25018.core-libs-dev@openjdk.java.net> <2c3333ec8a1a5f9b132222de2e96386b@sonic.net> <560EE638.3020300@Oracle.com> Message-ID: <56103B46.5030602@gmail.com> On 10/02/2015 10:16 PM, Roger Riggs wrote: > Hi Mike, > > Thanks for the review and comments... > > On 10/2/2015 3:33 PM, Mike Duigou wrote: >> Hi Roger; >> >> This looks like an interesting proposal and would be a good >> replacement for alternative solutions. >> >> I am curious why the thread is run at max priority. Also, why not set >> priority and daemon status in the factory? > Yes, that should probably be left to the factory and for built-in > factory would be moved to the InnocuousThreadFactory. >> >> You should clear the Thread intrerruption if you are going to ignore >> it. Thread.interrupted(); > Will do. >> >> I would suggest surrounding the thunk.run() with a catch of Throwable >> or Exception. In the current implementation one bad egg spoils the >> party for everyone. There is a catch of RuntimeException described as >> "catch (RuntimeException e) { // ignore exceptions from the cleanup >> thunk }" but I would suggest that this is insufficiently paranoid. > Good point, catches more bad eggs. >> >> Consider a pattern like: >> >> private static final ReferenceQueue<Object> weakListeners = new >> ReferenceQueue<>(); >> >> >> private static class CleanerThread extends Thread { >> { setDaemon(true); setPriority(Thread.MIN_PRIORITY); } >> @Override >> @SuppressWarnings("unchecked") >> public void run() { >> // Using weak ref to queue allows shutdown if class is unloaded >> WeakReference<ReferenceQueue<Object>> weakQueue = new >> WeakReference<>(weakListeners); >> ReferenceQueue<Object> queue = null; >> while((queue = (queue == null ? weakQueue.get() : queue) != null) >> try { >> Object dead = queue.remove(10000); >> if(dead != null) { >> // do stuff with "dead" >> } else { >> queue = null; // recheck to see if queue is gone. >> } >> } catch(InterruptedException woken) { >> Thread.interrupted(); >> } >> } >> } >> >> When 'weakListeners' is cleared when the containing class is unloaded >> then the thread will shut down after roughly 10 seconds. >> >> I have been meaning to check whether CleanerThread needs to be in a >> separate class--an inner class, even a static one, may prevent it's >> containing class from being GCed. IDK. > I think that 'nested' classes aka static class has no links to the > outer class and can be GC'ed but will check. > > Thanks, Roger Hi Mike, Roger, Nested classes are typically loaded by the same ClassLoader as their outer classes. Normal named classes (as opposed to VM-annonymous classes) can't be GC-ed individually. Their defining ClassLoader keeps them referenced in it's ClassLoader#classes Vector. Each class has an implicit reference to it's defining ClassLoader, therefore each class indirectly references every class defined by the same ClassLoader as itself, and by delegation of ClassLoaders also every class defined by predecessor ClassLoaders. Only when all classes defined by a particular ClassLoader become unreachable and the ClassLoader too, do they become eligible for GC at the same time. In Roger's API, the class loader of those classes is bootstrap classloader which never goes away, so any objects referenced by static fields in bootstrap classes are never released. Above code has a flaw even if the weakListeners ReferenceQueue is passed to the CleanerThread via constructor parameter and immediately wrapped by WeakReference, like: private static class CleanerThread extends Thread { WeakReference<ReferenceQueue<Object>> weakQueue; CleanerThread(ReferenceQueue<Object> weakListeners) { setDaemon(true); setPriority(Thread.MIN_PRIORITY); weakQueue = new WeakReference<>(weakListeners); } public void run() { ReferenceQueue<Object> queue = null; while((queue = (queue == null ? weakQueue.get() : queue) != null) try { Object dead = queue.remove(10000); if(dead != null) { // do stuff with "dead" } else { queue = null; // recheck to see if queue is gone. } } catch(InterruptedException woken) { Thread.interrupted(); } } } There is a big chance that this loop will run forever even after 'weakListeners' is not referenced from other parts of code any more. The problem is the queue.remove(10000) call which spends 10 seconds waiting for a Reference to be enqueued, which never happens, but keeps the 'queue' alive all that time. There's only a brief window of time between 'queue = null' assignment and 'weakQueue.get()' which re-obtains a strong reference to the queue and happens periodically every 10 seconds.If GC never runs in this small window of opportunity, the weakQueue will never be cleared and the thread will run forever. Regards, Peter From gil at azulsystems.com Sun Oct 4 16:22:51 2015 From: gil at azulsystems.com (Gil Tene) Date: Sun, 4 Oct 2015 16:22:51 +0000 Subject: Spin Loop Hint support: Draft JEP proposal Message-ID: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> I would like to circulate this draft JEP proposal for initial review and consensus building purposes. I'm cross-posting to both core-libs-dev and hotspot-dev. From a spec perspective, the main change it suggests is the addition of a method (and probably a class to hold it) to the core libraries. And intrinsifying implementations would involve changes in HotSpot (see prototype WebRev links included below). Draft JEP follows inline... ? Gil. JEP XYZ: Spin Loop Hint (suggested content for some JEP fields): Authors Gil Tene Owner Gil Tene Type Feature Status Draft Component core-libs Scope JDK Discussion core dash libs dash dev at openjdk dot java dot net Effort S Duration S Summary Add an API that would allow Java code to hint that a spin loop is being executed. Goals Provide an API that would allow Java code to hint to the runtime that it is in a spin loop. The API would be a pure hint, and will carry no semantic behavior requirements (i.e. a no-op is a valid implementation). Allow the JVM to benefit from spin loop specific behaviors that may be useful on certain hardware platforms. Provide both a no-op implementation and an intrinsic implementation in the JDK, and demonstrate an execution benefit on at least one major hardware platform. Non-Goals It is NOT a goal to look at performance hints beyond spin loops. Other performance hints, such as prefetch hints, are outside the scope of this JEP. Motivation Some hardware platforms benefit from software indication that a spin loop is in progress. Some common execution benefits may be observed: A) The reaction time of a spin loop may be improved when a spin hint is used due to various factors, reducing thread-to-thread latencies in spinning wait situations. and B) The power consumed by the core or hardware thread involved in the spin loop may be reduced, benefitting overall power consumption of a program, and possibly allowing other cores or hardware threads to execute at faster speeds within the same power consumption envelope. While long term spinning is often discouraged as a general user-mode programming practice, short term spinning prior to blocking is a common practice (both inside and outside of the JDK). Furthermore, as core-rich computing platforms are commonly available, many performance and/or latency sensitive applications use a pattern that dedicates a spinning thread to a latency critical function [1], and may involve long term spinning as well. As a practical example and use case, current x86 processors support a PAUSE instruction that can be used to indicate spinning behavior. Using a PAUSE instruction demonstrably reduces thread-to-thread round trips. Due to it's benefits and commonly recommended use, the x86 PAUSE instruction is commonly used in kernel spinlocks, in POSIX libraries that perform heuristic spins prior to blocking, and even by the JVM itself. However, due to the inability to hint that a Java loop is spinning, it's benefits are not available to regular Java code. We include specific supporting evidence: In simple tests [2] performed on a E5-2697 v2, measuring the round trip latency behavior between two threads that communicate by spinning on a volatile field, round-trip latencies were demonstrably reduced by 18-20nsec across a wide percentile spectrum (from the 10%'ile to the 99.9%'ile). This reduction can represent an improvement as high as 35%-50% in best-case thread-to-thread communication latency. E.g. when two spinning threads execute on two hardware threads that share a physical CPU core and an L1 data cache. See example latency measurement results comparing the reaction latency of a spin loop that includes an intrinsified spinLoopHint() call [intrinsified as a PAUSE instruction] to the same loop executed without using a PAUSE instruction [3], along with the measurements of the it takes to perform an actual System.nantoTime() call to measure time. Description We propose to add a method to the JDK which would be hint that a spin loop is being performed. E.g. jdk.util.PerformanceHints.spinLoopHint(), which will hopefully evolve to a Java SE API, e.g. java.util.PerformanceHints.spinLoopHint(). The specific name space location, class name, and method name will be determined as part of development of this JEP. An empty method would be a valid implementation of the spinLoopHint() method, but intrisic implementation is the obvious goal for hardware platforms that can benefit from it. We intend to produce an intrinsic x86 implementation for OpenJDK as part of developing this JEP. A prototype implementation already exists [4] [5] [6] [7] and results from initial testing show promise. Alternatives JNI can be used to spin loop with a spin-loop-hinting CPU instruction, but the JNI-boundary crossing overhead tends to be larger than the benefit provided by the instruction, at least where latency is concerned. We could attempt to have the JIT compilers deduce spin-loop situations and code and choose to automatically include a spin-loop-hinting CPU instructions with no Java code hints required. We expect that the complexity of automatically and reliably detecting spinning situations, coupled with questions about potential tradeoffs in using the hints on some platform to delay the availability of viable implementations significantly. Testing Testing of a "vanilla" no-op implementation will obviously be fairly simple. We believe that given the vey small footprint of this API, testing of an intrinsified x86 implementation in OpenJDK will also be straightforward. We expect testing to focus on confirming both the code generation correctness and latency benefits of using the spin loop hint with an intrinsic implementation. Should this API be proposed as a Java SE API (e.g. for inclusion in the java.* namespace in a future Java SE 9 or Java SE 10), we expect to develop an associated TCK tests for the API for potential inclusion in the Java SE TCK. Risks and Assumptions The "vanilla" no-op implementation is obviously fairly low risk. An intrinsic x86 implementation will involve modifications to multiple JVM components and as such they carry some risks, but no more than other simple intrinsics added to the JDK. [1] The LMAX Disruptor https://lmax-exchange.github.io/disruptor/ <https://lmax-exchange.github.io/disruptor/> [2] https://github.com/giltene/GilExamples/tree/master/SpinHintTest <https://github.com/giltene/GilExamples/tree/master/SpinHintTest> [3] Chart depicting SpinLoopHint intrinsification impact https://github.com/giltene/GilExamples/blob/master/SpinHintTest/SpinLoopLatency_E5-2697v2_sharedCore.png <https://github.com/giltene/GilExamples/blob/master/SpinHintTest/SpinLoopLatency_E5-2697v2_sharedCore.png> [4] HotSpot WebRevs for prototype implementation which intrinsifies org.performancehintsSpinHint.spinLoopHint() http://ivankrylov.github.io/spinloophint/webrev/ <http://ivankrylov.github.io/spinloophint/webrev/> [5] JDK WebRevs for prototype intrinsifying implementation: http://ivankrylov.github.io/spinloophint/webrev.jdk/ <http://ivankrylov.github.io/spinloophint/webrev.jdk/> [6] Build environment WebRevs for prototype intrinsifying implementation: http://ivankrylov.github.io/spinloophint/webrev.main/ <http://ivankrylov.github.io/spinloophint/webrev.main/> [7] Link to a working Linux protoype OpenJDK9-based JDK (accepts optional -XX:+UseSpinLoopHintIntrinsic) https://www.dropbox.com/s/r2w1s1jykr2qs01/slh-openjdk-9-b70-bin-linux-x64.tar.gz?dl=0 <https://www.dropbox.com/s/r2w1s1jykr2qs01/slh-openjdk-9-b70-bin-linux-x64.tar.gz?dl=0> From aleksey.shipilev at oracle.com Mon Oct 5 08:56:39 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 5 Oct 2015 11:56:39 +0300 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> Message-ID: <56123B47.4070706@oracle.com> Hi Gil, Glad to see this being addressed! On 10/04/2015 07:22 PM, Gil Tene wrote: > We propose to add a method to the JDK which would be hint that a spin > loop is being performed. E.g. > jdk.util.PerformanceHints.spinLoopHint(), which will hopefully evolve > to a Java SE API, e.g. java.util.PerformanceHints.spinLoopHint(). The > specific name space location, class name, and method name will be > determined as part of development of this JEP. Yes, that would be a tough part. JDK is usually oblivious of these low-level platform-specific hints, they go to sun.misc.* (e.g. Unsafe, @Contended and others...). I'll let Project Leads to make that call :) > [4] HotSpot WebRevs for prototype implementation which intrinsifies > org.performancehintsSpinHint.spinLoopHint() > http://ivankrylov.github.io/spinloophint/webrev/ > <http://ivankrylov.github.io/spinloophint/webrev/> * product_pd (platform-dependent) flags can be used to conditionalize the support on a platform. This helps to avoid vm_version_* tricks. * Does spinloophint imply membar as well? x86_64.ad suggests so. library_call.cpp suggests so. It seems weird to conflate the two, even though it's understandable you want to piggyback on existing machinery. * I think spinLoopHint() misses a @HotspotIntrinsicCandidate annotation. Thanks, -Aleksey From Alan.Bateman at oracle.com Mon Oct 5 09:04:22 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 5 Oct 2015 10:04:22 +0100 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> Message-ID: <56123D16.4070800@oracle.com> On 04/10/2015 17:22, Gil Tene wrote: > I would like to circulate this draft JEP proposal for initial review and consensus building purposes. > > I'm cross-posting to both core-libs-dev and hotspot-dev. From a spec perspective, the main change it suggests is the addition of a method (and probably a class to hold it) to the core libraries. And intrinsifying implementations would involve changes in HotSpot (see prototype WebRev links included below). > > Draft JEP follows inline... > > ? Gil. > I don't see any mention in the JEP about existing mechanisms to give hints to the runtime, as in @Contended (JEP 142) and @HotSpotIntrinsicCandidate (JDK-8076112). Just wondering if there is an alternative to explore where something like @Spinloop int ignore; would emit the PAUSE. This would at least give a starting point for usages in the JDK. The bigger question is whether to expose such runtime hints in an API. It's very much for the advanced developer and if an API is really needed then it might be something for a JDK-specific API. -Alan From aph at redhat.com Mon Oct 5 09:41:52 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 5 Oct 2015 10:41:52 +0100 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> Message-ID: <561245E0.8030708@redhat.com> Hi Gil, On 04/10/15 17:22, Gil Tene wrote: > Summary > > Add an API that would allow Java code to hint that a spin loop is > being executed. I don't think this will work for ARM, which has a rather different spinlock mechanism. Instead of PAUSE, we wait on a lock word with WFE. WFE puts a core into a lightweight sleep state waiting on a particular address (the lock word) and a write to the lock word wakes it up. This is very useful and somewhat analogous to 86's MONITOR/MWAIT. I can't immediately see how to generalize your proposal to ARM, which is a shame. Andrew. From daniel.fuchs at oracle.com Mon Oct 5 10:54:16 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 5 Oct 2015 12:54:16 +0200 Subject: JEP 264: Platform Logging API and Service In-Reply-To: <20150918161737.CF3F171F93@eggemoggin.niobe.net> References: <20150918161737.CF3F171F93@eggemoggin.niobe.net> Message-ID: <561256D8.10907@oracle.com> > New JEP Candidate: http://openjdk.java.net/jeps/264 Hi I have uploaded an initial prototype specdiff: http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/specdiff-api/overview-summary.html LoggerFinder methods that take a Class<?> caller argument will take a java.lang.reflect.Module callerModule instead when that is available in jdk9/dev. comments welcome, best regards, -- daniel From alexander.v.stepanov at oracle.com Mon Oct 5 11:12:27 2015 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Mon, 5 Oct 2015 14:12:27 +0300 Subject: P.S.: RFR [9] 8133651: automated replacing of old-style tags in docs In-Reply-To: <560D199B.30708@oracle.com> References: <740a3bdd-3a72-44ec-b51f-83c98cac07ca@default> <560A6628.5010807@oracle.com> <CA+kOe0_RoiEvvquZ-5aJ401b1oePuDG+7vd0ufzgctpFhUfaLA@mail.gmail.com> <560C8970.50805@oracle.com> <CA+kOe0-YkE_886K0b_OY4G7kmunx9eTG0rxhaoVt8YKUsixFHA@mail.gmail.com> <560D199B.30708@oracle.com> Message-ID: <56125B1B.9070905@oracle.com> Hello, Could you please review the fix for https://bugs.openjdk.java.net/browse/JDK-8138838 Patch + webrev zipped + specdiff report: http://cr.openjdk.java.net/~avstepan/8138838 Just some cosmetic changes for docs (<code>...</code> -> {@code ...} replacement) + some misprints fixed. Not sure if these changes are desired at all for now. Thanks, Alexander (Just in case, adding the prehistory and sending a copy to core-libs-dev). On 10/1/2015 2:31 PM, Alexander Stepanov wrote: > Hello Martin, Stuart, > > Thank you for the notes, > > Yes, the initial utility is quite ugly, I just tried to prepare it as > quickly as possible hoping that it covers the majority of "trivial" > replace cases. Yes, it does not process multi-line <code> inclusions. > > > s = s.replace( "<CODE>", tag1); > > s = s.replace( "<Code>", tag1); > > s = s.replace("</CODE>", tag2); > > s = s.replace("</Code>", tag2); > > - replaced with "s = ln.replaceAll("(?i)<code>", > "<code>").replaceAll("(?i)</code>", "</code>");" > > Unfortunately my Perl/lisp knowledge are zero :) > > > Should you publish your specdiff? I guess not - it would be empty! > For now it contains a single fixed misprint diff, but there are a few > another misprints at the moment which I'd like to include in the patch > as well. > > So if you don't have objections, I'll delay for a several days and > then publish a final RFR (probably containing changes in some other > repos like jaxws, corba or jaxp) which would be more formal > (containing bug # and the final specdiff report). > > Thanks again, > Alexander > > > On 10/1/2015 9:54 AM, Martin Buchholz wrote: >> Hi s'marks, >> You probably don't need to absolutify paths. >> And you can easily handle multiple args. >> >> (just for fun!) >> Checks for javadoc comment; handles popular html entities; handles >> multiple lines; handles both tt and code: >> >> #!/bin/bash >> find "$@" -name '*.java' | \ >> xargs -r perl -p0777i -e \ >> 'do {} while s~^ >> *\*.*\K<(tt|code)>((?:[^<>{}\&\@]|&(?:lt|gt|amp);)*)</\1>~$_=$2; >> s/&lt;/</g; s/&gt;/>/g; s/&amp;/&/g; "{\@code $_}"~mgie' >> >> >> On Wed, Sep 30, 2015 at 6:16 PM, Stuart Marks >> <stuart.marks at oracle.com <mailto:stuart.marks at oracle.com>> wrote: >> >> Hi Alexander, Martin, >> >> The challenge of Perl file slurping and Emacs one-liners was too >> much to bear. >> >> This is Java, so one-liners are hardly possible. Still, there are >> a bunch of improvements that can be made to the Java version. (OK, >> and I'm showing off a bit.) >> >> Take a look at this: >> >> http://cr.openjdk.java.net/~smarks/misc/SimpleTagEditorSmarks1.java >> <http://cr.openjdk.java.net/%7Esmarks/misc/SimpleTagEditorSmarks1.java> >> >> I haven't studied the output exhaustively, but it seems to do a >> reasonably good job for the common cases. I ran it over java.lang >> and I noticed a few cases where there is markup embedded within >> <code></code> text, which should be looked at more closely. >> >> I don't particularly care if you use my version, but there are >> some techniques that I'd strongly recommend that you consider >> using in any such tool. In particular: >> >> - Pattern.DOTALL to do multi-line matches >> - Pattern.CASE_INSENSITIVE >> - try-with-resources to ensure that files are closed properly >> - NIO instead of old java.io <http://java.io> APIs, particularly >> Files.walk() and streams >> - use Scanner to deal with input file buffering >> - Scanner's stream support (I recently added this to JDK 9) >> >> Enjoy, >> >> s'marks >> >> >> >> On 9/29/15 2:23 PM, Martin Buchholz wrote: >> >> Hi Alexander, >> >> your change looks good. It's OK to have manual corrections >> for automated >> mega-changes like this, as long as they all revert changes. >> >> Random comments: >> >> Should you publish your specdiff? I guess not - it would be >> empty! >> >> while((s = br.readLine()) != null) { >> >> by matching only one line at a time, you lose the ability to >> make >> replacements that span lines. Perlers like to "slurp" in the >> entire file >> as a single string. >> >> s = s.replace( "<CODE>", tag1); >> s = s.replace( "<Code>", tag1); >> s = s.replace("</CODE>", tag2); >> s = s.replace("</Code>", tag2); >> >> Why not use case-insensitive regex? >> >> Here's an emacs-lisp one-liner I've been known to use: >> >> (defun tt-code () >> (interactive) >> (query-replace-regexp >> "<\\(tt\\|code\\)>\\([^&<>\\\\]+\\)</\\1>" "{@code >> \\2}")) >> >> With more work, one can automate transformation of embedded >> things like &lt; >> >> But of course, it's not even possible to transform ALL uses of >> <code> to >> {@code, if there was imaginative use of nested html tags. >> >> >> On Tue, Sep 29, 2015 at 3:21 AM, Alexander Stepanov < >> alexander.v.stepanov at oracle.com >> <mailto:alexander.v.stepanov at oracle.com>> wrote: >> >> Updated: a few manual corrections were made (as @linkplain >> tags displays >> nested {@code } literally): >> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch >> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/jdk.patch> >> -checked with specdiff (which of course does not cover >> documentation for >> internal packages), no unexpected diffs detected. >> >> Regards, >> Alexander >> >> >> On 9/27/2015 4:52 PM, Alexander Stepanov wrote: >> >> Hello Martin, >> >> Here is some simple app. to replace <code></code> tags >> with a new-style >> {@code } one (which is definitely not so elegant as >> the Perl one-liners): >> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/SimpleTagEditor.java >> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/SimpleTagEditor.java> >> >> Corresponding patch for jdk and replacement log (~62k >> of the tag changes): >> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch >> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/jdk.patch> >> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/replace.log >> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/replace.log> >> (sorry, I have to check the correctness of the patch >> with specdiff yet, >> so this is rather demo at the moment). >> >> Don't know if these changes (cosmetic by nature) are >> desired for now or >> not. Moreover, probably some part of them should go to >> another repos (e.g., >> awt, swing -> "client" instead of "dev"). >> >> Regards, >> Alexander >> > From alexander.v.stepanov at oracle.com Mon Oct 5 11:15:19 2015 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Mon, 5 Oct 2015 14:15:19 +0300 Subject: <AWT Dev> [9] RFR 8138838: docs cleanup for java.desktop In-Reply-To: <56125B1B.9070905@oracle.com> References: <740a3bdd-3a72-44ec-b51f-83c98cac07ca@default> <560A6628.5010807@oracle.com> <CA+kOe0_RoiEvvquZ-5aJ401b1oePuDG+7vd0ufzgctpFhUfaLA@mail.gmail.com> <560C8970.50805@oracle.com> <CA+kOe0-YkE_886K0b_OY4G7kmunx9eTG0rxhaoVt8YKUsixFHA@mail.gmail.com> <560D199B.30708@oracle.com> <56125B1B.9070905@oracle.com> Message-ID: <56125BC7.102@oracle.com> Sorry; wrong subject... On 10/5/2015 2:12 PM, Alexander Stepanov wrote: > Hello, > > Could you please review the fix for > https://bugs.openjdk.java.net/browse/JDK-8138838 > > Patch + webrev zipped + specdiff report: > http://cr.openjdk.java.net/~avstepan/8138838 > > Just some cosmetic changes for docs (<code>...</code> -> {@code ...} > replacement) + some misprints fixed. > > Not sure if these changes are desired at all for now. > > Thanks, > Alexander > > (Just in case, adding the prehistory and sending a copy to > core-libs-dev). > > > > On 10/1/2015 2:31 PM, Alexander Stepanov wrote: >> Hello Martin, Stuart, >> >> Thank you for the notes, >> >> Yes, the initial utility is quite ugly, I just tried to prepare it as >> quickly as possible hoping that it covers the majority of "trivial" >> replace cases. Yes, it does not process multi-line <code> inclusions. >> >> > s = s.replace( "<CODE>", tag1); >> > s = s.replace( "<Code>", tag1); >> > s = s.replace("</CODE>", tag2); >> > s = s.replace("</Code>", tag2); >> >> - replaced with "s = ln.replaceAll("(?i)<code>", >> "<code>").replaceAll("(?i)</code>", "</code>");" >> >> Unfortunately my Perl/lisp knowledge are zero :) >> >> > Should you publish your specdiff? I guess not - it would be empty! >> For now it contains a single fixed misprint diff, but there are a few >> another misprints at the moment which I'd like to include in the >> patch as well. >> >> So if you don't have objections, I'll delay for a several days and >> then publish a final RFR (probably containing changes in some other >> repos like jaxws, corba or jaxp) which would be more formal >> (containing bug # and the final specdiff report). >> >> Thanks again, >> Alexander >> >> >> On 10/1/2015 9:54 AM, Martin Buchholz wrote: >>> Hi s'marks, >>> You probably don't need to absolutify paths. >>> And you can easily handle multiple args. >>> >>> (just for fun!) >>> Checks for javadoc comment; handles popular html entities; handles >>> multiple lines; handles both tt and code: >>> >>> #!/bin/bash >>> find "$@" -name '*.java' | \ >>> xargs -r perl -p0777i -e \ >>> 'do {} while s~^ >>> *\*.*\K<(tt|code)>((?:[^<>{}\&\@]|&(?:lt|gt|amp);)*)</\1>~$_=$2; >>> s/&lt;/</g; s/&gt;/>/g; s/&amp;/&/g; "{\@code $_}"~mgie' >>> >>> >>> On Wed, Sep 30, 2015 at 6:16 PM, Stuart Marks >>> <stuart.marks at oracle.com <mailto:stuart.marks at oracle.com>> wrote: >>> >>> Hi Alexander, Martin, >>> >>> The challenge of Perl file slurping and Emacs one-liners was too >>> much to bear. >>> >>> This is Java, so one-liners are hardly possible. Still, there are >>> a bunch of improvements that can be made to the Java version. (OK, >>> and I'm showing off a bit.) >>> >>> Take a look at this: >>> >>> http://cr.openjdk.java.net/~smarks/misc/SimpleTagEditorSmarks1.java >>> <http://cr.openjdk.java.net/%7Esmarks/misc/SimpleTagEditorSmarks1.java> >>> >>> I haven't studied the output exhaustively, but it seems to do a >>> reasonably good job for the common cases. I ran it over java.lang >>> and I noticed a few cases where there is markup embedded within >>> <code></code> text, which should be looked at more closely. >>> >>> I don't particularly care if you use my version, but there are >>> some techniques that I'd strongly recommend that you consider >>> using in any such tool. In particular: >>> >>> - Pattern.DOTALL to do multi-line matches >>> - Pattern.CASE_INSENSITIVE >>> - try-with-resources to ensure that files are closed properly >>> - NIO instead of old java.io <http://java.io> APIs, particularly >>> Files.walk() and streams >>> - use Scanner to deal with input file buffering >>> - Scanner's stream support (I recently added this to JDK 9) >>> >>> Enjoy, >>> >>> s'marks >>> >>> >>> >>> On 9/29/15 2:23 PM, Martin Buchholz wrote: >>> >>> Hi Alexander, >>> >>> your change looks good. It's OK to have manual corrections >>> for automated >>> mega-changes like this, as long as they all revert changes. >>> >>> Random comments: >>> >>> Should you publish your specdiff? I guess not - it would be >>> empty! >>> >>> while((s = br.readLine()) != null) { >>> >>> by matching only one line at a time, you lose the ability to >>> make >>> replacements that span lines. Perlers like to "slurp" in the >>> entire file >>> as a single string. >>> >>> s = s.replace( "<CODE>", tag1); >>> s = s.replace( "<Code>", tag1); >>> s = s.replace("</CODE>", tag2); >>> s = s.replace("</Code>", tag2); >>> >>> Why not use case-insensitive regex? >>> >>> Here's an emacs-lisp one-liner I've been known to use: >>> >>> (defun tt-code () >>> (interactive) >>> (query-replace-regexp >>> "<\\(tt\\|code\\)>\\([^&<>\\\\]+\\)</\\1>" "{@code >>> \\2}")) >>> >>> With more work, one can automate transformation of embedded >>> things like &lt; >>> >>> But of course, it's not even possible to transform ALL uses of >>> <code> to >>> {@code, if there was imaginative use of nested html tags. >>> >>> >>> On Tue, Sep 29, 2015 at 3:21 AM, Alexander Stepanov < >>> alexander.v.stepanov at oracle.com >>> <mailto:alexander.v.stepanov at oracle.com>> wrote: >>> >>> Updated: a few manual corrections were made (as @linkplain >>> tags displays >>> nested {@code } literally): >>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch >>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/jdk.patch> >>> -checked with specdiff (which of course does not cover >>> documentation for >>> internal packages), no unexpected diffs detected. >>> >>> Regards, >>> Alexander >>> >>> >>> On 9/27/2015 4:52 PM, Alexander Stepanov wrote: >>> >>> Hello Martin, >>> >>> Here is some simple app. to replace <code></code> tags >>> with a new-style >>> {@code } one (which is definitely not so elegant as >>> the Perl one-liners): >>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/SimpleTagEditor.java >>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/SimpleTagEditor.java> >>> >>> >>> Corresponding patch for jdk and replacement log (~62k >>> of the tag changes): >>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch >>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/jdk.patch> >>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/replace.log >>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/replace.log> >>> (sorry, I have to check the correctness of the patch >>> with specdiff yet, >>> so this is rather demo at the moment). >>> >>> Don't know if these changes (cosmetic by nature) are >>> desired for now or >>> not. Moreover, probably some part of them should go to >>> another repos (e.g., >>> awt, swing -> "client" instead of "dev"). >>> >>> Regards, >>> Alexander >>> >> > From miroslav.kos at oracle.com Mon Oct 5 11:52:58 2015 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Mon, 5 Oct 2015 13:52:58 +0200 Subject: [9] Review request JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader In-Reply-To: <560EC09A.8080804@oracle.com> References: <55D5E163.6090905@oracle.com> <55F2F9F4.5090309@oracle.com> <56054D74.3070903@oracle.com> <56059161.2010808@oracle.com> <560A95E8.30907@oracle.com> <47E51B07-4FA1-4C13-9F8C-450B44C8FE20@oracle.com> <560BE098.7090809@oracle.com> <1ACCA360-ED4B-4A06-B0AD-52F14E604FCD@oracle.com> <560BFAED.4070802@oracle.com> <560D165F.4030808@oracle.com> <560D4CEA.4000808@oracle.com> <560E7B6D.8020508@oracle.com> <560E92DF.4000807@oracle.com> <560EA840.5000602@oracle.com> <560EC09A.8080804@oracle.com> Message-ID: <5612649A.4060900@oracle.com> On 02/10/15 19:36, Georgiy Rakov wrote: > On 02.10.2015 18:52, Miroslav Kos wrote: >> There is an updated version: >> http://cr.openjdk.java.net/~mkos/8131334/specdiff.07/index.html >> Two changes: >> 1) SAAJMetaFactory javadoc - new (self contained) paragraph >> describing the algorithm for the factory + apiNote >> 2) package javadoc: added back SAAJMetaFactory + "all these factories >> define newInstance method ..." changed to "first three ..." + >> sentence about instantiating SAAJMetaFactory >> >> >> On 02/10/15 16:21, Georgiy Rakov wrote: >>> According to the spec ofSAAJMetaFactory.newInstance method there is >>> the last step of lookup procedure: >>> * <LI>Default to >>> com.sun.xml.internal.messaging.saaj.soap.SAAJMetaFactoryImpl. >> I mentioned the default impl. I believe it's specific enough - in >> jdk8 version there is nothing regarding this ... >>> If this step is still performed, I believe this should be mentioned >>> like it's made in the last step of the lookup procedure described in >>> javax.xml.soap: "...or platform default implementation is used...". >>> BTW it would be good to mention what newMessageFactory and >>> newSOAPFactory of this default implementation return (I guess the >>> default implementations of corresponding factories). >> I don't think it's necessary. > From conformance testing perspective it's not clear what to expect > from MessageFactory.newInstance and SOAPFactory.newInstance when there > is no configuration at all (ServiceLoader is not configured, > jaxm.properties is missing, corresponding system property is not > set). For instance returning null doesn't contradict spec. Not > specifying it actually means that this is left up to implementation. > Any conformance tests written and expecting non-null result could be > successfully challenged by an external implementer returning null > since there is no spec about it. Sorry, it was misunderstanding here - I thought you wanted me to specify the actual type of platform default implementations - specifying null/not null makes definitely sense. I added not null statements to SAAJMetaFactory methods' javadoc: Returns: a|SOAPFactory| <http://cr.openjdk.java.net/%7Emkos/8131334/specdiff.08/javax/xml/soap/SOAPFactory.html>,notnull Hopefully it's enough? Thanks Miran > > Thus we merely cannot write conformance tests verifying MessageFactory > and SOAPFactory default implementations if this is the way how they > are to be obtained. I'm telling about the way of obtaining the default > implementation because there are actually another way that is to > configure ServiceLoader to return default implementation. But I don't > like this idea, since there are other questions arise, for instance if > we should normatively specify that ServiceLoader should be configured > to return default implementation. > > The rest looks great. > > Thanks, > Georgiy. From georgiy.rakov at oracle.com Mon Oct 5 13:20:13 2015 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Mon, 5 Oct 2015 16:20:13 +0300 Subject: [9] Review request JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader In-Reply-To: <5612649A.4060900@oracle.com> References: <55D5E163.6090905@oracle.com> <55F2F9F4.5090309@oracle.com> <56054D74.3070903@oracle.com> <56059161.2010808@oracle.com> <560A95E8.30907@oracle.com> <47E51B07-4FA1-4C13-9F8C-450B44C8FE20@oracle.com> <560BE098.7090809@oracle.com> <1ACCA360-ED4B-4A06-B0AD-52F14E604FCD@oracle.com> <560BFAED.4070802@oracle.com> <560D165F.4030808@oracle.com> <560D4CEA.4000808@oracle.com> <560E7B6D.8020508@oracle.com> <560E92DF.4000807@oracle.com> <560EA840.5000602@oracle.com> <560EC09A.8080804@oracle.com> <5612649A.4060900@oracle.com> Message-ID: <5612790D.9040603@oracle.com> On 05.10.2015 14:52, Miroslav Kos wrote: > > > On 02/10/15 19:36, Georgiy Rakov wrote: >> On 02.10.2015 18:52, Miroslav Kos wrote: >>> There is an updated version: >>> http://cr.openjdk.java.net/~mkos/8131334/specdiff.07/index.html >>> Two changes: >>> 1) SAAJMetaFactory javadoc - new (self contained) paragraph >>> describing the algorithm for the factory + apiNote >>> 2) package javadoc: added back SAAJMetaFactory + "all these >>> factories define newInstance method ..." changed to "first three >>> ..." + sentence about instantiating SAAJMetaFactory >>> >>> >>> On 02/10/15 16:21, Georgiy Rakov wrote: >>>> According to the spec ofSAAJMetaFactory.newInstance method there is >>>> the last step of lookup procedure: >>>> * <LI>Default to >>>> com.sun.xml.internal.messaging.saaj.soap.SAAJMetaFactoryImpl. >>> I mentioned the default impl. I believe it's specific enough - in >>> jdk8 version there is nothing regarding this ... >>>> If this step is still performed, I believe this should be mentioned >>>> like it's made in the last step of the lookup procedure described >>>> in javax.xml.soap: "...or platform default implementation is >>>> used...". BTW it would be good to mention what newMessageFactory >>>> and newSOAPFactory of this default implementation return (I guess >>>> the default implementations of corresponding factories). >>> I don't think it's necessary. >> From conformance testing perspective it's not clear what to expect >> from MessageFactory.newInstance and SOAPFactory.newInstance when >> there is no configuration at all (ServiceLoader is not configured, >> jaxm.properties is missing, corresponding system property is not >> set). For instance returning null doesn't contradict spec. Not >> specifying it actually means that this is left up to implementation. >> Any conformance tests written and expecting non-null result could be >> successfully challenged by an external implementer returning null >> since there is no spec about it. > Sorry, it was misunderstanding here - I thought you wanted me to > specify the actual type of platform default implementations - > specifying null/not null makes definitely sense. > > I added not null statements to SAAJMetaFactory methods' javadoc: > > Returns: > a|SOAPFactory| > <http://cr.openjdk.java.net/%7Emkos/8131334/specdiff.08/javax/xml/soap/SOAPFactory.html>,notnull > > Hopefully it's enough? > Yep, it looks enough for me. Thank you, Georgiy. > Thanks > Miran > > >> >> Thus we merely cannot write conformance tests verifying >> MessageFactory and SOAPFactory default implementations if this is the >> way how they are to be obtained. I'm telling about the way of >> obtaining the default implementation because there are actually >> another way that is to configure ServiceLoader to return default >> implementation. But I don't like this idea, since there are other >> questions arise, for instance if we should normatively specify that >> ServiceLoader should be configured to return default implementation. >> >> The rest looks great. >> >> Thanks, >> Georgiy. > From Roger.Riggs at Oracle.com Mon Oct 5 14:06:08 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 5 Oct 2015 10:06:08 -0400 Subject: JEP 264: Platform Logging API and Service In-Reply-To: <561256D8.10907@oracle.com> References: <20150918161737.CF3F171F93@eggemoggin.niobe.net> <561256D8.10907@oracle.com> Message-ID: <561283D0.3060603@Oracle.com> Hi Daniel, This looks good, a few comments... j.l.System: - the behaviors described by the @implNote in getLogger(name) and @implSpec in getLogger(name, resourceBundle) seem like they should be consistent for the two methods. System.Logger: - log(level, throwable, Supplier) - to be more consistent, the Suppler<String> argument should be before the Throwable argument. Then in all cases the msg/string is before the Throwable. System.Logger.Level - TRACE might be used for more than just method entry and exit, perhaps the description can be more general: "usually used for diagnostic information." LoggerFinder: - should the CONTROL_PERMISSION field be renamed to "LOGGERFINDER_PERMISSION"? - the LoggerFinder constructor says "Only one instance will be created". That applies to the normal static logger initialization (getLoggerFinder). But there might be other cases where the application or service might create a LoggerFinder for its own purposes, and the phrase is not accurate in that case. Editorial: - The @since tags can be set to "9". - "JVM" -> "Java runtime"; JVM would specifically refer to the virtual machine implementation. (j.u.System.LoggerFinder) - "used by the JDK" can be omitted. (j.u.System.LoggerFinder) When used in the context of the JDK documentation itself it seems out of place and is unnecessary. - the word 'actually' can/should be omitted from descriptions. (j.l.System) Thanks, Roger On 10/5/2015 6:54 AM, Daniel Fuchs wrote: >> New JEP Candidate: http://openjdk.java.net/jeps/264 > > Hi I have uploaded an initial prototype specdiff: > > http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/specdiff-api/overview-summary.html > > > LoggerFinder methods that take a Class<?> caller argument > will take a java.lang.reflect.Module callerModule instead when > that is available in jdk9/dev. > > comments welcome, > > best regards, > > -- daniel > From peter.levart at gmail.com Mon Oct 5 14:59:12 2015 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 5 Oct 2015 16:59:12 +0200 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <561245E0.8030708@redhat.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561245E0.8030708@redhat.com> Message-ID: <56129040.8060701@gmail.com> On 10/05/2015 11:41 AM, Andrew Haley wrote: > Hi Gil, > > On 04/10/15 17:22, Gil Tene wrote: > >> Summary >> >> Add an API that would allow Java code to hint that a spin loop is >> being executed. > > I don't think this will work for ARM, which has a rather different > spinlock mechanism. > > Instead of PAUSE, we wait on a lock word with WFE. WFE puts a core > into a lightweight sleep state waiting on a particular address (the > lock word) and a write to the lock word wakes it up. This is very > useful and somewhat analogous to 86's MONITOR/MWAIT. > > I can't immediately see how to generalize your proposal to ARM, which > is a shame. > > Andrew. > Just a thought... ARM WaitForEvent/SendEvent instructions sound like a kind of park/unpark, but on a CPU-core-level (WFE) and global system-level (SendEvent). I wonder whether it would be possible to use them to optimize the latency of the implementation of park/unpark. The same goes for Spin Loop Hint. Would it be possible to incorporate spin-looping in the park/unpark implementation for x86 itself? Higher-level synchronization constructs (like locks, synchronizers, etc..) would then just use park/unpark and not bother with spin-looping themselves. Regards, Peter From aph at redhat.com Mon Oct 5 15:19:38 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 5 Oct 2015 16:19:38 +0100 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <56129040.8060701@gmail.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561245E0.8030708@redhat.com> <56129040.8060701@gmail.com> Message-ID: <5612950A.5070203@redhat.com> On 10/05/2015 03:59 PM, Peter Levart wrote: > > On 10/05/2015 11:41 AM, Andrew Haley wrote: >> Hi Gil, >> >> On 04/10/15 17:22, Gil Tene wrote: >> >>> Summary >>> >>> Add an API that would allow Java code to hint that a spin loop is >>> being executed. >> >> I don't think this will work for ARM, which has a rather different >> spinlock mechanism. >> >> Instead of PAUSE, we wait on a lock word with WFE. WFE puts a core >> into a lightweight sleep state waiting on a particular address (the >> lock word) and a write to the lock word wakes it up. This is very >> useful and somewhat analogous to 86's MONITOR/MWAIT. >> >> I can't immediately see how to generalize your proposal to ARM, >> which is a shame. > > Just a thought... > > ARM WaitForEvent/SendEvent instructions sound like a kind of > park/unpark, but on a CPU-core-level (WFE) and global system-level > (SendEvent). Pretty much, although the wakeup is just a store. > I wonder whether it would be possible to use them to optimize the > latency of the implementation of park/unpark. The same goes for Spin > Loop Hint. Would it be possible to incorporate spin-looping in the > park/unpark implementation for x86 itself? Higher-level > synchronization constructs (like locks, synchronizers, etc..) would > then just use park/unpark and not bother with spin-looping > themselves. I spent a while thinking about that, and I'm not sure it's possible. WFE can wait for a very long time, and there is a general presumption that if a thread blocks it really should be descheduled rather than hog a core with a WFE. WFE is excellent if you have many cores (more cores than threads) and don't mind dedicating them to particular tasks: it's great for fork/join thread pools, etc, because it doesn't have the overhead of blocking and unblocking. Maybe the best thing would be a different version of park/unpark. Andrew. From chris.hegarty at oracle.com Mon Oct 5 15:35:05 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 5 Oct 2015 16:35:05 +0100 Subject: Array equality, comparison and mismatch In-Reply-To: <79451C0B-DA1A-4FD6-B8F3-97B7BE841006@oracle.com> References: <79451C0B-DA1A-4FD6-B8F3-97B7BE841006@oracle.com> Message-ID: <561298A9.2040900@oracle.com> Paul, On 22/09/15 17:30, Paul Sandoz wrote: > Hi, > > Please review the following which adds methods to Arrays for performing equality, comparison and mismatch: > > https://bugs.openjdk.java.net/browse/JDK-8033148 > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/webrev/ > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/specdiff/overview-summary.html This looks very good. I know that there has been some discussion already about the behavior when passed null, but it seems a little unfortunate that the range accepting 'equals' methods don't behave in a similar manner to that of the non-range 'equals' methods. But I do accept that it makes little sense, where would the from/to indices come from. So I think NPE makes sense for these. It was not immediately obvious to me that the common prefix can be 0. Should this be called out specifically? Minor typo(s): "...the length of the smaller array and it follows THAT the index is only valid ..." "If one array is a proper prefix of the other, over the specified ranges, then the returned relative index is the length of the smaller range and it follows THAT the relative index is only valid for the array with the larger range." > The motivation behind this is the use of Unsafe in popular libraries and frameworks to speed up the lexicographical comparison of byte arrays. > > This issue focuses on the API and functional implementations. A follow up issue [1] tracks updating the implementations to use a common method that leverages Unsafe to improve performance. A further issue [2] tracks the intrinsification of that common method to support operating on > 64 bits in width and further improve performance. A further issue, yet to be created, will follow up on updating existing JDK code to use the public and/or internal methods where appropriate. Example candidates include String (compareTo, perhaps add a mismatch method and possibly reviewing existing intrinsics, including those for compact Strings), and managed and direct Buffers. > > So far i have only documented the new methods operating on byte[], as that will act as the template for the other methods. > > Some points: > > - Methods operating on Object[] will compare Object elements using Object.equals or associated comparators (as is the case for the existing equals method operating on Object[]). > > - Methods operating on float[] or double[] will check such array elements for equality using the IEEE bit layout (as is the case for the existing equals method operating on float[] or double[]). > > - Primitive array element comparison will be performed as if by the boxed primitive type?s compare or compareUnsigned method. > > - Range-accepting methods do not support null array values. > > - Non-range and range-accepting mismatch methods do not support null array values. (What value should be returned when a mismatch is performed on a null array and an empty array)? > > - Speculation: it may be possible that Project Valhalla will enable us to ?compress? down methods of certain groups to one ?template? method. Even if that is not possible i am not overly concerned about the number of methods added, which represents the maximum set. We could reduce them without a fundamental loss of functionality, but that might have a ?semantic? loss requiring developers to roll their own wrappers. -Chris. > Thanks, > Paul. > > [1] https://bugs.openjdk.java.net/browse/JDK-8136924 > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8136924-arrays-mismatch-vectorized-unsafe/webrev/ > > [2] https://bugs.openjdk.java.net/browse/JDK-8044082 > From peter.levart at gmail.com Mon Oct 5 15:40:34 2015 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 5 Oct 2015 17:40:34 +0200 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <5612950A.5070203@redhat.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561245E0.8030708@redhat.com> <56129040.8060701@gmail.com> <5612950A.5070203@redhat.com> Message-ID: <561299F2.3080000@gmail.com> On 10/05/2015 05:19 PM, Andrew Haley wrote: > On 10/05/2015 03:59 PM, Peter Levart wrote: >> On 10/05/2015 11:41 AM, Andrew Haley wrote: >>> Hi Gil, >>> >>> On 04/10/15 17:22, Gil Tene wrote: >>> >>>> Summary >>>> >>>> Add an API that would allow Java code to hint that a spin loop is >>>> being executed. >>> I don't think this will work for ARM, which has a rather different >>> spinlock mechanism. >>> >>> Instead of PAUSE, we wait on a lock word with WFE. WFE puts a core >>> into a lightweight sleep state waiting on a particular address (the >>> lock word) and a write to the lock word wakes it up. This is very >>> useful and somewhat analogous to 86's MONITOR/MWAIT. >>> >>> I can't immediately see how to generalize your proposal to ARM, >>> which is a shame. >> Just a thought... >> >> ARM WaitForEvent/SendEvent instructions sound like a kind of >> park/unpark, but on a CPU-core-level (WFE) and global system-level >> (SendEvent). > Pretty much, although the wakeup is just a store. > >> I wonder whether it would be possible to use them to optimize the >> latency of the implementation of park/unpark. The same goes for Spin >> Loop Hint. Would it be possible to incorporate spin-looping in the >> park/unpark implementation for x86 itself? Higher-level >> synchronization constructs (like locks, synchronizers, etc..) would >> then just use park/unpark and not bother with spin-looping >> themselves. > I spent a while thinking about that, and I'm not sure it's possible. > WFE can wait for a very long time, and there is a general presumption > that if a thread blocks it really should be descheduled rather than > hog a core with a WFE. WFE is excellent if you have many cores (more > cores than threads) and don't mind dedicating them to particular > tasks: it's great for fork/join thread pools, etc, because it doesn't > have the overhead of blocking and unblocking. Maybe the best thing > would be a different version of park/unpark. > > Andrew. Yes, perhaps park/unpark is already to high-level as it requires Thread to be passed to unpark and therefore requires a thread to publish itself before doing park(), etc. Spin-looping is usually used without thread bookkeeping. I wonder how Gil's proposed PerformanceHints.spinLoopHint() is to be called. Just before entering the spin-loop or at each iteration of the loop? Is this some kind of CPU.yield() (by analogy to Thread.yield())? Regards, Peter From paul.sandoz at oracle.com Mon Oct 5 15:46:43 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 5 Oct 2015 17:46:43 +0200 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <561299F2.3080000@gmail.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561245E0.8030708@redhat.com> <56129040.8060701@gmail.com> <5612950A.5070203@redhat.com> <561299F2.3080000@gmail.com> Message-ID: <D7F71F45-8AE9-484A-8411-D9E53F4D57CA@oracle.com> > I wonder how Gil's proposed PerformanceHints.spinLoopHint() is to be called. Just before entering the spin-loop or at each iteration of the loop? The latter, e.g. see the benchmark code. > Is this some kind of CPU.yield() (by analogy to Thread.yield())? > I was wondering the same, it feels like a more vague (API abstraction-wise at least) architecture specific Thread.yield(). Paul. From ivan at azulsystems.com Mon Oct 5 17:10:41 2015 From: ivan at azulsystems.com (Ivan Krylov) Date: Mon, 5 Oct 2015 20:10:41 +0300 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <56123B47.4070706@oracle.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <56123B47.4070706@oracle.com> Message-ID: <5612AF11.2080502@azulsystems.com> On 05/10/2015 11:56, Aleksey Shipilev wrote: > * I think spinLoopHint() misses a @HotspotIntrinsicCandidate > annotation. Thanks, -Aleksey Correct. This prototype was build a little while ago and was based on OpenJDK 9 build 70. This annotation was added as part of https://bugs.openjdk.java.net/browse/JDK-8076112 in build 74. Thanks, Ivan From ivan at azulsystems.com Mon Oct 5 18:06:37 2015 From: ivan at azulsystems.com (Ivan Krylov) Date: Mon, 5 Oct 2015 21:06:37 +0300 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <D7F71F45-8AE9-484A-8411-D9E53F4D57CA@oracle.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561245E0.8030708@redhat.com> <56129040.8060701@gmail.com> <5612950A.5070203@redhat.com> <561299F2.3080000@gmail.com> <D7F71F45-8AE9-484A-8411-D9E53F4D57CA@oracle.com> Message-ID: <5612BC2D.9080200@azulsystems.com> >> Is this some kind of CPU.yield() (by analogy to Thread.yield())? >> > I was wondering the same, it feels like a more vague (API abstraction-wise at least) architecture specific Thread.yield(). > > Paul. Thread.sleep(0), Thread.yield() and now PerformanceHints.spinLoopHint() are all implementation specific. Furthermore, Intel [1] says " The execution of the next instruction is delayed for an implementation-specific amount of time." Can be a nop (and is a nop on old CPUs), can be something else. [1] - https://software.intel.com/en-us/node/524249 From brian.burkhalter at oracle.com Mon Oct 5 19:00:31 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 5 Oct 2015 12:00:31 -0700 Subject: [9] RFR of 8032027: Add BigInteger square root methods In-Reply-To: <560FA21E.7050300@redhat.com> References: <75C5170A-11B1-437A-A411-C125D54406E9@oracle.com> <560FA21E.7050300@redhat.com> Message-ID: <99CFE478-9AED-415B-897F-F07CA79FF67D@oracle.com> Andrew / Joe, Thank you for the much appreciated comments. On Oct 3, 2015, at 11:45 AM, joe darcy <joe.darcy at oracle.com> wrote: > For an initial implementation, I think it is acceptable to use a simple algorithm that is clearly correct. That algorithm can then be replaced with faster ones once adequate tests are built up (with the original implementation perhaps retiring to the regression tests area where it can be used for comparison purposes). This was in fact my intention for the initial implementation: something simple that is numerically accurate. On Oct 3, 2015, at 2:38 AM, Andrew Haley <aph at redhat.com> wrote: > On 02/10/15 21:41, Brian Burkhalter wrote: > >> Any suggestions as to the improvement of the approach concerning >> memory use or any other aspect of the algorithm would be >> appreciated, as would be suggestions regarding the test. > > This algorithm doesn't look like the best to me because it's got this > slow division in the middle. If we calculate 1/sqrt(x) instead we can > use a version of Newton's iteration which requires no division. > > Starting with an approximation y = 1/sqrt(x) using the first few digits, > > y = y * (3 - x*y^2) > --------------- > 2 > > ... and fix it all up with a single iteration of Heron's algorithm at the > end. I will investigate the foregoing and Louis suggestion for this pass of the implementation. Thanks for the most welcome ideas. > But even better is Karatsuba Square Root: > https://hal.inria.fr/inria-00072854/document > > I guess it all depends on how much work we think this deserves. In > general the core algorithms in BigInteger are among the best, and it > would be nice to continue this tradition. The Karatsuba Square Root approach by Zimmerman was in fact my original intention and you will find a link to the same work already in the issue on file. On Oct 3, 2015, at 11:58 AM, joe darcy <joe.darcy at oracle.com> wrote: > Here is a trick to consider for future performance tuning: all large floating-point numbers are integers. Once the size of the positive exponent exceeds the number of bits of precision, the value must be an integer. For double, that means values greater than 2^54 are integers and the full double exponent range goes out to 2^1023. > > Consequently, if a BigInteger is less than 2^1023 and the spread of 1 bits in the BigInteger is contained within a double , the result could be directly calculated as > > BigInteger(Math.floor(Math.sqrt(bi.doubleValue()))) > > without needing any iterations on the BigInteger side. The bit spread could be able to be calculated from something like > > bi.bitLenth() - bi.getLowestSetBit() Good observation: I?ll look into this as well. Thanks for all for the ideas. Brian From daniel.fuchs at oracle.com Mon Oct 5 19:59:46 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 5 Oct 2015 21:59:46 +0200 Subject: JEP 264: Platform Logging API and Service In-Reply-To: <561283D0.3060603@Oracle.com> References: <20150918161737.CF3F171F93@eggemoggin.niobe.net> <561256D8.10907@oracle.com> <561283D0.3060603@Oracle.com> Message-ID: <5612D6B2.7010601@oracle.com> Thanks Roger! I have updated the specdiff online. http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/specdiff-api/overview-summary.html The only comment I haven't taken into account yet is this: > - the LoggerFinder constructor says "Only one instance will be created". > That applies to the normal static logger initialization > (getLoggerFinder). > But there might be other cases where the application or service > might create a LoggerFinder > for its own purposes, and the phrase is not accurate in that case. I was wondering whether I should try enforcing this actually, by throwing a ServiceConfigurationError or whatever if the LoggerFinder service is already loaded when the constructor is invoked. We had trouble in the past with LogManager - because the spec said there should be only one instance, but the implementation did not enforce it. It may be a bit different with LoggerFinder - as this is an abstract class devoid of instance state (the only method with a body is getLocalizedLogger and that's stateless) - so there may not be as much harm as with LogManager. There is probably no good way of implementing such enforcement though - so it would be a best effort :-( best regards, -- daniel On 05/10/15 16:06, Roger Riggs wrote: > Hi Daniel, > > This looks good, a few comments... > > j.l.System: > - the behaviors described by the @implNote in getLogger(name) and > @implSpec in getLogger(name, resourceBundle) seem like they should > be consistent > for the two methods. > > System.Logger: > - log(level, throwable, Supplier) - to be more consistent, the > Suppler<String> argument > should be before the Throwable argument. > Then in all cases the msg/string is before the Throwable. > > System.Logger.Level > - TRACE might be used for more than just method entry and exit, > perhaps the description can be more > general: "usually used for diagnostic information." > > LoggerFinder: > > - should the CONTROL_PERMISSION field be renamed to > "LOGGERFINDER_PERMISSION"? > > - the LoggerFinder constructor says "Only one instance will be created". > That applies to the normal static logger initialization > (getLoggerFinder). > But there might be other cases where the application or service > might create a LoggerFinder > for its own purposes, and the phrase is not accurate in that case. > > > Editorial: > - The @since tags can be set to "9". > > - "JVM" -> "Java runtime"; JVM would specifically refer to the > virtual machine implementation. (j.u.System.LoggerFinder) > > - "used by the JDK" can be omitted. (j.u.System.LoggerFinder) > When used in the context of the JDK documentation itself it seems > out of place and is unnecessary. > > - the word 'actually' can/should be omitted from descriptions. > (j.l.System) > > Thanks, Roger > > > On 10/5/2015 6:54 AM, Daniel Fuchs wrote: >>> New JEP Candidate: http://openjdk.java.net/jeps/264 >> >> Hi I have uploaded an initial prototype specdiff: >> >> http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/specdiff-api/overview-summary.html >> >> >> LoggerFinder methods that take a Class<?> caller argument >> will take a java.lang.reflect.Module callerModule instead when >> that is available in jdk9/dev. >> >> comments welcome, >> >> best regards, >> >> -- daniel >> > From gil at azulsystems.com Mon Oct 5 20:43:18 2015 From: gil at azulsystems.com (Gil Tene) Date: Mon, 5 Oct 2015 20:43:18 +0000 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <561245E0.8030708@redhat.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561245E0.8030708@redhat.com> Message-ID: <ED44A1CE-F28C-4EDA-89F8-B97CF2E3F3AB@azulsystems.com> I see SpinLoopHint as very separate from things like MONITOR/WAIT (on x86) and WFE/SEV (on ARM), as well as any other "wait in a nice way until this state changes" instructions that other architectures may have or add. Mechanisms like MONITOR/WAIT and WFE/SEV provide a way to potentially wait for specific state changes to occur. As such, they can be used to implement a specific form of a spin loop (the most common one, probably). But they do not provide for generic spinning forms. E.g. loops that have multiple exit conditions in different memory locations, loops that wait on internal state changes that are no affected by other CPUs (like "spin only this many times before giving up" or "spin for this much time"), and loops that may use transactional state changes (e.g. LOCK XADD, or wider things with TSX) are probably "hard" to model with these instructions. In contrast, spinLoopHint() is intended to hint that the loop it is in is spinning, regardless of the logic used for the spinning or the spin termination. It is useful, for example, in heuristic spinning-before-blocking situations, where WFE/SEV MONITOR/WAIT would not be appropriate. MONITOR/MWAIT and WFE/SEV would be a good way to implement an actual spinning test or atomic operation (if it were available in user mode, but alas it isn't). And I could see some variant of AtomicX.CompareAndSet being proposed to use them, but the semantics and context are different. There are at least two architectures for which spinLoophint() is both a natural fit as well as the way everything else (kernels, libraries) seem to be spinning: In x86, the PAUSE instruction is a classic example of the spinLoopHint() use case. On some PowerPC implementations with multiple hardware threads (HMT), a lowering of the hardware thread priority is probably another example of a good use for spinLoopHint() [I haven't tried or tested this for spinLoopHint(), but that's what the linux kernel spinloops do for example: http://lxr.free-electrons.com/source/arch/powerpc/include/asm/spinlock.h?v=2.6.35#L116]. On some CPUs there might not (or not yet) be equivalent operation. A nop would be a valid way to implement it on current ARM. ? Gil. > On Oct 5, 2015, at 2:41 AM, Andrew Haley <aph at redhat.com> wrote: > > Hi Gil, > > On 04/10/15 17:22, Gil Tene wrote: > >> Summary >> >> Add an API that would allow Java code to hint that a spin loop is >> being executed. > > > I don't think this will work for ARM, which has a rather different > spinlock mechanism. > > Instead of PAUSE, we wait on a lock word with WFE. WFE puts a core > into a lightweight sleep state waiting on a particular address (the > lock word) and a write to the lock word wakes it up. This is very > useful and somewhat analogous to 86's MONITOR/MWAIT. > > I can't immediately see how to generalize your proposal to ARM, which > is a shame. > > Andrew. > From gil at azulsystems.com Mon Oct 5 21:01:47 2015 From: gil at azulsystems.com (Gil Tene) Date: Mon, 5 Oct 2015 21:01:47 +0000 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <56123D16.4070800@oracle.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <56123D16.4070800@oracle.com> Message-ID: <BDE56FD3-B7E8-44D2-8554-9FA9A967EC78@azulsystems.com> > On Oct 5, 2015, at 2:04 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote: > > On 04/10/2015 17:22, Gil Tene wrote: >> I would like to circulate this draft JEP proposal for initial review and consensus building purposes. >> >> I'm cross-posting to both core-libs-dev and hotspot-dev. From a spec perspective, the main change it suggests is the addition of a method (and probably a class to hold it) to the core libraries. And intrinsifying implementations would involve changes in HotSpot (see prototype WebRev links included below). >> >> Draft JEP follows inline... >> >> ? Gil. >> > I don't see any mention in the JEP about existing mechanisms to give hints to the runtime, as in @Contended (JEP 142) and @HotSpotIntrinsicCandidate (JDK-8076112). Just wondering if there is an alternative to explore where something like @Spinloop int ignore; would emit the PAUSE. This would at least give a starting point for usages in the JDK. The bigger question is whether to expose such runtime hints in an API. It's very much for the advanced developer and if an API is really needed then it might be something for a JDK-specific API. Alan, The JEP is not about performance hints in general, it's about (and only about) spin loop hints. While there are many "spelling" options possible, I don't think annotations will fit well. The needs of a spinLoopHint seem to be very different from those of the @Contended and @HotSpotIntrinsicCandidate in several way. Annotations have limited places in code where they can be applied. Specifically, they apply to declarations but not to execution. E.g. "@SpinLoop int ignore;" is a declaration: it does not emit any bytecodes. Without actually using the variable "ignore" later in the code, there would be no way to link it to code. The place where actual byte-codes are emitted would need to tie in to the declared variable, which would probably make the "spelling" more cumbersome than a trivial method call (with a hopefully self-explanatory name). ? Gil. From steve.drach at oracle.com Mon Oct 5 21:16:25 2015 From: steve.drach at oracle.com (Steve Drach) Date: Mon, 5 Oct 2015 14:16:25 -0700 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <560D88B5.2000701@oracle.com> References: <A12C71A8-59AB-4271-873F-4F3435EB2493@oracle.com> <560AD899.2020903@oracle.com> <991FA3D3-851A-4912-8C71-80FD13C74496@oracle.com> <560D6381.8070907@oracle.com> <346ED951-5BD4-4F55-9C1E-2DB17353C83E@oracle.com> <560D88B5.2000701@oracle.com> Message-ID: <DB260DB9-194A-45E8-BCD4-98648118DFC2@oracle.com> Hi Alan, > It would be good to add @since to Attributes#MULTI_RELEASE before this goes in. None of the other attributes have this. Are you suggesting I do this? /** * {@code Name} object for {@code Multi-Release} * manifest attribute that indicates this is a multi-release JAR file. * * @since 1.9 */ public static final Name MULTI_RELEASE = new Name("Multi-Release"); From Roger.Riggs at Oracle.com Mon Oct 5 22:11:14 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 5 Oct 2015 18:11:14 -0400 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <560EA3F2.7030108@Oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> Message-ID: <5612F582.4050909@Oracle.com> Hi, Building on Peter's code to provide subclassable CleanableReferences, I rearranged the implementation a bit to make it easier to maintain. The CleanableReferences subclasses are nested inside the Cleaner to make the scoping clear. Please review and comment: Webrev: http://cr.openjdk.java.net/~rriggs/webrev-cleaner-extensible-8138696/ javadoc: http://cr.openjdk.java.net/~rriggs/cleaner-doc2/ Thanks, Roger On 10/2/2015 11:34 AM, Roger Riggs wrote: > Hi Peter, > > Great comments, thanks for looking into this... > > On 10/2/2015 7:52 AM, Peter Levart wrote: >> Hi Roger, >> >> This is a nice and clean API. I like the trick with embedding a >> private CleanerImpl in Cleaner and registering Cleaner itself as a >> tracked object so that automatic thread termination can be performed >> in a safe manner. You say the scope of this is not to replace >> internal usages of sun.misc.Cleaner. But if they ever get replaced, >> there are two differences between the implementations to note: >> >> - sun.misc.Cleaner thunks get executed by a ReferenceHandler thread >> directly and bypass ReferenceQueue-ing. This might be OK for internal >> use, but not appropriate for public API. I doubt this >> sun.misc.Cleaner exception in ReferenceHandler is necessary though. >> - With sun.misc.Cleaner one has to create a minimum of 2 additional >> objects per tracked object: the Cleaner object and a Runnable thunk. >> This API requires creation of 3 objects per tracked object: the >> Cleanup object, the internal Reference object and a Runnable thunk. >> >> Do you think Cleaner will not be used in scenarios where this >> additional footprint matters? > I don't have any particular data on that point. When used with lambda > or method references for > the thunk, it is likely there will be some binding overhead. >> >> It might be possible to merge the roles of Cleanup and Reference into >> one object, like this: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/Cleaner/Cleaner.java >> >> Making Cleanup an interface, internal Reference(s) can implement it. >> One can cast a Cleanup instance to a Reference and invoke it's other >> methods, but this can be prevented by throwing >> UnsupportedOperationException from them, so nobody is tempted to >> employ this implementation detail. > > I prototyped a similar implementation but backed it out due to the > code duplication and complexity. > It also seemed a poor choice to break the contract of Reference by > throwing UnsupportedOperationException > on the unneeded but exposed methods since they could not be completely > encapsulated. > It seemed cleaner to have only a concrete type that was exposed to the > clients. > > BTW, the code in you cleaner might be simpler if the cleaner lists for > each of the three types were separate. > (The entries don't need to be intermixed). That could simplify the > virtual next/prev access but would still be > duplicating the linked list management code). > There could be multiple insertXXX methods so the casts were not > necessary. > >> >> There might be utility in exposing Cleanup (or better named >> Cleanable) References as public abstract classes so that a footprint >> sensitive application (for example in a data structure with many >> elements) is possible. By subclassing such an abstract reference and >> implementing the abstract method, a single object is required per >> tracked object. Here I derived a proof of concept from your code: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/Cleaner/webrev.01/ >> >> The simple API is unchanged and there is additional low-level API >> that can be used if footprint matters. >> >> What do you think? > > I see what you're getting at. I would probably try to rearrange it so > that only the performMethod > could be overridden. Overriding clean() and clear() might disable > the list management > and reduce the robustness. > > I'll take another look, I was most concerned with simplicity, but if > the overhead for the number > of the objects is a concern that can be traded off against a more > complex implementation. > > Thanks, Roger > >> >> Regards, Peter >> >> >> On 10/01/2015 04:12 PM, Roger Riggs wrote: >>> Please review a proposal for public Cleaner API: >>> >>> A Cleaner is proposed to provide an easy to use alternative to >>> finalization. The service would provide easy registration and >>> cancellation of cleanup functions for objects. Applications create a >>> cleanup service for their own use and the service terminates when it >>> is no longer in use. >>> >>> Finalization has a long history of issues both in usage and >>> performance. PhantomReferences have been proposed as the alternative >>> GC based mechanism for cleaning functions but it has been left as an >>> exercise to the developer to construct the necessary mechanisms to >>> handle ReferenceQueues, handle threading issues and robust termination. >>> >>> The Cleaner performs cleaning functions when objects are unreachable >>> as found by garbage collection using the existing mechanisms of >>> PhantomReference, WeakReference, SoftReferences, and >>> ReferenceQueues. It manages a thread that dequeues references to >>> unreachable objects and invokes the corresponding cleaning function. >>> Registered cleaning functions can be cleared if no longer needed, >>> can be invoked explicitly to perform the cleanup immediately, or be >>> invoked when the object is not reachable (as detected by garbage >>> collection) and handled by a cleanup thread. >>> >>> The java.lang.ref package is proposed for the Cleaner because it is >>> complementary to the reference classes and reference queues and to >>> make it easy to find. >>> >>> It is not a goal to replace all uses of finalization or >>> sun.misc.Cleaner in the JDK. >>> Investigation will evaluate if and in what cases the Cleaner can >>> replace finalization. >>> A subsequent task will examine uses of finalization and propose >>> specific changes >>> on a case by base basis. >>> >>> Please review and comment: >>> >>> Javadoc: >>> http://cr.openjdk.java.net/~rriggs/cleaner-doc/ >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8138696 >>> >>> Thanks, Roger >>> >> > From gil at azulsystems.com Tue Oct 6 04:32:43 2015 From: gil at azulsystems.com (Gil Tene) Date: Tue, 6 Oct 2015 04:32:43 +0000 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <56123B47.4070706@oracle.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <56123B47.4070706@oracle.com> Message-ID: <9FD5F6D1-2875-469C-B4C1-5F7ED0740084@azulsystems.com> > On Oct 5, 2015, at 1:56 AM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote: > > Hi Gil, > > Glad to see this being addressed! > > On 10/04/2015 07:22 PM, Gil Tene wrote: >> We propose to add a method to the JDK which would be hint that a spin >> loop is being performed. E.g. >> jdk.util.PerformanceHints.spinLoopHint(), which will hopefully evolve >> to a Java SE API, e.g. java.util.PerformanceHints.spinLoopHint(). The >> specific name space location, class name, and method name will be >> determined as part of development of this JEP. > > Yes, that would be a tough part. JDK is usually oblivious of these > low-level platform-specific hints, they go to sun.misc.* (e.g. Unsafe, > @Contended and others...). I'll let Project Leads to make that call :) I don't think of this as platform specific. And it's not much lower level than e.g. some java.util.concurrent stuff (but probably doesn't belong in that package because it's not really about concurrency). I'm looking for a proper Java SE spec'ed way to do this. So sun.misc.* won't work. I'm sure we don't want another Unsafe for people to abuse... But naming the class and method is the smaller, easier detail. Right? ;-) > >> [4] HotSpot WebRevs for prototype implementation which intrinsifies >> org.performancehintsSpinHint.spinLoopHint() >> http://ivankrylov.github.io/spinloophint/webrev/ >> <http://ivankrylov.github.io/spinloophint/webrev/> > > * product_pd (platform-dependent) flags can be used to conditionalize > the support on a platform. This helps to avoid vm_version_* tricks. Thx. > * Does spinloophint imply membar as well? x86_64.ad suggests so. > library_call.cpp suggests so. It seems weird to conflate the two, even > though it's understandable you want to piggyback on existing machinery. Semantically. spinLoopHint() has zero semantic requirements, and therefore no implied behavior of any kind (no membar). We implemented the pause intrinsic as a variant representation of a membar because that was one relatively simple way of having it stay within the loop (or with whatever control flow it is under). The "membar" variant implementation doesn't prohibit reordering of loads or stores. > > * I think spinLoopHint() misses a @HotspotIntrinsicCandidate annotation. Will add that in future prototypes. > Thanks, > -Aleksey > From Alan.Bateman at oracle.com Tue Oct 6 07:08:42 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 6 Oct 2015 08:08:42 +0100 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <DB260DB9-194A-45E8-BCD4-98648118DFC2@oracle.com> References: <A12C71A8-59AB-4271-873F-4F3435EB2493@oracle.com> <560AD899.2020903@oracle.com> <991FA3D3-851A-4912-8C71-80FD13C74496@oracle.com> <560D6381.8070907@oracle.com> <346ED951-5BD4-4F55-9C1E-2DB17353C83E@oracle.com> <560D88B5.2000701@oracle.com> <DB260DB9-194A-45E8-BCD4-98648118DFC2@oracle.com> Message-ID: <5613737A.5090208@oracle.com> On 05/10/2015 22:16, Steve Drach wrote: > > None of the other attributes have this. Are you suggesting I do this? Yes, and I assume this will rename to @since 9 once the versioning JEP goes in. -Alan From aph at redhat.com Tue Oct 6 08:16:50 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 6 Oct 2015 09:16:50 +0100 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <9FD5F6D1-2875-469C-B4C1-5F7ED0740084@azulsystems.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <56123B47.4070706@oracle.com> <9FD5F6D1-2875-469C-B4C1-5F7ED0740084@azulsystems.com> Message-ID: <56138372.7050107@redhat.com> On 06/10/15 05:32, Gil Tene wrote: > I don't think of this as platform specific. And it's not much lower > level than e.g. some java.util.concurrent stuff (but probably > doesn't belong in that package because it's not really about > concurrency). I'm looking for a proper Java SE spec'ed way to do > this. So sun.misc.* won't work. I'm sure we don't want another > Unsafe for people to abuse... > > But naming the class and method is the smaller, easier detail. Right? ;-) Sure. I would have thought, though, that java.util.concurrent was a natural home for this. Is there any kind of userland spinlock which is not about concurrency? Andrew. From paul.sandoz at oracle.com Tue Oct 6 08:27:38 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 6 Oct 2015 10:27:38 +0200 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> Message-ID: <EE55C13E-0F91-4168-B092-73A67EC4FEA2@oracle.com> Hi Gil, Have you investigated the use of this spin loop hint in j.u.concurrent classes and other potential areas in the JDK? I think it would be useful to include some investigation to validate it?s use and then follow up with updates, perhaps separate to this JEP. > On 6 Oct 2015, at 06:32, Gil Tene <gil at azulsystems.com> wrote: > > But naming the class and method is the smaller, easier detail. Right? ;-) :-) indeed. IMHO j.u.c.LockSupport seems a reasonable location, backed by some JDK internal method which is intrinsic. One way forward is to start with the latter and if investigations with j.u.c. are fruitful expose via something like the former. Paul. > On 4 Oct 2015, at 18:22, Gil Tene <gil at azulsystems.com> wrote: > > I would like to circulate this draft JEP proposal for initial review and consensus building purposes. > > I'm cross-posting to both core-libs-dev and hotspot-dev. From a spec perspective, the main change it suggests is the addition of a method (and probably a class to hold it) to the core libraries. And intrinsifying implementations would involve changes in HotSpot (see prototype WebRev links included below). > > Draft JEP follows inline... From paul.sandoz at oracle.com Tue Oct 6 08:50:57 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 6 Oct 2015 10:50:57 +0200 Subject: Array equality, comparison and mismatch In-Reply-To: <561298A9.2040900@oracle.com> References: <79451C0B-DA1A-4FD6-B8F3-97B7BE841006@oracle.com> <561298A9.2040900@oracle.com> Message-ID: <362CCE17-4D8E-411A-82B5-EF83EDE2FE90@oracle.com> > On 5 Oct 2015, at 17:35, Chris Hegarty <chris.hegarty at oracle.com> wrote: > > Paul, > > On 22/09/15 17:30, Paul Sandoz wrote: >> Hi, >> >> Please review the following which adds methods to Arrays for performing equality, comparison and mismatch: >> >> https://bugs.openjdk.java.net/browse/JDK-8033148 >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/webrev/ >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/specdiff/overview-summary.html > > This looks very good. > > I know that there has been some discussion already about the behavior when passed null, but it seems a little unfortunate that the range accepting 'equals' methods don't behave in a similar manner to that of the non-range 'equals' methods. But I do accept that it makes little sense, where would the from/to indices come from. So I think NPE makes sense for these. > Note that this consistent with other range accepting methods, such as on Arrays or Spliterators (which also usually throw null on the non-range methods too, i wish we could be consistent in that aspect). > It was not immediately obvious to me that the common prefix can be 0. Should this be called out specifically? > When reading the documentation of compare or mismatch or both? > Minor typo(s): > > "...the length of the smaller array and it follows THAT the > index is only valid ..." > > "If one array is a proper prefix of the other, over the specified > ranges, then the returned relative index is the length of the > smaller range and it follows THAT the relative index is only valid > for the array with the larger range.? > Fixed. Thanks, Paul. From chris.hegarty at oracle.com Tue Oct 6 08:58:06 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 6 Oct 2015 09:58:06 +0100 Subject: Array equality, comparison and mismatch In-Reply-To: <362CCE17-4D8E-411A-82B5-EF83EDE2FE90@oracle.com> References: <79451C0B-DA1A-4FD6-B8F3-97B7BE841006@oracle.com> <561298A9.2040900@oracle.com> <362CCE17-4D8E-411A-82B5-EF83EDE2FE90@oracle.com> Message-ID: <663AA12B-6948-42B4-90E4-0E207D11D4D9@oracle.com> On 6 Oct 2015, at 09:50, Paul Sandoz <paul.sandoz at oracle.com> wrote: >> >> On 5 Oct 2015, at 17:35, Chris Hegarty <chris.hegarty at oracle.com> wrote: >> >> Paul, >> >> On 22/09/15 17:30, Paul Sandoz wrote: >>> Hi, >>> >>> Please review the following which adds methods to Arrays for performing equality, comparison and mismatch: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8033148 >>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/webrev/ >>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/specdiff/overview-summary.html >> >> This looks very good. >> >> I know that there has been some discussion already about the behavior when passed null, but it seems a little unfortunate that the range accepting 'equals' methods don't behave in a similar manner to that of the non-range 'equals' methods. But I do accept that it makes little sense, where would the from/to indices come from. So I think NPE makes sense for these. >> > > Note that this consistent with other range accepting methods, such as on Arrays or Spliterators (which also usually throw null on the non-range methods too, i wish we could be consistent in that aspect). Right. >> It was not immediately obvious to me that the common prefix can be 0. Should this be called out specifically? >> > > When reading the documentation of compare or mismatch or both? mismatch. But maybe this is just me. -Chris. From scolebourne at joda.org Tue Oct 6 10:24:24 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 6 Oct 2015 11:24:24 +0100 Subject: Test for JDK-5108778 Too many instances of java.lang.Boolean created in Java application In-Reply-To: <560F3B56.3060309@oracle.com> References: <560C3B56.4060309@gmx.de> <560F3B56.3060309@oracle.com> Message-ID: <CACzrW9Cgcd11S1j0Ft5VaAKUKsissO3Hm+3c-1JXLf_sFXhnCg@mail.gmail.com> Moving to core-libs: On 3 October 2015 at 03:20, Stuart Marks <stuart.marks at oracle.com> wrote: > An interesting exercise would be to add the @Deprecated annotation to the > Boolean constructor and build the JDK and see how many warnings result. That > might be a quick way to find the code that needs to be fixed. I'd really like to see this. Specifically, adding @Deprecated to _all_ constructors on Boolean, Short, Integer, Long, Character, Float, Double. This may require some additional factory methods to be added. Doing this for Java 9 would be good preparation for value types. While the Valhalla team are not currently talking about converting these classes to values, they are clearly very value-like. Pushing users to treat them more as values seems like a Good Thing. It might even tip the balance towards making them actual value types. Stephen On 3 October 2015 at 03:20, Stuart Marks <stuart.marks at oracle.com> wrote: > Hi Sebastian, > > Good to see you contributing to OpenJDK again! > > I'm not sure it's sensible to have a regression test for this sort of thing. > This seems more like static code analysis to me. In fact, Findbugs already > seems to have a pattern that detects calls to the Boolean constructor: > > http://findbugs.sourceforge.net/bugDescriptions.html#DM_BOOLEAN_CTOR > > (I believe that people are running Findbugs over the JDK regularly, but we > don't really have a workflow for processing diagnostics that it generates.) > > Now, regression tests are there to prevent bugs from reappearing once > they're fixed. So how would we do this? For cases like this, there's another > approach, which is deprecation: > > https://bugs.openjdk.java.net/browse/JDK-4941777 > > If the Boolean constructor is deprecated, then a warning will be issued > wherever they're called. By default, the JDK build treats warnings as > errors, so this will effectively prohibit any uses of Boolean constructors. > (The two legitimate uses of the Boolean constructor can be annotated with > @SuppressWarnings to prevent this.) > > An interesting exercise would be to add the @Deprecated annotation to the > Boolean constructor and build the JDK and see how many warnings result. That > might be a quick way to find the code that needs to be fixed. > > As for your other questions: > > 2. Boolean is a special case since there are exactly two boxed boolean > values. Possibly Byte as well, since all Byte values are cached. (See spec > for Byte.valueOf(byte).) There is a moderate preference for valueOf() over > the constructors of Character, Integer, and Short, since those cache a > subset of values. It's not clear to me these are worth worrying about > though. (Long, Float, and Double don't have caches.) > > 3. I would say that it's more likely that future JDK enhancements would be > able to optimize auto-boxing than explicit method calls that deal with boxed > values. > > 4. Unfortunately, different portions of code are handled by different > groups, and are thus reviewed on different mailing lists. I think asking on > jdk9-dev, as you've been doing, about where things need to be reviewed, is > the right thing to do. > > I'll reply on macosx-port-dev on your specific changes there. > > s'marks > > > > On 9/30/15 12:43 PM, Sebastian Sickelmann wrote: >> >> Hi, >> >> a few days ago i started to investigate JDK-5108778[1] and started >> discussions >> for a small parts of it in macosx-port-dev[2] and hotspot-dev[3]. As >> suggested by >> Alexandr there should be a test that saves for regression for such >> changes. I would >> like to introduce a test like[4], what do you think? >> >> It scans for all jimage-files in <java.home>/lib/modules and opens every >> classfile >> and scans every-method for a NEW-bytecode to a Wrapper-Type Classname. >> Every match that is not in the Wrapper-Type itself is reported and >> counted. >> >> >> I have some questions about this: >> 1. Is there a good way to get rid of the "9.0" part for reading the >> classes out of the jimage? >> 2. What is with other Wrapper-Types (Byte,Short,Integer,Long, Character) >> is it a good idea to also change such ctor of those? Would someone raise >> an enhancement >> for those? >> 3. How are value-types related to such an issue. Is it counterproductive >> to change to XYZ.valueOf Method uses, or should we change to autoboxing >> where possible? I haven't changed to autoboxing where i thought it would >> be much less readable. >> 4. Should the changes be discussed in the group-lists? Or is there a >> good place for discussion off central-changes? >> >> >> -- Sebastian >> >> >> [1] https://bugs.openjdk.java.net/browse/JDK-5108778 >> [2] >> >> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2015-September/006970.html >> [3] >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-September/020018.html >> [4] >> >> https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/test_0/webrev/index.html >> > From peter.levart at gmail.com Tue Oct 6 13:32:52 2015 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 6 Oct 2015 15:32:52 +0200 Subject: JEP 264: Platform Logging API and Service In-Reply-To: <5612D6B2.7010601@oracle.com> References: <20150918161737.CF3F171F93@eggemoggin.niobe.net> <561256D8.10907@oracle.com> <561283D0.3060603@Oracle.com> <5612D6B2.7010601@oracle.com> Message-ID: <5613CD84.4000401@gmail.com> On 10/05/2015 09:59 PM, Daniel Fuchs wrote: > Thanks Roger! > > I have updated the specdiff online. > http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/specdiff-api/overview-summary.html > > > The only comment I haven't taken into account yet is this: > > > - the LoggerFinder constructor says "Only one instance will be > created". > > That applies to the normal static logger initialization > > (getLoggerFinder). > > But there might be other cases where the application or service > > might create a LoggerFinder > > for its own purposes, and the phrase is not accurate in that case. > > I was wondering whether I should try enforcing this actually, by > throwing a ServiceConfigurationError or whatever if the > LoggerFinder service is already loaded when the constructor > is invoked. > > We had trouble in the past with LogManager - because the spec > said there should be only one instance, but the implementation > did not enforce it. > It may be a bit different with LoggerFinder - as this is an > abstract class devoid of instance state (the only method with a > body is getLocalizedLogger and that's stateless) - so there may > not be as much harm as with LogManager. > > There is probably no good way of implementing such enforcement > though - so it would be a best effort :-( Hi Daniel, Scala has singleton objects. Java hasn't. Your statement intrigued me to think whether it would be possible to enforce a one-instance-per-concrete-class rule in Java using just API. Here's a prototype that I think does that. Can you think of a corner case that fools it? /** * An abstract base class for subclasses that can only have one instance * per concrete subclass. Subclasses must define a public no-args constructor * which must never be called directly from code (it throws * UnsupportedOperationException), but via the factory method: * {@link #getInstance(Class)}. */ public abstract class ClassObject { /** * Lazily constructs and returns a singleton instance per given concrete * {@code ClassObject} subclass or throws exception. * Subclasses must define a public no-argument constructor. Multiple * invocations of this method with same {@code clazz} parameter either return * the same instance or throw the same exception. The result of this method * is therefore stable for given parameter. * * @param clazz the Class representing concrete {@code ClassObject} subclass * @param <T> the type of the {@code ClassObject} subclass * @return a singleton instance for given {@code clazz} * @throws InstantiationException see {@link Constructor#newInstance} * @throws IllegalAccessException see {@link Constructor#newInstance} * @throws InvocationTargetException see {@link Constructor#newInstance} */ public static <T extends ClassObject> T getInstance(Class<T> clazz) throws InstantiationException, IllegalAccessException, InvocationTargetException { return clazz.cast(factoryCV.get(clazz).get()); } /** * ClassObject constructor allows construction of a single instance of * {@code ClassObject} subclass per concrete subclass. */ public ClassObject() { Factory factory = factoryCV.get(getClass()); synchronized (factory) { if (!factory.inConstruction) { throw new UnsupportedOperationException( "Direct construction of ClassObject instances is not supported." + " Please use ClassObject.getInstance(Class) instead."); } if (factory.constructed != null) { throw new IllegalStateException( "Attempt to instantiate a second " + getClass().getName() + " instance."); } factory.constructed = this; } } /** * A ClassValue cache of Factory instances per class */ private static final ClassValue<Factory> factoryCV = new ClassValue<Factory>() { @Override protected Factory computeValue(Class<?> clazz) { return new Factory(clazz.asSubclass(ClassObject.class)); } }; /** * A Factory responsible for constructing and caching a singleton instance * of specified class. */ private static final class Factory { // the class of instance to construct private final Class<? extends ClassObject> clazz; // published instance or Throwable private volatile Object instance; // temporarily set to true while constructing and checked in ClassObject constructor boolean inConstruction; // the just being constructed instance or Throwable, set in ClassObject constructor Object constructed; Factory(Class<? extends ClassObject> clazz) { this.clazz = clazz; } ClassObject get() throws InstantiationException, IllegalAccessException, InvocationTargetException { Object obj = instance; if (obj == null) { synchronized (this) { obj = instance; if (obj == null) { if (constructed == null) { try { Constructor<? extends ClassObject> constructor = clazz.getDeclaredConstructor(); inConstruction = true; constructor.newInstance(); } catch (Throwable t) { // override with construction exception if thrown constructed = t; } finally { inConstruction = false; } } instance = obj = constructed; assert obj != null; } } } if (obj instanceof ClassObject) { return (ClassObject) obj; } Factory.<InstantiationException>sneakyThrow((Throwable) obj); // not reached return null; } @SuppressWarnings("unchecked") private static <T extends Throwable> void sneakyThrow(Throwable t) throws T { throw (T) t; } } } I don't think it is very important to enforce such rule for services provided via ServiceLoader since similar effect can be achieved by treating the published abstract type only as a factory for a real service which can then be initialized and cached as a singleton object in the implementation itself. But that can not be enforced on the system level. If the abstract type has state and you would want to initialize it only once, ClassObject might be an answer. If ClassObject abstract class was part of JDK, ServiceLoader would have to special-case it's subclasses and invoke ClassObject.getInstance(Class) instead of the no-arg constructor to obtain the instance. Regards, Peter > > best regards, > > -- daniel > > > On 05/10/15 16:06, Roger Riggs wrote: >> Hi Daniel, >> >> This looks good, a few comments... >> >> j.l.System: >> - the behaviors described by the @implNote in getLogger(name) and >> @implSpec in getLogger(name, resourceBundle) seem like they should >> be consistent >> for the two methods. >> >> System.Logger: >> - log(level, throwable, Supplier) - to be more consistent, the >> Suppler<String> argument >> should be before the Throwable argument. >> Then in all cases the msg/string is before the Throwable. >> >> System.Logger.Level >> - TRACE might be used for more than just method entry and exit, >> perhaps the description can be more >> general: "usually used for diagnostic information." >> >> LoggerFinder: >> >> - should the CONTROL_PERMISSION field be renamed to >> "LOGGERFINDER_PERMISSION"? >> >> - the LoggerFinder constructor says "Only one instance will be >> created". >> That applies to the normal static logger initialization >> (getLoggerFinder). >> But there might be other cases where the application or service >> might create a LoggerFinder >> for its own purposes, and the phrase is not accurate in that case. >> >> >> Editorial: >> - The @since tags can be set to "9". >> >> - "JVM" -> "Java runtime"; JVM would specifically refer to the >> virtual machine implementation. (j.u.System.LoggerFinder) >> >> - "used by the JDK" can be omitted. (j.u.System.LoggerFinder) >> When used in the context of the JDK documentation itself it seems >> out of place and is unnecessary. >> >> - the word 'actually' can/should be omitted from descriptions. >> (j.l.System) >> >> Thanks, Roger >> >> >> On 10/5/2015 6:54 AM, Daniel Fuchs wrote: >>>> New JEP Candidate: http://openjdk.java.net/jeps/264 >>> >>> Hi I have uploaded an initial prototype specdiff: >>> >>> http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/specdiff-api/overview-summary.html >>> >>> >>> >>> LoggerFinder methods that take a Class<?> caller argument >>> will take a java.lang.reflect.Module callerModule instead when >>> that is available in jdk9/dev. >>> >>> comments welcome, >>> >>> best regards, >>> >>> -- daniel >>> >> > From Roger.Riggs at Oracle.com Tue Oct 6 13:43:59 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 6 Oct 2015 09:43:59 -0400 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null Message-ID: <5613D01F.3000107@Oracle.com> Java.lang.Objects contains a number of convenience methods to make it easier to handle references that are null. For example, toString(obj, nullDefault), A new method is proposed to return the reference or a default value if the reference is null. static <T> T nonNull(T obj, T nullDefault); Alternatives to the method name include nonNullOrElse ( using the java.util.Optional name pattern) or nonNullOrDefault Please review and comment. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ Issue: https://bugs.openjdk.java.net/browse/JDK-8138963 Thanks, Roger From ivan.gerasimov at oracle.com Tue Oct 6 13:53:47 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 6 Oct 2015 16:53:47 +0300 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <5613D01F.3000107@Oracle.com> References: <5613D01F.3000107@Oracle.com> Message-ID: <5613D26B.2000407@oracle.com> Hi Roger! I didn't notice the message, so first commented in the Jira. Would it make sense to also add a variant with the second argument of type Supplier, so that it can be lazily calculated only if needed? Something like: public static <T> T nonNull(T obj, Supplier<T> nullDefaultSupplier) { return (obj != null) ? obj : nullDefaultSupplier.get(); } Sincerely yours, Ivan On 06.10.2015 16:43, Roger Riggs wrote: > Java.lang.Objects contains a number of convenience methods to make it > easier to handle references that are null. > For example, toString(obj, nullDefault), > > A new method is proposed to return the reference or a default value if > the reference is null. > static <T> T nonNull(T obj, T nullDefault); > > Alternatives to the method name include > nonNullOrElse ( using the java.util.Optional name pattern) or > nonNullOrDefault > > Please review and comment. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8138963 > > Thanks, Roger > > From Roger.Riggs at Oracle.com Tue Oct 6 13:53:46 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 6 Oct 2015 09:53:46 -0400 Subject: JEP 264: Platform Logging API and Service In-Reply-To: <5613CD84.4000401@gmail.com> References: <20150918161737.CF3F171F93@eggemoggin.niobe.net> <561256D8.10907@oracle.com> <561283D0.3060603@Oracle.com> <5612D6B2.7010601@oracle.com> <5613CD84.4000401@gmail.com> Message-ID: <5613D26A.4030608@Oracle.com> Hi, This case does not require a restriction. This is not really a case of a singleton object. I think the statement is a statement of fact. The behavior should be attributed to the LoggerFinder.getLoggerFinder method and not to the constructor of LoggerFinder. Roger On 10/6/2015 9:32 AM, Peter Levart wrote: > > > On 10/05/2015 09:59 PM, Daniel Fuchs wrote: >> Thanks Roger! >> >> I have updated the specdiff online. >> http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/specdiff-api/overview-summary.html >> >> >> The only comment I haven't taken into account yet is this: >> >> > - the LoggerFinder constructor says "Only one instance will be >> created". >> > That applies to the normal static logger initialization >> > (getLoggerFinder). >> > But there might be other cases where the application or service >> > might create a LoggerFinder >> > for its own purposes, and the phrase is not accurate in that case. >> >> I was wondering whether I should try enforcing this actually, by >> throwing a ServiceConfigurationError or whatever if the >> LoggerFinder service is already loaded when the constructor >> is invoked. >> >> We had trouble in the past with LogManager - because the spec >> said there should be only one instance, but the implementation >> did not enforce it. >> It may be a bit different with LoggerFinder - as this is an >> abstract class devoid of instance state (the only method with a >> body is getLocalizedLogger and that's stateless) - so there may >> not be as much harm as with LogManager. >> >> There is probably no good way of implementing such enforcement >> though - so it would be a best effort :-( > > Hi Daniel, > > Scala has singleton objects. Java hasn't. Your statement intrigued me > to think whether it would be possible to enforce a > one-instance-per-concrete-class rule in Java using just API. Here's a > prototype that I think does that. Can you think of a corner case that > fools it? > > /** > * An abstract base class for subclasses that can only have one instance > * per concrete subclass. Subclasses must define a public no-args > constructor > * which must never be called directly from code (it throws > * UnsupportedOperationException), but via the factory method: > * {@link #getInstance(Class)}. > */ > public abstract class ClassObject { > > /** > * Lazily constructs and returns a singleton instance per given > concrete > * {@code ClassObject} subclass or throws exception. > * Subclasses must define a public no-argument constructor. Multiple > * invocations of this method with same {@code clazz} parameter > either return > * the same instance or throw the same exception. The result of > this method > * is therefore stable for given parameter. > * > * @param clazz the Class representing concrete {@code > ClassObject} subclass > * @param <T> the type of the {@code ClassObject} subclass > * @return a singleton instance for given {@code clazz} > * @throws InstantiationException see {@link Constructor#newInstance} > * @throws IllegalAccessException see {@link Constructor#newInstance} > * @throws InvocationTargetException see {@link > Constructor#newInstance} > */ > public static <T extends ClassObject> T getInstance(Class<T> clazz) > throws InstantiationException, IllegalAccessException, > InvocationTargetException { > return clazz.cast(factoryCV.get(clazz).get()); > } > > /** > * ClassObject constructor allows construction of a single > instance of > * {@code ClassObject} subclass per concrete subclass. > */ > public ClassObject() { > Factory factory = factoryCV.get(getClass()); > synchronized (factory) { > if (!factory.inConstruction) { > throw new UnsupportedOperationException( > "Direct construction of ClassObject instances is > not supported." + > " Please use ClassObject.getInstance(Class) > instead."); > } > if (factory.constructed != null) { > throw new IllegalStateException( > "Attempt to instantiate a second " + > getClass().getName() + " instance."); > } > factory.constructed = this; > } > } > > /** > * A ClassValue cache of Factory instances per class > */ > private static final ClassValue<Factory> factoryCV = new > ClassValue<Factory>() { > @Override > protected Factory computeValue(Class<?> clazz) { > return new Factory(clazz.asSubclass(ClassObject.class)); > } > }; > > /** > * A Factory responsible for constructing and caching a singleton > instance > * of specified class. > */ > private static final class Factory { > // the class of instance to construct > private final Class<? extends ClassObject> clazz; > // published instance or Throwable > private volatile Object instance; > // temporarily set to true while constructing and checked in > ClassObject constructor > boolean inConstruction; > // the just being constructed instance or Throwable, set in > ClassObject constructor > Object constructed; > > Factory(Class<? extends ClassObject> clazz) { > this.clazz = clazz; > } > > ClassObject get() throws InstantiationException, > IllegalAccessException, InvocationTargetException { > Object obj = instance; > if (obj == null) { > synchronized (this) { > obj = instance; > if (obj == null) { > if (constructed == null) { > try { > Constructor<? extends ClassObject> > constructor = > clazz.getDeclaredConstructor(); > inConstruction = true; > constructor.newInstance(); > } catch (Throwable t) { > // override with construction > exception if thrown > constructed = t; > } finally { > inConstruction = false; > } > } > instance = obj = constructed; > assert obj != null; > } > } > } > if (obj instanceof ClassObject) { > return (ClassObject) obj; > } > Factory.<InstantiationException>sneakyThrow((Throwable) obj); > // not reached > return null; > } > > @SuppressWarnings("unchecked") > private static <T extends Throwable> void > sneakyThrow(Throwable t) throws T { > throw (T) t; > } > } > } > > > I don't think it is very important to enforce such rule for services > provided via ServiceLoader since similar effect can be achieved by > treating the published abstract type only as a factory for a real > service which can then be initialized and cached as a singleton object > in the implementation itself. But that can not be enforced on the > system level. If the abstract type has state and you would want to > initialize it only once, ClassObject might be an answer. If > ClassObject abstract class was part of JDK, ServiceLoader would have > to special-case it's subclasses and invoke > ClassObject.getInstance(Class) instead of the no-arg constructor to > obtain the instance. > > Regards, Peter > >> >> best regards, >> >> -- daniel >> >> >> On 05/10/15 16:06, Roger Riggs wrote: >>> Hi Daniel, >>> >>> This looks good, a few comments... >>> >>> j.l.System: >>> - the behaviors described by the @implNote in getLogger(name) and >>> @implSpec in getLogger(name, resourceBundle) seem like they should >>> be consistent >>> for the two methods. >>> >>> System.Logger: >>> - log(level, throwable, Supplier) - to be more consistent, the >>> Suppler<String> argument >>> should be before the Throwable argument. >>> Then in all cases the msg/string is before the Throwable. >>> >>> System.Logger.Level >>> - TRACE might be used for more than just method entry and exit, >>> perhaps the description can be more >>> general: "usually used for diagnostic information." >>> >>> LoggerFinder: >>> >>> - should the CONTROL_PERMISSION field be renamed to >>> "LOGGERFINDER_PERMISSION"? >>> >>> - the LoggerFinder constructor says "Only one instance will be >>> created". >>> That applies to the normal static logger initialization >>> (getLoggerFinder). >>> But there might be other cases where the application or service >>> might create a LoggerFinder >>> for its own purposes, and the phrase is not accurate in that case. >>> >>> >>> Editorial: >>> - The @since tags can be set to "9". >>> >>> - "JVM" -> "Java runtime"; JVM would specifically refer to the >>> virtual machine implementation. (j.u.System.LoggerFinder) >>> >>> - "used by the JDK" can be omitted. (j.u.System.LoggerFinder) >>> When used in the context of the JDK documentation itself it seems >>> out of place and is unnecessary. >>> >>> - the word 'actually' can/should be omitted from descriptions. >>> (j.l.System) >>> >>> Thanks, Roger >>> >>> >>> On 10/5/2015 6:54 AM, Daniel Fuchs wrote: >>>>> New JEP Candidate: http://openjdk.java.net/jeps/264 >>>> >>>> Hi I have uploaded an initial prototype specdiff: >>>> >>>> http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/specdiff-api/overview-summary.html >>>> >>>> >>>> >>>> LoggerFinder methods that take a Class<?> caller argument >>>> will take a java.lang.reflect.Module callerModule instead when >>>> that is available in jdk9/dev. >>>> >>>> comments welcome, >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>> >> > From pbenedict at apache.org Tue Oct 6 13:56:59 2015 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 6 Oct 2015 08:56:59 -0500 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <5613D01F.3000107@Oracle.com> References: <5613D01F.3000107@Oracle.com> Message-ID: <CABLGb9x=u8-3sM+0Ty5K+B3HjZoMO5wZTxjnbKaBgJMw6toyQw@mail.gmail.com> It's quite possible for the second argument to be null. Is that your intention? I am not sure it makes sense, but it's not harmful either. I recommend you can either (1) explicitly document that's a possibility and this method could still return null or (2) prevent it by calling requireNonNull. Cheers, Paul On Tue, Oct 6, 2015 at 8:43 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote: > Java.lang.Objects contains a number of convenience methods to make it > easier to handle references that are null. > For example, toString(obj, nullDefault), > > A new method is proposed to return the reference or a default value if the > reference is null. > static <T> T nonNull(T obj, T nullDefault); > > Alternatives to the method name include > nonNullOrElse ( using the java.util.Optional name pattern) or > nonNullOrDefault > > Please review and comment. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8138963 > > Thanks, Roger > > From Roger.Riggs at Oracle.com Tue Oct 6 13:58:44 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 6 Oct 2015 09:58:44 -0400 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <5613D26B.2000407@oracle.com> References: <5613D01F.3000107@Oracle.com> <5613D26B.2000407@oracle.com> Message-ID: <5613D394.6030006@Oracle.com> Hi Ivan, Easy enough, but I have not surveyed the codebase to see if it would be used or is necessary. Most of the cases I've seen are simple if/then/else or ?: expressions. Using the Supplier for does have some extra overhead not readily observable in the code. There is precedent for such a method in requireNonNull, where the cost of composing/formatting the exception text can be avoided using a supplier. Roger On 10/6/2015 9:53 AM, Ivan Gerasimov wrote: > Hi Roger! > > I didn't notice the message, so first commented in the Jira. > > Would it make sense to also add a variant with the second argument of > type Supplier, so that it can be lazily calculated only if needed? > Something like: > public static <T> T nonNull(T obj, Supplier<T> nullDefaultSupplier) { > return (obj != null) ? obj : nullDefaultSupplier.get(); > } > > Sincerely yours, > Ivan > > On 06.10.2015 16:43, Roger Riggs wrote: >> Java.lang.Objects contains a number of convenience methods to make it >> easier to handle references that are null. >> For example, toString(obj, nullDefault), >> >> A new method is proposed to return the reference or a default value >> if the reference is null. >> static <T> T nonNull(T obj, T nullDefault); >> >> Alternatives to the method name include >> nonNullOrElse ( using the java.util.Optional name pattern) or >> nonNullOrDefault >> >> Please review and comment. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8138963 >> >> Thanks, Roger >> >> > From scolebourne at joda.org Tue Oct 6 14:00:37 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 6 Oct 2015 15:00:37 +0100 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <5613D01F.3000107@Oracle.com> References: <5613D01F.3000107@Oracle.com> Message-ID: <CACzrW9CHGGpcDGQh2FoeFwgTwXr1besNdt42L3+RE6Cy7jPMLg@mail.gmail.com> Guava uses firstNonNull(a, b). It ensures that the result is never null, by checking that b is not null. I think the semantics of Guava's method is correct. I tend to think the method name isn't bad either. Calling it nonNull(Object,Object) clashes with the existing nonNull(Object) method. Those two have nothing much to do with each other. Stephen On 6 October 2015 at 14:43, Roger Riggs <Roger.Riggs at oracle.com> wrote: > Java.lang.Objects contains a number of convenience methods to make it easier > to handle references that are null. > For example, toString(obj, nullDefault), > > A new method is proposed to return the reference or a default value if the > reference is null. > static <T> T nonNull(T obj, T nullDefault); > > Alternatives to the method name include > nonNullOrElse ( using the java.util.Optional name pattern) or > nonNullOrDefault > > Please review and comment. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8138963 > > Thanks, Roger > From gil at azulsystems.com Tue Oct 6 14:04:54 2015 From: gil at azulsystems.com (Gil Tene) Date: Tue, 6 Oct 2015 14:04:54 +0000 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <56138372.7050107@redhat.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <56123B47.4070706@oracle.com> <9FD5F6D1-2875-469C-B4C1-5F7ED0740084@azulsystems.com>, <56138372.7050107@redhat.com> Message-ID: <A8FD2B97-945B-4BE6-862A-777FD7F4ADDC@azulsystems.com> Sent from Gil's iPhone > On Oct 6, 2015, at 1:16 AM, Andrew Haley <aph at redhat.com> wrote: > >> On 06/10/15 05:32, Gil Tene wrote: >> >> I don't think of this as platform specific. And it's not much lower >> level than e.g. some java.util.concurrent stuff (but probably >> doesn't belong in that package because it's not really about >> concurrency). I'm looking for a proper Java SE spec'ed way to do >> this. So sun.misc.* won't work. I'm sure we don't want another >> Unsafe for people to abuse... >> >> But naming the class and method is the smaller, easier detail. Right? ;-) > > Sure. I would have thought, though, that java.util.concurrent was a > natural home for this. Is there any kind of userland spinlock which > is not about concurrency? The same can be asked about Thread.notify(). To me, spinKoopHint() fits in (as in "probably a method in the same class") with other performance-oriented hints. Like prefetch variants (which we don't have but also probably need. E.g. prefetchWithIntentToWrite()). And placing prefetch hints in j.u.c would not make much sense. From Roger.Riggs at Oracle.com Tue Oct 6 14:06:57 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 6 Oct 2015 10:06:57 -0400 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <CABLGb9x=u8-3sM+0Ty5K+B3HjZoMO5wZTxjnbKaBgJMw6toyQw@mail.gmail.com> References: <5613D01F.3000107@Oracle.com> <CABLGb9x=u8-3sM+0Ty5K+B3HjZoMO5wZTxjnbKaBgJMw6toyQw@mail.gmail.com> Message-ID: <5613D581.2020808@Oracle.com> Hi Paul, Hence the question about the method name. It already documents explicitly that the nullDefault value is returned and does not restrict the value. To be a direct replacement for the current code, it should return the 2nd value regardless of whether it is null or not. Roger On 10/6/2015 9:56 AM, Paul Benedict wrote: > It's quite possible for the second argument to be null. Is that your > intention? I am not sure it makes sense, but it's not harmful either. > I recommend you can either (1) explicitly document that's a > possibility and this method could still return null or (2) prevent it > by calling requireNonNull. > > > Cheers, > Paul > > On Tue, Oct 6, 2015 at 8:43 AM, Roger Riggs <Roger.Riggs at oracle.com > <mailto:Roger.Riggs at oracle.com>> wrote: > > Java.lang.Objects contains a number of convenience methods to make > it easier to handle references that are null. > For example, toString(obj, nullDefault), > > A new method is proposed to return the reference or a default > value if the reference is null. > static <T> T nonNull(T obj, T nullDefault); > > Alternatives to the method name include > nonNullOrElse ( using the java.util.Optional name pattern) or > nonNullOrDefault > > Please review and comment. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ > <http://cr.openjdk.java.net/%7Erriggs/webrev-object-non-null/> > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8138963 > > Thanks, Roger > > From Roger.Riggs at Oracle.com Tue Oct 6 14:09:57 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 6 Oct 2015 10:09:57 -0400 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <CACzrW9CHGGpcDGQh2FoeFwgTwXr1besNdt42L3+RE6Cy7jPMLg@mail.gmail.com> References: <5613D01F.3000107@Oracle.com> <CACzrW9CHGGpcDGQh2FoeFwgTwXr1besNdt42L3+RE6Cy7jPMLg@mail.gmail.com> Message-ID: <5613D635.6000305@Oracle.com> Hi Stephen, Guava's firstNonNull is a useful semantic, but would not be a drop in replacement for existing code which would need to be examined for behavioral changes due to possibly throwing an exception. So perhaps the nonNullorElse name would be more accurate. Thanks, Roger On 10/6/2015 10:00 AM, Stephen Colebourne wrote: > Guava uses firstNonNull(a, b). It ensures that the result is never > null, by checking that b is not null. > I think the semantics of Guava's method is correct. I tend to think > the method name isn't bad either. > > Calling it nonNull(Object,Object) clashes with the existing > nonNull(Object) method. Those two have nothing much to do with each > other. > > Stephen > > > On 6 October 2015 at 14:43, Roger Riggs <Roger.Riggs at oracle.com> wrote: >> Java.lang.Objects contains a number of convenience methods to make it easier >> to handle references that are null. >> For example, toString(obj, nullDefault), >> >> A new method is proposed to return the reference or a default value if the >> reference is null. >> static <T> T nonNull(T obj, T nullDefault); >> >> Alternatives to the method name include >> nonNullOrElse ( using the java.util.Optional name pattern) or >> nonNullOrDefault >> >> Please review and comment. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8138963 >> >> Thanks, Roger >> From pbenedict at apache.org Tue Oct 6 14:11:23 2015 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 6 Oct 2015 09:11:23 -0500 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <5613D581.2020808@Oracle.com> References: <5613D01F.3000107@Oracle.com> <CABLGb9x=u8-3sM+0Ty5K+B3HjZoMO5wZTxjnbKaBgJMw6toyQw@mail.gmail.com> <5613D581.2020808@Oracle.com> Message-ID: <CABLGb9wFjb-vYvVY=Hs62YUAMwg9DJ2TmBt7OUYMw8Dmmeq=Kg@mail.gmail.com> If the second value is allowed to be null, then I don't find this new method useful. What value do you see in it? It doesn't provide any extra functionality to a simple if-else/ternary test, right? I throw my lot in with Stephen that the return value must be non-null. Cheers, Paul On Tue, Oct 6, 2015 at 9:06 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote: > Hi Paul, > > Hence the question about the method name. > It already documents explicitly that the nullDefault value is returned and > does not restrict the value. > > To be a direct replacement for the current code, it should return the 2nd > value regardless of whether it is null or not. > > Roger > > > > > On 10/6/2015 9:56 AM, Paul Benedict wrote: > > It's quite possible for the second argument to be null. Is that your > intention? I am not sure it makes sense, but it's not harmful either. I > recommend you can either (1) explicitly document that's a possibility and > this method could still return null or (2) prevent it by calling > requireNonNull. > > > Cheers, > Paul > > On Tue, Oct 6, 2015 at 8:43 AM, Roger Riggs <Roger.Riggs at oracle.com> > wrote: > >> Java.lang.Objects contains a number of convenience methods to make it >> easier to handle references that are null. >> For example, toString(obj, nullDefault), >> >> A new method is proposed to return the reference or a default value if >> the reference is null. >> static <T> T nonNull(T obj, T nullDefault); >> >> Alternatives to the method name include >> nonNullOrElse ( using the java.util.Optional name pattern) or >> nonNullOrDefault >> >> Please review and comment. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8138963 >> >> Thanks, Roger >> >> > > From vitalyd at gmail.com Tue Oct 6 14:12:24 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 6 Oct 2015 10:12:24 -0400 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <56138372.7050107@redhat.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <56123B47.4070706@oracle.com> <9FD5F6D1-2875-469C-B4C1-5F7ED0740084@azulsystems.com> <56138372.7050107@redhat.com> Message-ID: <CAHjP37H+sFtR=2VhQ-z_ZGxaC39DzKgenV_+o6mGp8aa0ukWVg@mail.gmail.com> Although spin lock would also benefit from this, the spinning is also done when doing message hand off between threads. It's common in low latency space to monopolize the cpu(s) and spin wait for data to arrive; this is to avoid parking the thread in kernel when you know arrival rate is very high. As for j.u.c. I believe StampedLock had some manual spinning and uses ThreadLocalRandom to create artificial mispredicts to prevent speculative pipeline from filling up (basically simulating pause like instruction). sent from my phone On Oct 6, 2015 4:17 AM, "Andrew Haley" <aph at redhat.com> wrote: > On 06/10/15 05:32, Gil Tene wrote: > > > I don't think of this as platform specific. And it's not much lower > > level than e.g. some java.util.concurrent stuff (but probably > > doesn't belong in that package because it's not really about > > concurrency). I'm looking for a proper Java SE spec'ed way to do > > this. So sun.misc.* won't work. I'm sure we don't want another > > Unsafe for people to abuse... > > > > But naming the class and method is the smaller, easier detail. Right? ;-) > > Sure. I would have thought, though, that java.util.concurrent was a > natural home for this. Is there any kind of userland spinlock which > is not about concurrency? > > Andrew. > From scolebourne at joda.org Tue Oct 6 14:15:01 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 6 Oct 2015 15:15:01 +0100 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <5613D635.6000305@Oracle.com> References: <5613D01F.3000107@Oracle.com> <CACzrW9CHGGpcDGQh2FoeFwgTwXr1besNdt42L3+RE6Cy7jPMLg@mail.gmail.com> <5613D635.6000305@Oracle.com> Message-ID: <CACzrW9C2bomoiA+hQcq6=H7QvMuBu2c7wmOGYHwq31b6Z=M18A@mail.gmail.com> What the existing code does would seem to be irrelevant. What is important is deciding what the correct semantics should be for a core method on Objects. If there a desperate need for the webrev semantics, how about two methods? firstNonNull(a, b) - result must not be null firstOrElse(a, b) - result is null only is b is null (although I struggle to see much point in the latter) Stephen On 6 October 2015 at 15:09, Roger Riggs <Roger.Riggs at oracle.com> wrote: > Hi Stephen, > > Guava's firstNonNull is a useful semantic, but would not be a drop in > replacement for existing code which > would need to be examined for behavioral changes due to possibly throwing an > exception. > So perhaps the nonNullorElse name would be more accurate. > > Thanks, Roger > > > > On 10/6/2015 10:00 AM, Stephen Colebourne wrote: >> >> Guava uses firstNonNull(a, b). It ensures that the result is never >> null, by checking that b is not null. >> I think the semantics of Guava's method is correct. I tend to think >> the method name isn't bad either. >> >> Calling it nonNull(Object,Object) clashes with the existing >> nonNull(Object) method. Those two have nothing much to do with each >> other. >> >> Stephen >> >> >> On 6 October 2015 at 14:43, Roger Riggs <Roger.Riggs at oracle.com> wrote: >>> >>> Java.lang.Objects contains a number of convenience methods to make it >>> easier >>> to handle references that are null. >>> For example, toString(obj, nullDefault), >>> >>> A new method is proposed to return the reference or a default value if >>> the >>> reference is null. >>> static <T> T nonNull(T obj, T nullDefault); >>> >>> Alternatives to the method name include >>> nonNullOrElse ( using the java.util.Optional name pattern) or >>> nonNullOrDefault >>> >>> Please review and comment. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8138963 >>> >>> Thanks, Roger >>> > From Roger.Riggs at Oracle.com Tue Oct 6 14:23:15 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 6 Oct 2015 10:23:15 -0400 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <CABLGb9wFjb-vYvVY=Hs62YUAMwg9DJ2TmBt7OUYMw8Dmmeq=Kg@mail.gmail.com> References: <5613D01F.3000107@Oracle.com> <CABLGb9x=u8-3sM+0Ty5K+B3HjZoMO5wZTxjnbKaBgJMw6toyQw@mail.gmail.com> <5613D581.2020808@Oracle.com> <CABLGb9wFjb-vYvVY=Hs62YUAMwg9DJ2TmBt7OUYMw8Dmmeq=Kg@mail.gmail.com> Message-ID: <5613D953.7030008@Oracle.com> HI Paul, It simplifies code that looks like this: followRedirects = builder.followRedirects == null ? Redirect.NEVER : builder.followRedirects; To: followRedirects = Objects.nonNullOrElse(builder.followRedirects, Redirect.NEVER); It makes the source code more concise by not repeating the expression twice and avoids evaluating the expression more than once. Roger On 10/6/2015 10:11 AM, Paul Benedict wrote: > If the second value is allowed to be null, then I don't find this new > method useful. What value do you see in it? It doesn't provide any > extra functionality to a simple if-else/ternary test, right? I throw > my lot in with Stephen that the return value must be non-null. > > > Cheers, > Paul > > On Tue, Oct 6, 2015 at 9:06 AM, Roger Riggs <Roger.Riggs at oracle.com > <mailto:Roger.Riggs at oracle.com>> wrote: > > Hi Paul, > > Hence the question about the method name. > It already documents explicitly that the nullDefault value is > returned and does not restrict the value. > > To be a direct replacement for the current code, it should return > the 2nd value regardless of whether it is null or not. > > Roger > > > > > On 10/6/2015 9:56 AM, Paul Benedict wrote: >> It's quite possible for the second argument to be null. Is that >> your intention? I am not sure it makes sense, but it's not >> harmful either. I recommend you can either (1) explicitly >> document that's a possibility and this method could still return >> null or (2) prevent it by calling requireNonNull. >> >> >> Cheers, >> Paul >> >> On Tue, Oct 6, 2015 at 8:43 AM, Roger Riggs >> <Roger.Riggs at oracle.com <mailto:Roger.Riggs at oracle.com>> wrote: >> >> Java.lang.Objects contains a number of convenience methods to >> make it easier to handle references that are null. >> For example, toString(obj, nullDefault), >> >> A new method is proposed to return the reference or a default >> value if the reference is null. >> static <T> T nonNull(T obj, T nullDefault); >> >> Alternatives to the method name include >> nonNullOrElse ( using the java.util.Optional name pattern) or >> nonNullOrDefault >> >> Please review and comment. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ >> <http://cr.openjdk.java.net/%7Erriggs/webrev-object-non-null/> >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8138963 >> >> Thanks, Roger >> >> > > From peter.levart at gmail.com Tue Oct 6 14:29:25 2015 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 6 Oct 2015 16:29:25 +0200 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <CABLGb9wFjb-vYvVY=Hs62YUAMwg9DJ2TmBt7OUYMw8Dmmeq=Kg@mail.gmail.com> References: <5613D01F.3000107@Oracle.com> <CABLGb9x=u8-3sM+0Ty5K+B3HjZoMO5wZTxjnbKaBgJMw6toyQw@mail.gmail.com> <5613D581.2020808@Oracle.com> <CABLGb9wFjb-vYvVY=Hs62YUAMwg9DJ2TmBt7OUYMw8Dmmeq=Kg@mail.gmail.com> Message-ID: <5613DAC5.8030504@gmail.com> On 10/06/2015 04:11 PM, Paul Benedict wrote: > If the second value is allowed to be null, then I don't find this new > method useful. What value do you see in it? It doesn't provide any extra > functionality to a simple if-else/ternary test, right? I throw my lot in > with Stephen that the return value must be non-null. The extra functionality of such function is that it can be used as an in-line expression. Ternary test requires to evaluate 1st argument twice or it can't be an expression: T x = expression that is costly to compute; (x == null) ? y : x vs. nullValue(expression that is costly to compute, y) You can always compose: nonNull(nullValue(x, y)) Regards, Peter P.S. nullValue is my suggestion for the name (Oracle DB uses NVL(x, y)) P.P.S Current alternative is also: Optional.ofNullable(x).orElse(y) > > > Cheers, > Paul > > On Tue, Oct 6, 2015 at 9:06 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote: > >> Hi Paul, >> >> Hence the question about the method name. >> It already documents explicitly that the nullDefault value is returned and >> does not restrict the value. >> >> To be a direct replacement for the current code, it should return the 2nd >> value regardless of whether it is null or not. >> >> Roger >> >> >> >> >> On 10/6/2015 9:56 AM, Paul Benedict wrote: >> >> It's quite possible for the second argument to be null. Is that your >> intention? I am not sure it makes sense, but it's not harmful either. I >> recommend you can either (1) explicitly document that's a possibility and >> this method could still return null or (2) prevent it by calling >> requireNonNull. >> >> >> Cheers, >> Paul >> >> On Tue, Oct 6, 2015 at 8:43 AM, Roger Riggs <Roger.Riggs at oracle.com> >> wrote: >> >>> Java.lang.Objects contains a number of convenience methods to make it >>> easier to handle references that are null. >>> For example, toString(obj, nullDefault), >>> >>> A new method is proposed to return the reference or a default value if >>> the reference is null. >>> static <T> T nonNull(T obj, T nullDefault); >>> >>> Alternatives to the method name include >>> nonNullOrElse ( using the java.util.Optional name pattern) or >>> nonNullOrDefault >>> >>> Please review and comment. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8138963 >>> >>> Thanks, Roger >>> >>> >> From Mohammad.Rezaei at gs.com Tue Oct 6 14:54:57 2015 From: Mohammad.Rezaei at gs.com (Rezaei, Mohammad A.) Date: Tue, 6 Oct 2015 10:54:57 -0400 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <A8FD2B97-945B-4BE6-862A-777FD7F4ADDC@azulsystems.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <56123B47.4070706@oracle.com> <9FD5F6D1-2875-469C-B4C1-5F7ED0740084@azulsystems.com>, <56138372.7050107@redhat.com> <A8FD2B97-945B-4BE6-862A-777FD7F4ADDC@azulsystems.com> Message-ID: <6882C9A35DFB9B4FA2779F7BF5B9757D2083639C97@GSCMAMP06EX.firmwide.corp.gs.com> Thread.yield(), Thread.sleep(), Thread.spinLoopHint()? Somehow, it feels right (as in consistent), but also off at the same time (as in, why are these on Thread). I'd take consistent over bespoke-one-static-method-class, unless there was a concerted effort to consolidate other related api/concerns. Thanks Moh >-----Original Message----- >From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf >Of Gil Tene >Sent: Tuesday, October 06, 2015 10:05 AM >To: Andrew Haley >Cc: hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net >Subject: Re: Spin Loop Hint support: Draft JEP proposal > > > >Sent from Gil's iPhone > >> On Oct 6, 2015, at 1:16 AM, Andrew Haley <aph at redhat.com> wrote: >> >>> On 06/10/15 05:32, Gil Tene wrote: >>> >>> I don't think of this as platform specific. And it's not much lower >>> level than e.g. some java.util.concurrent stuff (but probably >>> doesn't belong in that package because it's not really about >>> concurrency). I'm looking for a proper Java SE spec'ed way to do >>> this. So sun.misc.* won't work. I'm sure we don't want another >>> Unsafe for people to abuse... >>> >>> But naming the class and method is the smaller, easier detail. Right? ;-) >> >> Sure. I would have thought, though, that java.util.concurrent was a >> natural home for this. Is there any kind of userland spinlock which >> is not about concurrency? > >The same can be asked about Thread.notify(). > >To me, spinKoopHint() fits in (as in "probably a method in the same class") >with other performance-oriented hints. Like prefetch variants (which we don't >have but also probably need. E.g. prefetchWithIntentToWrite()). And placing >prefetch hints in j.u.c would not make much sense. From paul.sandoz at oracle.com Tue Oct 6 14:56:39 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 6 Oct 2015 16:56:39 +0200 Subject: RFR 8135248: Add utility methods to check indexes and ranges In-Reply-To: <219933313.1583380.1443622408446.JavaMail.zimbra@u-pem.fr> References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com> <9B6852B9-58C4-41C1-A731-0D5F3F87E9FE@oracle.com> <CACzrW9CR9hZt9BEaJSLnX8d7+w8D-5YA409TMjyF-8F+ddOsmQ@mail.gmail.com> <4B8AD5A1-376F-406B-8A50-44C199CB3471@oracle.com> <560AE56E.1020808@gmail.com> <8385037B-FB27-4885-802C-00CCE2556FC2@oracle.com> <560B9073.3060507@gmail.com> <CABLGb9zM-NWu-tyE-Ep95ij+6grSM0xGT=eRZ=FojGKHJAtTvA@mail.gmail.com> <219933313.1583380.1443622408446.JavaMail.zimbra@u-pem.fr> Message-ID: <1B93BECC-A884-459D-BFA7-964679A533BD@oracle.com> > On 30 Sep 2015, at 16:13, Remi Forax <forax at univ-mlv.fr> wrote: > > > > ----- Mail original ----- >> De: "Paul Benedict" <pbenedict at apache.org> >> ?: "Peter Levart" <peter.levart at gmail.com> >> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net> >> Envoy?: Mercredi 30 Septembre 2015 16:06:18 >> Objet: Re: RFR 8135248: Add utility methods to check indexes and ranges >> >> Ah, I was going to write about "values" ... glad this was mentioned. With >> Valhalla working on value classes, it does raise the question if >> range-checking is particular to Objects. Clearly it won't be once values >> are introduced. >> >> PS: I am still in favor of using Objects at the time being though just to >> get something checked-in. > > I am in favor of Objects too, > but I think the name (oh no bikeshedding again) should start with require* too make it clear that it goes with requireNonNull > > 'requireIndexInBounds' anyone ? > For now i am gonna commit what i currently have, and we could revisit the naming later on if necessary, but for now i will trade you the painting of this bike shed for another on Optional.or that kick start in another email (probably tomorrow). Paul. From peter.levart at gmail.com Tue Oct 6 15:14:20 2015 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 6 Oct 2015 17:14:20 +0200 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5612F582.4050909@Oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> Message-ID: <5613E54C.1040202@gmail.com> Hi Roger, This looks nice. Javadocs (in particular mine) will need some work though. I agree that clear() and clean() implementations are final so that subclasses can not interfere with (de)registration. Perhaps the same could be done to isEnqueued() and enqueue() so that subclasses would not be able to pretend they can do something about those methods. I think the xxxCleanableList fields in CleanerImpl can be wildcard typed: XxxCleanableReference<?> xxxCleanableList = ... The same can be done to prev/next fields in XxxxCleanableReference classes and to local "list" variables in insert()/remove() methods. Unsafe casts and @SuppressWarnings annotations can then be removed. Regards, Peter On 10/06/2015 12:11 AM, Roger Riggs wrote: > Hi, > > Building on Peter's code to provide subclassable CleanableReferences, > I rearranged > the implementation a bit to make it easier to maintain. > The CleanableReferences subclasses are nested inside the Cleaner to > make the scoping clear. > > Please review and comment: > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-cleaner-extensible-8138696/ > > javadoc: > http://cr.openjdk.java.net/~rriggs/cleaner-doc2/ > > Thanks, Roger > > > > On 10/2/2015 11:34 AM, Roger Riggs wrote: >> Hi Peter, >> >> Great comments, thanks for looking into this... >> >> On 10/2/2015 7:52 AM, Peter Levart wrote: >>> Hi Roger, >>> >>> This is a nice and clean API. I like the trick with embedding a >>> private CleanerImpl in Cleaner and registering Cleaner itself as a >>> tracked object so that automatic thread termination can be performed >>> in a safe manner. You say the scope of this is not to replace >>> internal usages of sun.misc.Cleaner. But if they ever get replaced, >>> there are two differences between the implementations to note: >>> >>> - sun.misc.Cleaner thunks get executed by a ReferenceHandler thread >>> directly and bypass ReferenceQueue-ing. This might be OK for >>> internal use, but not appropriate for public API. I doubt this >>> sun.misc.Cleaner exception in ReferenceHandler is necessary though. >>> - With sun.misc.Cleaner one has to create a minimum of 2 additional >>> objects per tracked object: the Cleaner object and a Runnable thunk. >>> This API requires creation of 3 objects per tracked object: the >>> Cleanup object, the internal Reference object and a Runnable thunk. >>> >>> Do you think Cleaner will not be used in scenarios where this >>> additional footprint matters? >> I don't have any particular data on that point. When used with >> lambda or method references for >> the thunk, it is likely there will be some binding overhead. >>> >>> It might be possible to merge the roles of Cleanup and Reference >>> into one object, like this: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Cleaner/Cleaner.java >>> >>> Making Cleanup an interface, internal Reference(s) can implement it. >>> One can cast a Cleanup instance to a Reference and invoke it's other >>> methods, but this can be prevented by throwing >>> UnsupportedOperationException from them, so nobody is tempted to >>> employ this implementation detail. >> >> I prototyped a similar implementation but backed it out due to the >> code duplication and complexity. >> It also seemed a poor choice to break the contract of Reference by >> throwing UnsupportedOperationException >> on the unneeded but exposed methods since they could not be >> completely encapsulated. >> It seemed cleaner to have only a concrete type that was exposed to >> the clients. >> >> BTW, the code in you cleaner might be simpler if the cleaner lists >> for each of the three types were separate. >> (The entries don't need to be intermixed). That could simplify the >> virtual next/prev access but would still be >> duplicating the linked list management code). >> There could be multiple insertXXX methods so the casts were not >> necessary. >> >>> >>> There might be utility in exposing Cleanup (or better named >>> Cleanable) References as public abstract classes so that a footprint >>> sensitive application (for example in a data structure with many >>> elements) is possible. By subclassing such an abstract reference and >>> implementing the abstract method, a single object is required per >>> tracked object. Here I derived a proof of concept from your code: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Cleaner/webrev.01/ >>> >>> The simple API is unchanged and there is additional low-level API >>> that can be used if footprint matters. >>> >>> What do you think? >> >> I see what you're getting at. I would probably try to rearrange it >> so that only the performMethod >> could be overridden. Overriding clean() and clear() might disable >> the list management >> and reduce the robustness. >> >> I'll take another look, I was most concerned with simplicity, but if >> the overhead for the number >> of the objects is a concern that can be traded off against a more >> complex implementation. >> >> Thanks, Roger >> >>> >>> Regards, Peter >>> >>> >>> On 10/01/2015 04:12 PM, Roger Riggs wrote: >>>> Please review a proposal for public Cleaner API: >>>> >>>> A Cleaner is proposed to provide an easy to use alternative to >>>> finalization. The service would provide easy registration and >>>> cancellation of cleanup functions for objects. Applications create >>>> a cleanup service for their own use and the service terminates when >>>> it is no longer in use. >>>> >>>> Finalization has a long history of issues both in usage and >>>> performance. PhantomReferences have been proposed as the >>>> alternative GC based mechanism for cleaning functions but it has >>>> been left as an exercise to the developer to construct the >>>> necessary mechanisms to handle ReferenceQueues, handle threading >>>> issues and robust termination. >>>> >>>> The Cleaner performs cleaning functions when objects are >>>> unreachable as found by garbage collection using the existing >>>> mechanisms of PhantomReference, WeakReference, SoftReferences, and >>>> ReferenceQueues. It manages a thread that dequeues references to >>>> unreachable objects and invokes the corresponding cleaning >>>> function. Registered cleaning functions can be cleared if no longer >>>> needed, can be invoked explicitly to perform the cleanup >>>> immediately, or be invoked when the object is not reachable (as >>>> detected by garbage collection) and handled by a cleanup thread. >>>> >>>> The java.lang.ref package is proposed for the Cleaner because it is >>>> complementary to the reference classes and reference queues and to >>>> make it easy to find. >>>> >>>> It is not a goal to replace all uses of finalization or >>>> sun.misc.Cleaner in the JDK. >>>> Investigation will evaluate if and in what cases the Cleaner can >>>> replace finalization. >>>> A subsequent task will examine uses of finalization and propose >>>> specific changes >>>> on a case by base basis. >>>> >>>> Please review and comment: >>>> >>>> Javadoc: >>>> http://cr.openjdk.java.net/~rriggs/cleaner-doc/ >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8138696 >>>> >>>> Thanks, Roger >>>> >>> >> > From gil at azulsystems.com Tue Oct 6 15:26:31 2015 From: gil at azulsystems.com (Gil Tene) Date: Tue, 6 Oct 2015 15:26:31 +0000 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <6882C9A35DFB9B4FA2779F7BF5B9757D2083639C97@GSCMAMP06EX.firmwide.corp.gs.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <56123B47.4070706@oracle.com> <9FD5F6D1-2875-469C-B4C1-5F7ED0740084@azulsystems.com> <56138372.7050107@redhat.com> <A8FD2B97-945B-4BE6-862A-777FD7F4ADDC@azulsystems.com> <6882C9A35DFB9B4FA2779F7BF5B9757D2083639C97@GSCMAMP06EX.firmwide.corp.gs.com> Message-ID: <9A739B8F-EB55-45C5-806B-D17C48168446@azulsystems.com> > On Oct 6, 2015, at 7:54 AM, Rezaei, Mohammad A. <Mohammad.Rezaei at gs.com> wrote: > > Thread.yield(), Thread.sleep(), Thread.spinLoopHint()? That's probably a good place, especially since it doesn't add a new class. Will need feedback about the concerns of adding methods to existing commonly used classes though. E.g. with non-static methods (which this isn't) there is often the "what if someone already has a xyz() method in a subclass" concern. Less of an issue with static methods. > Somehow, it feels right (as in consistent), but also off at the same time (as in, why are these on Thread). > > I'd take consistent over bespoke-one-static-method-class, unless there was a concerted effort to consolidate other related api/concerns. > > Thanks > Moh > >> -----Original Message----- >> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf >> Of Gil Tene >> Sent: Tuesday, October 06, 2015 10:05 AM >> To: Andrew Haley >> Cc: hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net >> Subject: Re: Spin Loop Hint support: Draft JEP proposal >> >> >> >> Sent from Gil's iPhone >> >>> On Oct 6, 2015, at 1:16 AM, Andrew Haley <aph at redhat.com> wrote: >>> >>>> On 06/10/15 05:32, Gil Tene wrote: >>>> >>>> I don't think of this as platform specific. And it's not much lower >>>> level than e.g. some java.util.concurrent stuff (but probably >>>> doesn't belong in that package because it's not really about >>>> concurrency). I'm looking for a proper Java SE spec'ed way to do >>>> this. So sun.misc.* won't work. I'm sure we don't want another >>>> Unsafe for people to abuse... >>>> >>>> But naming the class and method is the smaller, easier detail. Right? ;-) >>> >>> Sure. I would have thought, though, that java.util.concurrent was a >>> natural home for this. Is there any kind of userland spinlock which >>> is not about concurrency? >> >> The same can be asked about Thread.notify(). >> >> To me, spinKoopHint() fits in (as in "probably a method in the same class") >> with other performance-oriented hints. Like prefetch variants (which we don't >> have but also probably need. E.g. prefetchWithIntentToWrite()). And placing >> prefetch hints in j.u.c would not make much sense. From peter.levart at gmail.com Tue Oct 6 15:38:43 2015 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 6 Oct 2015 17:38:43 +0200 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5613E54C.1040202@gmail.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613E54C.1040202@gmail.com> Message-ID: <5613EB03.8090200@gmail.com> On 10/06/2015 05:14 PM, Peter Levart wrote: > Hi Roger, > > This looks nice. Javadocs (in particular mine) will need some work > though. I agree that clear() and clean() implementations are final so > that subclasses can not interfere with (de)registration. Perhaps the > same could be done to isEnqueued() and enqueue() so that subclasses > would not be able to pretend they can do something about those > methods. I think the xxxCleanableList fields in CleanerImpl can be > wildcard typed: XxxCleanableReference<?> xxxCleanableList = ... The > same can be done to prev/next fields in XxxxCleanableReference classes > and to local "list" variables in insert()/remove() methods. Unsafe > casts and @SuppressWarnings annotations can then be removed. > > Regards, Peter On a second thought: Is it really necessary to prevent access to enqueue() and isEnqueued() functionality in public XxxCleanableReference classes? These methods are harmless and enqueue() might actually be useful in situations where one wants to call it instead of clean(). The difference being that clean() does the cleanup synchronously in the invoking thread while enqueue() does it asynchronously in the Cleaner's thread. The only doubt I have is that making isEnqueued()/enqueue() accessible forces internal implementation be based based on ReferenceQueue(s), but in the future it needn't be if some more performant mechanism is introduced for XxxxCleanableReference(s). Maybe, if asynchronous early cleanup is a desired feature, new method could be added: Cleanable.cleanAsync() which would delegate to super.enqueue() in current XxxxCleanableReference(s) while access to isEnqueued()/enqueue() methods would still be prevented... Regards, Peter > > On 10/06/2015 12:11 AM, Roger Riggs wrote: >> Hi, >> >> Building on Peter's code to provide subclassable CleanableReferences, >> I rearranged >> the implementation a bit to make it easier to maintain. >> The CleanableReferences subclasses are nested inside the Cleaner to >> make the scoping clear. >> >> Please review and comment: >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-extensible-8138696/ >> >> javadoc: >> http://cr.openjdk.java.net/~rriggs/cleaner-doc2/ >> >> Thanks, Roger >> >> >> >> On 10/2/2015 11:34 AM, Roger Riggs wrote: >>> Hi Peter, >>> >>> Great comments, thanks for looking into this... >>> >>> On 10/2/2015 7:52 AM, Peter Levart wrote: >>>> Hi Roger, >>>> >>>> This is a nice and clean API. I like the trick with embedding a >>>> private CleanerImpl in Cleaner and registering Cleaner itself as a >>>> tracked object so that automatic thread termination can be >>>> performed in a safe manner. You say the scope of this is not to >>>> replace internal usages of sun.misc.Cleaner. But if they ever get >>>> replaced, there are two differences between the implementations to >>>> note: >>>> >>>> - sun.misc.Cleaner thunks get executed by a ReferenceHandler thread >>>> directly and bypass ReferenceQueue-ing. This might be OK for >>>> internal use, but not appropriate for public API. I doubt this >>>> sun.misc.Cleaner exception in ReferenceHandler is necessary though. >>>> - With sun.misc.Cleaner one has to create a minimum of 2 additional >>>> objects per tracked object: the Cleaner object and a Runnable >>>> thunk. This API requires creation of 3 objects per tracked object: >>>> the Cleanup object, the internal Reference object and a Runnable >>>> thunk. >>>> >>>> Do you think Cleaner will not be used in scenarios where this >>>> additional footprint matters? >>> I don't have any particular data on that point. When used with >>> lambda or method references for >>> the thunk, it is likely there will be some binding overhead. >>>> >>>> It might be possible to merge the roles of Cleanup and Reference >>>> into one object, like this: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Cleaner/Cleaner.java >>>> >>>> Making Cleanup an interface, internal Reference(s) can implement >>>> it. One can cast a Cleanup instance to a Reference and invoke it's >>>> other methods, but this can be prevented by throwing >>>> UnsupportedOperationException from them, so nobody is tempted to >>>> employ this implementation detail. >>> >>> I prototyped a similar implementation but backed it out due to the >>> code duplication and complexity. >>> It also seemed a poor choice to break the contract of Reference by >>> throwing UnsupportedOperationException >>> on the unneeded but exposed methods since they could not be >>> completely encapsulated. >>> It seemed cleaner to have only a concrete type that was exposed to >>> the clients. >>> >>> BTW, the code in you cleaner might be simpler if the cleaner lists >>> for each of the three types were separate. >>> (The entries don't need to be intermixed). That could simplify the >>> virtual next/prev access but would still be >>> duplicating the linked list management code). >>> There could be multiple insertXXX methods so the casts were not >>> necessary. >>> >>>> >>>> There might be utility in exposing Cleanup (or better named >>>> Cleanable) References as public abstract classes so that a >>>> footprint sensitive application (for example in a data structure >>>> with many elements) is possible. By subclassing such an abstract >>>> reference and implementing the abstract method, a single object is >>>> required per tracked object. Here I derived a proof of concept from >>>> your code: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Cleaner/webrev.01/ >>>> >>>> The simple API is unchanged and there is additional low-level API >>>> that can be used if footprint matters. >>>> >>>> What do you think? >>> >>> I see what you're getting at. I would probably try to rearrange it >>> so that only the performMethod >>> could be overridden. Overriding clean() and clear() might disable >>> the list management >>> and reduce the robustness. >>> >>> I'll take another look, I was most concerned with simplicity, but if >>> the overhead for the number >>> of the objects is a concern that can be traded off against a more >>> complex implementation. >>> >>> Thanks, Roger >>> >>>> >>>> Regards, Peter >>>> >>>> >>>> On 10/01/2015 04:12 PM, Roger Riggs wrote: >>>>> Please review a proposal for public Cleaner API: >>>>> >>>>> A Cleaner is proposed to provide an easy to use alternative to >>>>> finalization. The service would provide easy registration and >>>>> cancellation of cleanup functions for objects. Applications create >>>>> a cleanup service for their own use and the service terminates >>>>> when it is no longer in use. >>>>> >>>>> Finalization has a long history of issues both in usage and >>>>> performance. PhantomReferences have been proposed as the >>>>> alternative GC based mechanism for cleaning functions but it has >>>>> been left as an exercise to the developer to construct the >>>>> necessary mechanisms to handle ReferenceQueues, handle threading >>>>> issues and robust termination. >>>>> >>>>> The Cleaner performs cleaning functions when objects are >>>>> unreachable as found by garbage collection using the existing >>>>> mechanisms of PhantomReference, WeakReference, SoftReferences, and >>>>> ReferenceQueues. It manages a thread that dequeues references to >>>>> unreachable objects and invokes the corresponding cleaning >>>>> function. Registered cleaning functions can be cleared if no >>>>> longer needed, can be invoked explicitly to perform the cleanup >>>>> immediately, or be invoked when the object is not reachable (as >>>>> detected by garbage collection) and handled by a cleanup thread. >>>>> >>>>> The java.lang.ref package is proposed for the Cleaner because it >>>>> is complementary to the reference classes and reference queues and >>>>> to make it easy to find. >>>>> >>>>> It is not a goal to replace all uses of finalization or >>>>> sun.misc.Cleaner in the JDK. >>>>> Investigation will evaluate if and in what cases the Cleaner can >>>>> replace finalization. >>>>> A subsequent task will examine uses of finalization and propose >>>>> specific changes >>>>> on a case by base basis. >>>>> >>>>> Please review and comment: >>>>> >>>>> Javadoc: >>>>> http://cr.openjdk.java.net/~rriggs/cleaner-doc/ >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>>>> >>>>> Issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8138696 >>>>> >>>>> Thanks, Roger >>>>> >>>> >>> >> > From ivan.gerasimov at oracle.com Tue Oct 6 15:48:48 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 6 Oct 2015 18:48:48 +0300 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <5613D394.6030006@Oracle.com> References: <5613D01F.3000107@Oracle.com> <5613D26B.2000407@oracle.com> <5613D394.6030006@Oracle.com> Message-ID: <5613ED60.803@oracle.com> On 06.10.2015 16:58, Roger Riggs wrote: > Hi Ivan, > > Easy enough, but I have not surveyed the codebase to see if it would > be used or is necessary. > Most of the cases I've seen are simple if/then/else or ?: expressions. > I found a few possible candidates with grep: share/classes/java/net/InetSocketAddress.java: addr == null ? InetAddress.anyLocalAddress() : addr, ==> Objects.nonNull(addr, InetAddress::anyLocalAddress) share/classes/java/net/InetAddress.java: throw ex == null ? new UnknownHostException(host) : ex; ==> throw Objects.nonNull(ex, () -> new UnknownHostException(host)) share/classes/java/util/TreeMap.java: value = (defaultVal != null ? defaultVal : (V) str.readObject()); ==> value = Objects.nonNull(defaultVal, () -> (V) str.readObject()) share/classes/java/time/format/DateTimeFormatter.java: ParsePosition pos = (position != null ? position : new ParsePosition(0)); ==> ParsePosition pos = Objects.nonNull(position, () -> new ParsePosition(0) etc. I'm not sure, though, they should be really changed, as using this nonNull() method doesn't really make the code shorter. My point is that if someone wants to use Objects.nonNull() in a case, where the second argument is calculated, it would be better to provide her with that additional variant with Supplier. Sincerely yours, Ivan > Using the Supplier for does have some extra overhead not readily > observable in the code. > There is precedent for such a method in requireNonNull, where the cost > of composing/formatting > the exception text can be avoided using a supplier. > > Roger > > > On 10/6/2015 9:53 AM, Ivan Gerasimov wrote: >> Hi Roger! >> >> I didn't notice the message, so first commented in the Jira. >> >> Would it make sense to also add a variant with the second argument of >> type Supplier, so that it can be lazily calculated only if needed? >> Something like: >> public static <T> T nonNull(T obj, Supplier<T> nullDefaultSupplier) { >> return (obj != null) ? obj : nullDefaultSupplier.get(); >> } >> >> Sincerely yours, >> Ivan >> >> On 06.10.2015 16:43, Roger Riggs wrote: >>> Java.lang.Objects contains a number of convenience methods to make >>> it easier to handle references that are null. >>> For example, toString(obj, nullDefault), >>> >>> A new method is proposed to return the reference or a default value >>> if the reference is null. >>> static <T> T nonNull(T obj, T nullDefault); >>> >>> Alternatives to the method name include >>> nonNullOrElse ( using the java.util.Optional name pattern) or >>> nonNullOrDefault >>> >>> Please review and comment. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8138963 >>> >>> Thanks, Roger >>> >>> >> > From pbenedict at apache.org Tue Oct 6 15:53:35 2015 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 6 Oct 2015 10:53:35 -0500 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <5613ED60.803@oracle.com> References: <5613D01F.3000107@Oracle.com> <5613D26B.2000407@oracle.com> <5613D394.6030006@Oracle.com> <5613ED60.803@oracle.com> Message-ID: <CABLGb9yNdB+76BC4jkDxZ6VEKR-ZddvEEztBPS6s7_+QywUkVw@mail.gmail.com> In the database world, the function is COALESCE. And it's not just two arguments but the first non-null argument of any items. I would go with firstNonNull(Object a, Object b) and then provide an overload for a vararg. Cheers, Paul On Tue, Oct 6, 2015 at 10:48 AM, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote: > > On 06.10.2015 16:58, Roger Riggs wrote: > >> Hi Ivan, >> >> Easy enough, but I have not surveyed the codebase to see if it would be >> used or is necessary. >> Most of the cases I've seen are simple if/then/else or ?: expressions. >> >> I found a few possible candidates with grep: > > share/classes/java/net/InetSocketAddress.java: addr == null ? > InetAddress.anyLocalAddress() : addr, > ==> Objects.nonNull(addr, InetAddress::anyLocalAddress) > > share/classes/java/net/InetAddress.java: throw ex == null ? new > UnknownHostException(host) : ex; > ==> throw Objects.nonNull(ex, () -> new UnknownHostException(host)) > > share/classes/java/util/TreeMap.java: value = (defaultVal != > null ? defaultVal : (V) str.readObject()); > ==> value = > Objects.nonNull(defaultVal, () -> (V) str.readObject()) > > share/classes/java/time/format/DateTimeFormatter.java: ParsePosition pos = > (position != null ? position : new ParsePosition(0)); > ==> ParsePosition pos = Objects.nonNull(position, () -> new > ParsePosition(0) > etc. > > I'm not sure, though, they should be really changed, as using this > nonNull() method doesn't really make the code shorter. > > My point is that if someone wants to use Objects.nonNull() in a case, > where the second argument is calculated, it would be better to provide her > with that additional variant with Supplier. > > Sincerely yours, > Ivan > > Using the Supplier for does have some extra overhead not readily >> observable in the code. >> There is precedent for such a method in requireNonNull, where the cost of >> composing/formatting >> the exception text can be avoided using a supplier. >> >> Roger >> >> >> On 10/6/2015 9:53 AM, Ivan Gerasimov wrote: >> >>> Hi Roger! >>> >>> I didn't notice the message, so first commented in the Jira. >>> >>> Would it make sense to also add a variant with the second argument of >>> type Supplier, so that it can be lazily calculated only if needed? >>> Something like: >>> public static <T> T nonNull(T obj, Supplier<T> nullDefaultSupplier) { >>> return (obj != null) ? obj : nullDefaultSupplier.get(); >>> } >>> >>> Sincerely yours, >>> Ivan >>> >>> On 06.10.2015 16:43, Roger Riggs wrote: >>> >>>> Java.lang.Objects contains a number of convenience methods to make it >>>> easier to handle references that are null. >>>> For example, toString(obj, nullDefault), >>>> >>>> A new method is proposed to return the reference or a default value if >>>> the reference is null. >>>> static <T> T nonNull(T obj, T nullDefault); >>>> >>>> Alternatives to the method name include >>>> nonNullOrElse ( using the java.util.Optional name pattern) or >>>> nonNullOrDefault >>>> >>>> Please review and comment. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8138963 >>>> >>>> Thanks, Roger >>>> >>>> >>>> >>> >> > From peter.levart at gmail.com Tue Oct 6 16:06:54 2015 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 6 Oct 2015 18:06:54 +0200 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5612F582.4050909@Oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> Message-ID: <5613F19E.7010708@gmail.com> Hi Roger (again, sorry)! I think I found a race in the implementation which could leave the Cleaner thread run forever: 238 public void run() { 239 Thread t = Thread.currentThread(); 240 ManagedLocalsThread mlThread = (t instanceof ManagedLocalsThread) 241 ? (ManagedLocalsThread)t 242 : null; 243 while (!phantomCleanableList.isEmpty() || 244 !weakCleanableList.isEmpty() || 245 !softCleanableList.isEmpty()) { 246 if (mlThread != null) { 247 // Cleanable the thread locals 248 mlThread.eraseThreadLocals(); 249 } 250 try { 251 Cleanable ref = (Cleanable) queue.remove(); 252 ref.clean(); 253 } catch (InterruptedException i) { 254 continue; // ignore the interruption 255 } catch (Throwable e) { 256 // ignore exceptions from the cleanup thunk 257 } 258 } 259 } Suppose the Cleaner instance has already been collected and it's associated PhantomCleanableRef has already been removed from phantomCleanableList. Let weakCleanableList and softCleanableList be (already) empty too. Let there be some last PhantomCleanableRefefence in the phantomCleanableList. while condition is therefore true, so the Cleaner thread enters loop and blocks at queue.remove(). Now some user thread clean()s or clear()s the remaining PhantomCleanableRefefence before it's referent is found phantom reachable by GC and removes the Reference from the list. This reference will never be enqueued by GC+ReferenceHandler, so queue.remove() will block forever. The simplest fix would be to use a remove() with a timeout in this situation. Regards, Peter On 10/06/2015 12:11 AM, Roger Riggs wrote: > Hi, > > Building on Peter's code to provide subclassable CleanableReferences, > I rearranged > the implementation a bit to make it easier to maintain. > The CleanableReferences subclasses are nested inside the Cleaner to > make the scoping clear. > > Please review and comment: > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-cleaner-extensible-8138696/ > > javadoc: > http://cr.openjdk.java.net/~rriggs/cleaner-doc2/ > > Thanks, Roger > > > > On 10/2/2015 11:34 AM, Roger Riggs wrote: >> Hi Peter, >> >> Great comments, thanks for looking into this... >> >> On 10/2/2015 7:52 AM, Peter Levart wrote: >>> Hi Roger, >>> >>> This is a nice and clean API. I like the trick with embedding a >>> private CleanerImpl in Cleaner and registering Cleaner itself as a >>> tracked object so that automatic thread termination can be performed >>> in a safe manner. You say the scope of this is not to replace >>> internal usages of sun.misc.Cleaner. But if they ever get replaced, >>> there are two differences between the implementations to note: >>> >>> - sun.misc.Cleaner thunks get executed by a ReferenceHandler thread >>> directly and bypass ReferenceQueue-ing. This might be OK for >>> internal use, but not appropriate for public API. I doubt this >>> sun.misc.Cleaner exception in ReferenceHandler is necessary though. >>> - With sun.misc.Cleaner one has to create a minimum of 2 additional >>> objects per tracked object: the Cleaner object and a Runnable thunk. >>> This API requires creation of 3 objects per tracked object: the >>> Cleanup object, the internal Reference object and a Runnable thunk. >>> >>> Do you think Cleaner will not be used in scenarios where this >>> additional footprint matters? >> I don't have any particular data on that point. When used with >> lambda or method references for >> the thunk, it is likely there will be some binding overhead. >>> >>> It might be possible to merge the roles of Cleanup and Reference >>> into one object, like this: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Cleaner/Cleaner.java >>> >>> Making Cleanup an interface, internal Reference(s) can implement it. >>> One can cast a Cleanup instance to a Reference and invoke it's other >>> methods, but this can be prevented by throwing >>> UnsupportedOperationException from them, so nobody is tempted to >>> employ this implementation detail. >> >> I prototyped a similar implementation but backed it out due to the >> code duplication and complexity. >> It also seemed a poor choice to break the contract of Reference by >> throwing UnsupportedOperationException >> on the unneeded but exposed methods since they could not be >> completely encapsulated. >> It seemed cleaner to have only a concrete type that was exposed to >> the clients. >> >> BTW, the code in you cleaner might be simpler if the cleaner lists >> for each of the three types were separate. >> (The entries don't need to be intermixed). That could simplify the >> virtual next/prev access but would still be >> duplicating the linked list management code). >> There could be multiple insertXXX methods so the casts were not >> necessary. >> >>> >>> There might be utility in exposing Cleanup (or better named >>> Cleanable) References as public abstract classes so that a footprint >>> sensitive application (for example in a data structure with many >>> elements) is possible. By subclassing such an abstract reference and >>> implementing the abstract method, a single object is required per >>> tracked object. Here I derived a proof of concept from your code: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Cleaner/webrev.01/ >>> >>> The simple API is unchanged and there is additional low-level API >>> that can be used if footprint matters. >>> >>> What do you think? >> >> I see what you're getting at. I would probably try to rearrange it >> so that only the performMethod >> could be overridden. Overriding clean() and clear() might disable >> the list management >> and reduce the robustness. >> >> I'll take another look, I was most concerned with simplicity, but if >> the overhead for the number >> of the objects is a concern that can be traded off against a more >> complex implementation. >> >> Thanks, Roger >> >>> >>> Regards, Peter >>> >>> >>> On 10/01/2015 04:12 PM, Roger Riggs wrote: >>>> Please review a proposal for public Cleaner API: >>>> >>>> A Cleaner is proposed to provide an easy to use alternative to >>>> finalization. The service would provide easy registration and >>>> cancellation of cleanup functions for objects. Applications create >>>> a cleanup service for their own use and the service terminates when >>>> it is no longer in use. >>>> >>>> Finalization has a long history of issues both in usage and >>>> performance. PhantomReferences have been proposed as the >>>> alternative GC based mechanism for cleaning functions but it has >>>> been left as an exercise to the developer to construct the >>>> necessary mechanisms to handle ReferenceQueues, handle threading >>>> issues and robust termination. >>>> >>>> The Cleaner performs cleaning functions when objects are >>>> unreachable as found by garbage collection using the existing >>>> mechanisms of PhantomReference, WeakReference, SoftReferences, and >>>> ReferenceQueues. It manages a thread that dequeues references to >>>> unreachable objects and invokes the corresponding cleaning >>>> function. Registered cleaning functions can be cleared if no longer >>>> needed, can be invoked explicitly to perform the cleanup >>>> immediately, or be invoked when the object is not reachable (as >>>> detected by garbage collection) and handled by a cleanup thread. >>>> >>>> The java.lang.ref package is proposed for the Cleaner because it is >>>> complementary to the reference classes and reference queues and to >>>> make it easy to find. >>>> >>>> It is not a goal to replace all uses of finalization or >>>> sun.misc.Cleaner in the JDK. >>>> Investigation will evaluate if and in what cases the Cleaner can >>>> replace finalization. >>>> A subsequent task will examine uses of finalization and propose >>>> specific changes >>>> on a case by base basis. >>>> >>>> Please review and comment: >>>> >>>> Javadoc: >>>> http://cr.openjdk.java.net/~rriggs/cleaner-doc/ >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8138696 >>>> >>>> Thanks, Roger >>>> >>> >> > From stuart.marks at oracle.com Tue Oct 6 17:03:34 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 6 Oct 2015 10:03:34 -0700 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <CACzrW9C2bomoiA+hQcq6=H7QvMuBu2c7wmOGYHwq31b6Z=M18A@mail.gmail.com> References: <5613D01F.3000107@Oracle.com> <CACzrW9CHGGpcDGQh2FoeFwgTwXr1besNdt42L3+RE6Cy7jPMLg@mail.gmail.com> <5613D635.6000305@Oracle.com> <CACzrW9C2bomoiA+hQcq6=H7QvMuBu2c7wmOGYHwq31b6Z=M18A@mail.gmail.com> Message-ID: <5613FEE6.2010907@oracle.com> I agree that with Stephen that Guava's semantics of disallowing a null default are preferable. It would seem very odd if a method that has "nonNull" in its name is allowed to return null. It seems to me that the point of this and related methods is to provide a fluent way for a class to separate the nullable world outside with the non-nullable world inside. Thus, void setValue(T arg) { // arg is nullable field = Objects.firstNonNull(arg, DEFAULT_VALUE_FOR_FIELD); assert field != null; } If the default value can be null, why bother checking arg at all? It seems to me that it's a programming error if the default value is null, so this should be checked. * * * As an aside I notice that Guava's Objects.firstNonNull() is deprecated, with a recommended replacement of MoreObjects.firstNonNull(). [1] The semantics are the same, though, as far as I can see. I'm curious as to what's going here, though. [1] http://google.github.io/guava/releases/18.0/api/docs/ s'marks On 10/6/15 7:15 AM, Stephen Colebourne wrote: > What the existing code does would seem to be irrelevant. What is > important is deciding what the correct semantics should be for a core > method on Objects. > > If there a desperate need for the webrev semantics, how about two methods? > > firstNonNull(a, b) - result must not be null > firstOrElse(a, b) - result is null only is b is null > > (although I struggle to see much point in the latter) > > Stephen > > > > > On 6 October 2015 at 15:09, Roger Riggs <Roger.Riggs at oracle.com> wrote: >> Hi Stephen, >> >> Guava's firstNonNull is a useful semantic, but would not be a drop in >> replacement for existing code which >> would need to be examined for behavioral changes due to possibly throwing an >> exception. >> So perhaps the nonNullorElse name would be more accurate. >> >> Thanks, Roger >> >> >> >> On 10/6/2015 10:00 AM, Stephen Colebourne wrote: >>> >>> Guava uses firstNonNull(a, b). It ensures that the result is never >>> null, by checking that b is not null. >>> I think the semantics of Guava's method is correct. I tend to think >>> the method name isn't bad either. >>> >>> Calling it nonNull(Object,Object) clashes with the existing >>> nonNull(Object) method. Those two have nothing much to do with each >>> other. >>> >>> Stephen >>> >>> >>> On 6 October 2015 at 14:43, Roger Riggs <Roger.Riggs at oracle.com> wrote: >>>> >>>> Java.lang.Objects contains a number of convenience methods to make it >>>> easier >>>> to handle references that are null. >>>> For example, toString(obj, nullDefault), >>>> >>>> A new method is proposed to return the reference or a default value if >>>> the >>>> reference is null. >>>> static <T> T nonNull(T obj, T nullDefault); >>>> >>>> Alternatives to the method name include >>>> nonNullOrElse ( using the java.util.Optional name pattern) or >>>> nonNullOrDefault >>>> >>>> Please review and comment. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8138963 >>>> >>>> Thanks, Roger >>>> >> From lowasser at google.com Tue Oct 6 17:09:01 2015 From: lowasser at google.com (Louis Wasserman) Date: Tue, 06 Oct 2015 17:09:01 +0000 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <5613FEE6.2010907@oracle.com> References: <5613D01F.3000107@Oracle.com> <CACzrW9CHGGpcDGQh2FoeFwgTwXr1besNdt42L3+RE6Cy7jPMLg@mail.gmail.com> <5613D635.6000305@Oracle.com> <CACzrW9C2bomoiA+hQcq6=H7QvMuBu2c7wmOGYHwq31b6Z=M18A@mail.gmail.com> <5613FEE6.2010907@oracle.com> Message-ID: <CAGB9EW-q9DKn1aoCh2kOqG6E74KohKJYv5_kfyg5sp298=1peg@mail.gmail.com> > As an aside I notice that Guava's Objects.firstNonNull() is deprecated, with a recommended replacement of MoreObjects.firstNonNull(). [1] The semantics are the same, though, as far as I can see. I'm curious as to what's going here, though. Guava is moving from Objects to MoreObjects because the JDK added an Objects class, and Guava wanted to avoid naming conflicts with the JDK. On Tue, Oct 6, 2015 at 10:03 AM Stuart Marks <stuart.marks at oracle.com> wrote: > I agree that with Stephen that Guava's semantics of disallowing a null > default > are preferable. It would seem very odd if a method that has "nonNull" in > its > name is allowed to return null. > > It seems to me that the point of this and related methods is to provide a > fluent > way for a class to separate the nullable world outside with the > non-nullable > world inside. Thus, > > void setValue(T arg) { // arg is nullable > field = Objects.firstNonNull(arg, DEFAULT_VALUE_FOR_FIELD); > assert field != null; > } > > If the default value can be null, why bother checking arg at all? It seems > to me > that it's a programming error if the default value is null, so this should > be > checked. > > * * * > > As an aside I notice that Guava's Objects.firstNonNull() is deprecated, > with a > recommended replacement of MoreObjects.firstNonNull(). [1] The semantics > are the > same, though, as far as I can see. I'm curious as to what's going here, > though. > > [1] http://google.github.io/guava/releases/18.0/api/docs/ > > s'marks > > > > On 10/6/15 7:15 AM, Stephen Colebourne wrote: > > What the existing code does would seem to be irrelevant. What is > > important is deciding what the correct semantics should be for a core > > method on Objects. > > > > If there a desperate need for the webrev semantics, how about two > methods? > > > > firstNonNull(a, b) - result must not be null > > firstOrElse(a, b) - result is null only is b is null > > > > (although I struggle to see much point in the latter) > > > > Stephen > > > > > > > > > > On 6 October 2015 at 15:09, Roger Riggs <Roger.Riggs at oracle.com> wrote: > >> Hi Stephen, > >> > >> Guava's firstNonNull is a useful semantic, but would not be a drop in > >> replacement for existing code which > >> would need to be examined for behavioral changes due to possibly > throwing an > >> exception. > >> So perhaps the nonNullorElse name would be more accurate. > >> > >> Thanks, Roger > >> > >> > >> > >> On 10/6/2015 10:00 AM, Stephen Colebourne wrote: > >>> > >>> Guava uses firstNonNull(a, b). It ensures that the result is never > >>> null, by checking that b is not null. > >>> I think the semantics of Guava's method is correct. I tend to think > >>> the method name isn't bad either. > >>> > >>> Calling it nonNull(Object,Object) clashes with the existing > >>> nonNull(Object) method. Those two have nothing much to do with each > >>> other. > >>> > >>> Stephen > >>> > >>> > >>> On 6 October 2015 at 14:43, Roger Riggs <Roger.Riggs at oracle.com> > wrote: > >>>> > >>>> Java.lang.Objects contains a number of convenience methods to make it > >>>> easier > >>>> to handle references that are null. > >>>> For example, toString(obj, nullDefault), > >>>> > >>>> A new method is proposed to return the reference or a default value if > >>>> the > >>>> reference is null. > >>>> static <T> T nonNull(T obj, T nullDefault); > >>>> > >>>> Alternatives to the method name include > >>>> nonNullOrElse ( using the java.util.Optional name pattern) or > >>>> nonNullOrDefault > >>>> > >>>> Please review and comment. > >>>> > >>>> Webrev: > >>>> http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ > >>>> > >>>> Issue: > >>>> https://bugs.openjdk.java.net/browse/JDK-8138963 > >>>> > >>>> Thanks, Roger > >>>> > >> > From Roger.Riggs at Oracle.com Tue Oct 6 18:05:21 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 6 Oct 2015 14:05:21 -0400 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5613EB03.8090200@gmail.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613E54C.1040202@gmail.com> <5613EB03.8090200@gmail.com> Message-ID: <56140D61.6010101@Oracle.com> Hi Peter, Thanks for the cleanup suggestions in your previous email. I do need to look at the javadoc again. On 10/6/2015 11:38 AM, Peter Levart wrote: > > > On 10/06/2015 05:14 PM, Peter Levart wrote: >> Hi Roger, >> >> This looks nice. Javadocs (in particular mine) will need some work >> though. I agree that clear() and clean() implementations are final so >> that subclasses can not interfere with (de)registration. Perhaps the >> same could be done to isEnqueued() and enqueue() so that subclasses >> would not be able to pretend they can do something about those >> methods. I think the xxxCleanableList fields in CleanerImpl can be >> wildcard typed: XxxCleanableReference<?> xxxCleanableList = ... The >> same can be done to prev/next fields in XxxxCleanableReference >> classes and to local "list" variables in insert()/remove() methods. >> Unsafe casts and @SuppressWarnings annotations can then be removed. >> >> Regards, Peter > > On a second thought: Is it really necessary to prevent access to > enqueue() and isEnqueued() functionality in public > XxxCleanableReference classes? These methods are harmless and > enqueue() might actually be useful in situations where one wants to > call it instead of clean(). The difference being that clean() does the > cleanup synchronously in the invoking thread while enqueue() does it > asynchronously in the Cleaner's thread. The only doubt I have is that > making isEnqueued()/enqueue() accessible forces internal > implementation be based based on ReferenceQueue(s), but in the future > it needn't be if some more performant mechanism is introduced for > XxxxCleanableReference(s). I think the implementation should remain as hidden/private as possible. Keeping the number of objects create to 1 necessitates subclassing the Reference types but exposing any part/any more of their behavior breaks the encapsulation. It is preferable that cleaning be as aggressive as possible, since it usually is releasing limited resources (memory or file descriptors). The application itself has other mechanisms to perform the cleanup asynchronously if that is beneficial. The ForkJoinPool for example. > Maybe, if asynchronous early cleanup is a desired feature, new method > could be added: Cleanable.cleanAsync() which would delegate to > super.enqueue() in current XxxxCleanableReference(s) while access to > isEnqueued()/enqueue() methods would still be prevented... If it is needed, it would be cleaner to expose it deliberately with a new method. Thanks, Roger > > Regards, Peter > >> >> On 10/06/2015 12:11 AM, Roger Riggs wrote: >>> Hi, >>> >>> Building on Peter's code to provide subclassable >>> CleanableReferences, I rearranged >>> the implementation a bit to make it easier to maintain. >>> The CleanableReferences subclasses are nested inside the Cleaner to >>> make the scoping clear. >>> >>> Please review and comment: >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-extensible-8138696/ >>> >>> javadoc: >>> http://cr.openjdk.java.net/~rriggs/cleaner-doc2/ >>> >>> Thanks, Roger >>> >>> >>> >>> On 10/2/2015 11:34 AM, Roger Riggs wrote: >>>> Hi Peter, >>>> >>>> Great comments, thanks for looking into this... >>>> >>>> On 10/2/2015 7:52 AM, Peter Levart wrote: >>>>> Hi Roger, >>>>> >>>>> This is a nice and clean API. I like the trick with embedding a >>>>> private CleanerImpl in Cleaner and registering Cleaner itself as a >>>>> tracked object so that automatic thread termination can be >>>>> performed in a safe manner. You say the scope of this is not to >>>>> replace internal usages of sun.misc.Cleaner. But if they ever get >>>>> replaced, there are two differences between the implementations to >>>>> note: >>>>> >>>>> - sun.misc.Cleaner thunks get executed by a ReferenceHandler >>>>> thread directly and bypass ReferenceQueue-ing. This might be OK >>>>> for internal use, but not appropriate for public API. I doubt this >>>>> sun.misc.Cleaner exception in ReferenceHandler is necessary though. >>>>> - With sun.misc.Cleaner one has to create a minimum of 2 >>>>> additional objects per tracked object: the Cleaner object and a >>>>> Runnable thunk. This API requires creation of 3 objects per >>>>> tracked object: the Cleanup object, the internal Reference object >>>>> and a Runnable thunk. >>>>> >>>>> Do you think Cleaner will not be used in scenarios where this >>>>> additional footprint matters? >>>> I don't have any particular data on that point. When used with >>>> lambda or method references for >>>> the thunk, it is likely there will be some binding overhead. >>>>> >>>>> It might be possible to merge the roles of Cleanup and Reference >>>>> into one object, like this: >>>>> >>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Cleaner/Cleaner.java >>>>> >>>>> Making Cleanup an interface, internal Reference(s) can implement >>>>> it. One can cast a Cleanup instance to a Reference and invoke it's >>>>> other methods, but this can be prevented by throwing >>>>> UnsupportedOperationException from them, so nobody is tempted to >>>>> employ this implementation detail. >>>> >>>> I prototyped a similar implementation but backed it out due to the >>>> code duplication and complexity. >>>> It also seemed a poor choice to break the contract of Reference by >>>> throwing UnsupportedOperationException >>>> on the unneeded but exposed methods since they could not be >>>> completely encapsulated. >>>> It seemed cleaner to have only a concrete type that was exposed to >>>> the clients. >>>> >>>> BTW, the code in you cleaner might be simpler if the cleaner lists >>>> for each of the three types were separate. >>>> (The entries don't need to be intermixed). That could simplify the >>>> virtual next/prev access but would still be >>>> duplicating the linked list management code). >>>> There could be multiple insertXXX methods so the casts were not >>>> necessary. >>>> >>>>> >>>>> There might be utility in exposing Cleanup (or better named >>>>> Cleanable) References as public abstract classes so that a >>>>> footprint sensitive application (for example in a data structure >>>>> with many elements) is possible. By subclassing such an abstract >>>>> reference and implementing the abstract method, a single object is >>>>> required per tracked object. Here I derived a proof of concept >>>>> from your code: >>>>> >>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Cleaner/webrev.01/ >>>>> >>>>> The simple API is unchanged and there is additional low-level API >>>>> that can be used if footprint matters. >>>>> >>>>> What do you think? >>>> >>>> I see what you're getting at. I would probably try to rearrange it >>>> so that only the performMethod >>>> could be overridden. Overriding clean() and clear() might disable >>>> the list management >>>> and reduce the robustness. >>>> >>>> I'll take another look, I was most concerned with simplicity, but >>>> if the overhead for the number >>>> of the objects is a concern that can be traded off against a more >>>> complex implementation. >>>> >>>> Thanks, Roger >>>> >>>>> >>>>> Regards, Peter >>>>> >>>>> >>>>> On 10/01/2015 04:12 PM, Roger Riggs wrote: >>>>>> Please review a proposal for public Cleaner API: >>>>>> >>>>>> A Cleaner is proposed to provide an easy to use alternative to >>>>>> finalization. The service would provide easy registration and >>>>>> cancellation of cleanup functions for objects. Applications >>>>>> create a cleanup service for their own use and the service >>>>>> terminates when it is no longer in use. >>>>>> >>>>>> Finalization has a long history of issues both in usage and >>>>>> performance. PhantomReferences have been proposed as the >>>>>> alternative GC based mechanism for cleaning functions but it has >>>>>> been left as an exercise to the developer to construct the >>>>>> necessary mechanisms to handle ReferenceQueues, handle threading >>>>>> issues and robust termination. >>>>>> >>>>>> The Cleaner performs cleaning functions when objects are >>>>>> unreachable as found by garbage collection using the existing >>>>>> mechanisms of PhantomReference, WeakReference, SoftReferences, >>>>>> and ReferenceQueues. It manages a thread that dequeues references >>>>>> to unreachable objects and invokes the corresponding cleaning >>>>>> function. Registered cleaning functions can be cleared if no >>>>>> longer needed, can be invoked explicitly to perform the cleanup >>>>>> immediately, or be invoked when the object is not reachable (as >>>>>> detected by garbage collection) and handled by a cleanup thread. >>>>>> >>>>>> The java.lang.ref package is proposed for the Cleaner because it >>>>>> is complementary to the reference classes and reference queues >>>>>> and to make it easy to find. >>>>>> >>>>>> It is not a goal to replace all uses of finalization or >>>>>> sun.misc.Cleaner in the JDK. >>>>>> Investigation will evaluate if and in what cases the Cleaner can >>>>>> replace finalization. >>>>>> A subsequent task will examine uses of finalization and propose >>>>>> specific changes >>>>>> on a case by base basis. >>>>>> >>>>>> Please review and comment: >>>>>> >>>>>> Javadoc: >>>>>> http://cr.openjdk.java.net/~rriggs/cleaner-doc/ >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>>>>> >>>>>> Issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8138696 >>>>>> >>>>>> Thanks, Roger >>>>>> >>>>> >>>> >>> >> > From Roger.Riggs at Oracle.com Tue Oct 6 18:20:55 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 6 Oct 2015 14:20:55 -0400 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5613F19E.7010708@gmail.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> Message-ID: <56141107.8000407@Oracle.com> Hi Peter, Well spotted, the timeout is the easiest solution, and it will happen infrequently. The timeout can be quite long to avoid a 'polling' tax. Perhaps 60 seconds. Thanks, Roger On 10/6/2015 12:06 PM, Peter Levart wrote: > Hi Roger (again, sorry)! > > I think I found a race in the implementation which could leave the > Cleaner thread run forever: > > 238 public void run() { > 239 Thread t = Thread.currentThread(); > 240 ManagedLocalsThread mlThread = (t instanceof > ManagedLocalsThread) > 241 ? (ManagedLocalsThread)t > 242 : null; > 243 while (!phantomCleanableList.isEmpty() || > 244 !weakCleanableList.isEmpty() || > 245 !softCleanableList.isEmpty()) { > 246 if (mlThread != null) { > 247 // Cleanable the thread locals > 248 mlThread.eraseThreadLocals(); > 249 } > 250 try { > 251 Cleanable ref = (Cleanable) queue.remove(); > 252 ref.clean(); > 253 } catch (InterruptedException i) { > 254 continue; // ignore the interruption > 255 } catch (Throwable e) { > 256 // ignore exceptions from the cleanup thunk > 257 } > 258 } > 259 } > > Suppose the Cleaner instance has already been collected and it's > associated PhantomCleanableRef has already been removed from > phantomCleanableList. Let weakCleanableList and softCleanableList be > (already) empty too. Let there be some last PhantomCleanableRefefence > in the phantomCleanableList. while condition is therefore true, so the > Cleaner thread enters loop and blocks at queue.remove(). Now some user > thread clean()s or clear()s the remaining PhantomCleanableRefefence > before it's referent is found phantom reachable by GC and removes the > Reference from the list. This reference will never be enqueued by > GC+ReferenceHandler, so queue.remove() will block forever. > > The simplest fix would be to use a remove() with a timeout in this > situation. > > Regards, Peter > > On 10/06/2015 12:11 AM, Roger Riggs wrote: >> Hi, >> >> Building on Peter's code to provide subclassable CleanableReferences, >> I rearranged >> the implementation a bit to make it easier to maintain. >> The CleanableReferences subclasses are nested inside the Cleaner to >> make the scoping clear. >> >> Please review and comment: >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-extensible-8138696/ >> >> javadoc: >> http://cr.openjdk.java.net/~rriggs/cleaner-doc2/ >> >> Thanks, Roger >> >> >> >> On 10/2/2015 11:34 AM, Roger Riggs wrote: >>> Hi Peter, >>> >>> Great comments, thanks for looking into this... >>> >>> On 10/2/2015 7:52 AM, Peter Levart wrote: >>>> Hi Roger, >>>> >>>> This is a nice and clean API. I like the trick with embedding a >>>> private CleanerImpl in Cleaner and registering Cleaner itself as a >>>> tracked object so that automatic thread termination can be >>>> performed in a safe manner. You say the scope of this is not to >>>> replace internal usages of sun.misc.Cleaner. But if they ever get >>>> replaced, there are two differences between the implementations to >>>> note: >>>> >>>> - sun.misc.Cleaner thunks get executed by a ReferenceHandler thread >>>> directly and bypass ReferenceQueue-ing. This might be OK for >>>> internal use, but not appropriate for public API. I doubt this >>>> sun.misc.Cleaner exception in ReferenceHandler is necessary though. >>>> - With sun.misc.Cleaner one has to create a minimum of 2 additional >>>> objects per tracked object: the Cleaner object and a Runnable >>>> thunk. This API requires creation of 3 objects per tracked object: >>>> the Cleanup object, the internal Reference object and a Runnable >>>> thunk. >>>> >>>> Do you think Cleaner will not be used in scenarios where this >>>> additional footprint matters? >>> I don't have any particular data on that point. When used with >>> lambda or method references for >>> the thunk, it is likely there will be some binding overhead. >>>> >>>> It might be possible to merge the roles of Cleanup and Reference >>>> into one object, like this: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Cleaner/Cleaner.java >>>> >>>> Making Cleanup an interface, internal Reference(s) can implement >>>> it. One can cast a Cleanup instance to a Reference and invoke it's >>>> other methods, but this can be prevented by throwing >>>> UnsupportedOperationException from them, so nobody is tempted to >>>> employ this implementation detail. >>> >>> I prototyped a similar implementation but backed it out due to the >>> code duplication and complexity. >>> It also seemed a poor choice to break the contract of Reference by >>> throwing UnsupportedOperationException >>> on the unneeded but exposed methods since they could not be >>> completely encapsulated. >>> It seemed cleaner to have only a concrete type that was exposed to >>> the clients. >>> >>> BTW, the code in you cleaner might be simpler if the cleaner lists >>> for each of the three types were separate. >>> (The entries don't need to be intermixed). That could simplify the >>> virtual next/prev access but would still be >>> duplicating the linked list management code). >>> There could be multiple insertXXX methods so the casts were not >>> necessary. >>> >>>> >>>> There might be utility in exposing Cleanup (or better named >>>> Cleanable) References as public abstract classes so that a >>>> footprint sensitive application (for example in a data structure >>>> with many elements) is possible. By subclassing such an abstract >>>> reference and implementing the abstract method, a single object is >>>> required per tracked object. Here I derived a proof of concept from >>>> your code: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Cleaner/webrev.01/ >>>> >>>> The simple API is unchanged and there is additional low-level API >>>> that can be used if footprint matters. >>>> >>>> What do you think? >>> >>> I see what you're getting at. I would probably try to rearrange it >>> so that only the performMethod >>> could be overridden. Overriding clean() and clear() might disable >>> the list management >>> and reduce the robustness. >>> >>> I'll take another look, I was most concerned with simplicity, but if >>> the overhead for the number >>> of the objects is a concern that can be traded off against a more >>> complex implementation. >>> >>> Thanks, Roger >>> >>>> >>>> Regards, Peter >>>> >>>> >>>> On 10/01/2015 04:12 PM, Roger Riggs wrote: >>>>> Please review a proposal for public Cleaner API: >>>>> >>>>> A Cleaner is proposed to provide an easy to use alternative to >>>>> finalization. The service would provide easy registration and >>>>> cancellation of cleanup functions for objects. Applications create >>>>> a cleanup service for their own use and the service terminates >>>>> when it is no longer in use. >>>>> >>>>> Finalization has a long history of issues both in usage and >>>>> performance. PhantomReferences have been proposed as the >>>>> alternative GC based mechanism for cleaning functions but it has >>>>> been left as an exercise to the developer to construct the >>>>> necessary mechanisms to handle ReferenceQueues, handle threading >>>>> issues and robust termination. >>>>> >>>>> The Cleaner performs cleaning functions when objects are >>>>> unreachable as found by garbage collection using the existing >>>>> mechanisms of PhantomReference, WeakReference, SoftReferences, and >>>>> ReferenceQueues. It manages a thread that dequeues references to >>>>> unreachable objects and invokes the corresponding cleaning >>>>> function. Registered cleaning functions can be cleared if no >>>>> longer needed, can be invoked explicitly to perform the cleanup >>>>> immediately, or be invoked when the object is not reachable (as >>>>> detected by garbage collection) and handled by a cleanup thread. >>>>> >>>>> The java.lang.ref package is proposed for the Cleaner because it >>>>> is complementary to the reference classes and reference queues and >>>>> to make it easy to find. >>>>> >>>>> It is not a goal to replace all uses of finalization or >>>>> sun.misc.Cleaner in the JDK. >>>>> Investigation will evaluate if and in what cases the Cleaner can >>>>> replace finalization. >>>>> A subsequent task will examine uses of finalization and propose >>>>> specific changes >>>>> on a case by base basis. >>>>> >>>>> Please review and comment: >>>>> >>>>> Javadoc: >>>>> http://cr.openjdk.java.net/~rriggs/cleaner-doc/ >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>>>> >>>>> Issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8138696 >>>>> >>>>> Thanks, Roger >>>>> >>>> >>> >> > From brian.burkhalter at oracle.com Tue Oct 6 18:26:47 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 6 Oct 2015 11:26:47 -0700 Subject: JDK 9 RFR of JDK-8138823: Correct bug in port of fdlibm hypot to Java In-Reply-To: <560F3CD7.20900@oracle.com> References: <560F3CD7.20900@oracle.com> Message-ID: <308AD43B-F276-43D4-AE85-76C7CB44C49F@oracle.com> Hi Joe, On Oct 2, 2015, at 7:26 PM, joe darcy <joe.darcy at oracle.com> wrote: > Please review the changes for > > JDK-8138823: Correct bug in port of fdlibm hypot to Java > http://cr.openjdk.java.net/~darcy/8138823.0/ > > The change to java/lang/FdLibm.java is to correct a problem analogous to one recently corrected in the port of the pow method. This looks good. > The testing includes a few improvements, including the addition of FdlibmTranslit.java to host transliteration ports of the fdlibm methods. This is a good idea. Do you think that at lines 60-64 of HypotTests it would be worth printing separate failure counts for standard versus transliteration failures? > That is, Java ports of the code that are as close to the C versions as possible while still being readable. For the code used for java.lang.StrictMath, it is desirable for the code to be faster and to be closer to idiomatic Java. Something like createRandomDouble() from StrictMath/Tests.java would not be a bad addition to j.u.Random, e.g., public double nextFullRangeDouble() {} although this is somewhat covered by Random.doubles(double,double) {}. Overall: +1. Thanks, Brian From ivan.gerasimov at oracle.com Tue Oct 6 19:28:53 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 6 Oct 2015 22:28:53 +0300 Subject: [9] [xxs] RFR 8138938: Clarify javadoc for java.util.Collections.copy() Message-ID: <561420F5.8010606@oracle.com> Hello! It was suggested that the javadoc for the java.util.Collections.copy() method can be clarified. Currently it says that the dest list must be long enough, not specifying what it means to be long. The submitter claims that it may be treated that the capacity of the list must be large enough, which is not what what was meant. The fix does not change meaning of the doc, so it should not be considered as a spec change. Would you please help review the javadoc clarification. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8138938 WEBREV: http://cr.openjdk.java.net/~igerasim/8138938/00/webrev/ Sincerely yours, Ivan From dl at cs.oswego.edu Tue Oct 6 20:02:04 2015 From: dl at cs.oswego.edu (Doug Lea) Date: Tue, 6 Oct 2015 16:02:04 -0400 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> Message-ID: <561428BC.3060806@cs.oswego.edu> On 10/04/2015 12:22 PM, Gil Tene wrote: > I would like to circulate this draft JEP proposal for initial review and consensus building purposes. > Some background: about two years ago, Dave Dice and I put together a pre-jep proposal for JVM support for recent CPU features covering: (1) MWAIT/PAUSE/etc (for spins as well as other uses people have noted); (2) Core topology/neighborhood information and; (3) 2CAS, as a foothold on HTM that could still be reasonably efficient on non-transactional processors. My understanding of the result of this effort was that Oracle JVM engineers didn't think they had resources to do this for jdk9. It didn't occur to me that non-Oracle contributors might want to cherry-pick one (some of (1) above). It seems plausible to do this, but only if designed as the first of some possible enhanced support along these lines. -Doug From stuart.marks at oracle.com Tue Oct 6 21:03:57 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 6 Oct 2015 14:03:57 -0700 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <CAGB9EW-q9DKn1aoCh2kOqG6E74KohKJYv5_kfyg5sp298=1peg@mail.gmail.com> References: <5613D01F.3000107@Oracle.com> <CACzrW9CHGGpcDGQh2FoeFwgTwXr1besNdt42L3+RE6Cy7jPMLg@mail.gmail.com> <5613D635.6000305@Oracle.com> <CACzrW9C2bomoiA+hQcq6=H7QvMuBu2c7wmOGYHwq31b6Z=M18A@mail.gmail.com> <5613FEE6.2010907@oracle.com> <CAGB9EW-q9DKn1aoCh2kOqG6E74KohKJYv5_kfyg5sp298=1peg@mail.gmail.com> Message-ID: <5614373D.90803@oracle.com> On 10/6/15 10:09 AM, Louis Wasserman wrote: > On Tue, Oct 6, 2015 at 10:03 AM Stuart Marks <stuart.marks at oracle.com > <mailto:stuart.marks at oracle.com>> wrote: >> As an aside I notice that Guava's Objects.firstNonNull() is deprecated, with a >> recommended replacement of MoreObjects.firstNonNull(). [1] The semantics are the >> same, though, as far as I can see. I'm curious as to what's going here, though. > Guava is moving from Objects to MoreObjects because the JDK added an Objects > class, and Guava wanted to avoid naming conflicts with the JDK. Thanks for the quick response, Louis. We'll make sure not to add a MoreObjects class to the JDK. :-) s'marks From stuart.marks at oracle.com Tue Oct 6 21:14:19 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 6 Oct 2015 14:14:19 -0700 Subject: [9] [xxs] RFR 8138938: Clarify javadoc for java.util.Collections.copy() In-Reply-To: <561420F5.8010606@oracle.com> References: <561420F5.8010606@oracle.com> Message-ID: <561439AB.8020004@oracle.com> On 10/6/15 12:28 PM, Ivan Gerasimov wrote: > It was suggested that the javadoc for the java.util.Collections.copy() method > can be clarified. > Currently it says that the dest list must be long enough, not specifying what it > means to be long. > The submitter claims that it may be treated that the capacity of the list must > be large enough, which is not what what was meant. > > The fix does not change meaning of the doc, so it should not be considered as a > spec change. > Would you please help review the javadoc clarification. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8138938 > WEBREV: http://cr.openjdk.java.net/~igerasim/8138938/00/webrev/ Hi Ivan, Thanks for picking this up. I think this is a small but useful clarification. When I saw the bug report, I had to read the spec for Collections.copy() a couple times before I figured out what it really meant. (That is, size, not length.) I also believe this is merely a clarification, not a spec change, but we might be overridden by the spec gurus on this one. Aside from that, I think the change looks good; you may consider it reviewed. s'marks From forax at univ-mlv.fr Tue Oct 6 22:42:18 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 7 Oct 2015 00:42:18 +0200 (CEST) Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <5613FEE6.2010907@oracle.com> References: <5613D01F.3000107@Oracle.com> <CACzrW9CHGGpcDGQh2FoeFwgTwXr1besNdt42L3+RE6Cy7jPMLg@mail.gmail.com> <5613D635.6000305@Oracle.com> <CACzrW9C2bomoiA+hQcq6=H7QvMuBu2c7wmOGYHwq31b6Z=M18A@mail.gmail.com> <5613FEE6.2010907@oracle.com> Message-ID: <1391860289.1215500.1444171338590.JavaMail.zimbra@u-pem.fr> Null coalescing is a popular operator in several languages [1] and the usual semantics is nullOrElse and not firstNonNull. In languages like Kotlin or Swift, because there is a distinction between Object and Object?, it's not a big deal, you can not de-reference null by error, anyway. Also note that nullOrElseGet, the one that takes a supplier also exists in Groovy and Kotlin under the name null safe navigation. So even if i prefer the semantics of firstNonNull, i think we should also include both nullOrElse and nullOrElseGet. regards, R?mi [1] https://en.wikipedia.org/wiki/Null_coalescing_operator ----- Mail original ----- > De: "Stuart Marks" <stuart.marks at oracle.com> > ?: "Stephen Colebourne" <scolebourne at joda.org>, "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Roger Riggs" > <Roger.Riggs at oracle.com> > Envoy?: Mardi 6 Octobre 2015 19:03:34 > Objet: Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null > > I agree that with Stephen that Guava's semantics of disallowing a null > default > are preferable. It would seem very odd if a method that has "nonNull" in its > name is allowed to return null. > > It seems to me that the point of this and related methods is to provide a > fluent > way for a class to separate the nullable world outside with the non-nullable > world inside. Thus, > > void setValue(T arg) { // arg is nullable > field = Objects.firstNonNull(arg, DEFAULT_VALUE_FOR_FIELD); > assert field != null; > } > > If the default value can be null, why bother checking arg at all? It seems to > me > that it's a programming error if the default value is null, so this should be > checked. > > * * * > > As an aside I notice that Guava's Objects.firstNonNull() is deprecated, with > a > recommended replacement of MoreObjects.firstNonNull(). [1] The semantics are > the > same, though, as far as I can see. I'm curious as to what's going here, > though. > > [1] http://google.github.io/guava/releases/18.0/api/docs/ > > s'marks > > > > On 10/6/15 7:15 AM, Stephen Colebourne wrote: > > What the existing code does would seem to be irrelevant. What is > > important is deciding what the correct semantics should be for a core > > method on Objects. > > > > If there a desperate need for the webrev semantics, how about two methods? > > > > firstNonNull(a, b) - result must not be null > > firstOrElse(a, b) - result is null only is b is null > > > > (although I struggle to see much point in the latter) > > > > Stephen > > > > > > > > > > On 6 October 2015 at 15:09, Roger Riggs <Roger.Riggs at oracle.com> wrote: > >> Hi Stephen, > >> > >> Guava's firstNonNull is a useful semantic, but would not be a drop in > >> replacement for existing code which > >> would need to be examined for behavioral changes due to possibly throwing > >> an > >> exception. > >> So perhaps the nonNullorElse name would be more accurate. > >> > >> Thanks, Roger > >> > >> > >> > >> On 10/6/2015 10:00 AM, Stephen Colebourne wrote: > >>> > >>> Guava uses firstNonNull(a, b). It ensures that the result is never > >>> null, by checking that b is not null. > >>> I think the semantics of Guava's method is correct. I tend to think > >>> the method name isn't bad either. > >>> > >>> Calling it nonNull(Object,Object) clashes with the existing > >>> nonNull(Object) method. Those two have nothing much to do with each > >>> other. > >>> > >>> Stephen > >>> > >>> > >>> On 6 October 2015 at 14:43, Roger Riggs <Roger.Riggs at oracle.com> wrote: > >>>> > >>>> Java.lang.Objects contains a number of convenience methods to make it > >>>> easier > >>>> to handle references that are null. > >>>> For example, toString(obj, nullDefault), > >>>> > >>>> A new method is proposed to return the reference or a default value if > >>>> the > >>>> reference is null. > >>>> static <T> T nonNull(T obj, T nullDefault); > >>>> > >>>> Alternatives to the method name include > >>>> nonNullOrElse ( using the java.util.Optional name pattern) or > >>>> nonNullOrDefault > >>>> > >>>> Please review and comment. > >>>> > >>>> Webrev: > >>>> http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ > >>>> > >>>> Issue: > >>>> https://bugs.openjdk.java.net/browse/JDK-8138963 > >>>> > >>>> Thanks, Roger > >>>> > >> > From stuart.marks at oracle.com Wed Oct 7 00:01:11 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 6 Oct 2015 17:01:11 -0700 Subject: Test for JDK-5108778 Too many instances of java.lang.Boolean created in Java application In-Reply-To: <CACzrW9Cgcd11S1j0Ft5VaAKUKsissO3Hm+3c-1JXLf_sFXhnCg@mail.gmail.com> References: <560C3B56.4060309@gmx.de> <560F3B56.3060309@oracle.com> <CACzrW9Cgcd11S1j0Ft5VaAKUKsissO3Hm+3c-1JXLf_sFXhnCg@mail.gmail.com> Message-ID: <561460C7.10403@oracle.com> On 10/6/15 3:24 AM, Stephen Colebourne wrote: > Moving to core-libs: > > On 3 October 2015 at 03:20, Stuart Marks <stuart.marks at oracle.com> wrote: >> An interesting exercise would be to add the @Deprecated annotation to the >> Boolean constructor and build the JDK and see how many warnings result. That >> might be a quick way to find the code that needs to be fixed. > > I'd really like to see this. Specifically, adding @Deprecated to _all_ > constructors on Boolean, Short, Integer, Long, Character, Float, > Double. This may require some additional factory methods to be added. > > Doing this for Java 9 would be good preparation for value types. While > the Valhalla team are not currently talking about converting these > classes to values, they are clearly very value-like. Pushing users to > treat them more as values seems like a Good Thing. It might even tip > the balance towards making them actual value types. Hi Stephen, Interesting. There are a few issues at play here; let me try to separate them. In my message above, I merely suggested that Sebastian add @Deprecated to the Boolean constructors in his source tree as a means of static analysis. This is a quick way to derive a set of targets for cleaning up. That said, it's worth considering changing the Java SE API to deprecate Boolean and possibly other box constructors. As things stand today, though, the situation with deprecation is quite confusing. It's not clear whether deprecating something means that it will eventually be removed. When something becomes deprecated, people's responses are all over the map. It's either "ignore it, they've never removed anything from the JDK" or "they can't remove that, it will cause massive breakage!!" So the notion of deprecation will have to be clarified first. I'm working on a draft JEP (not yet public) for this, but some early thoughts along these lines were presented by my alter ego Dr Deprecator at JavaOne last year.[1] Basically, you'd want some marking that doesn't mean that the API will be removed, but that will issue a warning to developers suggesting they use a different API instead. I think it's pretty clear that we should "deprecate" in some fashion the Boolean and Byte constructors, since boxes for all possible values of these types are cached and reused. The case for deprecating other box constructors is less clear in my mind. For example, Double.valueOf(d) always calls new Double(d); no Double boxes are cached. One could imagine caching specific boxes such as zero, but there are very few such values that would make sense to cache. The benefit of telling programmers to convert new Double(d) to Double.valueOf(d) thus seems quite small to me. Then again, in a value-typed future, there might be some advantages to doing this that I'm not aware of. Some time ago Brian Goetz was quite skeptical that the primitive boxes could ever become true value types. But things might have changed, so I'll avoid forming a strong opinion on this issue until we hear more about how value types might impact this issue. s'marks [1] https://oracleus.activeevents.com/2014/connect/sessionDetail.ww?SESSION_ID=6377 From stuart.marks at oracle.com Wed Oct 7 00:13:30 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 6 Oct 2015 17:13:30 -0700 Subject: JEP 269: Convenience Factory Methods for Collections In-Reply-To: <1536405490.3047562.1443881785146.JavaMail.zimbra@u-pem.fr> References: <20150924000217.D476B7A327@eggemoggin.niobe.net> <CAGKkBks7CKsJngvagV15C47E6zncdS-ag2m2OOKGoTtm-+YFFw@mail.gmail.com> <1548646383.2640105.1443208816341.JavaMail.zimbra@u-pem.fr> <CAGKkBkveaKTmGbhYJ4J8NNzkD5DwMz+ZvhHufC5Q2tQHU5D3Jg@mail.gmail.com> <1536405490.3047562.1443881785146.JavaMail.zimbra@u-pem.fr> Message-ID: <561463AA.6070206@oracle.com> On 10/3/15 7:16 AM, forax at univ-mlv.fr wrote: > "Kevin Bourrillion" <kevinb at google.com> wrote: >> We have ~1800 occurrences of Optional-valued Maps or Caches in Google. They >> do this for an actual reason: a negative result is meaningfully different >> from no result. This is addressed in our Optional javadoc . > > mapped-to-absent means that you know the keys you are waiting for, so you can store them in an external set (list, etc) and enjoy implementations like EnumMap or the couple JSObject/HiddenClass you found in most javascript engines. > Using Optional for that seem inefficient. Indeed, the Optional docs that Kevin linked to themselves have links to other pages that describe techniques for avoiding use of nulls and Optionals in cases such as this. Nonetheless, as Kevin points out, there are 1,800 such usages in Google's code base. And personally, as a matter of style, I dislike using Optional in collections. My question is, is this enough of a problem that we should allow nulls in these collections? I would prefer not to do this, but if there is evidence that this would be a mistake, I'd like to hear it. And if disallowing nulls will cause developers to create things like Map<K,Optional<V>>, are we ok with that, and are developers ok with that? s'marks From gil at azulsystems.com Wed Oct 7 01:28:44 2015 From: gil at azulsystems.com (Gil Tene) Date: Wed, 7 Oct 2015 01:28:44 +0000 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <561428BC.3060806@cs.oswego.edu> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> Message-ID: <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> > On Oct 6, 2015, at 1:02 PM, Doug Lea <dl at cs.oswego.edu> wrote: > > On 10/04/2015 12:22 PM, Gil Tene wrote: >> I would like to circulate this draft JEP proposal for initial review and consensus building purposes. >> > > Some background: about two years ago, Dave Dice and I put together > a pre-jep proposal for JVM support for recent CPU features covering: > > (1) MWAIT/PAUSE/etc (for spins as well as other uses people have noted); > (2) Core topology/neighborhood information and; > (3) 2CAS, as a foothold on HTM that could still be reasonably efficient > on non-transactional processors. > > My understanding of the result of this effort was that Oracle JVM engineers > didn't think they had resources to do this for jdk9. It didn't occur to > me that non-Oracle contributors might want to cherry-pick one (some > of (1) above). It seems plausible to do this, but only if designed > as the first of some possible enhanced support along these lines. Good point. But that's what an actual community is about. Isn't it? We (Azul) are volunteering the resources for spinloopHint(). Including experimentation, implementation, testing, and even a TCK (which in this case will be trivial). So the vast majority of resources needed will not be coming other budgeted jdk9 resources. I certainly recognize that there will still be work involved that others will end up having to do: reviewing, arguing, contributing opinions, etc., as well as integrating the work into the whole. But this specific proposed JEP is about as narrow and low risk as you can get. especially from a specification point of view (e.g. intrinsic implementation can be left under a flag if deemed risky to stability or schedule). As for fitting in with larger-picture or theme things (listed above). I think that agonizing over the choice of where to put this is important (e.g. the Thread.spinLoopHint() idea, or a create new class that other hints will go into in the future, and where?). But I don't think that there is good reason to bundle this work with e.g. 2CAS, HTM, and affinity. Work. While we can think of them all as "support for recent CPU features", they are very different (and probably have multiple other unrelated groupings). MWAIT (and the like) and PAUSE do deserve some co-thinking (see earlier discussion on the thread). So does a discussion about a capturing abstraction like synchronic (raised in concurrency interest), But given the actual common uses already waiting for a spinLoopHint(), the very tangible and immediate benefit it shows, and the fact that most of the use cases wouldn't be able to make use of MWAIT (or the like), and some won't be able to use a synchronic-like thing, I think that either a spin-hint-only JEP is not just a good "shortcut", but also an actual stand-alone feature need. > -Doug > > > From joe.darcy at oracle.com Wed Oct 7 01:50:18 2015 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 06 Oct 2015 18:50:18 -0700 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> Message-ID: <56147A5A.5040308@oracle.com> On 10/6/2015 6:28 PM, Gil Tene wrote: >> On Oct 6, 2015, at 1:02 PM, Doug Lea <dl at cs.oswego.edu> wrote: >> >> On 10/04/2015 12:22 PM, Gil Tene wrote: >>> I would like to circulate this draft JEP proposal for initial review and consensus building purposes. >>> >> Some background: about two years ago, Dave Dice and I put together >> a pre-jep proposal for JVM support for recent CPU features covering: >> >> (1) MWAIT/PAUSE/etc (for spins as well as other uses people have noted); >> (2) Core topology/neighborhood information and; >> (3) 2CAS, as a foothold on HTM that could still be reasonably efficient >> on non-transactional processors. >> >> My understanding of the result of this effort was that Oracle JVM engineers >> didn't think they had resources to do this for jdk9. It didn't occur to >> me that non-Oracle contributors might want to cherry-pick one (some >> of (1) above). It seems plausible to do this, but only if designed >> as the first of some possible enhanced support along these lines. > Good point. But that's what an actual community is about. Isn't it? > > We (Azul) are volunteering the resources for spinloopHint(). Including > experimentation, implementation, testing, and even a TCK (which in this case > will be trivial). So the vast majority of resources needed will not be coming > other budgeted jdk9 resources. > > I certainly recognize that there will still be work involved that others will > end up having to do: reviewing, arguing, contributing opinions, etc., as well > as integrating the work into the whole. But this specific proposed JEP is about > as narrow and low risk as you can get. especially from a specification point of > view (e.g. intrinsic implementation can be left under a flag if deemed risky to > stability or schedule). > > As for fitting in with larger-picture or theme things (listed above). I think that > agonizing over the choice of where to put this is important (e.g. the Thread.spinLoopHint() > idea, or a create new class that other hints will go into in the future, and where?). > But I don't think that there is good reason to bundle this work with e.g. 2CAS, HTM, > and affinity. Work. While we can think of them all as "support for recent CPU features", > they are very different (and probably have multiple other unrelated groupings). > > MWAIT (and the like) and PAUSE do deserve some co-thinking (see earlier discussion > on the thread). So does a discussion about a capturing abstraction like synchronic > (raised in concurrency interest), But given the actual common uses already waiting > for a spinLoopHint(), the very tangible and immediate benefit it shows, and the fact that > most of the use cases wouldn't be able to make use of MWAIT (or the like), and some > won't be able to use a synchronic-like thing, I think that either a spin-hint-only JEP > is not just a good "shortcut", but also an actual stand-alone feature need. > Taking a long-term view, it seems to me premature to burn this kind of hint into the Java SE API (effectively) forever in the absence of experience that the hint in this form is useful and will continue to be useful in 5 years, 10 years, etc. If the hint started out as a JDK-specific API, there would be (some) more room to modify or drop the API in the future, leaving open the possibility of migrating the functionality to the Java SE API too. -Joe From dawid.weiss at gmail.com Wed Oct 7 06:51:35 2015 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Wed, 7 Oct 2015 08:51:35 +0200 Subject: Test for JDK-5108778 Too many instances of java.lang.Boolean created in Java application In-Reply-To: <561460C7.10403@oracle.com> References: <560C3B56.4060309@gmx.de> <560F3B56.3060309@oracle.com> <CACzrW9Cgcd11S1j0Ft5VaAKUKsissO3Hm+3c-1JXLf_sFXhnCg@mail.gmail.com> <561460C7.10403@oracle.com> Message-ID: <CAM21Rt9RkdaAfrzyPE8PZ=vWq-DDCtxCyE5RRk8u9Mvg2C+Bmw@mail.gmail.com> A @Discouraged(String seeAlternative) annotation? This also applies to things like Vector or Hashtable (which arguably have a slightly different semantics from ArrayList or HashMap, but if somebody uses them it's very likely a mistake). This reminds me of the work Uwe Schindler did with his "forbidden APIs" tool [1]; many projects are currently using it to avoid trappy APIs. The tool emits a warning and an explanation when it encounters such API usage, see [2] for a list of methods in the JDK, for instance. Dawid [1] https://github.com/policeman-tools/forbidden-apis [2] https://github.com/policeman-tools/forbidden-apis/tree/master/src/main/resources/de/thetaphi/forbiddenapis/signatures On Wed, Oct 7, 2015 at 2:01 AM, Stuart Marks <stuart.marks at oracle.com> wrote: > > > On 10/6/15 3:24 AM, Stephen Colebourne wrote: >> >> Moving to core-libs: >> >> On 3 October 2015 at 03:20, Stuart Marks <stuart.marks at oracle.com> wrote: >>> >>> An interesting exercise would be to add the @Deprecated annotation to the >>> Boolean constructor and build the JDK and see how many warnings result. >>> That >>> might be a quick way to find the code that needs to be fixed. >> >> >> I'd really like to see this. Specifically, adding @Deprecated to _all_ >> constructors on Boolean, Short, Integer, Long, Character, Float, >> Double. This may require some additional factory methods to be added. >> >> Doing this for Java 9 would be good preparation for value types. While >> the Valhalla team are not currently talking about converting these >> classes to values, they are clearly very value-like. Pushing users to >> treat them more as values seems like a Good Thing. It might even tip >> the balance towards making them actual value types. > > > Hi Stephen, > > Interesting. There are a few issues at play here; let me try to separate > them. > > In my message above, I merely suggested that Sebastian add @Deprecated to > the Boolean constructors in his source tree as a means of static analysis. > This is a quick way to derive a set of targets for cleaning up. > > That said, it's worth considering changing the Java SE API to deprecate > Boolean and possibly other box constructors. As things stand today, though, > the situation with deprecation is quite confusing. It's not clear whether > deprecating something means that it will eventually be removed. When > something becomes deprecated, people's responses are all over the map. It's > either "ignore it, they've never removed anything from the JDK" or "they > can't remove that, it will cause massive breakage!!" So the notion of > deprecation will have to be clarified first. > > I'm working on a draft JEP (not yet public) for this, but some early > thoughts along these lines were presented by my alter ego Dr Deprecator at > JavaOne last year.[1] Basically, you'd want some marking that doesn't mean > that the API will be removed, but that will issue a warning to developers > suggesting they use a different API instead. > > I think it's pretty clear that we should "deprecate" in some fashion the > Boolean and Byte constructors, since boxes for all possible values of these > types are cached and reused. > > The case for deprecating other box constructors is less clear in my mind. > For example, Double.valueOf(d) always calls new Double(d); no Double boxes > are cached. One could imagine caching specific boxes such as zero, but there > are very few such values that would make sense to cache. The benefit of > telling programmers to convert new Double(d) to Double.valueOf(d) thus seems > quite small to me. > > Then again, in a value-typed future, there might be some advantages to doing > this that I'm not aware of. Some time ago Brian Goetz was quite skeptical > that the primitive boxes could ever become true value types. But things > might have changed, so I'll avoid forming a strong opinion on this issue > until we hear more about how value types might impact this issue. > > s'marks > > > > [1] > https://oracleus.activeevents.com/2014/connect/sessionDetail.ww?SESSION_ID=6377 From gil at azulsystems.com Wed Oct 7 07:17:46 2015 From: gil at azulsystems.com (Gil Tene) Date: Wed, 7 Oct 2015 07:17:46 +0000 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <56147A5A.5040308@oracle.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56147A5A.5040308@oracle.com> Message-ID: <60ED335F-9898-4496-99AF-C5DBE5B3E8F1@azulsystems.com> > On Oct 6, 2015, at 6:50 PM, Joseph D. Darcy <joe.darcy at oracle.com> wrote: > > > On 10/6/2015 6:28 PM, Gil Tene wrote: >>> On Oct 6, 2015, at 1:02 PM, Doug Lea <dl at cs.oswego.edu> wrote: >>> >>> On 10/04/2015 12:22 PM, Gil Tene wrote: >>>> I would like to circulate this draft JEP proposal for initial review and consensus building purposes. >>>> >>> Some background: about two years ago, Dave Dice and I put together >>> a pre-jep proposal for JVM support for recent CPU features covering: >>> >>> (1) MWAIT/PAUSE/etc (for spins as well as other uses people have noted); >>> (2) Core topology/neighborhood information and; >>> (3) 2CAS, as a foothold on HTM that could still be reasonably efficient >>> on non-transactional processors. >>> >>> My understanding of the result of this effort was that Oracle JVM engineers >>> didn't think they had resources to do this for jdk9. It didn't occur to >>> me that non-Oracle contributors might want to cherry-pick one (some >>> of (1) above). It seems plausible to do this, but only if designed >>> as the first of some possible enhanced support along these lines. >> Good point. But that's what an actual community is about. Isn't it? >> >> We (Azul) are volunteering the resources for spinloopHint(). Including >> experimentation, implementation, testing, and even a TCK (which in this case >> will be trivial). So the vast majority of resources needed will not be coming >> other budgeted jdk9 resources. >> >> I certainly recognize that there will still be work involved that others will >> end up having to do: reviewing, arguing, contributing opinions, etc., as well >> as integrating the work into the whole. But this specific proposed JEP is about >> as narrow and low risk as you can get. especially from a specification point of >> view (e.g. intrinsic implementation can be left under a flag if deemed risky to >> stability or schedule). >> >> As for fitting in with larger-picture or theme things (listed above). I think that >> agonizing over the choice of where to put this is important (e.g. the Thread.spinLoopHint() >> idea, or a create new class that other hints will go into in the future, and where?). >> But I don't think that there is good reason to bundle this work with e.g. 2CAS, HTM, >> and affinity. Work. While we can think of them all as "support for recent CPU features", >> they are very different (and probably have multiple other unrelated groupings). >> >> MWAIT (and the like) and PAUSE do deserve some co-thinking (see earlier discussion >> on the thread). So does a discussion about a capturing abstraction like synchronic >> (raised in concurrency interest), But given the actual common uses already waiting >> for a spinLoopHint(), the very tangible and immediate benefit it shows, and the fact that >> most of the use cases wouldn't be able to make use of MWAIT (or the like), and some >> won't be able to use a synchronic-like thing, I think that either a spin-hint-only JEP >> is not just a good "shortcut", but also an actual stand-alone feature need. >> > > Taking a long-term view, it seems to me premature to burn this kind of hint into the Java SE API (effectively) forever in the absence of experience that the hint in this form is useful and will continue to be useful in 5 years, 10 years, etc. > > If the hint started out as a JDK-specific API, there would be (some) more room to modify or drop the API in the future, leaving open the possibility of migrating the functionality to the Java SE API too. > > -Joe While I don't disagree with the need for long term thinking, I think this JEP represents exactly that. It is hardly "premature". "Very late" is probably a much better description. There is overwhelming evidence and experience showing that this exact form of hint is useful, and will likely continue to be useful for a decade or more. Spin hinting isn't something new. This hint technique (include an explicit instruction or function call hinting that you are in a spin loop) has been dominantly and beneficially used for over a decade in virtually all spinning code *other* than Java. E.g. Linux (and probably all other OSs) uses this for virtually all kernel spinning situations on x86 and PowerPC. POSIX libraries do so too in mutexes and semaphores in user mode. Even the JVM's own custom C++ spinning code has been doing it for many years. It is only pure Java code that has been deprived this ability for the past decade. And in the many-core world we've been living in for at least 5 years, even on commodity hardware, the lack really hurts. This JEP is a fairly late reaction to the very patient requests of a substantial set of Java developers. The community of people doing performant messaging and latency sensitive stuff with Java has been asking for this for a long time as well. Usually with variants of sentences like "Our C and C++ versions of these things use a PAUSE instruction, but in Java we have no way to make that happen. As a result, the reaction time of our Java spin loops is unnecessarily slower than non-Java setups, and our metrics suffer". People often phrase their request as "I'd like PAUSE instruction API in Java". The JEP is aiming for a platform-independent way to express that. ?Gil. From aph at redhat.com Wed Oct 7 08:14:25 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 7 Oct 2015 09:14:25 +0100 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <ED44A1CE-F28C-4EDA-89F8-B97CF2E3F3AB@azulsystems.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561245E0.8030708@redhat.com> <ED44A1CE-F28C-4EDA-89F8-B97CF2E3F3AB@azulsystems.com> Message-ID: <5614D461.8050403@redhat.com> On 05/10/15 21:43, Gil Tene wrote: > I see SpinLoopHint as very separate from things like MONITOR/WAIT > (on x86) and WFE/SEV (on ARM), as well as any other "wait in a nice > way until this state changes" instructions that other architectures > may have or add. > > Mechanisms like MONITOR/WAIT and WFE/SEV provide a way to > potentially wait for specific state changes to occur. As such, they > can be used to implement a specific form of a spin loop (the most > common one, probably). But they do not provide for generic spinning > forms. E.g. loops that have multiple exit conditions in different > memory locations, loops that wait on internal state changes that are > no affected by other CPUs (like "spin only this many times before > giving up" or "spin for this much time"), and loops that may use > transactional state changes (e.g. LOCK XADD, or wider things with > TSX) are probably "hard" to model with these instructions. Yes, you're right: there's no real way to combine these things, and support for WFE requires some other kind of interface -- if I ever manage to think of a nice way to express it in Java. So, my apologies for hijacking this thread, but now you've got me thinking. In an ideal world there would be a timer associated with WFE which would trigger after a short while and allow a thread to be descheduled. However, it is possible to set a periodic timer which regularly signals each worker thread, giving it the opportunity to block if unused for a long time. This should make a much more responsive thread pool, so that when worker threads are active they respond in nanoseconds rather than microseconds. [ An aside: WFE is available in user mode, and according to Intel's documentation it should be possible to configre an OS to use MONITOR/WAIT in user mode too. I don't know why it doesn't work. ] Andrew. From scolebourne at joda.org Wed Oct 7 09:30:27 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 7 Oct 2015 10:30:27 +0100 Subject: JEP 269: Convenience Factory Methods for Collections In-Reply-To: <561463AA.6070206@oracle.com> References: <20150924000217.D476B7A327@eggemoggin.niobe.net> <CAGKkBks7CKsJngvagV15C47E6zncdS-ag2m2OOKGoTtm-+YFFw@mail.gmail.com> <1548646383.2640105.1443208816341.JavaMail.zimbra@u-pem.fr> <CAGKkBkveaKTmGbhYJ4J8NNzkD5DwMz+ZvhHufC5Q2tQHU5D3Jg@mail.gmail.com> <1536405490.3047562.1443881785146.JavaMail.zimbra@u-pem.fr> <561463AA.6070206@oracle.com> Message-ID: <CACzrW9Bf0YgsKqUew2Q_0z-1P8M72q3UxGgW1RJE7703DvxU5g@mail.gmail.com> On 7 October 2015 at 01:13, Stuart Marks <stuart.marks at oracle.com> wrote: > My question is, is this enough of a problem that we should allow nulls in > these collections? I would prefer not to do this, but if there is evidence > that this would be a mistake, I'd like to hear it. > > And if disallowing nulls will cause developers to create things like > Map<K,Optional<V>>, are we ok with that, and are developers ok with that? Given what we know now vs when the collections library ws created, I think it would be a mistake to allow nulls. Developers that desperately want null in there have other mechanisms to achieve that, not just Optional. I too would argue against Optional in collections, at least until value types exist, but thats a social discussion, not one that can be controlled. Stephen From chris.hegarty at oracle.com Wed Oct 7 10:10:16 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 7 Oct 2015 11:10:16 +0100 Subject: JEP 269: Convenience Factory Methods for Collections In-Reply-To: <CACzrW9Bf0YgsKqUew2Q_0z-1P8M72q3UxGgW1RJE7703DvxU5g@mail.gmail.com> References: <20150924000217.D476B7A327@eggemoggin.niobe.net> <CAGKkBks7CKsJngvagV15C47E6zncdS-ag2m2OOKGoTtm-+YFFw@mail.gmail.com> <1548646383.2640105.1443208816341.JavaMail.zimbra@u-pem.fr> <CAGKkBkveaKTmGbhYJ4J8NNzkD5DwMz+ZvhHufC5Q2tQHU5D3Jg@mail.gmail.com> <1536405490.3047562.1443881785146.JavaMail.zimbra@u-pem.fr> <561463AA.6070206@oracle.com> <CACzrW9Bf0YgsKqUew2Q_0z-1P8M72q3UxGgW1RJE7703DvxU5g@mail.gmail.com> Message-ID: <B703FABA-40BB-4CAF-BA26-EBDE1A278FCA@oracle.com> On 7 Oct 2015, at 10:30, Stephen Colebourne <scolebourne at joda.org> wrote: > On 7 October 2015 at 01:13, Stuart Marks <stuart.marks at oracle.com> wrote: >> My question is, is this enough of a problem that we should allow nulls in >> these collections? I would prefer not to do this, but if there is evidence >> that this would be a mistake, I'd like to hear it. >> >> And if disallowing nulls will cause developers to create things like >> Map<K,Optional<V>>, are we ok with that, and are developers ok with that? > > Given what we know now vs when the collections library ws created, I > think it would be a mistake to allow nulls. Developers that > desperately want null in there have other mechanisms to achieve that, > not just Optional. I agree with this. These are, after all, ?just convenience? methods, there are other ways if null is required. I do not see any compelling reason for allowing null, given the type of use case these methods are trying address, collections and maps with small numbers of elements. > I too would argue against Optional in collections, > at least until value types exist, but thats a social discussion, not > one that can be controlled. > > Stephen -Chris. From forax at univ-mlv.fr Wed Oct 7 12:49:35 2015 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 07 Oct 2015 12:49:35 +0000 Subject: JEP 269: Convenience Factory Methods for Collections In-Reply-To: <561463AA.6070206@oracle.com> References: <20150924000217.D476B7A327@eggemoggin.niobe.net> <CAGKkBks7CKsJngvagV15C47E6zncdS-ag2m2OOKGoTtm-+YFFw@mail.gmail.com> <1548646383.2640105.1443208816341.JavaMail.zimbra@u-pem.fr> <CAGKkBkveaKTmGbhYJ4J8NNzkD5DwMz+ZvhHufC5Q2tQHU5D3Jg@mail.gmail.com> <1536405490.3047562.1443881785146.JavaMail.zimbra@u-pem.fr> <561463AA.6070206@oracle.com> Message-ID: <A4EE45FD-7C3C-4999-B478-9DA45F3FB823@univ-mlv.fr> The current guideline seems to be that new collections introduced after Java 4 should not allow null. ArrayDeque is an example of such collections. This proposal introduces new static methods on both interfaces and implementations. Interface static methods use new immutable collections, if those doesn't support null, a user can easily switch to the static method on one of the corresponding implementation class. By example, instead of using List.of (null), one can use ArrayList.of (null). That's why i think it's fine to not allow null in new immutable collections. regards, R?mi Le 7 octobre 2015 02:13:30 CEST, Stuart Marks <stuart.marks at oracle.com> a ?crit : > > >On 10/3/15 7:16 AM, forax at univ-mlv.fr wrote: >> "Kevin Bourrillion" <kevinb at google.com> wrote: >>> We have ~1800 occurrences of Optional-valued Maps or Caches in >Google. They >>> do this for an actual reason: a negative result is meaningfully >different >>> from no result. This is addressed in our Optional javadoc . >> >> mapped-to-absent means that you know the keys you are waiting for, so >you can store them in an external set (list, etc) and enjoy >implementations like EnumMap or the couple JSObject/HiddenClass you >found in most javascript engines. >> Using Optional for that seem inefficient. > >Indeed, the Optional docs that Kevin linked to themselves have links to >other >pages that describe techniques for avoiding use of nulls and Optionals >in cases >such as this. Nonetheless, as Kevin points out, there are 1,800 such >usages in >Google's code base. > >And personally, as a matter of style, I dislike using Optional in >collections. > >My question is, is this enough of a problem that we should allow nulls >in these >collections? I would prefer not to do this, but if there is evidence >that this >would be a mistake, I'd like to hear it. > >And if disallowing nulls will cause developers to create things like >Map<K,Optional<V>>, are we ok with that, and are developers ok with >that? > >s'marks From thomas.stuefe at gmail.com Wed Oct 7 14:28:05 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 7 Oct 2015 16:28:05 +0200 Subject: RFR(xxs): 8139037: [aix] Crash in ResolverConfigurationImpl.c - pointer shearing Message-ID: <CAA-vtUxoXJyAXKSJ5gnGjOO2rH0PM=ewJyW4ep83S34fTTszVA@mail.gmail.com> Hi, please review and sponsor this AIX fix. in ResolverConfigurationImpl.c, we may crash because strchr() is used without prototype, which causes the C compiler to default to an int return type, which means we loose the upper 32bit of the pointer returned by strchr(). The solution is to include string.h. Before, string.h was conditionally included for all platforms but AIX - reason is not really clear to me. But as strchr() is POSIX and always in string.h, I included string.h unconditionally for all Unices. webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8139037/webrev.00/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8139037 Kind Regards, Thomas From daniel.fuchs at oracle.com Wed Oct 7 14:57:12 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 7 Oct 2015 16:57:12 +0200 Subject: JEP 264: Platform Logging API and Service In-Reply-To: <561256D8.10907@oracle.com> References: <20150918161737.CF3F171F93@eggemoggin.niobe.net> <561256D8.10907@oracle.com> Message-ID: <561532C8.5020202@oracle.com> Hi, I have pushed an implementation of the prototype in the sandbox. The branch name is JDK-8046565-branch Instructions for cloning a sandbox branch can be found here: http://cr.openjdk.java.net/~chegar/docs/sandbox.html best regards, -- daniel On 05/10/15 12:54, Daniel Fuchs wrote: >> New JEP Candidate: http://openjdk.java.net/jeps/264 > > Hi I have uploaded an initial prototype specdiff: > > http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/specdiff-api/overview-summary.html > > > LoggerFinder methods that take a Class<?> caller argument > will take a java.lang.reflect.Module callerModule instead when > that is available in jdk9/dev. > > comments welcome, > > best regards, > > -- daniel > From gil at azulsystems.com Wed Oct 7 15:45:44 2015 From: gil at azulsystems.com (Gil Tene) Date: Wed, 7 Oct 2015 15:45:44 +0000 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <5614D461.8050403@redhat.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561245E0.8030708@redhat.com> <ED44A1CE-F28C-4EDA-89F8-B97CF2E3F3AB@azulsystems.com>, <5614D461.8050403@redhat.com> Message-ID: <A5B98226-F31B-4873-A363-5C4B5DCC777D@azulsystems.com> Sent from Gil's iPhone > On Oct 7, 2015, at 1:14 AM, Andrew Haley <aph at redhat.com> wrote: > >> On 05/10/15 21:43, Gil Tene wrote: >> >> I see SpinLoopHint as very separate from things like MONITOR/WAIT >> (on x86) and WFE/SEV (on ARM), as well as any other "wait in a nice >> way until this state changes" instructions that other architectures >> may have or add. >> >> Mechanisms like MONITOR/WAIT and WFE/SEV provide a way to >> potentially wait for specific state changes to occur. As such, they >> can be used to implement a specific form of a spin loop (the most >> common one, probably). But they do not provide for generic spinning >> forms. E.g. loops that have multiple exit conditions in different >> memory locations, loops that wait on internal state changes that are >> no affected by other CPUs (like "spin only this many times before >> giving up" or "spin for this much time"), and loops that may use >> transactional state changes (e.g. LOCK XADD, or wider things with >> TSX) are probably "hard" to model with these instructions. > > Yes, you're right: there's no real way to combine these things, and > support for WFE requires some other kind of interface -- if I ever > manage to think of a nice way to express it in Java. So, my > apologies for hijacking this thread, but now you've got me thinking. > > In an ideal world there would be a timer associated with WFE which > would trigger after a short while and allow a thread to be > descheduled. However, it is possible to set a periodic timer which > regularly signals each worker thread, giving it the opportunity to > block if unused for a long time. This should make a much more > responsive thread pool, so that when worker threads are active they > respond in nanoseconds rather than microseconds. The problem with using timer based interrupts to kick out of WFE or MWAIT situations is that the granularity is often too thin for timers (and interrupts). E.g. j.u.c often uses "magic number of spins" of 64 or so before backed my out of the spin. That's just too short to get a timer going (and canceled) in, and the overhead of interrupt handling will overwhelm the actual action being attempted. "What we really need" for WFE/MEAIT hardware instructions to be useful in this space (of spin-for-bit-before-giving-up) is for the instructions to take a timeout argument (e.g. # of clock cycles. A power of two would probably suffice, so not slot of bits needed). But that's just not how they work on current HW... > > [ An aside: WFE is available in user mode, and according to Intel's > documentation it should be possible to configre an OS to use > MONITOR/WAIT in user mode too. I don't know why it doesn't work. ] While there are some ambiguous suggestions that MONITOR/MWAIT may be available in CPLs above 0 in some documentation, the current documentation for the actual MWAIT instruction is pretty clear about it only working in privilege level 0. So maybe this will be relaxed in the future? In any case, even if it were user-mode-accessible, MWAIT may not appropriate for latency-sensitive spinning because it can apparently take 1000s of cycles to come out of the C-state modes it goes into. At those level, you may be better off blocking or yielding, and no one would make use of it if they care about quick reaction time. It may be that it's not that bad, depending on the cstate requested, but the fact that Linux kernels don't currently use MWAIT for spin loops suggests that it not good for that use case yet. For ARM, I expect WFE/SEV to need to evolve as well, and for other reasons, even fit use within OSs. The current WFE/SEV scheme is not scalable. While it probably works ok for spinning at the kernel level on hardware that only has s handful of cores, the fact that the event WFE waits for (and SEV sends) is global to the system will break things as core counts grow (it is the hardware equivalent of wait/notifyAll() with a single global monitor). I expect that for OSs to use it for spinning on many-core systems, there would need to be some de-muxing capability added (e.g. by address or by some id). In its current form, it is probably not ready for exposure to user mode code. (Imagine what would happen if user code started doing system-wide SEVs on every unlock). From aph at redhat.com Wed Oct 7 15:49:49 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 7 Oct 2015 16:49:49 +0100 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <A5B98226-F31B-4873-A363-5C4B5DCC777D@azulsystems.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561245E0.8030708@redhat.com> <ED44A1CE-F28C-4EDA-89F8-B97CF2E3F3AB@azulsystems.com> <5614D461.8050403@redhat.com> <A5B98226-F31B-4873-A363-5C4B5DCC777D@azulsystems.com> Message-ID: <56153F1D.80503@redhat.com> On 10/07/2015 04:45 PM, Gil Tene wrote: > In any case, even if it were user-mode-accessible, MWAIT may not appropriate for latency-sensitive spinning because it can apparently take 1000s of cycles to come out of the C-state modes it goes into. Oh, yuck. OK, forget it. Thanks, Andrew. From aph at redhat.com Wed Oct 7 15:51:39 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 7 Oct 2015 16:51:39 +0100 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <A5B98226-F31B-4873-A363-5C4B5DCC777D@azulsystems.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561245E0.8030708@redhat.com> <ED44A1CE-F28C-4EDA-89F8-B97CF2E3F3AB@azulsystems.com> <5614D461.8050403@redhat.com> <A5B98226-F31B-4873-A363-5C4B5DCC777D@azulsystems.com> Message-ID: <56153F8B.8000102@redhat.com> On 10/07/2015 04:45 PM, Gil Tene wrote: > For ARM, I expect WFE/SEV to need to evolve as well, and for other > reasons, even fit use within OSs. The current WFE/SEV scheme is not > scalable. While it probably works ok for spinning at the kernel > level on hardware that only has s handful of cores, the fact that > the event WFE waits for (and SEV sends) is global to the system will > break things as core counts grow (it is the hardware equivalent of > wait/notifyAll() with a single global monitor). That's not how it works. It's sufficient to write to the lock word to wake a core from a WFE: SEV is not required. Each core has its own event monitor, and wakeup is handled by the cache coherency logic. Andrew. From paul.sandoz at oracle.com Wed Oct 7 15:55:27 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 7 Oct 2015 17:55:27 +0200 Subject: Array equality, comparison and mismatch In-Reply-To: <663AA12B-6948-42B4-90E4-0E207D11D4D9@oracle.com> References: <79451C0B-DA1A-4FD6-B8F3-97B7BE841006@oracle.com> <561298A9.2040900@oracle.com> <362CCE17-4D8E-411A-82B5-EF83EDE2FE90@oracle.com> <663AA12B-6948-42B4-90E4-0E207D11D4D9@oracle.com> Message-ID: <A5D702A0-9BF0-4F18-93D8-EC5A36D5122C@oracle.com> > On 6 Oct 2015, at 10:58, Chris Hegarty <chris.hegarty at oracle.com> wrote: >>> It was not immediately obvious to me that the common prefix can be 0. Should this be called out specifically? >>> >> >> When reading the documentation of compare or mismatch or both? > > mismatch. But maybe this is just me. > I could add something following the paragraph defining the common prefix: Note that a common prefix length of {@code 0} indicates that the first elements from each array mismatch. Paul. From chris.hegarty at oracle.com Wed Oct 7 16:41:59 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 7 Oct 2015 17:41:59 +0100 Subject: Array equality, comparison and mismatch In-Reply-To: <A5D702A0-9BF0-4F18-93D8-EC5A36D5122C@oracle.com> References: <79451C0B-DA1A-4FD6-B8F3-97B7BE841006@oracle.com> <561298A9.2040900@oracle.com> <362CCE17-4D8E-411A-82B5-EF83EDE2FE90@oracle.com> <663AA12B-6948-42B4-90E4-0E207D11D4D9@oracle.com> <A5D702A0-9BF0-4F18-93D8-EC5A36D5122C@oracle.com> Message-ID: <774B2C36-EDC1-450D-8334-54CCFC7393F2@oracle.com> On 7 Oct 2015, at 16:55, Paul Sandoz <paul.sandoz at oracle.com> wrote: > >> On 6 Oct 2015, at 10:58, Chris Hegarty <chris.hegarty at oracle.com> wrote: >>>> It was not immediately obvious to me that the common prefix can be 0. Should this be called out specifically? >>>> >>> >>> When reading the documentation of compare or mismatch or both? >> >> mismatch. But maybe this is just me. >> > > I could add something following the paragraph defining the common prefix: > > Note that a common prefix length of {@code 0} indicates that the first elements from each array mismatch. Thanks, that makes it explicit. -Chris. > Paul. From chris.hegarty at oracle.com Wed Oct 7 18:19:17 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 7 Oct 2015 19:19:17 +0100 Subject: RFR [9] 8138978: Examine usages of sun.misc.IOUtils Message-ID: <A79916EE-69DE-49EB-9C22-3384290A7AFF@oracle.com> This primary motivation behind this bug [1] is the clearing out of sun.misc, in preparation for JEP 260 [2]. sun.misc.IOUtils is a JDK internal convenience utility class that provides a single method that offers bulk blocking InputStream read semantics. In 9, java.io.InputStream has been retrofitted with two methods that provide similar, but not quite the same, functionality, readNBytes and readAllBytes, see JDK-8080835 [3]. There are a number of places where IOUtils can be replaced with the appropriate supported API, readNBytes or readAllBytes. There are a number of places, mainly in the security implementation, that required to read a specific number of bytes ( not to end of stream ), where it is preferable to not preallocate the byte[] and allow it to "grow" lazily, to be defensive against protocol errors. These cases cannot use read[N|All]Bytes, so it makes sense to retain IOUtils but locate it in a package, sun.security.util, that makes it clear who its primary consumer is. http://cr.openjdk.java.net/~chegar/8138978/webrev.00/jdk/ http://cr.openjdk.java.net/~chegar/8138978/webrev.00/hotspot/ -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8138978 [2] https://bugs.openjdk.java.net/browse/JDK-8132928 [3] https://bugs.openjdk.java.net/browse/JDK-8080835 From Roger.Riggs at Oracle.com Wed Oct 7 19:01:32 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 7 Oct 2015 15:01:32 -0400 Subject: RFR [9] 8138978: Examine usages of sun.misc.IOUtils In-Reply-To: <A79916EE-69DE-49EB-9C22-3384290A7AFF@oracle.com> References: <A79916EE-69DE-49EB-9C22-3384290A7AFF@oracle.com> Message-ID: <56156C0C.90008@Oracle.com> Hi Chris, Looks fine. The change in exception message is more informative than the previous exception message. Roger On 10/7/2015 2:19 PM, Chris Hegarty wrote: > This primary motivation behind this bug [1] is the clearing out of > sun.misc, in preparation for JEP 260 [2]. > > sun.misc.IOUtils is a JDK internal convenience utility class that > provides a single method that offers bulk blocking InputStream read > semantics. In 9, java.io.InputStream has been retrofitted with two > methods that provide similar, but not quite the same, functionality, > readNBytes and readAllBytes, see JDK-8080835 [3]. > > There are a number of places where IOUtils can be replaced with the > appropriate supported API, readNBytes or readAllBytes. > > There are a number of places, mainly in the security implementation, > that required to read a specific number of bytes ( not to end of > stream ), where it is preferable to not preallocate the byte[] and > allow it to "grow" lazily, to be defensive against protocol errors. > These cases cannot use read[N|All]Bytes, so it makes sense to retain > IOUtils but locate it in a package, sun.security.util, that makes it > clear who its primary consumer is. > > http://cr.openjdk.java.net/~chegar/8138978/webrev.00/jdk/ > http://cr.openjdk.java.net/~chegar/8138978/webrev.00/hotspot/ > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8138978 > [2] https://bugs.openjdk.java.net/browse/JDK-8132928 > [3] https://bugs.openjdk.java.net/browse/JDK-8080835 From Alan.Bateman at oracle.com Wed Oct 7 19:04:01 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 7 Oct 2015 20:04:01 +0100 Subject: RFR [9] 8138978: Examine usages of sun.misc.IOUtils In-Reply-To: <A79916EE-69DE-49EB-9C22-3384290A7AFF@oracle.com> References: <A79916EE-69DE-49EB-9C22-3384290A7AFF@oracle.com> Message-ID: <56156CA1.5090405@oracle.com> On 07/10/2015 19:19, Chris Hegarty wrote: > This primary motivation behind this bug [1] is the clearing out of > sun.misc, in preparation for JEP 260 [2]. > > It would be nice if com/sun/jndi/ldap/Connection.java didn't have to use sun.security.util.IOUtils, could that one be fixed? The rest look fine. -Alan From chris.hegarty at oracle.com Wed Oct 7 19:15:43 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 7 Oct 2015 20:15:43 +0100 Subject: RFR [9] 8138978: Examine usages of sun.misc.IOUtils In-Reply-To: <56156CA1.5090405@oracle.com> References: <A79916EE-69DE-49EB-9C22-3384290A7AFF@oracle.com> <56156CA1.5090405@oracle.com> Message-ID: <460DA874-DD8C-4999-92BE-91CC7E0392D6@oracle.com> On 7 Oct 2015, at 20:04, Alan Bateman <Alan.Bateman at oracle.com> wrote: > On 07/10/2015 19:19, Chris Hegarty wrote: >> This primary motivation behind this bug [1] is the clearing out of >> sun.misc, in preparation for JEP 260 [2]. >> >> > It would be nice if com/sun/jndi/ldap/Connection.java didn't have to use sun.security.util.IOUtils, It certainly would be nice. > could that one be fixed? I didn?t look too hard at this because sun.security.util is already exported to java.naming, but yes I could write a readFully variant that works for this. I?ll take a closer look. > The rest look fine. Thanks. -Chris. > -Alan From chris.hegarty at oracle.com Wed Oct 7 19:57:16 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 7 Oct 2015 20:57:16 +0100 Subject: RFR [9] 8138978: Examine usages of sun.misc.IOUtils In-Reply-To: <460DA874-DD8C-4999-92BE-91CC7E0392D6@oracle.com> References: <A79916EE-69DE-49EB-9C22-3384290A7AFF@oracle.com> <56156CA1.5090405@oracle.com> <460DA874-DD8C-4999-92BE-91CC7E0392D6@oracle.com> Message-ID: <7724B104-27B8-4C07-95F9-F6D00D92FCCC@oracle.com> On 7 Oct 2015, at 20:15, Chris Hegarty <chris.hegarty at oracle.com> wrote: > On 7 Oct 2015, at 20:04, Alan Bateman <Alan.Bateman at oracle.com> wrote: > >> On 07/10/2015 19:19, Chris Hegarty wrote: >>> This primary motivation behind this bug [1] is the clearing out of >>> sun.misc, in preparation for JEP 260 [2]. >>> >>> >> It would be nice if com/sun/jndi/ldap/Connection.java didn't have to use sun.security.util.IOUtils, > > It certainly would be nice. > >> could that one be fixed? > > I didn?t look too hard at this because sun.security.util > is already exported to java.naming, but yes I could > write a readFully variant that works for this. I?ll take a > closer look. I updated Connection with a readFully that has the same semantics as IOUtils. http://cr.openjdk.java.net/~chegar/8138978/webrev.01/jdk/ -Chris. From sebastian.sickelmann at gmx.de Wed Oct 7 19:59:12 2015 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Wed, 7 Oct 2015 21:59:12 +0200 Subject: RFR: 5108778 Too many instances of java.lang.Boolean created in Java application(core-libs) Message-ID: <56157990.7020506@gmx.de> Hello, Actually I am searching through the JBS for low hanging fruits. Right now i am looking through the openjdk-sources and try to evaluate if i can make something about JDK-5108778. Please find my webrevs for the jdk, jaxp, jaxws and corba repos at: http://cr.openjdk.java.net/~sebastian/5108778/core-libs/webrev.00/ http://cr.openjdk.java.net/~sebastian/5108778/jaxp/webrev.00/ http://cr.openjdk.java.net/~sebastian/5108778/jaxws/webrev.00/ http://cr.openjdk.java.net/~sebastian/5108778/corba/webrev.00/ I hope for jaxp,jaxws and corba this mailinglist is also the right place. jdk: The Boolean constructors are @Deprecated now so that we get compile-warnings for the uses. See also [0] and [1] jaxp: For the change in XBoolean (jaxp) i thought it would be more readable than the autoboxing solution. jaxws: The changes in jaxws are in a generated class. I would love to fix this in the source, but i have no clue where the real source could be. corba: For all calls against com.sun.tools.corba.se.idl.constExpr.Expression.value(Object) i used the valueOf solution instead of the autoboxing for better readability. For some general discussion on regression-tests for this please find the thread in discuss[0][1] and for the general suggestion to make more wrapper-type-constructors deprecated find [2] at core-libs-dev. [0] http://mail.openjdk.java.net/pipermail/discuss/2015-September/003804.html [1] http://mail.openjdk.java.net/pipermail/discuss/2015-October/003805.html [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035642.html -- Sebastian From Roger.Riggs at Oracle.com Wed Oct 7 19:59:56 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 7 Oct 2015 15:59:56 -0400 Subject: RFR [9] 8138978: Examine usages of sun.misc.IOUtils In-Reply-To: <7724B104-27B8-4C07-95F9-F6D00D92FCCC@oracle.com> References: <A79916EE-69DE-49EB-9C22-3384290A7AFF@oracle.com> <56156CA1.5090405@oracle.com> <460DA874-DD8C-4999-92BE-91CC7E0392D6@oracle.com> <7724B104-27B8-4C07-95F9-F6D00D92FCCC@oracle.com> Message-ID: <561579BC.1050607@Oracle.com> Hi, Yea, but now we have duplicated code... Does it ever go away? Roger On 10/7/2015 3:57 PM, Chris Hegarty wrote: > On 7 Oct 2015, at 20:15, Chris Hegarty <chris.hegarty at oracle.com> wrote: > >> On 7 Oct 2015, at 20:04, Alan Bateman <Alan.Bateman at oracle.com> wrote: >> >>> On 07/10/2015 19:19, Chris Hegarty wrote: >>>> This primary motivation behind this bug [1] is the clearing out of >>>> sun.misc, in preparation for JEP 260 [2]. >>>> >>>> >>> It would be nice if com/sun/jndi/ldap/Connection.java didn't have to use sun.security.util.IOUtils, >> It certainly would be nice. >> >>> could that one be fixed? >> I didn?t look too hard at this because sun.security.util >> is already exported to java.naming, but yes I could >> write a readFully variant that works for this. I?ll take a >> closer look. > I updated Connection with a readFully that has the same > semantics as IOUtils. > > http://cr.openjdk.java.net/~chegar/8138978/webrev.01/jdk/ > > -Chris. From Alan.Bateman at oracle.com Wed Oct 7 20:28:50 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 7 Oct 2015 21:28:50 +0100 Subject: RFR [9] 8138978: Examine usages of sun.misc.IOUtils In-Reply-To: <7724B104-27B8-4C07-95F9-F6D00D92FCCC@oracle.com> References: <A79916EE-69DE-49EB-9C22-3384290A7AFF@oracle.com> <56156CA1.5090405@oracle.com> <460DA874-DD8C-4999-92BE-91CC7E0392D6@oracle.com> <7724B104-27B8-4C07-95F9-F6D00D92FCCC@oracle.com> Message-ID: <56158082.4050304@oracle.com> On 07/10/2015 20:57, Chris Hegarty wrote: > : > I updated Connection with a readFully that has the same > semantics as IOUtils. > > http://cr.openjdk.java.net/~chegar/8138978/webrev.01/jdk/ > I agree with Roger. Couldn't this be changed to use create an array of length seqlen and use readNBytes? -Alan From john.r.rose at oracle.com Wed Oct 7 22:01:31 2015 From: john.r.rose at oracle.com (John Rose) Date: Wed, 7 Oct 2015 15:01:31 -0700 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <561245E0.8030708@redhat.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561245E0.8030708@redhat.com> Message-ID: <38110705-2789-4050-913C-0568DD8B61E9@oracle.com> On Oct 5, 2015, at 2:41 AM, Andrew Haley <aph at redhat.com> wrote: > > Hi Gil, > > On 04/10/15 17:22, Gil Tene wrote: > >> Summary >> >> Add an API that would allow Java code to hint that a spin loop is >> being executed. > > > I don't think this will work for ARM, which has a rather different > spinlock mechanism. > > Instead of PAUSE, we wait on a lock word with WFE. WFE puts a core > into a lightweight sleep state waiting on a particular address (the > lock word) and a write to the lock word wakes it up. This is very > useful and somewhat analogous to 86's MONITOR/MWAIT. > > I can't immediately see how to generalize your proposal to ARM, which > is a shame. Suggestion: Allow the hint intrinsic to take an argument, from which a JIT can infer a memory dependency (if one is in fact present). Even if we are just targeting a PAUSE instruction, I think it is helpful to the JIT to add more connection points (beyond control flow) between the intrinsic and the surrounding loop. class jdk.internal.vm.SpinLoop { /** Provides a hint to the processor that a spin loop is in progress. * The boolean is returned unchanged. The processor may assume * that the loop is likely to continue as long as the boolean is false. * The processor may pause or wait after a false result, if there is * some reason to believe that the boolean argument, if re-evaluated, * will be false again. Any pausing behavior is system-specific. * The processor may not pause indefinitely. * <p>Example: * <blockquote><pre>{@code MyMailbox mb = ?; while (true) { if (!pollSpinExit(mb.hasMail()) continue; Object m = mb.getMail(); if (m != null) return m; } * }</pre></blockquote> * / @jdk.internal.HotSpotIntrinsicCandidate public static boolean pollSpinExit(boolean spinExit) { return spinExit; } } I'm going to guess that the extra hinting provided by the parameter would make it easier for a JIT to generate MWAIT and WFEs. Also, the boolean argument is easy to profile in the interpreter, if that's what a VM wants to do. For a similar mechanism (which again uses a boolean to provide IR connection to a data dependency), see: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/fe40b31c0e52/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java#l697 <http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/fe40b31c0e52/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java#l697> In fact, something like the profileBoolean intrinsic might be useful to allow spin loops to gather their own statistics. Getting the array allocation right might require an invokedynamic site (or some equivalent, like a static method handle), in order to control the allocation of profile state per call site. HTH ? John P.S. I agree with others that this needs cooking, in a jdk.internal place, before it is ready for SE. From Roger.Riggs at Oracle.com Wed Oct 7 22:24:26 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 7 Oct 2015 18:24:26 -0400 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <1391860289.1215500.1444171338590.JavaMail.zimbra@u-pem.fr> References: <5613D01F.3000107@Oracle.com> <CACzrW9CHGGpcDGQh2FoeFwgTwXr1besNdt42L3+RE6Cy7jPMLg@mail.gmail.com> <5613D635.6000305@Oracle.com> <CACzrW9C2bomoiA+hQcq6=H7QvMuBu2c7wmOGYHwq31b6Z=M18A@mail.gmail.com> <5613FEE6.2010907@oracle.com> <1391860289.1215500.1444171338590.JavaMail.zimbra@u-pem.fr> Message-ID: <56159B9A.4040404@Oracle.com> Hi, The original intent was to simplify the filling in of default values (even if null). I took Remi's point about the canonical coalescing operator not always returning non-null but the push seems to be in the direction of making sure the result is always non-null. I'd rather add a few very useful methods and avoid those with diminishing returns. I note that nulls are discovered eventually, but doing more aggressive checking is preferred. I expect the compiler is able to squeeze out all the extra checks. In the current context of Objects that the jdk, I read the naming pattern of firstNonNull to imply access to some sequential data structure like an array or list; but it doesn't gel with me to apply it to the arg list (unless it was varargs). The pattern of naming us "of" as being factory producing an object from the arguments seems apropos and is concise. Please consider and comment: <T> T nonNullOf(T obj, T defaultObj); <T> T nonNullOf(T, obj, Supplier<T> defaultSupplier); Details are in the updated webrev: http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ Regards, Roger On 10/6/2015 6:42 PM, Remi Forax wrote: > Null coalescing is a popular operator in several languages [1] and the usual semantics is nullOrElse and not firstNonNull. > In languages like Kotlin or Swift, because there is a distinction between Object and Object?, it's not a big deal, you can not de-reference null by error, anyway. > > Also note that nullOrElseGet, the one that takes a supplier also exists in Groovy and Kotlin under the name null safe navigation. > > So even if i prefer the semantics of firstNonNull, i think we should also include both nullOrElse and nullOrElseGet. > > regards, > R?mi > > [1] https://en.wikipedia.org/wiki/Null_coalescing_operator > > - From scolebourne at joda.org Wed Oct 7 22:44:23 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 7 Oct 2015 23:44:23 +0100 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <56159B9A.4040404@Oracle.com> References: <5613D01F.3000107@Oracle.com> <CACzrW9CHGGpcDGQh2FoeFwgTwXr1besNdt42L3+RE6Cy7jPMLg@mail.gmail.com> <5613D635.6000305@Oracle.com> <CACzrW9C2bomoiA+hQcq6=H7QvMuBu2c7wmOGYHwq31b6Z=M18A@mail.gmail.com> <5613FEE6.2010907@oracle.com> <1391860289.1215500.1444171338590.JavaMail.zimbra@u-pem.fr> <56159B9A.4040404@Oracle.com> Message-ID: <CACzrW9A-LA71srhcQ-VqaSvSOO=OHW9cCzM8qpCQbrXHO-Bupw@mail.gmail.com> On 7 October 2015 at 23:24, Roger Riggs <Roger.Riggs at oracle.com> wrote: > Please consider and comment: > > <T> T nonNullOf(T obj, T defaultObj); > <T> T nonNullOf(T, obj, Supplier<T> defaultSupplier); > > Details are in the updated webrev: > http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ I think I can live with that name. The Javadoc for the supplier variant needs to mention that an NPE is thrown if the supplier itself is null. @throws NullPointerException if {@code obj} is null and either {@code supplier} is null or the {@code supplier.get()} value is {@code null} Stephen From brent.christian at oracle.com Wed Oct 7 23:30:39 2015 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 7 Oct 2015 16:30:39 -0700 Subject: RFR 9 : 8138824 : java.lang.String: spec doesn't match impl when ignoring case - equalsIgnoreCase(), regionMatches() Message-ID: <5615AB1F.4050604@oracle.com> Hi, Please review my doc/spec change (no code) for 8138824. Bug: https://bugs.openjdk.java.net/browse/JDK-8138824 Webrev: http://cr.openjdk.java.net/~bchristi/8138824/webrev.0/ Specdiff: http://cr.openjdk.java.net/~bchristi/8138824/specdiff.0/overview-summary.html This change addresses a longstanding mismatch between spec and implementation, clarifies comparison methods which do not account for locale, and adds references to the locale-aware java.text.Collator. Thanks, -Brent From brian.burkhalter at oracle.com Thu Oct 8 02:02:34 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 7 Oct 2015 19:02:34 -0700 Subject: [9] RFR of 8032027: Add BigInteger square root methods In-Reply-To: <99CFE478-9AED-415B-897F-F07CA79FF67D@oracle.com> References: <75C5170A-11B1-437A-A411-C125D54406E9@oracle.com> <560FA21E.7050300@redhat.com> <99CFE478-9AED-415B-897F-F07CA79FF67D@oracle.com> Message-ID: <6D64676C-9A0B-42B7-905C-67CADC99F1DF@oracle.com> Joe / Andrew / Louis, Following up on the thread regarding https://bugs.openjdk.java.net/browse/JDK-8032027. I revised the algorithm similarly to what Louis suggested for the initial value of the iteration. I also tightened up the memory usage. The updated version is here: http://cr.openjdk.java.net/~bpb/8032027/webrev.01/ I did not at this time change the algorithm to compute the reciprocal of the square root instead of the root directly as Andrew suggested. Apparently this would improve the rate of convergence from quadratic to cubic, but I am inclined to file this and the Karatsuba square root as two separate issues for future enhancement. Likewise I did not yet include the special case which Joe mentioned for tuning performance for n < 2^1023 wherein the spread of unity bits is sufficiently small. If this does not make it into the current round of revisions a separate enhancement issue may likewise be filed. Thanks, Brian From gil at azul.com Thu Oct 8 07:39:30 2015 From: gil at azul.com (Gil Tene) Date: Thu, 8 Oct 2015 07:39:30 +0000 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <38110705-2789-4050-913C-0568DD8B61E9@oracle.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561245E0.8030708@redhat.com> <38110705-2789-4050-913C-0568DD8B61E9@oracle.com> Message-ID: <DDC775F6-63F7-4028-87B8-351594E5B9BE@azul.com> On Oct 7, 2015, at 3:01 PM, John Rose <john.r.rose at oracle.com<mailto:john.r.rose at oracle.com>> wrote: On Oct 5, 2015, at 2:41 AM, Andrew Haley <aph at redhat.com<mailto:aph at redhat.com>> wrote: Hi Gil, On 04/10/15 17:22, Gil Tene wrote: Summary Add an API that would allow Java code to hint that a spin loop is being executed. I don't think this will work for ARM, which has a rather different spinlock mechanism. Instead of PAUSE, we wait on a lock word with WFE. WFE puts a core into a lightweight sleep state waiting on a particular address (the lock word) and a write to the lock word wakes it up. This is very useful and somewhat analogous to 86's MONITOR/MWAIT. I can't immediately see how to generalize your proposal to ARM, which is a shame. Suggestion: Allow the hint intrinsic to take an argument, from which a JIT can infer a memory dependency (if one is in fact present). Even if we are just targeting a PAUSE instruction, I think it is helpful to the JIT to add more connection points (beyond control flow) between the intrinsic and the surrounding loop. class jdk.internal.vm.SpinLoop { /** Provides a hint to the processor that a spin loop is in progress. * The boolean is returned unchanged. The processor may assume * that the loop is likely to continue as long as the boolean is false. * The processor may pause or wait after a false result, if there is * some reason to believe that the boolean argument, if re-evaluated, * will be false again. Any pausing behavior is system-specific. * The processor may not pause indefinitely. * <p>Example: * <blockquote><pre>{@code MyMailbox mb = ?; while (true) { if (!pollSpinExit(mb.hasMail()) continue; Object m = mb.getMail(); if (m != null) return m; } * }</pre></blockquote> * / @jdk.internal.HotSpotIntrinsicCandidate public static boolean pollSpinExit(boolean spinExit) { return spinExit; } } I'm going to guess that the extra hinting provided by the parameter would make it easier for a JIT to generate MWAIT and WFEs. On the one hand: I like the idea of (an optional?) boolean parameter as a means of hinting at the thing that may terminate the spin. It's probably much more general than identifying a specific field or address. And it can be used to cover cases that poll multiple addresses (an or in the boolean) or look a termination time. If the JVM can track down the boolean's evaluation to dependencies on specific memory state changes, it could pass it on to hardware, if such hardware exists. On the other hard: Unfortunately, I don't think that hardware support that can receive the address information exists right now, and if/when it does, I'm not sure the semantics of passing the boolean through are enough to cover the actual way to use such hardware when it becomes available. It is probably premature to design a generic way to provide addresses and/or state to this "spin until something interesting changes" stuff without looking at working examples. A single watched address API is much more likely to fit current implementations without being fragile. ARM v8's WFE is probably the most real user-mode-accesible thing for this right now (MWAIT isn't real yet, as it's not accessible from user mode). We can look at an example of how a spinloop needs to coordinate the use of WFE, SEVL, and the evaluation of memory location with load exclusive operations here: http://lxr.free-electrons.com/source/arch/arm64/include/asm/spinlock.h . The tricky part is that the SEVL needs to immediately proceed the loop (and all accesses that need to be watched by the WFE), but can't be part of the loop (if were in the loop the WFE would always trigger immediately). But the code in the spinning loop can can only track a single address (the exclusive tag in load exclusive applies only the the most recent address used), so it would be wrong to allow generic code in the spin (it would have to be code that watches exactly one address). My suspicion is that the "right" way to capture the various ways a spin loop would need to interact with RFE logic will be different than tracking things that can generically affect the value of a boolean. E.g. the evaluation of the boolean could be based on multiple addresses, and since it's not clear (in the API) that this is a problem, the benefits derived would be fragile. In addition, there can validly be state mutating logic in the loop (e.g. counting), and implicitly re-executing that logic repeatedly inside a pollSpinExit(booleanThatOnlyWatchesOneAddress) call would seem "wrong" (the logic would presumably proceed the call, and it would be surprising to see it execute more than once within the call). I suspect that the right way to deal with RFE would be to provide an API that is closer to what it needs (and which is different from spin-hinting in the loop). E.g. some way to designate the beginning of the loop (so SEVL could be inserted right before it), some way to indicate the address that needs to use exclusive load in the loop, and some way to indicate that the loop is done. A possible way to do this is by wrapping the spinloop code and providing the address. E.g.: /** * Execute the spinCode repeatedly until it returns false. The processor * may assume that of the return value is false, it is likely to continue to * return false as long as the contents of the fieldToWatch field of the * objectToWatchFieldIn object does not change. he processor may therefore * pause or wait after a false result. The processor must not pause indefinitely, * but other pausing behavior is system-specific. */ void spinExecuteWhileTrue(BooleanSupplier spinCode, Field fieldToWatch, Object objectToWatchFieldIn); This would probably be a good fit for the specific WFE/SEVL semantics: the loop is implicit to the call, so the SEVL can be placed ahead of it; The loop can perform a load exclusive on the designated field of the designated object, and the spinCode can then do whatever it wants, with the understanding that no address other than the fieldToWatch is being watched to provide a timely exit from the loop. [Similar variant can be done for watching array fields]. The same single-watched-address API will probably fit MONITOR/MWAIT if it becomes available, and possibly ll/sc variants in other CPUs too. But wider-watching variants (NCAS, TSX) will not be covered by this API. And common uses of the x86 PAUSE instruction wouldn't either (since they are not limited at all to a limited number of addresses). Th good news is that even though the single-address-watching API only covers limited use cases, it can be easily implemented on architectures that only support spin hinting. So if someone's use case does fit into the API and is codes to that form, they are likely to gain benefits on both types of platforms. This leads me to believe that we are looking at two different APIs: - Spin loop hinting (matching the mature use cases of the PAUSE instruction in x86 and HW thread priority reduction in Power). - Single-watched-address spinning, matching ARM v8's WFE/SEVL use case, and potential other single address watchers (MONITOR/WAIT, and potential ll/sc based hints in other future cpus). I think the first use case is very mature and well understood, and certainly ready for a long term supported Java SE API. The second use case only applies to recently introduced hardware (ARM v8 right now), but it is fairly simple and *may* be useful more widely in the future. Since it can be beneficially intrinsified on platforms that support the wider spin-hinting API, we could add the single-address-watching for the JEP (as the two do seem related). I just worry that the questions about the usefulness and longevity of the single-address-watching use model may shadow the simplicity and apparent slam-dunkness of the spin loop hinting solution. Also, the boolean argument is easy to profile in the interpreter, if that's what a VM wants to do. For a similar mechanism (which again uses a boolean to provide IR connection to a data dependency), see: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/fe40b31c0e52/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java#l697 In fact, something like the profileBoolean intrinsic might be useful to allow spin loops to gather their own statistics. Getting the array allocation right might require an invokedynamic site (or some equivalent, like a static method handle), in order to control the allocation of profile state per call site. HTH ? John P.S. I agree with others that this needs cooking, in a jdk.internal place, before it is ready for SE. From chris.hegarty at oracle.com Thu Oct 8 08:29:18 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 8 Oct 2015 09:29:18 +0100 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <CACzrW9A-LA71srhcQ-VqaSvSOO=OHW9cCzM8qpCQbrXHO-Bupw@mail.gmail.com> References: <5613D01F.3000107@Oracle.com> <CACzrW9CHGGpcDGQh2FoeFwgTwXr1besNdt42L3+RE6Cy7jPMLg@mail.gmail.com> <5613D635.6000305@Oracle.com> <CACzrW9C2bomoiA+hQcq6=H7QvMuBu2c7wmOGYHwq31b6Z=M18A@mail.gmail.com> <5613FEE6.2010907@oracle.com> <1391860289.1215500.1444171338590.JavaMail.zimbra@u-pem.fr> <56159B9A.4040404@Oracle.com> <CACzrW9A-LA71srhcQ-VqaSvSOO=OHW9cCzM8qpCQbrXHO-Bupw@mail.gmail.com> Message-ID: <707F6616-FF1A-4767-84C9-BD2DE255F383@oracle.com> On 7 Oct 2015, at 23:44, Stephen Colebourne <scolebourne at joda.org> wrote: > On 7 October 2015 at 23:24, Roger Riggs <Roger.Riggs at oracle.com> wrote: >> Please consider and comment: >> >> <T> T nonNullOf(T obj, T defaultObj); >> <T> T nonNullOf(T, obj, Supplier<T> defaultSupplier); >> >> Details are in the updated webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ > > I think I can live with that name. +1 > The Javadoc for the supplier variant needs to mention that an NPE is > thrown if the supplier itself is null. > > @throws NullPointerException if {@code obj} is null and either {@code > supplier} is null or the {@code supplier.get()} value is {@code null} +1 Shouldn?t the supplier variant signature be as follows: public static <T> T nonNullOf(T obj, Supplier<? extends T> supplier) { -Chris. From paul.sandoz at oracle.com Thu Oct 8 08:32:05 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 8 Oct 2015 10:32:05 +0200 Subject: RFR [9] 8138978: Examine usages of sun.misc.IOUtils In-Reply-To: <56158082.4050304@oracle.com> References: <A79916EE-69DE-49EB-9C22-3384290A7AFF@oracle.com> <56156CA1.5090405@oracle.com> <460DA874-DD8C-4999-92BE-91CC7E0392D6@oracle.com> <7724B104-27B8-4C07-95F9-F6D00D92FCCC@oracle.com> <56158082.4050304@oracle.com> Message-ID: <7A05EA1B-F4C1-4512-ABED-DBB169E70B38@oracle.com> > On 7 Oct 2015, at 22:28, Alan Bateman <Alan.Bateman at oracle.com> wrote: > > > On 07/10/2015 20:57, Chris Hegarty wrote: >> : >> I updated Connection with a readFully that has the same >> semantics as IOUtils. >> >> http://cr.openjdk.java.net/~chegar/8138978/webrev.01/jdk/ >> > I agree with Roger. Couldn't this be changed to use create an array of length seqlen and use readNBytes? > It reads at most ?seqlen" bytes, so the array may be larger than necessary, which might be ok depending on whether one can trust "seqlen". The following pattern occurs a few times: byte[] b = is.readAllBytes(); if (len !- -1 && b.length != len) throw new EOFException(?) A further useful addition to consider would be an IS.readFulyl(int expectedLength). I suspect you could probably remove sun.security.util.IOUtils, if the assumption is correct than one never relies on a length of -1 or Integer.MAX_VALUE to signal ?readAllBytes?. That seems to be the case since all security usages pass in a true value for readAll. From what i can tell the length passed in is never < 0, since it is checked before hand. So that leaves the Integer.MAX_VALUE case, which i am not sure is intentional in the use-cases, as that will mean readAllBytes and not readNBytes. Paul From chris.hegarty at oracle.com Thu Oct 8 08:46:42 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 8 Oct 2015 09:46:42 +0100 Subject: RFR [9] 8138978: Examine usages of sun.misc.IOUtils In-Reply-To: <7A05EA1B-F4C1-4512-ABED-DBB169E70B38@oracle.com> References: <A79916EE-69DE-49EB-9C22-3384290A7AFF@oracle.com> <56156CA1.5090405@oracle.com> <460DA874-DD8C-4999-92BE-91CC7E0392D6@oracle.com> <7724B104-27B8-4C07-95F9-F6D00D92FCCC@oracle.com> <56158082.4050304@oracle.com> <7A05EA1B-F4C1-4512-ABED-DBB169E70B38@oracle.com> Message-ID: <18078001-183E-4A5F-BA97-28EF3D149EE8@oracle.com> On 8 Oct 2015, at 09:32, Paul Sandoz <paul.sandoz at oracle.com> wrote: > >> On 7 Oct 2015, at 22:28, Alan Bateman <Alan.Bateman at oracle.com> wrote: >> >> >> On 07/10/2015 20:57, Chris Hegarty wrote: >>> : >>> I updated Connection with a readFully that has the same >>> semantics as IOUtils. >>> >>> http://cr.openjdk.java.net/~chegar/8138978/webrev.01/jdk/ >>> >> I agree with Roger. Couldn't this be changed to use create an array of length seqlen and use readNBytes? >> > > It reads at most ?seqlen" bytes, so the array may be larger than necessary, which might be ok depending on whether one can trust "seqlen?. We do no trust ?seqlen?. :-( > The following pattern occurs a few times: > > byte[] b = is.readAllBytes(); > if (len !- -1 && b.length != len) throw new EOFException(?) > > A further useful addition to consider would be an IS.readFulyl(int expectedLength). Yes, I think a variant of readNBytes(long expectedLength), would be a useful addition. I can file a bug and add it to the I/O grab bag, 6852033 [1]. Then a further round of cleanup could possibly remove IOUtils completely. > I suspect you could probably remove sun.security.util.IOUtils, if the assumption is correct than one never relies on a length of -1 or Integer.MAX_VALUE to signal ?readAllBytes?. That seems to be the case since all security usages pass in a true value for readAll. From what i can tell the length passed in is never < 0, since it is checked before hand. So that leaves the Integer.MAX_VALUE case, which i am not sure is intentional in the use-cases, as that will mean readAllBytes and not readNBytes. -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-6852033 From forax at univ-mlv.fr Thu Oct 8 08:49:42 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 8 Oct 2015 10:49:42 +0200 (CEST) Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <56159B9A.4040404@Oracle.com> References: <5613D01F.3000107@Oracle.com> <CACzrW9CHGGpcDGQh2FoeFwgTwXr1besNdt42L3+RE6Cy7jPMLg@mail.gmail.com> <5613D635.6000305@Oracle.com> <CACzrW9C2bomoiA+hQcq6=H7QvMuBu2c7wmOGYHwq31b6Z=M18A@mail.gmail.com> <5613FEE6.2010907@oracle.com> <1391860289.1215500.1444171338590.JavaMail.zimbra@u-pem.fr> <56159B9A.4040404@Oracle.com> Message-ID: <1319440457.2004194.1444294182369.JavaMail.zimbra@u-pem.fr> Hi Roger, using overloads here seems to be a bad idea, as a nice puzzler, what does the compiler do for these two lines of code Supplier<String> supplier = Objects.nonNullOf(null, () -> null); Supplier<String> supplier2 = Objects.nonNullOf(null, () -> ""); The other issue is that defaultSupplier should allow covariant Supplier, the signature should be: <T> T nonNullOfGet(T obj, Supplier<? extends T> defaultSupplier) otherwise apart form the remark of Stephen, the code is Ok. cheers, R?mi ----- Mail original ----- > De: "Roger Riggs" <Roger.Riggs at Oracle.com> > ?: "core-libs-dev" <core-libs-dev at openjdk.java.net> > Envoy?: Jeudi 8 Octobre 2015 00:24:26 > Objet: Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null > > Hi, > > The original intent was to simplify the filling in of default values > (even if null). > I took Remi's point about the canonical coalescing operator not always > returning non-null > but the push seems to be in the direction of making sure the result is > always non-null. > I'd rather add a few very useful methods and avoid those with > diminishing returns. > > I note that nulls are discovered eventually, but doing more aggressive > checking is preferred. > I expect the compiler is able to squeeze out all the extra checks. > > In the current context of Objects that the jdk, I read the naming > pattern of firstNonNull to imply > access to some sequential data structure like an array or list; but it > doesn't gel with me to apply it to the arg list > (unless it was varargs). The pattern of naming us "of" as being > factory producing an object > from the arguments seems apropos and is concise. > > Please consider and comment: > > <T> T nonNullOf(T obj, T defaultObj); > <T> T nonNullOf(T, obj, Supplier<T> defaultSupplier); > > Details are in the updated webrev: > http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ > > Regards, Roger > > > On 10/6/2015 6:42 PM, Remi Forax wrote: > > Null coalescing is a popular operator in several languages [1] and the > > usual semantics is nullOrElse and not firstNonNull. > > In languages like Kotlin or Swift, because there is a distinction between > > Object and Object?, it's not a big deal, you can not de-reference null by > > error, anyway. > > > > Also note that nullOrElseGet, the one that takes a supplier also exists in > > Groovy and Kotlin under the name null safe navigation. > > > > So even if i prefer the semantics of firstNonNull, i think we should also > > include both nullOrElse and nullOrElseGet. > > > > regards, > > R?mi > > > > [1] https://en.wikipedia.org/wiki/Null_coalescing_operator > > > > - > > From paul.sandoz at oracle.com Thu Oct 8 08:55:14 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 8 Oct 2015 10:55:14 +0200 Subject: RFR [9] 8138978: Examine usages of sun.misc.IOUtils In-Reply-To: <18078001-183E-4A5F-BA97-28EF3D149EE8@oracle.com> References: <A79916EE-69DE-49EB-9C22-3384290A7AFF@oracle.com> <56156CA1.5090405@oracle.com> <460DA874-DD8C-4999-92BE-91CC7E0392D6@oracle.com> <7724B104-27B8-4C07-95F9-F6D00D92FCCC@oracle.com> <56158082.4050304@oracle.com> <7A05EA1B-F4C1-4512-ABED-DBB169E70B38@oracle.com> <18078001-183E-4A5F-BA97-28EF3D149EE8@oracle.com> Message-ID: <D5AD6515-7686-4FC1-959E-7599B7C3F5CF@oracle.com> > On 8 Oct 2015, at 10:46, Chris Hegarty <chris.hegarty at oracle.com> wrote: >> It reads at most ?seqlen" bytes, so the array may be larger than necessary, which might be ok depending on whether one can trust "seqlen?. > > We do no trust ?seqlen?. :-( > Good! >> The following pattern occurs a few times: >> >> byte[] b = is.readAllBytes(); >> if (len !- -1 && b.length != len) throw new EOFException(?) >> >> A further useful addition to consider would be an IS.readFulyl(int expectedLength). > > Yes, I think a variant of readNBytes(long expectedLength), > would be a useful addition. I can file a bug and add it to > the I/O grab bag, 6852033 [1]. Then a further round of > cleanup could possibly remove IOUtils completely. > Ok. Paul. From aph at redhat.com Thu Oct 8 09:28:15 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 8 Oct 2015 10:28:15 +0100 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <2C546647-3BC9-4A9D-938B-7192824B2D05@azul.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561245E0.8030708@redhat.com> <ED44A1CE-F28C-4EDA-89F8-B97CF2E3F3AB@azulsystems.com> <5614D461.8050403@redhat.com> <A5B98226-F31B-4873-A363-5C4B5DCC777D@azulsystems.com> <56153F8B.8000102@redhat.com> <2C546647-3BC9-4A9D-938B-7192824B2D05@azul.com> Message-ID: <5616372F.7090506@redhat.com> On 10/07/2015 09:21 PM, Gil Tene wrote: > Interesting. I was going off of the 32 bit ARM documentation. Looks like > ARMv8 improved on that, and did it implicitly (without requiring different > instructions). > > You can see the differences on the unlock path between the 32 bit and 64 bit implementations here: > http://lxr.free-electrons.com/source/arch/arm/include/asm/spinlock.h > http://lxr.free-electrons.com/source/arch/arm64/include/asm/spinlock.h Yeah, that's right. SEV is very broadcasty and not at all suited to large systems, which is obviously what v8 is aimed at. There are also local timer queues, BTW, and one of the things a timer can do is a local SEV. So we have just the right things, if we can ever figure out how to use them in Java! BTW, I apologize for hijacking your thread. Your JEP looks good, and I can't see any good reason that such a simple and non-intrusive API shouldn't go in. Andrew. From dl at cs.oswego.edu Thu Oct 8 10:58:04 2015 From: dl at cs.oswego.edu (Doug Lea) Date: Thu, 8 Oct 2015 06:58:04 -0400 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> Message-ID: <56164C3C.4050800@cs.oswego.edu> On 10/06/2015 09:28 PM, Gil Tene wrote: > > As for fitting in with larger-picture or theme things (listed above). I think that > agonizing over the choice of where to put this is important To avoid the kinds of problems we later saw when basic JVM methods were placed in odd places just for the sake of appearances (e.g., park/unpark), the best choice seems to be class Thread, as in: class Thread { // /** * A hint to the platform that the current thread is momentarily * unable to progress. ... add more guidance ... */ void spinYield(); } In principle, this would also allow the implementation to do an actual yield on uniprocessors or when the load average is high. Probably not in initial implementation though. Adding a method to class Thread risks name clashes with existing methods introduced in subclasses. So this might need a clunkier name to effectively eliminate the possibility. An analogous method could also be added (now or later) for MWAIT-based support for waits on the thread's park semaphore (which is more tractable than doing so for an arbitrary variable). An alternative to either is to add optional arguments to yield and park providing a hint about whether to context-switch. Joe Darcy: Thread.yield does set a precedent here: * A hint to the scheduler that the current thread is willing to yield * its current use of a processor. The scheduler is free to ignore this * hint. -Doug From david.lloyd at redhat.com Thu Oct 8 11:01:51 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 8 Oct 2015 06:01:51 -0500 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <56164C3C.4050800@cs.oswego.edu> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56164C3C.4050800@cs.oswego.edu> Message-ID: <56164D1F.405@redhat.com> On 10/08/2015 05:58 AM, Doug Lea wrote: > On 10/06/2015 09:28 PM, Gil Tene wrote: >> >> As for fitting in with larger-picture or theme things (listed above). >> I think that >> agonizing over the choice of where to put this is important > > To avoid the kinds of problems we later saw when basic JVM methods were > placed in odd places just for the sake of appearances (e.g., park/unpark), > the best choice seems to be class Thread, as in: > > class Thread { // > /** > * A hint to the platform that the current thread is momentarily > * unable to progress. ... add more guidance ... > */ > void spinYield(); > } > > In principle, this would also allow the implementation to do an actual > yield on uniprocessors or when the load average is high. Probably not > in initial implementation though. > > Adding a method to class Thread risks name clashes with existing > methods introduced in subclasses. So this might need a clunkier name > to effectively eliminate the possibility. If the method is static, then the impact of a clashing name should be fairly minimal. -- - DML From daniel.fuchs at oracle.com Thu Oct 8 12:26:02 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 8 Oct 2015 14:26:02 +0200 Subject: RFR: JDK-8046565: Platform Logger API and Service Message-ID: <561660DA.7070900@oracle.com> Hi, Please find below the webrev for a first prototype of JEP 264 - Platform Logger API and Service. JEP: http://openjdk.java.net/jeps/264 https://bugs.openjdk.java.net/browse/JDK-8046565 specdiff: http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/specdiff-api/overview-summary.html webrev: http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/webrev.01/ A prototype implementation was uploaded in the sandbox, branch named JDK-8046565-branch (Instructions on how to clone a sandbox branch can be found here: http://cr.openjdk.java.net/~chegar/docs/sandbox.html ) best regards, -- daniel From sean.mullan at oracle.com Thu Oct 8 12:34:00 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 8 Oct 2015 08:34:00 -0400 Subject: RFR [9] 8138978: Examine usages of sun.misc.IOUtils In-Reply-To: <A79916EE-69DE-49EB-9C22-3384290A7AFF@oracle.com> References: <A79916EE-69DE-49EB-9C22-3384290A7AFF@oracle.com> Message-ID: <561662B8.6070007@oracle.com> Looks fine to me, though I have one question below. On 10/7/15 2:19 PM, Chris Hegarty wrote: > This primary motivation behind this bug [1] is the clearing out of > sun.misc, in preparation for JEP 260 [2]. > > sun.misc.IOUtils is a JDK internal convenience utility class that > provides a single method that offers bulk blocking InputStream read > semantics. In 9, java.io.InputStream has been retrofitted with two > methods that provide similar, but not quite the same, functionality, > readNBytes and readAllBytes, see JDK-8080835 [3]. > > There are a number of places where IOUtils can be replaced with the > appropriate supported API, readNBytes or readAllBytes. > > There are a number of places, mainly in the security implementation, > that required to read a specific number of bytes ( not to end of > stream ), where it is preferable to not preallocate the byte[] and > allow it to "grow" lazily, to be defensive against protocol errors. > These cases cannot use read[N|All]Bytes, so it makes sense to retain > IOUtils but locate it in a package, sun.security.util, that makes it > clear who its primary consumer is. Would it make sense to add a method to InputStream that provides that functionality the security classes need? --Sean > > http://cr.openjdk.java.net/~chegar/8138978/webrev.00/jdk/ > http://cr.openjdk.java.net/~chegar/8138978/webrev.00/hotspot/ > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8138978 > [2] https://bugs.openjdk.java.net/browse/JDK-8132928 > [3] https://bugs.openjdk.java.net/browse/JDK-8080835 > From vitalyd at gmail.com Thu Oct 8 14:39:30 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 8 Oct 2015 10:39:30 -0400 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <257A3F23-9F15-4BFF-A42B-AAC979A0C8A6@gmail.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56164C3C.4050800@cs.oswego.edu> <257A3F23-9F15-4BFF-A42B-AAC979A0C8A6@gmail.com> Message-ID: <CAHjP37FhU2jAt66ZqTJ1DNb9XMhZavtEGfZXL+jd2BfOdBgJeA@mail.gmail.com> I agree with David that it should be static though; it doesn't really make sense to be instance. sent from my phone On Oct 8, 2015 10:13 AM, "Kirk Pepperdine" <kirk.pepperdine at gmail.com> wrote: > Hi Doug, > > Brilliant thought, absolutely?. so obvious that it is completely hidden in > plain sight. In the past dumping these things into unsafe was a huge > mistake. It?s like a back alley for homeless behavior. If you think about > it, it?s the thread that would be spinning so it?s obviously the thread > that needs the hint. It should own the behavior? Very clear thinking. > > Regards, > Kirk > > > On Oct 8, 2015, at 12:58 PM, Doug Lea <dl at cs.oswego.edu> wrote: > > > > On 10/06/2015 09:28 PM, Gil Tene wrote: > >> > >> As for fitting in with larger-picture or theme things (listed above). I > think that > >> agonizing over the choice of where to put this is important > > > > To avoid the kinds of problems we later saw when basic JVM methods were > > placed in odd places just for the sake of appearances (e.g., > park/unpark), > > the best choice seems to be class Thread, as in: > > > > class Thread { // > > /** > > * A hint to the platform that the current thread is momentarily > > * unable to progress. ... add more guidance ... > > */ > > void spinYield(); > > } > > > > In principle, this would also allow the implementation to do an actual > > yield on uniprocessors or when the load average is high. Probably not > > in initial implementation though. > > > > Adding a method to class Thread risks name clashes with existing > > methods introduced in subclasses. So this might need a clunkier name > > to effectively eliminate the possibility. > > > > An analogous method could also be added (now or later) > > for MWAIT-based support for waits on the thread's park semaphore > > (which is more tractable than doing so for an arbitrary variable). > > > > An alternative to either is to add optional arguments to > > yield and park providing a hint about whether to context-switch. > > > > Joe Darcy: Thread.yield does set a precedent here: > > > > * A hint to the scheduler that the current thread is willing to yield > > * its current use of a processor. The scheduler is free to ignore this > > * hint. > > > > > > -Doug > > > > From Roger.Riggs at Oracle.com Thu Oct 8 14:44:54 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 8 Oct 2015 10:44:54 -0400 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <1319440457.2004194.1444294182369.JavaMail.zimbra@u-pem.fr> References: <5613D01F.3000107@Oracle.com> <CACzrW9CHGGpcDGQh2FoeFwgTwXr1besNdt42L3+RE6Cy7jPMLg@mail.gmail.com> <5613D635.6000305@Oracle.com> <CACzrW9C2bomoiA+hQcq6=H7QvMuBu2c7wmOGYHwq31b6Z=M18A@mail.gmail.com> <5613FEE6.2010907@oracle.com> <1391860289.1215500.1444171338590.JavaMail.zimbra@u-pem.fr> <56159B9A.4040404@Oracle.com> <1319440457.2004194.1444294182369.JavaMail.zimbra@u-pem.fr> Message-ID: <56168166.5030903@Oracle.com> Hi Remi, On 10/8/2015 4:49 AM, Remi Forax wrote: > Hi Roger, > using overloads here seems to be a bad idea, > as a nice puzzler, what does the compiler do for these two lines of code > Supplier<String> supplier = Objects.nonNullOf(null, () -> null); > Supplier<String> supplier2 = Objects.nonNullOf(null, () -> ""); The first form compiled and threw the expected NPE at runtime. In the second case, the () -> "" is a supplier<String> not a Supplier<Supplier<String>>. The compiler correctly produced a error. I don't think the method name will help the developer much and just makes the name longer for everyone else who is not producing a Supplier<Supplier<T>>. > > The other issue is that defaultSupplier should allow covariant Supplier, > the signature should be: > <T> T nonNullOfGet(T obj, Supplier<? extends T> defaultSupplier) Right, as Chris pointed out also. Thanks, Roger > > otherwise apart form the remark of Stephen, the code is Ok. > > cheers, > R?mi > > > ----- Mail original ----- >> De: "Roger Riggs" <Roger.Riggs at Oracle.com> >> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net> >> Envoy?: Jeudi 8 Octobre 2015 00:24:26 >> Objet: Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null >> >> Hi, >> >> The original intent was to simplify the filling in of default values >> (even if null). >> I took Remi's point about the canonical coalescing operator not always >> returning non-null >> but the push seems to be in the direction of making sure the result is >> always non-null. >> I'd rather add a few very useful methods and avoid those with >> diminishing returns. >> >> I note that nulls are discovered eventually, but doing more aggressive >> checking is preferred. >> I expect the compiler is able to squeeze out all the extra checks. >> >> In the current context of Objects that the jdk, I read the naming >> pattern of firstNonNull to imply >> access to some sequential data structure like an array or list; but it >> doesn't gel with me to apply it to the arg list >> (unless it was varargs). The pattern of naming us "of" as being >> factory producing an object >> from the arguments seems apropos and is concise. >> >> Please consider and comment: >> >> <T> T nonNullOf(T obj, T defaultObj); >> <T> T nonNullOf(T, obj, Supplier<T> defaultSupplier); >> >> Details are in the updated webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ >> >> Regards, Roger >> >> >> On 10/6/2015 6:42 PM, Remi Forax wrote: >>> Null coalescing is a popular operator in several languages [1] and the >>> usual semantics is nullOrElse and not firstNonNull. >>> In languages like Kotlin or Swift, because there is a distinction between >>> Object and Object?, it's not a big deal, you can not de-reference null by >>> error, anyway. >>> >>> Also note that nullOrElseGet, the one that takes a supplier also exists in >>> Groovy and Kotlin under the name null safe navigation. >>> >>> So even if i prefer the semantics of firstNonNull, i think we should also >>> include both nullOrElse and nullOrElseGet. >>> >>> regards, >>> R?mi >>> >>> [1] https://en.wikipedia.org/wiki/Null_coalescing_operator >>> >>> - >> From dl at cs.oswego.edu Thu Oct 8 14:56:28 2015 From: dl at cs.oswego.edu (Doug Lea) Date: Thu, 8 Oct 2015 10:56:28 -0400 Subject: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal In-Reply-To: <56164D1F.405@redhat.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56164C3C.4050800@cs.oswego.edu> <56164D1F.405@redhat.com> Message-ID: <5616841C.6000406@cs.oswego.edu> On 10/08/2015 07:01 AM, David M. Lloyd wrote: > On 10/08/2015 05:58 AM, Doug Lea wrote: > >> class Thread { // >> /** >> * A hint to the platform that the current thread is momentarily >> * unable to progress. ... add more guidance ... >> */ >> void spinYield(); should be: public static void spinYield(); >> } >> >> In principle, this would also allow the implementation to do an actual >> yield on uniprocessors or when the load average is high. Probably not >> in initial implementation though. >> >> Adding a method to class Thread risks name clashes with existing >> methods introduced in subclasses. So this might need a clunkier name >> to effectively eliminate the possibility. > > If the method is static, then the impact of a clashing name should be fairly > minimal. > Right. For statics, pretty much the only concern is whether reflective mechanics (Class.getMethod etc) return unexpected entries that would break existing code. The name "spinYield" seems unlikely enough to be a problem though. -Doug From Roger.Riggs at Oracle.com Thu Oct 8 15:26:29 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 8 Oct 2015 11:26:29 -0400 Subject: RFR 9 : 8138824 : java.lang.String: spec doesn't match impl when ignoring case - equalsIgnoreCase(), regionMatches() In-Reply-To: <5615AB1F.4050604@oracle.com> References: <5615AB1F.4050604@oracle.com> Message-ID: <56168B25.80605@Oracle.com> Hi Brent, I'm not sure we have a best practice for referring to other classes but I think that the {@code } references to Collator could be {@link java.text.Collator} and the @See tags can be omitted. It puts the link where the reader sees the reference and is just as informative. Otherwise, looks good. Roger On 10/7/2015 7:30 PM, Brent Christian wrote: > Hi, > > Please review my doc/spec change (no code) for 8138824. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8138824 > Webrev: http://cr.openjdk.java.net/~bchristi/8138824/webrev.0/ > Specdiff: > http://cr.openjdk.java.net/~bchristi/8138824/specdiff.0/overview-summary.html > > This change addresses a longstanding mismatch between spec and > implementation, clarifies comparison methods which do not account for > locale, and adds references to the locale-aware java.text.Collator. > > Thanks, > -Brent > From jeanphilippe.bempel at ullink.com Thu Oct 8 15:37:31 2015 From: jeanphilippe.bempel at ullink.com (Jean Philippe Bempel) Date: Thu, 8 Oct 2015 17:37:31 +0200 Subject: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal In-Reply-To: <56164D1F.405@redhat.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56164C3C.4050800@cs.oswego.edu> <56164D1F.405@redhat.com> Message-ID: <CABLF9Evc10X85Rq3Xe1ZFwNcovvwKSnkem-rfH7g6=JP+ixvgw@mail.gmail.com> On Thu, Oct 8, 2015 at 1:01 PM, David M. Lloyd <david.lloyd at redhat.com> wrote: > > If the method is static, then the impact of a clashing name should be > fairly minimal. > > +1 on this, I do not see the benefit of an instance method either here. But good idea, Doug, for Thread class and the yield hint :) -- *The information contained in or attached to this email is strictly confidential. If you are not the intended recipient, please notify us immediately by telephone and return the message to us.* From brent.christian at oracle.com Thu Oct 8 15:55:00 2015 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 08 Oct 2015 08:55:00 -0700 Subject: RFR 9 : 8138824 : java.lang.String: spec doesn't match impl when ignoring case - equalsIgnoreCase(), regionMatches() In-Reply-To: <56168B25.80605@Oracle.com> References: <5615AB1F.4050604@oracle.com> <56168B25.80605@Oracle.com> Message-ID: <561691D4.2080209@oracle.com> Sounds reasonable - I'll make the change. Thanks, Roger -Brent On 10/08/2015 08:26 AM, Roger Riggs wrote: > Hi Brent, > > I'm not sure we have a best practice for referring to other classes but > I think that the {@code } references > to Collator could be {@link java.text.Collator} and the @See tags can be > omitted. > It puts the link where the reader sees the reference and is just as > informative. > > Otherwise, looks good. > > Roger > > > On 10/7/2015 7:30 PM, Brent Christian wrote: >> Hi, >> >> Please review my doc/spec change (no code) for 8138824. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8138824 >> Webrev: http://cr.openjdk.java.net/~bchristi/8138824/webrev.0/ >> Specdiff: >> http://cr.openjdk.java.net/~bchristi/8138824/specdiff.0/overview-summary.html >> >> >> This change addresses a longstanding mismatch between spec and >> implementation, clarifies comparison methods which do not account for >> locale, and adds references to the locale-aware java.text.Collator. >> >> Thanks, >> -Brent >> > From naoto.sato at oracle.com Thu Oct 8 15:57:27 2015 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 8 Oct 2015 08:57:27 -0700 Subject: RFR 9 : 8138824 : java.lang.String: spec doesn't match impl when ignoring case - equalsIgnoreCase(), regionMatches() In-Reply-To: <5615AB1F.4050604@oracle.com> References: <5615AB1F.4050604@oracle.com> Message-ID: <56169267.3060505@oracle.com> Hi Brent, I wonder whether we should add a negative test case, in which lowercasing/uppercasing on the originals would differ but String.equalsIgnoreCase() returns true. Naoto On 10/7/15 4:30 PM, Brent Christian wrote: > Hi, > > Please review my doc/spec change (no code) for 8138824. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8138824 > Webrev: http://cr.openjdk.java.net/~bchristi/8138824/webrev.0/ > Specdiff: > http://cr.openjdk.java.net/~bchristi/8138824/specdiff.0/overview-summary.html > > > This change addresses a longstanding mismatch between spec and > implementation, clarifies comparison methods which do not account for > locale, and adds references to the locale-aware java.text.Collator. > > Thanks, > -Brent > From ivan.gerasimov at oracle.com Thu Oct 8 16:13:23 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 8 Oct 2015 19:13:23 +0300 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <56159B9A.4040404@Oracle.com> References: <5613D01F.3000107@Oracle.com> <CACzrW9CHGGpcDGQh2FoeFwgTwXr1besNdt42L3+RE6Cy7jPMLg@mail.gmail.com> <5613D635.6000305@Oracle.com> <CACzrW9C2bomoiA+hQcq6=H7QvMuBu2c7wmOGYHwq31b6Z=M18A@mail.gmail.com> <5613FEE6.2010907@oracle.com> <1391860289.1215500.1444171338590.JavaMail.zimbra@u-pem.fr> <56159B9A.4040404@Oracle.com> Message-ID: <56169623.7080501@oracle.com> Hi Roger! In the test, why the 'result' variable is needed? 242 String result; 243 errors += (result = Objects.nonNullOf(nullString, defString)) == defString ? 0 : 1; 244 errors += (result = Objects.nonNullOf(nonNullString, defString)) == nonNullString ? 0 : 1; 245 errors += (result = Objects.nonNullOf(nonNullString, null)) == nonNullString ? 0 : 1; I don't see its value being used anywhere. Sincerely yours, Ivan On 08.10.2015 1:24, Roger Riggs wrote: > Hi, > > The original intent was to simplify the filling in of default values > (even if null). > I took Remi's point about the canonical coalescing operator not > always returning non-null > but the push seems to be in the direction of making sure the result is > always non-null. > I'd rather add a few very useful methods and avoid those with > diminishing returns. > > I note that nulls are discovered eventually, but doing more aggressive > checking is preferred. > I expect the compiler is able to squeeze out all the extra checks. > > In the current context of Objects that the jdk, I read the naming > pattern of firstNonNull to imply > access to some sequential data structure like an array or list; but it > doesn't gel with me to apply it to the arg list > (unless it was varargs). The pattern of naming us "of" as being > factory producing an object > from the arguments seems apropos and is concise. > > Please consider and comment: > > <T> T nonNullOf(T obj, T defaultObj); > <T> T nonNullOf(T, obj, Supplier<T> defaultSupplier); > > Details are in the updated webrev: > http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ > > Regards, Roger > > > On 10/6/2015 6:42 PM, Remi Forax wrote: >> Null coalescing is a popular operator in several languages [1] and >> the usual semantics is nullOrElse and not firstNonNull. >> In languages like Kotlin or Swift, because there is a distinction >> between Object and Object?, it's not a big deal, you can not >> de-reference null by error, anyway. >> >> Also note that nullOrElseGet, the one that takes a supplier also >> exists in Groovy and Kotlin under the name null safe navigation. >> >> So even if i prefer the semantics of firstNonNull, i think we should >> also include both nullOrElse and nullOrElseGet. >> >> regards, >> R?mi >> >> [1] https://en.wikipedia.org/wiki/Null_coalescing_operator >> >> - > > From mark.reinhold at oracle.com Thu Oct 8 16:33:18 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 08 Oct 2015 09:33:18 -0700 Subject: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal In-Reply-To: <5616841C.6000406@cs.oswego.edu> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com>, <561428BC.3060806@cs.oswego.edu>, <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com>, <56164C3C.4050800@cs.oswego.edu>, <56164D1F.405@redhat.com>, <5616841C.6000406@cs.oswego.edu> Message-ID: <20151008093318.990378@eggemoggin.niobe.net> 2015/10/8 7:56 -0700, dl at cs.oswego.edu: >>> ... >>> >>> class Thread { // >>> /** >>> * A hint to the platform that the current thread is momentarily >>> * unable to progress. ... add more guidance ... >>> */ >>> void spinYield(); > > should be: > public static void spinYield(); Yes -- let's keep this simple. It's just one method, another hint in j.l.Thread which can be ignored (or not) by the VM. This concept seems sufficiently well understood, based on its use in other platforms, that putting it directly into j.l.Thread is not a huge risk. I don't see a strong need for this to start out as a JDK-specific API. - Mark From Roger.Riggs at Oracle.com Thu Oct 8 16:33:52 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 8 Oct 2015 12:33:52 -0400 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <56169623.7080501@oracle.com> References: <5613D01F.3000107@Oracle.com> <CACzrW9CHGGpcDGQh2FoeFwgTwXr1besNdt42L3+RE6Cy7jPMLg@mail.gmail.com> <5613D635.6000305@Oracle.com> <CACzrW9C2bomoiA+hQcq6=H7QvMuBu2c7wmOGYHwq31b6Z=M18A@mail.gmail.com> <5613FEE6.2010907@oracle.com> <1391860289.1215500.1444171338590.JavaMail.zimbra@u-pem.fr> <56159B9A.4040404@Oracle.com> <56169623.7080501@oracle.com> Message-ID: <56169AF0.2050902@Oracle.com> Hi Ivan, It was there, for compile time, to confirm the type signature of the return value; the type checking on == isn't as strong as assignment. But it would not be needed more than once. Roger On 10/8/2015 12:13 PM, Ivan Gerasimov wrote: > Hi Roger! > > In the test, why the 'result' variable is needed? > > 242 String result; > 243 errors += (result = Objects.nonNullOf(nullString, > defString)) == defString ? 0 : 1; > 244 errors += (result = Objects.nonNullOf(nonNullString, > defString)) == nonNullString ? 0 : 1; > 245 errors += (result = Objects.nonNullOf(nonNullString, > null)) == nonNullString ? 0 : 1; > > I don't see its value being used anywhere. > > Sincerely yours, > Ivan > > On 08.10.2015 1:24, Roger Riggs wrote: >> Hi, >> >> The original intent was to simplify the filling in of default values >> (even if null). >> I took Remi's point about the canonical coalescing operator not >> always returning non-null >> but the push seems to be in the direction of making sure the result >> is always non-null. >> I'd rather add a few very useful methods and avoid those with >> diminishing returns. >> >> I note that nulls are discovered eventually, but doing more >> aggressive checking is preferred. >> I expect the compiler is able to squeeze out all the extra checks. >> >> In the current context of Objects that the jdk, I read the naming >> pattern of firstNonNull to imply >> access to some sequential data structure like an array or list; but >> it doesn't gel with me to apply it to the arg list >> (unless it was varargs). The pattern of naming us "of" as being >> factory producing an object >> from the arguments seems apropos and is concise. >> >> Please consider and comment: >> >> <T> T nonNullOf(T obj, T defaultObj); >> <T> T nonNullOf(T, obj, Supplier<T> defaultSupplier); >> >> Details are in the updated webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ >> >> Regards, Roger >> >> >> On 10/6/2015 6:42 PM, Remi Forax wrote: >>> Null coalescing is a popular operator in several languages [1] and >>> the usual semantics is nullOrElse and not firstNonNull. >>> In languages like Kotlin or Swift, because there is a distinction >>> between Object and Object?, it's not a big deal, you can not >>> de-reference null by error, anyway. >>> >>> Also note that nullOrElseGet, the one that takes a supplier also >>> exists in Groovy and Kotlin under the name null safe navigation. >>> >>> So even if i prefer the semantics of firstNonNull, i think we should >>> also include both nullOrElse and nullOrElseGet. >>> >>> regards, >>> R?mi >>> >>> [1] https://en.wikipedia.org/wiki/Null_coalescing_operator >>> >>> - >> >> > From paul.sandoz at oracle.com Thu Oct 8 16:35:45 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 8 Oct 2015 18:35:45 +0200 Subject: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal In-Reply-To: <20151008093318.990378@eggemoggin.niobe.net> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56164C3C.4050800@cs.oswego.edu> <56164D1F.405@redhat.com> <5616841C.6000406@cs.oswego.edu> <20151008093318.990378@eggemoggin.niobe.net> Message-ID: <C4F66753-5C67-4F96-9132-079A0F91EBBB@oracle.com> > On 8 Oct 2015, at 18:33, mark.reinhold at oracle.com wrote: > > 2015/10/8 7:56 -0700, dl at cs.oswego.edu: >>>> ... >>>> >>>> class Thread { // >>>> /** >>>> * A hint to the platform that the current thread is momentarily >>>> * unable to progress. ... add more guidance ... >>>> */ >>>> void spinYield(); >> >> should be: >> public static void spinYield(); > > Yes -- let's keep this simple. It's just one method, another hint > in j.l.Thread which can be ignored (or not) by the VM. > > This concept seems sufficiently well understood, based on its use > in other platforms, that putting it directly into j.l.Thread is not > a huge risk. I don't see a strong need for this to start out as a > JDK-specific API. > +1 Paul. From ivan.gerasimov at oracle.com Thu Oct 8 16:40:03 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 8 Oct 2015 19:40:03 +0300 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <56169AF0.2050902@Oracle.com> References: <5613D01F.3000107@Oracle.com> <CACzrW9CHGGpcDGQh2FoeFwgTwXr1besNdt42L3+RE6Cy7jPMLg@mail.gmail.com> <5613D635.6000305@Oracle.com> <CACzrW9C2bomoiA+hQcq6=H7QvMuBu2c7wmOGYHwq31b6Z=M18A@mail.gmail.com> <5613FEE6.2010907@oracle.com> <1391860289.1215500.1444171338590.JavaMail.zimbra@u-pem.fr> <56159B9A.4040404@Oracle.com> <56169623.7080501@oracle.com> <56169AF0.2050902@Oracle.com> Message-ID: <56169C63.5010809@oracle.com> On 08.10.2015 19:33, Roger Riggs wrote: > Hi Ivan, > > It was there, for compile time, to confirm the type signature of the > return value; > the type checking on == isn't as strong as assignment. Ah, Okay. Thanks for explanation! Sincerely yours, Ivan > But it would not be needed more than once. > > Roger > > > > On 10/8/2015 12:13 PM, Ivan Gerasimov wrote: >> Hi Roger! >> >> In the test, why the 'result' variable is needed? >> >> 242 String result; >> 243 errors += (result = Objects.nonNullOf(nullString, >> defString)) == defString ? 0 : 1; >> 244 errors += (result = Objects.nonNullOf(nonNullString, >> defString)) == nonNullString ? 0 : 1; >> 245 errors += (result = Objects.nonNullOf(nonNullString, >> null)) == nonNullString ? 0 : 1; >> >> I don't see its value being used anywhere. >> >> Sincerely yours, >> Ivan >> >> On 08.10.2015 1:24, Roger Riggs wrote: >>> Hi, >>> >>> The original intent was to simplify the filling in of default values >>> (even if null). >>> I took Remi's point about the canonical coalescing operator not >>> always returning non-null >>> but the push seems to be in the direction of making sure the result >>> is always non-null. >>> I'd rather add a few very useful methods and avoid those with >>> diminishing returns. >>> >>> I note that nulls are discovered eventually, but doing more >>> aggressive checking is preferred. >>> I expect the compiler is able to squeeze out all the extra checks. >>> >>> In the current context of Objects that the jdk, I read the naming >>> pattern of firstNonNull to imply >>> access to some sequential data structure like an array or list; but >>> it doesn't gel with me to apply it to the arg list >>> (unless it was varargs). The pattern of naming us "of" as being >>> factory producing an object >>> from the arguments seems apropos and is concise. >>> >>> Please consider and comment: >>> >>> <T> T nonNullOf(T obj, T defaultObj); >>> <T> T nonNullOf(T, obj, Supplier<T> defaultSupplier); >>> >>> Details are in the updated webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ >>> >>> Regards, Roger >>> >>> >>> On 10/6/2015 6:42 PM, Remi Forax wrote: >>>> Null coalescing is a popular operator in several languages [1] and >>>> the usual semantics is nullOrElse and not firstNonNull. >>>> In languages like Kotlin or Swift, because there is a distinction >>>> between Object and Object?, it's not a big deal, you can not >>>> de-reference null by error, anyway. >>>> >>>> Also note that nullOrElseGet, the one that takes a supplier also >>>> exists in Groovy and Kotlin under the name null safe navigation. >>>> >>>> So even if i prefer the semantics of firstNonNull, i think we >>>> should also include both nullOrElse and nullOrElseGet. >>>> >>>> regards, >>>> R?mi >>>> >>>> [1] https://en.wikipedia.org/wiki/Null_coalescing_operator >>>> >>>> - >>> >>> >> > From brent.christian at oracle.com Thu Oct 8 17:22:51 2015 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 08 Oct 2015 10:22:51 -0700 Subject: RFR 9 : 8138824 : java.lang.String: spec doesn't match impl when ignoring case - equalsIgnoreCase(), regionMatches() In-Reply-To: <56169267.3060505@oracle.com> References: <5615AB1F.4050604@oracle.com> <56169267.3060505@oracle.com> Message-ID: <5616A66B.50407@oracle.com> Sure, I'll write something. -B On 10/08/2015 08:57 AM, Naoto Sato wrote: > Hi Brent, > > I wonder whether we should add a negative test case, in which > lowercasing/uppercasing on the originals would differ but > String.equalsIgnoreCase() returns true. > > Naoto > > On 10/7/15 4:30 PM, Brent Christian wrote: >> Hi, >> >> Please review my doc/spec change (no code) for 8138824. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8138824 >> Webrev: http://cr.openjdk.java.net/~bchristi/8138824/webrev.0/ >> Specdiff: >> http://cr.openjdk.java.net/~bchristi/8138824/specdiff.0/overview-summary.html >> >> >> >> This change addresses a longstanding mismatch between spec and >> implementation, clarifies comparison methods which do not account for >> locale, and adds references to the locale-aware java.text.Collator. >> >> Thanks, >> -Brent >> From lange.fabian at gmail.com Thu Oct 8 17:30:18 2015 From: lange.fabian at gmail.com (Fabian Lange) Date: Thu, 8 Oct 2015 19:30:18 +0200 Subject: RFR: 5108778 Too many instances of java.lang.Boolean created in Java application(core-libs) Message-ID: <CAFNq5NPDik2LtV_QWJqYe4yXsVU=SH3XyxuawuTsPqT-A5-QGA@mail.gmail.com> Hi Sebastian, I am all for micro optimizations that do make sense, even if their impact might be low, but I disagree with deprecating the Boolean constructor. Using it, while not being the most efficient, is not a problem, and I would say in almost all application and workloads not an issue worth discussing. What I consider a problem is making the Wrapper types asymetric by removing the constructor (that is the ultimate goal of deprecation). I do realize Dr. Deprecator suggested doing this, but I do not agree this time- Also this would be a spec change, right? Fabian > Hello, > > Actually I am searching through the JBS for low hanging fruits. > Right now i am looking through the openjdk-sources and try to evaluate > if i can make something about JDK-5108778. > > Please find my webrevs for the jdk, jaxp, jaxws and corba repos at: > > http://cr.openjdk.java.net/~sebastian/5108778/core-libs/webrev.00/ > http://cr.openjdk.java.net/~sebastian/5108778/jaxp/webrev.00/ > http://cr.openjdk.java.net/~sebastian/5108778/jaxws/webrev.00/ > http://cr.openjdk.java.net/~sebastian/5108778/corba/webrev.00/ > > I hope for jaxp,jaxws and corba this mailinglist is also the right place. > > jdk: > The Boolean constructors are @Deprecated now so that we get > compile-warnings for the uses. See also [0] and [1] > > jaxp: > For the change in XBoolean (jaxp) i thought it would be more readable > than the autoboxing solution. > > jaxws: > The changes in jaxws are in a generated class. I would love to fix this > in the source, but i have no clue where the real source could be. > > corba: > For all calls against > com.sun.tools.corba.se.idl.constExpr.Expression.value(Object) i used the > valueOf solution instead of the autoboxing for better readability. > > For some general discussion on regression-tests for this please find the > thread in discuss[0][1] and for the general suggestion to make more > wrapper-type-constructors deprecated find [2] at core-libs-dev. > > [0] > http://mail.openjdk.java.net/pipermail/discuss/2015-September/003804.html > [1] > http://mail.openjdk.java.net/pipermail/discuss/2015-October/003805.html > [2] > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035642.html > > -- Sebastian From forax at univ-mlv.fr Thu Oct 8 18:37:41 2015 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 8 Oct 2015 20:37:41 +0200 (CEST) Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <56168166.5030903@Oracle.com> References: <5613D01F.3000107@Oracle.com> <5613D635.6000305@Oracle.com> <CACzrW9C2bomoiA+hQcq6=H7QvMuBu2c7wmOGYHwq31b6Z=M18A@mail.gmail.com> <5613FEE6.2010907@oracle.com> <1391860289.1215500.1444171338590.JavaMail.zimbra@u-pem.fr> <56159B9A.4040404@Oracle.com> <1319440457.2004194.1444294182369.JavaMail.zimbra@u-pem.fr> <56168166.5030903@Oracle.com> Message-ID: <1200530124.2619128.1444329461357.JavaMail.zimbra@u-pem.fr> Hi Roger, my point was that for me, all theses forms are ambiguous thus not readable. > De: "Roger Riggs" <Roger.Riggs at Oracle.com> > ?: "Remi Forax" <forax at univ-mlv.fr> > Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net> > Envoy?: Jeudi 8 Octobre 2015 16:44:54 > Objet: Re: RFR 9: 8138963 : java.lang.Objects new method to default to > non-null > Hi Remi, > On 10/8/2015 4:49 AM, Remi Forax wrote: > > Hi Roger, > > > using overloads here seems to be a bad idea, > > > as a nice puzzler, what does the compiler do for these two lines of code > > > Supplier<String> supplier = Objects.nonNullOf(null, () -> null); > > > Supplier<String> supplier2 = Objects.nonNullOf(null, () -> ""); > > The first form compiled and threw the expected NPE at runtime. I'm not sure you can say this is the expected result. Why the compiler doesn't call <T> T nonNullOf(T, T) and return () -> null as Supplier ? > In the second case, the () -> "" is a supplier<String> not a > Supplier<Supplier<String>>. > The compiler correctly produced a error. Why the compiler doesn't select the method <T> T nonNullOf(T, T) instead, this version compiles ! and if you want more weirdness, what about ? Object o = Objects.nonNullOf"foo", null); > I don't think the method name will help the developer much and just makes the > name longer > for everyone else who is not producing a Supplier<Supplier<T>>. maybe "nonNullOfGet" is a bad name, my point is that when you have several overloads like this, the result is not easy to predict (I suppose that people don't know by heart the chapter 15.12.2 of the JLS). [...] > Thanks, Roger regards, R?mi > > otherwise apart form the remark of Stephen, the code is Ok. > > > cheers, > > > R?mi > > > > > > ----- Mail original ----- > > > > De: "Roger Riggs" <Roger.Riggs at Oracle.com> ?: "core-libs-dev" > > > <core-libs-dev at openjdk.java.net> Envoy?: Jeudi 8 Octobre 2015 00:24:26 > > > > > > Objet: Re: RFR 9: 8138963 : java.lang.Objects new method to default to > > > non-null > > > > > > Hi, > > > > > > The original intent was to simplify the filling in of default values > > > > > > (even if null). > > > > > > I took Remi's point about the canonical coalescing operator not always > > > > > > returning non-null > > > > > > but the push seems to be in the direction of making sure the result is > > > > > > always non-null. > > > > > > I'd rather add a few very useful methods and avoid those with > > > > > > diminishing returns. > > > > > > I note that nulls are discovered eventually, but doing more aggressive > > > > > > checking is preferred. > > > > > > I expect the compiler is able to squeeze out all the extra checks. > > > > > > In the current context of Objects that the jdk, I read the naming > > > > > > pattern of firstNonNull to imply > > > > > > access to some sequential data structure like an array or list; but it > > > > > > doesn't gel with me to apply it to the arg list > > > > > > (unless it was varargs). The pattern of naming us "of" as being > > > > > > factory producing an object > > > > > > from the arguments seems apropos and is concise. > > > > > > Please consider and comment: > > > > > > <T> T nonNullOf(T obj, T defaultObj); > > > > > > <T> T nonNullOf(T, obj, Supplier<T> defaultSupplier); > > > > > > Details are in the updated webrev: > > > http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ Regards, Roger > > > > > > On 10/6/2015 6:42 PM, Remi Forax wrote: > > > > > > > Null coalescing is a popular operator in several languages [1] and the > > > > > > > > > > usual semantics is nullOrElse and not firstNonNull. > > > > > > > > > > In languages like Kotlin or Swift, because there is a distinction > > > > between > > > > > > > > > > Object and Object?, it's not a big deal, you can not de-reference null > > > > by > > > > > > > > > > error, anyway. > > > > > > > > > > Also note that nullOrElseGet, the one that takes a supplier also exists > > > > in > > > > > > > > > > Groovy and Kotlin under the name null safe navigation. > > > > > > > > > > So even if i prefer the semantics of firstNonNull, i think we should > > > > also > > > > > > > > > > include both nullOrElse and nullOrElseGet. > > > > > > > > > > regards, > > > > > > > > > > R?mi > > > > > > > > > > [1] https://en.wikipedia.org/wiki/Null_coalescing_operator - > > > > > > From stuart.marks at oracle.com Thu Oct 8 18:39:04 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 8 Oct 2015 11:39:04 -0700 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <56168166.5030903@Oracle.com> References: <5613D01F.3000107@Oracle.com> <CACzrW9CHGGpcDGQh2FoeFwgTwXr1besNdt42L3+RE6Cy7jPMLg@mail.gmail.com> <5613D635.6000305@Oracle.com> <CACzrW9C2bomoiA+hQcq6=H7QvMuBu2c7wmOGYHwq31b6Z=M18A@mail.gmail.com> <5613FEE6.2010907@oracle.com> <1391860289.1215500.1444171338590.JavaMail.zimbra@u-pem.fr> <56159B9A.4040404@Oracle.com> <1319440457.2004194.1444294182369.JavaMail.zimbra@u-pem.fr> <56168166.5030903@Oracle.com> Message-ID: <5616B848.9020900@oracle.com> On 10/8/15 7:44 AM, Roger Riggs wrote: > On 10/8/2015 4:49 AM, Remi Forax wrote: >> Hi Roger, >> using overloads here seems to be a bad idea, >> as a nice puzzler, what does the compiler do for these two lines of code >> Supplier<String> supplier = Objects.nonNullOf(null, () -> null); >> Supplier<String> supplier2 = Objects.nonNullOf(null, () -> ""); > The first form compiled and threw the expected NPE at runtime. > > In the second case, the () -> "" is a supplier<String> not a > Supplier<Supplier<String>>. > The compiler correctly produced a error. > > I don't think the method name will help the developer much and just makes the > name longer > for everyone else who is not producing a Supplier<Supplier<T>>. I think there is an overloading issue here. It occurs when dealing with Supplier<T>, not Supplier<Supplier<T>> (which I agree would be pretty obscure). Suppose we're trying to initialize a variable whose type is Supplier<String>. We might try static void setSupplier(Supplier<String> arg) { Supplier<String> supplier = Objects.nonNullOf(arg, () -> ""); // ERROR } This seems like it ought to work, but it gives an error: /Users/smarks/NetBeansProjects/Java9scratch/src/ObjectsNonNull.java:35: error: incompatible types: inference variable T has incompatible bounds Supplier<String> supplier = Objects.nonNullOf(arg, () -> ""); // ERROR upper bounds: Supplier<String>,Object lower bounds: String,Supplier<String> where T is a type-variable: T extends Object declared in method <T>nonNullOf(T,Supplier<T>) This is with a recent jdk9/dev build, but it also seems to happen in 8u25. You'd think the compiler would infer T to be Supplier<String> based on the target type, and matching of both args, but ... it doesn't. The workaround is to supply a type witness: Supplier<String> supplier = Objects.<Supplier<String>>nonNullOf(arg, () -> ""); I don't know whether this is a compiler bug or just a limitation in the way type inference interacts with overload resolution. In any case, I'd like to be able to write my example code without compiler errors or having to provide a type witness. If it's just a compiler bug that's likely to be fixed in 9, I'd be ok with proceeding with this the overload approach. Otherwise, I'd prefer to rename the Supplier-based method in order to avoid the issue. s'marks > >> >> The other issue is that defaultSupplier should allow covariant Supplier, >> the signature should be: >> <T> T nonNullOfGet(T obj, Supplier<? extends T> defaultSupplier) > Right, as Chris pointed out also. > > Thanks, Roger > >> >> otherwise apart form the remark of Stephen, the code is Ok. >> >> cheers, >> R?mi >> >> ----- Mail original ----- >>> De: "Roger Riggs" <Roger.Riggs at Oracle.com> >>> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net> >>> Envoy?: Jeudi 8 Octobre 2015 00:24:26 >>> Objet: Re: RFR 9: 8138963 : java.lang.Objects new method to default to >>> non-null >>> >>> Hi, >>> >>> The original intent was to simplify the filling in of default values >>> (even if null). >>> I took Remi's point about the canonical coalescing operator not always >>> returning non-null >>> but the push seems to be in the direction of making sure the result is >>> always non-null. >>> I'd rather add a few very useful methods and avoid those with >>> diminishing returns. >>> >>> I note that nulls are discovered eventually, but doing more aggressive >>> checking is preferred. >>> I expect the compiler is able to squeeze out all the extra checks. >>> >>> In the current context of Objects that the jdk, I read the naming >>> pattern of firstNonNull to imply >>> access to some sequential data structure like an array or list; but it >>> doesn't gel with me to apply it to the arg list >>> (unless it was varargs). The pattern of naming us "of" as being >>> factory producing an object >>> from the arguments seems apropos and is concise. >>> >>> Please consider and comment: >>> >>> <T> T nonNullOf(T obj, T defaultObj); >>> <T> T nonNullOf(T, obj, Supplier<T> defaultSupplier); >>> >>> Details are in the updated webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ >>> >>> Regards, Roger >>> >>> >>> On 10/6/2015 6:42 PM, Remi Forax wrote: >>>> Null coalescing is a popular operator in several languages [1] and the >>>> usual semantics is nullOrElse and not firstNonNull. >>>> In languages like Kotlin or Swift, because there is a distinction between >>>> Object and Object?, it's not a big deal, you can not de-reference null by >>>> error, anyway. >>>> >>>> Also note that nullOrElseGet, the one that takes a supplier also exists in >>>> Groovy and Kotlin under the name null safe navigation. >>>> >>>> So even if i prefer the semantics of firstNonNull, i think we should also >>>> include both nullOrElse and nullOrElseGet. >>>> >>>> regards, >>>> R?mi >>>> >>>> [1] https://en.wikipedia.org/wiki/Null_coalescing_operator >>>> >>>> - >>> > From stuart.marks at oracle.com Thu Oct 8 18:58:46 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 8 Oct 2015 11:58:46 -0700 Subject: RFR: 5108778 Too many instances of java.lang.Boolean created in Java application(core-libs) In-Reply-To: <56157990.7020506@gmx.de> References: <56157990.7020506@gmx.de> Message-ID: <5616BCE6.9000108@oracle.com> On 10/7/15 12:59 PM, Sebastian Sickelmann wrote: > http://cr.openjdk.java.net/~sebastian/5108778/core-libs/webrev.00/ > > jdk: > The Boolean constructors are @Deprecated now so that we get > compile-warnings for the uses. See also [0] and [1] > > [0] > http://mail.openjdk.java.net/pipermail/discuss/2015-September/003804.html > [1] http://mail.openjdk.java.net/pipermail/discuss/2015-October/003805.html Hi Sebastian, I did suggest adding @Deprecated to the Boolean constructors, but only in your own source tree, as a quick means of causing the compiler to emit warnings for places where they're used. I don't think we should actually go ahead and deprecate them at this time. So, please drop the deprecation changes from your patch. Sorry for the misunderstanding. (As I've mentioned elsewhere, there is forthcoming work in the area of deprecation, so the Boolean constructors will eventually be marked in some way so that developers will be advised to update their code.) I do think the cleanup work to remove usages of the Boolean constructors is worthwhile and that you should proceed with it. s'marks From stuart.marks at oracle.com Thu Oct 8 19:05:58 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 8 Oct 2015 12:05:58 -0700 Subject: Test for JDK-5108778 Too many instances of java.lang.Boolean created in Java application In-Reply-To: <CAM21Rt9RkdaAfrzyPE8PZ=vWq-DDCtxCyE5RRk8u9Mvg2C+Bmw@mail.gmail.com> References: <560C3B56.4060309@gmx.de> <560F3B56.3060309@oracle.com> <CACzrW9Cgcd11S1j0Ft5VaAKUKsissO3Hm+3c-1JXLf_sFXhnCg@mail.gmail.com> <561460C7.10403@oracle.com> <CAM21Rt9RkdaAfrzyPE8PZ=vWq-DDCtxCyE5RRk8u9Mvg2C+Bmw@mail.gmail.com> Message-ID: <5616BE96.2090108@oracle.com> On 10/6/15 11:51 PM, Dawid Weiss wrote: > A @Discouraged(String seeAlternative) annotation? This also applies to > things like Vector or Hashtable (which arguably have a > slightly different semantics from ArrayList or HashMap, but if somebody uses > them it's very likely a mistake). Yes, something like this, although it might be spelled differently. It would be applied not only to Vector and Hashtable, but also things like Dictionary and Stack. (Remember them?) s'marks From Roger.Riggs at Oracle.com Thu Oct 8 19:09:26 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 8 Oct 2015 15:09:26 -0400 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <1200530124.2619128.1444329461357.JavaMail.zimbra@u-pem.fr> References: <5613D01F.3000107@Oracle.com> <5613D635.6000305@Oracle.com> <CACzrW9C2bomoiA+hQcq6=H7QvMuBu2c7wmOGYHwq31b6Z=M18A@mail.gmail.com> <5613FEE6.2010907@oracle.com> <1391860289.1215500.1444171338590.JavaMail.zimbra@u-pem.fr> <56159B9A.4040404@Oracle.com> <1319440457.2004194.1444294182369.JavaMail.zimbra@u-pem.fr> <56168166.5030903@Oracle.com> <1200530124.2619128.1444329461357.JavaMail.zimbra@u-pem.fr> Message-ID: <5616BF66.3010607@Oracle.com> So for you, method overloading is a mis-feature of the language because it inhibits readability. Though I might argue, that the magic type inference is the real culprit. In most coding cases, the types of the arguments are visible and/or via syntax and naming. Thanks, Roger On 10/8/2015 2:37 PM, forax at univ-mlv.fr wrote: > Hi Roger, > my point was that for me, all theses forms are ambiguous thus not > readable. > > *De: *"Roger Riggs" <Roger.Riggs at Oracle.com> > *?: *"Remi Forax" <forax at univ-mlv.fr> > *Cc: *"core-libs-dev" <core-libs-dev at openjdk.java.net> > *Envoy?: *Jeudi 8 Octobre 2015 16:44:54 > *Objet: *Re: RFR 9: 8138963 : java.lang.Objects new method to > default to non-null > > Hi Remi, > > On 10/8/2015 4:49 AM, Remi Forax wrote: > > Hi Roger, > using overloads here seems to be a bad idea, > as a nice puzzler, what does the compiler do for these two lines of code > Supplier<String> supplier = Objects.nonNullOf(null, () -> null); > Supplier<String> supplier2 = Objects.nonNullOf(null, () -> ""); > > The first form compiled and threw the expected NPE at runtime. > > > I'm not sure you can say this is the expected result. Why the compiler > doesn't call <T> T nonNullOf(T, T) and return () -> null as Supplier ? > > > > In the second case, the () -> "" is a supplier<String> not a > Supplier<Supplier<String>>. > The compiler correctly produced a error. > > > Why the compiler doesn't select the method <T> T nonNullOf(T, T) > instead, this version compiles ! > > and if you want more weirdness, what about ? > Object o = Objects.nonNullOf"foo", null); > > > > I don't think the method name will help the developer much and > just makes the name longer > for everyone else who is not producing a Supplier<Supplier<T>>. > > > maybe "nonNullOfGet" is a bad name, my point is that when you have > several overloads like this, the result is not easy to predict (I > suppose that people don't know by heart the chapter 15.12.2 of the JLS). > > [...] > > > Thanks, Roger > > > regards, > R?mi > > > > otherwise apart form the remark of Stephen, the code is Ok. > > cheers, > R?mi > > > ----- Mail original ----- > > De: "Roger Riggs"<Roger.Riggs at Oracle.com> > ?: "core-libs-dev"<core-libs-dev at openjdk.java.net> > Envoy?: Jeudi 8 Octobre 2015 00:24:26 > Objet: Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null > > Hi, > > The original intent was to simplify the filling in of default values > (even if null). > I took Remi's point about the canonical coalescing operator not always > returning non-null > but the push seems to be in the direction of making sure the result is > always non-null. > I'd rather add a few very useful methods and avoid those with > diminishing returns. > > I note that nulls are discovered eventually, but doing more aggressive > checking is preferred. > I expect the compiler is able to squeeze out all the extra checks. > > In the current context of Objects that the jdk, I read the naming > pattern of firstNonNull to imply > access to some sequential data structure like an array or list; but it > doesn't gel with me to apply it to the arg list > (unless it was varargs). The pattern of naming us "of" as being > factory producing an object > from the arguments seems apropos and is concise. > > Please consider and comment: > > <T> T nonNullOf(T obj, T defaultObj); > <T> T nonNullOf(T, obj, Supplier<T> defaultSupplier); > > Details are in the updated webrev: > http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ > > Regards, Roger > > > On 10/6/2015 6:42 PM, Remi Forax wrote: > > Null coalescing is a popular operator in several languages [1] and the > usual semantics is nullOrElse and not firstNonNull. > In languages like Kotlin or Swift, because there is a distinction between > Object and Object?, it's not a big deal, you can not de-reference null by > error, anyway. > > Also note that nullOrElseGet, the one that takes a supplier also exists in > Groovy and Kotlin under the name null safe navigation. > > So even if i prefer the semantics of firstNonNull, i think we should also > include both nullOrElse and nullOrElseGet. > > regards, > R?mi > > [1]https://en.wikipedia.org/wiki/Null_coalescing_operator > > - > > > From stuart.marks at oracle.com Thu Oct 8 19:15:13 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 8 Oct 2015 12:15:13 -0700 Subject: RFR: 5108778 Too many instances of java.lang.Boolean created in Java application(core-libs) In-Reply-To: <CAFNq5NPDik2LtV_QWJqYe4yXsVU=SH3XyxuawuTsPqT-A5-QGA@mail.gmail.com> References: <CAFNq5NPDik2LtV_QWJqYe4yXsVU=SH3XyxuawuTsPqT-A5-QGA@mail.gmail.com> Message-ID: <5616C0C1.1080408@oracle.com> Hi Fabian, As you might have seen from my message to Sebastian, I agree that the Boolean constructors shouldn't be deprecated -- at least not with deprecation in its current form. The idea is eventually to mark them somehow, in a way that warns developers that other APIs are preferable, but without any implication that they will eventually be removed. There are no plans to remove the Boolean constructors from the API. s'marks On 10/8/15 10:30 AM, Fabian Lange wrote: > Hi Sebastian, > > I am all for micro optimizations that do make sense, even if their impact > might be low, but I disagree with deprecating the Boolean constructor. > Using it, while not being the most efficient, is not a problem, and I would > say in almost all application and workloads not an issue worth discussing. > What I consider a problem is making the Wrapper types asymetric by removing > the constructor (that is the ultimate goal of deprecation). > I do realize Dr. Deprecator suggested doing this, but I do not agree this > time- > > Also this would be a spec change, right? > > Fabian > > >> Hello, >> >> Actually I am searching through the JBS for low hanging fruits. >> Right now i am looking through the openjdk-sources and try to evaluate >> if i can make something about JDK-5108778. >> >> Please find my webrevs for the jdk, jaxp, jaxws and corba repos at: >> >> http://cr.openjdk.java.net/~sebastian/5108778/core-libs/webrev.00/ >> http://cr.openjdk.java.net/~sebastian/5108778/jaxp/webrev.00/ >> http://cr.openjdk.java.net/~sebastian/5108778/jaxws/webrev.00/ >> http://cr.openjdk.java.net/~sebastian/5108778/corba/webrev.00/ >> >> I hope for jaxp,jaxws and corba this mailinglist is also the right place. >> >> jdk: >> The Boolean constructors are @Deprecated now so that we get >> compile-warnings for the uses. See also [0] and [1] >> >> jaxp: >> For the change in XBoolean (jaxp) i thought it would be more readable >> than the autoboxing solution. >> >> jaxws: >> The changes in jaxws are in a generated class. I would love to fix this >> in the source, but i have no clue where the real source could be. >> >> corba: >> For all calls against >> com.sun.tools.corba.se.idl.constExpr.Expression.value(Object) i used the >> valueOf solution instead of the autoboxing for better readability. >> >> For some general discussion on regression-tests for this please find the >> thread in discuss[0][1] and for the general suggestion to make more >> wrapper-type-constructors deprecated find [2] at core-libs-dev. >> >> [0] >> http://mail.openjdk.java.net/pipermail/discuss/2015-September/003804.html >> [1] >> http://mail.openjdk.java.net/pipermail/discuss/2015-October/003805.html >> [2] >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035642.html >> >> -- Sebastian From forax at univ-mlv.fr Thu Oct 8 19:34:21 2015 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 8 Oct 2015 21:34:21 +0200 (CEST) Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <5616BF66.3010607@Oracle.com> References: <5613D01F.3000107@Oracle.com> <5613FEE6.2010907@oracle.com> <1391860289.1215500.1444171338590.JavaMail.zimbra@u-pem.fr> <56159B9A.4040404@Oracle.com> <1319440457.2004194.1444294182369.JavaMail.zimbra@u-pem.fr> <56168166.5030903@Oracle.com> <1200530124.2619128.1444329461357.JavaMail.zimbra@u-pem.fr> <5616BF66.3010607@Oracle.com> Message-ID: <278013257.2631892.1444332861717.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Roger Riggs" <Roger.Riggs at Oracle.com> > ?: forax at univ-mlv.fr > Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net> > Envoy?: Jeudi 8 Octobre 2015 21:09:26 > Objet: Re: RFR 9: 8138963 : java.lang.Objects new method to default to > non-null > So for you, method overloading is a mis-feature of the language because it > inhibits readability. > Though I might argue, that the magic type inference is the real culprit. > In most coding cases, the types of the arguments are visible and/or via > syntax and naming. > Thanks, Roger I don't really like overloading mostly because the rules that govern overloading are too complex. When you introduce a new feature like auto-boxing or lambda auto-conversion in the language, you can not say that a call is ambiguous with the new rules because it will break backward compatibility, so you end up with weird overloading rules that you can only understand in the light of the Java history. Anyway, in this case the problem is not just overloading, it is the mix of overloading and type inference as you said. I vaguely remember that we, the lambda EG, discuss about javac emitting a warning for cases like this one. regards, R?mi > On 10/8/2015 2:37 PM, forax at univ-mlv.fr wrote: > > Hi Roger, > > > my point was that for me, all theses forms are ambiguous thus not readable. > > > > De: "Roger Riggs" <Roger.Riggs at Oracle.com> > > > > > > ?: "Remi Forax" <forax at univ-mlv.fr> > > > > > > Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net> > > > > > > Envoy?: Jeudi 8 Octobre 2015 16:44:54 > > > > > > Objet: Re: RFR 9: 8138963 : java.lang.Objects new method to default to > > > non-null > > > > > > Hi Remi, > > > > > > On 10/8/2015 4:49 AM, Remi Forax wrote: > > > > > > > Hi Roger, > > > > > > > > > > using overloads here seems to be a bad idea, > > > > > > > > > > as a nice puzzler, what does the compiler do for these two lines of > > > > code > > > > > > > > > > Supplier<String> supplier = Objects.nonNullOf(null, () -> null); > > > > > > > > > > Supplier<String> supplier2 = Objects.nonNullOf(null, () -> ""); > > > > > > > > > The first form compiled and threw the expected NPE at runtime. > > > > > I'm not sure you can say this is the expected result. Why the compiler > > doesn't call <T> T nonNullOf(T, T) and return () -> null as Supplier ? > > > > In the second case, the () -> "" is a supplier<String> not a > > > Supplier<Supplier<String>>. > > > > > > The compiler correctly produced a error. > > > > > Why the compiler doesn't select the method <T> T nonNullOf(T, T) instead, > > this version compiles ! > > > and if you want more weirdness, what about ? > > > Object o = Objects.nonNullOf"foo", null); > > > > I don't think the method name will help the developer much and just makes > > > the > > > name longer > > > > > > for everyone else who is not producing a Supplier<Supplier<T>>. > > > > > maybe "nonNullOfGet" is a bad name, my point is that when you have several > > overloads like this, the result is not easy to predict (I suppose that > > people don't know by heart the chapter 15.12.2 of the JLS). > > > [...] > > > > Thanks, Roger > > > > > regards, > > > R?mi > > > > > otherwise apart form the remark of Stephen, the code is Ok. > > > > > > > > > > cheers, > > > > > > > > > > R?mi > > > > > > > > > > > > > > > > > > > > ----- Mail original ----- > > > > > > > > > > > De: "Roger Riggs" <Roger.Riggs at Oracle.com> ?: "core-libs-dev" > > > > > <core-libs-dev at openjdk.java.net> Envoy?: Jeudi 8 Octobre 2015 > > > > > 00:24:26 > > > > > > > > > > > > > > > Objet: Re: RFR 9: 8138963 : java.lang.Objects new method to default > > > > > to > > > > > non-null > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > The original intent was to simplify the filling in of default values > > > > > > > > > > > > > > > (even if null). > > > > > > > > > > > > > > > I took Remi's point about the canonical coalescing operator not > > > > > always > > > > > > > > > > > > > > > returning non-null > > > > > > > > > > > > > > > but the push seems to be in the direction of making sure the result > > > > > is > > > > > > > > > > > > > > > always non-null. > > > > > > > > > > > > > > > I'd rather add a few very useful methods and avoid those with > > > > > > > > > > > > > > > diminishing returns. > > > > > > > > > > > > > > > I note that nulls are discovered eventually, but doing more > > > > > aggressive > > > > > > > > > > > > > > > checking is preferred. > > > > > > > > > > > > > > > I expect the compiler is able to squeeze out all the extra checks. > > > > > > > > > > > > > > > In the current context of Objects that the jdk, I read the naming > > > > > > > > > > > > > > > pattern of firstNonNull to imply > > > > > > > > > > > > > > > access to some sequential data structure like an array or list; but > > > > > it > > > > > > > > > > > > > > > doesn't gel with me to apply it to the arg list > > > > > > > > > > > > > > > (unless it was varargs). The pattern of naming us "of" as being > > > > > > > > > > > > > > > factory producing an object > > > > > > > > > > > > > > > from the arguments seems apropos and is concise. > > > > > > > > > > > > > > > Please consider and comment: > > > > > > > > > > > > > > > <T> T nonNullOf(T obj, T defaultObj); > > > > > > > > > > > > > > > <T> T nonNullOf(T, obj, Supplier<T> defaultSupplier); > > > > > > > > > > > > > > > Details are in the updated webrev: > > > > > http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ Regards, > > > > > Roger > > > > > > > > > > > > > > > On 10/6/2015 6:42 PM, Remi Forax wrote: > > > > > > > > > > > > > > > > Null coalescing is a popular operator in several languages [1] and > > > > > > the > > > > > > > > > > > > > > > > > > > > > usual semantics is nullOrElse and not firstNonNull. > > > > > > > > > > > > > > > > > > > > > In languages like Kotlin or Swift, because there is a distinction > > > > > > between > > > > > > > > > > > > > > > > > > > > > Object and Object?, it's not a big deal, you can not de-reference > > > > > > null > > > > > > by > > > > > > > > > > > > > > > > > > > > > error, anyway. > > > > > > > > > > > > > > > > > > > > > Also note that nullOrElseGet, the one that takes a supplier also > > > > > > exists > > > > > > in > > > > > > > > > > > > > > > > > > > > > Groovy and Kotlin under the name null safe navigation. > > > > > > > > > > > > > > > > > > > > > So even if i prefer the semantics of firstNonNull, i think we > > > > > > should > > > > > > also > > > > > > > > > > > > > > > > > > > > > include both nullOrElse and nullOrElseGet. > > > > > > > > > > > > > > > > > > > > > regards, > > > > > > > > > > > > > > > > > > > > > R?mi > > > > > > > > > > > > > > > > > > > > > [1] https://en.wikipedia.org/wiki/Null_coalescing_operator - > > > > > > > > > > > > > > > From Roger.Riggs at Oracle.com Thu Oct 8 20:41:40 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 8 Oct 2015 16:41:40 -0400 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <56141107.8000407@Oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> Message-ID: <5616D504.4000104@Oracle.com> Please review a few improvements to the Cleaner nested classes and implementation. - The extensible reference classes have shorter names that focus on the cleanup behavior, PhantomCleanup, WeakCleanup, SoftCleanup and to update the javadoc - Added documentation for the Reference.get method; its behavior was not clear - Corrected a race condition that would prevent the cleaning thread from terminating - cleanup of the link list management Webrev: http://cr.openjdk.java.net/~rriggs/webrev-cleaner-extensible-8138696/ javadoc: http://cr.openjdk.java.net/~rriggs/cleaner-doc2/ Please review and comment, Roger From Roger.Riggs at Oracle.com Thu Oct 8 21:10:23 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 8 Oct 2015 17:10:23 -0400 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <278013257.2631892.1444332861717.JavaMail.zimbra@u-pem.fr> References: <5613D01F.3000107@Oracle.com> <5613FEE6.2010907@oracle.com> <1391860289.1215500.1444171338590.JavaMail.zimbra@u-pem.fr> <56159B9A.4040404@Oracle.com> <1319440457.2004194.1444294182369.JavaMail.zimbra@u-pem.fr> <56168166.5030903@Oracle.com> <1200530124.2619128.1444329461357.JavaMail.zimbra@u-pem.fr> <5616BF66.3010607@Oracle.com> <278013257.2631892.1444332861717.JavaMail.zimbra@u-pem.fr> Message-ID: <5616DBBF.1040209@Oracle.com> Hi Remi, ok, the easy way out is to rename it/both of the methods. And the name comes back around for discussion so the two names have some synergy: <T> T nonNullOrGet(T, Supplier<T>) <T> T nonNullOrElse(T, T); Updated Webrev: http://cr.openjdk.java.net/~rriggs/webrev-cleaner-extensible-8138696/ I am curious as to Stuart's question about whether it is supposed to figure out the overloads and is a bug, or if it just too difficult to make the inference work. Thanks, Roger The variations: nonNullOf(T, T) is ok but nonNullOfOrGet(T, Supplier<T>) is poor Splitting between Of and Or nonNullOf(T, T) nonNullOrGet(T, Supplier<T>) - nope Sigh... On 10/8/2015 3:34 PM, forax at univ-mlv.fr wrote: > > > ------------------------------------------------------------------------ > > *De: *"Roger Riggs" <Roger.Riggs at Oracle.com> > *?: *forax at univ-mlv.fr > *Cc: *"core-libs-dev" <core-libs-dev at openjdk.java.net> > *Envoy?: *Jeudi 8 Octobre 2015 21:09:26 > *Objet: *Re: RFR 9: 8138963 : java.lang.Objects new method to > default to non-null > > So for you, method overloading is a mis-feature of the language > because it inhibits readability. > Though I might argue, that the magic type inference is the real > culprit. > In most coding cases, the types of the arguments are visible > and/or via syntax and naming. > > Thanks, Roger > > > I don't really like overloading mostly because the rules that govern > overloading are too complex. When you introduce a new feature like > auto-boxing or lambda auto-conversion in the language, you can not say > that a call is ambiguous with the new rules because it will break > backward compatibility, so you end up with weird overloading rules > that you can only understand in the light of the Java history. > > Anyway, in this case the problem is not just overloading, it is the > mix of overloading and type inference as you said. > I vaguely remember that we, the lambda EG, discuss about javac > emitting a warning for cases like this one. > > regards, > R?mi > > > > > On 10/8/2015 2:37 PM, forax at univ-mlv.fr wrote: > > Hi Roger, > my point was that for me, all theses forms are ambiguous thus > not readable. > > *De: *"Roger Riggs" <Roger.Riggs at Oracle.com> > *?: *"Remi Forax" <forax at univ-mlv.fr> > *Cc: *"core-libs-dev" <core-libs-dev at openjdk.java.net> > *Envoy?: *Jeudi 8 Octobre 2015 16:44:54 > *Objet: *Re: RFR 9: 8138963 : java.lang.Objects new method > to default to non-null > > Hi Remi, > > On 10/8/2015 4:49 AM, Remi Forax wrote: > > Hi Roger, > using overloads here seems to be a bad idea, > as a nice puzzler, what does the compiler do for these two lines of code > Supplier<String> supplier = Objects.nonNullOf(null, () -> null); > Supplier<String> supplier2 = Objects.nonNullOf(null, () -> ""); > > The first form compiled and threw the expected NPE at runtime. > > > I'm not sure you can say this is the expected result. Why the > compiler doesn't call <T> T nonNullOf(T, T) and return () -> > null as Supplier ? > > > > In the second case, the () -> "" is a supplier<String> not > a Supplier<Supplier<String>>. > The compiler correctly produced a error. > > > Why the compiler doesn't select the method <T> T nonNullOf(T, > T) instead, this version compiles ! > > and if you want more weirdness, what about ? > Object o = Objects.nonNullOf"foo", null); > > > > I don't think the method name will help the developer much > and just makes the name longer > for everyone else who is not producing a > Supplier<Supplier<T>>. > > > maybe "nonNullOfGet" is a bad name, my point is that when you > have several overloads like this, the result is not easy to > predict (I suppose that people don't know by heart the chapter > 15.12.2 of the JLS). > > [...] > > > Thanks, Roger > > > regards, > R?mi > > > > otherwise apart form the remark of Stephen, the code is Ok. > > cheers, > R?mi > > > ----- Mail original ----- > > De: "Roger Riggs"<Roger.Riggs at Oracle.com> > ?: "core-libs-dev"<core-libs-dev at openjdk.java.net> > Envoy?: Jeudi 8 Octobre 2015 00:24:26 > Objet: Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null > > Hi, > > The original intent was to simplify the filling in of default values > (even if null). > I took Remi's point about the canonical coalescing operator not always > returning non-null > but the push seems to be in the direction of making sure the result is > always non-null. > I'd rather add a few very useful methods and avoid those with > diminishing returns. > > I note that nulls are discovered eventually, but doing more aggressive > checking is preferred. > I expect the compiler is able to squeeze out all the extra checks. > > In the current context of Objects that the jdk, I read the naming > pattern of firstNonNull to imply > access to some sequential data structure like an array or list; but it > doesn't gel with me to apply it to the arg list > (unless it was varargs). The pattern of naming us "of" as being > factory producing an object > from the arguments seems apropos and is concise. > > Please consider and comment: > > <T> T nonNullOf(T obj, T defaultObj); > <T> T nonNullOf(T, obj, Supplier<T> defaultSupplier); > > Details are in the updated webrev: > http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ > > Regards, Roger > > > On 10/6/2015 6:42 PM, Remi Forax wrote: > > Null coalescing is a popular operator in several languages [1] and the > usual semantics is nullOrElse and not firstNonNull. > In languages like Kotlin or Swift, because there is a distinction between > Object and Object?, it's not a big deal, you can not de-reference null by > error, anyway. > > Also note that nullOrElseGet, the one that takes a supplier also exists in > Groovy and Kotlin under the name null safe navigation. > > So even if i prefer the semantics of firstNonNull, i think we should also > include both nullOrElse and nullOrElseGet. > > regards, > R?mi > > [1]https://en.wikipedia.org/wiki/Null_coalescing_operator > > - > > > > > From john.r.rose at oracle.com Thu Oct 8 21:26:48 2015 From: john.r.rose at oracle.com (John Rose) Date: Thu, 8 Oct 2015 14:26:48 -0700 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <278013257.2631892.1444332861717.JavaMail.zimbra@u-pem.fr> References: <5613D01F.3000107@Oracle.com> <5613FEE6.2010907@oracle.com> <1391860289.1215500.1444171338590.JavaMail.zimbra@u-pem.fr> <56159B9A.4040404@Oracle.com> <1319440457.2004194.1444294182369.JavaMail.zimbra@u-pem.fr> <56168166.5030903@Oracle.com> <1200530124.2619128.1444329461357.JavaMail.zimbra@u-pem.fr> <5616BF66.3010607@Oracle.com> <278013257.2631892.1444332861717.JavaMail.zimbra@u-pem.fr> Message-ID: <33D01469-37DE-4502-8112-0E4865733AFF@oracle.com> On Oct 8, 2015, at 12:34 PM, forax at univ-mlv.fr wrote: > > Anyway, in this case the problem is not just overloading, it is the mix of overloading and type inference as you said. Add type erasure to this cocktail, and it's perfect. My antennae go up when the erased types overlap. When they do, there's usually a sad story (with puzzlers) waiting to appear. On 7 October 2015 at 23:24, Roger Riggs <Roger.Riggs at oracle.com <mailto:Roger.Riggs at oracle.com>> wrote: > Please consider and comment: > > <T> T nonNullOf(T obj, T defaultObj); > <T> T nonNullOf(T, obj, Supplier<T> defaultSupplier); > > Details are in the updated webrev: > http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ <http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/> In this case, the erased types are Object(Object, Object) and Object(Object, Supplier). So the source language (usually) makes all needed distinctions, but the bytecodes are full of ambiguity. And nulls are wonderful carriers of ambiguity, at both source and bytecode levels. Please align this API point with the closely analogous points already found in java.util.Optional. In particular, a third throwing form looks right. Those are my substantive comments. Now for bikeshed comments. I don't like "Of" here, which doesn't appear in Optional, and seems to be used more frequently for factory methods. I suggest using Optional::orElse* method names, but kill leading noise word "or". "Non-null else foo" is good programmer talk for "non-null or else foo". (Speculation: The "or" is present in Optional mainly to avoid reserved word "else".) - nonNullElse(T,T) (cf. Optional::orElse) - nonNullElseGet(T,Supplier<T>) (cf. Optional::orElseGet) - nonNullElseThrow(T,Supplier<X>) (cf. Optional::orElseThrow) ? John From Roger.Riggs at Oracle.com Thu Oct 8 21:42:29 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 8 Oct 2015 17:42:29 -0400 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <33D01469-37DE-4502-8112-0E4865733AFF@oracle.com> References: <5613D01F.3000107@Oracle.com> <5613FEE6.2010907@oracle.com> <1391860289.1215500.1444171338590.JavaMail.zimbra@u-pem.fr> <56159B9A.4040404@Oracle.com> <1319440457.2004194.1444294182369.JavaMail.zimbra@u-pem.fr> <56168166.5030903@Oracle.com> <1200530124.2619128.1444329461357.JavaMail.zimbra@u-pem.fr> <5616BF66.3010607@Oracle.com> <278013257.2631892.1444332861717.JavaMail.zimbra@u-pem.fr> <33D01469-37DE-4502-8112-0E4865733AFF@oracle.com> Message-ID: <5616E345.9090609@Oracle.com> Hi John, Thanks for the insight, I hope it will help cut down on the thrashing. Isn't there a 4th form that throws missing? There was quite a bit of support for a version the never returned null and threw an exception if the replacement was null. Thanks, Roger On 10/8/2015 5:26 PM, John Rose wrote: > On Oct 8, 2015, at 12:34 PM, forax at univ-mlv.fr > <mailto:forax at univ-mlv.fr> wrote: >> >> Anyway, in this case the problem is not just overloading, it is the >> mix of overloading and type inference as you said. > > Add type erasure to this cocktail, and it's perfect. > > My antennae go up when the erased types overlap. When they do, > there's usually a sad story (with puzzlers) waiting to appear. > > On 7 October 2015 at 23:24, Roger Riggs <Roger.Riggs at oracle.com > <mailto:Roger.Riggs at oracle.com>> wrote: >> Please consider and comment: >> >> <T> T nonNullOf(T obj, T defaultObj); >> <T> T nonNullOf(T, obj, Supplier<T> defaultSupplier); >> >> Details are in the updated webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ >> <http://cr.openjdk.java.net/%7Erriggs/webrev-object-non-null/> > > In this case, the erased types are Object(Object, Object) and > Object(Object, Supplier). > > So the source language (usually) makes all needed distinctions, but > the bytecodes are full of ambiguity. And nulls are wonderful carriers > of ambiguity, at both source and bytecode levels. > > Please align this API point with the closely analogous points already > found in java.util.Optional. In particular, a third throwing form > looks right. > > Those are my substantive comments. > > Now for bikeshed comments. > > I don't like "Of" here, which doesn't appear in Optional, and seems to > be used more frequently for factory methods. > > I suggest using Optional::orElse* method names, but kill leading noise > word "or". "Non-null else foo" is good programmer talk for "non-null > or else foo". (Speculation: The "or" is present in Optional mainly > to avoid reserved word "else".) > > - nonNullElse(T,T) (cf. Optional::orElse) > - nonNullElseGet(T,Supplier<T>) (cf. Optional::orElseGet) > - nonNullElseThrow(T,Supplier<X>) (cf. Optional::orElseThrow) > > ? John From chris.hegarty at oracle.com Thu Oct 8 22:18:38 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 8 Oct 2015 23:18:38 +0100 Subject: RFR [9] 8138978: Examine usages of sun.misc.IOUtils In-Reply-To: <561662B8.6070007@oracle.com> References: <A79916EE-69DE-49EB-9C22-3384290A7AFF@oracle.com> <561662B8.6070007@oracle.com> Message-ID: <D2B0B034-6D09-4FDB-9A99-0C03AC964988@oracle.com> > On 8 Oct 2015, at 13:34, Sean Mullan <sean.mullan at oracle.com> wrote: > > Looks fine to me, though I have one question below. Thanks for looking at this Sean. > On 10/7/15 2:19 PM, Chris Hegarty wrote: >> This primary motivation behind this bug [1] is the clearing out of >> sun.misc, in preparation for JEP 260 [2]. >> >> sun.misc.IOUtils is a JDK internal convenience utility class that >> provides a single method that offers bulk blocking InputStream read >> semantics. In 9, java.io.InputStream has been retrofitted with two >> methods that provide similar, but not quite the same, functionality, >> readNBytes and readAllBytes, see JDK-8080835 [3]. >> >> There are a number of places where IOUtils can be replaced with the >> appropriate supported API, readNBytes or readAllBytes. >> >> There are a number of places, mainly in the security implementation, >> that required to read a specific number of bytes ( not to end of >> stream ), where it is preferable to not preallocate the byte[] and >> allow it to "grow" lazily, to be defensive against protocol errors. >> These cases cannot use read[N|All]Bytes, so it makes sense to retain >> IOUtils but locate it in a package, sun.security.util, that makes it >> clear who its primary consumer is. > > Would it make sense to add a method to InputStream that provides that functionality the security classes need? I filed 8139206 to track this. -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8139206 > --Sean > >> >> http://cr.openjdk.java.net/~chegar/8138978/webrev.00/jdk/ >> http://cr.openjdk.java.net/~chegar/8138978/webrev.00/hotspot/ >> >> -Chris. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8138978 >> [2] https://bugs.openjdk.java.net/browse/JDK-8132928 >> [3] https://bugs.openjdk.java.net/browse/JDK-8080835 >> From stuart.marks at oracle.com Thu Oct 8 23:39:33 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 8 Oct 2015 16:39:33 -0700 Subject: RFC: draft API for JEP 269 Convenience Collection Factories Message-ID: <5616FEB5.5090104@oracle.com> Hi all, Please review and comment on this draft API for JEP 269, Convenience Collection Factories. For this review I'd like to focus on the API, and set aside implementation issues and discussion for later. JEP: http://openjdk.java.net/jeps/269 javadoc: http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151008.mod/ specdiff: http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151008.specdiff/overview-summary.html Most of the API is pretty straightforward, with fixed-arg and varargs "of()" factories for List, Set, ArrayList, and HashSet; and with fixed-arg "of()" factories and varargs "ofEntries()" factories for Map and HashMap. There are a few issues on which I'd like to solicit discussion. 1. Number of fixed arg overloads. I've somewhat arbitrarily provided up to 5 fixed-arg overloads for the lists and sets, and up to 8 pairs for the fixed-arg map factories. The rationale for 8 pairs is that there are 8 primitives, and various language processing tools often have maps for the primitive types. (But such tools also often need to handle the Void type, which exceeds the limit of 8. So this might need to change if we want to follow this rationale.) I also note that Guava's immutable factories provide 11 fixed-arg overloads for list, 5 for set, and 5 pairs for map. I'd be curious as to the rationale for this, and whether it also would apply to the JDK. 2. Other concrete collection factories. I've chosen to provide factories for the concrete collections ArrayList, HashSet, and HashMap, since those seem to be the most commonly used. Is there a need to provide factories for other concrete collections, such as LinkedHashMap? 3. Duplicate handling. My current thinking is for the Set and Map factories to throw IllegalArgumentException if a duplicate element or key is detected. The current draft specification is silent on this point. It needs to be specified, one way or another. The rationale for throwing an exception is that if these factories are used in a "literal like" fashion, then having a duplicate is almost certainly a programming error. Consider this example: Map<String,TypeUse> m = Map.ofEntries( entry("CDATA", CBuiltinLeafInfo.NORMALIZED_STRING), entry("ENTITY", CBuiltinLeafInfo.TOKEN), entry("ENTITIES", CBuiltinLeafInfo.STRING.makeCollection()), entry("ENUMERATION", CBuiltinLeafInfo.STRING.makeCollection()), entry("NMTOKEN", CBuiltinLeafInfo.TOKEN), entry("NMTOKENS", CBuiltinLeafInfo.STRING.makeCollection()), entry("ID", CBuiltinLeafInfo.ID), entry("IDREF", CBuiltinLeafInfo.IDREF), entry("IDREFS", TypeUseFactory.makeCollection(CBuiltinLeafInfo.IDREF)); entry("ENUMERATION", CBuiltinLeafInfo.TOKEN)); (derived from [1]) If duplicates were silently ignored, this might result in hard-to-spot errors. There's also the matter of which value ends up being used in the case of duplicate map keys, and whether this should be specified. A fairly obvious policy would be "last one wins" but I'm reluctant to specify that, as it starts to place unnecessary constraints on implementations. However, the alternative of leaving it unspecified is also unpalatable. I'm aware that very few programming systems with similar constructs will signal an error on duplicate elements. Python, Ruby, Groovy, Scala, and Perl all seem to allow duplicates in maps or equivalent, apparently with a last-wins policy. (Though sometimes it's hard to tell if the policy is specified.) The only system I've been able to find that explicitly rejects duplicates is Clojure, and this policy isn't without controversy. [2] The main rationale is to prevent programming errors. There is a python bug [3] where it was proposed that duplicates in a dict should raise an error or warning, also in order to catch programming errors. The request was rejected, not necessarily because it was a bad idea, but primarily because it would be a backward incompatible change. The easiest thing to do would simply to require last-wins, since "everybody else is doing it" ... but that doesn't mean it's right. Since we're introducing a new API here, there is no compatibility issue. Throwing an exception for duplicates seems like a good way to prevent a certain class of programming errors. What do people think? s'marks [1] http://hg.openjdk.java.net/jdk8/jdk8/jaxws/file/d03dd22762db/src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/TDTDReader.java#l420 [2] http://dev.clojure.org/display/design/Allow+duplicate+map+keys+and+set+elements [3] https://bugs.python.org/issue16385 From stuart.marks at oracle.com Fri Oct 9 00:09:54 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 8 Oct 2015 17:09:54 -0700 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <5616DBBF.1040209@Oracle.com> References: <5613D01F.3000107@Oracle.com> <5613FEE6.2010907@oracle.com> <1391860289.1215500.1444171338590.JavaMail.zimbra@u-pem.fr> <56159B9A.4040404@Oracle.com> <1319440457.2004194.1444294182369.JavaMail.zimbra@u-pem.fr> <56168166.5030903@Oracle.com> <1200530124.2619128.1444329461357.JavaMail.zimbra@u-pem.fr> <5616BF66.3010607@Oracle.com> <278013257.2631892.1444332861717.JavaMail.zimbra@u-pem.fr> <5616DBBF.1040209@Oracle.com> Message-ID: <561705D2.6050008@oracle.com> On 10/8/15 2:10 PM, Roger Riggs wrote: > I am curious as to Stuart's question about whether it is supposed to figure out > the overloads > and is a bug, or if it just too difficult to make the inference work. I talked this over (internal discussion) with Vicente Romero-Zaldivar, one of the compiler guys. He walked me through what the compiler is doing. He says this isn't a bug in the compiler. Here's what's going on. We have // (1) <T> T nonNullOf(T obj, T defaultObj) // (2) <T> T nonNullOf(T obj, Supplier<? extends T> defaultSupplier) and the code in question: void setSupplier(Supplier<String> arg) { Supplier<String> supplier = Objects.nonNullOf(arg, () -> ""); // ERROR } The compiler first does overload resolution, and chooses (2) because it's more specific. The lambda matches Supplier, a functional interface, more specifically than it matches T, which is unconstrained (essentially Object) at this point. Unfortunately we really wanted this code to call (1). But now that the compiler has chosen (2), it tries to infer T. There's no value of T that allows both the first and the second arg to match, resulting in the error. The usual problem with overloads is that resolution is ambiguous. This case is different. The compiler goes through the overload resolution process and comes up with an unambiguous answer. Unfortunately it's the "wrong" one, or at least, the one we as programmers didn't expect for this case. Once the compiler has chosen the "wrong" method, it proceeds down that path to an error. The conclusion here is that we need to adjust the API so that it avoids overloading. This can be done by changing the name or arity. I can't really think of another parameter for this method, so that leaves us with the name. We now return to our usual naming bikeshed.... :-) s'marks > > Thanks, Roger > > The variations: > nonNullOf(T, T) is ok but > nonNullOfOrGet(T, Supplier<T>) is poor > > Splitting between Of and Or > nonNullOf(T, T) > nonNullOrGet(T, Supplier<T>) - nope > > Sigh... > > > > On 10/8/2015 3:34 PM, forax at univ-mlv.fr wrote: >> >> >> ------------------------------------------------------------------------ >> >> *De: *"Roger Riggs" <Roger.Riggs at Oracle.com> >> *?: *forax at univ-mlv.fr >> *Cc: *"core-libs-dev" <core-libs-dev at openjdk.java.net> >> *Envoy?: *Jeudi 8 Octobre 2015 21:09:26 >> *Objet: *Re: RFR 9: 8138963 : java.lang.Objects new method to >> default to non-null >> >> So for you, method overloading is a mis-feature of the language >> because it inhibits readability. >> Though I might argue, that the magic type inference is the real >> culprit. >> In most coding cases, the types of the arguments are visible >> and/or via syntax and naming. >> >> Thanks, Roger >> >> >> I don't really like overloading mostly because the rules that govern >> overloading are too complex. When you introduce a new feature like auto-boxing >> or lambda auto-conversion in the language, you can not say that a call is >> ambiguous with the new rules because it will break backward compatibility, so >> you end up with weird overloading rules that you can only understand in the >> light of the Java history. >> >> Anyway, in this case the problem is not just overloading, it is the mix of >> overloading and type inference as you said. >> I vaguely remember that we, the lambda EG, discuss about javac emitting a >> warning for cases like this one. >> >> regards, >> R?mi >> >> >> >> >> On 10/8/2015 2:37 PM, forax at univ-mlv.fr wrote: >> >> Hi Roger, >> my point was that for me, all theses forms are ambiguous thus >> not readable. >> >> *De: *"Roger Riggs" <Roger.Riggs at Oracle.com> >> *?: *"Remi Forax" <forax at univ-mlv.fr> >> *Cc: *"core-libs-dev" <core-libs-dev at openjdk.java.net> >> *Envoy?: *Jeudi 8 Octobre 2015 16:44:54 >> *Objet: *Re: RFR 9: 8138963 : java.lang.Objects new method >> to default to non-null >> >> Hi Remi, >> >> On 10/8/2015 4:49 AM, Remi Forax wrote: >> >> Hi Roger, >> using overloads here seems to be a bad idea, >> as a nice puzzler, what does the compiler do for these two >> lines of code >> Supplier<String> supplier = Objects.nonNullOf(null, () -> >> null); >> Supplier<String> supplier2 = Objects.nonNullOf(null, () -> >> ""); >> >> The first form compiled and threw the expected NPE at runtime. >> >> >> I'm not sure you can say this is the expected result. Why the >> compiler doesn't call <T> T nonNullOf(T, T) and return () -> >> null as Supplier ? >> >> >> >> In the second case, the () -> "" is a supplier<String> not >> a Supplier<Supplier<String>>. >> The compiler correctly produced a error. >> >> Why the compiler doesn't select the method <T> T nonNullOf(T, >> T) instead, this version compiles ! >> >> and if you want more weirdness, what about ? >> Object o = Objects.nonNullOf"foo", null); >> >> >> >> I don't think the method name will help the developer much >> and just makes the name longer >> for everyone else who is not producing a >> Supplier<Supplier<T>>. >> >> >> maybe "nonNullOfGet" is a bad name, my point is that when you >> have several overloads like this, the result is not easy to >> predict (I suppose that people don't know by heart the chapter >> 15.12.2 of the JLS). >> >> [...] >> >> >> Thanks, Roger >> >> >> regards, >> R?mi >> >> >> >> otherwise apart form the remark of Stephen, the code is Ok. >> >> cheers, >> R?mi >> >> ----- Mail original ----- >> >> De: "Roger Riggs"<Roger.Riggs at Oracle.com> >> ?: "core-libs-dev"<core-libs-dev at openjdk.java.net> >> Envoy?: Jeudi 8 Octobre 2015 00:24:26 >> Objet: Re: RFR 9: 8138963 : java.lang.Objects new method >> to default to non-null >> >> Hi, >> >> The original intent was to simplify the filling in of >> default values >> (even if null). >> I took Remi's point about the canonical coalescing >> operator not always >> returning non-null >> but the push seems to be in the direction of making sure >> the result is >> always non-null. >> I'd rather add a few very useful methods and avoid those with >> diminishing returns. >> >> I note that nulls are discovered eventually, but doing >> more aggressive >> checking is preferred. >> I expect the compiler is able to squeeze out all the extra >> checks. >> >> In the current context of Objects that the jdk, I read the >> naming >> pattern of firstNonNull to imply >> access to some sequential data structure like an array or >> list; but it >> doesn't gel with me to apply it to the arg list >> (unless it was varargs). The pattern of naming us "of" >> as being >> factory producing an object >> from the arguments seems apropos and is concise. >> >> Please consider and comment: >> >> <T> T nonNullOf(T obj, T defaultObj); >> <T> T nonNullOf(T, obj, Supplier<T> defaultSupplier); >> >> Details are in the updated webrev: >> >> http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ >> >> Regards, Roger >> >> >> On 10/6/2015 6:42 PM, Remi Forax wrote: >> >> Null coalescing is a popular operator in several >> languages [1] and the >> usual semantics is nullOrElse and not firstNonNull. >> In languages like Kotlin or Swift, because there is a >> distinction between >> Object and Object?, it's not a big deal, you can not >> de-reference null by >> error, anyway. >> >> Also note that nullOrElseGet, the one that takes a >> supplier also exists in >> Groovy and Kotlin under the name null safe navigation. >> >> So even if i prefer the semantics of firstNonNull, i >> think we should also >> include both nullOrElse and nullOrElseGet. >> >> regards, >> R?mi >> >> [1]https://en.wikipedia.org/wiki/Null_coalescing_operator >> >> - >> >> >> >> >> > From john.r.rose at oracle.com Fri Oct 9 00:31:58 2015 From: john.r.rose at oracle.com (John Rose) Date: Thu, 8 Oct 2015 17:31:58 -0700 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <5616E345.9090609@Oracle.com> References: <5613D01F.3000107@Oracle.com> <5613FEE6.2010907@oracle.com> <1391860289.1215500.1444171338590.JavaMail.zimbra@u-pem.fr> <56159B9A.4040404@Oracle.com> <1319440457.2004194.1444294182369.JavaMail.zimbra@u-pem.fr> <56168166.5030903@Oracle.com> <1200530124.2619128.1444329461357.JavaMail.zimbra@u-pem.fr> <5616BF66.3010607@Oracle.com> <278013257.2631892.1444332861717.JavaMail.zimbra@u-pem.fr> <33D01469-37DE-4502-8112-0E4865733AFF@oracle.com> <5616E345.9090609@Oracle.com> Message-ID: <A4D5091B-C41A-4EA4-B811-F4C3658B8AB0@oracle.com> On Oct 8, 2015, at 2:42 PM, Roger Riggs <Roger.Riggs at Oracle.com> wrote: > > Thanks for the insight, I hope it will help cut down on the thrashing. > > Isn't there a 4th form that throws missing? There are four forms in Optional, but one of them returns "void" and is not relevant here, IMO. The third one I pointed out is the one that throws a programmable exception (e.g., IAE instead of NPE). > There was quite a bit of support for a version the never returned null and threw an exception if the replacement was null. This particular concern also transfers from Optional, with some forcing: Just as Optional::orElse cannot turn around and return an Optional::empty value, nonNullElse should not turn around and return a null. But, of course, the reason Optional::orElse doesn't return an empty is that the Java types forbid it (T != Optional<T>) while the issue is allowed by Java's always-nullable ref types. Anyway, I agree with the consensus that nonNullElse and nonNullElseGet should throw NPE instead of returning nulls. It may be instructive to link nulls to Optionals by encoding null-ness using Optional: <T> T nonNullElse(T x, T y) := Optional.ofNullable(x).orElseGet(() -> Optional.ofNullable(y).get()) <T> T nonNullElseGet(T x, Supplier<T> y) := Optional.ofNullable(x).orElseGet(() -> Optional.ofNullable(y.get()).get()) or: <T> T nonNullElse(T x, T y) := Objects.requireNonNull( Optional.ofNullable(x).orElse(y) ) <T> T nonNullElseGet(T x, Supplier<T> y) := Objects.requireNonNull( Optional.ofNullable(x).orElseGet(y) ) This leads me to yet another bikeshed color, FWIW: - T requireNonNull(T) (cf. Optional::get) - T requireNonNullElse(T,T) (cf. Optional::orElse) - T requireNonNullElseGet(T,Supplier<T>) (cf. Optional::orElseGet) - T requireNonNullElseThrow(T,Supplier<X>) (cf. Optional::orElseThrow) - T requireNonNull(T,String) (shorthand for common use of requireNonNullElseThrow) This spelling makes it abundantly clear that the return value will *never* be null, unlike some other APIs. I can imagine being content, as an IDE user, to see all of those options together, from a single completion gesture. ? John From john.r.rose at oracle.com Fri Oct 9 01:18:22 2015 From: john.r.rose at oracle.com (John Rose) Date: Thu, 8 Oct 2015 18:18:22 -0700 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <DDC775F6-63F7-4028-87B8-351594E5B9BE@azul.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561245E0.8030708@redhat.com> <38110705-2789-4050-913C-0568DD8B61E9@oracle.com> <DDC775F6-63F7-4028-87B8-351594E5B9BE@azul.com> Message-ID: <B93EDAA4-C5A3-434F-BBC7-6788BFDBC52B@oracle.com> On Oct 8, 2015, at 12:39 AM, Gil Tene <gil at azul.com> wrote: > > On the one hand: > > I like the idea of (an optional?) boolean parameter as a means of hinting at the thing that may terminate the spin. It's probably much more general than identifying a specific field or address. And it can be used to cover cases that poll multiple addresses (an or in the boolean) or look a termination time. If the JVM can track down the boolean's evaluation to dependencies on specific memory state changes, it could pass it on to hardware, if such hardware exists. Yep. And there is a user-mode MWAIT in SPARC M7, today. For Intel, Dave Dice wrote this up: https://blogs.oracle.com/dave/entry/monitor_mwait_for_spin_loops Also, from a cross-platform POV, a boolean would provide an easy to use "hook" for profiling how often the polling is failing. Failure frequency is an important input to the tuning of spin loops, isn't it? Why not feed that info through to the JVM? > On the other hard: > > Unfortunately, I don't think that hardware support that can receive the address information exists right now, (It does, on SPARC.) > and if/when it does, I'm not sure the semantics of passing the boolean through are enough to cover the actual way to use such hardware when it becomes available. The alternative is to have the JIT pattern-match for loop control around the call to Thread.yield. That is obviously less robust than having the user thread the poll condition bit through the poll primitive. > It is probably premature to design a generic way to provide addresses and/or state to this "spin until something interesting changes" stuff without looking at working examples. A single watched address API is much more likely to fit current implementations without being fragile. > > ARM v8's WFE is probably the most real user-mode-accesible thing for this right now (MWAIT isn't real yet, as it's not accessible from user mode). We can look at an example of how a spinloop needs to coordinate the use of WFE, SEVL, and the evaluation of memory location with load exclusive operations here: http://lxr.free-electrons.com/source/arch/arm64/include/asm/spinlock.h . The tricky part is that the SEVL needs to immediately proceed the loop (and all accesses that need to be watched by the WFE), but can't be part of the loop (if were in the loop the WFE would always trigger immediately). But the code in the spinning loop can can only track a single address (the exclusive tag in load exclusive applies only the the most recent address used), so it would be wrong to allow generic code in the spin (it would have to be code that watches exactly one address). > > My suspicion is that the "right" way to capture the various ways a spin loop would need to interact with RFE logic will be different than tracking things that can generically affect the value of a boolean. E.g. the evaluation of the boolean could be based on multiple addresses, and since it's not clear (in the API) that this is a problem, the benefits derived would be fragile. Having the JIT explore nearby loop structure for memory references is even more fragile. If we can agree that (a) there are advantages to profiling the boolean parameter for all platforms, and (b) the single-poll-variable case is likely to be optimizable sooner *with* a parameter than *without*, maybe this is enough to tip the scales towards boolean parameter. The idea would be that programmers would take a little extra thought when using yield(Z)Z, and get paid immediately from good profiling. They would get paid again later if and when platforms analyze data dependencies on the Z. If there's no initial payoff, then, yes, it is hard asking programmers to expend extra thought that only benefits on some platforrms. ? John From stuart.marks at oracle.com Fri Oct 9 01:34:48 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 8 Oct 2015 18:34:48 -0700 Subject: JEP 269: Convenience Factory Methods for Collections In-Reply-To: <CACzrW9Bf0YgsKqUew2Q_0z-1P8M72q3UxGgW1RJE7703DvxU5g@mail.gmail.com> References: <20150924000217.D476B7A327@eggemoggin.niobe.net> <CAGKkBks7CKsJngvagV15C47E6zncdS-ag2m2OOKGoTtm-+YFFw@mail.gmail.com> <1548646383.2640105.1443208816341.JavaMail.zimbra@u-pem.fr> <CAGKkBkveaKTmGbhYJ4J8NNzkD5DwMz+ZvhHufC5Q2tQHU5D3Jg@mail.gmail.com> <1536405490.3047562.1443881785146.JavaMail.zimbra@u-pem.fr> <561463AA.6070206@oracle.com> <CACzrW9Bf0YgsKqUew2Q_0z-1P8M72q3UxGgW1RJE7703DvxU5g@mail.gmail.com> Message-ID: <561719B8.4020604@oracle.com> On 10/7/15 2:30 AM, Stephen Colebourne wrote: > Given what we know now vs when the collections library ws created, I > think it would be a mistake to allow nulls. Developers that > desperately want null in there have other mechanisms to achieve that, > not just Optional. I too would argue against Optional in collections, > at least until value types exist, but thats a social discussion, not > one that can be controlled. Nicely put. It seems there's some consensus to disallow nulls. Whew! One bikeshed down, 23,498 to go. :-) s'marks From pbenedict at apache.org Fri Oct 9 02:39:33 2015 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 8 Oct 2015 21:39:33 -0500 Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <5616FEB5.5090104@oracle.com> References: <5616FEB5.5090104@oracle.com> Message-ID: <CABLGb9wJGoE=ujEs_XporTVpb37ikpSAUyhiJF4w=-UYzbXtgQ@mail.gmail.com> I don't think the statements "Creates an unmodifiable set containing X elements" is always true. Since sets cannot have duplicates, it's possible passing in X elements gives you less than that based on equality. I think the Set docs should say "...X possible elements if unique". Wordsmith something better if you can, of course. Cheers, Paul On Thu, Oct 8, 2015 at 6:39 PM, Stuart Marks <stuart.marks at oracle.com> wrote: > Hi all, > > Please review and comment on this draft API for JEP 269, Convenience > Collection Factories. For this review I'd like to focus on the API, and set > aside implementation issues and discussion for later. > > > JEP: > > http://openjdk.java.net/jeps/269 > > javadoc: > > > http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151008.mod/ > > specdiff: > > > http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151008.specdiff/overview-summary.html > > > Most of the API is pretty straightforward, with fixed-arg and varargs > "of()" factories for List, Set, ArrayList, and HashSet; and with fixed-arg > "of()" factories and varargs "ofEntries()" factories for Map and HashMap. > > There are a few issues on which I'd like to solicit discussion. > > 1. Number of fixed arg overloads. > > I've somewhat arbitrarily provided up to 5 fixed-arg overloads for the > lists and sets, and up to 8 pairs for the fixed-arg map factories. The > rationale for 8 pairs is that there are 8 primitives, and various language > processing tools often have maps for the primitive types. (But such tools > also often need to handle the Void type, which exceeds the limit of 8. So > this might need to change if we want to follow this rationale.) > > I also note that Guava's immutable factories provide 11 fixed-arg > overloads for list, 5 for set, and 5 pairs for map. I'd be curious as to > the rationale for this, and whether it also would apply to the JDK. > > 2. Other concrete collection factories. > > I've chosen to provide factories for the concrete collections ArrayList, > HashSet, and HashMap, since those seem to be the most commonly used. Is > there a need to provide factories for other concrete collections, such as > LinkedHashMap? > > 3. Duplicate handling. > > My current thinking is for the Set and Map factories to throw > IllegalArgumentException if a duplicate element or key is detected. The > current draft specification is silent on this point. It needs to be > specified, one way or another. > > The rationale for throwing an exception is that if these factories are > used in a "literal like" fashion, then having a duplicate is almost > certainly a programming error. Consider this example: > > Map<String,TypeUse> m = Map.ofEntries( > entry("CDATA", CBuiltinLeafInfo.NORMALIZED_STRING), > entry("ENTITY", CBuiltinLeafInfo.TOKEN), > entry("ENTITIES", CBuiltinLeafInfo.STRING.makeCollection()), > entry("ENUMERATION", CBuiltinLeafInfo.STRING.makeCollection()), > entry("NMTOKEN", CBuiltinLeafInfo.TOKEN), > entry("NMTOKENS", CBuiltinLeafInfo.STRING.makeCollection()), > entry("ID", CBuiltinLeafInfo.ID), > entry("IDREF", CBuiltinLeafInfo.IDREF), > entry("IDREFS", > TypeUseFactory.makeCollection(CBuiltinLeafInfo.IDREF)); > entry("ENUMERATION", CBuiltinLeafInfo.TOKEN)); > > (derived from [1]) > > If duplicates were silently ignored, this might result in hard-to-spot > errors. > > There's also the matter of which value ends up being used in the case of > duplicate map keys, and whether this should be specified. A fairly obvious > policy would be "last one wins" but I'm reluctant to specify that, as it > starts to place unnecessary constraints on implementations. However, the > alternative of leaving it unspecified is also unpalatable. > > I'm aware that very few programming systems with similar constructs will > signal an error on duplicate elements. Python, Ruby, Groovy, Scala, and > Perl all seem to allow duplicates in maps or equivalent, apparently with a > last-wins policy. (Though sometimes it's hard to tell if the policy is > specified.) > > The only system I've been able to find that explicitly rejects duplicates > is Clojure, and this policy isn't without controversy. [2] The main > rationale is to prevent programming errors. > > There is a python bug [3] where it was proposed that duplicates in a dict > should raise an error or warning, also in order to catch programming > errors. The request was rejected, not necessarily because it was a bad > idea, but primarily because it would be a backward incompatible change. > > The easiest thing to do would simply to require last-wins, since > "everybody else is doing it" ... but that doesn't mean it's right. Since > we're introducing a new API here, there is no compatibility issue. Throwing > an exception for duplicates seems like a good way to prevent a certain > class of programming errors. > > What do people think? > > s'marks > > [1] > http://hg.openjdk.java.net/jdk8/jdk8/jaxws/file/d03dd22762db/src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/TDTDReader.java#l420 > > [2] > http://dev.clojure.org/display/design/Allow+duplicate+map+keys+and+set+elements > > [3] https://bugs.python.org/issue16385 > > From gil at azul.com Fri Oct 9 06:56:02 2015 From: gil at azul.com (Gil Tene) Date: Fri, 9 Oct 2015 06:56:02 +0000 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <B93EDAA4-C5A3-434F-BBC7-6788BFDBC52B@oracle.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561245E0.8030708@redhat.com> <38110705-2789-4050-913C-0568DD8B61E9@oracle.com> <DDC775F6-63F7-4028-87B8-351594E5B9BE@azul.com> <B93EDAA4-C5A3-434F-BBC7-6788BFDBC52B@oracle.com> Message-ID: <A88BF292-9AE7-4D01-8584-D3A77E031971@azul.com> > On Oct 8, 2015, at 6:18 PM, John Rose <john.r.rose at oracle.com> wrote: > > On Oct 8, 2015, at 12:39 AM, Gil Tene <gil at azul.com> wrote: >> >> On the one hand: >> >> I like the idea of (an optional?) boolean parameter as a means of hinting at the thing that may terminate the spin. It's probably much more general than identifying a specific field or address. And it can be used to cover cases that poll multiple addresses (an or in the boolean) or look a termination time. If the JVM can track down the boolean's evaluation to dependencies on specific memory state changes, it could pass it on to hardware, if such hardware exists. > > Yep. And there is a user-mode MWAIT in SPARC M7, today. Cool. Didn't know that. So now It's SPARC M7 and ARM v8. Both fairly new, but the pattern of monitoring a single address (or range) and waiting on a potential change to it seems common (and similar to the kernel mode MONITOR/MWAIT in x86). Anything similar coming (or already here) in Power or MIPS? > For Intel, Dave Dice wrote this up: > https://blogs.oracle.com/dave/entry/monitor_mwait_for_spin_loops Cool writeup. But with the current need to transition to kernel mode this may work for loops that want to idle and save power and are willing to sacrifice reaction time to do so. But it is the opposite of what a spinHintLoop() would typically be looking to do. On modern x86, for example, adding a pause instruction improves the reaction speed of the spin loop (see charts attached to JEP), but adding the trapping cost and protection mode transition of a system call to do an MWAIT will almost certainly do the opposite. If/when MONITOR/MWAIT becomes available in user mode, it will join ARM v8 and SPARC M7 in a common useful paradigm. > Also, from a cross-platform POV, a boolean would provide an easy to use "hook" for profiling how often the polling is failing. Failure frequency is an important input to the tuning of spin loops, isn't it? Why not feed that info through to the JVM? I don't follow. Perhaps I'm missing something. Spin loops are "strange" in that they tend to not care about how "fast" they spin, but do care about their reaction time to a change in the thing(s) they are spinning on. I don't think profiling will help here? E.g. in the example tests for this JEP on Ivy Bridge Xeons, adding an intrinsified spinLoopHint() to the a simple spin volatile value loop appears to reduce the "spin throughput" by a significant ratio (3x-5x for L1-sharing threads), but also reduces the reaction time by 35-50%. > ... >> and if/when it does, I'm not sure the semantics of passing the boolean through are enough to cover the actual way to use such hardware when it becomes available. > > The alternative is to have the JIT pattern-match for loop control around the call to Thread.yield. That is obviously less robust than having the user thread the poll condition bit through the poll primitive. I dont' think that's the alternative. The alternative(s) I suggest require no analysis by the JIT: The main means of spin loop hinting I am suggesting is a simple no args hint. [Folks seem to be converging on using Thread as the home for this stuff, so I'll use that]: E.g.: while (!done) { Thread.spinLoopHint(); } The second form I'm suggesting (mostly in reaction to discussion on this thread) directly captures the notion that a single address is being monitored: E.g. volatile boolean done; static final Field doneField = ?; ... Thread.spinExecuteWhileTrue( () -> !done, doneField, this ); // ugly method name I'm not married to... or a slighltly more complicated: Thread.spinExecuteWhileTrue( () -> { count++; return !done;} , doneField, this ); [These Thread.spinExecuteWhileTrue() examples will execute the BooleanSupplier each time, but will only watch the specified field for changes in the spin loop, potentially pausing the loop until a change in the field is detected, but will not pause indefinitely. This can be implemented with a MONITOR/MWAIT, WFE/SEVL, or by just using a PAUSE instruction and not watching the field at all.] (for Java 9, a varhandle variant of the above reflection based model is probably more appropriate. I spelled this with the reflection form for readability by pre-varhandles-speakers). Neither of these forms require any specific JIT matching or exploration. We know the first form is fairly robust on architectures that support stuff like PAUSE. The second form will probably be robust both architectures that support MWAIT or WFE, and on those that support PAUSE (those just won't watch anything). On how this differs from a single boolean parameter: My notion (in the example above) of a single poll variable would be one that specifically designates the poll variable as a field (or maybe array index as an option), rather than provide a boolean parameter that is potentially evaluated based on data read from more than one memory location. The issue is that while it's an easy fit if the boolean is computed based on evaluating a single address, it becomes fragile if multiple addresses are involved and the hardware can only watch one (which is the current trend for ARM v8, SPARC M7, and a potential MONITOR/WAIT x86). It would be "hard" for a JIT to figure out which of the addresses read to compute the bollean should be watched in the spin. And getting it wrong can have potentially surprising consequences (not just lack of benefit, but terribly slow execution due to waiting for something that is not going to be externally modified and timing out each time before spinning). e.g. these probably look good to a programmer: while (!pollSpinExit(done1 || done 2 || (count++ > limit)) { } And it could translate to the following rough mixed pseudo code: SEVL loop: WFE ldaxrh %done1, [done] if (!(%done1 || done2 || (count++ > limit)) goto loop: ? But it could also be translated to: SEVL loop: WFE ldaxrh %done2, [done] if (!(done1 || %done2 || (count++ > limit)) goto loop: ? (or a third option that decides to watch count instead). None of these are "right". And there is nothing in the semantics that suggests which one to expect. You could fall back and say that you would only get the benefit if there is exactly one address used in deriving the boolean, but this would probably make it hard to code to and maintain. A form that forces you to specific the polling parameter would be less generic in expression, but will be less fragile to program to as well, IMO. > >> It is probably premature to design a generic way to provide addresses and/or state to this "spin until something interesting changes" stuff without looking at working examples. A single watched address API is much more likely to fit current implementations without being fragile. >> >> ARM v8's WFE is probably the most real user-mode-accesible thing for this right now (MWAIT isn't real yet, as it's not accessible from user mode). We can look at an example of how a spinloop needs to coordinate the use of WFE, SEVL, and the evaluation of memory location with load exclusive operations here: http://lxr.free-electrons.com/source/arch/arm64/include/asm/spinlock.h . The tricky part is that the SEVL needs to immediately proceed the loop (and all accesses that need to be watched by the WFE), but can't be part of the loop (if were in the loop the WFE would always trigger immediately). But the code in the spinning loop can can only track a single address (the exclusive tag in load exclusive applies only the the most recent address used), so it would be wrong to allow generic code in the spin (it would have to be code that watches exactly one address). >> >> My suspicion is that the "right" way to capture the various ways a spin loop would need to interact with RFE logic will be different than tracking things that can generically affect the value of a boolean. E.g. the evaluation of the boolean could be based on multiple addresses, and since it's not clear (in the API) that this is a problem, the benefits derived would be fragile. > > Having the JIT explore nearby loop structure for memory references is even more fragile. Agreed. Which is why I'm not suggesting it. > If we can agree that (a) there are advantages to profiling the boolean parameter for all platforms, and (b) the single-poll-variable case is likely to be optimizable sooner *with* a parameter than *without*, maybe this is enough to tip the scales towards boolean parameter. I guess that's where we differ: I don't see a benefit in profiling the spin loop, so we disagree on (a). And hence (b) is not relevant? Maybe I'm mis-reading what you mean by "profiling" and "optimizing" above? > The idea would be that programmers would take a little extra thought when using yield(Z)Z, and get paid immediately from good profiling. They would get paid again later if and when platforms analyze data dependencies on the Z. > > If there's no initial payoff, then, yes, it is hard asking programmers to expend extra thought that only benefits on some platforrms. Whatever the choices end up being, we could provide multiple signatures or APIs. E.g. I think that the no-args spinLoopHint() is the de-facto spinning model for x86 and Power (and have been for over a decade for everything outside of Java). So it's a safe bet and a natural form. The spin-execute-something-while-watching-a-single-address model is *probably* a good fit for some relatively young but very useful hardware capabilities, and can probably be captured in a long-lasting API as well. More complicated boolean-derived-from-pretty-much-anything or multi-address watching schemes are IMO too early to evaluate. E.g. they could potentially leverage some just-around-the-corner (or recently arrived) features like TSX and NCAS schemes, but since there is relatively little experience with using such things for spinning (outside of Java), it is probably pre-mature to solidify a Java API for them. BTW, even with user-mode MWAIT and cousins, and with the watch-a-single-address API forms, we may be looking at two separate motivations, and may want to consider a hint of which one is intended. E.g. one of spinLoopHint()'s main drivers is latency improvement, and the other is power reduction (with potential speed benefits or just power savings benefits). It appears that on x86 a PAUSE provides both, so there is no choice needed there. But MWAIT may be much more of a power-centric approach that sacrifices latency, and that may be OK for some and un-OK for others. We may want to have API variants that allow a hint about whether power-reduction or latency-reduction is the preferred driver. > > ? John > From paul.sandoz at oracle.com Fri Oct 9 07:59:22 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 9 Oct 2015 09:59:22 +0200 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <A4D5091B-C41A-4EA4-B811-F4C3658B8AB0@oracle.com> References: <5613D01F.3000107@Oracle.com> <5613FEE6.2010907@oracle.com> <1391860289.1215500.1444171338590.JavaMail.zimbra@u-pem.fr> <56159B9A.4040404@Oracle.com> <1319440457.2004194.1444294182369.JavaMail.zimbra@u-pem.fr> <56168166.5030903@Oracle.com> <1200530124.2619128.1444329461357.JavaMail.zimbra@u-pem.fr> <5616BF66.3010607@Oracle.com> <278013257.2631892.1444332861717.JavaMail.zimbra@u-pem.fr> <33D01469-37DE-4502-8112-0E4865733AFF@oracle.com> <5616E345.9090609@Oracle.com> <A4D5091B-C41A-4EA4-B811-F4C3658B8AB0@oracle.com> Message-ID: <BE829577-0D74-4BE3-93C9-B88D49AFFF3C@oracle.com> > On 9 Oct 2015, at 02:31, John Rose <john.r.rose at oracle.com> wrote: > > It may be instructive to link nulls to Optionals by encoding null-ness using Optional: > > <T> T nonNullElse(T x, T y) := Optional.ofNullable(x).orElseGet(() -> Optional.ofNullable(y).get()) > And with the new Optional.or [*] to be added soon the above could be expressed as: := Optional.ofNullable(x).or(() -> Optional.ofNullable(y)) Paul. [*] i am searching for a better name, but don?t want to derail this thread with such a discussion. > <T> T nonNullElseGet(T x, Supplier<T> y) := Optional.ofNullable(x).orElseGet(() -> Optional.ofNullable(y.get()).get()) > From sebastian.sickelmann at gmx.de Fri Oct 9 09:45:28 2015 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Fri, 9 Oct 2015 11:45:28 +0200 Subject: RFR: 5108778 Too many instances of java.lang.Boolean created in Java application(core-libs) In-Reply-To: <5616BCE6.9000108@oracle.com> References: <56157990.7020506@gmx.de> <5616BCE6.9000108@oracle.com> Message-ID: <56178CB8.1020108@gmx.de> On 10/08/2015 08:58 PM, Stuart Marks wrote: > On 10/7/15 12:59 PM, Sebastian Sickelmann wrote: >> http://cr.openjdk.java.net/~sebastian/5108778/core-libs/webrev.00/ >> >> jdk: >> The Boolean constructors are @Deprecated now so that we get >> compile-warnings for the uses. See also [0] and [1] >> >> [0] >> http://mail.openjdk.java.net/pipermail/discuss/2015-September/003804.html >> >> [1] >> http://mail.openjdk.java.net/pipermail/discuss/2015-October/003805.html > > > Hi Sebastian, > > I did suggest adding @Deprecated to the Boolean constructors, but only > in your own source tree, as a quick means of causing the compiler to > emit warnings for places where they're used. I don't think we should > actually go ahead and deprecate them at this time. So, please drop the > deprecation changes from your patch. Sorry for the misunderstanding. > > (As I've mentioned elsewhere, there is forthcoming work in the area of > deprecation, so the Boolean constructors will eventually be marked in > some way so that developers will be advised to update their code.) > > I do think the cleanup work to remove usages of the Boolean > constructors is worthwhile and that you should proceed with it. Thanks for the clarification. But than i will use my static analysis tool[1], because it runs in a few seconds after an incremental build. While using the deprecated option, take some more time cause i think a have to do a clean build to get all warnings. So please forget the core-libs webrev[0] [0] http://cr.openjdk.java.net/~sebastian/5108778/core-libs/webrev.00 > > s'marks > From scolebourne at joda.org Fri Oct 9 09:58:10 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 9 Oct 2015 10:58:10 +0100 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <A4D5091B-C41A-4EA4-B811-F4C3658B8AB0@oracle.com> References: <5613D01F.3000107@Oracle.com> <5613FEE6.2010907@oracle.com> <1391860289.1215500.1444171338590.JavaMail.zimbra@u-pem.fr> <56159B9A.4040404@Oracle.com> <1319440457.2004194.1444294182369.JavaMail.zimbra@u-pem.fr> <56168166.5030903@Oracle.com> <1200530124.2619128.1444329461357.JavaMail.zimbra@u-pem.fr> <5616BF66.3010607@Oracle.com> <278013257.2631892.1444332861717.JavaMail.zimbra@u-pem.fr> <33D01469-37DE-4502-8112-0E4865733AFF@oracle.com> <5616E345.9090609@Oracle.com> <A4D5091B-C41A-4EA4-B811-F4C3658B8AB0@oracle.com> Message-ID: <CACzrW9BPnBNKaXzLfZeJdD+5n_mZV-OM3TH+yD=suGB2mYR2CQ@mail.gmail.com> On 9 October 2015 at 01:31, John Rose <john.r.rose at oracle.com> wrote: > This leads me to yet another bikeshed color, FWIW: > > - T requireNonNull(T) (cf. Optional::get) > - T requireNonNullElse(T,T) (cf. Optional::orElse) > - T requireNonNullElseGet(T,Supplier<T>) (cf. Optional::orElseGet) > - T requireNonNullElseThrow(T,Supplier<X>) (cf. Optional::orElseThrow) > - T requireNonNull(T,String) (shorthand for common use of requireNonNullElseThrow) Note that there is already a new method in JDK 8 not listed above: requireNonNull(T, Supplier<String>) As such, I'm not convinced that requireNonNullElseThrow will pull its weight. I can see the benefits of this consistency of naming. (FWIW, I think the "require" prefix was a mistake, but that ship has sailed). If this naming is chosen, I'd like to see all the methods next to one another in the source file, which involves moving the method added in JDK 8. Stephen From aleksey.shipilev at oracle.com Fri Oct 9 11:16:20 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 9 Oct 2015 14:16:20 +0300 Subject: RFR: 5108778 Too many instances of java.lang.Boolean created in Java application(core-libs) In-Reply-To: <5616BCE6.9000108@oracle.com> References: <56157990.7020506@gmx.de> <5616BCE6.9000108@oracle.com> Message-ID: <5617A204.3080903@oracle.com> On 10/08/2015 09:58 PM, Stuart Marks wrote: > On 10/7/15 12:59 PM, Sebastian Sickelmann wrote: >> http://cr.openjdk.java.net/~sebastian/5108778/core-libs/webrev.00/ >> >> jdk: >> The Boolean constructors are @Deprecated now so that we get >> compile-warnings for the uses. See also [0] and [1] >> >> [0] >> http://mail.openjdk.java.net/pipermail/discuss/2015-September/003804.html >> [1] >> http://mail.openjdk.java.net/pipermail/discuss/2015-October/003805.html > > > Hi Sebastian, > > I did suggest adding @Deprecated to the Boolean constructors, but only > in your own source tree, as a quick means of causing the compiler to > emit warnings for places where they're used. I don't think we should > actually go ahead and deprecate them at this time. So, please drop the > deprecation changes from your patch. Sorry for the misunderstanding. > > (As I've mentioned elsewhere, there is forthcoming work in the area of > deprecation, so the Boolean constructors will eventually be marked in > some way so that developers will be advised to update their code.) Please note that "static final Boolean myBool = new Boolean(true).booleanValue()" is a spec-recommended way to avoid binary incompatibilities caused by conditional compilation. See JLS 13.4.9. Therefore, deprecating Boolean constructors is a spec issue as well. Thanks, -Aleksey From brian.goetz at oracle.com Fri Oct 9 11:41:38 2015 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 9 Oct 2015 13:41:38 +0200 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <CACzrW9BPnBNKaXzLfZeJdD+5n_mZV-OM3TH+yD=suGB2mYR2CQ@mail.gmail.com> References: <5613D01F.3000107@Oracle.com> <5613FEE6.2010907@oracle.com> <1391860289.1215500.1444171338590.JavaMail.zimbra@u-pem.fr> <56159B9A.4040404@Oracle.com> <1319440457.2004194.1444294182369.JavaMail.zimbra@u-pem.fr> <56168166.5030903@Oracle.com> <1200530124.2619128.1444329461357.JavaMail.zimbra@u-pem.fr> <5616BF66.3010607@Oracle.com> <278013257.2631892.1444332861717.JavaMail.zimbra@u-pem.fr> <33D01469-37DE-4502-8112-0E4865733AFF@oracle.com> <5616E345.9090609@Oracle.com> <A4D5091B-C41A-4EA4-B811-F4C3658B8AB0@oracle.com> <CACzrW9BPnBNKaXzLfZeJdD+5n_mZV-OM3TH+yD=suGB2mYR2CQ@mail.gmail.com> Message-ID: <91F25DF8-BC0F-44EB-A57D-A49FF7876DB9@oracle.com> The semantics of require* here was that it should throw if the precondition is violated. That lead to a different naming direction than the current use case, in which null is an expected value rather than an error. Sent from my iPhone > On Oct 9, 2015, at 11:58 AM, Stephen Colebourne <scolebourne at joda.org> wrote: > >> On 9 October 2015 at 01:31, John Rose <john.r.rose at oracle.com> wrote: >> This leads me to yet another bikeshed color, FWIW: >> >> - T requireNonNull(T) (cf. Optional::get) >> - T requireNonNullElse(T,T) (cf. Optional::orElse) >> - T requireNonNullElseGet(T,Supplier<T>) (cf. Optional::orElseGet) >> - T requireNonNullElseThrow(T,Supplier<X>) (cf. Optional::orElseThrow) >> - T requireNonNull(T,String) (shorthand for common use of requireNonNullElseThrow) > > Note that there is already a new method in JDK 8 not listed above: > requireNonNull(T, Supplier<String>) > As such, I'm not convinced that requireNonNullElseThrow will pull its weight. > > I can see the benefits of this consistency of naming. (FWIW, I think > the "require" prefix was a mistake, but that ship has sailed). If this > naming is chosen, I'd like to see all the methods next to one another > in the source file, which involves moving the method added in JDK 8. > > Stephen From peter.levart at gmail.com Fri Oct 9 12:08:24 2015 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 9 Oct 2015 14:08:24 +0200 Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <CABLGb9wJGoE=ujEs_XporTVpb37ikpSAUyhiJF4w=-UYzbXtgQ@mail.gmail.com> References: <5616FEB5.5090104@oracle.com> <CABLGb9wJGoE=ujEs_XporTVpb37ikpSAUyhiJF4w=-UYzbXtgQ@mail.gmail.com> Message-ID: <5617AE38.4040406@gmail.com> Hi, On 10/09/2015 04:39 AM, Paul Benedict wrote: > I don't think the statements "Creates an unmodifiable set containing X > elements" is always true. Since sets cannot have duplicates, it's possible > passing in X elements gives you less than that based on equality. I think > the Set docs should say "...X possible elements if unique". Wordsmith > something better if you can, of course. The same goes for Map.of(....). The question is should the factories uniquify the element(s) / key(s) or should they throw IllegalArgumentException? In case of the former, which element / entry should they keep - the one appearing 1st or last in the source? For example: Map<String, Integer> map = Map.of("a", 1, "a", 2); System.out.println(map); What should the result be: 1. {"a", 1} 2. {"a", 2} 3. IllegalArgumentException I don't have a preference, but I think it should be specified. Regards, Peter > > Cheers, > Paul > > On Thu, Oct 8, 2015 at 6:39 PM, Stuart Marks <stuart.marks at oracle.com> > wrote: > >> Hi all, >> >> Please review and comment on this draft API for JEP 269, Convenience >> Collection Factories. For this review I'd like to focus on the API, and set >> aside implementation issues and discussion for later. >> >> >> JEP: >> >> http://openjdk.java.net/jeps/269 >> >> javadoc: >> >> >> http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151008.mod/ >> >> specdiff: >> >> >> http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151008.specdiff/overview-summary.html >> >> >> Most of the API is pretty straightforward, with fixed-arg and varargs >> "of()" factories for List, Set, ArrayList, and HashSet; and with fixed-arg >> "of()" factories and varargs "ofEntries()" factories for Map and HashMap. >> >> There are a few issues on which I'd like to solicit discussion. >> >> 1. Number of fixed arg overloads. >> >> I've somewhat arbitrarily provided up to 5 fixed-arg overloads for the >> lists and sets, and up to 8 pairs for the fixed-arg map factories. The >> rationale for 8 pairs is that there are 8 primitives, and various language >> processing tools often have maps for the primitive types. (But such tools >> also often need to handle the Void type, which exceeds the limit of 8. So >> this might need to change if we want to follow this rationale.) >> >> I also note that Guava's immutable factories provide 11 fixed-arg >> overloads for list, 5 for set, and 5 pairs for map. I'd be curious as to >> the rationale for this, and whether it also would apply to the JDK. >> >> 2. Other concrete collection factories. >> >> I've chosen to provide factories for the concrete collections ArrayList, >> HashSet, and HashMap, since those seem to be the most commonly used. Is >> there a need to provide factories for other concrete collections, such as >> LinkedHashMap? >> >> 3. Duplicate handling. >> >> My current thinking is for the Set and Map factories to throw >> IllegalArgumentException if a duplicate element or key is detected. The >> current draft specification is silent on this point. It needs to be >> specified, one way or another. >> >> The rationale for throwing an exception is that if these factories are >> used in a "literal like" fashion, then having a duplicate is almost >> certainly a programming error. Consider this example: >> >> Map<String,TypeUse> m = Map.ofEntries( >> entry("CDATA", CBuiltinLeafInfo.NORMALIZED_STRING), >> entry("ENTITY", CBuiltinLeafInfo.TOKEN), >> entry("ENTITIES", CBuiltinLeafInfo.STRING.makeCollection()), >> entry("ENUMERATION", CBuiltinLeafInfo.STRING.makeCollection()), >> entry("NMTOKEN", CBuiltinLeafInfo.TOKEN), >> entry("NMTOKENS", CBuiltinLeafInfo.STRING.makeCollection()), >> entry("ID", CBuiltinLeafInfo.ID), >> entry("IDREF", CBuiltinLeafInfo.IDREF), >> entry("IDREFS", >> TypeUseFactory.makeCollection(CBuiltinLeafInfo.IDREF)); >> entry("ENUMERATION", CBuiltinLeafInfo.TOKEN)); >> >> (derived from [1]) >> >> If duplicates were silently ignored, this might result in hard-to-spot >> errors. >> >> There's also the matter of which value ends up being used in the case of >> duplicate map keys, and whether this should be specified. A fairly obvious >> policy would be "last one wins" but I'm reluctant to specify that, as it >> starts to place unnecessary constraints on implementations. However, the >> alternative of leaving it unspecified is also unpalatable. >> >> I'm aware that very few programming systems with similar constructs will >> signal an error on duplicate elements. Python, Ruby, Groovy, Scala, and >> Perl all seem to allow duplicates in maps or equivalent, apparently with a >> last-wins policy. (Though sometimes it's hard to tell if the policy is >> specified.) >> >> The only system I've been able to find that explicitly rejects duplicates >> is Clojure, and this policy isn't without controversy. [2] The main >> rationale is to prevent programming errors. >> >> There is a python bug [3] where it was proposed that duplicates in a dict >> should raise an error or warning, also in order to catch programming >> errors. The request was rejected, not necessarily because it was a bad >> idea, but primarily because it would be a backward incompatible change. >> >> The easiest thing to do would simply to require last-wins, since >> "everybody else is doing it" ... but that doesn't mean it's right. Since >> we're introducing a new API here, there is no compatibility issue. Throwing >> an exception for duplicates seems like a good way to prevent a certain >> class of programming errors. >> >> What do people think? >> >> s'marks >> >> [1] >> http://hg.openjdk.java.net/jdk8/jdk8/jaxws/file/d03dd22762db/src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/TDTDReader.java#l420 >> >> [2] >> http://dev.clojure.org/display/design/Allow+duplicate+map+keys+and+set+elements >> >> [3] https://bugs.python.org/issue16385 >> >> From daniel.fuchs at oracle.com Fri Oct 9 12:22:28 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 9 Oct 2015 14:22:28 +0200 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <91F25DF8-BC0F-44EB-A57D-A49FF7876DB9@oracle.com> References: <5613D01F.3000107@Oracle.com> <5613FEE6.2010907@oracle.com> <1391860289.1215500.1444171338590.JavaMail.zimbra@u-pem.fr> <56159B9A.4040404@Oracle.com> <1319440457.2004194.1444294182369.JavaMail.zimbra@u-pem.fr> <56168166.5030903@Oracle.com> <1200530124.2619128.1444329461357.JavaMail.zimbra@u-pem.fr> <5616BF66.3010607@Oracle.com> <278013257.2631892.1444332861717.JavaMail.zimbra@u-pem.fr> <33D01469-37DE-4502-8112-0E4865733AFF@oracle.com> <5616E345.9090609@Oracle.com> <A4D5091B-C41A-4EA4-B811-F4C3658B8AB0@oracle.com> <CACzrW9BPnBNKaXzLfZeJdD+5n_mZV-OM3TH+yD=suGB2mYR2CQ@mail.gmail.com> <91F25DF8-BC0F-44EB-A57D-A49FF7876DB9@oracle.com> Message-ID: <5617B184.7060803@oracle.com> Hi Brian, On 09/10/15 13:41, Brian Goetz wrote: > The semantics of require* here was that it should throw if the precondition > is violated. That lead to a different naming direction than the current > use case, in which null is an expected value rather than an error. Not necessarily - as the requireNonNull*(x, y) will throw if the resulting value would be null: the method either returns non-null or throws... In other words it throws if the postcondition is violated (which the existing require* method also do, since for those precondition and postcondition are the same). best regards, -- daniel > > Sent from my iPhone > >> On Oct 9, 2015, at 11:58 AM, Stephen Colebourne <scolebourne at joda.org> wrote: >> >>> On 9 October 2015 at 01:31, John Rose <john.r.rose at oracle.com> wrote: >>> This leads me to yet another bikeshed color, FWIW: >>> >>> - T requireNonNull(T) (cf. Optional::get) >>> - T requireNonNullElse(T,T) (cf. Optional::orElse) >>> - T requireNonNullElseGet(T,Supplier<T>) (cf. Optional::orElseGet) >>> - T requireNonNullElseThrow(T,Supplier<X>) (cf. Optional::orElseThrow) >>> - T requireNonNull(T,String) (shorthand for common use of requireNonNullElseThrow) >> >> Note that there is already a new method in JDK 8 not listed above: >> requireNonNull(T, Supplier<String>) >> As such, I'm not convinced that requireNonNullElseThrow will pull its weight. >> >> I can see the benefits of this consistency of naming. (FWIW, I think >> the "require" prefix was a mistake, but that ship has sailed). If this >> naming is chosen, I'd like to see all the methods next to one another >> in the source file, which involves moving the method added in JDK 8. >> >> Stephen From scolebourne at joda.org Fri Oct 9 13:11:47 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 9 Oct 2015 14:11:47 +0100 Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <5616FEB5.5090104@oracle.com> References: <5616FEB5.5090104@oracle.com> Message-ID: <CACzrW9A3MZja2wxsHZ7E0vSupkMJXMTQDqMQRjV548ArAF57Hw@mail.gmail.com> On 9 October 2015 at 00:39, Stuart Marks <stuart.marks at oracle.com> wrote: > 1. Number of fixed arg overloads. Guava follows this pattern: of(T) of(T, T) of(T, T, T) of(T, T, T, T... elements) whereas the proposal has of(T) of(T, T) of(T, T, T) of(T... elements) I'd be interested to know why Guava did it that way and what the trade offs are. > 2. Other concrete collection factories. > > I've chosen to provide factories for the concrete collections ArrayList, > HashSet, and HashMap, since those seem to be the most commonly used. Is > there a need to provide factories for other concrete collections, such as > LinkedHashMap? LinkedHashMap definitely LinkedList definitely not (as its very slow and use should not be encouraged). TreeSet/TreeMap, maybe, they'd need an extra parameter though. > 3. Duplicate handling. > > My current thinking is for the Set and Map factories to throw > IllegalArgumentException if a duplicate element or key is detected. Definitely. Given that ofEntries() takes a Map.Entry as input, why does Map.KeyValueHolder need to be public? This would require Map.entry(K,V) return Map.Entry, not Map.KeyValueHolder. Stephen From chris.hegarty at oracle.com Fri Oct 9 13:56:24 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 9 Oct 2015 14:56:24 +0100 Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <5617AE38.4040406@gmail.com> References: <5616FEB5.5090104@oracle.com> <CABLGb9wJGoE=ujEs_XporTVpb37ikpSAUyhiJF4w=-UYzbXtgQ@mail.gmail.com> <5617AE38.4040406@gmail.com> Message-ID: <5617C788.1060005@oracle.com> On 09/10/15 13:08, Peter Levart wrote: > Hi, > > On 10/09/2015 04:39 AM, Paul Benedict wrote: >> I don't think the statements "Creates an unmodifiable set containing X >> elements" is always true. Since sets cannot have duplicates, it's >> possible >> passing in X elements gives you less than that based on equality. I think >> the Set docs should say "...X possible elements if unique". Wordsmith >> something better if you can, of course. > > The same goes for Map.of(....). > > The question is should the factories uniquify the element(s) / key(s) or > should they throw IllegalArgumentException? > > In case of the former, which element / entry should they keep - the one > appearing 1st or last in the source? > > For example: > > Map<String, Integer> map = Map.of("a", 1, "a", 2); > System.out.println(map); > > What should the result be: > > 1. {"a", 1} > 2. {"a", 2} > 3. IllegalArgumentException I would expect IAE. It is clearly an error, right. -Chris > > I don't have a preference, but I think it should be specified. > > Regards, Peter > >> >> Cheers, >> Paul >> >> On Thu, Oct 8, 2015 at 6:39 PM, Stuart Marks <stuart.marks at oracle.com> >> wrote: >> >>> Hi all, >>> >>> Please review and comment on this draft API for JEP 269, Convenience >>> Collection Factories. For this review I'd like to focus on the API, >>> and set >>> aside implementation issues and discussion for later. >>> >>> >>> JEP: >>> >>> http://openjdk.java.net/jeps/269 >>> >>> javadoc: >>> >>> >>> http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151008.mod/ >>> >>> specdiff: >>> >>> >>> http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151008.specdiff/overview-summary.html >>> >>> >>> >>> Most of the API is pretty straightforward, with fixed-arg and varargs >>> "of()" factories for List, Set, ArrayList, and HashSet; and with >>> fixed-arg >>> "of()" factories and varargs "ofEntries()" factories for Map and >>> HashMap. >>> >>> There are a few issues on which I'd like to solicit discussion. >>> >>> 1. Number of fixed arg overloads. >>> >>> I've somewhat arbitrarily provided up to 5 fixed-arg overloads for the >>> lists and sets, and up to 8 pairs for the fixed-arg map factories. The >>> rationale for 8 pairs is that there are 8 primitives, and various >>> language >>> processing tools often have maps for the primitive types. (But such >>> tools >>> also often need to handle the Void type, which exceeds the limit of >>> 8. So >>> this might need to change if we want to follow this rationale.) >>> >>> I also note that Guava's immutable factories provide 11 fixed-arg >>> overloads for list, 5 for set, and 5 pairs for map. I'd be curious as to >>> the rationale for this, and whether it also would apply to the JDK. >>> >>> 2. Other concrete collection factories. >>> >>> I've chosen to provide factories for the concrete collections ArrayList, >>> HashSet, and HashMap, since those seem to be the most commonly used. Is >>> there a need to provide factories for other concrete collections, >>> such as >>> LinkedHashMap? >>> >>> 3. Duplicate handling. >>> >>> My current thinking is for the Set and Map factories to throw >>> IllegalArgumentException if a duplicate element or key is detected. The >>> current draft specification is silent on this point. It needs to be >>> specified, one way or another. >>> >>> The rationale for throwing an exception is that if these factories are >>> used in a "literal like" fashion, then having a duplicate is almost >>> certainly a programming error. Consider this example: >>> >>> Map<String,TypeUse> m = Map.ofEntries( >>> entry("CDATA", CBuiltinLeafInfo.NORMALIZED_STRING), >>> entry("ENTITY", CBuiltinLeafInfo.TOKEN), >>> entry("ENTITIES", CBuiltinLeafInfo.STRING.makeCollection()), >>> entry("ENUMERATION", CBuiltinLeafInfo.STRING.makeCollection()), >>> entry("NMTOKEN", CBuiltinLeafInfo.TOKEN), >>> entry("NMTOKENS", CBuiltinLeafInfo.STRING.makeCollection()), >>> entry("ID", CBuiltinLeafInfo.ID), >>> entry("IDREF", CBuiltinLeafInfo.IDREF), >>> entry("IDREFS", >>> >>> TypeUseFactory.makeCollection(CBuiltinLeafInfo.IDREF)); >>> entry("ENUMERATION", CBuiltinLeafInfo.TOKEN)); >>> >>> (derived from [1]) >>> >>> If duplicates were silently ignored, this might result in hard-to-spot >>> errors. >>> >>> There's also the matter of which value ends up being used in the case of >>> duplicate map keys, and whether this should be specified. A fairly >>> obvious >>> policy would be "last one wins" but I'm reluctant to specify that, as it >>> starts to place unnecessary constraints on implementations. However, the >>> alternative of leaving it unspecified is also unpalatable. >>> >>> I'm aware that very few programming systems with similar constructs will >>> signal an error on duplicate elements. Python, Ruby, Groovy, Scala, and >>> Perl all seem to allow duplicates in maps or equivalent, apparently >>> with a >>> last-wins policy. (Though sometimes it's hard to tell if the policy is >>> specified.) >>> >>> The only system I've been able to find that explicitly rejects >>> duplicates >>> is Clojure, and this policy isn't without controversy. [2] The main >>> rationale is to prevent programming errors. >>> >>> There is a python bug [3] where it was proposed that duplicates in a >>> dict >>> should raise an error or warning, also in order to catch programming >>> errors. The request was rejected, not necessarily because it was a bad >>> idea, but primarily because it would be a backward incompatible change. >>> >>> The easiest thing to do would simply to require last-wins, since >>> "everybody else is doing it" ... but that doesn't mean it's right. Since >>> we're introducing a new API here, there is no compatibility issue. >>> Throwing >>> an exception for duplicates seems like a good way to prevent a certain >>> class of programming errors. >>> >>> What do people think? >>> >>> s'marks >>> >>> [1] >>> http://hg.openjdk.java.net/jdk8/jdk8/jaxws/file/d03dd22762db/src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/TDTDReader.java#l420 >>> >>> >>> [2] >>> http://dev.clojure.org/display/design/Allow+duplicate+map+keys+and+set+elements >>> >>> >>> [3] https://bugs.python.org/issue16385 >>> >>> > From Roger.Riggs at Oracle.com Fri Oct 9 15:46:09 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 9 Oct 2015 11:46:09 -0400 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <5617B184.7060803@oracle.com> References: <5613D01F.3000107@Oracle.com> <5613FEE6.2010907@oracle.com> <1391860289.1215500.1444171338590.JavaMail.zimbra@u-pem.fr> <56159B9A.4040404@Oracle.com> <1319440457.2004194.1444294182369.JavaMail.zimbra@u-pem.fr> <56168166.5030903@Oracle.com> <1200530124.2619128.1444329461357.JavaMail.zimbra@u-pem.fr> <5616BF66.3010607@Oracle.com> <278013257.2631892.1444332861717.JavaMail.zimbra@u-pem.fr> <33D01469-37DE-4502-8112-0E4865733AFF@oracle.com> <5616E345.9090609@Oracle.com> <A4D5091B-C41A-4EA4-B811-F4C3658B8AB0@oracle.com> <CACzrW9BPnBNKaXzLfZeJdD+5n_mZV-OM3TH+yD=suGB2mYR2CQ@mail.gmail.com> <91F25DF8-BC0F-44EB-A57D-A49FF7876DB9@oracle.com> <5617B184.7060803@oracle.com> Message-ID: <5617E141.7000503@Oracle.com> Hi, The primary purpose of the existing 'requireNonNull' methods is to check for null and throw an exception. It is used for explicit testing and producing a cogent exception. Returning the value was a secondary benefit that allowed it to be used in fluent expressions. The purpose of the new methods is to provide a default value (non-null); throwing an exception is secondary. This is consistent with the behavior and intent of the Optional methods. So, I think using the more concise naming consistent with Optional is preferred because it is more readable and usable. New Methods: - T nonNullElse(T,T) (cf. Optional::orElse) - T nonNullElseGet(T,Supplier<T>) (cf. Optional::orElseGet) The existing methods cover the cases for checking and throwing exceptions. - T requireNonNull(T) (cf. Optional::get) - T requireNonNull(T,String) (shorthand for common use of requireNonNullElseThrow) Except for throwing some exception other than NPE, which is included in Optional.orElseThrow - T requireNonNullElseThrow(T,Supplier<X>) (cf. Optional::orElseThrow) Combines two different purposes and I don't think it pulls it own weight in the Objects case. More general would be T requireNonNullThrow(T, Supplier<X>). (not proposed) Roger webrev: http://cr.openjdk.java.net/~rriggs//webrev-object-non-null On 10/9/2015 8:22 AM, Daniel Fuchs wrote: > Hi Brian, > > On 09/10/15 13:41, Brian Goetz wrote: >> The semantics of require* here was that it should throw if the >> precondition >> is violated. That lead to a different naming direction than the current >> use case, in which null is an expected value rather than an error. > > Not necessarily - as the requireNonNull*(x, y) will throw if the > resulting value would be null: the method either returns non-null > or throws... In other words it throws if the postcondition > is violated (which the existing require* method also do, > since for those precondition and postcondition are the same). > > best regards, > > -- daniel > >> >> Sent from my iPhone >> >>> On Oct 9, 2015, at 11:58 AM, Stephen Colebourne >>> <scolebourne at joda.org> wrote: >>> >>>> On 9 October 2015 at 01:31, John Rose <john.r.rose at oracle.com> wrote: >>>> This leads me to yet another bikeshed color, FWIW: >>>> >>>> - T requireNonNull(T) (cf. Optional::get) >>>> - T requireNonNullElse(T,T) (cf. Optional::orElse) >>>> - T requireNonNullElseGet(T,Supplier<T>) (cf. Optional::orElseGet) >>>> - T requireNonNullElseThrow(T,Supplier<X>) (cf. Optional::orElseThrow) >>>> - T requireNonNull(T,String) (shorthand for common use of >>>> requireNonNullElseThrow) >>> >>> Note that there is already a new method in JDK 8 not listed above: >>> requireNonNull(T, Supplier<String>) >>> As such, I'm not convinced that requireNonNullElseThrow will pull >>> its weight. >>> >>> I can see the benefits of this consistency of naming. (FWIW, I think >>> the "require" prefix was a mistake, but that ship has sailed). If this >>> naming is chosen, I'd like to see all the methods next to one another >>> in the source file, which involves moving the method added in JDK 8. >>> >>> Stephen > From chris.hegarty at oracle.com Fri Oct 9 17:23:26 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 9 Oct 2015 18:23:26 +0100 Subject: RFR [9] 8139307: Remove sun.misc.ConditionLock and Lock Message-ID: <9069DB82-1CFE-4018-9941-9DFCAF1F0EB7@oracle.com> The functionality provided by these classes has long since been provided by supported APIs in java.util.concurrent.locks. Nothing internal, or external ( to the best of my knowledge ), to the JDK is depending on these classes. They should simply be removed. $ hg rm src/java.base/share/classes/sun/misc/ConditionLock.java $ hg rm src/java.base/share/classes/sun/misc/Lock.java -Chris. P.S. I did not feel it necessary to generate a webrev for this change. From lance.andersen at oracle.com Fri Oct 9 17:31:30 2015 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 9 Oct 2015 13:31:30 -0400 Subject: RFR [9] 8139307: Remove sun.misc.ConditionLock and Lock In-Reply-To: <9069DB82-1CFE-4018-9941-9DFCAF1F0EB7@oracle.com> References: <9069DB82-1CFE-4018-9941-9DFCAF1F0EB7@oracle.com> Message-ID: <422DC2A6-70A5-4291-B4E2-714DC13F7172@oracle.com> Agree a webrev would be silly. Trust you on this and +1 Best Lance On Oct 9, 2015, at 1:23 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote: > The functionality provided by these classes has long since been provided > by supported APIs in java.util.concurrent.locks. Nothing internal, or external > ( to the best of my knowledge ), to the JDK is depending on these classes. > They should simply be removed. > > $ hg rm src/java.base/share/classes/sun/misc/ConditionLock.java > $ hg rm src/java.base/share/classes/sun/misc/Lock.java > > -Chris. > > P.S. I did not feel it necessary to generate a webrev for this change. 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 aleksey.shipilev at oracle.com Fri Oct 9 17:33:09 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 9 Oct 2015 20:33:09 +0300 Subject: RFR [9] 8139307: Remove sun.misc.ConditionLock and Lock In-Reply-To: <9069DB82-1CFE-4018-9941-9DFCAF1F0EB7@oracle.com> References: <9069DB82-1CFE-4018-9941-9DFCAF1F0EB7@oracle.com> Message-ID: <5617FA55.6070809@oracle.com> On 10/09/2015 08:23 PM, Chris Hegarty wrote: > The functionality provided by these classes has long since been provided > by supported APIs in java.util.concurrent.locks. Nothing internal, or external > ( to the best of my knowledge ), to the JDK is depending on these classes. > They should simply be removed. > > $ hg rm src/java.base/share/classes/sun/misc/ConditionLock.java > $ hg rm src/java.base/share/classes/sun/misc/Lock.java +1 Thanks, -Aleksey From Alan.Bateman at oracle.com Fri Oct 9 18:04:19 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 9 Oct 2015 19:04:19 +0100 Subject: RFR [9] 8139307: Remove sun.misc.ConditionLock and Lock In-Reply-To: <9069DB82-1CFE-4018-9941-9DFCAF1F0EB7@oracle.com> References: <9069DB82-1CFE-4018-9941-9DFCAF1F0EB7@oracle.com> Message-ID: <561801A3.2020605@oracle.com> On 09/10/2015 18:23, Chris Hegarty wrote: > The functionality provided by these classes has long since been provided > by supported APIs in java.util.concurrent.locks. Nothing internal, or external > ( to the best of my knowledge ), to the JDK is depending on these classes. > They should simply be removed. > > $ hg rm src/java.base/share/classes/sun/misc/ConditionLock.java > $ hg rm src/java.base/share/classes/sun/misc/Lock.java > > -Chris. > > P.S. I did not feel it necessary to generate a webrev for this change. Got for it. From martinrb at google.com Fri Oct 9 18:12:23 2015 From: martinrb at google.com (Martin Buchholz) Date: Fri, 9 Oct 2015 11:12:23 -0700 Subject: RFR [9] 8139307: Remove sun.misc.ConditionLock and Lock In-Reply-To: <9069DB82-1CFE-4018-9941-9DFCAF1F0EB7@oracle.com> References: <9069DB82-1CFE-4018-9941-9DFCAF1F0EB7@oracle.com> Message-ID: <CA+kOe09hQ_oUN2rXbRd=O6W7WfwJkqPbjJu0yXB3gg2ePfBgbw@mail.gmail.com> If I ever knew about these classes, I have long forgotten! On Fri, Oct 9, 2015 at 10:23 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote: > The functionality provided by these classes has long since been provided > by supported APIs in java.util.concurrent.locks. Nothing internal, or > external > ( to the best of my knowledge ), to the JDK is depending on these classes. > They should simply be removed. > > $ hg rm src/java.base/share/classes/sun/misc/ConditionLock.java > $ hg rm src/java.base/share/classes/sun/misc/Lock.java > > -Chris. > > P.S. I did not feel it necessary to generate a webrev for this change. From stuart.marks at oracle.com Fri Oct 9 18:51:09 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 9 Oct 2015 11:51:09 -0700 Subject: RFR [9] 8139307: Remove sun.misc.ConditionLock and Lock In-Reply-To: <9069DB82-1CFE-4018-9941-9DFCAF1F0EB7@oracle.com> References: <9069DB82-1CFE-4018-9941-9DFCAF1F0EB7@oracle.com> Message-ID: <56180C9D.9000200@oracle.com> On 10/9/15 10:23 AM, Chris Hegarty wrote: > The functionality provided by these classes has long since been provided > by supported APIs in java.util.concurrent.locks. Nothing internal, or external > ( to the best of my knowledge ), to the JDK is depending on these classes. > They should simply be removed. > > $ hg rm src/java.base/share/classes/sun/misc/ConditionLock.java > $ hg rm src/java.base/share/classes/sun/misc/Lock.java > > -Chris. > > P.S. I did not feel it necessary to generate a webrev for this change. Dr Deprecator approves! From chris.hegarty at oracle.com Fri Oct 9 18:54:32 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 9 Oct 2015 19:54:32 +0100 Subject: RFR [9] 8139307: Remove sun.misc.ConditionLock and Lock In-Reply-To: <56180C9D.9000200@oracle.com> References: <9069DB82-1CFE-4018-9941-9DFCAF1F0EB7@oracle.com> <56180C9D.9000200@oracle.com> Message-ID: <A22DFBF0-19EB-4295-B8A5-D6B1456C8E98@oracle.com> On 9 Oct 2015, at 19:51, Stuart Marks <stuart.marks at oracle.com> wrote: > On 10/9/15 10:23 AM, Chris Hegarty wrote: >> The functionality provided by these classes has long since been provided >> by supported APIs in java.util.concurrent.locks. Nothing internal, or external >> ( to the best of my knowledge ), to the JDK is depending on these classes. >> They should simply be removed. >> >> $ hg rm src/java.base/share/classes/sun/misc/ConditionLock.java >> $ hg rm src/java.base/share/classes/sun/misc/Lock.java >> >> -Chris. >> >> P.S. I did not feel it necessary to generate a webrev for this change. > > Dr Deprecator approves! Hmmm.. does Dr Deprecator have an OpenJDK userId? If not, we should have one assigned! ;-) -Chris. From mandy.chung at oracle.com Fri Oct 9 18:55:03 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 09 Oct 2015 11:55:03 -0700 Subject: RFR [9] 8139307: Remove sun.misc.ConditionLock and Lock In-Reply-To: <9069DB82-1CFE-4018-9941-9DFCAF1F0EB7@oracle.com> References: <9069DB82-1CFE-4018-9941-9DFCAF1F0EB7@oracle.com> Message-ID: <56180D87.7090200@oracle.com> +1 Mandy P.S. These two classes do not show up in the list of JDK internal API referenced I gathered. On 10/09/2015 10:23 AM, Chris Hegarty wrote: > The functionality provided by these classes has long since been provided > by supported APIs in java.util.concurrent.locks. Nothing internal, or external > ( to the best of my knowledge ), to the JDK is depending on these classes. > They should simply be removed. > > $ hg rm src/java.base/share/classes/sun/misc/ConditionLock.java > $ hg rm src/java.base/share/classes/sun/misc/Lock.java > > -Chris. > > P.S. I did not feel it necessary to generate a webrev for this change. From stuart.marks at oracle.com Fri Oct 9 18:58:08 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 9 Oct 2015 11:58:08 -0700 Subject: RFR: 5108778 Too many instances of java.lang.Boolean created in Java application(core-libs) In-Reply-To: <5617A204.3080903@oracle.com> References: <56157990.7020506@gmx.de> <5616BCE6.9000108@oracle.com> <5617A204.3080903@oracle.com> Message-ID: <56180E40.7010302@oracle.com> On 10/9/15 4:16 AM, Aleksey Shipilev wrote: > Please note that "static final Boolean myBool = new > Boolean(true).booleanValue()" is a spec-recommended way to avoid binary > incompatibilities caused by conditional compilation. See JLS 13.4.9. > Therefore, deprecating Boolean constructors is a spec issue as well. Well, not "recommended" :-) but point well taken. From JLS 13.4.9: > We note, but do not recommend, that if a field of primitive type of an > interface may change, its value may be expressed idiomatically as in: > boolean debug = new Boolean(true).booleanValue(); The bit about conditional compilation is with regard to constant expressions. The goal here is to get a boolean value into the initializer of a field, but to have that initializer not be a constant expression. I think that Boolean.valueOf(true).booleanValue() would be sufficient for this and avoids using the constructor. I'll file a bug on the JLS for this. Thanks! s'marks From chris.hegarty at oracle.com Fri Oct 9 18:59:46 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 9 Oct 2015 19:59:46 +0100 Subject: RFR [9] 8139297: java.lang.NoClassDefFoundError: Could not initialize class jdk.internal.jimage.ImageNativeSubstrate Message-ID: <B2973B6F-65EC-4B10-8970-9068F94BD9D0@oracle.com> This is a little temporary solution to get the jrt-fs up and running again with JDK 8, until JDK-8137017 [1] can be resolved. It is fair game for an unchecked Exception or Error thrown during class initialization to result in a NCDFE. The code in BasicImageReader should catch java.lang.LinkageError, rather than UnsatisfiedLinkError ( LinkageError is the supertype of NCDFE and UnsatisfiedLinkError ), so that it falls over the the Java implementation when libjimage is not in the runtime image. diff --git a/src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java b/src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java --- a/src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java +++ b/src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java @@ -58,7 +58,7 @@ try { substrate = ImageNativeSubstrate.openImage(imagePath, byteOrder); - } catch (UnsatisfiedLinkError ex) { + } catch (LinkageError ex) { substrate = ImageJavaSubstrate.openImage(imagePath, byteOrder); } -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8137017 From john.r.rose at oracle.com Fri Oct 9 19:10:26 2015 From: john.r.rose at oracle.com (John Rose) Date: Fri, 9 Oct 2015 12:10:26 -0700 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <91F25DF8-BC0F-44EB-A57D-A49FF7876DB9@oracle.com> References: <5613D01F.3000107@Oracle.com> <5613FEE6.2010907@oracle.com> <1391860289.1215500.1444171338590.JavaMail.zimbra@u-pem.fr> <56159B9A.4040404@Oracle.com> <1319440457.2004194.1444294182369.JavaMail.zimbra@u-pem.fr> <56168166.5030903@Oracle.com> <1200530124.2619128.1444329461357.JavaMail.zimbra@u-pem.fr> <5616BF66.3010607@Oracle.com> <278013257.2631892.1444332861717.JavaMail.zimbra@u-pem.fr> <33D01469-37DE-4502-8112-0E4865733AFF@oracle.com> <5616E345.9090609@Oracle.com> <A4D5091B-C41A-4EA4-B811-F4C3658B8AB0@oracle.com> <CACzrW9BPnBNKaXzLfZeJdD+5n_mZV-OM3TH+yD=suGB2mYR2CQ@mail.gmail.com> <91F25DF8-BC0F-44EB-A57D-A49FF7876DB9@oracle.com> Message-ID: <33D4BF6E-A38D-4B52-BE01-994D773E5CAA@oracle.com> My point, and Daniel's point, is that requireNonNull can be re-interpreted (ret-conned) as enforcing a post-condition instead of a pre-condition. (The logic of JDK 8 rNN allows either view equally.) Then all of these API points hang together very nicely. After I tinkered with the cross-simulation to Optional this insight just fell out of the equations: It's a rare case of Math improving English. Roger, it's a judgement call, but I don't think the API points differ as much as you say they do. ? John On Oct 9, 2015, at 4:41 AM, Brian Goetz <brian.goetz at oracle.com> wrote: > > The semantics of require* here was that it should throw if the precondition is violated. That lead to a different naming direction than the current use case, in which null is an expected value rather than an error. > > Sent from my iPhone > >> On Oct 9, 2015, at 11:58 AM, Stephen Colebourne <scolebourne at joda.org> wrote: >> >>> On 9 October 2015 at 01:31, John Rose <john.r.rose at oracle.com> wrote: >>> This leads me to yet another bikeshed color, FWIW: >>> >>> - T requireNonNull(T) (cf. Optional::get) >>> - T requireNonNullElse(T,T) (cf. Optional::orElse) >>> - T requireNonNullElseGet(T,Supplier<T>) (cf. Optional::orElseGet) >>> - T requireNonNullElseThrow(T,Supplier<X>) (cf. Optional::orElseThrow) >>> - T requireNonNull(T,String) (shorthand for common use of requireNonNullElseThrow) >> >> Note that there is already a new method in JDK 8 not listed above: >> requireNonNull(T, Supplier<String>) >> As such, I'm not convinced that requireNonNullElseThrow will pull its weight. >> >> I can see the benefits of this consistency of naming. (FWIW, I think >> the "require" prefix was a mistake, but that ship has sailed). If this >> naming is chosen, I'd like to see all the methods next to one another >> in the source file, which involves moving the method added in JDK 8. >> >> Stephen From Alan.Bateman at oracle.com Fri Oct 9 19:18:49 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 9 Oct 2015 20:18:49 +0100 Subject: RFR [9] 8139297: java.lang.NoClassDefFoundError: Could not initialize class jdk.internal.jimage.ImageNativeSubstrate In-Reply-To: <B2973B6F-65EC-4B10-8970-9068F94BD9D0@oracle.com> References: <B2973B6F-65EC-4B10-8970-9068F94BD9D0@oracle.com> Message-ID: <56181319.5050209@oracle.com> On 09/10/2015 19:59, Chris Hegarty wrote: > This is a little temporary solution to get the jrt-fs up and running again > with JDK 8, until JDK-8137017 [1] can be resolved. > > It is fair game for an unchecked Exception or Error thrown during > class initialization to result in a NCDFE. The code in BasicImageReader > should catch java.lang.LinkageError, rather than UnsatisfiedLinkError > ( LinkageError is the supertype of NCDFE and UnsatisfiedLinkError ), > so that it falls over the the Java implementation when libjimage is not > in the runtime image. > > diff --git a/src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java b/src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java > --- a/src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java > +++ b/src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java > @@ -58,7 +58,7 @@ > > try { > substrate = ImageNativeSubstrate.openImage(imagePath, byteOrder); > - } catch (UnsatisfiedLinkError ex) { > + } catch (LinkageError ex) { > substrate = ImageJavaSubstrate.openImage(imagePath, byteOrder); > } > I realize this is a temporary fix but what is the specific exception that is thrown here (just asking catching LinkageError could hide other issues here)? Do we have an issue submitted to fix the real issue here as it should never attempt to use the native implementation when on JDK 8 or when targeting a different run-time image. -Alan From sebastian.sickelmann at gmx.de Fri Oct 9 19:23:08 2015 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Fri, 9 Oct 2015 21:23:08 +0200 Subject: RFR: 5108778 Too many instances of java.lang.Boolean created in Java application(core-libs) In-Reply-To: <56180E40.7010302@oracle.com> References: <56157990.7020506@gmx.de> <5616BCE6.9000108@oracle.com> <5617A204.3080903@oracle.com> <56180E40.7010302@oracle.com> Message-ID: <5618141C.6000504@gmx.de> On 10/09/2015 08:58 PM, Stuart Marks wrote: > On 10/9/15 4:16 AM, Aleksey Shipilev wrote: >> Please note that "static final Boolean myBool = new >> Boolean(true).booleanValue()" is a spec-recommended way to avoid binary >> incompatibilities caused by conditional compilation. See JLS 13.4.9. >> Therefore, deprecating Boolean constructors is a spec issue as well. > > Well, not "recommended" :-) but point well taken. From JLS 13.4.9: I didn't know that there is a recommended workaround for this in the JLS, but maybe it is in the wrong chapter. Chapter "13 Binary Compatibility" is fine for the first part of "13.4.9 |final| Fields and |static| Constant Variables". But the workaround for should be documented in a chapter that handles the conditional compilation. The only place i could find is the end of "14.21. Unreachable Statements" > >> We note, but do not recommend, that if a field of primitive type of an >> interface may change, its value may be expressed idiomatically as in: >> boolean debug = new Boolean(true).booleanValue(); > > The bit about conditional compilation is with regard to constant > expressions. The goal here is to get a boolean value into the > initializer of a field, but to have that initializer not be a constant > expression. I think that > > Boolean.valueOf(true).booleanValue() I have tried it. And it works as described on primitive types. So a static final Boolean myBool = new Boolean(true).booleanValue() is not needed because- static final Boolean myBool = true works too due to autoboxing and implicitly changing to static final Boolean myBool = Boolean.valueOf(true) > > would be sufficient for this and avoids using the constructor. And i think i would use Boolean.TRUE.booleanValue() to do the trick on booleans. The valueOf works best with every other Wrapper-Type. > > I'll file a bug on the JLS for this. What is the Bug-Number. Maybe i can watch and comment on this. Thanks > > Thanks! > > s'marks > From Alan.Bateman at oracle.com Fri Oct 9 19:26:30 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 9 Oct 2015 20:26:30 +0100 Subject: RFR [9] 8139297: java.lang.NoClassDefFoundError: Could not initialize class jdk.internal.jimage.ImageNativeSubstrate In-Reply-To: <56181319.5050209@oracle.com> References: <B2973B6F-65EC-4B10-8970-9068F94BD9D0@oracle.com> <56181319.5050209@oracle.com> Message-ID: <561814E6.70706@oracle.com> I looked more closely at this and I think it's best to handle NCDFE rather than the more general LinkageError. But I hope very temporary, we need to get this code fixed so do the right thing. -Alan From james.laskey at oracle.com Fri Oct 9 19:26:31 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 9 Oct 2015 16:26:31 -0300 Subject: RFR [9] 8139297: java.lang.NoClassDefFoundError: Could not initialize class jdk.internal.jimage.ImageNativeSubstrate In-Reply-To: <56181319.5050209@oracle.com> References: <B2973B6F-65EC-4B10-8970-9068F94BD9D0@oracle.com> <56181319.5050209@oracle.com> Message-ID: <6CA2A5A8-62FB-42EC-8E93-BB2A8358DF01@oracle.com> "it should never attempt to use the native implementation? This is confusing. It?s attempting to see if a native library is present otherwise use java. Is this the wrong approach? > On Oct 9, 2015, at 4:18 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote: > > On 09/10/2015 19:59, Chris Hegarty wrote: >> This is a little temporary solution to get the jrt-fs up and running again >> with JDK 8, until JDK-8137017 [1] can be resolved. >> >> It is fair game for an unchecked Exception or Error thrown during >> class initialization to result in a NCDFE. The code in BasicImageReader >> should catch java.lang.LinkageError, rather than UnsatisfiedLinkError >> ( LinkageError is the supertype of NCDFE and UnsatisfiedLinkError ), >> so that it falls over the the Java implementation when libjimage is not >> in the runtime image. >> >> diff --git a/src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java b/src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java >> --- a/src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java >> +++ b/src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java >> @@ -58,7 +58,7 @@ >> try { >> substrate = ImageNativeSubstrate.openImage(imagePath, byteOrder); >> - } catch (UnsatisfiedLinkError ex) { >> + } catch (LinkageError ex) { >> substrate = ImageJavaSubstrate.openImage(imagePath, byteOrder); >> } >> > I realize this is a temporary fix but what is the specific exception that is thrown here (just asking catching LinkageError could hide other issues here)? Do we have an issue submitted to fix the real issue here as it should never attempt to use the native implementation when on JDK 8 or when targeting a different run-time image. > > -Alan From chris.hegarty at oracle.com Fri Oct 9 19:33:52 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 9 Oct 2015 20:33:52 +0100 Subject: RFR [9] 8139297: java.lang.NoClassDefFoundError: Could not initialize class jdk.internal.jimage.ImageNativeSubstrate In-Reply-To: <561814E6.70706@oracle.com> References: <B2973B6F-65EC-4B10-8970-9068F94BD9D0@oracle.com> <56181319.5050209@oracle.com> <561814E6.70706@oracle.com> Message-ID: <FD83E9D4-7BA4-487C-BE3E-08ECD86005CE@oracle.com> On 9 Oct 2015, at 20:26, Alan Bateman <Alan.Bateman at oracle.com> wrote: > I looked more closely at this and I think it's best to handle NCDFE rather than the more general LinkageError. Ok, I make the follow change before pushing: diff --git a/src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java b/src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java --- a/src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java +++ b/src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java @@ -58,7 +58,7 @@ try { substrate = ImageNativeSubstrate.openImage(imagePath, byteOrder); - } catch (UnsatisfiedLinkError ex) { + } catch (UnsatisfiedLinkError | NoClassDefFoundError ex) { substrate = ImageJavaSubstrate.openImage(imagePath, byteOrder); } > But I hope very temporary, we need to get this code fixed so do the right thing. I added the follow to JDK-8137017, to ensure this is not forgotten: jrt-fs.jar should not depend, directly or indirectly, on JDK internal native libraries, e.g. libjimage. -Chris. From Alan.Bateman at oracle.com Fri Oct 9 19:37:19 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 9 Oct 2015 20:37:19 +0100 Subject: RFR [9] 8139297: java.lang.NoClassDefFoundError: Could not initialize class jdk.internal.jimage.ImageNativeSubstrate In-Reply-To: <6CA2A5A8-62FB-42EC-8E93-BB2A8358DF01@oracle.com> References: <B2973B6F-65EC-4B10-8970-9068F94BD9D0@oracle.com> <56181319.5050209@oracle.com> <6CA2A5A8-62FB-42EC-8E93-BB2A8358DF01@oracle.com> Message-ID: <5618176F.1060808@oracle.com> On 09/10/2015 20:26, Jim Laskey (Oracle) wrote: > "it should never attempt to use the native implementation? This is confusing. It?s attempting to see if a native library is present otherwise use java. Is this the wrong approach? > > jrtfs should use the native implementation when targeting the current runtime of course. However, when the target runtime is different then the safest is to use the pure-java implementation. I think this will become more obvious when jrtfs is updated to work on JDK 9 but targeting a different JDK 9 build. -Alan. From Alan.Bateman at oracle.com Fri Oct 9 19:37:49 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 9 Oct 2015 20:37:49 +0100 Subject: RFR [9] 8139297: java.lang.NoClassDefFoundError: Could not initialize class jdk.internal.jimage.ImageNativeSubstrate In-Reply-To: <FD83E9D4-7BA4-487C-BE3E-08ECD86005CE@oracle.com> References: <B2973B6F-65EC-4B10-8970-9068F94BD9D0@oracle.com> <56181319.5050209@oracle.com> <561814E6.70706@oracle.com> <FD83E9D4-7BA4-487C-BE3E-08ECD86005CE@oracle.com> Message-ID: <5618178D.6010707@oracle.com> On 09/10/2015 20:33, Chris Hegarty wrote: > On 9 Oct 2015, at 20:26, Alan Bateman <Alan.Bateman at oracle.com> wrote: > >> I looked more closely at this and I think it's best to handle NCDFE rather than the more general LinkageError. > Ok, I make the follow change before pushing: > > diff --git a/src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java b/src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java > --- a/src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java > +++ b/src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java > @@ -58,7 +58,7 @@ > > try { > substrate = ImageNativeSubstrate.openImage(imagePath, byteOrder); > - } catch (UnsatisfiedLinkError ex) { > + } catch (UnsatisfiedLinkError | NoClassDefFoundError ex) { > substrate = ImageJavaSubstrate.openImage(imagePath, byteOrder); > } This looks fine. > >> But I hope very temporary, we need to get this code fixed so do the right thing. > I added the follow to JDK-8137017, to ensure this is not forgotten: > > jrt-fs.jar should not depend, directly or indirectly, on JDK internal > native libraries, e.g. libjimage. > Thanks. From james.laskey at oracle.com Fri Oct 9 19:43:25 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 9 Oct 2015 16:43:25 -0300 Subject: RFR [9] 8139297: java.lang.NoClassDefFoundError: Could not initialize class jdk.internal.jimage.ImageNativeSubstrate In-Reply-To: <5618178D.6010707@oracle.com> References: <B2973B6F-65EC-4B10-8970-9068F94BD9D0@oracle.com> <56181319.5050209@oracle.com> <561814E6.70706@oracle.com> <FD83E9D4-7BA4-487C-BE3E-08ECD86005CE@oracle.com> <5618178D.6010707@oracle.com> Message-ID: <9956581B-2E85-44AE-A1E8-79AB456BBB42@oracle.com> I?m still missing something. How does the jrtfs code ?know? it?s in a jar vs part of the jdk9 runtime? > On Oct 9, 2015, at 4:37 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote: > > > On 09/10/2015 20:33, Chris Hegarty wrote: >> On 9 Oct 2015, at 20:26, Alan Bateman <Alan.Bateman at oracle.com> wrote: >> >>> I looked more closely at this and I think it's best to handle NCDFE rather than the more general LinkageError. >> Ok, I make the follow change before pushing: >> >> diff --git a/src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java b/src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java >> --- a/src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java >> +++ b/src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java >> @@ -58,7 +58,7 @@ >> try { >> substrate = ImageNativeSubstrate.openImage(imagePath, byteOrder); >> - } catch (UnsatisfiedLinkError ex) { >> + } catch (UnsatisfiedLinkError | NoClassDefFoundError ex) { >> substrate = ImageJavaSubstrate.openImage(imagePath, byteOrder); >> } > This looks fine. > > >> >>> But I hope very temporary, we need to get this code fixed so do the right thing. >> I added the follow to JDK-8137017, to ensure this is not forgotten: >> >> jrt-fs.jar should not depend, directly or indirectly, on JDK internal >> native libraries, e.g. libjimage. >> > Thanks. From daniel.fuchs at oracle.com Fri Oct 9 19:53:59 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 9 Oct 2015 21:53:59 +0200 Subject: RFR: JDK-8046565: Platform Logging API and Service In-Reply-To: <561660DA.7070900@oracle.com> References: <561660DA.7070900@oracle.com> Message-ID: <56181B57.2010801@oracle.com> Hi, I have updated the materials for the first prototype of JEP 264 - Platform Logging API and Service. I have done some minor editorial changes in the API doc ( null -> {@code null} ) fixed a few minor issues, and added some new tests. Sandbox has been updated. JEP: http://openjdk.java.net/jeps/264 https://bugs.openjdk.java.net/browse/JDK-8046565 specdiff: http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/specdiff-api/overview-summary.html webrev: http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/webrev.01/ A prototype implementation is available in the sandbox, branch named JDK-8046565-branch (Instructions on how to clone a sandbox branch can be found here: http://cr.openjdk.java.net/~chegar/docs/sandbox.html ) best regards, -- daniel From Alan.Bateman at oracle.com Fri Oct 9 19:56:10 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 9 Oct 2015 20:56:10 +0100 Subject: RFR [9] 8139297: java.lang.NoClassDefFoundError: Could not initialize class jdk.internal.jimage.ImageNativeSubstrate In-Reply-To: <9956581B-2E85-44AE-A1E8-79AB456BBB42@oracle.com> References: <B2973B6F-65EC-4B10-8970-9068F94BD9D0@oracle.com> <56181319.5050209@oracle.com> <561814E6.70706@oracle.com> <FD83E9D4-7BA4-487C-BE3E-08ECD86005CE@oracle.com> <5618178D.6010707@oracle.com> <9956581B-2E85-44AE-A1E8-79AB456BBB42@oracle.com> Message-ID: <56181BDA.4040606@oracle.com> On 09/10/2015 20:43, Jim Laskey (Oracle) wrote: > I?m still missing something. How does the jrtfs code ?know? it?s in a jar vs part of the jdk9 runtime? > > In jrtfs then SystemImages has code to look at its code source. -Alan. From aleksej.efimov at oracle.com Fri Oct 9 21:09:21 2015 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Sat, 10 Oct 2015 00:09:21 +0300 Subject: RFR: 8073519: schemagen does not report errors while generating xsd files Message-ID: <56182D01.7000203@oracle.com> Hello, Please, review the fix for schemagen regression bug [1] in JDK9: The JDK9 (and JDK8 too) version of schemagen doesn't report errors during the compilation of the input java file. The issue was introduced by standalone JAXB project changes and then it was synced to JDK source. The SchemaGenerator class was changed to use javax.tools.JavaCompiler (instead of com.sun.tools.apt.process), but the diagnostic information generated by javac was silently ignored. The proposed patch solves the reported problem: http://cr.openjdk.java.net/~aefimov/8073519/9/00/ The generated messages with fix applied is the same as in JDK7 - same as was before mentioned changes. The proposed fix is already integrated to standalone JAXB project and identical to the proposed source changes. Testing shows no failures with schemagen tool. With Best Regards, Aleksej [1] https://bugs.openjdk.java.net/browse/JDK-8073519 From mandy.chung at oracle.com Fri Oct 9 21:16:30 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 09 Oct 2015 14:16:30 -0700 Subject: RFR [9] 8139297: java.lang.NoClassDefFoundError: Could not initialize class jdk.internal.jimage.ImageNativeSubstrate In-Reply-To: <5618176F.1060808@oracle.com> References: <B2973B6F-65EC-4B10-8970-9068F94BD9D0@oracle.com> <56181319.5050209@oracle.com> <6CA2A5A8-62FB-42EC-8E93-BB2A8358DF01@oracle.com> <5618176F.1060808@oracle.com> Message-ID: <56182EAE.5090407@oracle.com> On 10/09/2015 12:37 PM, Alan Bateman wrote: > > On 09/10/2015 20:26, Jim Laskey (Oracle) wrote: >> "it should never attempt to use the native implementation? This is >> confusing. It?s attempting to see if a native library is present >> otherwise use java. Is this the wrong approach? >> >> > jrtfs should use the native implementation when targeting the current > runtime of course. > > However, when the target runtime is different then the safest is to > use the pure-java implementation. I think this will become more > obvious when jrtfs is updated to work on JDK 9 but targeting a > different JDK 9 build. I also think it's a better approach for jrtfs to use pure-java implementation when targetting a different runtime. Perhaps you can add a method SystemImages::isCurrentRuntime (something like that) that BasicImageReader can use to determine if it should use ImageNativeSubstrate or ImageJavaSubstrate. Mandy From john.r.rose at oracle.com Fri Oct 9 21:32:01 2015 From: john.r.rose at oracle.com (John Rose) Date: Fri, 9 Oct 2015 14:32:01 -0700 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <A88BF292-9AE7-4D01-8584-D3A77E031971@azul.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561245E0.8030708@redhat.com> <38110705-2789-4050-913C-0568DD8B61E9@oracle.com> <DDC775F6-63F7-4028-87B8-351594E5B9BE@azul.com> <B93EDAA4-C5A3-434F-BBC7-6788BFDBC52B@oracle.com> <A88BF292-9AE7-4D01-8584-D3A77E031971@azul.com> Message-ID: <CFF936DD-EE02-4BF4-B7ED-9785D7D0D9D2@oracle.com> On Oct 8, 2015, at 11:56 PM, Gil Tene <gil at azul.com> wrote: > >> >> On Oct 8, 2015, at 6:18 PM, John Rose <john.r.rose at oracle.com> wrote: >> >> On Oct 8, 2015, at 12:39 AM, Gil Tene <gil at azul.com> wrote: > ? If/when MONITOR/MWAIT becomes available in user mode, it will join ARM v8 and SPARC M7 in a common useful paradigm. > >> Also, from a cross-platform POV, a boolean would provide an easy to use "hook" for profiling how often the polling is failing. Failure frequency is an important input to the tuning of spin loops, isn't it? Why not feed that info through to the JVM? > > I don't follow. Perhaps I'm missing something. Spin loops are "strange" in that they tend to not care about how "fast" they spin, but do care about their reaction time to a change in the thing(s) they are spinning on. I don't think profiling will help here? There might be a question of how to scale (or otherwise arrange) the delay until next poll. But I see the x86 PAUSE instruction has no delay parameter. (It's my first time reading the SDM entry. Now I see why it was dubbed spinLoopHint.) > E.g. in the example tests for this JEP on Ivy Bridge Xeons, adding an intrinsified spinLoopHint() to the a simple spin volatile value loop appears to reduce the "spin throughput" by a significant ratio (3x-5x for L1-sharing threads), but also reduces the reaction time by 35-50%. > >> ... >>> and if/when it does, I'm not sure the semantics of passing the boolean through are enough to cover the actual way to use such hardware when it becomes available. >> >> The alternative is to have the JIT pattern-match for loop control around the call to Thread.yield. That is obviously less robust than having the user thread the poll condition bit through the poll primitive. > > I dont' think that's the alternative. The alternative(s) I suggest require no analysis by the JIT: Got it. No analysis, no profiling needed. > The main means of spin loop hinting I am suggesting is a simple no args hint. [Folks seem to be converging on using Thread as the home for this stuff, so I'll use that]: > ... > (for Java 9, a varhandle variant of the above reflection based model is probably more appropriate. I spelled this with the reflection form for readability by pre-varhandles-speakers). OK, I agree it would be better to use reified (encapsulated) memory locations and explicit wait-to-poll operations on them. > Neither of these forms require any specific JIT matching or exploration. We know the first form is fairly robust on architectures that support stuff like PAUSE. The second form will probably be robust both architectures that support MWAIT or WFE, and on those that support PAUSE (those just won't watch anything). > > On how this differs from a single boolean parameter: My notion (in the example above) of a single poll variable would be one that specifically designates the poll variable as a field (or maybe array index as an option), rather than provide a boolean parameter that is potentially evaluated based on data read from more than one memory location. Clearly explained. > The issue is that while it's an easy fit if the boolean is computed based on evaluating a single address, it becomes fragile if multiple addresses are involved and the hardware can only watch one (which is the current trend for ARM v8, SPARC M7, and a potential MONITOR/WAIT x86). It would be "hard" for a JIT to figure out which of the addresses read to compute the bollean should be watched in the spin. Yes, it's hard to break down a multi-input boolean into its component effects. Not impossible, but hard. Given that, the extra complexity of "exploring" a loop looking for exit gating is probably insignificant. I was thinking the javadoc for a boolean-accepting spin loop hint would ask programmers to pick one input, and tell them that the benefits go down if they use complex predicates. But the VH-based API is much crisper. > And getting it wrong can have potentially surprising consequences (not just lack of benefit, but terribly slow execution due to waiting for something that is not going to be externally modified and timing out each time before spinning). > ... > None of these are "right". And there is nothing in the semantics that suggests which one to expect. Granted. > You could fall back and say that you would only get the benefit if there is exactly one address used in deriving the boolean, but this would probably make it hard to code to and maintain. A form that forces you to specific the polling parameter would be less generic in expression, but will be less fragile to program to as well, IMO. Granted. > I guess that's where we differ: I don't see a benefit in profiling the spin loop, so we disagree on (a). And hence (b) is not relevant? > > Maybe I'm mis-reading what you mean by "profiling" and "optimizing" above? You are probably reading me correctly. When tuning such things in software it is useful to know (or guess correctly) what is the likely time until the polling condition changes. Online profiling can derive some of that information, if history predicts the future. The boolean parameter provides a direct and explicit source to collect that information. > >> The idea would be that programmers would take a little extra thought when using yield(Z)Z, and get paid immediately from good profiling. They would get paid again later if and when platforms analyze data dependencies on the Z. >> >> If there's no initial payoff, then, yes, it is hard asking programmers to expend extra thought that only benefits on some platforrms. > > Whatever the choices end up being, we could provide multiple signatures or APIs. E.g. I think that the no-args spinLoopHint() is the de-facto spinning model for x86 and Power (and have been for over a decade for everything outside of Java). So it's a safe bet and a natural form. The spin-execute-something-while-watching-a-single-address model is *probably* a good fit for some relatively young but very useful hardware capabilities, and can probably be captured in a long-lasting API as well. > > More complicated boolean-derived-from-pretty-much-anything or multi-address watching schemes are IMO too early to evaluate. E.g. they could potentially leverage some just-around-the-corner (or recently arrived) features like TSX and NCAS schemes, but since there is relatively little experience with using such things for spinning (outside of Java), it is probably pre-mature to solidify a Java API for them. > > BTW, even with user-mode MWAIT and cousins, and with the watch-a-single-address API forms, we may be looking at two separate motivations, and may want to consider a hint of which one is intended. E.g. one of spinLoopHint()'s main drivers is latency improvement, and the other is power reduction (with potential speed benefits or just power savings benefits). It appears that on x86 a PAUSE provides both, so there is no choice needed there. But MWAIT may be much more of a power-centric approach that sacrifices latency, and that may be OK for some and un-OK for others. We may want to have API variants that allow a hint about whether power-reduction or latency-reduction is the preferred driver. Bottom line: I'm content to wait for a VH-based poll operator. Thanks for the clear explanations. ? John From stuart.marks at oracle.com Fri Oct 9 21:44:02 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 9 Oct 2015 14:44:02 -0700 Subject: RFR [9] 8139307: Remove sun.misc.ConditionLock and Lock In-Reply-To: <A22DFBF0-19EB-4295-B8A5-D6B1456C8E98@oracle.com> References: <9069DB82-1CFE-4018-9941-9DFCAF1F0EB7@oracle.com> <56180C9D.9000200@oracle.com> <A22DFBF0-19EB-4295-B8A5-D6B1456C8E98@oracle.com> Message-ID: <56183522.3020606@oracle.com> On 10/9/15 11:54 AM, Chris Hegarty wrote: > On 9 Oct 2015, at 19:51, Stuart Marks <stuart.marks at oracle.com> wrote: >> Dr Deprecator approves! > > Hmmm.. does Dr Deprecator have an OpenJDK userId? If not, we should > have one assigned! ;-) Yes, good idea. At some point, then, Dr Deprecator will become a Decommitter. <rimshot/> From stuart.marks at oracle.com Fri Oct 9 21:49:23 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 9 Oct 2015 14:49:23 -0700 Subject: RFR: 5108778 Too many instances of java.lang.Boolean created in Java application(core-libs) In-Reply-To: <5618141C.6000504@gmx.de> References: <56157990.7020506@gmx.de> <5616BCE6.9000108@oracle.com> <5617A204.3080903@oracle.com> <56180E40.7010302@oracle.com> <5618141C.6000504@gmx.de> Message-ID: <56183663.8030409@oracle.com> On 10/9/15 12:23 PM, Sebastian Sickelmann wrote: >> I'll file a bug on the JLS for this. > What is the Bug-Number. Maybe i can watch and comment on this. https://bugs.openjdk.java.net/browse/JDK-8139324 s'marks From stuart.marks at oracle.com Fri Oct 9 22:01:20 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 9 Oct 2015 15:01:20 -0700 Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <CABLGb9wJGoE=ujEs_XporTVpb37ikpSAUyhiJF4w=-UYzbXtgQ@mail.gmail.com> References: <5616FEB5.5090104@oracle.com> <CABLGb9wJGoE=ujEs_XporTVpb37ikpSAUyhiJF4w=-UYzbXtgQ@mail.gmail.com> Message-ID: <56183930.6@oracle.com> On 10/8/15 7:39 PM, Paul Benedict wrote: > I don't think the statements "Creates an unmodifiable set containing X elements" > is always true. Since sets cannot have duplicates, it's possible passing in X > elements gives you less than that based on equality. I think the Set docs should > say "...X possible elements if unique". Wordsmith something better if you can, > of course. Fair point, I probably had the idea of throwing an exception for duplicate elements when I wrote the "Creates an unmodifiable set containing X elements" lines. If the policy were to silently ignore duplicates, applying the usual dose of spec weasel wording might result in something like "Creates an unmodifiable set from the X elements passed as arguments." Then again, one of the advantages of rejecting duplicates is that the resulting collection's size equals the number of arguments passed. This also applies to the varargs cases; the resulting size equals the varargs array length. This not only provides clear semantics to the programmer, but it also lets the implementation preallocate internal arrays knowing that they'll have exactly the right size. s'marks > > > Cheers, > Paul > > On Thu, Oct 8, 2015 at 6:39 PM, Stuart Marks <stuart.marks at oracle.com > <mailto:stuart.marks at oracle.com>> wrote: > > Hi all, > > Please review and comment on this draft API for JEP 269, Convenience > Collection Factories. For this review I'd like to focus on the API, and set > aside implementation issues and discussion for later. > > > JEP: > > http://openjdk.java.net/jeps/269 > > javadoc: > > http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151008.mod/ > > specdiff: > > http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151008.specdiff/overview-summary.html > > > Most of the API is pretty straightforward, with fixed-arg and varargs "of()" > factories for List, Set, ArrayList, and HashSet; and with fixed-arg "of()" > factories and varargs "ofEntries()" factories for Map and HashMap. > > There are a few issues on which I'd like to solicit discussion. > > 1. Number of fixed arg overloads. > > I've somewhat arbitrarily provided up to 5 fixed-arg overloads for the lists > and sets, and up to 8 pairs for the fixed-arg map factories. The rationale > for 8 pairs is that there are 8 primitives, and various language processing > tools often have maps for the primitive types. (But such tools also often > need to handle the Void type, which exceeds the limit of 8. So this might > need to change if we want to follow this rationale.) > > I also note that Guava's immutable factories provide 11 fixed-arg overloads > for list, 5 for set, and 5 pairs for map. I'd be curious as to the rationale > for this, and whether it also would apply to the JDK. > > 2. Other concrete collection factories. > > I've chosen to provide factories for the concrete collections ArrayList, > HashSet, and HashMap, since those seem to be the most commonly used. Is > there a need to provide factories for other concrete collections, such as > LinkedHashMap? > > 3. Duplicate handling. > > My current thinking is for the Set and Map factories to throw > IllegalArgumentException if a duplicate element or key is detected. The > current draft specification is silent on this point. It needs to be > specified, one way or another. > > The rationale for throwing an exception is that if these factories are used > in a "literal like" fashion, then having a duplicate is almost certainly a > programming error. Consider this example: > > Map<String,TypeUse> m = Map.ofEntries( > entry("CDATA", CBuiltinLeafInfo.NORMALIZED_STRING), > entry("ENTITY", CBuiltinLeafInfo.TOKEN), > entry("ENTITIES", CBuiltinLeafInfo.STRING.makeCollection()), > entry("ENUMERATION", CBuiltinLeafInfo.STRING.makeCollection()), > entry("NMTOKEN", CBuiltinLeafInfo.TOKEN), > entry("NMTOKENS", CBuiltinLeafInfo.STRING.makeCollection()), > entry("ID", CBuiltinLeafInfo.ID), > entry("IDREF", CBuiltinLeafInfo.IDREF), > entry("IDREFS", > TypeUseFactory.makeCollection(CBuiltinLeafInfo.IDREF)); > entry("ENUMERATION", CBuiltinLeafInfo.TOKEN)); > > (derived from [1]) > > If duplicates were silently ignored, this might result in hard-to-spot errors. > > There's also the matter of which value ends up being used in the case of > duplicate map keys, and whether this should be specified. A fairly obvious > policy would be "last one wins" but I'm reluctant to specify that, as it > starts to place unnecessary constraints on implementations. However, the > alternative of leaving it unspecified is also unpalatable. > > I'm aware that very few programming systems with similar constructs will > signal an error on duplicate elements. Python, Ruby, Groovy, Scala, and Perl > all seem to allow duplicates in maps or equivalent, apparently with a > last-wins policy. (Though sometimes it's hard to tell if the policy is > specified.) > > The only system I've been able to find that explicitly rejects duplicates is > Clojure, and this policy isn't without controversy. [2] The main rationale > is to prevent programming errors. > > There is a python bug [3] where it was proposed that duplicates in a dict > should raise an error or warning, also in order to catch programming errors. > The request was rejected, not necessarily because it was a bad idea, but > primarily because it would be a backward incompatible change. > > The easiest thing to do would simply to require last-wins, since "everybody > else is doing it" ... but that doesn't mean it's right. Since we're > introducing a new API here, there is no compatibility issue. Throwing an > exception for duplicates seems like a good way to prevent a certain class of > programming errors. > > What do people think? > > s'marks > > [1] > http://hg.openjdk.java.net/jdk8/jdk8/jaxws/file/d03dd22762db/src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/TDTDReader.java#l420 > > [2] > http://dev.clojure.org/display/design/Allow+duplicate+map+keys+and+set+elements > > [3] https://bugs.python.org/issue16385 > > From stuart.marks at oracle.com Fri Oct 9 23:11:09 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 9 Oct 2015 16:11:09 -0700 Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <CACzrW9A3MZja2wxsHZ7E0vSupkMJXMTQDqMQRjV548ArAF57Hw@mail.gmail.com> References: <5616FEB5.5090104@oracle.com> <CACzrW9A3MZja2wxsHZ7E0vSupkMJXMTQDqMQRjV548ArAF57Hw@mail.gmail.com> Message-ID: <5618498D.2040807@oracle.com> On 10/9/15 6:11 AM, Stephen Colebourne wrote: > On 9 October 2015 at 00:39, Stuart Marks <stuart.marks at oracle.com> wrote: >> 1. Number of fixed arg overloads. > > Guava follows this pattern: > > of(T) > of(T, T) > of(T, T, T) > of(T, T, T, T... elements) > > whereas the proposal has > > of(T) > of(T, T) > of(T, T, T) > of(T... elements) > > I'd be interested to know why Guava did it that way and what the trade offs are. I can't answer for the Guava guys, of course, but I can supply some additional background about why we chose this approach for our proposal. Note carefully that the Guava pattern is: of() // zero args, for completeness of(T) of(T, T) of(T, T, T) of(T, T, T, T, T...) // an extra fixed arg THEN the varargs param Following this pattern means that overload resolution can be performed entirely based on the arity of the call site. With the JEP 269 proposal, there is a potential overloading ambiguity with these two methods: of(T) of(T...) The reason we chose to provide a one-arg of(T...) method is that it supports a secondary use case, which is how to create one of these collections if the values aren't known until runtime. The of(T...) method allows you to pass an arbitrary number of actual arguments as well as an array of arbitrary size. It's really hard to do this with the Guava pattern of fixed and varargs methods. Now, Guava handles this use case by providing a family of copying factories that can accept an array, a Collection, an Iterator, or an Iterable. These are all useful, but for JEP 269, we wanted to focus on the "collection literal like" APIs and not expand the proposal to include a bunch of additional factory methods. Since we need to have a varargs method anyway, it seemed reasonable to arrange it so that it could easily accept an array as well. Now, the usual problem with this scheme is that calling of(null) is ambiguous. Indeed, it actually is ambiguous in the JEP 269 proposal, and call sites will generate varargs warnings. It turns out that we've finessed this issue since we disallow nulls. Another issue is that a call site that passes a T[] argument matches the of(T...) overload and not of(T), where in the latter case T is an array type. This is a problem if you want to create a list or set containing a single array. If you need this, you can do List<String[]> list = List.<String[]>of(stringArray); This is messy, but it really seems like an edge case, and there's a simple workaround. I've described this in an @apiNote on List.of(T...). (I need to add something similar for Set.of(T...).) >> 2. Other concrete collection factories. >> >> I've chosen to provide factories for the concrete collections ArrayList, >> HashSet, and HashMap, since those seem to be the most commonly used. Is >> there a need to provide factories for other concrete collections, such as >> LinkedHashMap? > > LinkedHashMap definitely > LinkedList definitely not (as its very slow and use should not be encouraged). > TreeSet/TreeMap, maybe, they'd need an extra parameter though. LinkedHashMap: ok. I assume this should create an insertion-ordered map, with the initial entries being inserted in left-to-right order. Does anybody care about LinkedHashSet? >> 3. Duplicate handling. >> >> My current thinking is for the Set and Map factories to throw >> IllegalArgumentException if a duplicate element or key is detected. > > Definitely. Well ok then! :-) > Given that ofEntries() takes a Map.Entry as input, why does > Map.KeyValueHolder need to be public? This would require > Map.entry(K,V) return Map.Entry, not Map.KeyValueHolder. Good question, it might or might not need to be this way. By having Map.entry() return KeyValueHolder instead of Map.Entry, call sites are compiled with KeyValueHolder as the method return type. If, in the future, KeyValueHolder were to become a value type, and in the future, if another overload Map.ofEntries(KeyValueHolder... entries) were added, then recompiling will avoid upcasting to Map.Entry, which might prevent boxing of the value type. I think the way this needs to be set up and how it will interact with some future evolution toward value types is mainly in Brian Goetz' head right now, so I'll need to go over this again to make sure it's set up correctly. s'marks My thinking was, suppose KeyValueHolder eventually turns into a value type From forax at univ-mlv.fr Sat Oct 10 08:52:18 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 10 Oct 2015 10:52:18 +0200 (CEST) Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <5618498D.2040807@oracle.com> References: <5616FEB5.5090104@oracle.com> <CACzrW9A3MZja2wxsHZ7E0vSupkMJXMTQDqMQRjV548ArAF57Hw@mail.gmail.com> <5618498D.2040807@oracle.com> Message-ID: <261170982.3352772.1444467138843.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Stuart Marks" <stuart.marks at oracle.com> > ?: "Stephen Colebourne" <scolebourne at joda.org> > Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net> > Envoy?: Samedi 10 Octobre 2015 01:11:09 > Objet: Re: RFC: draft API for JEP 269 Convenience Collection Factories > > > > On 10/9/15 6:11 AM, Stephen Colebourne wrote: > > On 9 October 2015 at 00:39, Stuart Marks <stuart.marks at oracle.com> wrote: > >> 1. Number of fixed arg overloads. > > > > Guava follows this pattern: > > > > of(T) > > of(T, T) > > of(T, T, T) > > of(T, T, T, T... elements) > > > > whereas the proposal has > > > > of(T) > > of(T, T) > > of(T, T, T) > > of(T... elements) > > > > I'd be interested to know why Guava did it that way and what the trade offs > > are. > > I can't answer for the Guava guys, of course, but I can supply some > additional > background about why we chose this approach for our proposal. I remember discussing this kind of things with Kevin Bourrillion something like 5 years ago. There are several issues with: of(T) of(T...) if called with null, the overload selected will be of(T...) and the compiler will emit a warning, because it's not clear if of(null) should be called like this of((T[])null) or of(new T[]{null}) (for backward compatibility the former will be used by default). but even without null, a code like this is ambiguous from the user perspective, String[] array = ... of(array) should it returns a List<String[]> with the array as sole element or a List<String> with all elements contained in the array. R?mi From forax at univ-mlv.fr Sat Oct 10 13:55:58 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 10 Oct 2015 15:55:58 +0200 (CEST) Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <CACzrW9A3MZja2wxsHZ7E0vSupkMJXMTQDqMQRjV548ArAF57Hw@mail.gmail.com> References: <5616FEB5.5090104@oracle.com> <CACzrW9A3MZja2wxsHZ7E0vSupkMJXMTQDqMQRjV548ArAF57Hw@mail.gmail.com> Message-ID: <87025428.3530190.1444485358747.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Stephen Colebourne" <scolebourne at joda.org> > ?: "core-libs-dev" <core-libs-dev at openjdk.java.net> > Envoy?: Vendredi 9 Octobre 2015 15:11:47 > Objet: Re: RFC: draft API for JEP 269 Convenience Collection Factories > > On 9 October 2015 at 00:39, Stuart Marks <stuart.marks at oracle.com> wrote: [...] > > 2. Other concrete collection factories. > > > > I've chosen to provide factories for the concrete collections ArrayList, > > HashSet, and HashMap, since those seem to be the most commonly used. Is > > there a need to provide factories for other concrete collections, such as > > LinkedHashMap? > > LinkedHashMap definitely > LinkedList definitely not (as its very slow and use should not be > encouraged). > TreeSet/TreeMap, maybe, they'd need an extra parameter though. There is an issue with LinkedHashMap (resp LinkedHashSet), it inherits from HashMap /facepalm/, and static methods are accessible through class inheritance /facepalm/. So if LinkedHashMap doesn't declare some methods of(), LinkedHashMap.of("foo") will return a HashMap :( cheers, R?mi From lowasser at google.com Sat Oct 10 16:10:41 2015 From: lowasser at google.com (Louis Wasserman) Date: Sat, 10 Oct 2015 16:10:41 +0000 Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <87025428.3530190.1444485358747.JavaMail.zimbra@u-pem.fr> References: <5616FEB5.5090104@oracle.com> <CACzrW9A3MZja2wxsHZ7E0vSupkMJXMTQDqMQRjV548ArAF57Hw@mail.gmail.com> <87025428.3530190.1444485358747.JavaMail.zimbra@u-pem.fr> Message-ID: <CAGB9EW82wrS6Zsg+iaWHgzLxEKL6r5P9aoryS4450h0TfYjBQw@mail.gmail.com> I'm unclear on whether the question is where Guava stopped, or why we included the fixed-args versions as well as the varargs versions? Part of the answer, of course, is that those factories predate @SafeVarargs, and frankly even now Guava doesn't really depend on Java 7. If you're asking about why we stopped where we did, we collected actually rather a lot of data on the size of static collection constants using immutable collections, both with builder syntax and without. https://github.com/google/guava/issues/2071#issuecomment-126468933 has the statistics (in terms of ratios, not absolute numbers), but we found that there was right about an exponential trend: static collection constants of size n+1 were ~half as common as collection constants of size n. On Sat, Oct 10, 2015 at 6:56 AM Remi Forax <forax at univ-mlv.fr> wrote: > ----- Mail original ----- > > De: "Stephen Colebourne" <scolebourne at joda.org> > > ?: "core-libs-dev" <core-libs-dev at openjdk.java.net> > > Envoy?: Vendredi 9 Octobre 2015 15:11:47 > > Objet: Re: RFC: draft API for JEP 269 Convenience Collection Factories > > > > On 9 October 2015 at 00:39, Stuart Marks <stuart.marks at oracle.com> > wrote: > > [...] > > > > 2. Other concrete collection factories. > > > > > > I've chosen to provide factories for the concrete collections > ArrayList, > > > HashSet, and HashMap, since those seem to be the most commonly used. Is > > > there a need to provide factories for other concrete collections, such > as > > > LinkedHashMap? > > > > LinkedHashMap definitely > > LinkedList definitely not (as its very slow and use should not be > > encouraged). > > TreeSet/TreeMap, maybe, they'd need an extra parameter though. > > There is an issue with LinkedHashMap (resp LinkedHashSet), > it inherits from HashMap /facepalm/, and static methods are accessible > through class inheritance /facepalm/. > So if LinkedHashMap doesn't declare some methods of(), > LinkedHashMap.of("foo") > will return a HashMap :( > > cheers, > R?mi > From paul.sandoz at oracle.com Mon Oct 12 07:31:04 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 12 Oct 2015 09:31:04 +0200 Subject: Array equality, comparison and mismatch In-Reply-To: <79451C0B-DA1A-4FD6-B8F3-97B7BE841006@oracle.com> References: <79451C0B-DA1A-4FD6-B8F3-97B7BE841006@oracle.com> Message-ID: <A508DD9E-FED5-49ED-B901-2481BF1E7A2A@oracle.com> > On 22 Sep 2015, at 18:30, Paul Sandoz <Paul.Sandoz at oracle.com> wrote: > > Hi, > > Please review the following which adds methods to Arrays for performing equality, comparison and mismatch: > > https://bugs.openjdk.java.net/browse/JDK-8033148 > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/webrev/ > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/specdiff/overview-summary.html > Updated the above with JavaDoc for all methods. Paul. From andrej.golovnin at gmail.com Mon Oct 12 07:47:12 2015 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Mon, 12 Oct 2015 09:47:12 +0200 Subject: Array equality, comparison and mismatch In-Reply-To: <A508DD9E-FED5-49ED-B901-2481BF1E7A2A@oracle.com> References: <79451C0B-DA1A-4FD6-B8F3-97B7BE841006@oracle.com> <A508DD9E-FED5-49ED-B901-2481BF1E7A2A@oracle.com> Message-ID: <CAM6ZMz92TtgKgf00YQdQ8vtAWKKZeOdRz-sO4McJKV_WGeKVOw@mail.gmail.com> Hi Paul, wouldn't it be better to use Objects#equals(Object, Object) in the line 3293 in the Arrays class instead of the ternary operator (the same applies to the line 3238)? Best regards, Andrej Golovnin On Mon, Oct 12, 2015 at 9:31 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote: > >> On 22 Sep 2015, at 18:30, Paul Sandoz <Paul.Sandoz at oracle.com> wrote: >> >> Hi, >> >> Please review the following which adds methods to Arrays for performing equality, comparison and mismatch: >> >> https://bugs.openjdk.java.net/browse/JDK-8033148 >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/webrev/ >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/specdiff/overview-summary.html >> > > Updated the above with JavaDoc for all methods. > > Paul. From paul.sandoz at oracle.com Mon Oct 12 07:48:13 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 12 Oct 2015 09:48:13 +0200 Subject: Optional.or name <was> Re: RFR 8080418 Add Optional.or() In-Reply-To: <2C9C9A31-7AA0-47CC-B17A-35A7188F4F8B@oracle.com> References: <2C9C9A31-7AA0-47CC-B17A-35A7188F4F8B@oracle.com> Message-ID: <C8CBC8A5-BF87-4560-880A-29A13E376DB6@oracle.com> > On 25 Sep 2015, at 12:58, Paul Sandoz <Paul.Sandoz at oracle.com> wrote: > > Hi, > > Please review this change to add a method Optional.or that allows one to better compose optionals: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8080418-optional-or/webrev/ > > I also took the opportunity to clear up the JavaDoc, it was a little inconsistent and i personally found it harder to read in source code. > Now that the overall documentation changes and functional behaviour of Optional.or has been agreed i would like to see if we can find a better name, suggestions welcome, so lets get our paint brushes out :-) I suggest we avoid commenting on comments, otherwise this thread could get out of control. ?Optional.or? is the best name so far i have come up with. The ?orElse? prefix is reversed for terminal methods and i don?t want to overload that. -- Alternative suggestions: - ?Optional.otherwise? A bit of a mouthful, but reasonably accurate - ?Optional.mapElse" The name is not entirely accurate since it accepts a Suppler<T> not a T, a more accurate name would be the following alternative. - ?Optional.flatMapElse" This name is likely to confuse. Paul. From paul.sandoz at oracle.com Mon Oct 12 08:14:55 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 12 Oct 2015 10:14:55 +0200 Subject: Array equality, comparison and mismatch In-Reply-To: <CAM6ZMz92TtgKgf00YQdQ8vtAWKKZeOdRz-sO4McJKV_WGeKVOw@mail.gmail.com> References: <79451C0B-DA1A-4FD6-B8F3-97B7BE841006@oracle.com> <A508DD9E-FED5-49ED-B901-2481BF1E7A2A@oracle.com> <CAM6ZMz92TtgKgf00YQdQ8vtAWKKZeOdRz-sO4McJKV_WGeKVOw@mail.gmail.com> Message-ID: <26525EEF-7881-4E48-9536-EFACF743B6D9@oracle.com> > On 12 Oct 2015, at 09:47, Andrej Golovnin <andrej.golovnin at gmail.com> wrote: > > Hi Paul, > > wouldn't it be better to use Objects#equals(Object, Object) in the > line 3293 in the Arrays class instead of the ternary operator (the > same applies to the line 3238)? > Thanks updated both the Arrays.equals and Arrays.mismatch methods (and also fixed a bug in the JavaDoc for the common prefix definition of those methods). Paul. From spliterator at gmail.com Mon Oct 12 08:17:12 2015 From: spliterator at gmail.com (Stefan Zobel) Date: Mon, 12 Oct 2015 10:17:12 +0200 Subject: Optional.or name <was> Re: RFR 8080418 Add Optional.or() In-Reply-To: <C8CBC8A5-BF87-4560-880A-29A13E376DB6@oracle.com> References: <2C9C9A31-7AA0-47CC-B17A-35A7188F4F8B@oracle.com> <C8CBC8A5-BF87-4560-880A-29A13E376DB6@oracle.com> Message-ID: <CAPkkuSeL63HCOjuL8j=LmLqvTkGyOWQcH-Hb-z03GckE9JftkQ@mail.gmail.com> > > ?Optional.or? is the best name so far i have come up with. The ?orElse? prefix is reversed for terminal methods and i don?t want to overload that. > > -- > > Alternative suggestions: > > - ?Optional.otherwise? > A bit of a mouthful, but reasonably accurate > > - ?Optional.mapElse" > The name is not entirely accurate since it accepts a Suppler<T> not a T, a more accurate name would be the following alternative. > > - ?Optional.flatMapElse" > This name is likely to confuse. > > Paul. > - "Optional.orIfAbsent" perhaps? Actually, I don't regard "Optional.or" as a poor name. Stefan. From amy.lu at oracle.com Mon Oct 12 08:27:21 2015 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 12 Oct 2015 16:27:21 +0800 Subject: JDK 9 RFR of JDK-8139407: Mark java/rmi/registry/readTest/readTest.sh as intermittently failing Message-ID: <561B6EE9.1050302@oracle.com> Test java/rmi/registry/readTest/readTest.sh is known to fail intermittently, this patch is to mark the test accordingly with keyword 'intermittent'. bug: https://bugs.openjdk.java.net/browse/JDK-8139407 webrev: http://cr.openjdk.java.net/~amlu/8139407/webrev.00/ Thanks, Amy --- old/test/java/rmi/registry/readTest/readTest.sh 2015-10-12 16:10:48.000000000 +0800 +++ new/test/java/rmi/registry/readTest/readTest.sh 2015-10-12 16:10:48.000000000 +0800 @@ -27,6 +27,7 @@ # @build TestLibrary # @summary remove java.rmi.server.codebase property parsing from registyimpl # @run shell readTest.sh +# @key intermittent OS=`uname -s` VER=`uname -r` From chris.hegarty at oracle.com Mon Oct 12 08:55:32 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 12 Oct 2015 09:55:32 +0100 Subject: JDK 9 RFR of JDK-8139407: Mark java/rmi/registry/readTest/readTest.sh as intermittently failing In-Reply-To: <561B6EE9.1050302@oracle.com> References: <561B6EE9.1050302@oracle.com> Message-ID: <561B7584.5020709@oracle.com> Looks ok to me Amy. -Chris. On 12/10/15 09:27, Amy Lu wrote: > Test java/rmi/registry/readTest/readTest.sh is known to fail > intermittently, this patch is to mark the test accordingly with keyword > 'intermittent'. > > bug: https://bugs.openjdk.java.net/browse/JDK-8139407 > webrev: http://cr.openjdk.java.net/~amlu/8139407/webrev.00/ > > Thanks, > Amy > > --- old/test/java/rmi/registry/readTest/readTest.sh 2015-10-12 > 16:10:48.000000000 +0800 > +++ new/test/java/rmi/registry/readTest/readTest.sh 2015-10-12 > 16:10:48.000000000 +0800 > @@ -27,6 +27,7 @@ > # @build TestLibrary > # @summary remove java.rmi.server.codebase property parsing from > registyimpl > # @run shell readTest.sh > +# @key intermittent > > OS=`uname -s` > VER=`uname -r` From amaembo at gmail.com Mon Oct 12 09:34:01 2015 From: amaembo at gmail.com (Tagir F. Valeev) Date: Mon, 12 Oct 2015 15:34:01 +0600 Subject: Optional.or name <was> Re: RFR 8080418 Add Optional.or() In-Reply-To: <C8CBC8A5-BF87-4560-880A-29A13E376DB6@oracle.com> References: <2C9C9A31-7AA0-47CC-B17A-35A7188F4F8B@oracle.com> <C8CBC8A5-BF87-4560-880A-29A13E376DB6@oracle.com> Message-ID: <1327894053.20151012153401@gmail.com> Hello! If my opinion matters, I'm perfectly fine with Optional.or name, no need to change. With best regards, Tagir Valeev. >> On 25 Sep 2015, at 12:58, Paul Sandoz <Paul.Sandoz at oracle.com> wrote: >> >> Hi, >> >> Please review this change to add a method Optional.or that allows one to better compose optionals: >> >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8080418-optional-or/webrev/ >> >> I also took the opportunity to clear up the JavaDoc, it was a little inconsistent and i personally found it harder to read in source code. >> PS> Now that the overall documentation changes and functional PS> behaviour of Optional.or has been agreed i would like to see if we PS> can find a better name, suggestions welcome, so lets get our paint brushes out :-) PS> I suggest we avoid commenting on comments, otherwise this thread could get out of control. PS> ?Optional.or? is the best name so far i have come up with. The PS> ?orElse? prefix is reversed for terminal methods and i don?t want to overload that. PS> -- PS> Alternative suggestions: PS> - ?Optional.otherwise? PS> A bit of a mouthful, but reasonably accurate PS> - ?Optional.mapElse" PS> The name is not entirely accurate since it accepts a Suppler<T> PS> not a T, a more accurate name would be the following alternative. PS> - ?Optional.flatMapElse" PS> This name is likely to confuse. PS> Paul. From amaembo at gmail.com Mon Oct 12 13:18:16 2015 From: amaembo at gmail.com (Tagir F. Valeev) Date: Mon, 12 Oct 2015 19:18:16 +0600 Subject: Incomplete JavaDoc for Collections.synchronizedXYZ Message-ID: <1322955461.20151012191816@gmail.com> Hello! With the introduction of Stream API the JavaDoc for Collections.synchronizedCollection was updated (as part of work on JDK-8023275): * It is imperative that the user manually synchronize on the returned * collection when traversing it via {@link Iterator}, {@link Spliterator} * or {@link Stream}: This sounds fine, but the same update is missing on other synchronizedXYZ methods. For example, Collections.synchronizedList documentation still states: * It is imperative that the user manually synchronize on the returned * list when iterating over it: Nothing about Spliterator and especially about Stream. The same for synchronizedSet, synchronizedSortedSet, synchronizedNavigableSet. Even though internally all of them inherit the SynchronizedCollection implementation, it's not specified that, for example, synchronizedSet behavior is somehow connected with synchronizedCollection behavior. I think, the corresponding documentation update should be added. It's especially important for the Stream as many people see no difference between collection.forEach(...); And collection.stream().forEach(...); But with synchronized collections these two lines are very different: the second call is not synchronized. What do you think? With best regards, Tagir Valeev. From vyom.tewari at oracle.com Mon Oct 12 15:09:13 2015 From: vyom.tewari at oracle.com (Vyom Tewari) Date: Mon, 12 Oct 2015 20:39:13 +0530 Subject: RFR 8068887 : java.lang.Throwable could use Collections.emptyList for suppressedException Message-ID: <561BCD19.9060408@oracle.com> Hi All, Please review my changes for below bug. Bug: JDK-8068887 : java.lang.Throwable could use Collections.emptyList for suppressedException Webrev: http://cr.openjdk.java.net/~vtewari/8068887/webrev.00/webrev/ This change ensure that fewer classes are loaded in a simple(hello world) program, and thus a very very small start-up footprint improvement. Thanks, Vyom From joe.darcy at oracle.com Mon Oct 12 15:53:59 2015 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 12 Oct 2015 08:53:59 -0700 Subject: JDK 9 RFR of JDK-8136799 Port fdlibm cbrt to Java Message-ID: <561BD797.6040803@oracle.com> Hello, Please review the next step of porting fdlibm to Java, the cbrt method: JDK-8136799 Port fdlibm cbrt to Java http://cr.openjdk.java.net/~darcy/8136799.3/ A few points of note about the port, there is a transliteration port in the test area for comparison purposes. I also ran these tests against an 8 update release where fdlibm is in C; this helps verify the transliteration port is correct. The small updates to constrain the @build directive in the tests to just the random number library allow the regression tests to be run out-of-the-box against JDK 8 as well as JDK 9. Thanks, -Joe From Alan.Bateman at oracle.com Mon Oct 12 15:56:35 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 12 Oct 2015 16:56:35 +0100 Subject: RFR 8068887 : java.lang.Throwable could use Collections.emptyList for suppressedException In-Reply-To: <561BCD19.9060408@oracle.com> References: <561BCD19.9060408@oracle.com> Message-ID: <561BD833.3090104@oracle.com> On 12/10/2015 16:09, Vyom Tewari wrote: > Hi All, > > Please review my changes for below bug. > > Bug: JDK-8068887 : java.lang.Throwable could use > Collections.emptyList for suppressedException > Webrev: http://cr.openjdk.java.net/~vtewari/8068887/webrev.00/webrev/ > > This change ensure that fewer classes are loaded in a simple(hello > world) program, and thus a very very small start-up footprint > improvement. > This looks okay (just missing the a space in =Collections) but I'm curious if it does actual reduce the number of classes loaded at startup. I would think ArrayList and unmodifiable list would be popular. (Your patch makes me wonder if Collections.unmodifiableXXX should return emptyXXX when the collection is empty). -Alan From aleksey.shipilev at oracle.com Mon Oct 12 16:20:56 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 12 Oct 2015 19:20:56 +0300 Subject: RFR 8068887 : java.lang.Throwable could use Collections.emptyList for suppressedException In-Reply-To: <561BD833.3090104@oracle.com> References: <561BCD19.9060408@oracle.com> <561BD833.3090104@oracle.com> Message-ID: <561BDDE8.2090500@oracle.com> On 10/12/2015 06:56 PM, Alan Bateman wrote: > On 12/10/2015 16:09, Vyom Tewari wrote: >> Bug: JDK-8068887 : java.lang.Throwable could use >> Collections.emptyList for suppressedException >> Webrev: http://cr.openjdk.java.net/~vtewari/8068887/webrev.00/webrev/ +1 > (Your patch makes me wonder if Collections.unmodifiableXXX should return > emptyXXX when the collection is empty). No, of course not :) The mere fact a collection is empty when the unmodifiable view is acquired does not mean somebody who can access the collection via the "modifiable" reference would not update it ;) Thanks, -Aleksey From peter.levart at gmail.com Mon Oct 12 16:22:49 2015 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 12 Oct 2015 18:22:49 +0200 Subject: RFR 8068887 : java.lang.Throwable could use Collections.emptyList for suppressedException In-Reply-To: <561BD833.3090104@oracle.com> References: <561BCD19.9060408@oracle.com> <561BD833.3090104@oracle.com> Message-ID: <561BDE59.5080201@gmail.com> On 10/12/2015 05:56 PM, Alan Bateman wrote: > > > On 12/10/2015 16:09, Vyom Tewari wrote: >> Hi All, >> >> Please review my changes for below bug. >> >> Bug: JDK-8068887 : java.lang.Throwable could use >> Collections.emptyList for suppressedException >> Webrev: http://cr.openjdk.java.net/~vtewari/8068887/webrev.00/webrev/ >> >> This change ensure that fewer classes are loaded in a simple(hello >> world) program, and thus a very very small start-up footprint >> improvement. >> > This looks okay (just missing the a space in =Collections) but I'm > curious if it does actual reduce the number of classes loaded at > startup. I would think ArrayList and unmodifiable list would be popular. > > (Your patch makes me wonder if Collections.unmodifiableXXX should > return emptyXXX when the collection is empty). Can not. unmodifiableXXX is defined to be a view over possibly modifiable collection. If underlying collection changes, the view changes. Peter > > -Alan > From claes.redestad at oracle.com Mon Oct 12 16:22:45 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 12 Oct 2015 18:22:45 +0200 Subject: RFR 8068887 : java.lang.Throwable could use Collections.emptyList for suppressedException In-Reply-To: <561BD833.3090104@oracle.com> References: <561BCD19.9060408@oracle.com> <561BD833.3090104@oracle.com> Message-ID: <561BDE55.4030008@oracle.com> On 2015-10-12 17:56, Alan Bateman wrote: >> > This looks okay (just missing the a space in =Collections) but I'm > curious if it does actual reduce the number of classes loaded at > startup. I would think ArrayList and unmodifiable list would be popular. I filed this RFE, so this looks okay to me as well. :-) I recall verifying that this drops a few tiny Collections.unmodifiableXX-related classes from various small applications. Also at least 2 fewer Objects on the heap. > > (Your patch makes me wonder if Collections.unmodifiableXXX should > return emptyXXX when the collection is empty). There's that small chance that someone is synchronizing on their (possibly empty) unmodifiableXXX collections, and this might not help anyone enough to justify even the most far-fetched compatibility risk. /Claes > > -Alan From Alan.Bateman at oracle.com Mon Oct 12 16:24:13 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 12 Oct 2015 17:24:13 +0100 Subject: RFR 8068887 : java.lang.Throwable could use Collections.emptyList for suppressedException In-Reply-To: <561BDDE8.2090500@oracle.com> References: <561BCD19.9060408@oracle.com> <561BD833.3090104@oracle.com> <561BDDE8.2090500@oracle.com> Message-ID: <561BDEAD.8030206@oracle.com> On 12/10/2015 17:20, Aleksey Shipilev wrote: > : > No, of course not :) The mere fact a collection is empty when the > unmodifiable view is acquired does not mean somebody who can access the > collection via the "modifiable" reference would not update it ;) > Of course :-) From mikeb01 at gmail.com Mon Oct 5 09:24:29 2015 From: mikeb01 at gmail.com (Michael Barker) Date: Mon, 5 Oct 2015 22:24:29 +1300 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <56123B47.4070706@oracle.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <56123B47.4070706@oracle.com> Message-ID: <CALwNKeSCQjM8V0+_QRqLHkvJ6WRHxZSL7gxpvsx2qGKtm+OFfQ@mail.gmail.com> > > Hi Gil, > > Glad to see this being addressed! > Me too, this would be a useful addition to the Disruptor. On 10/04/2015 07:22 PM, Gil Tene wrote: > > We propose to add a method to the JDK which would be hint that a spin > > loop is being performed. E.g. > > jdk.util.PerformanceHints.spinLoopHint(), which will hopefully evolve > > to a Java SE API, e.g. java.util.PerformanceHints.spinLoopHint(). The > > specific name space location, class name, and method name will be > > determined as part of development of this JEP. > > Yes, that would be a tough part. JDK is usually oblivious of these > low-level platform-specific hints, they go to sun.misc.* (e.g. Unsafe, > @Contended and others...). I'll let Project Leads to make that call :) > I think many of us are hoping that this will actually be a public API, unlike @Contented, will be enabled by default and therefore useful for third party libraries. Mike. From jeanphilippe.bempel at ullink.com Tue Oct 6 13:31:43 2015 From: jeanphilippe.bempel at ullink.com (Jean Philippe Bempel) Date: Tue, 6 Oct 2015 15:31:43 +0200 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <56138372.7050107@redhat.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <56123B47.4070706@oracle.com> <9FD5F6D1-2875-469C-B4C1-5F7ED0740084@azulsystems.com> <56138372.7050107@redhat.com> Message-ID: <CABLF9EtJpx9x+yzV7jjWBSme0QAG+Zgw6RD=w=s=HZRBLD8mFQ@mail.gmail.com> On Tue, Oct 6, 2015 at 10:16 AM, Andrew Haley <aph at redhat.com> wrote: > > Sure. I would have thought, though, that java.util.concurrent was a > natural home for this. Is there any kind of userland spinlock which > is not about concurrency? > > Andrew. > Spinning is not always for a spinlock. Most of the time is a lightweight & userland only wait/notify implementation. Or park/unpark equivalent which tends to fit into LockSupport like Paul Sandoz suggests. *Jean-Philippe Bempel* *|* Software Architect* |* *ULLINK |* T: +33 1 49 95 10 29 | 23-25 rue de Provence | 75009 Paris | *jpbempel at ullink.com* <jpbempel at ullink.com> | -- *The information contained in or attached to this email is strictly confidential. If you are not the intended recipient, please notify us immediately by telephone and return the message to us.* From jeanphilippe.bempel at ullink.com Wed Oct 7 08:03:32 2015 From: jeanphilippe.bempel at ullink.com (Jean Philippe Bempel) Date: Wed, 7 Oct 2015 10:03:32 +0200 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <56147A5A.5040308@oracle.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56147A5A.5040308@oracle.com> Message-ID: <CABLF9EtswGPEPJ_zoABHFfciQVK9GYf_CCXTe=mmpkkxLUrv9Q@mail.gmail.com> It seems you suggest to hide this feature "? la" Unsafe to avoid exposing a new Java SE API. But the move is quite the opposite right now where all Unsafe "features" will find an exit to a public reliable API which is good and low latency and performance people is waiting for. JVM already uses the PAUSE instruction into the synchronized block implementation before inflating part which is also a sign of a good behavior that Java users would like to leverage on their code. Spinning is here since a long time now, and there is no evidence it will change in the next year. And even if this is changing, roll backing to a no-op implementation will be safe anyway. This JEP starts with a baby step, but some other stuffs are in the pipe (like Doug's list). The most difficult part is to agree on the API for future improvement in that area. *Jean-Philippe Bempel* *|* Software Architect* |* *ULLINK |* T: +33 1 49 95 10 29 | 23-25 rue de Provence | 75009 Paris | *jpbempel at ullink.com* <jpbempel at ullink.com> | On Wed, Oct 7, 2015 at 3:50 AM, Joseph D. Darcy <joe.darcy at oracle.com> wrote: > > On 10/6/2015 6:28 PM, Gil Tene wrote: > >> On Oct 6, 2015, at 1:02 PM, Doug Lea <dl at cs.oswego.edu> wrote: >>> >>> On 10/04/2015 12:22 PM, Gil Tene wrote: >>> >>>> I would like to circulate this draft JEP proposal for initial review >>>> and consensus building purposes. >>>> >>>> Some background: about two years ago, Dave Dice and I put together >>> a pre-jep proposal for JVM support for recent CPU features covering: >>> >>> (1) MWAIT/PAUSE/etc (for spins as well as other uses people have noted); >>> (2) Core topology/neighborhood information and; >>> (3) 2CAS, as a foothold on HTM that could still be reasonably efficient >>> on non-transactional processors. >>> >>> My understanding of the result of this effort was that Oracle JVM >>> engineers >>> didn't think they had resources to do this for jdk9. It didn't occur to >>> me that non-Oracle contributors might want to cherry-pick one (some >>> of (1) above). It seems plausible to do this, but only if designed >>> as the first of some possible enhanced support along these lines. >>> >> Good point. But that's what an actual community is about. Isn't it? >> >> We (Azul) are volunteering the resources for spinloopHint(). Including >> experimentation, implementation, testing, and even a TCK (which in this >> case >> will be trivial). So the vast majority of resources needed will not be >> coming >> other budgeted jdk9 resources. >> >> I certainly recognize that there will still be work involved that others >> will >> end up having to do: reviewing, arguing, contributing opinions, etc., as >> well >> as integrating the work into the whole. But this specific proposed JEP is >> about >> as narrow and low risk as you can get. especially from a specification >> point of >> view (e.g. intrinsic implementation can be left under a flag if deemed >> risky to >> stability or schedule). >> >> As for fitting in with larger-picture or theme things (listed above). I >> think that >> agonizing over the choice of where to put this is important (e.g. the >> Thread.spinLoopHint() >> idea, or a create new class that other hints will go into in the future, >> and where?). >> But I don't think that there is good reason to bundle this work with e.g. >> 2CAS, HTM, >> and affinity. Work. While we can think of them all as "support for recent >> CPU features", >> they are very different (and probably have multiple other unrelated >> groupings). >> >> MWAIT (and the like) and PAUSE do deserve some co-thinking (see earlier >> discussion >> on the thread). So does a discussion about a capturing abstraction like >> synchronic >> (raised in concurrency interest), But given the actual common uses >> already waiting >> for a spinLoopHint(), the very tangible and immediate benefit it shows, >> and the fact that >> most of the use cases wouldn't be able to make use of MWAIT (or the >> like), and some >> won't be able to use a synchronic-like thing, I think that either a >> spin-hint-only JEP >> is not just a good "shortcut", but also an actual stand-alone feature >> need. >> >> > Taking a long-term view, it seems to me premature to burn this kind of > hint into the Java SE API (effectively) forever in the absence of > experience that the hint in this form is useful and will continue to be > useful in 5 years, 10 years, etc. > > If the hint started out as a JDK-specific API, there would be (some) more > room to modify or drop the API in the future, leaving open the possibility > of migrating the functionality to the Java SE API too. > > -Joe > -- *The information contained in or attached to this email is strictly confidential. If you are not the intended recipient, please notify us immediately by telephone and return the message to us.* From goetz.lindenmaier at sap.com Thu Oct 8 12:45:59 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 8 Oct 2015 12:45:59 +0000 Subject: RFR(xxs): 8139037: [aix] Crash in ResolverConfigurationImpl.c - pointer shearing In-Reply-To: <CAA-vtUxoXJyAXKSJ5gnGjOO2rH0PM=ewJyW4ep83S34fTTszVA@mail.gmail.com> References: <CAA-vtUxoXJyAXKSJ5gnGjOO2rH0PM=ewJyW4ep83S34fTTszVA@mail.gmail.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41E80FF9@DEWDFEMB12A.global.corp.sap> Hi Thomas, the change looks good. Thanks for fixing this. Best regards, Goetz. From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Thomas St?fe Sent: Mittwoch, 7. Oktober 2015 16:28 To: Java Core Libs; ppc-aix-port-dev at openjdk.java.net Subject: RFR(xxs): 8139037: [aix] Crash in ResolverConfigurationImpl.c - pointer shearing Hi, please review and sponsor this AIX fix. in ResolverConfigurationImpl.c, we may crash because strchr() is used without prototype, which causes the C compiler to default to an int return type, which means we loose the upper 32bit of the pointer returned by strchr(). The solution is to include string.h. Before, string.h was conditionally included for all platforms but AIX - reason is not really clear to me. But as strchr() is POSIX and always in string.h, I included string.h unconditionally for all Unices. webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8139037/webrev.00/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8139037 Kind Regards, Thomas From viktor.klang at gmail.com Thu Oct 8 17:48:51 2015 From: viktor.klang at gmail.com (Viktor Klang) Date: Thu, 8 Oct 2015 19:48:51 +0200 Subject: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal In-Reply-To: <C4F66753-5C67-4F96-9132-079A0F91EBBB@oracle.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56164C3C.4050800@cs.oswego.edu> <56164D1F.405@redhat.com> <5616841C.6000406@cs.oswego.edu> <20151008093318.990378@eggemoggin.niobe.net> <C4F66753-5C67-4F96-9132-079A0F91EBBB@oracle.com> Message-ID: <CANPzfU-UHdepNfSQ+6i0yQ3oX3uqUqp2V+6qEromE7sms8B-5A@mail.gmail.com> +1 On Thu, Oct 8, 2015 at 6:35 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote: > > > On 8 Oct 2015, at 18:33, mark.reinhold at oracle.com wrote: > > > > 2015/10/8 7:56 -0700, dl at cs.oswego.edu: > >>>> ... > >>>> > >>>> class Thread { // > >>>> /** > >>>> * A hint to the platform that the current thread is momentarily > >>>> * unable to progress. ... add more guidance ... > >>>> */ > >>>> void spinYield(); > >> > >> should be: > >> public static void spinYield(); > > > > Yes -- let's keep this simple. It's just one method, another hint > > in j.l.Thread which can be ignored (or not) by the VM. > > > > This concept seems sufficiently well understood, based on its use > > in other platforms, that putting it directly into j.l.Thread is not > > a huge risk. I don't see a strong need for this to start out as a > > JDK-specific API. > > > > +1 > > Paul. > > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest at cs.oswego.edu > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > > -- Cheers, ? From haim at performize-it.com Fri Oct 9 15:34:02 2015 From: haim at performize-it.com (Haim Yadid) Date: Fri, 9 Oct 2015 18:34:02 +0300 Subject: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal In-Reply-To: <5616841C.6000406@cs.oswego.edu> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56164C3C.4050800@cs.oswego.edu> <56164D1F.405@redhat.com> <5616841C.6000406@cs.oswego.edu> Message-ID: <902D73C6-8BDA-4FCD-BEE8-EA10808B3B28@performize-it.com> +1 as well :) BR, Haim Yadid > On 8 ????? 2015, at 17:56, Doug Lea <dl at cs.oswego.edu> wrote: > >> On 10/08/2015 07:01 AM, David M. Lloyd wrote: >>> On 10/08/2015 05:58 AM, Doug Lea wrote: >>> >>> class Thread { // >>> /** >>> * A hint to the platform that the current thread is momentarily >>> * unable to progress. ... add more guidance ... >>> */ >>> void spinYield(); > > should be: > public static void spinYield(); > >>> } >>> >>> In principle, this would also allow the implementation to do an actual >>> yield on uniprocessors or when the load average is high. Probably not >>> in initial implementation though. >>> >>> Adding a method to class Thread risks name clashes with existing >>> methods introduced in subclasses. So this might need a clunkier name >>> to effectively eliminate the possibility. >> >> If the method is static, then the impact of a clashing name should be fairly >> minimal. > > Right. For statics, pretty much the only concern is whether > reflective mechanics (Class.getMethod etc) return unexpected > entries that would break existing code. The name "spinYield" > seems unlikely enough to be a problem though. > > -Doug > > > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest at cs.oswego.edu > http://cs.oswego.edu/mailman/listinfo/concurrency-interest From ecki at zusammenkunft.net Mon Oct 12 16:45:10 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 12 Oct 2015 18:45:10 +0200 Subject: ChronoUnit.FOREVER javadoc talks about era Message-ID: <20151012184510.00007bfc.ecki@zusammenkunft.net> It might be intentional or a copy+paste thing, the javadoc of FOREVER reads: "... The estimated duration of the era is artificially defined as the largest duration supported by Duration." Since this fragment of the sentence is also describing ERA i suspect its a copy+paste problem, it can be reworded in: The estimated duration of this unit is artificially defined as the largest duration supported by @{link Duration}. Greetings Bernd From mandy.chung at oracle.com Mon Oct 12 16:54:43 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 12 Oct 2015 09:54:43 -0700 Subject: RFR 8068887 : java.lang.Throwable could use Collections.emptyList for suppressedException In-Reply-To: <561BCD19.9060408@oracle.com> References: <561BCD19.9060408@oracle.com> Message-ID: <9411EB09-AE2C-4A7A-A6E9-E9B44F5E030A@oracle.com> > On Oct 12, 2015, at 8:09 AM, Vyom Tewari <vyom.tewari at oracle.com> wrote: > > Hi All, > > Please review my changes for below bug. > > Bug: JDK-8068887 : java.lang.Throwable could use Collections.emptyList for suppressedException > Webrev: http://cr.openjdk.java.net/~vtewari/8068887/webrev.00/webrev/ > > This change ensure that fewer classes are loaded in a simple(hello world) program, and thus a very very small start-up footprint improvement. Looks okay to me (as Alan pointed out, a space is missing in ?=Collections.emptyList?. I?m curious to see the diff of -verbose:class before and after. Mandy From openjdk at duigou.org Mon Oct 12 17:50:21 2015 From: openjdk at duigou.org (Mike Duigou) Date: Mon, 12 Oct 2015 10:50:21 -0700 Subject: Array equality, comparison and mismatch In-Reply-To: <mailman.9033.1444655880.25018.core-libs-dev@openjdk.java.net> References: <mailman.9033.1444655880.25018.core-libs-dev@openjdk.java.net> Message-ID: <d61dae710154e4502ef52e4016ef0ede@sonic.net> >> On 22 Sep 2015, at 18:30, Paul Sandoz <Paul.Sandoz at oracle.com> wrote: >> >> Hi, >> >> Please review the following which adds methods to Arrays for >> performing equality, comparison and mismatch: >> >> https://bugs.openjdk.java.net/browse/JDK-8033148 >> >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/webrev/ >> >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/specdiff/overview-summary.html >> > > Updated the above with JavaDoc for all methods. > > Paul. There is a Kilimanjaro of tedium in building changes like these that are implemented across all the basic types. Thank you for taking this on so thoroughly. A few comments. - Inconsistent @since declarations. Both "9" and "1.9" are used. I know Henry Jen was working on normalizing this for the -platform javac work, but am uncertain what was chosen. It is perhaps time to drop the "1." - Have you done side by side textual comparisons of the docs and implementations to make sure there are only expected differences of types and semantics (== vs equals vs compareUnsigned)? It's easy for an error to creep in as you go through many iterations by forgetting to make a fix in one implementation. - I apologize if this was discussed earlier in the thread but why is the comparison of floats and doubles done by first == operator of the int bits and only then the compare method ? It would seem that the compare method could use this same technique if it wanted. Why not do the same for unsigned comparisons since == would also work for those? I am *REALLY* looking forward to using these! Mike From chris.hegarty at oracle.com Mon Oct 12 18:17:44 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 12 Oct 2015 19:17:44 +0100 Subject: RFR 8068887 : java.lang.Throwable could use Collections.emptyList for suppressedException In-Reply-To: <9411EB09-AE2C-4A7A-A6E9-E9B44F5E030A@oracle.com> References: <561BCD19.9060408@oracle.com> <9411EB09-AE2C-4A7A-A6E9-E9B44F5E030A@oracle.com> Message-ID: <502B8259-EE40-4060-BAA2-DCA208273228@oracle.com> On 12 Oct 2015, at 17:54, Mandy Chung <mandy.chung at oracle.com> wrote: > >> On Oct 12, 2015, at 8:09 AM, Vyom Tewari <vyom.tewari at oracle.com> wrote: >> >> Hi All, >> >> Please review my changes for below bug. >> >> Bug: JDK-8068887 : java.lang.Throwable could use Collections.emptyList for suppressedException >> Webrev: http://cr.openjdk.java.net/~vtewari/8068887/webrev.00/webrev/ >> >> This change ensure that fewer classes are loaded in a simple(hello world) program, and thus a very very small start-up footprint improvement. > > Looks okay to me (as Alan pointed out, a space is missing in ?=Collections.emptyList?. +1 -Chris. From mark.reinhold at oracle.com Mon Oct 12 19:30:16 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 12 Oct 2015 12:30:16 -0700 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5616D504.4000104@Oracle.com> References: <560D3F61.6040607@Oracle.com>, <560E6FEB.60607@gmail.com>, <560EA3F2.7030108@Oracle.com>, <5612F582.4050909@Oracle.com>, <5613F19E.7010708@gmail.com>, <56141107.8000407@Oracle.com>, <5616D504.4000104@Oracle.com> Message-ID: <20151012123016.566133@eggemoggin.niobe.net> 2015/10/8 1:41 -0700, roger.riggs at oracle.com: > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-cleaner-extensible-8138696/ > > javadoc: > http://cr.openjdk.java.net/~rriggs/cleaner-doc2/ Roger -- thanks for taking this on. The more we can do to get people to stop using sun.misc APIs, the better. A couple of comments/questions: First, I think the approach in your first version is, well, cleaner. The additional abstract classes in the second version look like a classic case of implementation inheritance that's not subtype inheritance, what with the overrides of the original enqueue and isEnqueued methods to throw UnsupportedOperationException. I understand the desire to avoid allocating too many objects, but do we have actual use cases where that's critical? The original sun.misc.Cleaner has been used by both internal and external code to do relatively heavy-weight things like unmap direct buffers and release other kinds of native resources, which suggests that allocating three small objects per cleaner is not a problem. Second, the original sun.misc.Cleaner only handles phantom references. What are the use cases for weak and soft cleaners? Finally, how important is it to be able to unregister a cleaner? In all the years we've had sun.misc.Cleaner that capability has never been needed, and leaving it out would simplify the API. - Mark From paul.sandoz at oracle.com Mon Oct 12 19:56:29 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 12 Oct 2015 21:56:29 +0200 Subject: Array equality, comparison and mismatch In-Reply-To: <d61dae710154e4502ef52e4016ef0ede@sonic.net> References: <mailman.9033.1444655880.25018.core-libs-dev@openjdk.java.net> <d61dae710154e4502ef52e4016ef0ede@sonic.net> Message-ID: <A2A63237-4C3C-440E-9769-4D31DAF10392@oracle.com> > On 12 Oct 2015, at 19:50, Mike Duigou <openjdk at duigou.org> wrote: > > >>> On 22 Sep 2015, at 18:30, Paul Sandoz <Paul.Sandoz at oracle.com> wrote: >>> Hi, >>> Please review the following which adds methods to Arrays for performing equality, comparison and mismatch: >>> https://bugs.openjdk.java.net/browse/JDK-8033148 >>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/webrev/ >>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/specdiff/overview-summary.html >> Updated the above with JavaDoc for all methods. >> Paul. > > There is a Kilimanjaro of tedium in building changes like these that are implemented across all the basic types. Thank you for taking this on so thoroughly. Tell me about it :-) > > A few comments. > > - Inconsistent @since declarations. Both "9" and "1.9" are used. I know Henry Jen was working on normalizing this for the -platform javac work, but am uncertain what was chosen. It is perhaps time to drop the "1.? > I updated Byte/Short methods. At some point there is likely to be a global s/@since 1.9/@since 9/ but i have been trying to use 9 where possible. > - Have you done side by side textual comparisons of the docs and implementations to make sure there are only expected differences of types and semantics (== vs equals vs compareUnsigned)? It's easy for an error to creep in as you go through many iterations by forgetting to make a fix in one implementation. > Not specifically but kind of when i copied the template from the byte[] receiving methods. I have eyeballed them enough times in different contexts: code, javadoc, specdiff. Doing that caught some mistakes. There might be some mistakes still lurking... > - I apologize if this was discussed earlier in the thread but why is the comparison of floats and doubles done by first == operator of the int bits and only then the compare method ? I was being consistent with the test used for the existing equals methods of float[] and double[]. Note that the Float/Double.*to*Bits methods are intrinsic. > It would seem that the compare method could use this same technique if it wanted. Why not do the same for unsigned comparisons since == would also work for those? > I am not following, sorry. Are you suggesting say: for (int i = 0; i < length; i++) { int c = Double.compare(a[i], b[i]) if (c != 0) return c; } ? Note that this area will change when the unsafe vectored mismatch goes in. > I am *REALLY* looking forward to using these! > Thanks. You might like them even more when they get faster :-) Paul. From brent.christian at oracle.com Mon Oct 12 21:44:25 2015 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 12 Oct 2015 14:44:25 -0700 Subject: RFR 9 : 8138824 : java.lang.String: spec doesn't match impl when ignoring case - equalsIgnoreCase(), regionMatches() In-Reply-To: <5616A66B.50407@oracle.com> References: <5615AB1F.4050604@oracle.com> <56169267.3060505@oracle.com> <5616A66B.50407@oracle.com> Message-ID: <561C29B9.7080403@oracle.com> FYI: updated webrev & specdiff with test case, and Roger's suggestion for using @link: http://cr.openjdk.java.net/~bchristi/8138824/webrev.1/ http://cr.openjdk.java.net/~bchristi/8138824/specdiff.1/overview-summary.html Thanks, -Brent On 10/8/15 10:22 AM, Brent Christian wrote: > Sure, I'll write something. -B > On 10/08/2015 08:57 AM, Naoto Sato wrote: >> Hi Brent, >> >> I wonder whether we should add a negative test case, in which >> lowercasing/uppercasing on the originals would differ but >> String.equalsIgnoreCase() returns true. >> >> Naoto >> >> On 10/7/15 4:30 PM, Brent Christian wrote: >>> Hi, >>> >>> Please review my doc/spec change (no code) for 8138824. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138824 >>> Webrev: http://cr.openjdk.java.net/~bchristi/8138824/webrev.0/ >>> Specdiff: >>> http://cr.openjdk.java.net/~bchristi/8138824/specdiff.0/overview-summary.html >>> >>> >>> >>> >>> This change addresses a longstanding mismatch between spec and >>> implementation, clarifies comparison methods which do not account for >>> locale, and adds references to the locale-aware java.text.Collator. >>> >>> Thanks, >>> -Brent >>> > From naoto.sato at oracle.com Mon Oct 12 22:40:35 2015 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 12 Oct 2015 15:40:35 -0700 Subject: RFR 9 : 8138824 : java.lang.String: spec doesn't match impl when ignoring case - equalsIgnoreCase(), regionMatches() In-Reply-To: <561C29B9.7080403@oracle.com> References: <5615AB1F.4050604@oracle.com> <56169267.3060505@oracle.com> <5616A66B.50407@oracle.com> <561C29B9.7080403@oracle.com> Message-ID: <561C36E3.1040703@oracle.com> Hi Brent, Thank you for adding a test case. I have two comments in the test case: - A typo in line 32: "symetrically" -> "symmetrically" - Should "toUpperToLowerOriginals() compare the length of two strings? The current implementation returns true if str2.startsWith(str1) is true. Naoto On 10/12/15 2:44 PM, Brent Christian wrote: > FYI: updated webrev & specdiff with test case, and Roger's suggestion > for using @link: > > http://cr.openjdk.java.net/~bchristi/8138824/webrev.1/ > > http://cr.openjdk.java.net/~bchristi/8138824/specdiff.1/overview-summary.html > > > Thanks, > -Brent > > On 10/8/15 10:22 AM, Brent Christian wrote: >> Sure, I'll write something. -B >> On 10/08/2015 08:57 AM, Naoto Sato wrote: >>> Hi Brent, >>> >>> I wonder whether we should add a negative test case, in which >>> lowercasing/uppercasing on the originals would differ but >>> String.equalsIgnoreCase() returns true. >>> >>> Naoto >>> >>> On 10/7/15 4:30 PM, Brent Christian wrote: >>>> Hi, >>>> >>>> Please review my doc/spec change (no code) for 8138824. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138824 >>>> Webrev: http://cr.openjdk.java.net/~bchristi/8138824/webrev.0/ >>>> Specdiff: >>>> http://cr.openjdk.java.net/~bchristi/8138824/specdiff.0/overview-summary.html >>>> >>>> >>>> >>>> >>>> >>>> This change addresses a longstanding mismatch between spec and >>>> implementation, clarifies comparison methods which do not account for >>>> locale, and adds references to the locale-aware java.text.Collator. >>>> >>>> Thanks, >>>> -Brent >>>> >> From brent.christian at oracle.com Mon Oct 12 22:52:10 2015 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 12 Oct 2015 15:52:10 -0700 Subject: RFR 9 : 8138824 : java.lang.String: spec doesn't match impl when ignoring case - equalsIgnoreCase(), regionMatches() In-Reply-To: <561C36E3.1040703@oracle.com> References: <5615AB1F.4050604@oracle.com> <56169267.3060505@oracle.com> <5616A66B.50407@oracle.com> <561C29B9.7080403@oracle.com> <561C36E3.1040703@oracle.com> Message-ID: <561C399A.1010909@oracle.com> On 10/12/15 3:40 PM, Naoto Sato wrote: > I have two comments in the test case: > > - A typo in line 32: "symetrically" -> "symmetrically" Well-spotted. I also fixed "corresponsing" on line 78. :) > - Should "toUpperToLowerOriginals() compare the length of two strings? > The current implementation returns true if str2.startsWith(str1) is true. Yes, it also seems to me that true should only be returned if the Strings' lengths match. Fixes will be in the pushed version. Thanks, Naoto. -Brent > On 10/12/15 2:44 PM, Brent Christian wrote: >> FYI: updated webrev & specdiff with test case, and Roger's suggestion >> for using @link: >> >> http://cr.openjdk.java.net/~bchristi/8138824/webrev.1/ >> >> http://cr.openjdk.java.net/~bchristi/8138824/specdiff.1/overview-summary.html >> >> >> >> Thanks, >> -Brent >> >> On 10/8/15 10:22 AM, Brent Christian wrote: >>> Sure, I'll write something. -B >>> On 10/08/2015 08:57 AM, Naoto Sato wrote: >>>> Hi Brent, >>>> >>>> I wonder whether we should add a negative test case, in which >>>> lowercasing/uppercasing on the originals would differ but >>>> String.equalsIgnoreCase() returns true. >>>> >>>> Naoto >>>> >>>> On 10/7/15 4:30 PM, Brent Christian wrote: >>>>> Hi, >>>>> >>>>> Please review my doc/spec change (no code) for 8138824. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138824 >>>>> Webrev: http://cr.openjdk.java.net/~bchristi/8138824/webrev.0/ >>>>> Specdiff: >>>>> http://cr.openjdk.java.net/~bchristi/8138824/specdiff.0/overview-summary.html >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This change addresses a longstanding mismatch between spec and >>>>> implementation, clarifies comparison methods which do not account for >>>>> locale, and adds references to the locale-aware java.text.Collator. >>>>> >>>>> Thanks, >>>>> -Brent >>>>> >>> From mandy.chung at oracle.com Tue Oct 13 01:12:26 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 12 Oct 2015 18:12:26 -0700 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <20151012123016.566133@eggemoggin.niobe.net> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> Message-ID: <B095DF43-4186-4E3D-90B8-91F17B4788DF@oracle.com> > On Oct 12, 2015, at 12:30 PM, mark.reinhold at oracle.com wrote: > > 2015/10/8 1:41 -0700, roger.riggs at oracle.com: >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-extensible-8138696/ >> >> javadoc: >> http://cr.openjdk.java.net/~rriggs/cleaner-doc2/ > > Roger -- thanks for taking this on. The more we can do to get people > to stop using sun.misc APIs, the better. > > A couple of comments/questions: > > First, I think the approach in your first version is, well, cleaner. +1 I started reviewing the first version and pondering on the benefits of the new versions. > The additional abstract classes in the second version look like a > classic case of implementation inheritance that's not subtype > inheritance, what with the overrides of the original enqueue and > isEnqueued methods to throw UnsupportedOperationException. > > I understand the desire to avoid allocating too many objects, but > do we have actual use cases where that's critical? The original > sun.misc.Cleaner has been used by both internal and external code > to do relatively heavy-weight things like unmap direct buffers and > release other kinds of native resources, which suggests that > allocating three small objects per cleaner is not a problem. > > Second, the original sun.misc.Cleaner only handles phantom references. > What are the use cases for weak and soft cleaners? > > Finally, how important is it to be able to unregister a cleaner? In > all the years we've had sun.misc.Cleaner that capability has never > been needed, and leaving it out would simplify the API. If there is no strong need of unregister a cleaner, Cleaner API won?t need to return a Cleanable object which I think it?s nice and simpler. Mandy From mandy.chung at oracle.com Tue Oct 13 02:50:03 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 12 Oct 2015 19:50:03 -0700 Subject: RFR: JDK-8046565: Platform Logging API and Service In-Reply-To: <56181B57.2010801@oracle.com> References: <561660DA.7070900@oracle.com> <56181B57.2010801@oracle.com> Message-ID: <D3BC77EA-30F5-4EB4-93D0-16F4D9D926B5@oracle.com> Hi Daniel, > On Oct 9, 2015, at 12:53 PM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote: > > JEP: > http://openjdk.java.net/jeps/264 > https://bugs.openjdk.java.net/browse/JDK-8046565 > > specdiff: > http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/specdiff-api/overview-summary.html > > webrev: > http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/webrev.01/ This is very good work. I?m glad to see this work that enables the dependency on java.logging be eliminated. The sun.util.logging.PlatformLogger was a stop-gap approach. There are many new tests that I will need time to review them all. I?m going to pass you my comments in several batches. This is the first batch. LogManager.java 1938 if (caller.getClassLoader() == null) { 1939 return LogManager.getLogManager().demandSystemLogger(name, 1940 Logger.SYSTEM_LOGGER_RB_NAME, caller); This only considers the classes loaded by the boot loader as system classes. We have deprivileged several modules to be loaded by the ext class loader such as JAX-WS, JAXB, CORBA etc. Loggers created by modules loaded by boot and ext class loader should be system. In the absence of java.logging, the default provider implementation will be used to print the log messages to System.err. This is useful since most JDK log messages are for debugging. I expect that a component may want to turn on debug messages without requiring the presence of java.logging. Is there any mechanism to change the default level of the default simple console loggers? It may be useful; otherwise it would need to run on an image with java.logging module. Maybe something to add in the future. System.Logger 964 * Unless - incomplete sentence? 1697 * @implSpec 1698 * Instances returned by this method route messages to loggers 1699 * obtained by calling {@link LoggerFinder#getLogger(java.lang.String, java.lang.Class) 1700 * LoggerFinder.getLogger(name, ca Is this intended to be implementation specification but not API spec? RuntimePermission(?LoggerFinder) is required in the provider constructor. - is it time to define a ServiceProviderPermission for provider constructor security permission check? Rather than overloading RuntimePermission public static final RuntimePermission LOGGERFINDER_PERMISSION = new RuntimePermission("loggerFinder?); - is there any need to define this constant? Suggest this be implementation-details. private LoggerFinderLoader() { throw new InternalError("LoggerFinderLoader cannot be instantiated"); } - is throwing InternalError necessary? No one else except its enclosing class can construct it. JdkLoggingProvider::LOGGING_CONTROL_PERMISSION - I think this field is unused. sun/management/ManagementFactoryHelper.java - Is LoggingMXBeanSupport intended to get java.management to remove its dependency on java.logging? 172 public interface LoggingMXBean 173 extends PlatformLoggingMXBean, java.util.logging.LoggingMXBean { 174 } This static dependency will still keep the dependency on java.logging. Mandy From openjdk at duigou.org Tue Oct 13 03:46:18 2015 From: openjdk at duigou.org (Mike Duigou) Date: Mon, 12 Oct 2015 20:46:18 -0700 Subject: Array equality, comparison and mismatch In-Reply-To: <mailman.9142.1444698750.25018.core-libs-dev@openjdk.java.net> References: <mailman.9142.1444698750.25018.core-libs-dev@openjdk.java.net> Message-ID: <85fedd00040c71eee083030befad0c96@sonic.net> > >> - I apologize if this was discussed earlier in the thread but why is >> the comparison of floats and doubles done by first == operator of the >> int bits and only then the compare method ? > > I was being consistent with the test used for the existing equals > methods of float[] and double[]. Note that the Float/Double.*to*Bits > methods are intrinsic. I guess my worry is that the == floatToIntBits would be redundant as the implementation of compare() might have exactly the same test as it's first step--it would be a reasonable optimization since it would have the benefit of loading the values into registers before doing the more expensive relational comparison. Mike From forax at univ-mlv.fr Tue Oct 13 08:11:58 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 13 Oct 2015 10:11:58 +0200 (CEST) Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <B095DF43-4186-4E3D-90B8-91F17B4788DF@oracle.com> References: <560D3F61.6040607@Oracle.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <B095DF43-4186-4E3D-90B8-91F17B4788DF@oracle.com> Message-ID: <84606140.785696.1444723918802.JavaMail.zimbra@u-pem.fr> Hi Roger, I agree with comments from Mark and Mandy, you can also simplify your code by using a lambda instead of a class to implement the thread factory. public static Cleaner create() { return create(runnable -> { return AccessController.doPrivileged((PrivilegedAction<Thread>) () -> { Thread t = new InnocuousThread(runnable); t.setName("Cleaner-" + t.getId()); return t; }); }); } given that the lambda (the one that takes a Runnable) doesn't capture anything, it will be considered as a constant by the VM, so no need to implement the singleton pattern, here. cheers, R?mi ----- Mail original ----- > De: "Mandy Chung" <mandy.chung at oracle.com> > ?: "mark reinhold" <mark.reinhold at oracle.com> > Cc: core-libs-dev at openjdk.java.net > Envoy?: Mardi 13 Octobre 2015 03:12:26 > Objet: Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization > > > > On Oct 12, 2015, at 12:30 PM, mark.reinhold at oracle.com wrote: > > > > 2015/10/8 1:41 -0700, roger.riggs at oracle.com: > >> Webrev: > >> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-extensible-8138696/ > >> > >> javadoc: > >> http://cr.openjdk.java.net/~rriggs/cleaner-doc2/ > > > > Roger -- thanks for taking this on. The more we can do to get people > > to stop using sun.misc APIs, the better. > > > > A couple of comments/questions: > > > > First, I think the approach in your first version is, well, cleaner. > > +1 > > I started reviewing the first version and pondering on the benefits of the > new versions. > > > > The additional abstract classes in the second version look like a > > classic case of implementation inheritance that's not subtype > > inheritance, what with the overrides of the original enqueue and > > isEnqueued methods to throw UnsupportedOperationException. > > > > I understand the desire to avoid allocating too many objects, but > > do we have actual use cases where that's critical? The original > > sun.misc.Cleaner has been used by both internal and external code > > to do relatively heavy-weight things like unmap direct buffers and > > release other kinds of native resources, which suggests that > > allocating three small objects per cleaner is not a problem. > > > > Second, the original sun.misc.Cleaner only handles phantom references. > > What are the use cases for weak and soft cleaners? > > > > Finally, how important is it to be able to unregister a cleaner? In > > all the years we've had sun.misc.Cleaner that capability has never > > been needed, and leaving it out would simplify the API. > > If there is no strong need of unregister a cleaner, Cleaner API won?t need to > return a Cleanable object which I think it?s nice and simpler. > > Mandy > > From peter.levart at gmail.com Tue Oct 13 08:31:05 2015 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 13 Oct 2015 10:31:05 +0200 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <B095DF43-4186-4E3D-90B8-91F17B4788DF@oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <B095DF43-4186-4E3D-90B8-91F17B4788DF@oracle.com> Message-ID: <561CC149.4080203@gmail.com> Hi Roger, Mark and Mandy On 10/13/2015 03:12 AM, Mandy Chung wrote: >> On Oct 12, 2015, at 12:30 PM, mark.reinhold at oracle.com wrote: >> >> 2015/10/8 1:41 -0700, roger.riggs at oracle.com: >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-extensible-8138696/ >>> >>> javadoc: >>> http://cr.openjdk.java.net/~rriggs/cleaner-doc2/ >> Roger -- thanks for taking this on. The more we can do to get people >> to stop using sun.misc APIs, the better. >> >> A couple of comments/questions: >> >> First, I think the approach in your first version is, well, cleaner. > +1 > > I started reviewing the first version and pondering on the benefits of the new versions. > > >> The additional abstract classes in the second version look like a >> classic case of implementation inheritance that's not subtype >> inheritance, what with the overrides of the original enqueue and >> isEnqueued methods to throw UnsupportedOperationException. >> >> I understand the desire to avoid allocating too many objects, but >> do we have actual use cases where that's critical? The original >> sun.misc.Cleaner has been used by both internal and external code >> to do relatively heavy-weight things like unmap direct buffers and >> release other kinds of native resources, which suggests that >> allocating three small objects per cleaner is not a problem. >> >> Second, the original sun.misc.Cleaner only handles phantom references. >> What are the use cases for weak and soft cleaners? >> >> Finally, how important is it to be able to unregister a cleaner? In >> all the years we've had sun.misc.Cleaner that capability has never >> been needed, and leaving it out would simplify the API. > If there is no strong need of unregister a cleaner, Cleaner API won?t need to return a Cleanable object which I think it?s nice and simpler. > > Mandy > There is one usage of sun.misc.Cleaner.clean() in JavaFX, I think. I also think that this API could have two faces: the simple face (it might even be without returning Cleanable and only Phantom-typed to be super-simple). The other low-level face could be abstract [Phantom|Weak|Soft]CleanableReference(s) which would take a mandatory Cleaner instance in the constructors instead of a ReferenceQueue. There could also be a JDK-internal single instance of a permanent Cleaner with a background thread to be used for JDK-internal cleanup tasks. I think there are several opportunities for the low-level part of the API in the JDK: - ClassLoader.getClassLoadingLock(String className): maintains an internal ConcurrentHashMap<String, Object> for locks - one entry per class-loading attempt. Those locks are just used briefly in most occasions and then kept in the map indefinitely. A couple of years ago I did an experiment to replace such map with ConcurrentHashMap<String, WeakReference<Object>> and it observably reduced the final footprint after starting-up an application with lots of classes. The sub-optimality of that approach was that some locks were always kept alive, since the expunging of cleared WeakReferences from the map was performed by class-loading requests and there can be long periods in an application without class-loading activity. An "active" auto-cleanable WeakReference would off-load the expunging activity to a background thread which would make sure to remove *all* cleared references from the map. - A couple of months ago I did a successful experiment in refactoring File[Input|Output]Stream and RandomAccessFile to use a Cleaner-like API instead of finalize() method. It was based on the premise that there is an on-demand cleaning method like Cleaner.clean(), which was called as part of the last close() on the FileHandle. [Phantom|Weak|Soft]Reference(s) are not something an average application programmer uses every day. It's more for constructors of middle-ware I think. And those are the programmers that are not afraid of lower-level APIs. They do care for flexibility of the API. But if the low-level API is not something that you are comfortable to expose to users, could it at least be used internally? Simply moving the public [Phantom|Weak|Soft]CleanableReference(s) to an internal package (like java.lang.ref.internal)? Regards, Peter From thomas.stuefe at gmail.com Tue Oct 13 08:52:14 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 13 Oct 2015 10:52:14 +0200 Subject: RFR(xxs): 8139037: [aix] Crash in ResolverConfigurationImpl.c - pointer shearing In-Reply-To: <CAA-vtUxoXJyAXKSJ5gnGjOO2rH0PM=ewJyW4ep83S34fTTszVA@mail.gmail.com> References: <CAA-vtUxoXJyAXKSJ5gnGjOO2rH0PM=ewJyW4ep83S34fTTszVA@mail.gmail.com> Message-ID: <CAA-vtUwJAbTY0ydu5Uwq+HOBVSr53OgRLWrW7P32MtLLTjT48Q@mail.gmail.com> Still need a second reviewer and a sponsor... please. ..Thomas On Wed, Oct 7, 2015 at 4:28 PM, Thomas St?fe <thomas.stuefe at gmail.com> wrote: > Hi, > > please review and sponsor this AIX fix. > > in ResolverConfigurationImpl.c, we may crash because strchr() is used > without prototype, which causes the C compiler to default to an int return > type, which means we loose the upper 32bit of the pointer returned by > strchr(). > > The solution is to include string.h. > > Before, string.h was conditionally included for all platforms but AIX - > reason is not really clear to me. But as strchr() is POSIX and always in > string.h, I included string.h unconditionally for all Unices. > > > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8139037/webrev.00/webrev/ > bug: https://bugs.openjdk.java.net/browse/JDK-8139037 > > Kind Regards, Thomas > From paul.sandoz at oracle.com Tue Oct 13 09:22:35 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 13 Oct 2015 11:22:35 +0200 Subject: Array equality, comparison and mismatch In-Reply-To: <85fedd00040c71eee083030befad0c96@sonic.net> References: <mailman.9142.1444698750.25018.core-libs-dev@openjdk.java.net> <85fedd00040c71eee083030befad0c96@sonic.net> Message-ID: <199FDD06-50C4-47B1-9676-5B6FD0B5E890@oracle.com> > On 13 Oct 2015, at 05:46, Mike Duigou <openjdk at duigou.org> wrote: > >>> - I apologize if this was discussed earlier in the thread but why is the comparison of floats and doubles done by first == operator of the int bits and only then the compare method ? >> I was being consistent with the test used for the existing equals >> methods of float[] and double[]. Note that the Float/Double.*to*Bits >> methods are intrinsic. > > I guess my worry is that the == floatToIntBits would be redundant as the implementation of compare() might have exactly the same test as it's first step--it would be a reasonable optimization since it would have the benefit of loading the values into registers before doing the more expensive relational comparison. > I did not concentrate on this area too much since this code is likely to change, but i just looked a little more closely at some benchmark results and generated code. Analysis so far indicate big gains are to be had on larger arrays with better or no impact on small arrays if i do the following instead: if (Double.doubleToRawLongBits(a[i]) != Double.doubleToRawLongBits(b[i])) { int c = Double.compare(a[i], b[i]); if (c != 0) return c; } (If C2 inlining occurs the registers correspond to the two array elements, e.g. xmm*, should be reused). That gets the NaN checking off the critical path. I think that is reasonable to do given the assumption that varying forms of NaN?s are likely to be rare. That same assumption also applies to Unsafe vectorization which first compares raw bits. Similar modifications can be made to the equals methods. Even though these methods are likely to change i will probably modify the current float/double methods. Better to come out with good performance now if for some reason the unsafe vectorization does not make it in. Thanks, Paul. From aph at redhat.com Tue Oct 13 10:03:36 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 13 Oct 2015 11:03:36 +0100 Subject: Array equality, comparison and mismatch In-Reply-To: <199FDD06-50C4-47B1-9676-5B6FD0B5E890@oracle.com> References: <mailman.9142.1444698750.25018.core-libs-dev@openjdk.java.net> <85fedd00040c71eee083030befad0c96@sonic.net> <199FDD06-50C4-47B1-9676-5B6FD0B5E890@oracle.com> Message-ID: <561CD6F8.5040206@redhat.com> On 13/10/15 10:22, Paul Sandoz wrote: > Analysis so far indicate big gains are to be had on larger arrays with better or no impact on small arrays if i do the following instead: > > if (Double.doubleToRawLongBits(a[i]) != > Double.doubleToRawLongBits(b[i])) { > int c = Double.compare(a[i], b[i]); > if (c != 0) return c; > } I was about to make a similar comment. My experiment was with if (Double.doubleToRawLongBits(a[i]) != Double.doubleToRawLongBits(b[i]) && (Double.doubleToLongBits(a[i]) != Double.doubleToLongBits(b[i]))) return Double.compare(a[i], b[i]); } which is about twice as fast as the original version, as is yours. But yours is more elegant. :-) It's a shame that HotSpot doesn't see through the load of a double and then the conversion through doubleToRawLongBits: it could just load directly into the integer registers. Andrew. From claes.redestad at oracle.com Tue Oct 13 11:26:59 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 13 Oct 2015 13:26:59 +0200 Subject: RFR: JDK-8136893: Improve early java.lang.invoke infrastructure initialization In-Reply-To: <C7FEA5E2-33AC-4D55-B567-321CB7301008@oracle.com> References: <5604EDAE.7080501@gmail.com> <79FDF077-226C-4D7A-A452-7D6447C2FB3F@oracle.com> <D3AE591C-FF34-4337-8932-6990322F32C5@oracle.com> <560565E6.7090000@gmail.com> <C7FEA5E2-33AC-4D55-B567-321CB7301008@oracle.com> Message-ID: <561CEA83.6010105@oracle.com> Hello! On 2015-09-30 12:50, Paul Sandoz wrote: >> On 25 Sep 2015, at 17:19, Peter Levart <peter.levart at gmail.com> wrote: >> >> Hi Paul, >> >> Thanks for looking into this. >> > Apologies for the late reply. > > >> On 09/25/2015 04:07 PM, Paul Sandoz wrote: >>> Hi, >>> >>> This looks like a partial dup of https://bugs.openjdk.java.net/browse/JDK-8076596 >> Ah, sorry, I wasn't aware this has already been registered in JIRA. I have linked the two issues together as DUPs. >> > Thanks. > > >>> The changes look ok, but I am concerned post initialization there may be code paths taken that require the system class loader to be used but instead the boot stream class loader is used instead. Is that a legitimate concern? >> It is legitimate, but I have inspected usages and: >> >> - In java.lang.invoke.BoundMethodHandle.Factory#makeCbmhCtor, null is passed explicitly and this method is used only from java.lang.invoke.BoundMethodHandle.Factory#makeCtors which is used from java.lang.invoke.BoundMethodHandle.SpeciesData#initForBootstrap and java.lang.invoke.BoundMethodHandle.SpeciesData#SpeciesData(java.lang.String, java.lang.Class<? extends java.lang.invoke.BoundMethodHandle>). These usages only deal with erased MH types (Object, long, int, double, float). >> >> - In java.lang.invoke.MemberName#getMethodType, the result of MemberName.getClassLoader() is passed to the method. This is the class loader of the member's declaring class. Any types referenced from the member declaration should be resolvable from this class loader. A member declared by a bootstrap class (MemberName.getClassLoader() returns null) can only reference types resolvable from bootstrap loader. >> >> - In java.lang.invoke.MemberName#getFieldType, the result of MemberName.getClassLoader() is passed to the method. Similar applies as above. >> >> - In java.lang.invoke.MethodHandleNatives#fixMethodType(Class<?> callerClass, Object type), the callerClass.getClassLoader() is passed to the method. This is invoked from: >> java.lang.invoke.MethodHandleNatives#linkMethodImpl( >> Class<?> callerClass, int refKind, >> Class<?> defc, String name, Object type, >> Object[] appendixResult) >> which is called from java.lang.invoke.MethodHandleNatives#linkMethod(same args) >> >> I suppose this is an upcall from VM to link a call to the @PolymorphicSignature method and callerClass is the class in which the invocation bytecodes are executed. Am I right? > Yes. > > And before that there is an upcall to MethodHandleNatives.findMethodHandleType, see SystemDictionary::find_method_handle_invoker in src/share/vm/classfile/systemDictionary.cpp. > > AFAICT the ?type? argument passed to the linkMethod should always be of MethodType: > > static MemberName linkMethod(Class<?> callerClass, int refKind, > Class<?> defc, String name, Object type, > Object[] appendixResult) { > if (!TRACE_METHOD_LINKAGE) > return linkMethodImpl(callerClass, refKind, defc, name, type, appendixResult); > return linkMethodTracing(callerClass, refKind, defc, name, type, appendixResult); > } > static MemberName linkMethodImpl(Class<?> callerClass, int refKind, > Class<?> defc, String name, Object type, > Object[] appendixResult) { > try { > if (defc == MethodHandle.class && refKind == REF_invokeVirtual) { > return Invokers.methodHandleInvokeLinkerMethod(name, fixMethodType(callerClass, type), appendixResult); > } > } catch (Throwable ex) { > if (ex instanceof LinkageError) > throw (LinkageError) ex; > else > throw new LinkageError(ex.getMessage(), ex); > } > throw new LinkageError("no such method "+defc.getName()+"."+name+type); > } > private static MethodType fixMethodType(Class<?> callerClass, Object type) { > if (type instanceof MethodType) > return (MethodType) type; > else > return MethodType.fromMethodDescriptorString((String)type, callerClass.getClassLoader()); > } > > Thus it seems fixMethodType is not necessary. I think this is confirmed when looking at up calls to linkMethodHandleConstant and linkCallSite. +1 - this should be a separate cleanup, though. > >> The reasoning is as follows: if callerClass.getClassLoader() is sufficient for resolving types that appear at the call site in a non-bootstrap callerClass, then bootstrap classloader should be sufficient to resolve types that appear at the call site in a bootstrap callerClass. Does anybody have any other opinion? >> >> - sun.invoke.util.BytecodeDescriptor#parseMethod(java.lang.String, java.lang.ClassLoader) is only used from the newly introduced java.lang.invoke.MethodType#fromDescriptor >> > Ok, i think you have things covered, thanks, I believe you meant "Ship it!"? :-) /Claes > Paul. From paul.sandoz at oracle.com Tue Oct 13 11:47:35 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 13 Oct 2015 13:47:35 +0200 Subject: RFR: JDK-8136893: Improve early java.lang.invoke infrastructure initialization In-Reply-To: <561CEA83.6010105@oracle.com> References: <5604EDAE.7080501@gmail.com> <79FDF077-226C-4D7A-A452-7D6447C2FB3F@oracle.com> <D3AE591C-FF34-4337-8932-6990322F32C5@oracle.com> <560565E6.7090000@gmail.com> <C7FEA5E2-33AC-4D55-B567-321CB7301008@oracle.com> <561CEA83.6010105@oracle.com> Message-ID: <823A8B73-F2D1-4584-841E-2E9215799E2F@oracle.com> > On 13 Oct 2015, at 13:26, Claes Redestad <claes.redestad at oracle.com> wrote: >> >> Thus it seems fixMethodType is not necessary. I think this is confirmed when looking at up calls to linkMethodHandleConstant and linkCallSite. > > +1 - this should be a separate cleanup, though. > Yes. >> >>> The reasoning is as follows: if callerClass.getClassLoader() is sufficient for resolving types that appear at the call site in a non-bootstrap callerClass, then bootstrap classloader should be sufficient to resolve types that appear at the call site in a bootstrap callerClass. Does anybody have any other opinion? >>> >>> - sun.invoke.util.BytecodeDescriptor#parseMethod(java.lang.String, java.lang.ClassLoader) is only used from the newly introduced java.lang.invoke.MethodType#fromDescriptor >>> >> Ok, i think you have things covered, thanks, > > I believe you meant "Ship it!"? :-) > Indeed! Paul. From peter.levart at gmail.com Tue Oct 13 12:01:51 2015 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 13 Oct 2015 14:01:51 +0200 Subject: RFR: JDK-8136893: Improve early java.lang.invoke infrastructure initialization In-Reply-To: <823A8B73-F2D1-4584-841E-2E9215799E2F@oracle.com> References: <5604EDAE.7080501@gmail.com> <79FDF077-226C-4D7A-A452-7D6447C2FB3F@oracle.com> <D3AE591C-FF34-4337-8932-6990322F32C5@oracle.com> <560565E6.7090000@gmail.com> <C7FEA5E2-33AC-4D55-B567-321CB7301008@oracle.com> <561CEA83.6010105@oracle.com> <823A8B73-F2D1-4584-841E-2E9215799E2F@oracle.com> Message-ID: <561CF2AF.1060807@gmail.com> On 10/13/2015 01:47 PM, Paul Sandoz wrote: >> On 13 Oct 2015, at 13:26, Claes Redestad <claes.redestad at oracle.com> wrote: >>> Thus it seems fixMethodType is not necessary. I think this is confirmed when looking at up calls to linkMethodHandleConstant and linkCallSite. >> +1 - this should be a separate cleanup, though. >> > Yes. > > >>>> The reasoning is as follows: if callerClass.getClassLoader() is sufficient for resolving types that appear at the call site in a non-bootstrap callerClass, then bootstrap classloader should be sufficient to resolve types that appear at the call site in a bootstrap callerClass. Does anybody have any other opinion? >>>> >>>> - sun.invoke.util.BytecodeDescriptor#parseMethod(java.lang.String, java.lang.ClassLoader) is only used from the newly introduced java.lang.invoke.MethodType#fromDescriptor >>>> >>> Ok, i think you have things covered, thanks, >> I believe you meant "Ship it!"? :-) >> > Indeed! > > Paul. Ok, thanks Paul, Michael and Claes! I'll push it later today or early tomorrow after running some more tests (nashorn for example). If anybody else wants to comment, there's still some time (for example about the name of the package-private method)... Regards, Peter From daniel.fuchs at oracle.com Tue Oct 13 12:14:19 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 13 Oct 2015 14:14:19 +0200 Subject: RFR: JDK-8046565: Platform Logging API and Service In-Reply-To: <D3BC77EA-30F5-4EB4-93D0-16F4D9D926B5@oracle.com> References: <561660DA.7070900@oracle.com> <56181B57.2010801@oracle.com> <D3BC77EA-30F5-4EB4-93D0-16F4D9D926B5@oracle.com> Message-ID: <561CF59B.8000305@oracle.com> Hi Mandy, Thanks a lot for your feedback! On 13/10/15 04:50, Mandy Chung wrote: > Hi Daniel, > >> On Oct 9, 2015, at 12:53 PM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote: >> >> JEP: >> http://openjdk.java.net/jeps/264 >> https://bugs.openjdk.java.net/browse/JDK-8046565 >> >> specdiff: >> http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/specdiff-api/overview-summary.html >> >> webrev: >> http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/webrev.01/ > > > This is very good work. I?m glad to see this work that enables the dependency on java.logging be eliminated. The sun.util.logging.PlatformLogger was a stop-gap approach. > > There are many new tests that I will need time to review them all. I tried to split the tests into tests that only test the public API, and tests that are implementation dependent: those also access the internals or test the internal artifacts that the implementation is using. The split may not be obvious at the first glance - but tests under 'internal' or 'jdk' subdirs are implementation specific. The other tests should not use internal APIs. I have tried to convey the intent of the test in the @summary tag, and those tests that are implementation specific say so in their summary. > I?m going to pass you my comments in several batches. This is the first batch. > > LogManager.java > 1938 if (caller.getClassLoader() == null) { > 1939 return LogManager.getLogManager().demandSystemLogger(name, > 1940 Logger.SYSTEM_LOGGER_RB_NAME, caller); > > This only considers the classes loaded by the boot loader as system classes. We have deprivileged several modules to be loaded by the ext class loader such as JAX-WS, JAXB, CORBA etc. Loggers created by modules loaded by boot and ext class loader should be system. Right. I agree. But I also think this is orthogonal to this JEP implementation. Would you agree to handle that in a separate JBS issue (probably more 'Bug' than 'RFE')? > In the absence of java.logging, the default provider implementation will be used to print the log messages to System.err. This is useful since most JDK log messages are for debugging. I expect that a component may want to turn on debug messages without requiring the presence of java.logging. > > Is there any mechanism to change the default level of the default simple console loggers? It may be useful; otherwise it would need to run on an image with java.logging module. Maybe something to add in the future. There isn't at this time. We could add for instance a global system property that would allow to define the 'default level' for all SimpleConsoleLogger. Something like '-Djdk.loggers.level.default=DEBUG' which would have an effect similar to setting the root logger level .level=FINE in the default configuration. The question then is whether that property would only be used when java.logging is not present, or whether the LogManager should be modified to take this into account too - and whether it would have precedence over what is in the configuration (default or not)... Possibly something to handle in a second time. Should I add a subtask to JDK-8046565 - to log an RFE about that after the initial implementation gets in? > System.Logger > 964 * Unless > - incomplete sentence? Thanks for catching that. I'd been considering adding some kind of global blanket statement for the throwing of NullPointerException, then decided against it but forgot I had started writing the sentence... I will remove this line. > 1697 * @implSpec > 1698 * Instances returned by this method route messages to loggers > 1699 * obtained by calling {@link LoggerFinder#getLogger(java.lang.String, java.lang.Class) > 1700 * LoggerFinder.getLogger(name, ca > > Is this intended to be implementation specification but not API spec? It's intended to be an API spec that the messages should be routed to loggers obtained from LoggerFinder.getLogger(name, caller). Whether the logger returned is directly the logger obtained, or a wrapper, and at which point exactly the 'real' logger will be created is implementation dependent. I think we need to have a bit of freedom here to deal with bootstrap issues according to the needs of the modules in the JDK. > RuntimePermission(?LoggerFinder) is required in the provider constructor. > - is it time to define a ServiceProviderPermission for provider constructor security permission check? Rather than overloading RuntimePermission If there was a ServiceProviderPermission I would use it, but I don't think this JEP should introduce it. We could log another RFE for that. > public static final RuntimePermission LOGGERFINDER_PERMISSION = > new RuntimePermission("loggerFinder?); > - is there any need to define this constant? Suggest this be implementation-details. This was mostly temporary convenience for me - until I'm sure I won't get further feedback that the name should be changed. Avoids copy/paste typo mistakes and spending time debugging it. If you think it would be better to not define such a constant, then I agree to remove it in the final API. Should I had a subtask to the JEP to get this removed, so that it's not forgotten? > private LoggerFinderLoader() { > throw new InternalError("LoggerFinderLoader cannot be instantiated"); > } > - is throwing InternalError necessary? No one else except its enclosing class can construct it. It clearly indicates that it should not be instantiated. I like it :-) > JdkLoggingProvider::LOGGING_CONTROL_PERMISSION > - I think this field is unused. Thanks. Removed. > sun/management/ManagementFactoryHelper.java > - Is LoggingMXBeanSupport intended to get java.management to remove its dependency on java.logging? > > 172 public interface LoggingMXBean > 173 extends PlatformLoggingMXBean, java.util.logging.LoggingMXBean { > 174 } > > This static dependency will still keep the dependency on java.logging. Yes. I have been scratching my head trying to figure out how to remove it. If at some point we change java.management to use System.Logger instead of java.util.logging.Logger, then we will still need to specify that java.management requires java.logging - because of this. Maybe we can find a clever way to deprecate this and use ServiceLoader to load the LogginMXBean implementation. That would be preferable to the reflection tricks I had to add here, but it might not be a trivial task. However the code I added to guard the uses of PlatformLoggingImpl and ManagemetFactoryHelper.LoggingMXBean should make it possible to use java.management without java.logging - in the hypothesis where java.management would be migrated to use System.Logger. Though of course I haven't tested it. Anyway - that's something for later. best regards, -- daniel > > Mandy > From vladimir.x.ivanov at oracle.com Tue Oct 13 12:18:59 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 13 Oct 2015 15:18:59 +0300 Subject: RFR: JDK-8136893: Improve early java.lang.invoke infrastructure initialization In-Reply-To: <561CF2AF.1060807@gmail.com> References: <5604EDAE.7080501@gmail.com> <79FDF077-226C-4D7A-A452-7D6447C2FB3F@oracle.com> <D3AE591C-FF34-4337-8932-6990322F32C5@oracle.com> <560565E6.7090000@gmail.com> <C7FEA5E2-33AC-4D55-B567-321CB7301008@oracle.com> <561CEA83.6010105@oracle.com> <823A8B73-F2D1-4584-841E-2E9215799E2F@oracle.com> <561CF2AF.1060807@gmail.com> Message-ID: <561CF6B3.5030604@oracle.com> Peter, > Ok, thanks Paul, Michael and Claes! I'll push it later today or early > tomorrow after running some more tests (nashorn for example). If anybody > else wants to comment, there's still some time (for example about the > name of the package-private method)... I'm late to the party :-) Don't worry, looks good to me as well. Thanks for taking care of the bug! Best regards, Vladimir Ivanov From Roger.Riggs at Oracle.com Tue Oct 13 12:53:47 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 13 Oct 2015 08:53:47 -0400 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <84606140.785696.1444723918802.JavaMail.zimbra@u-pem.fr> References: <560D3F61.6040607@Oracle.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <B095DF43-4186-4E3D-90B8-91F17B4788DF@oracle.com> <84606140.785696.1444723918802.JavaMail.zimbra@u-pem.fr> Message-ID: <561CFEDB.2060601@Oracle.com> Hi Remi, That was the initial implementation. However, it was being invoked during startup before Lambda was initialized and resulted in an ExceptionInInitializer. We don't have a good handle on when it is too early to use lambda except by trial and error. I think there are some improvements in the works so that some simple cases of Lambda can be used earlier and will see if they apply. Thanks, Roger On 10/13/2015 4:11 AM, Remi Forax wrote: > Hi Roger, > > I agree with comments from Mark and Mandy, > you can also simplify your code by using a lambda instead of a class to implement the thread factory. > > public static Cleaner create() { > return create(runnable -> { > return AccessController.doPrivileged((PrivilegedAction<Thread>) () -> { > Thread t = new InnocuousThread(runnable); > t.setName("Cleaner-" + t.getId()); > return t; > }); > }); > } > > given that the lambda (the one that takes a Runnable) doesn't capture anything, > it will be considered as a constant by the VM, so no need to implement the singleton pattern, here. > > cheers, > R?mi > > ----- Mail original ----- >> De: "Mandy Chung" <mandy.chung at oracle.com> >> ?: "mark reinhold" <mark.reinhold at oracle.com> >> Cc: core-libs-dev at openjdk.java.net >> Envoy?: Mardi 13 Octobre 2015 03:12:26 >> Objet: Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization >> >> >>> On Oct 12, 2015, at 12:30 PM, mark.reinhold at oracle.com wrote: >>> >>> 2015/10/8 1:41 -0700, roger.riggs at oracle.com: >>>> Webrev: >>>> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-extensible-8138696/ >>>> >>>> javadoc: >>>> http://cr.openjdk.java.net/~rriggs/cleaner-doc2/ >>> Roger -- thanks for taking this on. The more we can do to get people >>> to stop using sun.misc APIs, the better. >>> >>> A couple of comments/questions: >>> >>> First, I think the approach in your first version is, well, cleaner. >> +1 >> >> I started reviewing the first version and pondering on the benefits of the >> new versions. >> >> >>> The additional abstract classes in the second version look like a >>> classic case of implementation inheritance that's not subtype >>> inheritance, what with the overrides of the original enqueue and >>> isEnqueued methods to throw UnsupportedOperationException. >>> >>> I understand the desire to avoid allocating too many objects, but >>> do we have actual use cases where that's critical? The original >>> sun.misc.Cleaner has been used by both internal and external code >>> to do relatively heavy-weight things like unmap direct buffers and >>> release other kinds of native resources, which suggests that >>> allocating three small objects per cleaner is not a problem. >>> >>> Second, the original sun.misc.Cleaner only handles phantom references. >>> What are the use cases for weak and soft cleaners? >>> >>> Finally, how important is it to be able to unregister a cleaner? In >>> all the years we've had sun.misc.Cleaner that capability has never >>> been needed, and leaving it out would simplify the API. >> If there is no strong need of unregister a cleaner, Cleaner API won?t need to >> return a Cleanable object which I think it?s nice and simpler. >> >> Mandy >> >> From Roger.Riggs at Oracle.com Tue Oct 13 13:56:03 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 13 Oct 2015 09:56:03 -0400 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <20151012123016.566133@eggemoggin.niobe.net> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> Message-ID: <561D0D73.7080006@Oracle.com> Hi Mark, Thanks for the review and comments. On 10/12/2015 3:30 PM, mark.reinhold at oracle.com wrote: > 2015/10/8 1:41 -0700, roger.riggs at oracle.com: >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-extensible-8138696/ >> >> javadoc: >> http://cr.openjdk.java.net/~rriggs/cleaner-doc2/ > Roger -- thanks for taking this on. The more we can do to get people > to stop using sun.misc APIs, the better. > > A couple of comments/questions: > > First, I think the approach in your first version is, well, cleaner. > The additional abstract classes in the second version look like a > classic case of implementation inheritance that's not subtype > inheritance, what with the overrides of the original enqueue and > isEnqueued methods to throw UnsupportedOperationException. The simple use is preferred for most uses and is present using only the Cleaner. Collapsing into a single instance provided some benefits in the size too, fewer object headers and references between them. It seemed safer for evolutionary purposes to expose only the necessary Cleanup functions and hide or disable the rest. > > I understand the desire to avoid allocating too many objects, but > do we have actual use cases where that's critical? The original > sun.misc.Cleaner has been used by both internal and external code > to do relatively heavy-weight things like unmap direct buffers and > release other kinds of native resources, which suggests that > allocating three small objects per cleaner is not a problem. The reduction in the number of objects was an opportunity to look closely at what was needed and the use cases where it would be applied. Peter's email gives a few detailed cases where this would be used. When considering how to update the existing classes with finalize methods, it became clear that refactoring would be needed to separate out the state needed for the cleanup from public object that was being finalized into a separate object it would provide the cleanup behavior as well. In simple cases, it is just a copy of the native address or file descriptor. In other cases, like FileIn/OutputStream it is references to other objects. In cases like FileDescriptor and Zip streams the cleanup state is not just a native resource. The abstract XXXCleanup types make it easy to encapsulate the needed behavior and state. > > Second, the original sun.misc.Cleaner only handles phantom references. > What are the use cases for weak and soft cleaners? WeakReferences are sometimes used but since it is extra coding to clean them it tends not to be implemented. For example, sun.beans.WeakCache; it was just not worth the code to handle the weak refs completely. In another case, the ldap connection pool only cleans up connections when opening a new pooled connection. Having easy to use and more active cleanup would release resources sooner and reduce overall resource requirements. > > Finally, how important is it to be able to unregister a cleaner? In > all the years we've had sun.misc.Cleaner that capability has never > been needed, and leaving it out would simplify the API. Recently there was a long discussion on core-libs [1] about making the cleanup of MappedByteBuffers more timely to free up the memory sooner. If there was an explicit release operation on either of those, then the cleaner would want to be unregistered or it would need to be at-most-once. Encapsulating the cleanup state and behavior allows it to be invoked consistently both when the object is closed or is found to be unreachable. The cleanup code is not repeated, and it is easy to ensure that is invoked at most once. The other important aspect is that when the cleanup is performed explicitly (on close) the ref is cleared and the overhead associated with reference processing is eliminated. Currently, with finalizers, the finalizable refs still have to be processed, even if object has been closed. Thanks, Roger [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035055.html > > - Mark From daniel.fuchs at oracle.com Tue Oct 13 14:10:18 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 13 Oct 2015 16:10:18 +0200 Subject: RFR: 8073519: schemagen does not report errors while generating xsd files In-Reply-To: <56182D01.7000203@oracle.com> References: <56182D01.7000203@oracle.com> Message-ID: <561D10CA.6020201@oracle.com> Hi Aleksej, This looks good to me. Some blank lines in the test might make it more readable ;-) best regards, -- daniel On 09/10/15 23:09, Aleksej Efimov wrote: > Hello, > > Please, review the fix for schemagen regression bug [1] in JDK9: The > JDK9 (and JDK8 too) version of schemagen doesn't report errors during > the compilation of the input java file. > The issue was introduced by standalone JAXB project changes and then it > was synced to JDK source. The SchemaGenerator class was changed to use > javax.tools.JavaCompiler (instead of com.sun.tools.apt.process), but the > diagnostic information generated by javac was silently ignored. > The proposed patch solves the reported problem: > http://cr.openjdk.java.net/~aefimov/8073519/9/00/ > The generated messages with fix applied is the same as in JDK7 - same as > was before mentioned changes. > > The proposed fix is already integrated to standalone JAXB project and > identical to the proposed source changes. Testing shows no failures with > schemagen tool. > > With Best Regards, > Aleksej > > [1] https://bugs.openjdk.java.net/browse/JDK-8073519 From vyom.tewari at oracle.com Thu Oct 15 02:23:20 2015 From: vyom.tewari at oracle.com (vyom) Date: Thu, 15 Oct 2015 02:23:20 +0000 Subject: RFR 8068887 : java.lang.Throwable could use Collections.emptyList for suppressedException In-Reply-To: <9411EB09-AE2C-4A7A-A6E9-E9B44F5E030A@oracle.com> References: <561BCD19.9060408@oracle.com> <9411EB09-AE2C-4A7A-A6E9-E9B44F5E030A@oracle.com> Message-ID: <561F0E18.10006@oracle.com> Hi All, Please find the updated code, i fixed the missing space. http://cr.openjdk.java.net/~vtewari/8068887/webrev.0.1/webrev/ <http://cr.openjdk.java.net/%7Evtewari/8068887/webrev.0.1/webrev/> there are 3 less class loaded(455 vs 452) for simple hello world program.I just simply count numbers of lines in output so actual loaded classes may differ but difference will remain same. Please find below the diff ####################################### diff withfix.txt wfix.txt 217a218 > [Loaded java.util.ArrayList from /home/vytewari/source/jdk/jdk9/build/linux-x86_64-normal-server-release/jdk/modules/java.base] 223a225,227 > [Loaded java.util.Collections$UnmodifiableCollection from /home/vytewari/source/jdk/jdk9/build/linux-x86_64-normal-server-release/jdk/modules/java.base] > [Loaded java.util.Collections$UnmodifiableList from /home/vytewari/source/jdk/jdk9/build/linux-x86_64-normal-server-release/jdk/modules/java.base] > [Loaded java.util.Collections$UnmodifiableRandomAccessList from /home/vytewari/source/jdk/jdk9/build/linux-x86_64-normal-server-release/jdk/modules/java.base] 357d360 < [Loaded java.util.ArrayList from /home/vytewari/source/jdk/jdk9/build/linux-x86_64-normal-server-release/jdk/modules/java.base] ####################################### Thanks, Vyom On Monday 12 October 2015 04:54 PM, Mandy Chung wrote: >> On Oct 12, 2015, at 8:09 AM, Vyom Tewari <vyom.tewari at oracle.com> wrote: >> >> Hi All, >> >> Please review my changes for below bug. >> >> Bug: JDK-8068887 : java.lang.Throwable could use Collections.emptyList for suppressedException >> Webrev: http://cr.openjdk.java.net/~vtewari/8068887/webrev.00/webrev/ >> >> This change ensure that fewer classes are loaded in a simple(hello world) program, and thus a very very small start-up footprint improvement. > Looks okay to me (as Alan pointed out, a space is missing in ?=Collections.emptyList?. I?m curious to see the diff of -verbose:class before and after. > > Mandy > From forax at univ-mlv.fr Tue Oct 13 14:34:33 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 13 Oct 2015 16:34:33 +0200 (CEST) Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <561CFEDB.2060601@Oracle.com> References: <560D3F61.6040607@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <B095DF43-4186-4E3D-90B8-91F17B4788DF@oracle.com> <84606140.785696.1444723918802.JavaMail.zimbra@u-pem.fr> <561CFEDB.2060601@Oracle.com> Message-ID: <2097766342.1033200.1444746873499.JavaMail.zimbra@u-pem.fr> I see, I have seen the lambda used by doPrivileged and stupidly thunk it will be Ok to encapulate it in another lambda but because there are not called at the same time, we can't do that. cheers, R?mi ----- Mail original ----- > De: "Roger Riggs" <Roger.Riggs at Oracle.com> > ?: core-libs-dev at openjdk.java.net > Envoy?: Mardi 13 Octobre 2015 14:53:47 > Objet: Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization > > Hi Remi, > > That was the initial implementation. However, it was being invoked > during startup before Lambda was initialized and resulted in an > ExceptionInInitializer. > > We don't have a good handle on when it is too early to use lambda except > by trial and error. > I think there are some improvements in the works so that some simple > cases of Lambda > can be used earlier and will see if they apply. > > Thanks, Roger > > > > On 10/13/2015 4:11 AM, Remi Forax wrote: > > Hi Roger, > > > > I agree with comments from Mark and Mandy, > > you can also simplify your code by using a lambda instead of a class to > > implement the thread factory. > > > > public static Cleaner create() { > > return create(runnable -> { > > return AccessController.doPrivileged((PrivilegedAction<Thread>) () > > -> { > > Thread t = new InnocuousThread(runnable); > > t.setName("Cleaner-" + t.getId()); > > return t; > > }); > > }); > > } > > > > given that the lambda (the one that takes a Runnable) doesn't capture > > anything, > > it will be considered as a constant by the VM, so no need to implement the > > singleton pattern, here. > > > > cheers, > > R?mi > > > > ----- Mail original ----- > >> De: "Mandy Chung" <mandy.chung at oracle.com> > >> ?: "mark reinhold" <mark.reinhold at oracle.com> > >> Cc: core-libs-dev at openjdk.java.net > >> Envoy?: Mardi 13 Octobre 2015 03:12:26 > >> Objet: Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use > >> alternative to finalization > >> > >> > >>> On Oct 12, 2015, at 12:30 PM, mark.reinhold at oracle.com wrote: > >>> > >>> 2015/10/8 1:41 -0700, roger.riggs at oracle.com: > >>>> Webrev: > >>>> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-extensible-8138696/ > >>>> > >>>> javadoc: > >>>> http://cr.openjdk.java.net/~rriggs/cleaner-doc2/ > >>> Roger -- thanks for taking this on. The more we can do to get people > >>> to stop using sun.misc APIs, the better. > >>> > >>> A couple of comments/questions: > >>> > >>> First, I think the approach in your first version is, well, cleaner. > >> +1 > >> > >> I started reviewing the first version and pondering on the benefits of the > >> new versions. > >> > >> > >>> The additional abstract classes in the second version look like a > >>> classic case of implementation inheritance that's not subtype > >>> inheritance, what with the overrides of the original enqueue and > >>> isEnqueued methods to throw UnsupportedOperationException. > >>> > >>> I understand the desire to avoid allocating too many objects, but > >>> do we have actual use cases where that's critical? The original > >>> sun.misc.Cleaner has been used by both internal and external code > >>> to do relatively heavy-weight things like unmap direct buffers and > >>> release other kinds of native resources, which suggests that > >>> allocating three small objects per cleaner is not a problem. > >>> > >>> Second, the original sun.misc.Cleaner only handles phantom references. > >>> What are the use cases for weak and soft cleaners? > >>> > >>> Finally, how important is it to be able to unregister a cleaner? In > >>> all the years we've had sun.misc.Cleaner that capability has never > >>> been needed, and leaving it out would simplify the API. > >> If there is no strong need of unregister a cleaner, Cleaner API won?t need > >> to > >> return a Cleanable object which I think it?s nice and simpler. > >> > >> Mandy > >> > >> > > From Roger.Riggs at Oracle.com Tue Oct 13 14:40:45 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 13 Oct 2015 10:40:45 -0400 Subject: ChronoUnit.FOREVER javadoc talks about era In-Reply-To: <20151012184510.00007bfc.ecki@zusammenkunft.net> References: <20151012184510.00007bfc.ecki@zusammenkunft.net> Message-ID: <561D17ED.3030803@Oracle.com> Thanks, created a bug report for this: https://bugs.openjdk.java.net/browse/JDK-8139529 Roger On 10/12/2015 12:45 PM, Bernd Eckenfels wrote: > It might be intentional or a copy+paste thing, the javadoc of FOREVER > reads: > > "... The estimated duration of the era is artificially defined as the > largest duration supported by Duration." > > Since this fragment of the sentence is also describing ERA i suspect > its a copy+paste problem, it can be reworded in: > > The estimated duration of this unit is artificially defined as the > largest duration supported by @{link Duration}. > > Greetings > Bernd From mandy.chung at oracle.com Tue Oct 13 15:39:04 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 13 Oct 2015 08:39:04 -0700 Subject: RFR 8068887 : java.lang.Throwable could use Collections.emptyList for suppressedException In-Reply-To: <561F0E18.10006@oracle.com> References: <561BCD19.9060408@oracle.com> <9411EB09-AE2C-4A7A-A6E9-E9B44F5E030A@oracle.com> <561F0E18.10006@oracle.com> Message-ID: <157A7676-F207-4274-A9BD-3DAE47E1E39E@oracle.com> > On Oct 14, 2015, at 7:23 PM, vyom <vyom.tewari at oracle.com> wrote: > > Hi All, > > Please find the updated code, i fixed the missing space. > > http://cr.openjdk.java.net/~vtewari/8068887/webrev.0.1/webrev/ <http://cr.openjdk.java.net/%7Evtewari/8068887/webrev.0.1/webrev/> > Looks fine. > there are 3 less class loaded(455 vs 452) for simple hello world program. > : Thanks. Mandy From mandy.chung at oracle.com Tue Oct 13 15:55:02 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 13 Oct 2015 08:55:02 -0700 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <561CC149.4080203@gmail.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <B095DF43-4186-4E3D-90B8-91F17B4788DF@oracle.com> <561CC149.4080203@gmail.com> Message-ID: <7C7F630D-CDA4-4AFA-BFDC-2908D53CB9D6@oracle.com> > On Oct 13, 2015, at 1:31 AM, Peter Levart <peter.levart at gmail.com> wrote: > > There is one usage of sun.misc.Cleaner.clean() in JavaFX, I think. The only one I know is to invoke the cleaner of the DirectBuffer (are you referring to that)? I can?t find any usage of sun.misc.Cleaner to create its own Cleaner (sun.misc.Cleaner was used in older version of JavaFX but AFAIK they are replaced with phantom references). Mandy From mandy.chung at oracle.com Tue Oct 13 16:53:26 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 13 Oct 2015 09:53:26 -0700 Subject: RFR: JDK-8046565: Platform Logging API and Service In-Reply-To: <561CF59B.8000305@oracle.com> References: <561660DA.7070900@oracle.com> <56181B57.2010801@oracle.com> <D3BC77EA-30F5-4EB4-93D0-16F4D9D926B5@oracle.com> <561CF59B.8000305@oracle.com> Message-ID: <A3748366-B9A6-422E-B1F8-0C3CF6A18FE1@oracle.com> > On Oct 13, 2015, at 5:14 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote: > > Hi Mandy, > > > Thanks a lot for your feedback! > > On 13/10/15 04:50, Mandy Chung wrote: >> >> >> There are many new tests that I will need time to review them all. > > : My typo s/new tests/new classes/ > >> I?m going to pass you my comments in several batches. This is the first batch. >> >> LogManager.java >> 1938 if (caller.getClassLoader() == null) { >> 1939 return LogManager.getLogManager().demandSystemLogger(name, >> 1940 Logger.SYSTEM_LOGGER_RB_NAME, caller); >> >> This only considers the classes loaded by the boot loader as system classes. We have deprivileged several modules to be loaded by the ext class loader such as JAX-WS, JAXB, CORBA etc. Loggers created by modules loaded by boot and ext class loader should be system. > > Right. I agree. But I also think this is orthogonal to this > JEP implementation. Would you agree to handle that in a separate > JBS issue (probably more 'Bug' than 'RFE?)? I recalled you specify this in the specification. I prefer this to be handled at the moment. I currently focus on reviewing the implementation. I will re-comment on this point. > >> In the absence of java.logging, the default provider implementation will be used to print the log messages to System.err. This is useful since most JDK log messages are for debugging. I expect that a component may want to turn on debug messages without requiring the presence of java.logging. >> >> Is there any mechanism to change the default level of the default simple console loggers? It may be useful; otherwise it would need to run on an image with java.logging module. Maybe something to add in the future. > > There isn't at this time. We could add for instance a global system > property that would allow to define the 'default level' for all > SimpleConsoleLogger. Something like '-Djdk.loggers.level.default=DEBUG' > which would have an effect similar to setting the root logger level > .level=FINE in the default configuration. > The question then is whether that property would only be used > when java.logging is not present, or whether the LogManager should > be modified to take this into account too - and whether it would have > precedence over what is in the configuration (default or not)... > > Possibly something to handle in a second time. Should I add a subtask > to JDK-8046565 - to log an RFE about that after the initial > implementation gets in? That?d be good. > >> System.Logger >> 964 * Unless >> - incomplete sentence? > > Thanks for catching that. I'd been considering adding some kind of > global blanket statement for the throwing of NullPointerException, > then decided against it but forgot I had started writing the sentence... > I will remove this line. > > >> 1697 * @implSpec >> 1698 * Instances returned by this method route messages to loggers >> 1699 * obtained by calling {@link LoggerFinder#getLogger(java.lang.String, java.lang.Class) >> 1700 * LoggerFinder.getLogger(name, ca >> >> Is this intended to be implementation specification but not API spec? > > It's intended to be an API spec that the messages should be routed > to loggers obtained from LoggerFinder.getLogger(name, caller). You can take out @implSpec in that case. > > Whether the logger returned is directly the logger obtained, or > a wrapper, and at which point exactly the 'real' logger will be created > is implementation dependent. I think we need to have a bit of freedom > here to deal with bootstrap issues according to the needs of the > modules in the JDK. > >> RuntimePermission(?LoggerFinder) is required in the provider constructor. >> - is it time to define a ServiceProviderPermission for provider constructor security permission check? Rather than overloading RuntimePermission > > If there was a ServiceProviderPermission I would use it, but I > don't think this JEP should introduce it. We could log another > RFE for that. > I don?t see any issue of defining the permission type. I also have to understand other permission checks required for the provider implementation and may be an option to use a new permission specific to logger finder. Stay tuned. > >> public static final RuntimePermission LOGGERFINDER_PERMISSION = >> new RuntimePermission("loggerFinder?); >> - is there any need to define this constant? Suggest this be implementation-details. > > This was mostly temporary convenience for me - until I'm sure > I won't get further feedback that the name should be changed. > Avoids copy/paste typo mistakes and spending time debugging it. > If you think it would be better to not define such a constant, > then I agree to remove it in the final API. My take is that custom provider implementation can construct this instance themselves. You can define this constant as implementation. > Should I had a subtask to the JEP to get this removed, so that > it's not forgotten? > Are you thinking this is an API change? If you plan to address this in the first integration of this JEP, there is no need to file a subtask. It?s up to you if you prefer filing a subtask tracking the review comments for your own use. > >> private LoggerFinderLoader() { >> throw new InternalError("LoggerFinderLoader cannot be instantiated"); >> } >> - is throwing InternalError necessary? No one else except its enclosing class can construct it. > > It clearly indicates that it should not be instantiated. > I like it :-) Maybe assert is what you should consider. Static factory classes have an empty private constructor which is a clear idiom IMO. Mandy From chris.hegarty at oracle.com Tue Oct 13 19:06:43 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 13 Oct 2015 20:06:43 +0100 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <560D3F61.6040607@Oracle.com> References: <560D3F61.6040607@Oracle.com> Message-ID: <B772931E-00A9-402B-8AD2-DD5E23BBD82C@oracle.com> On 1 Oct 2015, at 15:12, Roger Riggs <Roger.Riggs at oracle.com> wrote: > ?. > > Javadoc: > http://cr.openjdk.java.net/~rriggs/cleaner-doc/ > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ This is nice addition. Some comments / questions: 1) Should the behaviour, TCCL, permissions, etc, for the default thread factory be specified in an apiNote? 2) threadFactory.newThread() is only ever called once? Is this worth a note? Or potentially limiting to some other implementation. 3) So the thunk runs with the intersection of the permissions that are associated with the thunk and the thread?s protection domain, regardless of the caller, right? -Chris From scolebourne at joda.org Tue Oct 13 20:43:28 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 13 Oct 2015 21:43:28 +0100 Subject: Optional.or name <was> Re: RFR 8080418 Add Optional.or() In-Reply-To: <C8CBC8A5-BF87-4560-880A-29A13E376DB6@oracle.com> References: <2C9C9A31-7AA0-47CC-B17A-35A7188F4F8B@oracle.com> <C8CBC8A5-BF87-4560-880A-29A13E376DB6@oracle.com> Message-ID: <CACzrW9DxAo7b33OFhFOsMtiUY-1Upq3RERbuTNPUUb2JHD20ng@mail.gmail.com> On 12 October 2015 at 08:48, Paul Sandoz <paul.sandoz at oracle.com> wrote: > Now that the overall documentation changes and functional behaviour of Optional.or has been agreed i would like to see if we can find a better name, suggestions welcome, so lets get our paint brushes out :-) "or" seems reasonable for this method. "If a value is present, returns an {@code Optional} describing the value, otherwise returns an {@code Optional} produced by the supplying function." I'd prefer to see "this" mentioned: "If a value is not present, invoke the specified supplier to provide the result, otherwise return {@code this}" While I understand the original form gave some spec wiggle room, it also made the method far more mysterious. Stephen From Roger.Riggs at Oracle.com Tue Oct 13 20:56:53 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 13 Oct 2015 16:56:53 -0400 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <B772931E-00A9-402B-8AD2-DD5E23BBD82C@oracle.com> References: <560D3F61.6040607@Oracle.com> <B772931E-00A9-402B-8AD2-DD5E23BBD82C@oracle.com> Message-ID: <561D7015.2060307@Oracle.com> Hi Chris, Thanks for the comments... On 10/13/2015 3:06 PM, Chris Hegarty wrote: > On 1 Oct 2015, at 15:12, Roger Riggs <Roger.Riggs at oracle.com> wrote: > >> ?. >> >> Javadoc: >> http://cr.openjdk.java.net/~rriggs/cleaner-doc/ >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > This is nice addition. Some comments / questions: > > 1) Should the behaviour, TCCL, permissions, etc, for > the default thread factory be specified in an apiNote? Yes, it would be nice not to have to repeat them but the InnocuousThread class does not have any public API to refer to. The TCCL is set to the systemClassLoader and the Acc is set to an empty ProtectionDomain. > > 2) threadFactory.newThread() is only ever called once? > Is this worth a note? Or potentially limiting to some > other implementation. Possibly useful to note, but not part of the specification of the behavior. > > 3) So the thunk runs with the intersection of the > permissions that are associated with the thunk and the > thread?s protection domain, regardless of the caller, right? yes For the default thread factory, the intersection is empty since the Threads ACC is an empty protection domain. Thanks, Roger > > -Chris From mandy.chung at oracle.com Tue Oct 13 20:59:12 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 13 Oct 2015 13:59:12 -0700 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <561D0D73.7080006@Oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561D0D73.7080006@Oracle.com> Message-ID: <5AB47826-626A-4760-97D9-547443847E2C@oracle.com> > On Oct 13, 2015, at 6:56 AM, Roger Riggs <roger.riggs at oracle.com> wrote: > > When considering how to update the existing classes with finalize methods, it became clear that > refactoring would be needed to separate out the state needed for the cleanup from public object > that was being finalized into a separate object it would provide the cleanup behavior as well. > In simple cases, it is just a copy of the native address or file descriptor. In other cases, like > FileIn/OutputStream it is references to other objects. In cases like FileDescriptor and Zip streams > the cleanup state is not just a native resource. > > The abstract XXXCleanup types make it easy to encapsulate the needed behavior and state. >> >> Second, the original sun.misc.Cleaner only handles phantom references. >> What are the use cases for weak and soft cleaners? > WeakReferences are sometimes used but since it is extra coding to clean them it tends > not to be implemented. > For example, sun.beans.WeakCache; it was just not worth the code to handle the weak refs completely. > > In another case, the ldap connection pool only cleans up connections when opening > a new pooled connection. > > Having easy to use and more active cleanup would release resources sooner and > reduce overall resource requirements. There are existing use of SoftReference and WeakReference in the JDK that has very simple dispose / clean method. This Cleaner API can benefit those cases if they are replaced to use the Cleaner API. It?d be useful to replace a couple of uses in the JDK with the new Cleaner API and include in the webrev. It could be different changesets that you can decide when it?s ready to be integrated. Same to include a few finalizers replaced would be good. > >> >> Finally, how important is it to be able to unregister a cleaner? In >> all the years we've had sun.misc.Cleaner that capability has never >> been needed, and leaving it out would simplify the API. > Recently there was a long discussion on core-libs [1] about making the cleanup of MappedByteBuffers > more timely to free up the memory sooner. If there was an explicit release operation on > either of those, then the cleaner would want to be unregistered or it would need to be at-most-once. > But this Cleaner API is not intended for MappedByteBuffer to replace its current use of sun.misc.Cleaner, right? I think it?s fine to keep this API for the common cases but not the cases that require on-demand clean up. > Encapsulating the cleanup state and behavior allows it to be invoked consistently both when the > object is closed or is found to be unreachable. The cleanup code is not repeated, and it is > easy to ensure that is invoked at most once. > > The other important aspect is that when the cleanup is performed explicitly (on close) > the ref is cleared and the overhead associated with reference processing is eliminated. > Currently, with finalizers, the finalizable refs still have to be processed, even if object has been closed. > This Cleaner API is intended to provide an easy to use alternative to finalization. I have been considering performance and promptness of reference processing separated from this proposed API (GC might be the appropriate place to speed up reference processing performance - what I refer to is common use of finalizers but not the resources that require promptness such as mapped byte buffer). It?s still unclear if it should allow a cleaner to be cleaned explicitly and unregistered. Mandy From john.r.rose at oracle.com Tue Oct 13 21:01:16 2015 From: john.r.rose at oracle.com (John Rose) Date: Tue, 13 Oct 2015 14:01:16 -0700 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <561CFEDB.2060601@Oracle.com> References: <560D3F61.6040607@Oracle.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <B095DF43-4186-4E3D-90B8-91F17B4788DF@oracle.com> <84606140.785696.1444723918802.JavaMail.zimbra@u-pem.fr> <561CFEDB.2060601@Oracle.com> Message-ID: <85BF724A-B700-4392-BD16-3450C9ED6161@oracle.com> On Oct 13, 2015, at 5:53 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote: > > We don't have a good handle on when it is too early to use lambda except by trial and error. > I think there are some improvements in the works so that some simple cases of Lambda > can be used earlier and will see if they apply. Aleksey also ran into this with his string factory work. Hopefully, error reports lead to fixes. See current reviews of JDK-8136893 as an example of progress. ? John From peter.levart at gmail.com Tue Oct 13 22:16:31 2015 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 14 Oct 2015 00:16:31 +0200 Subject: RFR: JDK-8136893: Improve early java.lang.invoke infrastructure initialization In-Reply-To: <561CF6B3.5030604@oracle.com> References: <5604EDAE.7080501@gmail.com> <79FDF077-226C-4D7A-A452-7D6447C2FB3F@oracle.com> <D3AE591C-FF34-4337-8932-6990322F32C5@oracle.com> <560565E6.7090000@gmail.com> <C7FEA5E2-33AC-4D55-B567-321CB7301008@oracle.com> <561CEA83.6010105@oracle.com> <823A8B73-F2D1-4584-841E-2E9215799E2F@oracle.com> <561CF2AF.1060807@gmail.com> <561CF6B3.5030604@oracle.com> Message-ID: <561D82BF.7010303@gmail.com> On 10/13/2015 02:18 PM, Vladimir Ivanov wrote: > Peter, > >> Ok, thanks Paul, Michael and Claes! I'll push it later today or early >> tomorrow after running some more tests (nashorn for example). If anybody >> else wants to comment, there's still some time (for example about the >> name of the package-private method)... > I'm late to the party :-) > Don't worry, looks good to me as well. > > Thanks for taking care of the bug! > > Best regards, > Vladimir Ivanov Hi Vladimir, nashorn tests pass. I have pushed the change. Thanks again for reviews. Regards, Peter From stuart.marks at oracle.com Wed Oct 14 04:18:21 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 13 Oct 2015 21:18:21 -0700 Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <CAGB9EW82wrS6Zsg+iaWHgzLxEKL6r5P9aoryS4450h0TfYjBQw@mail.gmail.com> References: <5616FEB5.5090104@oracle.com> <CACzrW9A3MZja2wxsHZ7E0vSupkMJXMTQDqMQRjV548ArAF57Hw@mail.gmail.com> <87025428.3530190.1444485358747.JavaMail.zimbra@u-pem.fr> <CAGB9EW82wrS6Zsg+iaWHgzLxEKL6r5P9aoryS4450h0TfYjBQw@mail.gmail.com> Message-ID: <561DD78D.8070800@oracle.com> On 10/10/15 9:10 AM, Louis Wasserman wrote: > If you're asking about why we stopped where we did, we collected actually > rather a lot of data on the size of static collection constants using > immutable collections, both with builder syntax and without. > https://github.com/google/guava/issues/2071#issuecomment-126468933 has the > statistics (in terms of ratios, not absolute numbers), but we found that > there was right about an exponential trend: static collection constants of > size n+1 were ~half as common as collection constants of size n. Hi Louis, Yes, this is mainly the issue that I'm interested in. Thanks for the pointer to these statistics. It's interesting that there seems to be a steady dropoff. But that makes it hard to decide where to cut it off, as there's no obvious "knee" of the curve. With a few elements, indeed it seems that the distribute drops off proportional to the power of 0.5, but it flattens out around considerably above 7. I'm not sure what this means. (I have a hunch this is related to Benford's Law [1] but this is only a hunch.) I'm not entirely sure what to take from this. If it were clearly exponential, we could say with confidence that above a certain threshold there would be vanishingly little benefit adding more arguments. But since the curve seems to flatten out, maybe this is pushing us to add more pairs than we had originally thought. The current draft API has 8 pairs; that seems to leave a few percent of cases on the table. Obviously we can't get to 100%, but is 97% good enough? Recommendations welcome. s'marks [1] https://en.wikipedia.org/wiki/Benford's_law From mandy.chung at oracle.com Wed Oct 14 05:21:41 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 13 Oct 2015 22:21:41 -0700 Subject: RFR: JDK-8046565: Platform Logger API and Service In-Reply-To: <561660DA.7070900@oracle.com> References: <561660DA.7070900@oracle.com> Message-ID: <8D8890A3-2337-4178-BA5C-CC32DE12F27D@oracle.com> > On Oct 8, 2015, at 5:26 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote: > > webrev: > http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/webrev.01/ System.Logger Several log methods throws NPE if the level is legible and the parameter is null. E.g. * @throws NullPointerException if {@code level} is {@code null}, or if the level * is loggable and {@code msgSupplier} is {@code null}. Should it throw NPE if the input parameter is null regardless of whether the level is loggable? RuntimePermission(?loggerFinder?) is required when 1. a LoggerFinder provider is instantiated 2. LoggerFinder::getLoggerFinder() is called 3. LoggerFinder::getLogger is called This is very specific to finding system logger (more than just the provider construction check). It does seem worth defining a specific Permission type for it e.g. LoggerPermission. Since LoggerFinder::getLogger requires permission check, does LoggerFinder::getLoggerFinder() need the explicit permission check? We will need to consult with the security experts. LazyLoggers::getLazyLogger(String name, Class<?> caller) - does it need permission check? it?s currently commented out public class LoggerWrapper<L extends Logger> extends AbstractLoggerWrapper<L> implements Logger, PlatformLoggerBridge - AbstractLoggerWrapper implements Logger, PlatformLoggerBridge, ConfigurableLoggerBridgem. Is "implements Logger, PlatformLoggerBridge? needed at all? Are all *Logger and *LoggerWrapper types implementing Logger, PlatformLoggerBridge, ConfigurableLoggerBridge? I might be missing it - I don?t see any non-configurable logger type implements only Logger, PlatformLoggerBridge. SimpleConsoleLogger.Formatting static final String FORMAT_PROP_KEY = "java.util.logging.SimpleFormatter.format"; - is this used when java.logging is not present? It?s for the simple console logger formatting. If so, the property name should be renamed to idk.logger.xxx? Can you explain the difference of sun.util.logging and sun.util.logger package? I think the reason to have two different packages is to make sure that sun.util.logger not used by other modules. What other issue to put the classes in sun.util.logging - the existing package? I don?t have any issue to create a new package but the name is hard to differentiate. Maybe rename sun.util.logger to jdk.internal.logger if not in sun.util.logging? Similarly, sun.util.logging.internal.JdkLoggingProvider and sun.util.logger.JdkLoggerProvider - the package names are too close and they are in two different module. Probably good to rename the classname - what about s/JdkLoggerProvider/SystemLoggerProvider/ s/JdkLoggingProvider/LoggingProvider/ I would have assumed that sun.util.logger.JdkLoggerProvider should be LoggerFinder. Is there any reason why it can?t extend LoggerFinder? I think that would be cleaner and getJdkLogger is not needed. Maybe DefaultLoggerFinder can be simplified. Have you considered moving out LoggerFinderLoader to a separate class? This change adds many lines in System.java. PlatformLogger - main reason to retain it is to minimize changes. I wonder if changing it to an interface would help or not. I?m still studying the sun.util.logger.* classes. jdk/test/java/lang/System/Logger/custom/AccessSystemLogger.java jdk/test/java/lang/System/Logger/default/AccessSystemLogger.java jdk/test/java/lang/System/LoggerFinder/public/BaseLoggerFinderTest/AccessSystemLogger.java - they seem to be duplicated code to setup boot directory. Worth putting them in logging test library? - what does the directory name "public" mean? maybe just take that directory out? jdk/test/java/lang/System/LoggerFinder/internal/backend/SystemClassLoader.java - copyright header That?s all for today. Mandy From paul.sandoz at oracle.com Wed Oct 14 08:54:09 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 14 Oct 2015 10:54:09 +0200 Subject: Optional.or name <was> Re: RFR 8080418 Add Optional.or() In-Reply-To: <CACzrW9DxAo7b33OFhFOsMtiUY-1Upq3RERbuTNPUUb2JHD20ng@mail.gmail.com> References: <2C9C9A31-7AA0-47CC-B17A-35A7188F4F8B@oracle.com> <C8CBC8A5-BF87-4560-880A-29A13E376DB6@oracle.com> <CACzrW9DxAo7b33OFhFOsMtiUY-1Upq3RERbuTNPUUb2JHD20ng@mail.gmail.com> Message-ID: <4F2E0C3B-8845-414D-9612-967CE20F484C@oracle.com> > On 13 Oct 2015, at 22:43, Stephen Colebourne <scolebourne at joda.org> wrote: > > I'd prefer to see "this" mentioned: > > "If a value is not present, invoke the specified supplier to provide > the result, otherwise return {@code this}" > > While I understand the original form gave some spec wiggle room, it > also made the method far more mysterious. > That wiggle room is useful to avoid baking in any assumptions about the identity of the returned Optional. Paul. From scolebourne at joda.org Wed Oct 14 09:33:43 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 14 Oct 2015 10:33:43 +0100 Subject: Optional.or name <was> Re: RFR 8080418 Add Optional.or() In-Reply-To: <4F2E0C3B-8845-414D-9612-967CE20F484C@oracle.com> References: <2C9C9A31-7AA0-47CC-B17A-35A7188F4F8B@oracle.com> <C8CBC8A5-BF87-4560-880A-29A13E376DB6@oracle.com> <CACzrW9DxAo7b33OFhFOsMtiUY-1Upq3RERbuTNPUUb2JHD20ng@mail.gmail.com> <4F2E0C3B-8845-414D-9612-967CE20F484C@oracle.com> Message-ID: <CACzrW9Ae6gjWO4muAj-HvZpMqwjUA3=mwNSu6pBi8QVwwQPr8w@mail.gmail.com> Maybe "an optional equivalent to {@code this}" The original text is quite obtuse. Stephen On 14 October 2015 at 09:54, Paul Sandoz <paul.sandoz at oracle.com> wrote: > >> On 13 Oct 2015, at 22:43, Stephen Colebourne <scolebourne at joda.org> wrote: >> >> I'd prefer to see "this" mentioned: >> >> "If a value is not present, invoke the specified supplier to provide >> the result, otherwise return {@code this}" >> >> While I understand the original form gave some spec wiggle room, it >> also made the method far more mysterious. >> > > That wiggle room is useful to avoid baking in any assumptions about the identity of the returned Optional. > > Paul. From paul.sandoz at oracle.com Wed Oct 14 09:38:22 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 14 Oct 2015 11:38:22 +0200 Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <561DD78D.8070800@oracle.com> References: <5616FEB5.5090104@oracle.com> <CACzrW9A3MZja2wxsHZ7E0vSupkMJXMTQDqMQRjV548ArAF57Hw@mail.gmail.com> <87025428.3530190.1444485358747.JavaMail.zimbra@u-pem.fr> <CAGB9EW82wrS6Zsg+iaWHgzLxEKL6r5P9aoryS4450h0TfYjBQw@mail.gmail.com> <561DD78D.8070800@oracle.com> Message-ID: <5CCBE2A7-3BF6-41E0-8651-A0DB7D714023@oracle.com> > On 14 Oct 2015, at 06:18, Stuart Marks <stuart.marks at oracle.com> wrote: > I'm not entirely sure what to take from this. If it were clearly exponential, we could say with confidence that above a certain threshold there would be vanishingly little benefit adding more arguments. But since the curve seems to flatten out, maybe this is pushing us to add more pairs than we had originally thought. The current draft API has 8 pairs; that seems to leave a few percent of cases on the table. Obviously we can't get to 100%, but is 97% good enough? > 11 if only for amusement purposes :-) Capturing 9 out of 10 cases seems reasonable to me i.e. 5 entries. Perhaps a common case for r > 5 entries is a map for the primitive types and ref (ignoring ?void?), which would push the limit up to 9 entries. I took a quick browse through the JDK and it is not that common AFAICT. j.l.invoke tends to use enums for example. There are two cases in java.ObjectInputStream and sun.misc.ProxyGenerator. Paul. From nadeesh.tv at oracle.com Wed Oct 14 09:53:14 2015 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Wed, 14 Oct 2015 15:23:14 +0530 Subject: RFR:8134928:java.time.Instant.truncatedTo(TemporalUnit unit) is truncating up if the year < 1970 Message-ID: <561E260A.8050103@oracle.com> Hi all, Please review a fix for https://bugs.openjdk.java.net/browse/JDK-8134928 Issue- java.time.Instant.truncatedTo(TemporalUnit unit) is truncating up if the year < 1970 BugId - https://bugs.openjdk.java.net/browse/JDK-8134928 webrev - http://cr.openjdk.java.net/~pchopra/8134928/webrev.01/ -- Thanks and Regards, Nadeesh TV From paul.sandoz at oracle.com Wed Oct 14 10:00:19 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 14 Oct 2015 12:00:19 +0200 Subject: Incomplete JavaDoc for Collections.synchronizedXYZ In-Reply-To: <1322955461.20151012191816@gmail.com> References: <1322955461.20151012191816@gmail.com> Message-ID: <A9B48EFE-4511-47C4-BAFF-CFC48B131741@oracle.com> Hi Tagir, Agreed. If you wanna send a patch to this list with updates to the other synchronized* methods i can review push it for you. Paul. > On 12 Oct 2015, at 15:18, Tagir F. Valeev <amaembo at gmail.com> wrote: > > Hello! > > With the introduction of Stream API the JavaDoc for > Collections.synchronizedCollection was updated (as part of work on > JDK-8023275): > > * It is imperative that the user manually synchronize on the returned > * collection when traversing it via {@link Iterator}, {@link Spliterator} > * or {@link Stream}: > > This sounds fine, but the same update is missing on other > synchronizedXYZ methods. For example, Collections.synchronizedList > documentation still states: > > * It is imperative that the user manually synchronize on the returned > * list when iterating over it: > > Nothing about Spliterator and especially about Stream. The same for > synchronizedSet, synchronizedSortedSet, synchronizedNavigableSet. Even > though internally all of them inherit the SynchronizedCollection > implementation, it's not specified that, for example, synchronizedSet > behavior is somehow connected with synchronizedCollection behavior. > > I think, the corresponding documentation update should be added. It's > especially important for the Stream as many people see no difference > between > > collection.forEach(...); > > And > > collection.stream().forEach(...); > > But with synchronized collections these two lines are very different: > the second call is not synchronized. > > What do you think? > > With best regards, > Tagir Valeev. > From kasperni at gmail.com Wed Oct 14 10:02:01 2015 From: kasperni at gmail.com (Kasper Nielsen) Date: Wed, 14 Oct 2015 12:02:01 +0200 Subject: java.lang.reflect.Method.copyOf Message-ID: <CAPs6152HyeMnK2v1s+mhG_kYuPSP-BcvHYnEFSdyc-mF-H-fSQ@mail.gmail.com> Hi, I was wondering if there is any reason for Method.copyOf (and friends) being package private. I'm trying to make a copy of a large number of Method objects in some performance sensitive code to avoid sharing the isAccessible flag. And while this is fairly fast. Class<?> declaringClass = method.getDeclaringClass(); try { return declaringClass.getDeclaredMethod(method.getName(), method.getParameterTypes()); } catch (NoSuchMethodException e) { throw new RuntimeException("This should never happen", e); } I would to like to avoid the performance penalty if possible. - Kasper From scolebourne at joda.org Wed Oct 14 10:36:20 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 14 Oct 2015 11:36:20 +0100 Subject: RFR:8134928:java.time.Instant.truncatedTo(TemporalUnit unit) is truncating up if the year < 1970 In-Reply-To: <561E260A.8050103@oracle.com> References: <561E260A.8050103@oracle.com> Message-ID: <CACzrW9Bzt64hHO=g8eECdteO75Zn7HYx_bWhWtvshsYa7EJwoQ@mail.gmail.com> I'd like to see an additional test case for the cases where rounding is *not* needed. Currently, there are only tests for where rounding is needed. It needs one more test line for after 1970 and one for before 1970. thanks Stephen On 14 October 2015 at 10:53, nadeesh tv <nadeesh.tv at oracle.com> wrote: > Hi all, > > Please review a fix for https://bugs.openjdk.java.net/browse/JDK-8134928 > > Issue- java.time.Instant.truncatedTo(TemporalUnit unit) is truncating up if > the year < 1970 > > BugId - https://bugs.openjdk.java.net/browse/JDK-8134928 > > webrev - http://cr.openjdk.java.net/~pchopra/8134928/webrev.01/ > > -- > Thanks and Regards, > Nadeesh TV > From forax at univ-mlv.fr Wed Oct 14 10:38:54 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 14 Oct 2015 12:38:54 +0200 (CEST) Subject: java.lang.reflect.Method.copyOf In-Reply-To: <CAPs6152HyeMnK2v1s+mhG_kYuPSP-BcvHYnEFSdyc-mF-H-fSQ@mail.gmail.com> References: <CAPs6152HyeMnK2v1s+mhG_kYuPSP-BcvHYnEFSdyc-mF-H-fSQ@mail.gmail.com> Message-ID: <811846492.1473636.1444819134738.JavaMail.zimbra@u-pem.fr> Given that j.l.r.Method is mutable, the best way to have performance is too encapsulate it in a non mutable class, if possible. As far as i know j.l.r.Method was introduced in Java 1.1 as non mutable and become mutable with Java 1.2, (yes, someone seriously fucked up !) so methods like copyOf were introduced to do defensive copies (the sharing mechanism was later introduced, in 1.4, i believe). cheers, R?mi ----- Mail original ----- > De: "Kasper Nielsen" <kasperni at gmail.com> > ?: "core-libs-dev" <core-libs-dev at openjdk.java.net> > Envoy?: Mercredi 14 Octobre 2015 12:02:01 > Objet: java.lang.reflect.Method.copyOf > > Hi, > > I was wondering if there is any reason for Method.copyOf (and friends) > being package private. > > I'm trying to make a copy of a large number of Method objects in some > performance sensitive code to avoid sharing the isAccessible flag. > > And while this is fairly fast. > > Class<?> declaringClass = method.getDeclaringClass(); > try { > return declaringClass.getDeclaredMethod(method.getName(), > method.getParameterTypes()); > } catch (NoSuchMethodException e) { > throw new RuntimeException("This should never happen", e); > } > > I would to like to avoid the performance penalty if possible. > > - Kasper > From scolebourne at joda.org Wed Oct 14 10:39:09 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 14 Oct 2015 11:39:09 +0100 Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <5CCBE2A7-3BF6-41E0-8651-A0DB7D714023@oracle.com> References: <5616FEB5.5090104@oracle.com> <CACzrW9A3MZja2wxsHZ7E0vSupkMJXMTQDqMQRjV548ArAF57Hw@mail.gmail.com> <87025428.3530190.1444485358747.JavaMail.zimbra@u-pem.fr> <CAGB9EW82wrS6Zsg+iaWHgzLxEKL6r5P9aoryS4450h0TfYjBQw@mail.gmail.com> <561DD78D.8070800@oracle.com> <5CCBE2A7-3BF6-41E0-8651-A0DB7D714023@oracle.com> Message-ID: <CACzrW9BjtxDEpQWDeQUJvd0H_Ff4OsPPgF=M2o4SjGFnRL+dhQ@mail.gmail.com> On 14 October 2015 at 10:38, Paul Sandoz <paul.sandoz at oracle.com> wrote: >> On 14 Oct 2015, at 06:18, Stuart Marks <stuart.marks at oracle.com> wrote: >> I'm not entirely sure what to take from this. If it were clearly exponential, we could say with confidence that above a certain threshold there would be vanishingly little benefit adding more arguments. But since the curve seems to flatten out, maybe this is pushing us to add more pairs than we had originally thought. The current draft API has 8 pairs; that seems to leave a few percent of cases on the table. Obviously we can't get to 100%, but is 97% good enough? I'd say 5 is definitely too little, without an easy builder fallback (as Guava provides). I'd say the right number is between 8 and 10. Stephen From timo.kinnunen at gmail.com Wed Oct 14 10:40:15 2015 From: timo.kinnunen at gmail.com (Timo Kinnunen) Date: Wed, 14 Oct 2015 12:40:15 +0200 Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <5CCBE2A7-3BF6-41E0-8651-A0DB7D714023@oracle.com> References: <5616FEB5.5090104@oracle.com> <CACzrW9A3MZja2wxsHZ7E0vSupkMJXMTQDqMQRjV548ArAF57Hw@mail.gmail.com> <87025428.3530190.1444485358747.JavaMail.zimbra@u-pem.fr> <CAGB9EW82wrS6Zsg+iaWHgzLxEKL6r5P9aoryS4450h0TfYjBQw@mail.gmail.com> <561DD78D.8070800@oracle.com> <5CCBE2A7-3BF6-41E0-8651-A0DB7D714023@oracle.com> Message-ID: <561e3110.a558c20a.6f12e.fffff6ef@mx.google.com> Hi, Alternatively you could create the variants whose parameters can be passed utilizing "all available registers", whatever that means in Java context. The rationale is that the reason for preferring variables over varargs is performance and this way there is no performance left on the table. Sent from Mail for Windows 10 From: Paul Sandoz Sent: Wednesday, October 14, 2015 11:38 Cc: core-libs-dev Subject: Re: RFC: draft API for JEP 269 Convenience Collection Factories > On 14 Oct 2015, at 06:18, Stuart Marks <stuart.marks at oracle.com> wrote: > I'm not entirely sure what to take from this. If it were clearly exponential, we could say with confidence that above a certain threshold there would be vanishingly little benefit adding more arguments. But since the curve seems to flatten out, maybe this is pushing us to add more pairs than we had originally thought. The current draft API has 8 pairs; that seems to leave a few percent of cases on the table. Obviously we can't get to 100%, but is 97% good enough? > 11 if only for amusement purposes :-) Capturing 9 out of 10 cases seems reasonable to me i.e. 5 entries. Perhaps a common case for r > 5 entries is a map for the primitive types and ref (ignoring ?void?), which would push the limit up to 9 entries. I took a quick browse through the JDK and it is not that common AFAICT. j.l.invoke tends to use enums for example. There are two cases in java.ObjectInputStream and sun.misc.ProxyGenerator. Paul. From daniel.fuchs at oracle.com Wed Oct 14 11:20:58 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 14 Oct 2015 13:20:58 +0200 Subject: RFR: JDK-8046565: Platform Logger API and Service In-Reply-To: <8D8890A3-2337-4178-BA5C-CC32DE12F27D@oracle.com> References: <561660DA.7070900@oracle.com> <8D8890A3-2337-4178-BA5C-CC32DE12F27D@oracle.com> Message-ID: <561E3A9A.9050807@oracle.com> Hi Mandy, On 14/10/15 07:21, Mandy Chung wrote: > >> On Oct 8, 2015, at 5:26 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote: >> >> webrev: >> http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/webrev.01/ > > System.Logger > > Several log methods throws NPE if the level is legible and the parameter is null. E.g. > * @throws NullPointerException if {@code level} is {@code null}, or if the level > * is loggable and {@code msgSupplier} is {@code null}. > > Should it throw NPE if the input parameter is null regardless of whether the level is loggable? Yes probably. The reason it is like that is that it mimics what java.util.logging.Logger does (at least for message suppliers), but it is probably not a good idea to propagate this bad practice. I will change System.Logger spec to mandate to always throw NPE if Supplier<String> is null - and ensure that the implementations we have follow the spec. > RuntimePermission(?loggerFinder?) is required when > 1. a LoggerFinder provider is instantiated > 2. LoggerFinder::getLoggerFinder() is called > 3. LoggerFinder::getLogger is called > > This is very specific to finding system logger (more than just the provider construction check). It does seem worth defining a specific Permission type for it e.g. LoggerPermission. Since LoggerFinder::getLogger requires permission check, does LoggerFinder::getLoggerFinder() need the explicit permission check? We will need to consult with the security experts. This is why it was first called "controlSystemLoggers" until somebody suggested to change it to "loggerFinder" ;-) But since it protects all access to LoggerFinder then naming it "loggerFinder" was actually a good suggestion :-) When I started working on this I added a new LoggerPermission class similar to java.util.logging.Permission. I received strong pushback against it and it was suggeseted I used RuntimePermission instead - which suits me well. I believe LoggerFinder::getLoggerFinder() should be protected by the permission. In the current design LoggerFinder::getLogger is abstract - so the permission check is not enforced. I had toyed with the idea of making getLogger final and make it call a protected abstract demandLogger method instead, so that we can enforce the permission check in getLogger. But I'm not sure it is worth it given that you need a permission to get the LoggerFinder object in the first place. And it would be two more methods in the spec... > LazyLoggers::getLazyLogger(String name, Class<?> caller) > - does it need permission check? it?s currently commented out This class should already be protected by packageAccess checks and module access checks (since it's not in an exported package). So I don't think it needs the additional permission check which should have been performed (if needed) by upstream code. The commented code should obviously go away before pushing, I left it to elicit confirmation that it was OK to leave it out. > public class LoggerWrapper<L extends Logger> extends AbstractLoggerWrapper<L> > implements Logger, PlatformLoggerBridge > > - AbstractLoggerWrapper implements Logger, PlatformLoggerBridge, ConfigurableLoggerBridgem. Is "implements Logger, PlatformLoggerBridge? needed at all? Yes. AbstractLoggerWrapper is a System.Logger and needs to implement System.Logger. PlatformLoggerBridge and ConfigurableLoggerBridge is bridging code for PlatformLogger. If the wrapped logger implements those then calls are directly forwarded to the wrapped logger. Otherwise the default mapping provided by AbstractLoggerWrapper is used. This makes it possible to avoid transforming FINEST in FINER and CONFIG in FINE when PlatformLogger is the front end and java.util.logging is the default backend. When component teams move from PlatformLogger to System.Logger *they* will have to decide whether they want to downgrade CONFIG to DEBUG or upgrade it to INFO. > Are all *Logger and *LoggerWrapper types implementing Logger, PlatformLoggerBridge, ConfigurableLoggerBridge? I might be missing it - I don?t see any non-configurable logger type implements only Logger, PlatformLoggerBridge. All *LoggerWrapper extend AbstractLoggerWrapper. All *Logger implementations that we provide implement those interfaces as well - so that PlatformLogger calls can be tunneled through to the concrete implementation returned by our default provider implementation when there's no custom LoggerFinder service plugged in. > SimpleConsoleLogger.Formatting > static final String FORMAT_PROP_KEY = > "java.util.logging.SimpleFormatter.format"; > - is this used when java.logging is not present? It?s for the simple console logger formatting. If so, the property name should be renamed to idk.logger.xxx? Yes. It's used both by java.util.logging and the SimpleConsoleLogger. I think you did introduce this property - it was also used both by java.util.logging and the PlatformLogger proxy - I simply translated the code from the proxy to SimpleConsoleLogger. SimpleConsoleLogger are also used as temporary loggers when LogManager is not initialized and has no custom configuration, just as PlatformLogger used to do. That functionality was simply translated from PlatformLogger to LazyLoggers/BootstrapLogger. > Can you explain the difference of sun.util.logging and sun.util.logger package? I think the reason to have two different packages is to make sure that sun.util.logger not used by other modules. What other issue to put the classes in sun.util.logging - the existing package? I don?t have any issue to create a new package but the name is hard to differentiate. Maybe rename sun.util.logger to jdk.internal.logger if not in sun.util.logging? sun.util.logging contains the 'legacy' PlatformLogger and all the code needed to bridge PlatformLogger. It can go away when we get to the point where nobody uses PlatformLogger any more. sun.util.logger has all the new internal classes of the new service. I could have put everything in sun.util.logging, but sun.util.logging is already exported to several modules - so I preferred to keep it separate. sun.util.logger is maybe not that a great name - but sun.util.logging was already taken ;-) Also I wanted to keep all restrictions that apply to sun.* packages (protected by package access checks, flagged by IDEs if you try to use them etc...). We don't want anybody start using sun.util.logger directly (only java.logging needs it in order to implement the internal service provider interface) In an ideal situation then in the mid-long term sun.util.logging should hopefully disappear from java.base - and only sun.util.logger would remain. Do you think it would be preferable to move all the classes from sun.util.logger over to sun.util.logging? The distinction between new and legacy/bridge might be less clear, and there might be a little more risk of having modules which already read sun.util.logging foraging inside - but it could be worth it as it would mean one less new package... > Similarly, sun.util.logging.internal.JdkLoggingProvider and sun.util.logger.JdkLoggerProvider - the package names are too close and they are in two different module. Probably good to rename the classname - what about > s/JdkLoggerProvider/SystemLoggerProvider/ > s/JdkLoggingProvider/LoggingProvider/ InternalLoggerProvider would be a better fit than SystemLoggerProvider. LoggingProvider is OK I guess. Or InternalLoggerProviderImpl? The Jdk prefix was here to indicate that these are JDK internals. But obviously it didn't convey the meaning strongly enough. WRT to package name there's a precedent because sun.util.logging.resources is in java.logging module. So this just adds sun.util.logging.internal next to it. I am not a great fan of the name - but this is 1. internal and 2. I had no better idea. I couldn't put that class under sun.util.logging.resources - could I? What about InternalLoggerProvider for the service and InternalLoggerProviderImpl for the impl provided by java.logging? > I would have assumed that sun.util.logger.JdkLoggerProvider should be LoggerFinder. It should not. That would also be confusing - I think. This is not a LoggerFinder. It is an internal (sub)service provider interface used by our internal default implementation of the LoggerFinder service. > Is there any reason why it can?t extend LoggerFinder? Yes, this is the internal service provider interface that we use to figure out whether java.logging is present. It's cleaner and safer than using reflection. This is not an implementation of the LoggerFinder service. > I think that would be cleaner and getJdkLogger is not needed. We don't want java.logging to provide a service that implements LoggerFinder. At the moment, we throw a ServiceConfigurationError if ServiceLoader has more than one implementation of the LoggerFinder service. That is cleaner than having to instantiate all the services and then decide which one to take and which one to discard. > Maybe DefaultLoggerFinder can be simplified. Not sure there's much to do here. > Have you considered moving out LoggerFinderLoader to a separate class? This change adds many lines in System.java. Could do it. That might not be a bad idea. LoggerFinderLoader should be a name clear enough to convey the intent and avoid confusion. So we could make it a package class instead of a static nested class. > PlatformLogger - main reason to retain it is to minimize changes. I wonder if changing it to an interface would help or not. I?m still studying the sun.util.logger.* classes. I had envisaged it. Then decided to keep it as a class. This is currently also used by javafx modules - so I believe a 3 steps strategy is better: 1. step 1 => change PlatformLogger to log through System.Logger, but don't change it's public interface (except for deprecating setLevel), and minimize the behaviour changes when java.logging is present (the purpose of the *Bridge interfaces) 2. step 2 => engage the component teams to plan for removing uses of PlatformLogger and use System.getLogger instead - possibly deprecate PlatformLogger at the time - 3. step 3 => when all is stable and nobody uses PlatformLogger anymore, remove sun.util.logging package and all the bridging code from the classes in sun.util.logger. I am not sure whether 1. 2. and 3. can/should be done in same time frame. Only step 1. is in this JEP goals anyway. > > jdk/test/java/lang/System/Logger/custom/AccessSystemLogger.java > jdk/test/java/lang/System/Logger/default/AccessSystemLogger.java > jdk/test/java/lang/System/LoggerFinder/public/BaseLoggerFinderTest/AccessSystemLogger.java > - they seem to be duplicated code to setup boot directory. Worth putting them in logging test library? I've been trying very hard to avoid using Libraries ;-). Also I want to have access to the .class generated by jtreg, in order to copy it in a directory that can be appended to the boot class path. That's what the AccessSystemLogger.java does. It is first compiled by jtreg - and is present in the classpath. Then it is activated by the @run driver line - and it copies its .class in a ./boot subdirectory Then the @run main line will pick the ./boot directory and append it to the bootclasspath. > - what does the directory name "public" mean? maybe just take that directory out? oh - that might be a good idea too. It was meant to indicate that the test in here might (possibly) serve to SQE because they don't depend on any implementation specific classes. I will take the directory out. > jdk/test/java/lang/System/LoggerFinder/internal/backend/SystemClassLoader.java > - copyright header Argh. Thanks for catching that. best regards, -- daniel > > That?s all for today. > > Mandy > > From paul.sandoz at oracle.com Wed Oct 14 11:46:38 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 14 Oct 2015 13:46:38 +0200 Subject: java.lang.reflect.Method.copyOf In-Reply-To: <811846492.1473636.1444819134738.JavaMail.zimbra@u-pem.fr> References: <CAPs6152HyeMnK2v1s+mhG_kYuPSP-BcvHYnEFSdyc-mF-H-fSQ@mail.gmail.com> <811846492.1473636.1444819134738.JavaMail.zimbra@u-pem.fr> Message-ID: <3C8048E3-E43F-4755-A6B9-259964147506@oracle.com> > On 14 Oct 2015, at 12:38, Remi Forax <forax at univ-mlv.fr> wrote: > > Given that j.l.r.Method is mutable, the best way to have performance is too encapsulate it in a non mutable class, if possible. > > As far as i know j.l.r.Method was introduced in Java 1.1 as non mutable and become mutable with Java 1.2, (yes, someone seriously fucked up !) Some harsh language there :-) I don?t know the full history but i like to think this may have been a frustrating compromise due to some demanding serialization requirements under a tight schedule. It?s definitely annoying that there is a mutable bit associated with each accessible object, which in turn has an impact a number of fundamental areas (such as final fields, strong module boundaries) Paul. > so methods like copyOf were introduced to do defensive copies (the sharing mechanism was later introduced, in 1.4, i believe). > > cheers, > R?mi From forax at univ-mlv.fr Wed Oct 14 12:14:18 2015 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 14 Oct 2015 12:14:18 +0000 Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <561e3110.a558c20a.6f12e.fffff6ef@mx.google.com> References: <5616FEB5.5090104@oracle.com> <CACzrW9A3MZja2wxsHZ7E0vSupkMJXMTQDqMQRjV548ArAF57Hw@mail.gmail.com> <87025428.3530190.1444485358747.JavaMail.zimbra@u-pem.fr> <CAGB9EW82wrS6Zsg+iaWHgzLxEKL6r5P9aoryS4450h0TfYjBQw@mail.gmail.com> <561DD78D.8070800@oracle.com> <5CCBE2A7-3BF6-41E0-8651-A0DB7D714023@oracle.com> <561e3110.a558c20a.6f12e.fffff6ef@mx.google.com> Message-ID: <0E130FE0-EECA-4B8F-A8BA-A62529D690F5@univ-mlv.fr> You can have 255 parameters for a method, it's perhaps a little too much, isn't it ? cheers, R?mi Le 14 octobre 2015 12:40:15 CEST, Timo Kinnunen <timo.kinnunen at gmail.com> a ?crit : >Hi, > >Alternatively you could create the variants whose parameters can be >passed utilizing "all available registers", whatever that means in >Java context. The rationale is that the reason for preferring variables >over varargs is performance and this way there is no performance left >on the table. > > > >Sent from Mail for Windows 10 > > > >From: Paul Sandoz >Sent: Wednesday, October 14, 2015 11:38 >Cc: core-libs-dev >Subject: Re: RFC: draft API for JEP 269 Convenience Collection >Factories > > > >> On 14 Oct 2015, at 06:18, Stuart Marks <stuart.marks at oracle.com> >wrote: >> I'm not entirely sure what to take from this. If it were clearly >exponential, we could say with confidence that above a certain >threshold there would be vanishingly little benefit adding more >arguments. But since the curve seems to flatten out, maybe this is >pushing us to add more pairs than we had originally thought. The >current draft API has 8 pairs; that seems to leave a few percent of >cases on the table. Obviously we can't get to 100%, but is 97% good >enough? >> > >11 if only for amusement purposes :-) > >Capturing 9 out of 10 cases seems reasonable to me i.e. 5 entries. > >Perhaps a common case for r > 5 entries is a map for the primitive >types and ref (ignoring ?void?), which would push the limit up to 9 >entries. I took a quick browse through the JDK and it is not that >common AFAICT. j.l.invoke tends to use enums for example. There are two >cases in java.ObjectInputStream and sun.misc.ProxyGenerator. > >Paul. From ivan.gerasimov at oracle.com Wed Oct 14 12:56:28 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 14 Oct 2015 15:56:28 +0300 Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <5616FEB5.5090104@oracle.com> References: <5616FEB5.5090104@oracle.com> Message-ID: <561E50FC.3070004@oracle.com> Hi Stuart! > Most of the API is pretty straightforward, with fixed-arg and varargs > "of()" factories for List, Set, ArrayList, and HashSet; and with > fixed-arg "of()" factories and varargs "ofEntries()" factories for Map > and HashMap. > Has it been considered to separate a Map creation into two steps: specifying keys and then values? Varargs methods can then be used in each step. I understand, that keeping the key and the value close each other looks better in many cases. However, separating them can allow some additional flexibility. Here's a draft of what it might look like: -------------------------------------------------------------------- import java.util.*; import java.util.function.*; public class MapOf { public static void main(String[] a) { Map<Integer,Character> m1 = MyCollections.<Integer,Character> ofKeys( 1, 2, 3, 4, 5) .vals( 'a', 'b', 'c', 'd', 'e'); m1.forEach((k, v) -> System.out.println("m1[" + k + "] = " + v)); Map<Integer,String> m2 = MyCollections.<Integer,String> ofKeys( 1, 2, 3, 4, 5) .calculateVals(k -> "#" + k + "#"); m2.forEach((k, v) -> System.out.println("m2[" + k + "] = " + v)); } } class MyCollections { public static <K,V> KeysHolder<K,V> ofKeys(K... keys) { return new KeysHolder<>(keys); } public static class KeysHolder<K,V> { K[] keys; KeysHolder(K[] keys) { this.keys = keys; } public Map<K,V> vals(V... vals) { if (vals.length != keys.length) { throw new IllegalArgumentException(); } Map<K,V> result = new HashMap<>(); for (int i = 0; i < keys.length; ++i) { result.put(keys[i], vals[i]); } return result; } public Map<K,V> calculateVals(Function<K,V> fun) { Map<K,V> result = new HashMap<>(); for (int i = 0; i < keys.length; ++i) { result.put(keys[i], fun.apply(keys[i])); } return result; } } } -------------------------------------------------------------------- Sincerely yours, Ivan From brian.goetz at oracle.com Wed Oct 14 13:17:02 2015 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 14 Oct 2015 09:17:02 -0400 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <20151012123016.566133@eggemoggin.niobe.net> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> Message-ID: <561E55CE.3000400@oracle.com> > Finally, how important is it to be able to unregister a cleaner? In > all the years we've had sun.misc.Cleaner that capability has never > been needed, and leaving it out would simplify the API. I see this as having two big potential benefits (I'll let Roger confirm whether the implementation provides both): - Resource release for finalizable objects is generally coded in two places; in the explicit close() / release() method, which we hope people will use, and in the finalizer, in case the object is collected without being closed. Having two ways to express the same action is error-prone; if there's one definition of "release the houn^H^H^H^Hresources" then they can't get out of sync. This requires an atomic means to say "unregister the cleaner, and, if its not yet been run, run it now". - If you can unregister the cleaner on the happy path (where the user explicitly closes the object ), then all the enqueue / reference processing / finalization work can be optimized away. From sean.coffey at oracle.com Wed Oct 14 13:20:42 2015 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 14 Oct 2015 14:20:42 +0100 Subject: RFR: 6907252: ZipFileInputStream Not Thread-Safe Message-ID: <561E56AA.6010405@oracle.com> Looking to tighten up access between the java and native level zip library calls. This extra check should ensure that we don't hit SEGV on thread races. I've also taken the opportunity to make the ZStreamRef address variable volatile. I'm still getting reports of zip crashes in the deflate, deflate_slow functions [1] but can't reproduce the failure. Access to the ZStreamRef address variable seems to be synchronized correctly in all calling sites. I'm just be extra sure for possible sharing across multiple threads. bug report : https://bugs.openjdk.java.net/browse/JDK-6907252 webrev : http://cr.openjdk.java.net/~coffeys/webrev.6907252/webrev/ [1] https://bugs.openjdk.java.net/browse/JDK-8028216 -- Regards, Sean. From Roger.Riggs at Oracle.com Wed Oct 14 13:24:36 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 14 Oct 2015 09:24:36 -0400 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <561E55CE.3000400@oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> Message-ID: <561E5794.5050002@Oracle.com> Hi, Confirmed, the design and implementation encapsulate the cleanup so it can be run consistently at-most-once either at close or when it is unreferenced. It has not been a problem for sun.misc.Cleaner because the cleanup is *only* done when the ref is unreachable. But there are issues about latency in getting resources released and reusable. Roger On 10/14/2015 9:17 AM, Brian Goetz wrote: >> Finally, how important is it to be able to unregister a cleaner? In >> all the years we've had sun.misc.Cleaner that capability has never >> been needed, and leaving it out would simplify the API. > > I see this as having two big potential benefits (I'll let Roger > confirm whether the implementation provides both): > > - Resource release for finalizable objects is generally coded in two > places; in the explicit close() / release() method, which we hope > people will use, and in the finalizer, in case the object is collected > without being closed. Having two ways to express the same action is > error-prone; if there's one definition of "release the resources" then > they can't get out of sync. > > This requires an atomic means to say "unregister the cleaner, and, if > its not yet been run, run it now". > > - If you can unregister the cleaner on the happy path (where the user > explicitly closes the object ), then all the enqueue / reference > processing / finalization work can be optimized away. > > From Alan.Bateman at oracle.com Wed Oct 14 13:35:02 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Oct 2015 14:35:02 +0100 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <561E5794.5050002@Oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> Message-ID: <561E5A06.3000802@oracle.com> On 14/10/2015 14:24, Roger Riggs wrote: > Hi, > > Confirmed, the design and implementation encapsulate the cleanup so > it can be run consistently > at-most-once either at close or when it is unreferenced. > It has not been a problem for sun.misc.Cleaner because the cleanup is > *only* done when > the ref is unreachable. But there are issues about latency in getting > resources released and reusable. There are a few places the in JDK where we do use Cleaner::clean for exactly this reason. One thing that I've been wondering about is why the abstract XXXCleanable classes are public, is that intended? -Alan. From Roger.Riggs at Oracle.com Wed Oct 14 13:54:16 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 14 Oct 2015 09:54:16 -0400 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <561E5A06.3000802@oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> Message-ID: <561E5E88.7070302@Oracle.com> Hi Alan, On 10/14/2015 9:35 AM, Alan Bateman wrote: > On 14/10/2015 14:24, Roger Riggs wrote: >> Hi, >> >> Confirmed, the design and implementation encapsulate the cleanup so >> it can be run consistently >> at-most-once either at close or when it is unreferenced. >> It has not been a problem for sun.misc.Cleaner because the cleanup is >> *only* done when >> the ref is unreachable. But there are issues about latency in >> getting resources released and reusable. > There are a few places the in JDK where we do use Cleaner::clean for > exactly this reason. > > One thing that I've been wondering about is why the abstract > XXXCleanable classes are public, is that intended? Being able to subclass the XXXCleanable classes allows more efficient implementation of the cleaners in both size and performance. The subclass adds the necessary state for the cleanup and implements the performCleanup method. Only a single object is created (and gc'd), reducing the size of headers and cross references between separate objects. Only the performCleanup method is overridable to maintain the robustness of the Cleaner implementation. If the XXXCleaner classes are not subclassed, a separate object is needed for the state and behavior. Either that extra object is created by the binding if lambda is used, or by the class needing the cleanup. It is not a big cost but is proposed to optimize the design and implementation. Peter's email [1] provided another description of the use case for subclassing. I'm working on a webrev to show how the Cleaner would be used instead of finalizers and it will show use use of both lambdas and explicit cleanup classes. Roger [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035826.html > > -Alan. From Alan.Bateman at oracle.com Wed Oct 14 14:01:20 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Oct 2015 15:01:20 +0100 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <561E5E88.7070302@Oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> Message-ID: <561E6030.4020403@oracle.com> On 14/10/2015 14:54, Roger Riggs wrote: > Being able to subclass the XXXCleanable classes allows more efficient > implementation of the cleaners > in both size and performance. The subclass adds the necessary state > for the cleanup and implements > the performCleanup method. Only a single object is created (and > gc'd), reducing the size of headers > and cross references between separate objects. Only the > performCleanup method is overridable to > maintain the robustness of the Cleaner implementation. > > If the XXXCleaner classes are not subclassed, a separate object is > needed for the state and behavior. > Either that extra object is created by the binding if lambda is used, > or by the class needing the cleanup. > It is not a big cost but is proposed to optimize the design and > implementation. > > Peter's email [1] provided another description of the use case for > subclassing. > > I'm working on a webrev to show how the Cleaner would be used instead > of finalizers > and it will show use use of both lambdas and explicit cleanup classes. No issue with sub-classing for the implementation, it's just not clear why they need to be in the public API. -Alan From Roger.Riggs at Oracle.com Wed Oct 14 14:03:36 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 14 Oct 2015 10:03:36 -0400 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <561E6030.4020403@oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> Message-ID: <561E60B8.2040900@Oracle.com> Hi Alan, So any user of the Cleaner can take advantage of the mechanism, for example in a different package or module. For example, Netbeans. Roger On 10/14/2015 10:01 AM, Alan Bateman wrote: > On 14/10/2015 14:54, Roger Riggs wrote: >> Being able to subclass the XXXCleanable classes allows more efficient >> implementation of the cleaners >> in both size and performance. The subclass adds the necessary state >> for the cleanup and implements >> the performCleanup method. Only a single object is created (and >> gc'd), reducing the size of headers >> and cross references between separate objects. Only the >> performCleanup method is overridable to >> maintain the robustness of the Cleaner implementation. >> >> If the XXXCleaner classes are not subclassed, a separate object is >> needed for the state and behavior. >> Either that extra object is created by the binding if lambda is used, >> or by the class needing the cleanup. >> It is not a big cost but is proposed to optimize the design and >> implementation. >> >> Peter's email [1] provided another description of the use case for >> subclassing. >> >> I'm working on a webrev to show how the Cleaner would be used instead >> of finalizers >> and it will show use use of both lambdas and explicit cleanup classes. > No issue with sub-classing for the implementation, it's just not clear > why they need to be in the public API. > > -Alan From forax at univ-mlv.fr Wed Oct 14 14:15:17 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 14 Oct 2015 16:15:17 +0200 (CEST) Subject: java.lang.reflect.Method.copyOf In-Reply-To: <3C8048E3-E43F-4755-A6B9-259964147506@oracle.com> References: <CAPs6152HyeMnK2v1s+mhG_kYuPSP-BcvHYnEFSdyc-mF-H-fSQ@mail.gmail.com> <811846492.1473636.1444819134738.JavaMail.zimbra@u-pem.fr> <3C8048E3-E43F-4755-A6B9-259964147506@oracle.com> Message-ID: <482359547.1607134.1444832117374.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Paul Sandoz" <paul.sandoz at oracle.com> > Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net> > Envoy?: Mercredi 14 Octobre 2015 13:46:38 > Objet: Re: java.lang.reflect.Method.copyOf > > > > On 14 Oct 2015, at 12:38, Remi Forax <forax at univ-mlv.fr> wrote: > > > > Given that j.l.r.Method is mutable, the best way to have performance is too > > encapsulate it in a non mutable class, if possible. > > > > As far as i know j.l.r.Method was introduced in Java 1.1 as non mutable and > > become mutable with Java 1.2, (yes, someone seriously fucked up !) > > Some harsh language there :-) I don?t know the full history but i like to > think this may have been a frustrating compromise due to some demanding > serialization requirements under a tight schedule. Methods are not serializable. And i will not throw the first rock ... after all we all have our own museum of bad decisions. > > It?s definitely annoying that there is a mutable bit associated with each > accessible object, which in turn has an impact a number of fundamental areas > (such as final fields, strong module boundaries) > > Paul. regards, R?mi > > > so methods like copyOf were introduced to do defensive copies (the sharing > > mechanism was later introduced, in 1.4, i believe). > > > > cheers, > > R?mi > > From Alan.Bateman at oracle.com Wed Oct 14 14:23:10 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Oct 2015 15:23:10 +0100 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <561E60B8.2040900@Oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> Message-ID: <561E654E.6040106@oracle.com> On 14/10/2015 15:03, Roger Riggs wrote: > Hi Alan, > > So any user of the Cleaner can take advantage of the mechanism, for > example in a different package or module. > For example, Netbeans. Cleaner + Cleanable need to be public of course so maybe we should wait for the examples that extend WeakCleanableRef or cast the Cleanable to a WeakCleanableRef before seeing if this is the right thing or not. -Alan From paul.sandoz at oracle.com Wed Oct 14 14:24:11 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 14 Oct 2015 16:24:11 +0200 Subject: java.lang.reflect.Method.copyOf In-Reply-To: <482359547.1607134.1444832117374.JavaMail.zimbra@u-pem.fr> References: <CAPs6152HyeMnK2v1s+mhG_kYuPSP-BcvHYnEFSdyc-mF-H-fSQ@mail.gmail.com> <811846492.1473636.1444819134738.JavaMail.zimbra@u-pem.fr> <3C8048E3-E43F-4755-A6B9-259964147506@oracle.com> <482359547.1607134.1444832117374.JavaMail.zimbra@u-pem.fr> Message-ID: <8A05C3D9-13BB-48E1-8222-F282622EAEF7@oracle.com> > On 14 Oct 2015, at 16:15, Remi Forax <forax at univ-mlv.fr> wrote: > > ----- Mail original ----- >> De: "Paul Sandoz" <paul.sandoz at oracle.com> >> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net> >> Envoy?: Mercredi 14 Octobre 2015 13:46:38 >> Objet: Re: java.lang.reflect.Method.copyOf >> >> >>> On 14 Oct 2015, at 12:38, Remi Forax <forax at univ-mlv.fr> wrote: >>> >>> Given that j.l.r.Method is mutable, the best way to have performance is too >>> encapsulate it in a non mutable class, if possible. >>> >>> As far as i know j.l.r.Method was introduced in Java 1.1 as non mutable and >>> become mutable with Java 1.2, (yes, someone seriously fucked up !) >> >> Some harsh language there :-) I don?t know the full history but i like to >> think this may have been a frustrating compromise due to some demanding >> serialization requirements under a tight schedule. > > Methods are not serializable. One of the primary motivations for the introduction of the accessibility bit was serialization: * <p>Setting the {@code accessible} flag in a reflected object * permits sophisticated applications with sufficient privilege, such * as Java Object Serialization or other persistence mechanisms, to * manipulate objects in a manner that would normally be prohibited. Paul. From chris.hegarty at oracle.com Wed Oct 14 14:29:15 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 14 Oct 2015 15:29:15 +0100 Subject: java.lang.reflect.Method.copyOf In-Reply-To: <482359547.1607134.1444832117374.JavaMail.zimbra@u-pem.fr> References: <CAPs6152HyeMnK2v1s+mhG_kYuPSP-BcvHYnEFSdyc-mF-H-fSQ@mail.gmail.com> <811846492.1473636.1444819134738.JavaMail.zimbra@u-pem.fr> <3C8048E3-E43F-4755-A6B9-259964147506@oracle.com> <482359547.1607134.1444832117374.JavaMail.zimbra@u-pem.fr> Message-ID: <075413CD-98E2-44F5-A88B-B321187C4A13@oracle.com> On 14 Oct 2015, at 15:15, Remi Forax <forax at univ-mlv.fr> wrote: > ----- Mail original ----- >> De: "Paul Sandoz" <paul.sandoz at oracle.com> >> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net> >> Envoy?: Mercredi 14 Octobre 2015 13:46:38 >> Objet: Re: java.lang.reflect.Method.copyOf >> >> >>> On 14 Oct 2015, at 12:38, Remi Forax <forax at univ-mlv.fr> wrote: >>> >>> Given that j.l.r.Method is mutable, the best way to have performance is too >>> encapsulate it in a non mutable class, if possible. >>> >>> As far as i know j.l.r.Method was introduced in Java 1.1 as non mutable and >>> become mutable with Java 1.2, (yes, someone seriously fucked up !) >> >> Some harsh language there :-) I don?t know the full history but i like to >> think this may have been a frustrating compromise due to some demanding >> serialization requirements under a tight schedule. > > Methods are not serializable. No, but was Paul referring to the fact the the custom readObject and writeObject methods must be private, and somehow accessible to the Serialization framework ? -Chris From forax at univ-mlv.fr Wed Oct 14 14:49:41 2015 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 14 Oct 2015 16:49:41 +0200 (CEST) Subject: java.lang.reflect.Method.copyOf In-Reply-To: <075413CD-98E2-44F5-A88B-B321187C4A13@oracle.com> References: <CAPs6152HyeMnK2v1s+mhG_kYuPSP-BcvHYnEFSdyc-mF-H-fSQ@mail.gmail.com> <811846492.1473636.1444819134738.JavaMail.zimbra@u-pem.fr> <3C8048E3-E43F-4755-A6B9-259964147506@oracle.com> <482359547.1607134.1444832117374.JavaMail.zimbra@u-pem.fr> <075413CD-98E2-44F5-A88B-B321187C4A13@oracle.com> Message-ID: <1298566516.1650356.1444834181327.JavaMail.zimbra@u-pem.fr> Thanks Paul and Chris, very interesting indeed. regards, R?mi ----- Mail original ----- > De: "Chris Hegarty" <chris.hegarty at oracle.com> > ?: "Remi Forax" <forax at univ-mlv.fr> > Cc: "Paul Sandoz" <paul.sandoz at oracle.com>, "core-libs-dev" <core-libs-dev at openjdk.java.net> > Envoy?: Mercredi 14 Octobre 2015 16:29:15 > Objet: Re: java.lang.reflect.Method.copyOf > > On 14 Oct 2015, at 15:15, Remi Forax <forax at univ-mlv.fr> wrote: > > > ----- Mail original ----- > >> De: "Paul Sandoz" <paul.sandoz at oracle.com> > >> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net> > >> Envoy?: Mercredi 14 Octobre 2015 13:46:38 > >> Objet: Re: java.lang.reflect.Method.copyOf > >> > >> > >>> On 14 Oct 2015, at 12:38, Remi Forax <forax at univ-mlv.fr> wrote: > >>> > >>> Given that j.l.r.Method is mutable, the best way to have performance is > >>> too > >>> encapsulate it in a non mutable class, if possible. > >>> > >>> As far as i know j.l.r.Method was introduced in Java 1.1 as non mutable > >>> and > >>> become mutable with Java 1.2, (yes, someone seriously fucked up !) > >> > >> Some harsh language there :-) I don?t know the full history but i like to > >> think this may have been a frustrating compromise due to some demanding > >> serialization requirements under a tight schedule. > > > > Methods are not serializable. > > No, but was Paul referring to the fact the the custom readObject > and writeObject methods must be private, and somehow > accessible to the Serialization framework ? > > -Chris From dl at cs.oswego.edu Wed Oct 14 15:04:36 2015 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 14 Oct 2015 11:04:36 -0400 Subject: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal In-Reply-To: <56164C3C.4050800@cs.oswego.edu> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56164C3C.4050800@cs.oswego.edu> Message-ID: <561E6F04.9030708@cs.oswego.edu> Some notes after reading follow-ups. One question is whether there should be a method that clues in the JVM about what change is being waited for. This is the territory of monitor-like constructions (see below), as opposed to the yield/sleep-like constructions that Gil was initially proposing. For these, the next question is whether this should be more like Thread.yield() vs Thread.sleep(). If it could be like sleep, then new a API might not be needed: JVMs could implement sleep(0, 1) (or any small value of nanosec arg) using a PAUSE instruction on platforms supporting them. But sleep is also required to check interrupt status, which means that at least one extra load would be needed in addition to PAUSE. So it seems that something yield-like (with no obligation to check interrupt) is still desirable, leading either to my original suggestion: /** * A hint to the platform that the current thread is momentarily * unable to progress... */ public static void spinYield(); OR something more analogous to sleep, but without interrupt check: /** * A hint to the platform that the current thread is unlikely * to progress for the indicated duration in nanoseconds... */ public static void yield(long nanoSeconds); When available, JVMs would implement small values via PAUSE, larger by calling plain yield(), but in no case promising to return in either at least or at most the given duration. While it is a little odd, it seems to cover John Rose's desire to force an argument dependency. I think either of these would be OK. We'd use this functionality in a few places inside java.util.concurrent. We can't do so as aggressively as some users might like: we generally bound spin-then-block constructions to an approximation of best-case unavailability (lock-hold etc) times, so as to work OK when systems are heavily loaded. When we have done more than this, we have gotten justifiable complaints. But we also have "try" and "poll" forms of almost everything so users can add additional spins themselves. Or create custom sync using base capabilities. Back to the question of monitor-like constructions: Low-level memory-wait instructions are limited in what they can wait for -- basically only changes at fixed addresses. This is not an easy fit for GCed languages where the address of a variable might change. However, there is at least one case where this can work: park/unpark are (and are nearly forced to be) implemented using an underlying native-level semaphore. So it should be possible to at least sometimes use MWAIT inside park to reduce unproductive context switches. The "sometimes" part might vary across platforms. In particular, the implementation of LockSupport.parkNanos could always just invoke an MWAIT-based intrinsic for small arguments. It would be great if people working on hotspot explored such options. So for this particular application of MWAIT-like support (which should be vastly more common than other uses anyway), we could side-step for now analogs of proposed C++ "synchronics" and the like that would require unknown mechanics on still-unreleased VarHandles. -Doug From xueming.shen at oracle.com Wed Oct 14 15:10:54 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 14 Oct 2015 08:10:54 -0700 Subject: RFR: 6907252: ZipFileInputStream Not Thread-Safe In-Reply-To: <561E56AA.6010405@oracle.com> References: <561E56AA.6010405@oracle.com> Message-ID: <561E707E.5090305@oracle.com> On 10/14/15 6:20 AM, Se?n Coffey wrote: > Looking to tighten up access between the java and native level zip > library calls. This extra check should ensure that we don't hit SEGV > on thread races. > > I've also taken the opportunity to make the ZStreamRef address > variable volatile. I'm still getting reports of zip crashes in the > deflate, deflate_slow functions [1] but can't reproduce the failure. > Access to the ZStreamRef address variable seems to be synchronized > correctly in all calling sites. I'm just be extra sure for possible > sharing across multiple threads. > > bug report : https://bugs.openjdk.java.net/browse/JDK-6907252 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.6907252/webrev/ > > [1] https://bugs.openjdk.java.net/browse/JDK-8028216 > looks good for me. -sherman From uschindler at apache.org Wed Oct 14 15:36:53 2015 From: uschindler at apache.org (Uwe Schindler) Date: Wed, 14 Oct 2015 17:36:53 +0200 Subject: java.lang.reflect.Method.copyOf In-Reply-To: <CAPs6152HyeMnK2v1s+mhG_kYuPSP-BcvHYnEFSdyc-mF-H-fSQ@mail.gmail.com> References: <CAPs6152HyeMnK2v1s+mhG_kYuPSP-BcvHYnEFSdyc-mF-H-fSQ@mail.gmail.com> Message-ID: <036401d10696$2855aea0$79010be0$@apache.org> Hi, Just as idea: Why not implement Cloneable for that purpose? Adding new methods does not look like a good idea. ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On > Behalf Of Kasper Nielsen > Sent: Wednesday, October 14, 2015 12:02 PM > To: core-libs-dev > Subject: java.lang.reflect.Method.copyOf > > Hi, > > I was wondering if there is any reason for Method.copyOf (and friends) > being package private. > > I'm trying to make a copy of a large number of Method objects in some > performance sensitive code to avoid sharing the isAccessible flag. > > And while this is fairly fast. > > Class<?> declaringClass = method.getDeclaringClass(); try { > return declaringClass.getDeclaredMethod(method.getName(), > method.getParameterTypes()); > } catch (NoSuchMethodException e) { > throw new RuntimeException("This should never happen", e); } > > I would to like to avoid the performance penalty if possible. > > - Kasper From steve.drach at oracle.com Wed Oct 14 16:07:13 2015 From: steve.drach at oracle.com (Steve Drach) Date: Wed, 14 Oct 2015 09:07:13 -0700 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files Message-ID: <F7C2BACE-2E86-4058-8136-F565799494F8@oracle.com> Hi, Let?s try again, this time there are tests. Please review the following webrev that adds support for multi-release jars as specified in JEP-238. Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305 Webrev: http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ A multi-release jar file is a jar file that contains a manifest with a main attribute named "Multi-Release", and also contains a directory "META-INF/versions" with subdirectories that contain versioned entries segregated by the major version of Java platform releases. A versioned entry, with a version n, in the "META-INF/versions/{n}" directory overrides the unversioned root entry as well as any entry with a version number i where i < n. The changes in this webrev implement an aliasing mechanism in JarEntry so that when a JarFile client retrieves a JarEntry, the data from the entry pointed to by the alias is returned. There are methods to configure whether or not aliasing is enabled, and if it is, which version of an entry the alias points to. When a JarFile is used by a class loader to load class resources, the default version retrieved is the runtime version of the Java platform (i.e. a version 9 entry is returned when the platform is JDK 9). This mechanism can be configured by System properties. Thanks, Steve From mandy.chung at oracle.com Wed Oct 14 16:13:40 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 14 Oct 2015 09:13:40 -0700 Subject: RFR: JDK-8046565: Platform Logger API and Service In-Reply-To: <561E3A9A.9050807@oracle.com> References: <561660DA.7070900@oracle.com> <8D8890A3-2337-4178-BA5C-CC32DE12F27D@oracle.com> <561E3A9A.9050807@oracle.com> Message-ID: <6241BCF8-C6A3-4E64-94E9-5E70CEF4A829@oracle.com> > On Oct 14, 2015, at 4:20 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote: > > Hi Mandy, > > On 14/10/15 07:21, Mandy Chung wrote: >> >>> On Oct 8, 2015, at 5:26 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote: >>> >>> webrev: >>> http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/webrev.01/ >> >> System.Logger >> >> Several log methods throws NPE if the level is legible and the parameter is null. E.g. >> * @throws NullPointerException if {@code level} is {@code null}, or if the level >> * is loggable and {@code msgSupplier} is {@code null}. >> >> Should it throw NPE if the input parameter is null regardless of whether the level is loggable? > > Yes probably. The reason it is like that is that it mimics > what java.util.logging.Logger does (at least for message suppliers), but > it is probably not a good idea to propagate this bad practice. > > I will change System.Logger spec to mandate to always throw NPE > if Supplier<String> is null - and ensure that the implementations > we have follow the spec. There are other methods having similar @throws that should be updated as well. > >> RuntimePermission(?loggerFinder?) is required when >> 1. a LoggerFinder provider is instantiated >> 2. LoggerFinder::getLoggerFinder() is called >> 3. LoggerFinder::getLogger is called >> >> This is very specific to finding system logger (more than just the provider construction check). It does seem worth defining a specific Permission type for it e.g. LoggerPermission. Since LoggerFinder::getLogger requires permission check, does LoggerFinder::getLoggerFinder() need the explicit permission check? We will need to consult with the security experts. > > This is why it was first called "controlSystemLoggers" until > somebody suggested to change it to "loggerFinder" ;-) > But since it protects all access to LoggerFinder then naming > it "loggerFinder" was actually a good suggestion :-) > > When I started working on this I added a new LoggerPermission > class similar to java.util.logging.Permission. I received > strong pushback against it and it was suggeseted I used > RuntimePermission instead - which suits me well. > I slightly prefer a specific Permission type for this. > I believe LoggerFinder::getLoggerFinder() should be protected by > the permission. This sounds reasonable to me. > : >> LazyLoggers::getLazyLogger(String name, Class<?> caller) >> - does it need permission check? it?s currently commented out > > This class should already be protected by packageAccess checks and > module access checks (since it's not in an exported package). > So I don't think it needs the additional permission check > which should have been performed (if needed) by upstream code. > The commented code should obviously go away before pushing, > I left it to elicit confirmation that it was OK to leave > it out. Take it out then. I was not sure if you have it commented as a question to the reviewer or not. > >> public class LoggerWrapper<L extends Logger> extends AbstractLoggerWrapper<L> >> implements Logger, PlatformLoggerBridge >> >> - AbstractLoggerWrapper implements Logger, PlatformLoggerBridge, ConfigurableLoggerBridgem. Is "implements Logger, PlatformLoggerBridge? needed at all? > What I tried to point out is the class declaration. Should LoggerWrapper simply extend AbstractLoggerWrapper (and drop the ?implements?.?)? It?s minor and try to understand why you declare ?implements?? explicitly that are the super interfaces of AbstractLoggerWrapper. > : > > >> SimpleConsoleLogger.Formatting >> static final String FORMAT_PROP_KEY = >> "java.util.logging.SimpleFormatter.format"; >> - is this used when java.logging is not present? It?s for the simple console logger formatting. If so, the property name should be renamed to idk.logger.xxx? > > Yes. It's used both by java.util.logging and the SimpleConsoleLogger. > I think you did introduce this property - it was also used both by > java.util.logging and the PlatformLogger proxy - I simply > translated the code from the proxy to SimpleConsoleLogger. Yes I did. It?s a standard property that java.util.logging supports. PlatformLogger proxy used it. I think we should look into some simple mechanism for simple console configuration when java.logging is not present (a RFE to cover it). It would be confusing to reuse ?java.util.logging.? property to configure simple console in the absence of java.logging. > SimpleConsoleLogger are also used as temporary loggers when > LogManager is not initialized and has no custom configuration, > just as PlatformLogger used to do. That functionality was > simply translated from PlatformLogger to LazyLoggers/BootstrapLogger. That?s the next big thing to review. > >> Can you explain the difference of sun.util.logging and sun.util.logger package? I think the reason to have two different packages is to make sure that sun.util.logger not used by other modules. What other issue to put the classes in sun.util.logging - the existing package? I don?t have any issue to create a new package but the name is hard to differentiate. Maybe rename sun.util.logger to jdk.internal.logger if not in sun.util.logging? > > sun.util.logging contains the 'legacy' PlatformLogger and all > the code needed to bridge PlatformLogger. > It can go away when we get to the point where nobody uses > PlatformLogger any more. > > : > In an ideal situation then in the mid-long term sun.util.logging > should hopefully disappear from java.base - and only > sun.util.logger would remain. > I?m glad that it?s a plan to migrate existing uses of sun.util.logging.PlatformLogger to System.Logger and ultimately PlatformLogger will go away. > Do you think it would be preferable to move all the classes > from sun.util.logger over to sun.util.logging? > The distinction between new and legacy/bridge might be less > clear, and there might be a little more risk of having modules > which already read sun.util.logging foraging inside - but it > could be worth it as it would mean one less new package? I think it?s better to rename the new package to jdk.internal.logger to make it easier to distinct. Mandy From Alan.Bateman at oracle.com Wed Oct 14 16:16:29 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Oct 2015 17:16:29 +0100 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <F7C2BACE-2E86-4058-8136-F565799494F8@oracle.com> References: <F7C2BACE-2E86-4058-8136-F565799494F8@oracle.com> Message-ID: <561E7FDD.9010500@oracle.com> On 14/10/2015 17:07, Steve Drach wrote: > Hi, > > Let?s try again, this time there are tests. Please review the following webrev that adds support for multi-release jars as specified in JEP-238. Good to have tests this time :-) I see several JAR files in the webrev, shouldn't the tests create these so that we don't have to check in binary files? I realize the signed case might be a bit of work but there may be some security tests that could provide examples. -Alan From nikolay at azulsystems.com Wed Oct 14 16:02:30 2015 From: nikolay at azulsystems.com (Nikolay Gorshkov) Date: Wed, 14 Oct 2015 19:02:30 +0300 Subject: RFR [7] 8133206: "java.lang.OutOfMemoryError: unable to create new native thread" caused by upgrade to zlib 1.2.8 Message-ID: <561E7C96.9010207@azulsystems.com> Please, review the following fix in core-libs area for the bug https://bugs.openjdk.java.net/browse/JDK-8133206 : http://cr.openjdk.java.net/~nikgor/8133206/jdk7u-dev/webrev.00/ The bug is a regression of the recent zlib 1.2.3 => 1.2.8 library update. One of our customers started to see significant increase of native memory usage in production, which actually led to startup failures of one of their service in 32 bit mode. The root cause is that inflate() method in zlib allocates a 32 KB window much more often than before (please, see the bug record for full details), and in some use cases like class loading these windows are then never freed. The fix (its idea was proposed by Mark Adler) is to change the way we call inflate() method of zlib library and process its return result. I fixed 4 points in jdk code. There are several more points in libpng, which is also a part of jdk code, but I didn't touch them - not sure what is our policy about changing the code of 3rd party libraries. The fix was verified: - in the customer's test environment (the problem's gone) - by running JCK-7 - by running regression tests for java/util/jar, java/util/zip, tools/jar, tools/pack200 The changeset is prepared for integration into jdk7u-dev. The only reason for this is that the only reproducer we have is a complicated environment that accepts JDK 7 only. I would say that with 90% probability the same issue exists in both JDK 8 and 9, and the same (or very similar) fix is applicable to them, but unfortunately I can't prove it - we don't have a reproducer for JDK 8 and 9. Please, reply to me directly since I'm not subscribed to these aliases. Thanks, Nikolay From steve.drach at oracle.com Wed Oct 14 16:28:25 2015 From: steve.drach at oracle.com (Steve Drach) Date: Wed, 14 Oct 2015 09:28:25 -0700 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <561E7FDD.9010500@oracle.com> References: <F7C2BACE-2E86-4058-8136-F565799494F8@oracle.com> <561E7FDD.9010500@oracle.com> Message-ID: <62A6505C-9FA6-44D9-A9BC-2FEE650582F5@oracle.com> >> Let?s try again, this time there are tests. Please review the following webrev that adds support for multi-release jars as specified in JEP-238. > Good to have tests this time :-) > > I see several JAR files in the webrev, shouldn't the tests create these so that we don't have to check in binary files? I realize the signed case might be a bit of work but there may be some security tests that could provide examples. The current test directory contains binary jar files. In fact in all the test directories, there are 52 binary .jar files. I added three more. I thought about generating the jar files but the problem I run into is that there are two test classes that use the same files and creating the files twice seemed to be a bit wasteful. I couldn?t figure out a reliable way to have one test class create the files and the other one just use the files. From peter.levart at gmail.com Wed Oct 14 16:39:11 2015 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 14 Oct 2015 18:39:11 +0200 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <561E654E.6040106@oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> Message-ID: <561E852F.1010001@gmail.com> On 10/14/2015 04:23 PM, Alan Bateman wrote: > > On 14/10/2015 15:03, Roger Riggs wrote: >> Hi Alan, >> >> So any user of the Cleaner can take advantage of the mechanism, for >> example in a different package or module. >> For example, Netbeans. > Cleaner + Cleanable need to be public of course so maybe we should > wait for the examples that extend WeakCleanableRef or cast the > Cleanable to a WeakCleanableRef before seeing if this is the right > thing or not. > > -Alan Hi Alan, I think you are referring to Cleaner.WeakCleanable which is public and abstract right? Because Cleaner.WeakCleanableRef is private. Besides being resource-friendly, a WeakCleanable is also a Reference, which means it has the get() method, so users can access the referent through it until the Reference is cleared. This can be useful in data structures where WeakCleanable can be subclassed to hold state that is needed to remove itself from the data structure and act as a [Weak|Soft]Reference so that it's referent is accessible through it. Imagine the following: public class WeakKey<K> extends WeakCleanable { private final hash; private final ConcurrentHashMap<WeakKey<K>, ?> map; public WeakKey(K key, Cleaner c, ConcurrentHashMap<WeakKey<K>, ?> map) { super(key, c); this.hash = key.hashCode(); this.map = map; } public int hashCode() { return hash; } public boolean equals(Object obj) { if (!(obj instanceof WeakKey)) return false; K key = get(); if (key == null) return obj == this; return key == ((WeakKey<?>)obj).get(); } @Override protected void performCleanup() { map.remove(this); } } ... ConcurrentHashMap<WeakKey<K>, Data> map = ... Cleaner cleaner = ... K key = ... Data data = ... map.put(new WeakKey<>(key, cleaner, map), data); Voila, you have a background-auto-cleaning ConcurrentWeakHashMap-like data structure. Regards, Peter From alexander.v.stepanov at oracle.com Wed Oct 14 16:49:30 2015 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Wed, 14 Oct 2015 19:49:30 +0300 Subject: <AWT Dev> [9] RFR 8138838: docs cleanup for java.desktop In-Reply-To: <56125B1B.9070905@oracle.com> References: <740a3bdd-3a72-44ec-b51f-83c98cac07ca@default> <560A6628.5010807@oracle.com> <CA+kOe0_RoiEvvquZ-5aJ401b1oePuDG+7vd0ufzgctpFhUfaLA@mail.gmail.com> <560C8970.50805@oracle.com> <CA+kOe0-YkE_886K0b_OY4G7kmunx9eTG0rxhaoVt8YKUsixFHA@mail.gmail.com> <560D199B.30708@oracle.com> <56125B1B.9070905@oracle.com> Message-ID: <561E879A.6010906@oracle.com> Sorry, just a reminder. If the activity is untimely, then could you please review the following minimum part of fix? http://cr.openjdk.java.net/~avstepan/8138838/webrev.min.00/index.html (some misprints + midget JDK-8138893 fixed). Thanks, Alexander On 10/5/2015 2:12 PM, Alexander Stepanov wrote: > Hello, > > Could you please review the fix for > https://bugs.openjdk.java.net/browse/JDK-8138838 > > Patch + webrev zipped + specdiff report: > http://cr.openjdk.java.net/~avstepan/8138838 > > Just some cosmetic changes for docs (<code>...</code> -> {@code ...} > replacement) + some misprints fixed. > > Not sure if these changes are desired at all for now. > > Thanks, > Alexander > > (Just in case, adding the prehistory and sending a copy to > core-libs-dev). > > > > On 10/1/2015 2:31 PM, Alexander Stepanov wrote: >> Hello Martin, Stuart, >> >> Thank you for the notes, >> >> Yes, the initial utility is quite ugly, I just tried to prepare it as >> quickly as possible hoping that it covers the majority of "trivial" >> replace cases. Yes, it does not process multi-line <code> inclusions. >> >> > s = s.replace( "<CODE>", tag1); >> > s = s.replace( "<Code>", tag1); >> > s = s.replace("</CODE>", tag2); >> > s = s.replace("</Code>", tag2); >> >> - replaced with "s = ln.replaceAll("(?i)<code>", >> "<code>").replaceAll("(?i)</code>", "</code>");" >> >> Unfortunately my Perl/lisp knowledge are zero :) >> >> > Should you publish your specdiff? I guess not - it would be empty! >> For now it contains a single fixed misprint diff, but there are a few >> another misprints at the moment which I'd like to include in the >> patch as well. >> >> So if you don't have objections, I'll delay for a several days and >> then publish a final RFR (probably containing changes in some other >> repos like jaxws, corba or jaxp) which would be more formal >> (containing bug # and the final specdiff report). >> >> Thanks again, >> Alexander >> >> >> On 10/1/2015 9:54 AM, Martin Buchholz wrote: >>> Hi s'marks, >>> You probably don't need to absolutify paths. >>> And you can easily handle multiple args. >>> >>> (just for fun!) >>> Checks for javadoc comment; handles popular html entities; handles >>> multiple lines; handles both tt and code: >>> >>> #!/bin/bash >>> find "$@" -name '*.java' | \ >>> xargs -r perl -p0777i -e \ >>> 'do {} while s~^ >>> *\*.*\K<(tt|code)>((?:[^<>{}\&\@]|&(?:lt|gt|amp);)*)</\1>~$_=$2; >>> s/&lt;/</g; s/&gt;/>/g; s/&amp;/&/g; "{\@code $_}"~mgie' >>> >>> >>> On Wed, Sep 30, 2015 at 6:16 PM, Stuart Marks >>> <stuart.marks at oracle.com <mailto:stuart.marks at oracle.com>> wrote: >>> >>> Hi Alexander, Martin, >>> >>> The challenge of Perl file slurping and Emacs one-liners was too >>> much to bear. >>> >>> This is Java, so one-liners are hardly possible. Still, there are >>> a bunch of improvements that can be made to the Java version. (OK, >>> and I'm showing off a bit.) >>> >>> Take a look at this: >>> >>> http://cr.openjdk.java.net/~smarks/misc/SimpleTagEditorSmarks1.java >>> <http://cr.openjdk.java.net/%7Esmarks/misc/SimpleTagEditorSmarks1.java> >>> >>> I haven't studied the output exhaustively, but it seems to do a >>> reasonably good job for the common cases. I ran it over java.lang >>> and I noticed a few cases where there is markup embedded within >>> <code></code> text, which should be looked at more closely. >>> >>> I don't particularly care if you use my version, but there are >>> some techniques that I'd strongly recommend that you consider >>> using in any such tool. In particular: >>> >>> - Pattern.DOTALL to do multi-line matches >>> - Pattern.CASE_INSENSITIVE >>> - try-with-resources to ensure that files are closed properly >>> - NIO instead of old java.io <http://java.io> APIs, particularly >>> Files.walk() and streams >>> - use Scanner to deal with input file buffering >>> - Scanner's stream support (I recently added this to JDK 9) >>> >>> Enjoy, >>> >>> s'marks >>> >>> >>> >>> On 9/29/15 2:23 PM, Martin Buchholz wrote: >>> >>> Hi Alexander, >>> >>> your change looks good. It's OK to have manual corrections >>> for automated >>> mega-changes like this, as long as they all revert changes. >>> >>> Random comments: >>> >>> Should you publish your specdiff? I guess not - it would be >>> empty! >>> >>> while((s = br.readLine()) != null) { >>> >>> by matching only one line at a time, you lose the ability to >>> make >>> replacements that span lines. Perlers like to "slurp" in the >>> entire file >>> as a single string. >>> >>> s = s.replace( "<CODE>", tag1); >>> s = s.replace( "<Code>", tag1); >>> s = s.replace("</CODE>", tag2); >>> s = s.replace("</Code>", tag2); >>> >>> Why not use case-insensitive regex? >>> >>> Here's an emacs-lisp one-liner I've been known to use: >>> >>> (defun tt-code () >>> (interactive) >>> (query-replace-regexp >>> "<\\(tt\\|code\\)>\\([^&<>\\\\]+\\)</\\1>" "{@code >>> \\2}")) >>> >>> With more work, one can automate transformation of embedded >>> things like &lt; >>> >>> But of course, it's not even possible to transform ALL uses of >>> <code> to >>> {@code, if there was imaginative use of nested html tags. >>> >>> >>> On Tue, Sep 29, 2015 at 3:21 AM, Alexander Stepanov < >>> alexander.v.stepanov at oracle.com >>> <mailto:alexander.v.stepanov at oracle.com>> wrote: >>> >>> Updated: a few manual corrections were made (as @linkplain >>> tags displays >>> nested {@code } literally): >>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch >>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/jdk.patch> >>> -checked with specdiff (which of course does not cover >>> documentation for >>> internal packages), no unexpected diffs detected. >>> >>> Regards, >>> Alexander >>> >>> >>> On 9/27/2015 4:52 PM, Alexander Stepanov wrote: >>> >>> Hello Martin, >>> >>> Here is some simple app. to replace <code></code> tags >>> with a new-style >>> {@code } one (which is definitely not so elegant as >>> the Perl one-liners): >>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/SimpleTagEditor.java >>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/SimpleTagEditor.java> >>> >>> >>> Corresponding patch for jdk and replacement log (~62k >>> of the tag changes): >>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch >>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/jdk.patch> >>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/replace.log >>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/replace.log> >>> (sorry, I have to check the correctness of the patch >>> with specdiff yet, >>> so this is rather demo at the moment). >>> >>> Don't know if these changes (cosmetic by nature) are >>> desired for now or >>> not. Moreover, probably some part of them should go to >>> another repos (e.g., >>> awt, swing -> "client" instead of "dev"). >>> >>> Regards, >>> Alexander >>> >> > From daniel.fuchs at oracle.com Wed Oct 14 17:08:13 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 14 Oct 2015 19:08:13 +0200 Subject: RFR 8068887 : java.lang.Throwable could use Collections.emptyList for suppressedException In-Reply-To: <157A7676-F207-4274-A9BD-3DAE47E1E39E@oracle.com> References: <561BCD19.9060408@oracle.com> <9411EB09-AE2C-4A7A-A6E9-E9B44F5E030A@oracle.com> <561F0E18.10006@oracle.com> <157A7676-F207-4274-A9BD-3DAE47E1E39E@oracle.com> Message-ID: <561E8BFD.6000009@oracle.com> Hi Vyom, I will push this for you. best regards, -- daniel On 13/10/15 17:39, Mandy Chung wrote: > >> On Oct 14, 2015, at 7:23 PM, vyom <vyom.tewari at oracle.com> wrote: >> >> Hi All, >> >> Please find the updated code, i fixed the missing space. >> >> http://cr.openjdk.java.net/~vtewari/8068887/webrev.0.1/webrev/ <http://cr.openjdk.java.net/%7Evtewari/8068887/webrev.0.1/webrev/> >> > > Looks fine. > >> there are 3 less class loaded(455 vs 452) for simple hello world program. >> : > > Thanks. > Mandy > From daniel.fuchs at oracle.com Wed Oct 14 17:12:07 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 14 Oct 2015 19:12:07 +0200 Subject: RFR: JDK-8046565: Platform Logger API and Service In-Reply-To: <6241BCF8-C6A3-4E64-94E9-5E70CEF4A829@oracle.com> References: <561660DA.7070900@oracle.com> <8D8890A3-2337-4178-BA5C-CC32DE12F27D@oracle.com> <561E3A9A.9050807@oracle.com> <6241BCF8-C6A3-4E64-94E9-5E70CEF4A829@oracle.com> Message-ID: <561E8CE7.9020609@oracle.com> On 14/10/15 18:13, Mandy Chung wrote: > There are other methods having similar @throws that should be updated as well. Yes - sorry - I meant I would do it for the method that takes Object as well. >> When I started working on this I added a new LoggerPermission >> class similar to java.util.logging.Permission. I received >> strong pushback against it and it was suggeseted I used >> RuntimePermission instead - which suits me well. >> > > I slightly prefer a specific Permission type for this. I am reluctant to add LoggerPermission back. Not only because I'd have to find a home for it - but also because RuntimePermission("loggerFinder") seems appropriate and conforms to what other service implementation do (and it doesn't add any new class) >>> LazyLoggers::getLazyLogger(String name, Class<?> caller) >>> - does it need permission check? it?s currently commented out >> >> This class should already be protected by packageAccess checks and >> module access checks (since it's not in an exported package). >> So I don't think it needs the additional permission check >> which should have been performed (if needed) by upstream code. >> The commented code should obviously go away before pushing, >> I left it to elicit confirmation that it was OK to leave >> it out. > > Take it out then. I was not sure if you have it commented as a question to the reviewer or not. Thanks :-) Will do. >>> public class LoggerWrapper<L extends Logger> extends AbstractLoggerWrapper<L> >>> implements Logger, PlatformLoggerBridge >>> >>> - AbstractLoggerWrapper implements Logger, PlatformLoggerBridge, ConfigurableLoggerBridgem. Is "implements Logger, PlatformLoggerBridge? needed at all? >> > > What I tried to point out is the class declaration. Should LoggerWrapper simply extend AbstractLoggerWrapper (and drop the ?implements?.?)? It?s minor and try to understand why you declare ?implements?? explicitly that are the super interfaces of AbstractLoggerWrapper. Oh sorry - I misunderstood your comment. That's an oversight indeed, I will fix it. >>> SimpleConsoleLogger.Formatting >>> static final String FORMAT_PROP_KEY = >>> "java.util.logging.SimpleFormatter.format"; >>> - is this used when java.logging is not present? It?s for the simple console logger formatting. If so, the property name should be renamed to idk.logger.xxx? >> >> Yes. It's used both by java.util.logging and the SimpleConsoleLogger. >> I think you did introduce this property - it was also used both by >> java.util.logging and the PlatformLogger proxy - I simply >> translated the code from the proxy to SimpleConsoleLogger. > > Yes I did. It?s a standard property that java.util.logging supports. PlatformLogger proxy used it. I think we should look into some simple mechanism for simple console configuration when java.logging is not present (a RFE to cover it). It would be confusing to reuse ?java.util.logging.? property to configure simple console in the absence of java.logging. It can be useful too if you want to have ms precision in time stamps. I agree it is strange to honor this contract when java.logging is not there. On the other hand - it might be simpler to always honor the contract. Let me think on it. >> SimpleConsoleLogger are also used as temporary loggers when >> LogManager is not initialized and has no custom configuration, >> just as PlatformLogger used to do. That functionality was >> simply translated from PlatformLogger to LazyLoggers/BootstrapLogger. > > That?s the next big thing to review. > >> >>> Can you explain the difference of sun.util.logging and sun.util.logger package? I think the reason to have two different packages is to make sure that sun.util.logger not used by other modules. What other issue to put the classes in sun.util.logging - the existing package? I don?t have any issue to create a new package but the name is hard to differentiate. Maybe rename sun.util.logger to jdk.internal.logger if not in sun.util.logging? >> >> sun.util.logging contains the 'legacy' PlatformLogger and all >> the code needed to bridge PlatformLogger. >> It can go away when we get to the point where nobody uses >> PlatformLogger any more. >> >> : >> In an ideal situation then in the mid-long term sun.util.logging >> should hopefully disappear from java.base - and only >> sun.util.logger would remain. >> > > I?m glad that it?s a plan to migrate existing uses of sun.util.logging.PlatformLogger to System.Logger and ultimately PlatformLogger will go away. > >> Do you think it would be preferable to move all the classes >> from sun.util.logger over to sun.util.logging? >> The distinction between new and legacy/bridge might be less >> clear, and there might be a little more risk of having modules >> which already read sun.util.logging foraging inside - but it >> could be worth it as it would mean one less new package? > > I think it?s better to rename the new package to jdk.internal.logger to make it easier to distinct. OK - I will do the renaming then. -- daniel > > Mandy > From Roger.Riggs at Oracle.com Wed Oct 14 17:43:48 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 14 Oct 2015 13:43:48 -0400 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <561E654E.6040106@oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> Message-ID: <561E9454.6030700@Oracle.com> Hi Alan, Mandy, I looked at a few of the many uses of finalize and the likely changes. The zip Inflater and Deflater are relatively simple cases. Some finalizers are not used and can be removed. The sun.net.www.MeteredStream example subclasses PhantomCleanable to add the state and cleanup behavior. http://cr.openjdk.java.net/~rriggs/webrev-cleaning-finalizers/ Some of the harder cases will take more time to disentangle the cleanup code. For example, ZipFile, and FileIn/OutputStream (Peter has prototyped this). Roger On 10/14/2015 10:23 AM, Alan Bateman wrote: > > On 14/10/2015 15:03, Roger Riggs wrote: >> Hi Alan, >> >> So any user of the Cleaner can take advantage of the mechanism, for >> example in a different package or module. >> For example, Netbeans. > Cleaner + Cleanable need to be public of course so maybe we should > wait for the examples that extend WeakCleanableRef or cast the > Cleanable to a WeakCleanableRef before seeing if this is the right > thing or not. > > -Alan From kevinb at google.com Wed Oct 14 17:56:06 2015 From: kevinb at google.com (Kevin Bourrillion) Date: Wed, 14 Oct 2015 10:56:06 -0700 Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <5618498D.2040807@oracle.com> References: <5616FEB5.5090104@oracle.com> <CACzrW9A3MZja2wxsHZ7E0vSupkMJXMTQDqMQRjV548ArAF57Hw@mail.gmail.com> <5618498D.2040807@oracle.com> Message-ID: <CAGKkBksRc1u2=ELyYxvKy69ux61uM8UnaUrbzmvXMgkwGLi8jQ@mail.gmail.com> (Sorry that Guava questions were asked and I didn't notice this thread sooner.) Note that we have empirically learned through our Lists/Sets/Maps factory classes that varargs factory methods for *mutable* collections are almost entirely useless. For one thing, it's simply not common to have a hardcoded set of initial values yet still actually need to modify the contents later. When that does come up, the existing workarounds just aren't bad at all: (a) Set<Foo> foos = new HashSet<>(asList(foo1, foo2, foo3)); // static import, of course (b) static final Set<Foo> INITIAL_VALUES = Set.of(foo1, foo2, foo3); . . . Set<Foo> foos = new HashSet<>(INITIAL_VALUES); (c) Set<Foo> foos = new HashSet<>(); Collections.addAll(foos, foo1, foo2, foo3); Note that (c) is a two-liner. But a two-liner is really only bad in the *immutable* case (because you might be initializing a static final). It's of little harm in the mutable case. Anyway, since we created these methods, they became an attractive nuisance, and thousands of users reach for them who would have been better off in every way using an immutable collection. Our fondest desire is to one day be able to delete them. So, obviously, my strong recommendation is not to add these to ArrayList, etc. On Fri, Oct 9, 2015 at 4:11 PM, Stuart Marks <stuart.marks at oracle.com> wrote: Now, Guava handles this use case by providing a family of copying factories > that can accept an array, a Collection, an Iterator, or an Iterable. These > are all useful, but for JEP 269, we wanted to focus on the "collection > literal like" APIs and not expand the proposal to include a bunch of > additional factory methods. Since we need to have a varargs method anyway, > it seemed reasonable to arrange it so that it could easily accept an array > as well. > A decision to support only varargs and arrays is reasonable. However, I don't see the advantage in using the same method name for both. In Guava, it's clear what the difference between ImmutableList.of(aStringArray) and ImmutableList.copyOf(aStringArray) is. Does anybody care about LinkedHashSet? Assuming you go ahead with this for mutable collection types despite the above, then YES, absolutely. Accidental dependence on hash order has always been a runaway problem in our codebase that has made every single major JDK upgrade difficult. And the memory cost of LHS over HS isn't nearly as great as HS is already paying over a lean immutable set. The use of HashMap and HashSet themselves should be discouraged. (Even I had to fight the temptation to add "except when memory is at a premium" to that! But it makes no sense. That's like "if you want to lose weight, then accompany your giant pasta dinner and chocolate cake with a *Diet* Coke.") 3. Duplicate handling. >>> >>> My current thinking is for the Set and Map factories to throw >>> IllegalArgumentException if a duplicate element or key is detected. >>> >> +1 To the other question: the reason we chose 11 as the cutoff is that we determined that there would be no logical basis for exactly where to do it, so we looked for an illogical basis. Sometimes you'll be at 10, all the way up, you're at 10 and where can you go from there? Where? Nowhere. So this way, if we need that extra push over the cliff, we can go up to 11. -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com From Alan.Bateman at oracle.com Wed Oct 14 19:04:05 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Oct 2015 20:04:05 +0100 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <62A6505C-9FA6-44D9-A9BC-2FEE650582F5@oracle.com> References: <F7C2BACE-2E86-4058-8136-F565799494F8@oracle.com> <561E7FDD.9010500@oracle.com> <62A6505C-9FA6-44D9-A9BC-2FEE650582F5@oracle.com> Message-ID: <561EA725.6080105@oracle.com> On 14/10/2015 17:28, Steve Drach wrote: > The current test directory contains binary jar files. In fact in all the test directories, there are 52 binary .jar files. I know but we need to work to remove those. > I added three more. I thought about generating the jar files but the problem I run into is that there are two test classes that use the same files and creating the files twice seemed to be a bit wasteful. I couldn?t figure out a reliable way to have one test class create the files and the other one just use the files. I'm not aware of anything in jtreg that would give you the @BeforeSuite-like support. One could use file locks to have it be setup in one place but it's probably more trouble that it is worth. How expensive is it to create them? -Alan From xueming.shen at oracle.com Wed Oct 14 19:07:22 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 14 Oct 2015 12:07:22 -0700 Subject: RFR [7] 8133206: "java.lang.OutOfMemoryError: unable to create new native thread" caused by upgrade to zlib 1.2.8 In-Reply-To: <561E7C96.9010207@azulsystems.com> References: <561E7C96.9010207@azulsystems.com> Message-ID: <561EA7EA.9050006@oracle.com> On 10/14/2015 09:02 AM, Nikolay Gorshkov wrote: > Please, review the following fix in core-libs area for the bug > https://bugs.openjdk.java.net/browse/JDK-8133206 : > > http://cr.openjdk.java.net/~nikgor/8133206/jdk7u-dev/webrev.00/ > > The bug is a regression of the recent zlib 1.2.3 => 1.2.8 library > update. One of our customers started to see significant increase > of native memory usage in production, which actually led to startup > failures of one of their service in 32 bit mode. > > The root cause is that inflate() method in zlib allocates a 32 KB > window much more often than before (please, see the bug record for > full details), and in some use cases like class loading these windows > are then never freed. Hi Nikolay, Can you be more specific about the "class loading cases" above? Sounds more like we have a memory leaking here (the real root cause)? for example the inflateEnd() never gets called? From the doc/impl in inflate() it appears the proposed change should be fine, though it's a little hacky, as you never know if it starts to return Z_OK from some future release(s). Since the "current" implementation never returns Z_OK, it might be worth considering to keep the Z_OK logic asis in Inflater.c, together with the Z_BUF_ERROR, just in case? I would be desired to add some words in Inflater.c to remind the future maintainer why we switched from partial to finish and why to check z_buf_error. ------------------------------------------------------------------------------------------- inflate.c In this implementation, the flush parameter of inflate() only affects the return code (per zlib.h). inflate() always writes as much as possible to strm->next_out, given the space available and the provided input--the effect documented in zlib.h of Z_SYNC_FLUSH. Furthermore, inflate() always defers the allocation of and copying into a sliding window until necessary, which provides the effect documented in zlib.h for Z_FINISH when the entire input stream available. So the only thing the flush parameter actually does is: when flush is set to Z_FINISH, inflate() cannot return Z_OK. Instead it will return Z_BUF_ERROR if it has not reached the end of the stream. ... if (((in == 0 && out == 0) || flush == Z_FINISH) && ret == Z_OK) ret = Z_BUF_ERROR; return ret; ------------------------------------------------------------------------------------------- -Sherman From steve.drach at oracle.com Wed Oct 14 19:12:53 2015 From: steve.drach at oracle.com (Steve Drach) Date: Wed, 14 Oct 2015 12:12:53 -0700 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <561EA725.6080105@oracle.com> References: <F7C2BACE-2E86-4058-8136-F565799494F8@oracle.com> <561E7FDD.9010500@oracle.com> <62A6505C-9FA6-44D9-A9BC-2FEE650582F5@oracle.com> <561EA725.6080105@oracle.com> Message-ID: <F0979CC5-B143-4C4A-9F1D-B9917B9EABBC@oracle.com> >> The current test directory contains binary jar files. In fact in all the test directories, there are 52 binary .jar files. > I know but we need to work to remove those. I figured that might be the response, but thought it was worth the try ;-) > > >> I added three more. I thought about generating the jar files but the problem I run into is that there are two test classes that use the same files and creating the files twice seemed to be a bit wasteful. I couldn?t figure out a reliable way to have one test class create the files and the other one just use the files. > I'm not aware of anything in jtreg that would give you the @BeforeSuite-like support. One could use file locks to have it be setup in one place but it's probably more trouble that it is worth. How expensive is it to create them? I don?t know, but probably not that expensive, basically for multi-release jar it?s 3 compiles and writing to a jarOutputStream(). I?ll do it. From paul.sandoz at oracle.com Wed Oct 14 19:36:39 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 14 Oct 2015 21:36:39 +0200 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <F0979CC5-B143-4C4A-9F1D-B9917B9EABBC@oracle.com> References: <F7C2BACE-2E86-4058-8136-F565799494F8@oracle.com> <561E7FDD.9010500@oracle.com> <62A6505C-9FA6-44D9-A9BC-2FEE650582F5@oracle.com> <561EA725.6080105@oracle.com> <F0979CC5-B143-4C4A-9F1D-B9917B9EABBC@oracle.com> Message-ID: <185D56CD-185A-4803-B718-01BCE02C7C6C@oracle.com> > On 14 Oct 2015, at 21:12, Steve Drach <steve.drach at oracle.com> wrote: > >>> The current test directory contains binary jar files. In fact in all the test directories, there are 52 binary .jar files. >> I know but we need to work to remove those. > > I figured that might be the response, but thought it was worth the try ;-) > A reasonable way forward is to go with pre-baked jar files (it?s not making the current situation particular any worse) then lets try and clear up this aspect in a later push, hopefully using a common mechanism that can be used by all such tests that need to construct jar files. We need a CCC, so i suggest if tests are not ready and approved by the time the CCC is approved then we push what we have. Paul. >> >> >>> I added three more. I thought about generating the jar files but the problem I run into is that there are two test classes that use the same files and creating the files twice seemed to be a bit wasteful. I couldn?t figure out a reliable way to have one test class create the files and the other one just use the files. >> I'm not aware of anything in jtreg that would give you the @BeforeSuite-like support. One could use file locks to have it be setup in one place but it's probably more trouble that it is worth. How expensive is it to create them? > > I don?t know, but probably not that expensive, basically for multi-release jar it?s 3 compiles and writing to a jarOutputStream(). I?ll do it. From brian.burkhalter at oracle.com Wed Oct 14 20:34:38 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 14 Oct 2015 13:34:38 -0700 Subject: JDK 9 RFR of JDK-8136799 Port fdlibm cbrt to Java In-Reply-To: <561BD797.6040803@oracle.com> References: <561BD797.6040803@oracle.com> Message-ID: <4BF95B37-ADB0-4194-9019-0594628A1B58@oracle.com> Hi Joe, On Oct 12, 2015, at 8:53 AM, joe darcy <joe.darcy at oracle.com> wrote: > Please review the next step of porting fdlibm to Java, the cbrt method: > > JDK-8136799 Port fdlibm cbrt to Java > http://cr.openjdk.java.net/~darcy/8136799.3/ FdLibm.java: * I assume that the diffs other than those of the Cbrt class itself are artifacts of webrev creation and no other (significant) changes are present elsewhere in the patch. * Based on code inspection, the cbrt port itself appears to be accurate. CubeRootTests.java: * line 487: ?hypot? -> ?cbrt? * line 504: probably need to insert a blank line after this line and possibly remove the blank line at 507. > A few points of note about the port, there is a transliteration port in the test area for comparison purposes. I also ran these tests against an 8 update release where fdlibm is in C; this helps verify the transliteration port is correct. The small updates to constrain the @build directive in the tests to just the random number library allow the regression tests to be run out-of-the-box against JDK 8 as well as JDK 9. That all sounds good. Reviewed: +1. Brian From john.r.rose at oracle.com Wed Oct 14 20:42:50 2015 From: john.r.rose at oracle.com (John Rose) Date: Wed, 14 Oct 2015 13:42:50 -0700 Subject: java.lang.reflect.Method.copyOf In-Reply-To: <811846492.1473636.1444819134738.JavaMail.zimbra@u-pem.fr> References: <CAPs6152HyeMnK2v1s+mhG_kYuPSP-BcvHYnEFSdyc-mF-H-fSQ@mail.gmail.com> <811846492.1473636.1444819134738.JavaMail.zimbra@u-pem.fr> Message-ID: <35CC1969-D44D-4C4B-B6F6-238AC71A267C@oracle.com> On Oct 14, 2015, at 3:38 AM, Remi Forax <forax at univ-mlv.fr> wrote: > > Given that j.l.r.Method is mutable, the best way to have performance is too encapsulate it in a non mutable class, if possible. OK, I'll bite. Here's a way to make Method its own non-mutable encapsulation, a la List::set or (future feature) frozen arrays. diff --git a/src/java.base/share/classes/java/lang/reflect/AccessibleObject.java b/src/java.base/share/classes/java/lang/reflect/AccessibleObject.java --- a/src/java.base/share/classes/java/lang/reflect/AccessibleObject.java +++ b/src/java.base/share/classes/java/lang/reflect/AccessibleObject.java @@ -120,15 +120,36 @@ * * @param flag the new value for the {@code accessible} flag * @throws SecurityException if the request is denied. + * @throws UnsupportedOperationException if the accessible object is frozen * @see SecurityManager#checkPermission * @see java.lang.RuntimePermission */ - public void setAccessible(boolean flag) throws SecurityException { + public void setAccessible(boolean flag) throws SecurityException, UnsupportedOperationException { + checkFrozen(); SecurityManager sm = System.getSecurityManager(); if (sm != null) sm.checkPermission(ACCESS_PERMISSION); setAccessible0(this, flag); } + protected void checkFrozen() { + if (frozen) throw new UnsupportedOperationException(); + } + + /** + * Make a frozen copy of this accessible object, with the accessible + * bit set to false. If this object is already frozen, return the + * same object. If this object is not already frozen, return a frozen + * copy, with the accessibility flag forced to {@code false}. + */ + public abstract AccessibleObject asNonAccessible(); + + /** + * Return {@code true} if this object was produced by {@link #isNonAccessible}. + */ + public boolean isNonAccessible() { + return frozen; + } + /* Check that you aren't exposing java.lang.Class.<init> or sensitive fields in java.lang.Class. */ private static void setAccessible0(AccessibleObject obj, boolean flag) @@ -166,6 +187,9 @@ // outside this package. boolean override; + // Indicates whether this object is frozen in the non-accessible state. + boolean frozen; + // Reflection factory used by subclasses for creating field, // method, and constructor accessors. Note that this is called // very early in the bootstrapping process. From john.r.rose at oracle.com Wed Oct 14 20:46:40 2015 From: john.r.rose at oracle.com (John Rose) Date: Wed, 14 Oct 2015 13:46:40 -0700 Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <CAGKkBksRc1u2=ELyYxvKy69ux61uM8UnaUrbzmvXMgkwGLi8jQ@mail.gmail.com> References: <5616FEB5.5090104@oracle.com> <CACzrW9A3MZja2wxsHZ7E0vSupkMJXMTQDqMQRjV548ArAF57Hw@mail.gmail.com> <5618498D.2040807@oracle.com> <CAGKkBksRc1u2=ELyYxvKy69ux61uM8UnaUrbzmvXMgkwGLi8jQ@mail.gmail.com> Message-ID: <2C0C7E71-4B00-4316-8256-497DDC77592C@oracle.com> On Oct 14, 2015, at 10:56 AM, Kevin Bourrillion <kevinb at google.com> wrote: > Anyway, since we created these methods, they became an attractive nuisance, > and thousands of users reach for them who would have been better off in > every way using an immutable collection. Our fondest desire is to one day > be able to delete them. So, obviously, my strong recommendation is not to > add these to ArrayList, etc. I agree with Kevin's warning here. Please, (1) make the immutable version easy to get (List.of not ImmutableList.of), and require users to thoughtfully opt into mutability (new ArrayList not ArrayList.of). ? John From steve.drach at oracle.com Wed Oct 14 20:56:06 2015 From: steve.drach at oracle.com (Steve Drach) Date: Wed, 14 Oct 2015 13:56:06 -0700 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <185D56CD-185A-4803-B718-01BCE02C7C6C@oracle.com> References: <F7C2BACE-2E86-4058-8136-F565799494F8@oracle.com> <561E7FDD.9010500@oracle.com> <62A6505C-9FA6-44D9-A9BC-2FEE650582F5@oracle.com> <561EA725.6080105@oracle.com> <F0979CC5-B143-4C4A-9F1D-B9917B9EABBC@oracle.com> <185D56CD-185A-4803-B718-01BCE02C7C6C@oracle.com> Message-ID: <99143F1C-5786-460B-A5E7-DB9EE0B68414@oracle.com> >>>> The current test directory contains binary jar files. In fact in all the test directories, there are 52 binary .jar files. >>> I know but we need to work to remove those. >> >> I figured that might be the response, but thought it was worth the try ;-) >> > > A reasonable way forward is to go with pre-baked jar files (it?s not making the current situation particular any worse) then lets try and clear up this aspect in a later push, hopefully using a common mechanism that can be used by all such tests that need to construct jar files. +1 on the common mechanism. For building jars and other common tasks. It would also be nice to have some form of test sequencing or other way to indicate that multiple tests depend on a common set of artifacts and that set only needs to be created once. From mandy.chung at oracle.com Wed Oct 14 20:57:37 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 14 Oct 2015 13:57:37 -0700 Subject: RFR: JDK-8046565: Platform Logger API and Service In-Reply-To: <561E8CE7.9020609@oracle.com> References: <561660DA.7070900@oracle.com> <8D8890A3-2337-4178-BA5C-CC32DE12F27D@oracle.com> <561E3A9A.9050807@oracle.com> <6241BCF8-C6A3-4E64-94E9-5E70CEF4A829@oracle.com> <561E8CE7.9020609@oracle.com> Message-ID: <17C7339F-2107-49DE-B909-A65D779F0DF1@oracle.com> Addiitional comments: JdkLoggerProvider.java - should the GC?ed referent entries in the application SharedLoggers map be occasionally drained? BootstrapLogger.java In the BootstrapExecutors::join(Runnable r) method: try { getExecutor().submit(r).get(); } catch (InterruptedException | ExecutionException ex) { // should not happen ex.printStackTrace(System.err); } - we should avoid output any debugging code though. typos: indepedent temporarilly // Unfortunately, if we come to here it means we are in the bootsraping // phase where using lambdas is not safe yet - so we have to use a // a data object instead? FYI. jake has changed the system initialization sequence that allows the use of lambda early at startup. That may help in this case that you can revisit this in the future. This reminds me the startup performance. Is there any use System.Logger to log message during startup in JDK 9? Using lambda at startup will have impact to the startup performance. Also I?m curious to know the difference of classes loaded at startup if System.getLogger is called in one of the system class loaded during startup but no log message is output (as typical case is to print debugging message) with and without java.logging. // Not sure whether this is needed: it was in the original // PlatformLogger proxy code: - I don?t understand why sun.util.logger.LazyLoggers$JdkLazyLogger need to be loaded. DetectBackend is loaded only after booted (per the comment) Naming nit: PlatformLoggerBridge - would it be better to move to PlatformLogger.Bridge? It?s nit and I think it reads better and clearly associate with PlatformLogger. Mandy From timo.kinnunen at gmail.com Wed Oct 14 21:48:53 2015 From: timo.kinnunen at gmail.com (Timo Kinnunen) Date: Wed, 14 Oct 2015 23:48:53 +0200 Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <0E130FE0-EECA-4B8F-A8BA-A62529D690F5@univ-mlv.fr> References: <5616FEB5.5090104@oracle.com> <CACzrW9A3MZja2wxsHZ7E0vSupkMJXMTQDqMQRjV548ArAF57Hw@mail.gmail.com> <87025428.3530190.1444485358747.JavaMail.zimbra@u-pem.fr> <CAGB9EW82wrS6Zsg+iaWHgzLxEKL6r5P9aoryS4450h0TfYjBQw@mail.gmail.com> <561DD78D.8070800@oracle.com> <5CCBE2A7-3BF6-41E0-8651-A0DB7D714023@oracle.com> <561e3110.a558c20a.6f12e.fffff6ef@mx.google.com> <0E130FE0-EECA-4B8F-A8BA-A62529D690F5@univ-mlv.fr> Message-ID: <561ecdc6.ea78c20a.a6973.152c@mx.google.com> No, I meant the number should be limited by how many arguments (not including the last varargs array) it is possible to pass in registers without having to spill any of them on the stack on some widely-used architecture like x86-64, for example. This lets clients on it use its full capabilities, doesn?t limit lower-end runtimes and provides a hint about a typical performance profile one could expect. Sent from Mail for Windows 10 From: R?mi Forax Sent: Wednesday, October 14, 2015 14:16 To: Timo Kinnunen;Paul Sandoz Cc: core-libs-dev Subject: RE: RFC: draft API for JEP 269 Convenience Collection Factories You can have 255 parameters for a method, it's perhaps a little too much, isn't it ? cheers, R?mi Le 14 octobre 2015 12:40:15 CEST, Timo Kinnunen <timo.kinnunen at gmail.com> a ?crit : >Hi, > >Alternatively you could create the variants whose parameters can be >passed utilizing "all available registers", whatever that means in >Java context. The rationale is that the reason for preferring variables >over varargs is performance and this way there is no performance left >on the table. > > > >Sent from Mail for Windows 10 > > > >From: Paul Sandoz >Sent: Wednesday, October 14, 2015 11:38 >Cc: core-libs-dev >Subject: Re: RFC: draft API for JEP 269 Convenience Collection >Factories > > > >> On 14 Oct 2015, at 06:18, Stuart Marks <stuart.marks at oracle.com> >wrote: >> I'm not entirely sure what to take from this. If it were clearly >exponential, we could say with confidence that above a certain >threshold there would be vanishingly little benefit adding more >arguments. But since the curve seems to flatten out, maybe this is >pushing us to add more pairs than we had originally thought. The >current draft API has 8 pairs; that seems to leave a few percent of >cases on the table. Obviously we can't get to 100%, but is 97% good >enough? >> > >11 if only for amusement purposes :-) > >Capturing 9 out of 10 cases seems reasonable to me i.e. 5 entries. > >Perhaps a common case for r > 5 entries is a map for the primitive >types and ref (ignoring ?void?), which would push the limit up to 9 >entries. I took a quick browse through the JDK and it is not that >common AFAICT. j.l.invoke tends to use enums for example. There are two >cases in java.ObjectInputStream and sun.misc.ProxyGenerator. > >Paul. From timo.kinnunen at gmail.com Wed Oct 14 21:48:54 2015 From: timo.kinnunen at gmail.com (Timo Kinnunen) Date: Wed, 14 Oct 2015 23:48:54 +0200 Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <CAGKkBksRc1u2=ELyYxvKy69ux61uM8UnaUrbzmvXMgkwGLi8jQ@mail.gmail.com> References: <5616FEB5.5090104@oracle.com> <CACzrW9A3MZja2wxsHZ7E0vSupkMJXMTQDqMQRjV548ArAF57Hw@mail.gmail.com> <5618498D.2040807@oracle.com> <CAGKkBksRc1u2=ELyYxvKy69ux61uM8UnaUrbzmvXMgkwGLi8jQ@mail.gmail.com> Message-ID: <561ecdc8.ea78c20a.a6973.1535@mx.google.com> Hi, That?s intriguing since I wrote a collections library too, covering just Map/Set/List/Stream, with immutable/mutable versions and lots of convenience methods included, but I haven?t noticed such issues. My scope is a lot smaller, of course. It?s also not beholden to the way the Collections Framework does things so I can decide List is immutable, ArrayList is mutable, both will use the same API and there won?t be any subtyping relation between them. Maybe it?s this freedom that makes the difference. I actually have 4 uses of ArrayList.of in a smallish project where they are used for reading and generating configuration files. I get to do things like this in a few places: ArrayList<String> lines = ArrayList.of( "<?xml version='1.0' encoding='UTF-8'?>", "<?profile version='1.0.0'?>", "<profile id='" + ECLIPSE_PROFILE_ID + "' timestamp='" + timestamp + "'>", " <properties size='7'>", // more lines of prefix . . . And also this sort of thing: ArrayList<String> list = ArrayList.of(FILES.replaceAll("^\"|\"$", "").split("\" \"")).removeIf(String::isEmpty); ArrayList<Path> list2 = list.map(Paths::get); If that looks somewhat like a Stream then just imagine what the user experience is like when stepping into it in a debugger ?? More anecdotes: Having methods taking a Collection overloaded with versions taking varargs makes the API a lot more flexible. I chose ArrayList.of(), ArrayList.of(T t) and ArrayList.of(T...ts), and List.of(T...ts) and the [0. . .10] argument variants for List.of(T t0, ... , T tn) completely unscientifically. Sent from Mail for Windows 10 From: Kevin Bourrillion Sent: Wednesday, October 14, 2015 19:56 To: Stuart Marks Cc: core-libs-dev Subject: Re: RFC: draft API for JEP 269 Convenience Collection Factories (Sorry that Guava questions were asked and I didn't notice this thread sooner.) Note that we have empirically learned through our Lists/Sets/Maps factory classes that varargs factory methods for *mutable* collections are almost entirely useless. For one thing, it's simply not common to have a hardcoded set of initial values yet still actually need to modify the contents later. When that does come up, the existing workarounds just aren't bad at all: (a) Set<Foo> foos = new HashSet<>(asList(foo1, foo2, foo3)); // static import, of course (b) static final Set<Foo> INITIAL_VALUES = Set.of(foo1, foo2, foo3); . . . Set<Foo> foos = new HashSet<>(INITIAL_VALUES); (c) Set<Foo> foos = new HashSet<>(); Collections.addAll(foos, foo1, foo2, foo3); Note that (c) is a two-liner. But a two-liner is really only bad in the *immutable* case (because you might be initializing a static final). It's of little harm in the mutable case. Anyway, since we created these methods, they became an attractive nuisance, and thousands of users reach for them who would have been better off in every way using an immutable collection. Our fondest desire is to one day be able to delete them. So, obviously, my strong recommendation is not to add these to ArrayList, etc. On Fri, Oct 9, 2015 at 4:11 PM, Stuart Marks <stuart.marks at oracle.com> wrote: Now, Guava handles this use case by providing a family of copying factories > that can accept an array, a Collection, an Iterator, or an Iterable. These > are all useful, but for JEP 269, we wanted to focus on the "collection > literal like" APIs and not expand the proposal to include a bunch of > additional factory methods. Since we need to have a varargs method anyway, > it seemed reasonable to arrange it so that it could easily accept an array > as well. > A decision to support only varargs and arrays is reasonable. However, I don't see the advantage in using the same method name for both. In Guava, it's clear what the difference between ImmutableList.of(aStringArray) and ImmutableList.copyOf(aStringArray) is. Does anybody care about LinkedHashSet? Assuming you go ahead with this for mutable collection types despite the above, then YES, absolutely. Accidental dependence on hash order has always been a runaway problem in our codebase that has made every single major JDK upgrade difficult. And the memory cost of LHS over HS isn't nearly as great as HS is already paying over a lean immutable set. The use of HashMap and HashSet themselves should be discouraged. (Even I had to fight the temptation to add "except when memory is at a premium" to that! But it makes no sense. That's like "if you want to lose weight, then accompany your giant pasta dinner and chocolate cake with a *Diet* Coke.") 3. Duplicate handling. >>> >>> My current thinking is for the Set and Map factories to throw >>> IllegalArgumentException if a duplicate element or key is detected. >>> >> +1 To the other question: the reason we chose 11 as the cutoff is that we determined that there would be no logical basis for exactly where to do it, so we looked for an illogical basis. Sometimes you'll be at 10, all the way up, you're at 10 and where can you go from there? Where? Nowhere. So this way, if we need that extra push over the cliff, we can go up to 11. -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com From xueming.shen at oracle.com Wed Oct 14 22:35:43 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 14 Oct 2015 15:35:43 -0700 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <F7C2BACE-2E86-4058-8136-F565799494F8@oracle.com> References: <F7C2BACE-2E86-4058-8136-F565799494F8@oracle.com> Message-ID: <561ED8BF.40901@oracle.com> Steve, Any reason the JarEntry.get/setSize() are the only ZipEntry methods get overridden? -Sherman On 10/14/2015 09:07 AM, Steve Drach wrote: > Hi, > > Let?s try again, this time there are tests. Please review the following webrev that adds support for multi-release jars as specified in JEP-238. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 > JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305 > Webrev: http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ > > A multi-release jar file is a jar file that contains a manifest with a main attribute named "Multi-Release", and also contains a directory "META-INF/versions" with subdirectories that contain versioned entries segregated by the major version of Java platform releases. A versioned entry, with a version n, in the "META-INF/versions/{n}" directory overrides the unversioned root entry as well as any entry with a version number i where i< n. > > The changes in this webrev implement an aliasing mechanism in JarEntry so that when a JarFile client retrieves a JarEntry, the data from the entry pointed to by the alias is returned. There are methods to configure whether or not aliasing is enabled, and if it is, which version of an entry the alias points to. > > When a JarFile is used by a class loader to load class resources, the default version retrieved is the runtime version of the Java platform (i.e. a version 9 entry is returned when the platform is JDK 9). This mechanism can be configured by System properties. > > Thanks, > Steve From steve.drach at oracle.com Wed Oct 14 23:04:16 2015 From: steve.drach at oracle.com (Steve Drach) Date: Wed, 14 Oct 2015 16:04:16 -0700 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <561ED8BF.40901@oracle.com> References: <F7C2BACE-2E86-4058-8136-F565799494F8@oracle.com> <561ED8BF.40901@oracle.com> Message-ID: <CC71DAAE-940B-47EB-A2F2-FFB89F2EBAD3@oracle.com> > Any reason the JarEntry.get/setSize() are the only ZipEntry methods get overridden? It didn?t seem necessary. The root entries are the ?public interface?, we?re just providing aliased entry contents. > > -Sherman > > On 10/14/2015 09:07 AM, Steve Drach wrote: >> Hi, >> >> Let?s try again, this time there are tests. Please review the following webrev that adds support for multi-release jars as specified in JEP-238. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 >> JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305 >> Webrev: http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ >> >> A multi-release jar file is a jar file that contains a manifest with a main attribute named "Multi-Release", and also contains a directory "META-INF/versions" with subdirectories that contain versioned entries segregated by the major version of Java platform releases. A versioned entry, with a version n, in the "META-INF/versions/{n}" directory overrides the unversioned root entry as well as any entry with a version number i where i< n. >> >> The changes in this webrev implement an aliasing mechanism in JarEntry so that when a JarFile client retrieves a JarEntry, the data from the entry pointed to by the alias is returned. There are methods to configure whether or not aliasing is enabled, and if it is, which version of an entry the alias points to. >> >> When a JarFile is used by a class loader to load class resources, the default version retrieved is the runtime version of the Java platform (i.e. a version 9 entry is returned when the platform is JDK 9). This mechanism can be configured by System properties. >> >> Thanks, >> Steve > From joe.darcy at oracle.com Wed Oct 14 23:17:54 2015 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 14 Oct 2015 16:17:54 -0700 Subject: JDK 9 RFR of JDK-8136799 Port fdlibm cbrt to Java In-Reply-To: <4BF95B37-ADB0-4194-9019-0594628A1B58@oracle.com> References: <561BD797.6040803@oracle.com> <4BF95B37-ADB0-4194-9019-0594628A1B58@oracle.com> Message-ID: <561EE2A2.9050806@oracle.com> Hi Brian, On 10/14/2015 1:34 PM, Brian Burkhalter wrote: > Hi Joe, > > On Oct 12, 2015, at 8:53 AM, joe darcy <joe.darcy at oracle.com > <mailto:joe.darcy at oracle.com>> wrote: > >> Please review the next step of porting fdlibm to Java, the cbrt method: >> >> JDK-8136799 Port fdlibm cbrt to Java >> http://cr.openjdk.java.net/~darcy/8136799.3/ >> <http://cr.openjdk.java.net/%7Edarcy/8136799.3/> > > FdLibm.java: > * I assume that the diffs other than those of the Cbrt class itself > are artifacts of webrev creation and no other (significant) changes > are present elsewhere in the patch. > * Based on code inspection, the cbrt port itself appears to be accurate. > > CubeRootTests.java: > * line 487: ?hypot? -> ?cbrt? > * line 504: probably need to insert a blank line after this line and > possibly remove the blank line at 507. Corrected and pushed; thanks, -Joe From joe.darcy at oracle.com Thu Oct 15 00:31:45 2015 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 14 Oct 2015 17:31:45 -0700 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <99143F1C-5786-460B-A5E7-DB9EE0B68414@oracle.com> References: <F7C2BACE-2E86-4058-8136-F565799494F8@oracle.com> <561E7FDD.9010500@oracle.com> <62A6505C-9FA6-44D9-A9BC-2FEE650582F5@oracle.com> <561EA725.6080105@oracle.com> <F0979CC5-B143-4C4A-9F1D-B9917B9EABBC@oracle.com> <185D56CD-185A-4803-B718-01BCE02C7C6C@oracle.com> <99143F1C-5786-460B-A5E7-DB9EE0B68414@oracle.com> Message-ID: <561EF3F1.7020905@oracle.com> On 10/14/2015 1:56 PM, Steve Drach wrote: >>>>> The current test directory contains binary jar files. In fact in all the test directories, there are 52 binary .jar files. >>>> I know but we need to work to remove those. >>> I figured that might be the response, but thought it was worth the try ;-) >>> >> A reasonable way forward is to go with pre-baked jar files (it?s not making the current situation particular any worse) then lets try and clear up this aspect in a later push, hopefully using a common mechanism that can be used by all such tests that need to construct jar files. > +1 on the common mechanism. For building jars and other common tasks. > > It would also be nice to have some form of test sequencing or other way to indicate that multiple tests depend on a common set of artifacts and that set only needs to be created once. > You can put multiple @build and @run directives in a test. In particular, you can build and run multiple Java sources files, such as sources for different logical tests, from a single jtreg @test file. I believe you can use this capability to implement sequencing. HTH, -Joe From xueming.shen at oracle.com Thu Oct 15 03:00:17 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 14 Oct 2015 20:00:17 -0700 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <CC71DAAE-940B-47EB-A2F2-FFB89F2EBAD3@oracle.com> References: <F7C2BACE-2E86-4058-8136-F565799494F8@oracle.com> <561ED8BF.40901@oracle.com> <CC71DAAE-940B-47EB-A2F2-FFB89F2EBAD3@oracle.com> Message-ID: <561F16C1.6090702@oracle.com> On 10/14/15 4:04 PM, Steve Drach wrote: >> Any reason the JarEntry.get/setSize() are the only ZipEntry methods get overridden? > It didn?t seem necessary. The root entries are the ?public interface?, we?re just providing aliased entry contents. > It does not sound right. The "exported public interface" of a jar file, or a multi-release-jar file is NOT those root entries, but the name of those entries. As the updated/newly added spec says, "The returned JarEntry is the versioned entry corresponding to the given root entry NAME prefixed with the string META-INF/versions/{n}...", So the returned entry should be the one that represents the "versioned entry", with the content of the entry and the meta data of the entry (the compressed size, the various timestamps, the comment...) form the versioned entry, not the root one, if there is a matched versioned entry. The implementation seems not follow this spec, it return the entry that actually is for the root entry, with a link to the versioned one, which serves the purpose of getting the corresponding input stream correctly, and make the verifier work (by simply passing the linked versioned to the verifier). However, all the meta data, accessible from the JarEntry APIs are all "broken", the attributes, certificates and the codeSigners are from the root entry. If my reading is correct, I'm not sure how it can work if someone wants to "verify" an individual signed entry by himself via security APIs, with all meta data from the root entry and the data itself from the versioned entry. I'm not sure if it is a good idea, from performance perspective, to add a "versionEntry" field into the JarEntry to support this feature, given most of the jar files might not be multi-release-jar aware, and the Jar input& output streams dont work with a multi-release jar directly. Why should they all pay a runtime price for it. If we really have to add an extra field, the JarFileEntry might be a better place, and it might be desired to define a new subclass JarFileEntryMR to use when the MR is enabled, instead of adding directly into the existing JarFileEntry. -Sherman On 10/14/2015 09:07 AM, Steve Drach wrote: >>> Hi, >>> >>> Let?s try again, this time there are tests. Please review the following webrev that adds support for multi-release jars as specified in JEP-238. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 >>> JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305 >>> Webrev: http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ >>> >>> A multi-release jar file is a jar file that contains a manifest with a main attribute named "Multi-Release", and also contains a directory "META-INF/versions" with subdirectories that contain versioned entries segregated by the major version of Java platform releases. A versioned entry, with a version n, in the "META-INF/versions/{n}" directory overrides the unversioned root entry as well as any entry with a version number i where i< n. >>> >>> The changes in this webrev implement an aliasing mechanism in JarEntry so that when a JarFile client retrieves a JarEntry, the data from the entry pointed to by the alias is returned. There are methods to configure whether or not aliasing is enabled, and if it is, which version of an entry the alias points to. >>> >>> When a JarFile is used by a class loader to load class resources, the default version retrieved is the runtime version of the Java platform (i.e. a version 9 entry is returned when the platform is JDK 9). This mechanism can be configured by System properties. >>> >>> Thanks, >>> Steve From gil at azul.com Thu Oct 15 03:53:15 2015 From: gil at azul.com (Gil Tene) Date: Thu, 15 Oct 2015 03:53:15 +0000 Subject: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal In-Reply-To: <561E6F04.9030708@cs.oswego.edu> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56164C3C.4050800@cs.oswego.edu> <561E6F04.9030708@cs.oswego.edu> Message-ID: <54AE479E-9891-48FB-AD47-ECED8147DABE@azul.com> I agree on the separation between spin-hinting and monitor-like constructs. But not so much on the analogy to or use of the term "yield" to describe what is intended y spin hints. On the name choice: things that include the word "yield" vs. spinLoopHint():: While the spinYield() example in your e-mail below can work from a semantic point of view in the same code, IMO the word "yield" suggests the exact opposite of what spnLoopHint() is intending to do or hint at: spinLoopHint is motivated by wanting to spin while holding onto the CPU (intentionally not yielding to other processes), and by the wish to improve performance while doing so, primarily by reducing the reaction time to a loop-terminating event. So spinLoopHint() is something that very selfish spinning code does without reducing it's selfishness. In contrast, yield() is virtually always done as an unselfish act (the very word suggests it). The general expectation with yield() calls is that that the OS scheduler can make use of the core for other uses, it is OK to switch away form the current task since the thread may not be making progress, or may be ok with relinquishing resources to be "nice" to others". As such, a yield() generally suggests a system call, a (relatively) large overhead, and a willingness to sacrifice reaction time in order to allow others to make use of the CPU. My preferred choice of the spinLoopHint() name comes directly from how the behavior expectations of of a PAUSE-like instruction are already expressed in relevant documents. E.g. Intel's documentation describes PAUSE instructions as a "Spin Loop Hint". On the no-args vs. "with some arg" variants: With regards to passing a time value (e.g. the yield(long nanoseconds) example in your e-mail below): A spinLoopHint() is a natural fit for loops that already do their own spinning, and as such needs to allow those loop to deal with their own composition, choices around termination conditions, state updates, and choices about backing of or employing time or count based termination behaviors. Choosing and dictating a specific mechanism (nanoseconds) or terminating condition checks will interfere with the compostability of spinLoopHint() into such code. To use a specific example: E.g. the yield(long nanoSeconds) form (even if it's called spinLoopHint(long nanoSeconds)) would not be directly usable in the following code: while (!(doneCond1 || doneCond2 || count++ > backOffThreshld) { spinLoopHint(): } Similarly, a no-args spinLoopHint() will cleanly drop into things like the disruptor's bust spin waitFor() variant (https://github.com/LMAX-Exchange/disruptor/blob/f29b3148c2eef3aa2dc5d5f570d7dde92b2f98ba/src/main/java/com/lmax/disruptor/BusySpinWaitStrategy.java#L28), but something that takes a nanoseconds argument would not. I think that compose-abiliy should be our main driver here. Java code already knows how to spin in many interesting ways. It just needs to have away to hint that reaction time is more important that speed in the spin, and that's what I'm suggesting as the main purpose of a spinLoophint(). See proposed JavaDoc below. ? Gil. /** * Provide the JVM with a hint that this call is made from within a spinning * loop. The JVM may assume that the speed of executing the loop (e.g. in * terms of number of loop executions per second) is less important than the * reaction time to events that would cause the loop to terminate, or than * potential power savings that may be derived from possible execution * choices. The JVM will not slow down the loop execution to a point where * execution will be delayed indefinitely, but other choices of loop execution * speed are system-specific. Note that a nop is a valid implementation of * this hint. */ public static void spinLoopHint() { } > On Oct 14, 2015, at 11:04 PM, Doug Lea <dl at cs.oswego.edu> wrote: > > Some notes after reading follow-ups. > > One question is whether there should be a method that clues in > the JVM about what change is being waited for. This is the territory of > monitor-like constructions (see below), as opposed to the > yield/sleep-like constructions that Gil was initially proposing. > > For these, the next question is whether this should be more > like Thread.yield() vs Thread.sleep(). If it could be like > sleep, then new a API might not be needed: JVMs could > implement sleep(0, 1) (or any small value of nanosec arg) > using a PAUSE instruction on platforms supporting them. > But sleep is also required to check interrupt status, > which means that at least one extra load would be needed > in addition to PAUSE. So it seems that something yield-like > (with no obligation to check interrupt) is still desirable, > leading either to my original suggestion: > > /** > * A hint to the platform that the current thread is momentarily > * unable to progress... > */ > public static void spinYield(); > > OR something more analogous to sleep, but without interrupt check: > > /** > * A hint to the platform that the current thread is unlikely > * to progress for the indicated duration in nanoseconds... > */ > public static void yield(long nanoSeconds); > > When available, JVMs would implement small values via PAUSE, > larger by calling plain yield(), but in no case promising to > return in either at least or at most the given duration. > While it is a little odd, it seems to cover John Rose's desire > to force an argument dependency. > > I think either of these would be OK. > > We'd use this functionality in a few places inside java.util.concurrent. > We can't do so as aggressively as some users might like: we > generally bound spin-then-block constructions to an approximation > of best-case unavailability (lock-hold etc) times, so as to > work OK when systems are heavily loaded. When we have done more > than this, we have gotten justifiable complaints. But we also > have "try" and "poll" forms of almost everything so users can > add additional spins themselves. Or create custom sync using > base capabilities. > > Back to the question of monitor-like constructions: > > Low-level memory-wait instructions are limited in what they > can wait for -- basically only changes at fixed addresses. > This is not an easy fit for GCed languages where the address > of a variable might change. However, there is at least one > case where this can work: park/unpark are (and are nearly forced > to be) implemented using an underlying native-level semaphore. > So it should be possible to at least sometimes use MWAIT > inside park to reduce unproductive context switches. > The "sometimes" part might vary across platforms. > In particular, the implementation of LockSupport.parkNanos > could always just invoke an MWAIT-based intrinsic for small > arguments. It would be great if people working on hotspot > explored such options. > > So for this particular application of MWAIT-like support > (which should be vastly more common than other uses anyway), > we could side-step for now analogs of proposed C++ "synchronics" > and the like that would require unknown mechanics on > still-unreleased VarHandles. > > -Doug > From openjdk at duigou.org Thu Oct 15 04:38:03 2015 From: openjdk at duigou.org (Mike Duigou) Date: Wed, 14 Oct 2015 21:38:03 -0700 Subject: CopyOnWriteArrayNavigableSet discussion on concurrency-interest Message-ID: <36fed16e31cb55c0377a5e5ee748d124@sonic.net> Hello all; For those that don't regularly read the JSR-166 concurrency-interest list (http://cs.oswego.edu/mailman/listinfo/concurrency-interest) I wanted to make note of a discussion there that some reading here may be interested in. I have recently proposed a new NavigableSet implementation which, similar to CopyOnWriteArraySet, uses CopyOnWriteArrayList for storing the Set elements. The main difference between this new implementation and the existing CopyOnWriteArraySet is that the new implementation keeps the backing array in sorted order and can use binary search for some operations. Some applications may find either it's implementation of the NavigableSet interface, the sorted behaviour or the O(log2 n) performance useful. In my particular use case, both of the later attributes are most useful to me. I suspect that once it's available many usages of CopyOnWriteArraySet for Comparable types could be converted for an easy boost from O(n) to O(log2 n) performance. I have done no performance analysis but my gut feel is that it will be a win for sets with dozens to thousands of elements. As with all uses of CopyOnWriteArraySet the mutation rate is usually the practical limiting factor influencing the size of viable supported sets. If you have suggestions, feedback or comments please contribute to the discussion on concurrency-interest. Assuming the idea is accepted for inclusion there would still be an eventual pre-integration RFC review through this list, but in the meantime any discussion can be sent to me directly or concurrency-interest. Cheers, Mike From huizhe.wang at oracle.com Thu Oct 15 07:52:14 2015 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 15 Oct 2015 00:52:14 -0700 Subject: RFR (JAXP) : 8081248: Implement JEP 268: XML Catalog API Message-ID: <561F5B2E.7060107@oracle.com> Hi all, Please help review JEP 268 implementation: https://bugs.openjdk.java.net/browse/JDK-8081248 Catalog specification: https://www.oasis-open.org/committees/download.php/14809/xml-catalogs.html webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8081248/webrev/ A Catalog is basically an ordered list of entries that map external references to local resources using string identifiers called systemId/publicId. The main function of the Catalog API therefore is 1) parse a catalog; 2) use it to find a matching entry and resolve the resource referenced in an XML document. For common use cases, an application would simply acquire a CatalogResolver and set it on a parser to be used for resource resolution, refer to the test for an example. The unit test contains test cases for the simple entries. Since SQE test development has been in parallel with the dev work, this unit test didn't have to cover all of the functions. What it does is to test and demonstrate the use in a real environment, using a CatalogResolver to actually resolves resources in XML documents, while the SQE tests focus on having a full coverage by matching literal strings without involving XML documents. The SQE test suite has gone through internal reviews and will start public review following this review. Thanks, Joe From peter.levart at gmail.com Thu Oct 15 08:12:36 2015 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 15 Oct 2015 10:12:36 +0200 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <561E9454.6030700@Oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> Message-ID: <561F5FF4.1080505@gmail.com> On 10/14/2015 07:43 PM, Roger Riggs wrote: > Hi Alan, Mandy, > > I looked at a few of the many uses of finalize and the likely changes. > The zip Inflater and Deflater are relatively simple cases. > Some finalizers are not used and can be removed. > The sun.net.www.MeteredStream example subclasses PhantomCleanable to > add the state and cleanup > behavior. > > http://cr.openjdk.java.net/~rriggs/webrev-cleaning-finalizers/ > > Some of the harder cases will take more time to disentangle the > cleanup code. > For example, ZipFile, and FileIn/OutputStream (Peter has prototyped > this). > > Roger Hi Roger, It's good to see some actual uses of the API and how it is supposed to be used in migration from finalize() methods. I think empty protected finalize() method is almost always safe to remove. If the class is not subclassed, it serves no purpose (unless some other same-package class or itself is calling it, which can be checked and those calls removed). If subclass overrides finalize() and calls super.finalize(), its ok (it will call Object.finalize then when empty finalize() is removed). The same holds if a subclass calls finalize() as a virtual method regardless of whether it also overrides it or not. One thing to watch for is in case a subclass overrides finalize() like this: class Subclass extends Superclass { ... @Override protected finalize() { .... pre-actions ... super.finalize(); ... post-actions... } ... where the order of cleanup actions has to be orchestrated between super and subclass. Having a PhantomCleanable replace the finalize() in a superclass has a similar effect as the following re-ordering in subclass: @Override protected finalize() { .... pre-actions ... ... post-actions... super.finalize(); } ...since finalization is performed before PhantomReference is enqueued. This re-ordering is luckily often safe as post-actions usually can't use superclass resources any more and usually don't depend on the state of superclass. In addition, when superclass actions do happen, they can't invoke any instance methods if they are refactored to use Cleaner. This brings up an interesting question. finalize() method allows subclasses to override it and augment cleanup logic to include any state changes or resources used by subclass. How about Cleanup API? Subclass can register it's own Cleanable for own resources, but order of execution of superclass and subclass Cleanable(s) is arbitrary then. Cleanables will often be established in constructors and super/subclass constructors have a defined order of execution. So what about the following: public class Cleaner { public Cleanup phantomCleanup(Object referent); public interface Cleanable { void clean(); void clear(); } public interface Cleanup extends Cleanable { Cleanable append(Runnable action); Cleanable prepend(Runnable action); } public static abstract class PhantomCleanable extends PhantomReference implements Cleanable { ... } private static final class PhantomCleanup extends PhantomCleanable implements Cleanup { ... } ...use... class SuperClass { protected final Cleanup cleanup = XXX.getCleaner().phantomCleanup(this); SuperClass() { cleanup.append(() -> {... super class cleanup ...}); } } class SubClass extends SuperClass { SubClass() { super(); cleanup.prepend(() -> {... pre-actions ...}) .append(() -> {... post-actions ...}); } } Regards, Peter > > > > On 10/14/2015 10:23 AM, Alan Bateman wrote: >> >> On 14/10/2015 15:03, Roger Riggs wrote: >>> Hi Alan, >>> >>> So any user of the Cleaner can take advantage of the mechanism, for >>> example in a different package or module. >>> For example, Netbeans. >> Cleaner + Cleanable need to be public of course so maybe we should >> wait for the examples that extend WeakCleanableRef or cast the >> Cleanable to a WeakCleanableRef before seeing if this is the right >> thing or not. >> >> -Alan > From paul.sandoz at oracle.com Thu Oct 15 08:53:01 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 15 Oct 2015 10:53:01 +0200 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <561F16C1.6090702@oracle.com> References: <F7C2BACE-2E86-4058-8136-F565799494F8@oracle.com> <561ED8BF.40901@oracle.com> <CC71DAAE-940B-47EB-A2F2-FFB89F2EBAD3@oracle.com> <561F16C1.6090702@oracle.com> Message-ID: <A8D7EE96-1238-401D-813D-E977CCD9E73F@oracle.com> > On 15 Oct 2015, at 05:00, Xueming Shen <xueming.shen at oracle.com> wrote: > > I'm not sure if it is a good idea, from performance perspective, to add a "versionEntry" field into the JarEntry > to support this feature, given most of the jar files might not be multi-release-jar aware, and the Jar input& > output streams dont work with a multi-release jar directly. Why should they all pay a runtime price for it. If > we really have to add an extra field, the JarFileEntry might be a better place, and it might be desired to > define a new subclass JarFileEntryMR to use when the MR is enabled, instead of adding directly into the existing > JarFileEntry. > According to jol there is currently space available due to alignment. If there was not it would add about 4% in direct instance size. But the actual footprint is likely to be chunkier because of the string character storage for the name so the % increase in size would be smaller e.g. perhaps on average < 2% which might be ok given that i presume such entries are unlikely to be cached. So i am not concerned about the size. If there was a way to design it to avoid modification of existing classes all the better, but i dunno if it is possible. Steve will surely know more. Paul. From sean.coffey at oracle.com Thu Oct 15 09:02:40 2015 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 15 Oct 2015 10:02:40 +0100 Subject: RFR (xs) : 8038502: Deflater.needsInput() should use synchronization Message-ID: <561F6BB0.2030601@oracle.com> bug report : https://bugs.openjdk.java.net/browse/JDK-8038502 The len instance variable should be read/written while holding the zsRef lock. needsInput() seems to be missing that. Simple change : diff --git a/src/java.base/share/classes/java/util/zip/Deflater.java b/src/java.base/share/classes/java/util/zip/Deflater.java --- a/src/java.base/share/classes/java/util/zip/Deflater.java +++ b/src/java.base/share/classes/java/util/zip/Deflater.java @@ -318,8 +318,10 @@ * should be called in order to provide more input */ public boolean needsInput() { + synchronized (zsRef) { return len <= 0; } + } /** * When called, indicates that compression should end with the current -- Regards, Sean. From chris.hegarty at oracle.com Thu Oct 15 10:47:19 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 15 Oct 2015 11:47:19 +0100 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <561E9454.6030700@Oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> Message-ID: <825C75CC-AAC3-4881-B86A-98F37DD17E84@oracle.com> Roger, On 14 Oct 2015, at 18:43, Roger Riggs <Roger.Riggs at oracle.com> wrote: > Hi Alan, Mandy, > > I looked at a few of the many uses of finalize and the likely changes. > The zip Inflater and Deflater are relatively simple cases. > Some finalizers are not used and can be removed. It is not immediately clear to me. Are you saying that some finalize() methods, like the ones on Inflater and Deflater, are part of Java SE spec and should be deprecated in 9, then removed in 10. While others, that are just implementation, can be removed now? -Chris. > The sun.net.www.MeteredStream example subclasses PhantomCleanable to add the state and cleanup > behavior. > > http://cr.openjdk.java.net/~rriggs/webrev-cleaning-finalizers/ > > Some of the harder cases will take more time to disentangle the cleanup code. > For example, ZipFile, and FileIn/OutputStream (Peter has prototyped this). > > Roger > > > > On 10/14/2015 10:23 AM, Alan Bateman wrote: >> >> On 14/10/2015 15:03, Roger Riggs wrote: >>> Hi Alan, >>> >>> So any user of the Cleaner can take advantage of the mechanism, for example in a different package or module. >>> For example, Netbeans. >> Cleaner + Cleanable need to be public of course so maybe we should wait for the examples that extend WeakCleanableRef or cast the Cleanable to a WeakCleanableRef before seeing if this is the right thing or not. >> >> -Alan > From scolebourne at joda.org Thu Oct 15 10:48:03 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 15 Oct 2015 11:48:03 +0100 Subject: RFR: JDK-8046565: Platform Logger API and Service In-Reply-To: <561E3A9A.9050807@oracle.com> References: <561660DA.7070900@oracle.com> <8D8890A3-2337-4178-BA5C-CC32DE12F27D@oracle.com> <561E3A9A.9050807@oracle.com> Message-ID: <CACzrW9Dp3wUHk=TY=nfApczW5GfgGpWj7R9bcGRPXr9VGqH7fA@mail.gmail.com> On 14 October 2015 at 12:20, Daniel Fuchs <daniel.fuchs at oracle.com> wrote: > On 14/10/15 07:21, Mandy Chung wrote: >> Several log methods throws NPE if the level is legible and the parameter >> is null. E.g. >> * @throws NullPointerException if {@code level} is {@code null}, or if the >> level >> * is loggable and {@code msgSupplier} is {@code null}. >> >> Should it throw NPE if the input parameter is null regardless of whether >> the level is loggable? > > > Yes probably. The reason it is like that is that it mimics > what java.util.logging.Logger does (at least for message suppliers), but > it is probably not a good idea to propagate this bad practice. > > I will change System.Logger spec to mandate to always throw NPE > if Supplier<String> is null - and ensure that the implementations > we have follow the spec. I believe the desire in logging is to a sensible degree write defensively to avoid getting an exception due to logging which obscures the actual error. Thus, log(level, msg) should accept a null message (but not a null level) But, log(level, supplier) should not accept a null supplier or level The Javadoc for 'System.Logger' starts with "The minimum set of methods that a logger returned by..." which isn't a good description of the interface. I have a major concern that the class names 'Logger' and 'Level' duplicate those of java.util.logging. While they are inner classes as opposed to top level classes, both IntelliJ and Eclipse will find the inner class and top level class when typing "Logger". This will no doubt cause many users to import the wrong one. I propose that these classes are renamed to avoid this problem. The simplest would be to change them from inner classes to top level classes "System.Logger" -> "SystemLogger". Alternatively, they could stay as inner classes and be prefixed "System.Logger" -> "System.SysLogger" or "System.Logger" -> "System.BasicLogger". Stephen From paul.sandoz at oracle.com Thu Oct 15 10:52:31 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 15 Oct 2015 12:52:31 +0200 Subject: Array equality, comparison and mismatch In-Reply-To: <561CD6F8.5040206@redhat.com> References: <mailman.9142.1444698750.25018.core-libs-dev@openjdk.java.net> <85fedd00040c71eee083030befad0c96@sonic.net> <199FDD06-50C4-47B1-9676-5B6FD0B5E890@oracle.com> <561CD6F8.5040206@redhat.com> Message-ID: <747868FE-6ED8-4193-9BC1-EDBB7B925992@oracle.com> > On 13 Oct 2015, at 12:03, Andrew Haley <aph at redhat.com> wrote: > > On 13/10/15 10:22, Paul Sandoz wrote: >> Analysis so far indicate big gains are to be had on larger arrays with better or no impact on small arrays if i do the following instead: >> >> if (Double.doubleToRawLongBits(a[i]) != >> Double.doubleToRawLongBits(b[i])) { >> int c = Double.compare(a[i], b[i]); >> if (c != 0) return c; >> } > > I was about to make a similar comment. My experiment was with > > if (Double.doubleToRawLongBits(a[i]) != Double.doubleToRawLongBits(b[i]) > && (Double.doubleToLongBits(a[i]) != > Double.doubleToLongBits(b[i]))) > return Double.compare(a[i], b[i]); > } > > which is about twice as fast as the original version, as is yours. > But yours is more elegant. :-) > Thanks :-) updated: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/webrev/ > It's a shame that HotSpot doesn't see through the load of a > double and then the conversion through doubleToRawLongBits: > it could just load directly into the integer registers. > The following webrev explicitly does what you mention above and is faster for mismatching double arrays (with no differing NaN values): http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8136924-arrays-mismatch-vectorized-unsafe/webrev/ I would be very interested in your opinion on being able to make intrinsic on ARM the method ArraysSupport.vectorizedMismatch [1]. Paul. [1] http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8136924-arrays-mismatch-vectorized-unsafe/webrev/src/java.base/share/classes/java/util/ArraysSupport.java.html From chris.hegarty at oracle.com Thu Oct 15 11:43:32 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 15 Oct 2015 12:43:32 +0100 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <561F5FF4.1080505@gmail.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> Message-ID: <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> Peter, On 15 Oct 2015, at 09:12, Peter Levart <peter.levart at gmail.com> wrote: > On 10/14/2015 07:43 PM, Roger Riggs wrote: >> Hi Alan, Mandy, >> >> I looked at a few of the many uses of finalize and the likely changes. >> The zip Inflater and Deflater are relatively simple cases. >> Some finalizers are not used and can be removed. >> The sun.net.www.MeteredStream example subclasses PhantomCleanable to add the state and cleanup >> behavior. >> >> http://cr.openjdk.java.net/~rriggs/webrev-cleaning-finalizers/ >> >> Some of the harder cases will take more time to disentangle the cleanup code. >> For example, ZipFile, and FileIn/OutputStream (Peter has prototyped this). >> >> Roger > > Hi Roger, > > It's good to see some actual uses of the API and how it is supposed to be used in migration from finalize() methods. I think empty protected finalize() method is almost always safe to remove. If the class is not subclassed, it serves no purpose (unless some other same-package class or itself is calling it, which can be checked and those calls removed). If subclass overrides finalize() and calls super.finalize(), its ok (it will call Object.finalize then when empty finalize() is removed). The same holds if a subclass calls finalize() as a virtual method regardless of whether it also overrides it or not. > > One thing to watch for is in case a subclass overrides finalize() like this: > > class Subclass extends Superclass { > ... > @Override protected finalize() { > .... pre-actions ... > super.finalize(); > ... post-actions... > } > > ... where the order of cleanup actions has to be orchestrated between super and subclass. Having a PhantomCleanable replace the finalize() in a superclass has a similar effect as the following re-ordering in subclass: > > @Override protected finalize() { > .... pre-actions ... > ... post-actions... > super.finalize(); > } > > ...since finalization is performed before PhantomReference is enqueued. This re-ordering is luckily often safe as post-actions usually can't use superclass resources any more and usually don't depend on the state of superclass. In addition, when superclass actions do happen, they can't invoke any instance methods if they are refactored to use Cleaner. > > This brings up an interesting question. finalize() method allows subclasses to override it and augment cleanup logic to include any state changes or resources used by subclass. Or for a subclass to effectively cancel any clean up, by providing an empty finalize() method. Which I think is also supported by your proposal, or at least a side-effect of having the Cleanup as a protected field ( you can call clear on it, right? ). Having the Cleanup as a protected field looks a little odd, but no more so than the public/protected finalize method. This is now getting even more complicated. There are potentially multiple object references being tracked as part of the cleanup of a single ?significant? object ? -Chris. > How about Cleanup API? Subclass can register it's own Cleanable for own resources, but order of execution of superclass and subclass Cleanable(s) is arbitrary then. Cleanables will often be established in constructors and super/subclass constructors have a defined order of execution. So what about the following: > > public class Cleaner { > > public Cleanup phantomCleanup(Object referent); > > public interface Cleanable { > void clean(); > void clear(); > } > > public interface Cleanup extends Cleanable { > Cleanable append(Runnable action); > Cleanable prepend(Runnable action); > } > > public static abstract class PhantomCleanable extends PhantomReference implements Cleanable { ... } > > private static final class PhantomCleanup extends PhantomCleanable implements Cleanup { ... } > > ...use... > > class SuperClass { > protected final Cleanup cleanup = XXX.getCleaner().phantomCleanup(this); > > SuperClass() { > cleanup.append(() -> {... super class cleanup ...}); > } > } > > class SubClass extends SuperClass { > SubClass() { > super(); > cleanup.prepend(() -> {... pre-actions ...}) > .append(() -> {... post-actions ...}); > } > } > > > Regards, Peter > >> >> >> >> On 10/14/2015 10:23 AM, Alan Bateman wrote: >>> >>> On 14/10/2015 15:03, Roger Riggs wrote: >>>> Hi Alan, >>>> >>>> So any user of the Cleaner can take advantage of the mechanism, for example in a different package or module. >>>> For example, Netbeans. >>> Cleaner + Cleanable need to be public of course so maybe we should wait for the examples that extend WeakCleanableRef or cast the Cleanable to a WeakCleanableRef before seeing if this is the right thing or not. >>> >>> -Alan >> > From chris.hegarty at oracle.com Thu Oct 15 11:50:56 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 15 Oct 2015 12:50:56 +0100 Subject: RFR (xs) : 8038502: Deflater.needsInput() should use synchronization In-Reply-To: <561F6BB0.2030601@oracle.com> References: <561F6BB0.2030601@oracle.com> Message-ID: <39E2B2A2-81B8-4314-A6BC-066481C5CC7F@oracle.com> Looks good to me Sean. All other state seems to be accessed when holding zsRef. -Chris. On 15 Oct 2015, at 10:02, Se?n Coffey <sean.coffey at oracle.com> wrote: > bug report : https://bugs.openjdk.java.net/browse/JDK-8038502 > > The len instance variable should be read/written while holding the zsRef lock. > > needsInput() seems to be missing that. Simple change : > > diff --git a/src/java.base/share/classes/java/util/zip/Deflater.java b/src/java.base/share/classes/java/util/zip/Deflater.java > --- a/src/java.base/share/classes/java/util/zip/Deflater.java > +++ b/src/java.base/share/classes/java/util/zip/Deflater.java > @@ -318,8 +318,10 @@ > * should be called in order to provide more input > */ > public boolean needsInput() { > + synchronized (zsRef) { > return len <= 0; > } > + } > > /** > * When called, indicates that compression should end with the current > > -- > Regards, > Sean. > From aph at redhat.com Thu Oct 15 12:37:33 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 15 Oct 2015 13:37:33 +0100 Subject: Array equality, comparison and mismatch In-Reply-To: <747868FE-6ED8-4193-9BC1-EDBB7B925992@oracle.com> References: <mailman.9142.1444698750.25018.core-libs-dev@openjdk.java.net> <85fedd00040c71eee083030befad0c96@sonic.net> <199FDD06-50C4-47B1-9676-5B6FD0B5E890@oracle.com> <561CD6F8.5040206@redhat.com> <747868FE-6ED8-4193-9BC1-EDBB7B925992@oracle.com> Message-ID: <561F9E0D.1060401@redhat.com> On 10/15/2015 11:52 AM, Paul Sandoz wrote: > I would be very interested in your opinion on being able to make > intrinsic on ARM the method ArraysSupport.vectorizedMismatch [1]. Pretty easy, I'm sure. We already have MacroAssembler::string_compare which does essentially the same thing but with char arrays. Andrew. From roger.riggs at oracle.com Thu Oct 15 13:03:00 2015 From: roger.riggs at oracle.com (Roger Riggs) Date: Thu, 15 Oct 2015 09:03:00 -0400 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <825C75CC-AAC3-4881-B86A-98F37DD17E84@oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <825C75CC-AAC3-4881-B86A-98F37DD17E84@oracle.com> Message-ID: <561FA404.1030408@oracle.com> Hi Chris, I think this warrants some discussion related to the normal deprecation practice. If there is specified behavior related to finalize, then the behavior has to be replicated using the Cleaner to ensure backward compatibility. It is a spec change (at least a documentation change) and may move from the finalize method to the class javadoc. Since finalize is an overridden method, removing a particular override does not remove the method. There is no issue with source compatibility. I'll need to check binary compatibility that the VM when it sees a call to a specific finalize method that it will search up for the super method. I think this is the case. If it is decided that the finalize method overrides need to follow the standard 2 release deprecation cycle there is not much of a down side. There is an optimization in the VM that looks for empty finalize methods. Only if a type has at least one non-empty finalize method does the overhead for a finalizable reference kick in. yes, finalize methods in non-public classes can be removed. BTW, I expect there are cases where it is not practical or urgent to replace the finalizers and they will stay the same, perhaps indefinitely. Roger On 10/15/15 6:47 AM, Chris Hegarty wrote: > Roger, > > On 14 Oct 2015, at 18:43, Roger Riggs <Roger.Riggs at oracle.com> wrote: > >> Hi Alan, Mandy, >> >> I looked at a few of the many uses of finalize and the likely changes. >> The zip Inflater and Deflater are relatively simple cases. >> Some finalizers are not used and can be removed. > It is not immediately clear to me. Are you saying that some > finalize() methods, like the ones on Inflater and Deflater, > are part of Java SE spec and should be deprecated in 9, > then removed in 10. While others, that are just > implementation, can be removed now? > > -Chris. > >> The sun.net.www.MeteredStream example subclasses PhantomCleanable to add the state and cleanup >> behavior. >> >> http://cr.openjdk.java.net/~rriggs/webrev-cleaning-finalizers/ >> >> Some of the harder cases will take more time to disentangle the cleanup code. >> For example, ZipFile, and FileIn/OutputStream (Peter has prototyped this). >> >> Roger >> >> >> >> On 10/14/2015 10:23 AM, Alan Bateman wrote: >>> On 14/10/2015 15:03, Roger Riggs wrote: >>>> Hi Alan, >>>> >>>> So any user of the Cleaner can take advantage of the mechanism, for example in a different package or module. >>>> For example, Netbeans. >>> Cleaner + Cleanable need to be public of course so maybe we should wait for the examples that extend WeakCleanableRef or cast the Cleanable to a WeakCleanableRef before seeing if this is the right thing or not. >>> >>> -Alan From roger.riggs at oracle.com Thu Oct 15 13:21:17 2015 From: roger.riggs at oracle.com (Roger Riggs) Date: Thu, 15 Oct 2015 09:21:17 -0400 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> Message-ID: <561FA84D.5030502@oracle.com> Peter, Chris, Plausible but getting complicated as Chris observed. We can be on the lookout for specific cases in the JDK like that. I expect most can be resolved by specific cooperation between the super/subclasses. The cleanup of each class should *only* be doing cleanup for their own class. Because it is invoked after finalization, there can be *no* access to the instance being cleaned. Any shared state will be duplicated between the two cleanable behaviors. If the subclass shares state with the superclass (protected fields or references) then the cleanup needs to be co-designed. Canceling cleanup is easier, because the object has not been finalized. If such a function is needed, it should be part of the API of the superclass and part of the contract. Also, I've seen a few calls to super.finalize() where there were no finalizers in any of the superclasses. It would be considered good design to always include it. I don't know if the optimization for empty finalize methods includes the case where it only calls super.finalize(). Roger On 10/15/15 7:43 AM, Chris Hegarty wrote: > Peter, > > On 15 Oct 2015, at 09:12, Peter Levart <peter.levart at gmail.com> wrote: > >> On 10/14/2015 07:43 PM, Roger Riggs wrote: >>> Hi Alan, Mandy, >>> >>> I looked at a few of the many uses of finalize and the likely changes. >>> The zip Inflater and Deflater are relatively simple cases. >>> Some finalizers are not used and can be removed. >>> The sun.net.www.MeteredStream example subclasses PhantomCleanable to add the state and cleanup >>> behavior. >>> >>> http://cr.openjdk.java.net/~rriggs/webrev-cleaning-finalizers/ >>> >>> Some of the harder cases will take more time to disentangle the cleanup code. >>> For example, ZipFile, and FileIn/OutputStream (Peter has prototyped this). >>> >>> Roger >> Hi Roger, >> >> It's good to see some actual uses of the API and how it is supposed to be used in migration from finalize() methods. I think empty protected finalize() method is almost always safe to remove. If the class is not subclassed, it serves no purpose (unless some other same-package class or itself is calling it, which can be checked and those calls removed). If subclass overrides finalize() and calls super.finalize(), its ok (it will call Object.finalize then when empty finalize() is removed). The same holds if a subclass calls finalize() as a virtual method regardless of whether it also overrides it or not. >> >> One thing to watch for is in case a subclass overrides finalize() like this: >> >> class Subclass extends Superclass { >> ... >> @Override protected finalize() { >> .... pre-actions ... >> super.finalize(); >> ... post-actions... >> } >> >> ... where the order of cleanup actions has to be orchestrated between super and subclass. Having a PhantomCleanable replace the finalize() in a superclass has a similar effect as the following re-ordering in subclass: >> >> @Override protected finalize() { >> .... pre-actions ... >> ... post-actions... >> super.finalize(); >> } >> >> ...since finalization is performed before PhantomReference is enqueued. This re-ordering is luckily often safe as post-actions usually can't use superclass resources any more and usually don't depend on the state of superclass. In addition, when superclass actions do happen, they can't invoke any instance methods if they are refactored to use Cleaner. >> >> This brings up an interesting question. finalize() method allows subclasses to override it and augment cleanup logic to include any state changes or resources used by subclass. > Or for a subclass to effectively cancel any clean up, by > providing an empty finalize() method. Which I think is > also supported by your proposal, or at least a side-effect > of having the Cleanup as a protected field ( you can call > clear on it, right? ). > > Having the Cleanup as a protected field looks a little odd, > but no more so than the public/protected finalize method. > > This is now getting even more complicated. There are > potentially multiple object references being tracked as > part of the cleanup of a single ?significant? object ? > > -Chris. > >> How about Cleanup API? Subclass can register it's own Cleanable for own resources, but order of execution of superclass and subclass Cleanable(s) is arbitrary then. Cleanables will often be established in constructors and super/subclass constructors have a defined order of execution. So what about the following: >> >> public class Cleaner { >> >> public Cleanup phantomCleanup(Object referent); >> >> public interface Cleanable { >> void clean(); >> void clear(); >> } >> >> public interface Cleanup extends Cleanable { >> Cleanable append(Runnable action); >> Cleanable prepend(Runnable action); >> } >> >> public static abstract class PhantomCleanable extends PhantomReference implements Cleanable { ... } >> >> private static final class PhantomCleanup extends PhantomCleanable implements Cleanup { ... } >> >> ...use... >> >> class SuperClass { >> protected final Cleanup cleanup = XXX.getCleaner().phantomCleanup(this); >> >> SuperClass() { >> cleanup.append(() -> {... super class cleanup ...}); >> } >> } >> >> class SubClass extends SuperClass { >> SubClass() { >> super(); >> cleanup.prepend(() -> {... pre-actions ...}) >> .append(() -> {... post-actions ...}); >> } >> } >> >> >> Regards, Peter >> >>> >>> >>> On 10/14/2015 10:23 AM, Alan Bateman wrote: >>>> On 14/10/2015 15:03, Roger Riggs wrote: >>>>> Hi Alan, >>>>> >>>>> So any user of the Cleaner can take advantage of the mechanism, for example in a different package or module. >>>>> For example, Netbeans. >>>> Cleaner + Cleanable need to be public of course so maybe we should wait for the examples that extend WeakCleanableRef or cast the Cleanable to a WeakCleanableRef before seeing if this is the right thing or not. >>>> >>>> -Alan From chris.hegarty at oracle.com Thu Oct 15 13:34:40 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 15 Oct 2015 14:34:40 +0100 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <561FA84D.5030502@oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> Message-ID: <8D799F49-D9F5-4CC6-8816-A4E6799A6C0A@oracle.com> On 15 Oct 2015, at 14:21, Roger Riggs <Roger.Riggs at oracle.com> wrote: > ... > > Also, I've seen a few calls to super.finalize() where there were no finalizers > in any of the superclasses. It would be considered good design to always include it. > I don't know if the optimization for empty finalize methods includes the > case where it only calls super.finalize(). I believe it is only for empty finalize methods. http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/tip/src/share/vm/classfile/classFileParser.cpp#l2506 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/tip/src/share/vm/classfile/classFileParser.cpp#l4509 -Chris. From peter.levart at gmail.com Thu Oct 15 13:49:18 2015 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 15 Oct 2015 15:49:18 +0200 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <561FA84D.5030502@oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> Message-ID: <561FAEDE.5040100@gmail.com> On 10/15/2015 03:21 PM, Roger Riggs wrote: > Peter, Chris, > > Plausible but getting complicated as Chris observed. > > We can be on the lookout for specific cases in the JDK like that. I > expect most > can be resolved by specific cooperation between the super/subclasses. How? Such "cooperation" can not use the tracked object's instance methods as the instance is gone when cleanup happens, so no overriding is possible. Can you rewrite this example: class SuperClass { protected final Cleanup cleanup = XXX.getCleaner().phantomCleanup(this); SuperClass() { cleanup.append(() -> {... super class cleanup ...}); } } class SubClass extends SuperClass { SubClass() { super(); cleanup.prepend(() -> {... pre-actions ...}) .append(() -> {... post-actions ...}); } } ...using just current simple Cleaner API? I think that if we design an API to replace finalize(), then it should support use cases that are possible with finalize(). Not just use cases in the JDK itself, but also elsewhere on the planet. > The cleanup of each class should *only* be doing cleanup for their own > class. > Because it is invoked after finalization, there can be *no* access to > the instance > being cleaned. Any shared state will be duplicated between the two > cleanable behaviors. > If the subclass shares state with the superclass (protected fields or > references) > then the cleanup needs to be co-designed. Even if state needed for clean-up is duplicated (it can just be doubly referenced, for example: superclass establishes state and exposes it to subclass that just references it), registering separate Cleanup instances per super/subclass means that you can not control the order of them fire-ing. If for example, the subclass cleanup logic needs the superclass still be fully functional, it can do that now by: @Override protected void finalize() { ... subclass cleanup ... // flushing something - needs superclass functionality super.finalize(); } With separate Cleanable(s) for super/subclass, the order is not guaranteed. > > Canceling cleanup is easier, because the object has not been finalized. > If such a function is needed, it should be part of the API of the > superclass > and part of the contract. Ideally such methods would be in superclass only and be final and just delegate to Cleanable.clear() or Cleanable.clean(). The Cleanable should be the only place where the cleanup logic is encapsulated. > > Also, I've seen a few calls to super.finalize() where there were no > finalizers > in any of the superclasses. It would be considered good design to > always include it. > I don't know if the optimization for empty finalize methods includes the > case where it only calls super.finalize(). Ah, I forgot that empty finalize() is optimized away (the Object is not even registered for finalization). Regards, Peter > > Roger > > On 10/15/15 7:43 AM, Chris Hegarty wrote: >> Peter, >> >> On 15 Oct 2015, at 09:12, Peter Levart <peter.levart at gmail.com> wrote: >> >>> On 10/14/2015 07:43 PM, Roger Riggs wrote: >>>> Hi Alan, Mandy, >>>> >>>> I looked at a few of the many uses of finalize and the likely changes. >>>> The zip Inflater and Deflater are relatively simple cases. >>>> Some finalizers are not used and can be removed. >>>> The sun.net.www.MeteredStream example subclasses PhantomCleanable >>>> to add the state and cleanup >>>> behavior. >>>> >>>> http://cr.openjdk.java.net/~rriggs/webrev-cleaning-finalizers/ >>>> >>>> Some of the harder cases will take more time to disentangle the >>>> cleanup code. >>>> For example, ZipFile, and FileIn/OutputStream (Peter has prototyped >>>> this). >>>> >>>> Roger >>> Hi Roger, >>> >>> It's good to see some actual uses of the API and how it is supposed >>> to be used in migration from finalize() methods. I think empty >>> protected finalize() method is almost always safe to remove. If the >>> class is not subclassed, it serves no purpose (unless some other >>> same-package class or itself is calling it, which can be checked and >>> those calls removed). If subclass overrides finalize() and calls >>> super.finalize(), its ok (it will call Object.finalize then when >>> empty finalize() is removed). The same holds if a subclass calls >>> finalize() as a virtual method regardless of whether it also >>> overrides it or not. >>> >>> One thing to watch for is in case a subclass overrides finalize() >>> like this: >>> >>> class Subclass extends Superclass { >>> ... >>> @Override protected finalize() { >>> .... pre-actions ... >>> super.finalize(); >>> ... post-actions... >>> } >>> >>> ... where the order of cleanup actions has to be orchestrated >>> between super and subclass. Having a PhantomCleanable replace the >>> finalize() in a superclass has a similar effect as the following >>> re-ordering in subclass: >>> >>> @Override protected finalize() { >>> .... pre-actions ... >>> ... post-actions... >>> super.finalize(); >>> } >>> >>> ...since finalization is performed before PhantomReference is >>> enqueued. This re-ordering is luckily often safe as post-actions >>> usually can't use superclass resources any more and usually don't >>> depend on the state of superclass. In addition, when superclass >>> actions do happen, they can't invoke any instance methods if they >>> are refactored to use Cleaner. >>> >>> This brings up an interesting question. finalize() method allows >>> subclasses to override it and augment cleanup logic to include any >>> state changes or resources used by subclass. >> Or for a subclass to effectively cancel any clean up, by >> providing an empty finalize() method. Which I think is >> also supported by your proposal, or at least a side-effect >> of having the Cleanup as a protected field ( you can call >> clear on it, right? ). >> >> Having the Cleanup as a protected field looks a little odd, >> but no more so than the public/protected finalize method. >> >> This is now getting even more complicated. There are >> potentially multiple object references being tracked as >> part of the cleanup of a single ?significant? object ? >> >> -Chris. >> >>> How about Cleanup API? Subclass can register it's own Cleanable for >>> own resources, but order of execution of superclass and subclass >>> Cleanable(s) is arbitrary then. Cleanables will often be established >>> in constructors and super/subclass constructors have a defined order >>> of execution. So what about the following: >>> >>> public class Cleaner { >>> >>> public Cleanup phantomCleanup(Object referent); >>> >>> public interface Cleanable { >>> void clean(); >>> void clear(); >>> } >>> >>> public interface Cleanup extends Cleanable { >>> Cleanable append(Runnable action); >>> Cleanable prepend(Runnable action); >>> } >>> >>> public static abstract class PhantomCleanable extends >>> PhantomReference implements Cleanable { ... } >>> >>> private static final class PhantomCleanup extends PhantomCleanable >>> implements Cleanup { ... } >>> >>> ...use... >>> >>> class SuperClass { >>> protected final Cleanup cleanup = >>> XXX.getCleaner().phantomCleanup(this); >>> >>> SuperClass() { >>> cleanup.append(() -> {... super class cleanup ...}); >>> } >>> } >>> >>> class SubClass extends SuperClass { >>> SubClass() { >>> super(); >>> cleanup.prepend(() -> {... pre-actions ...}) >>> .append(() -> {... post-actions ...}); >>> } >>> } >>> >>> >>> Regards, Peter >>> >>>> >>>> >>>> On 10/14/2015 10:23 AM, Alan Bateman wrote: >>>>> On 14/10/2015 15:03, Roger Riggs wrote: >>>>>> Hi Alan, >>>>>> >>>>>> So any user of the Cleaner can take advantage of the mechanism, >>>>>> for example in a different package or module. >>>>>> For example, Netbeans. >>>>> Cleaner + Cleanable need to be public of course so maybe we should >>>>> wait for the examples that extend WeakCleanableRef or cast the >>>>> Cleanable to a WeakCleanableRef before seeing if this is the right >>>>> thing or not. >>>>> >>>>> -Alan > From scolebourne at joda.org Thu Oct 15 14:28:00 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 15 Oct 2015 15:28:00 +0100 Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <CACzrW9BjtxDEpQWDeQUJvd0H_Ff4OsPPgF=M2o4SjGFnRL+dhQ@mail.gmail.com> References: <5616FEB5.5090104@oracle.com> <CACzrW9A3MZja2wxsHZ7E0vSupkMJXMTQDqMQRjV548ArAF57Hw@mail.gmail.com> <87025428.3530190.1444485358747.JavaMail.zimbra@u-pem.fr> <CAGB9EW82wrS6Zsg+iaWHgzLxEKL6r5P9aoryS4450h0TfYjBQw@mail.gmail.com> <561DD78D.8070800@oracle.com> <5CCBE2A7-3BF6-41E0-8651-A0DB7D714023@oracle.com> <CACzrW9BjtxDEpQWDeQUJvd0H_Ff4OsPPgF=M2o4SjGFnRL+dhQ@mail.gmail.com> Message-ID: <CACzrW9A7ZL=cv+PZBFe=Nxq-6ry6xBQ7dikHkJwaSEcgajBLzA@mail.gmail.com> I've been working on a Java 8 wrapper class around double[] in my day job, and added the following factory method: /** * Obtains an instance with entries filled using a function. * <p> * The function is passed the array index and returns the value for that index. * * @param size the number of elements * @param valueFunction the function used to populate the value * @return an array initialized using the function */ public static DoubleMatrix1D of(int size, IntToDoubleFunction valueFunction) { if (size == 0) { return EMPTY; } double[] array = new double[size]; for (int i = 0; i < array.length; i++) { array[i] = valueFunction.applyAsDouble(i); } return new DoubleMatrix1D(array); } View on GitHub here: https://github.com/OpenGamma/Strata/commit/63e73652194a3dd94e37fbc407f4933c10abadda#diff-2a9787868cf0654b4a6a07e75c1a6286R199 It occurs to me that it would be a *very* good idea to add a similar method to List. public static <T> List of(int size, IntFunction<T> valueFunction) { ... } Stephen On 14 October 2015 at 11:39, Stephen Colebourne <scolebourne at joda.org> wrote: > On 14 October 2015 at 10:38, Paul Sandoz <paul.sandoz at oracle.com> wrote: >>> On 14 Oct 2015, at 06:18, Stuart Marks <stuart.marks at oracle.com> wrote: >>> I'm not entirely sure what to take from this. If it were clearly exponential, we could say with confidence that above a certain threshold there would be vanishingly little benefit adding more arguments. But since the curve seems to flatten out, maybe this is pushing us to add more pairs than we had originally thought. The current draft API has 8 pairs; that seems to leave a few percent of cases on the table. Obviously we can't get to 100%, but is 97% good enough? > > I'd say 5 is definitely too little, without an easy builder fallback > (as Guava provides). I'd say the right number is between 8 and 10. > > Stephen From paul.sandoz at oracle.com Thu Oct 15 14:40:18 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 15 Oct 2015 16:40:18 +0200 Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <CACzrW9A7ZL=cv+PZBFe=Nxq-6ry6xBQ7dikHkJwaSEcgajBLzA@mail.gmail.com> References: <5616FEB5.5090104@oracle.com> <CACzrW9A3MZja2wxsHZ7E0vSupkMJXMTQDqMQRjV548ArAF57Hw@mail.gmail.com> <87025428.3530190.1444485358747.JavaMail.zimbra@u-pem.fr> <CAGB9EW82wrS6Zsg+iaWHgzLxEKL6r5P9aoryS4450h0TfYjBQw@mail.gmail.com> <561DD78D.8070800@oracle.com> <5CCBE2A7-3BF6-41E0-8651-A0DB7D714023@oracle.com> <CACzrW9BjtxDEpQWDeQUJvd0H_Ff4OsPPgF=M2o4SjGFnRL+dhQ@mail.gmail.com> <CACzrW9A7ZL=cv+PZBFe=Nxq-6ry6xBQ7dikHkJwaSEcgajBLzA@mail.gmail.com> Message-ID: <A4909975-6CC0-491C-8A57-391835D51BBD@oracle.com> > On 15 Oct 2015, at 16:28, Stephen Colebourne <scolebourne at joda.org> wrote: > > I've been working on a Java 8 wrapper class around double[] in my day > job, and added the following factory method: > > /** > * Obtains an instance with entries filled using a function. > * <p> > * The function is passed the array index and returns the value for > that index. > * > * @param size the number of elements > * @param valueFunction the function used to populate the value > * @return an array initialized using the function > */ > public static DoubleMatrix1D of(int size, IntToDoubleFunction valueFunction) { > if (size == 0) { > return EMPTY; > } > double[] array = new double[size]; > for (int i = 0; i < array.length; i++) { > array[i] = valueFunction.applyAsDouble(i); > } > return new DoubleMatrix1D(array); > } > Within that method you can use Arrays.setAll(array, valueFunction). In hindsight it would have been useful for that method to return the filled array. Paul. From forax at univ-mlv.fr Thu Oct 15 14:46:09 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 15 Oct 2015 16:46:09 +0200 (CEST) Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <CACzrW9A7ZL=cv+PZBFe=Nxq-6ry6xBQ7dikHkJwaSEcgajBLzA@mail.gmail.com> References: <5616FEB5.5090104@oracle.com> <CACzrW9A3MZja2wxsHZ7E0vSupkMJXMTQDqMQRjV548ArAF57Hw@mail.gmail.com> <87025428.3530190.1444485358747.JavaMail.zimbra@u-pem.fr> <CAGB9EW82wrS6Zsg+iaWHgzLxEKL6r5P9aoryS4450h0TfYjBQw@mail.gmail.com> <561DD78D.8070800@oracle.com> <5CCBE2A7-3BF6-41E0-8651-A0DB7D714023@oracle.com> <CACzrW9BjtxDEpQWDeQUJvd0H_Ff4OsPPgF=M2o4SjGFnRL+dhQ@mail.gmail.com> <CACzrW9A7ZL=cv+PZBFe=Nxq-6ry6xBQ7dikHkJwaSEcgajBLzA@mail.gmail.com> Message-ID: <1637457181.2233753.1444920369219.JavaMail.zimbra@u-pem.fr> Hi Stephen, you can use Arrays.setAll() which do something similar. The code seems really simple, public static <T> List of(int size, IntFunction<T> valueFunction) { T[] array = (T[])new Object[size]; Arrays.setAll(array, valueFunction); return List.of(array); } or I miss something ? R?mi ----- Mail original ----- > De: "Stephen Colebourne" <scolebourne at joda.org> > ?: "core-libs-dev" <core-libs-dev at openjdk.java.net> > Envoy?: Jeudi 15 Octobre 2015 16:28:00 > Objet: Re: RFC: draft API for JEP 269 Convenience Collection Factories > > I've been working on a Java 8 wrapper class around double[] in my day > job, and added the following factory method: > > /** > * Obtains an instance with entries filled using a function. > * <p> > * The function is passed the array index and returns the value for > that index. > * > * @param size the number of elements > * @param valueFunction the function used to populate the value > * @return an array initialized using the function > */ > public static DoubleMatrix1D of(int size, IntToDoubleFunction > valueFunction) { > if (size == 0) { > return EMPTY; > } > double[] array = new double[size]; > for (int i = 0; i < array.length; i++) { > array[i] = valueFunction.applyAsDouble(i); > } > return new DoubleMatrix1D(array); > } > > View on GitHub here: > https://github.com/OpenGamma/Strata/commit/63e73652194a3dd94e37fbc407f4933c10abadda#diff-2a9787868cf0654b4a6a07e75c1a6286R199 > > It occurs to me that it would be a *very* good idea to add a similar > method to List. > > public static <T> List of(int size, IntFunction<T> valueFunction) { ... } > > Stephen > > > > On 14 October 2015 at 11:39, Stephen Colebourne <scolebourne at joda.org> wrote: > > On 14 October 2015 at 10:38, Paul Sandoz <paul.sandoz at oracle.com> wrote: > >>> On 14 Oct 2015, at 06:18, Stuart Marks <stuart.marks at oracle.com> wrote: > >>> I'm not entirely sure what to take from this. If it were clearly > >>> exponential, we could say with confidence that above a certain threshold > >>> there would be vanishingly little benefit adding more arguments. But > >>> since the curve seems to flatten out, maybe this is pushing us to add > >>> more pairs than we had originally thought. The current draft API has 8 > >>> pairs; that seems to leave a few percent of cases on the table. > >>> Obviously we can't get to 100%, but is 97% good enough? > > > > I'd say 5 is definitely too little, without an easy builder fallback > > (as Guava provides). I'd say the right number is between 8 and 10. > > > > Stephen > From dl at cs.oswego.edu Thu Oct 15 15:32:09 2015 From: dl at cs.oswego.edu (Doug Lea) Date: Thu, 15 Oct 2015 11:32:09 -0400 Subject: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal In-Reply-To: <54AE479E-9891-48FB-AD47-ECED8147DABE@azul.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56164C3C.4050800@cs.oswego.edu> <561E6F04.9030708@cs.oswego.edu> <54AE479E-9891-48FB-AD47-ECED8147DABE@azul.com> Message-ID: <561FC6F9.1080701@cs.oswego.edu> On 10/14/2015 11:53 PM, Gil Tene wrote: > I agree on the separation between spin-hinting and monitor-like constructs. > But not so much on the analogy to or use of the term "yield" to describe what > is intended y spin hints. > I've been focussing on the spec, which still seems to best support this naming. Let's try fleshing out some more (for no-arg version). /** * A hint to the platform that the current thread is momentarily * unable to progress until the occurrence of one or more actions * of one or more other threads. The method is mainly applicable * in spin-then-block constructions entailing a bounded number * of re-checks of a condition, separated by spinYield(), followed * if necessary with use of a blocking synchronization mechanism. */ public static void spinYield(); What should be the response to this hint? When applicable and available, the JVM should just issue PAUSE. But on a uniprocessor, or when load average is easily detected to be high, or on a tightly packed cloud node, a plain yield or something along those lines might be a better use of this hint, that the spec should not rule out. Also, I believe that some x86 hypervisors intercept PAUSE and do something roughly similar after repeated invocations. > While the spinYield() example in your e-mail below can work from a semantic > point of view in the same code, IMO the word "yield" suggests the exact > opposite of what spnLoopHint() is intending to do or hint at Maybe. If you are on a system with load > #cpus, or with certain forms of hypervisor, or without a PAUSE instruction, spinYield might not improve responsiveness but might still improve system throughput. -Doug From Roger.Riggs at Oracle.com Thu Oct 15 16:00:57 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 15 Oct 2015 12:00:57 -0400 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <561FAEDE.5040100@gmail.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> Message-ID: <561FCDB9.5080306@Oracle.com> Hi Peter, It was not the (my/our) intention for the Cleaner to be able to completely replace finalization. The emphasis is on keeping it simple and efficient and covering the 99% of the cases. On 10/15/2015 9:49 AM, Peter Levart wrote: > > > On 10/15/2015 03:21 PM, Roger Riggs wrote: >> Peter, Chris, >> >> Plausible but getting complicated as Chris observed. >> >> We can be on the lookout for specific cases in the JDK like that. I >> expect most >> can be resolved by specific cooperation between the super/subclasses. > > How? Such "cooperation" can not use the tracked object's instance > methods as the instance is gone when cleanup happens, so no overriding > is possible. Can you rewrite this example: > > class SuperClass { > protected final Cleanup cleanup = > XXX.getCleaner().phantomCleanup(this); > > SuperClass() { > cleanup.append(() -> {... super class cleanup ...}); > } > } > > class SubClass extends SuperClass { > SubClass() { > super(); > cleanup.prepend(() -> {... pre-actions ...}) > .append(() -> {... post-actions ...}); > } > } > > > ...using just current simple Cleaner API? > > I think that if we design an API to replace finalize(), then it should > support use cases that are possible with finalize(). Not just use > cases in the JDK itself, but also elsewhere on the planet. I'd be interested in the other cases, but it is not a goal to solve every finalization problem. > >> The cleanup of each class should *only* be doing cleanup for their >> own class. >> Because it is invoked after finalization, there can be *no* access to >> the instance >> being cleaned. Any shared state will be duplicated between the two >> cleanable behaviors. >> If the subclass shares state with the superclass (protected fields or >> references) >> then the cleanup needs to be co-designed. > > Even if state needed for clean-up is duplicated (it can just be doubly > referenced, for example: superclass establishes state and exposes it > to subclass that just references it), registering separate Cleanup > instances per super/subclass means that you can not control the order > of them fire-ing. If for example, the subclass cleanup logic needs the > superclass still be fully functional, it can do that now by: > > @Override protected void finalize() { > ... subclass cleanup ... // flushing something - needs > superclass functionality > super.finalize(); > } > > With separate Cleanable(s) for super/subclass, the order is not > guaranteed. The superclass can expose its Cleanable and additional functionality to prepend or append. That function do not exclusively need to be supported by the Cleaner/Cleanable types. The order can be ensured by registering the cleanups with each other and delegating to the other to achieve a desired execution order. This would put the necessary mechanisms in the types that need specialized behavior without adding complexity to the Cleaner. If it turns out that it is a frequent pattern then it would make sense to look at it again. Regards, Roger > >> >> Canceling cleanup is easier, because the object has not been finalized. >> If such a function is needed, it should be part of the API of the >> superclass >> and part of the contract. > > Ideally such methods would be in superclass only and be final and just > delegate to Cleanable.clear() or Cleanable.clean(). The Cleanable > should be the only place where the cleanup logic is encapsulated. > >> >> Also, I've seen a few calls to super.finalize() where there were no >> finalizers >> in any of the superclasses. It would be considered good design to >> always include it. >> I don't know if the optimization for empty finalize methods includes the >> case where it only calls super.finalize(). > > Ah, I forgot that empty finalize() is optimized away (the Object is > not even registered for finalization). > > Regards, Peter > >> >> Roger >> >> On 10/15/15 7:43 AM, Chris Hegarty wrote: >>> Peter, >>> >>> On 15 Oct 2015, at 09:12, Peter Levart <peter.levart at gmail.com> wrote: >>> >>>> On 10/14/2015 07:43 PM, Roger Riggs wrote: >>>>> Hi Alan, Mandy, >>>>> >>>>> I looked at a few of the many uses of finalize and the likely >>>>> changes. >>>>> The zip Inflater and Deflater are relatively simple cases. >>>>> Some finalizers are not used and can be removed. >>>>> The sun.net.www.MeteredStream example subclasses PhantomCleanable >>>>> to add the state and cleanup >>>>> behavior. >>>>> >>>>> http://cr.openjdk.java.net/~rriggs/webrev-cleaning-finalizers/ >>>>> >>>>> Some of the harder cases will take more time to disentangle the >>>>> cleanup code. >>>>> For example, ZipFile, and FileIn/OutputStream (Peter has >>>>> prototyped this). >>>>> >>>>> Roger >>>> Hi Roger, >>>> >>>> It's good to see some actual uses of the API and how it is supposed >>>> to be used in migration from finalize() methods. I think empty >>>> protected finalize() method is almost always safe to remove. If the >>>> class is not subclassed, it serves no purpose (unless some other >>>> same-package class or itself is calling it, which can be checked >>>> and those calls removed). If subclass overrides finalize() and >>>> calls super.finalize(), its ok (it will call Object.finalize then >>>> when empty finalize() is removed). The same holds if a subclass >>>> calls finalize() as a virtual method regardless of whether it also >>>> overrides it or not. >>>> >>>> One thing to watch for is in case a subclass overrides finalize() >>>> like this: >>>> >>>> class Subclass extends Superclass { >>>> ... >>>> @Override protected finalize() { >>>> .... pre-actions ... >>>> super.finalize(); >>>> ... post-actions... >>>> } >>>> >>>> ... where the order of cleanup actions has to be orchestrated >>>> between super and subclass. Having a PhantomCleanable replace the >>>> finalize() in a superclass has a similar effect as the following >>>> re-ordering in subclass: >>>> >>>> @Override protected finalize() { >>>> .... pre-actions ... >>>> ... post-actions... >>>> super.finalize(); >>>> } >>>> >>>> ...since finalization is performed before PhantomReference is >>>> enqueued. This re-ordering is luckily often safe as post-actions >>>> usually can't use superclass resources any more and usually don't >>>> depend on the state of superclass. In addition, when superclass >>>> actions do happen, they can't invoke any instance methods if they >>>> are refactored to use Cleaner. >>>> >>>> This brings up an interesting question. finalize() method allows >>>> subclasses to override it and augment cleanup logic to include any >>>> state changes or resources used by subclass. >>> Or for a subclass to effectively cancel any clean up, by >>> providing an empty finalize() method. Which I think is >>> also supported by your proposal, or at least a side-effect >>> of having the Cleanup as a protected field ( you can call >>> clear on it, right? ). >>> >>> Having the Cleanup as a protected field looks a little odd, >>> but no more so than the public/protected finalize method. >>> >>> This is now getting even more complicated. There are >>> potentially multiple object references being tracked as >>> part of the cleanup of a single ?significant? object ? >>> >>> -Chris. >>> >>>> How about Cleanup API? Subclass can register it's own Cleanable for >>>> own resources, but order of execution of superclass and subclass >>>> Cleanable(s) is arbitrary then. Cleanables will often be >>>> established in constructors and super/subclass constructors have a >>>> defined order of execution. So what about the following: >>>> >>>> public class Cleaner { >>>> >>>> public Cleanup phantomCleanup(Object referent); >>>> >>>> public interface Cleanable { >>>> void clean(); >>>> void clear(); >>>> } >>>> >>>> public interface Cleanup extends Cleanable { >>>> Cleanable append(Runnable action); >>>> Cleanable prepend(Runnable action); >>>> } >>>> >>>> public static abstract class PhantomCleanable extends >>>> PhantomReference implements Cleanable { ... } >>>> >>>> private static final class PhantomCleanup extends PhantomCleanable >>>> implements Cleanup { ... } >>>> >>>> ...use... >>>> >>>> class SuperClass { >>>> protected final Cleanup cleanup = >>>> XXX.getCleaner().phantomCleanup(this); >>>> >>>> SuperClass() { >>>> cleanup.append(() -> {... super class cleanup ...}); >>>> } >>>> } >>>> >>>> class SubClass extends SuperClass { >>>> SubClass() { >>>> super(); >>>> cleanup.prepend(() -> {... pre-actions ...}) >>>> .append(() -> {... post-actions ...}); >>>> } >>>> } >>>> >>>> >>>> Regards, Peter >>>> >>>>> >>>>> >>>>> On 10/14/2015 10:23 AM, Alan Bateman wrote: >>>>>> On 14/10/2015 15:03, Roger Riggs wrote: >>>>>>> Hi Alan, >>>>>>> >>>>>>> So any user of the Cleaner can take advantage of the mechanism, >>>>>>> for example in a different package or module. >>>>>>> For example, Netbeans. >>>>>> Cleaner + Cleanable need to be public of course so maybe we >>>>>> should wait for the examples that extend WeakCleanableRef or cast >>>>>> the Cleanable to a WeakCleanableRef before seeing if this is the >>>>>> right thing or not. >>>>>> >>>>>> -Alan >> > From daniel.fuchs at oracle.com Thu Oct 15 16:31:02 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 15 Oct 2015 18:31:02 +0200 Subject: RFR: JDK-8046565: Platform Logger API and Service In-Reply-To: <CACzrW9Dp3wUHk=TY=nfApczW5GfgGpWj7R9bcGRPXr9VGqH7fA@mail.gmail.com> References: <561660DA.7070900@oracle.com> <8D8890A3-2337-4178-BA5C-CC32DE12F27D@oracle.com> <561E3A9A.9050807@oracle.com> <CACzrW9Dp3wUHk=TY=nfApczW5GfgGpWj7R9bcGRPXr9VGqH7fA@mail.gmail.com> Message-ID: <561FD4C6.1020803@oracle.com> Hi Stephen, On 15/10/15 12:48, Stephen Colebourne wrote: > On 14 October 2015 at 12:20, Daniel Fuchs <daniel.fuchs at oracle.com> wrote: >> On 14/10/15 07:21, Mandy Chung wrote: >>> Several log methods throws NPE if the level is legible and the parameter >>> is null. E.g. >>> * @throws NullPointerException if {@code level} is {@code null}, or if the >>> level >>> * is loggable and {@code msgSupplier} is {@code null}. >>> >>> Should it throw NPE if the input parameter is null regardless of whether >>> the level is loggable? >> >> >> Yes probably. The reason it is like that is that it mimics >> what java.util.logging.Logger does (at least for message suppliers), but >> it is probably not a good idea to propagate this bad practice. >> >> I will change System.Logger spec to mandate to always throw NPE >> if Supplier<String> is null - and ensure that the implementations >> we have follow the spec. > > I believe the desire in logging is to a sensible degree write > defensively to avoid getting an exception due to logging which > obscures the actual error. > > Thus, log(level, msg) should accept a null message (but not a null level) > But, log(level, supplier) should not accept a null supplier or level Yes exactly. I agree. > The Javadoc for 'System.Logger' starts with "The minimum set of > methods that a logger returned by..." which isn't a good description > of the interface. Right. Mandy already told me that :-) Working on finding a better wording. > I have a major concern that the class names 'Logger' and 'Level' > duplicate those of java.util.logging. While they are inner classes as > opposed to top level classes, both IntelliJ and Eclipse will find the > inner class and top level class when typing "Logger". This will no > doubt cause many users to import the wrong one. I propose that these > classes are renamed to avoid this problem. The simplest would be to > change them from inner classes to top level classes "System.Logger" -> > "SystemLogger". Alternatively, they could stay as inner classes and be > prefixed "System.Logger" -> "System.SysLogger" or "System.Logger" -> > "System.BasicLogger". I usually like to avoid to have two classes with the same name in different packages. As you say it can be confusing when you mistakenly import the wrong one. In NetBeans - when doing name completion, System.Logger appears with a different font than j.u.l.Logger because it is an interface. And if you search the file - then obviously it is not proposed because it's an inner interface. After having worked with it for some time I find that using inner interfaces/classes for Logger and Level is not that bad. Certainly better than if it was a top-level class of the same name. It is fortunately rare that you need to use both (the System. and the j.u.l one) in the same class. It's hard to find a compelling new name though :-) best regards, -- daniel > > Stephen > From gil at azul.com Thu Oct 15 17:23:30 2015 From: gil at azul.com (Gil Tene) Date: Thu, 15 Oct 2015 17:23:30 +0000 Subject: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal In-Reply-To: <561FC6F9.1080701@cs.oswego.edu> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56164C3C.4050800@cs.oswego.edu> <561E6F04.9030708@cs.oswego.edu> <54AE479E-9891-48FB-AD47-ECED8147DABE@azul.com> <561FC6F9.1080701@cs.oswego.edu> Message-ID: <25B8ED3D-4B35-48F4-BF24-32D48E85343E@azul.com> > On Oct 15, 2015, at 11:32 PM, Doug Lea <dl at cs.oswego.edu> wrote: > > On 10/14/2015 11:53 PM, Gil Tene wrote: >> I agree on the separation between spin-hinting and monitor-like constructs. >> But not so much on the analogy to or use of the term "yield" to describe what >> is intended y spin hints. >> > > I've been focussing on the spec, which still seems to best support > this naming. Let's try fleshing out some more (for no-arg version). > > /** > * A hint to the platform that the current thread is momentarily > * unable to progress until the occurrence of one or more actions > * of one or more other threads. The method is mainly applicable > * in spin-then-block constructions entailing a bounded number > * of re-checks of a condition, separated by spinYield(), followed > * if necessary with use of a blocking synchronization mechanism. > */ > public static void spinYield(); I don't think that this is a good description of the use cases. Yes, the hint is helpful for spin-then-block constructions, but that's just a part of where it can help. In fact, I expect the hint to be very applicable for indefinitely-spinning loops, and I expect the measurable impact there to be much more reliably noticed because such loops are invariably concerned with fast reaction times above all else. I also don't think that the "?momentarily unable to progress until the occurrence of one or more actions of one or more other threads. " is true: while (!(done || (count++ > threshold))) { spinLoopHint(); } can progress without any action by any other thread. As noted in my proposed JavaDoc, I see the primary indication of the hint to be that the reaction time to events that would cause the loop to exit (e.g. in nanosecond units) is more important to the caller than the speed at which the loop is executing (e.g. in "number of loop iterations per second" units). So if we are focusing on the spec, here is my suggested (edited to be more specific ) spec: /** * Provide the JVM with a hint that this call is made from within a spinning * loop. The JVM may assume that the reaction time to events that would * cause the loop to terminate is more important than the speed of executing * the loop (e.g. in terms of number of loop iterations per second). * Power savings may also occur, but those are considered incidental to the * primary purpose of improving reaction time. The JVM will not slow down * the loop execution to a point where execution will be delayed indefinitely, * but other choices of loop execution speed are system-specific. Note that a * nop is a valid implementation of this hint. */ > What should be the response to this hint? When applicable > and available, the JVM should just issue PAUSE. But on a uniprocessor, > or when load average is easily detected to be high, or > on a tightly packed cloud node, a plain yield or something > along those lines might be a better use of this hint, that > the spec should not rule out. Anyone running indefinite spin loops on a uniprocessor deserves whatever they get. Yielding in order to help them out is not mercy. Let Darwin take care of them instead. But indefinite user-mode spinning on many-core systems is a valid and common use case (see the disruptor link in my previous e-mail). And because a spin loop hint is extremely useful for indefinitely spinning loop situations, and a spin hint is primarily intended to improve the reaction time of spin loops, I would describe any explicit yielding by the JVM at the hint point as mis-behavior. [Not quite an invalid behavior, because we don't want to specify allowed behavior too strongly, but certainly surprising, unexpected, and highly disappointing given the intent expressed by the hint]. Yes, the OS or hypervisor may choose to preempt a thread at any random point in code, including at these hint points, but that's their job and their problem, and not the JVM's. The JVM should not be in the business of voluntarily and implicitly yielding at specific points in code, and especially not at points in code that spins and hints that it wants to improve the performance of that spin. If what you want is a spin loop that yields, write one: while (!done) { yield(); }. I don't see how while (!done) { spinYield(); } has any different meaning to the reader. It just reads as something like "yield faster, knowing that you are in a spin". > Also, I believe that some x86 > hypervisors intercept PAUSE and do something roughly similar > after repeated invocations. As to hypervisor choices: preempting a guest OS at a PAUSE instruction is actually higher risk, since the PAUSE instruction could be taken while holding a ciritical kernel resource (e.g. mremap always grabs one spinlock while holding another spinlock). The trick most hypervisors seem to use is to prefer to preempt code in user mode rather than in kernel mode, since user mode code doesn't see preemption as an invalid operation, but kernel code paths (e.g those running under a spinlock) often consider losing the CPU for 200msec in a critical path a surprising thing and a valid cause for panic. >> While the spinYield() example in your e-mail below can work from a semantic >> point of view in the same code, IMO the word "yield" suggests the exact >> opposite of what spnLoopHint() is intending to do or hint at > > Maybe. If you are on a system with load > #cpus, or with > certain forms of hypervisor, or without a PAUSE instruction, > spinYield might not improve responsiveness but might still > improve system throughput. In such situations the spinning loop should just be calling yield(), or looping for a very short count (like your magic 64) and then yielding. A "magically choose for me whether reaction time or throughput or being nice to others is more important" call is not a useful hint IMO. Like in my uniprocessor comment above, any program spinning indefinitely (or for a non-trivial amount of time) with load > # cpus deserves what it gets. Allowing it to live longer/better with it's programmer's mistakes is just polluting the gene pool. > > -Doug > From semyon.sadetsky at oracle.com Thu Oct 15 18:09:57 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 15 Oct 2015 21:09:57 +0300 Subject: <AWT Dev> [9] RFR 8138838: docs cleanup for java.desktop In-Reply-To: <561E879A.6010906@oracle.com> References: <740a3bdd-3a72-44ec-b51f-83c98cac07ca@default> <560A6628.5010807@oracle.com> <CA+kOe0_RoiEvvquZ-5aJ401b1oePuDG+7vd0ufzgctpFhUfaLA@mail.gmail.com> <560C8970.50805@oracle.com> <CA+kOe0-YkE_886K0b_OY4G7kmunx9eTG0rxhaoVt8YKUsixFHA@mail.gmail.com> <560D199B.30708@oracle.com> <56125B1B.9070905@oracle.com> <561E879A.6010906@oracle.com> Message-ID: <561FEBF5.2080404@oracle.com> Hi Alexander, Since you are doing cosmetic changes, could please wrap the amended lines to 80 characters per line? Also some notes: MultiResolutionImage.java interface has a mix of verbose/implicit method modifiers. It would be nice to reduce it to the uniform style. MenuComponent.java : @param d - the <code>Dimension</code>... - Should it also be replaced with brackets? PrinterInfo.java - also <CODE> is used. --Semyon On 10/14/2015 7:49 PM, Alexander Stepanov wrote: > Sorry, just a reminder. If the activity is untimely, then could you > please review the following minimum part of fix? > > http://cr.openjdk.java.net/~avstepan/8138838/webrev.min.00/index.html > (some misprints + midget JDK-8138893 fixed). > > Thanks, > Alexander > > On 10/5/2015 2:12 PM, Alexander Stepanov wrote: >> Hello, >> >> Could you please review the fix for >> https://bugs.openjdk.java.net/browse/JDK-8138838 >> >> Patch + webrev zipped + specdiff report: >> http://cr.openjdk.java.net/~avstepan/8138838 >> >> Just some cosmetic changes for docs (<code>...</code> -> {@code ...} >> replacement) + some misprints fixed. >> >> Not sure if these changes are desired at all for now. >> >> Thanks, >> Alexander >> >> (Just in case, adding the prehistory and sending a copy to >> core-libs-dev). >> >> >> >> On 10/1/2015 2:31 PM, Alexander Stepanov wrote: >>> Hello Martin, Stuart, >>> >>> Thank you for the notes, >>> >>> Yes, the initial utility is quite ugly, I just tried to prepare it >>> as quickly as possible hoping that it covers the majority of >>> "trivial" replace cases. Yes, it does not process multi-line <code> >>> inclusions. >>> >>> > s = s.replace( "<CODE>", tag1); >>> > s = s.replace( "<Code>", tag1); >>> > s = s.replace("</CODE>", tag2); >>> > s = s.replace("</Code>", tag2); >>> >>> - replaced with "s = ln.replaceAll("(?i)<code>", >>> "<code>").replaceAll("(?i)</code>", "</code>");" >>> >>> Unfortunately my Perl/lisp knowledge are zero :) >>> >>> > Should you publish your specdiff? I guess not - it would be empty! >>> For now it contains a single fixed misprint diff, but there are a >>> few another misprints at the moment which I'd like to include in the >>> patch as well. >>> >>> So if you don't have objections, I'll delay for a several days and >>> then publish a final RFR (probably containing changes in some other >>> repos like jaxws, corba or jaxp) which would be more formal >>> (containing bug # and the final specdiff report). >>> >>> Thanks again, >>> Alexander >>> >>> >>> On 10/1/2015 9:54 AM, Martin Buchholz wrote: >>>> Hi s'marks, >>>> You probably don't need to absolutify paths. >>>> And you can easily handle multiple args. >>>> >>>> (just for fun!) >>>> Checks for javadoc comment; handles popular html entities; handles >>>> multiple lines; handles both tt and code: >>>> >>>> #!/bin/bash >>>> find "$@" -name '*.java' | \ >>>> xargs -r perl -p0777i -e \ >>>> 'do {} while s~^ >>>> *\*.*\K<(tt|code)>((?:[^<>{}\&\@]|&(?:lt|gt|amp);)*)</\1>~$_=$2; >>>> s/&lt;/</g; s/&gt;/>/g; s/&amp;/&/g; "{\@code $_}"~mgie' >>>> >>>> >>>> On Wed, Sep 30, 2015 at 6:16 PM, Stuart Marks >>>> <stuart.marks at oracle.com <mailto:stuart.marks at oracle.com>> wrote: >>>> >>>> Hi Alexander, Martin, >>>> >>>> The challenge of Perl file slurping and Emacs one-liners was too >>>> much to bear. >>>> >>>> This is Java, so one-liners are hardly possible. Still, there are >>>> a bunch of improvements that can be made to the Java version. (OK, >>>> and I'm showing off a bit.) >>>> >>>> Take a look at this: >>>> >>>> http://cr.openjdk.java.net/~smarks/misc/SimpleTagEditorSmarks1.java >>>> <http://cr.openjdk.java.net/%7Esmarks/misc/SimpleTagEditorSmarks1.java> >>>> >>>> >>>> I haven't studied the output exhaustively, but it seems to do a >>>> reasonably good job for the common cases. I ran it over java.lang >>>> and I noticed a few cases where there is markup embedded within >>>> <code></code> text, which should be looked at more closely. >>>> >>>> I don't particularly care if you use my version, but there are >>>> some techniques that I'd strongly recommend that you consider >>>> using in any such tool. In particular: >>>> >>>> - Pattern.DOTALL to do multi-line matches >>>> - Pattern.CASE_INSENSITIVE >>>> - try-with-resources to ensure that files are closed properly >>>> - NIO instead of old java.io <http://java.io> APIs, particularly >>>> Files.walk() and streams >>>> - use Scanner to deal with input file buffering >>>> - Scanner's stream support (I recently added this to JDK 9) >>>> >>>> Enjoy, >>>> >>>> s'marks >>>> >>>> >>>> >>>> On 9/29/15 2:23 PM, Martin Buchholz wrote: >>>> >>>> Hi Alexander, >>>> >>>> your change looks good. It's OK to have manual corrections >>>> for automated >>>> mega-changes like this, as long as they all revert changes. >>>> >>>> Random comments: >>>> >>>> Should you publish your specdiff? I guess not - it would be >>>> empty! >>>> >>>> while((s = br.readLine()) != null) { >>>> >>>> by matching only one line at a time, you lose the ability >>>> to make >>>> replacements that span lines. Perlers like to "slurp" in the >>>> entire file >>>> as a single string. >>>> >>>> s = s.replace( "<CODE>", tag1); >>>> s = s.replace( "<Code>", tag1); >>>> s = s.replace("</CODE>", tag2); >>>> s = s.replace("</Code>", tag2); >>>> >>>> Why not use case-insensitive regex? >>>> >>>> Here's an emacs-lisp one-liner I've been known to use: >>>> >>>> (defun tt-code () >>>> (interactive) >>>> (query-replace-regexp >>>> "<\\(tt\\|code\\)>\\([^&<>\\\\]+\\)</\\1>" "{@code >>>> \\2}")) >>>> >>>> With more work, one can automate transformation of embedded >>>> things like &lt; >>>> >>>> But of course, it's not even possible to transform ALL uses of >>>> <code> to >>>> {@code, if there was imaginative use of nested html tags. >>>> >>>> >>>> On Tue, Sep 29, 2015 at 3:21 AM, Alexander Stepanov < >>>> alexander.v.stepanov at oracle.com >>>> <mailto:alexander.v.stepanov at oracle.com>> wrote: >>>> >>>> Updated: a few manual corrections were made (as @linkplain >>>> tags displays >>>> nested {@code } literally): >>>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch >>>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/jdk.patch> >>>> -checked with specdiff (which of course does not cover >>>> documentation for >>>> internal packages), no unexpected diffs detected. >>>> >>>> Regards, >>>> Alexander >>>> >>>> >>>> On 9/27/2015 4:52 PM, Alexander Stepanov wrote: >>>> >>>> Hello Martin, >>>> >>>> Here is some simple app. to replace <code></code> tags >>>> with a new-style >>>> {@code } one (which is definitely not so elegant as >>>> the Perl one-liners): >>>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/SimpleTagEditor.java >>>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/SimpleTagEditor.java> >>>> >>>> >>>> Corresponding patch for jdk and replacement log (~62k >>>> of the tag changes): >>>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch >>>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/jdk.patch> >>>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/replace.log >>>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/replace.log> >>>> (sorry, I have to check the correctness of the patch >>>> with specdiff yet, >>>> so this is rather demo at the moment). >>>> >>>> Don't know if these changes (cosmetic by nature) are >>>> desired for now or >>>> not. Moreover, probably some part of them should go to >>>> another repos (e.g., >>>> awt, swing -> "client" instead of "dev"). >>>> >>>> Regards, >>>> Alexander >>>> >>> >> > From bob.vandette at oracle.com Thu Oct 15 18:10:05 2015 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 15 Oct 2015 14:10:05 -0400 Subject: RFR: 8136556 - Add the ability to perform static builds of MacOSX x64 binaries Message-ID: <B7374CF4-8168-488F-8E03-04282666FCE1@oracle.com> Please review this JDK 9 enhancement which allows a completely static build of the JDK for MacOSX x64 platforms. https://bugs.openjdk.java.net/browse/JDK-8136556 <https://bugs.openjdk.java.net/browse/JDK-8136556> The change involves: 1. Producing ?.a? archives for each native libraries. 2. Ensuring that all symbols across the JDK native libraries are unique. 3. Changing the JNI_OnLoad and JNI_OnUnload (and the Agent equivalents) to have the each library name appended per the JNI specification. 4. Modifications to the launcher and launcher Makefiles to allow them to be linked with the java.base and jdk.jdwp.agent libraries and function. http://cr.openjdk.java.net/~bobv/8136556/webrev.00/ <http://cr.openjdk.java.net/~bobv/8136556/webrev.00/> http://cr.openjdk.java.net/~bobv/8136556/hotspot/webrev.00/ <http://cr.openjdk.java.net/~bobv/8136556/hotspot/webrev.00/> http://cr.openjdk.java.net/~bobv/8136556/jdk/webrev.00/ <http://cr.openjdk.java.net/~bobv/8136556/jdk/webrev.00/> Note: This change does not link every possible static library with the launchers. It is currently limited to the java.base and jdk.jdwp.agent libraries in order to allow for the TCK validation of the base module only. Bob. From claes.redestad at oracle.com Thu Oct 15 20:33:20 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 15 Oct 2015 22:33:20 +0200 Subject: RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes Message-ID: <56200D90.3000406@oracle.com> Hi all, java.util.jar.JarFile could be improved further by using InputStream.readNBytes when there's information in the ZipEntry about the entry size. Webrev: http://cr.openjdk.java.net/~redestad/8139706/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8139706 Testing: verified improvements in internal startup/footprint tests /Claes From ecki at zusammenkunft.net Thu Oct 15 20:59:01 2015 From: ecki at zusammenkunft.net (ecki at zusammenkunft.net) Date: Thu, 15 Oct 2015 22:59:01 +0200 Subject: RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes In-Reply-To: <56200D90.3000406@oracle.com> References: <56200D90.3000406@oracle.com> Message-ID: <d4d54041-b8b9-4d9c-8a97-71f48be1f5cf.maildroid@localhost> Hello, This does change a bit the semantic of the length check. If the stream would return more bytes than the zipentry says the new version would ignore them, the old version was consuming then and then fail the check. However I am not sure if this is relevant. Gruss Bernd -- http://bernd.eckenfels.net -----Original Message----- From: Claes Redestad <claes.redestad at oracle.com> To: "core-libs-dev at openjdk.java.net Libs" <core-libs-dev at openjdk.java.net> Sent: Do., 15 Okt. 2015 22:43 Subject: RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes Hi all, java.util.jar.JarFile could be improved further by using InputStream.readNBytes when there's information in the ZipEntry about the entry size. Webrev: http://cr.openjdk.java.net/~redestad/8139706/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8139706 Testing: verified improvements in internal startup/footprint tests /Claes From mark.reinhold at oracle.com Thu Oct 15 21:12:49 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 15 Oct 2015 14:12:49 -0700 Subject: [9] RFR(XS): 8137173: @HotSpotIntrinsicCandidate is not Oracle-specific In-Reply-To: <560E1CDF.7070307@oracle.com> References: <560D51BD.6030108@oracle.com>, <560D540E.4090609@oracle.com>, <20151001085441.434440@eggemoggin.niobe.net>, <560E1CDF.7070307@oracle.com> Message-ID: <20151015141249.801300@eggemoggin.niobe.net> 2015/10/1 10:57 -0700, zoltan.majo at oracle.com: > On 10/01/2015 05:54 PM, mark.reinhold at oracle.com wrote: >> I suggest putting this into jdk.internal.vm.annotation, which is >> also a good place for the ReservedStackAccess annotation envisioned >> in JEP 270 (http://openjdk.java.net/jeps/270). > > I filed an RFE, JDK-8138732: "move @HotSpotIntrinsicCandidate to the > jdk.internal.vm.annotation package" [1], to track the issue of moving > the annotation to a different package. I hope I can take care of it soon. > > Thank you and best regards, Thanks. While you're at it, could you please rename the annotation to @IntrinsicCandidate? There's no need for the "HotSpot" prefix any more since this annotation will now be in a package that is reserved for VM-specific annotations. (Sorry for this late suggestion; this just came up in a discussion of the @ReservedStackAccess annotation for JEP 270, which is also destined for the jdk.internal.vm.annotation package.) (I've pasted this addendum into JDK-8138732.) - Mark From claes.redestad at oracle.com Thu Oct 15 21:16:12 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 15 Oct 2015 23:16:12 +0200 Subject: RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes In-Reply-To: <d4d54041-b8b9-4d9c-8a97-71f48be1f5cf.maildroid@localhost> References: <56200D90.3000406@oracle.com> <d4d54041-b8b9-4d9c-8a97-71f48be1f5cf.maildroid@localhost> Message-ID: <5620179C.6020109@oracle.com> Hi Bernd, thanks for looking at this! You're right about the semantic change for this patch in isolation, but compared to the previous implementation that used sun.misc.IOUtils the semantics are unchanged (compare with theprevious implementation of JarFiles::getBytes and sun.misc.IOUtils::readFully in http://hg.openjdk.java.net/jdk9/dev/jdk/rev/5537b74dea17 ) /Claes On 2015-10-15 22:59, ecki at zusammenkunft.net wrote: > Hello, > > This does change a bit the semantic of the length check. If the stream would return more bytes than the zipentry says the new version would ignore them, the old version was consuming then and then fail the check. However I am not sure if this is relevant. > > Gruss > Bernd > From chris.hegarty at oracle.com Thu Oct 15 21:21:33 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 15 Oct 2015 22:21:33 +0100 Subject: RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes In-Reply-To: <d4d54041-b8b9-4d9c-8a97-71f48be1f5cf.maildroid@localhost> References: <56200D90.3000406@oracle.com> <d4d54041-b8b9-4d9c-8a97-71f48be1f5cf.maildroid@localhost> Message-ID: <323C4C63-649F-4F20-9E5A-82B9A8BFA8B1@oracle.com> > On 15 Oct 2015, at 21:59, ecki at zusammenkunft.net wrote: > > Hello, > > This does change a bit the semantic of the length check. If the stream would return more bytes than the zipentry says the new version would ignore them, the old version was consuming then and then fail the check. However I am not sure if this is relevant. Right, there are certainly some subtle differences resulting from the proposed change. When working on JDK-8138978 I thought about using readNBytes, but played it safe as IOUtils was growing the bye[] lazily too, so no real perf difference. In fact, I think I seen a test failure with using readNBytes here. I?ll have to check. -Chris. > Gruss > Bernd > > -- > http://bernd.eckenfels.net > > -----Original Message----- > From: Claes Redestad <claes.redestad at oracle.com> > To: "core-libs-dev at openjdk.java.net Libs" <core-libs-dev at openjdk.java.net> > Sent: Do., 15 Okt. 2015 22:43 > Subject: RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes > > Hi all, > > java.util.jar.JarFile could be improved further by using > InputStream.readNBytes when there's information in the ZipEntry about > the entry size. > > Webrev: http://cr.openjdk.java.net/~redestad/8139706/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8139706 > > Testing: verified improvements in internal startup/footprint tests > > /Claes From claes.redestad at oracle.com Thu Oct 15 22:08:13 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 16 Oct 2015 00:08:13 +0200 Subject: RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes In-Reply-To: <323C4C63-649F-4F20-9E5A-82B9A8BFA8B1@oracle.com> References: <56200D90.3000406@oracle.com> <d4d54041-b8b9-4d9c-8a97-71f48be1f5cf.maildroid@localhost> <323C4C63-649F-4F20-9E5A-82B9A8BFA8B1@oracle.com> Message-ID: <562023CD.9070406@oracle.com> On 2015-10-15 23:21, Chris Hegarty wrote: >> On 15 Oct 2015, at 21:59, ecki at zusammenkunft.net wrote: >> >> Hello, >> >> This does change a bit the semantic of the length check. If the stream would return more bytes than the zipentry says the new version would ignore them, the old version was consuming then and then fail the check. However I am not sure if this is relevant. > Right, there are certainly some subtle differences resulting from > the proposed change. When working on JDK-8138978 I thought > about using readNBytes, but played it safe as IOUtils was growing > the bye[] lazily too, so no real perf difference. In fact, I think I seen > a test failure with using readNBytes here. I?ll have to check. Seeing no jtreg test failures in java/util/zip nor java/util/jar (apart from 2 ignored tests), but I can see a reason for the current implementation being conservative: Corrupt/malicious jar files might lie about the entry length and report very large values, which could bring a down with OOME. I believe we could be both safe and faster than baseline by adding a reasonable limit for when to use readNBytes, e.g., 32k would deal with the majority of .class files. /Claes From chris.hegarty at oracle.com Thu Oct 15 22:12:59 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 15 Oct 2015 23:12:59 +0100 Subject: RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes In-Reply-To: <562023CD.9070406@oracle.com> References: <56200D90.3000406@oracle.com> <d4d54041-b8b9-4d9c-8a97-71f48be1f5cf.maildroid@localhost> <323C4C63-649F-4F20-9E5A-82B9A8BFA8B1@oracle.com> <562023CD.9070406@oracle.com> Message-ID: <F30D458F-E1F1-472A-B7C7-66BC9C3EC285@oracle.com> > On 15 Oct 2015, at 11:08 p.m., Claes Redestad <claes.redestad at oracle.com> wrote: > > > On 2015-10-15 23:21, Chris Hegarty wrote: >>> On 15 Oct 2015, at 21:59, ecki at zusammenkunft.net wrote: >>> >>> Hello, >>> >>> This does change a bit the semantic of the length check. If the stream would return more bytes than the zipentry says the new version would ignore them, the old version was consuming then and then fail the check. However I am not sure if this is relevant. >> Right, there are certainly some subtle differences resulting from >> the proposed change. When working on JDK-8138978 I thought >> about using readNBytes, but played it safe as IOUtils was growing >> the bye[] lazily too, so no real perf difference. In fact, I think I seen >> a test failure with using readNBytes here. I?ll have to check. > > Seeing no jtreg test failures in java/util/zip nor java/util/jar (apart from 2 ignored tests), but I can see a reason for the current implementation being conservative: Corrupt/malicious jar files might lie about the entry length and report very large values, which could bring a down with OOME. > > I believe we could be both safe and faster than baseline by adding a reasonable limit for when to use readNBytes, e.g., 32k would deal with the majority of .class files. Sounds good to me. -Chris. > /Claes From christian.thalinger at oracle.com Thu Oct 15 22:30:08 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 15 Oct 2015 12:30:08 -1000 Subject: RFR: 8136556 - Add the ability to perform static builds of MacOSX x64 binaries In-Reply-To: <B7374CF4-8168-488F-8E03-04282666FCE1@oracle.com> References: <B7374CF4-8168-488F-8E03-04282666FCE1@oracle.com> Message-ID: <53008404-633F-4EF9-BC7C-708AFC0B26DF@oracle.com> Copy-pasting the comment I made earlier (internally): >> make/bsd/makefiles/gcc.make: >> >> + ifeq ($(BUILD_STATIC),true) >> + CXXFLAGS += -DSTATIC_BUILD >> + CFLAGS += -DSTATIC_BUILD >> >> Can we use the same name everywhere? > > We were trying to differentiate Makefile options from compile time conditionals. > In one case it?s set to true and the other it?s defined. > > Are there no other cases where this is done? I?m not sure but looking at make/excludeSrc.make all of them use the same name. > On Oct 15, 2015, at 8:10 AM, Bob Vandette <bob.vandette at oracle.com> wrote: > > Please review this JDK 9 enhancement which allows a completely static build of the JDK for MacOSX x64 platforms. > > https://bugs.openjdk.java.net/browse/JDK-8136556 <https://bugs.openjdk.java.net/browse/JDK-8136556> > > The change involves: > > 1. Producing ?.a? archives for each native libraries. > 2. Ensuring that all symbols across the JDK native libraries are unique. > 3. Changing the JNI_OnLoad and JNI_OnUnload (and the Agent equivalents) to have the each library name appended per > the JNI specification. > 4. Modifications to the launcher and launcher Makefiles to allow them to be linked with the java.base and jdk.jdwp.agent libraries > and function. > > http://cr.openjdk.java.net/~bobv/8136556/webrev.00/ <http://cr.openjdk.java.net/~bobv/8136556/webrev.00/> > http://cr.openjdk.java.net/~bobv/8136556/hotspot/webrev.00/ <http://cr.openjdk.java.net/~bobv/8136556/hotspot/webrev.00/> > http://cr.openjdk.java.net/~bobv/8136556/jdk/webrev.00/ <http://cr.openjdk.java.net/~bobv/8136556/jdk/webrev.00/> > > Note: This change does not link every possible static library with the launchers. It is currently limited to > the java.base and jdk.jdwp.agent libraries in order to allow for the TCK validation of the base module only. > > > Bob. From xueming.shen at oracle.com Fri Oct 16 02:09:58 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 15 Oct 2015 19:09:58 -0700 Subject: RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes In-Reply-To: <562023CD.9070406@oracle.com> References: <56200D90.3000406@oracle.com> <d4d54041-b8b9-4d9c-8a97-71f48be1f5cf.maildroid@localhost> <323C4C63-649F-4F20-9E5A-82B9A8BFA8B1@oracle.com> <562023CD.9070406@oracle.com> Message-ID: <56205C76.3060201@oracle.com> On 10/15/15 3:08 PM, Claes Redestad wrote: > > On 2015-10-15 23:21, Chris Hegarty wrote: >>> On 15 Oct 2015, at 21:59, ecki at zusammenkunft.net wrote: >>> >>> Hello, >>> >>> This does change a bit the semantic of the length check. If the >>> stream would return more bytes than the zipentry says the new >>> version would ignore them, the old version was consuming then and >>> then fail the check. However I am not sure if this is relevant. >> Right, there are certainly some subtle differences resulting from >> the proposed change. When working on JDK-8138978 I thought >> about using readNBytes, but played it safe as IOUtils was growing >> the bye[] lazily too, so no real perf difference. In fact, I think I >> seen >> a test failure with using readNBytes here. I?ll have to check. > > Seeing no jtreg test failures in java/util/zip nor java/util/jar > (apart from 2 ignored tests), but I can see a reason for the current > implementation being conservative: Corrupt/malicious jar files might > lie about the entry length and report very large values, which could > bring a down with OOME. > > I believe we could be both safe and faster than baseline by adding a > reasonable limit for when to use readNBytes, e.g., 32k would deal with > the majority of .class files. > getBytes should be used to read the meta-inf files only, not the .class files. -sherman From xueming.shen at oracle.com Fri Oct 16 03:47:44 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 15 Oct 2015 20:47:44 -0700 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <A8D7EE96-1238-401D-813D-E977CCD9E73F@oracle.com> References: <F7C2BACE-2E86-4058-8136-F565799494F8@oracle.com> <561ED8BF.40901@oracle.com> <CC71DAAE-940B-47EB-A2F2-FFB89F2EBAD3@oracle.com> <561F16C1.6090702@oracle.com> <A8D7EE96-1238-401D-813D-E977CCD9E73F@oracle.com> Message-ID: <56207360.6040502@oracle.com> On 10/15/15 1:53 AM, Paul Sandoz wrote: >> On 15 Oct 2015, at 05:00, Xueming Shen <xueming.shen at oracle.com> wrote: >> >> I'm not sure if it is a good idea, from performance perspective, to add a "versionEntry" field into the JarEntry >> to support this feature, given most of the jar files might not be multi-release-jar aware, and the Jar input& >> output streams dont work with a multi-release jar directly. Why should they all pay a runtime price for it. If >> we really have to add an extra field, the JarFileEntry might be a better place, and it might be desired to >> define a new subclass JarFileEntryMR to use when the MR is enabled, instead of adding directly into the existing >> JarFileEntry. >> > According to jol there is currently space available due to alignment. If there was not it would add about 4% in direct instance size. But the actual footprint is likely to be chunkier because of the string character storage for the name so the % increase in size would be smaller e.g. perhaps on average < 2% which might be ok given that i presume such entries are unlikely to be cached. > > So i am not concerned about the size. If there was a way to design it to avoid modification of existing classes all the better, but i dunno if it is possible. Steve will surely know more. > > Paul. > Let's try it from another angle:-) Based on the webrev, no one need to and actually does create a JarEntry with a versionedEntry, except JarFile, and JarFile only creates its own version of JarEntry, the JarFileEntry. The only non-JarFile consumer of "versioned" JarEntry is the package private JarVerifier.getCoderSigners, and obviously it takes a JarFile together with the source JarEntry (again, if this jarEntry is not from A JarFile, it should never have a "versionedEntry") So why do you want to put this field into the super class JarEntry, not the JarFileEntry, don't see any benefit of doing that. While I'm writing this email, it appears to me that we might have a more "severe" issue with the general/base JarEntry class to hold the link to the "versionedEntry". The "general" JarEntry object is not associated with a specific JarFile (the JarFileEntry does). So there is no way for JarFile.getInputStream(ZipFile ze) to verify that the JarEntry passed in and its "versionedEntry" is actually belong to "this" JarFile in the following implementation, if the "ze" is just a JarEntry but NOT instanceof of a JarFileEntry 759 public synchronized InputStream getInputStream(ZipEntry ze) 760 throws IOException 761 { 762 maybeInstantiateVerifier(); 763 764 if (ze instanceof JarEntry) { 765 ZipEntry vze = ((JarEntry)ze).versionedEntry; 766 if (vze != null) { 767 return getInputStream(vze); 768 } 769 } 770 I think it's a bug of the implementation if we don't check, as the "versioned entry" is really associated to the jar file that creates it. Sure, as I said above, there is actually no way you can create a general JarEntry or a JarFileEntry with a "versionedEntry" from "outside", but it appears to be possible (have not tried, just in theory) to mess up the current mechanism by passing a "jar entry" from one JarFile instance to another one, if two JarFile instances are open on the same multi-release-jar, but with different "version setting" policy... But again, I still believe it might be a wrong approach to add such a "versionedEntry" into any of the JarEntry, including the JarFileEntry. As specified by the specification, the returned entry should be the jar entry pointing to the versioned entity in the Jar File, not the root one. The question I would like to ask is why do you even need the "root entry" at all, if there is a matched versioned one. It might be desired to have a mechanism to return the "base/root name" for such an entry, but it probably does not deserve a "dedicate" entry object. -Sherman > > From Alan.Bateman at oracle.com Fri Oct 16 06:28:43 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 16 Oct 2015 07:28:43 +0100 Subject: RFR: 8136556 - Add the ability to perform static builds of MacOSX x64 binaries In-Reply-To: <EFE473E9-96C6-49D5-BA84-81D6011B579C@oracle.com> References: <EFE473E9-96C6-49D5-BA84-81D6011B579C@oracle.com> Message-ID: <5620991B.8050606@oracle.com> On 15/10/2015 19:07, Bob Vandette wrote: > Please review this JDK 9 enhancement which allows a completely static build of the JDK for MacOSX x64 platforms. > > https://bugs.openjdk.java.net/browse/JDK-8136556 <https://bugs.openjdk.java.net/browse/JDK-8136556> > > The change involves: > > 1. Producing ?.a? archives for each native libraries. > 2. Ensuring that all symbols across the JDK native libraries are unique. > 3. Changing the JNI_OnLoad and JNI_OnUnload (and the Agent equivalents) to have the each library name appended per > the JNI specification. > 4. Modifications to the launcher and launcher Makefiles to allow them to be linked with the java.base and jdk.jdwp.agent libraries > and function. > > http://cr.openjdk.java.net/~bobv/8136556/webrev.00/ <http://cr.openjdk.java.net/~bobv/8136556/webrev.00/> > http://cr.openjdk.java.net/~bobv/8136556/hotspot/webrev.00/ <http://cr.openjdk.java.net/~bobv/8136556/hotspot/webrev.00/> > http://cr.openjdk.java.net/~bobv/8136556/jdk/webrev.00/ <http://cr.openjdk.java.net/~bobv/8136556/jdk/webrev.00/> > > Note: This change does not link every possible static library with the launchers. It is currently limited to > the java.base and jdk.jdwp.agent libraries in order to allow for the TCK validation of the base module only. > I've skimmed through the patches and the DEF_* macros look okay. The only one that doesn't look right is jawt.h/jawt.c. As jawt.h is shipped by the JDK then I think the include of jni_util.h needs to move from jawt.h to jawt.c. If I read the changes correctly then not loading the JavaRuntimeSupport.framework on Mac means the locale might not be right, is that correct? Brent might remember this issue as we've often pondered the implications of this disappearing in an Mac update. Will there be continuous or at least regular builds setup so that build breakages will be reported in a timely manner? It would be easy to change something that breaks the static library build. -Alan From zoltan.majo at oracle.com Fri Oct 16 08:21:50 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 16 Oct 2015 10:21:50 +0200 Subject: [9] RFR(XS): 8137173: @HotSpotIntrinsicCandidate is not Oracle-specific In-Reply-To: <20151015141249.801300@eggemoggin.niobe.net> References: <560D51BD.6030108@oracle.com> <560D540E.4090609@oracle.com> <20151001085441.434440@eggemoggin.niobe.net> <560E1CDF.7070307@oracle.com> <20151015141249.801300@eggemoggin.niobe.net> Message-ID: <5620B39E.8070501@oracle.com> Hi Mark, On 10/15/2015 11:12 PM, mark.reinhold at oracle.com wrote: > 2015/10/1 10:57 -0700, zoltan.majo at oracle.com: >> On 10/01/2015 05:54 PM, mark.reinhold at oracle.com wrote: >>> I suggest putting this into jdk.internal.vm.annotation, which is >>> also a good place for the ReservedStackAccess annotation envisioned >>> in JEP 270 (http://openjdk.java.net/jeps/270). >> I filed an RFE, JDK-8138732: "move @HotSpotIntrinsicCandidate to the >> jdk.internal.vm.annotation package" [1], to track the issue of moving >> the annotation to a different package. I hope I can take care of it soon. >> >> Thank you and best regards, > Thanks. While you're at it, could you please rename the annotation to > @IntrinsicCandidate? There's no need for the "HotSpot" prefix any more > since this annotation will now be in a package that is reserved for > VM-specific annotations. > > (Sorry for this late suggestion; this just came up in a discussion of > the @ReservedStackAccess annotation for JEP 270, which is also destined > for the jdk.internal.vm.annotation package.) > > (I've pasted this addendum into JDK-8138732.) thank you for updating the bug description! Best regards, Zoltan > > - Mark From daniel.fuchs at oracle.com Fri Oct 16 10:44:22 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 16 Oct 2015 12:44:22 +0200 Subject: RFR: JDK-8046565: Platform Logger API and Service In-Reply-To: <17C7339F-2107-49DE-B909-A65D779F0DF1@oracle.com> References: <561660DA.7070900@oracle.com> <8D8890A3-2337-4178-BA5C-CC32DE12F27D@oracle.com> <561E3A9A.9050807@oracle.com> <6241BCF8-C6A3-4E64-94E9-5E70CEF4A829@oracle.com> <561E8CE7.9020609@oracle.com> <17C7339F-2107-49DE-B909-A65D779F0DF1@oracle.com> Message-ID: <5620D506.1080705@oracle.com> Hi Mandy, On 14/10/15 22:57, Mandy Chung wrote: > Addiitional comments: > > JdkLoggerProvider.java > - should the GC?ed referent entries in the application SharedLoggers map be occasionally drained? Right. Will do. > BootstrapLogger.java > In the BootstrapExecutors::join(Runnable r) method: > try { > getExecutor().submit(r).get(); > } catch (InterruptedException | ExecutionException ex) { > // should not happen > ex.printStackTrace(System.err); > } > - we should avoid output any debugging code though. OK. This is only used in unit tests. I will rethrow a RuntimeException instead. > typos: > indepedent > temporarilly Thanks. > // Unfortunately, if we come to here it means we are in the bootsraping > // phase where using lambdas is not safe yet - so we have to use a > // a data object instead? > FYI. jake has changed the system initialization sequence that allows the use of lambda early at startup. That may help in this case that you can revisit this in the future. > > This reminds me the startup performance. Is there any use System.Logger to log message during startup in JDK 9? Using lambda at startup will have impact to the startup performance. Depends on the definition of 'startup'. java.desktop can be very verbose when you enable its loggers. > Also I?m curious to know the difference of classes loaded at startup if System.getLogger is called in one of the system class loaded during startup but no log message is output (as typical case is to print debugging message) with and without java.logging. Yes, that would be interesting. > // Not sure whether this is needed: it was in the original > // PlatformLogger proxy code: > - I don?t understand why sun.util.logger.LazyLoggers$JdkLazyLogger need to be loaded. DetectBackend is loaded only after booted (per the comment) OK - will remove this. > > Naming nit: > PlatformLoggerBridge - would it be better to move to PlatformLogger.Bridge? It?s nit and I think it reads better and clearly associate with PlatformLogger. That could be a good idea. -- daniel > > Mandy > From scolebourne at joda.org Fri Oct 16 11:16:20 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 16 Oct 2015 12:16:20 +0100 Subject: RFR: JDK-8046565: Platform Logger API and Service In-Reply-To: <561FD4C6.1020803@oracle.com> References: <561660DA.7070900@oracle.com> <8D8890A3-2337-4178-BA5C-CC32DE12F27D@oracle.com> <561E3A9A.9050807@oracle.com> <CACzrW9Dp3wUHk=TY=nfApczW5GfgGpWj7R9bcGRPXr9VGqH7fA@mail.gmail.com> <561FD4C6.1020803@oracle.com> Message-ID: <CACzrW9AzE0QkL+TjdOCoMN=4Epadkh27ybgC9nWv=LwHDrvfWg@mail.gmail.com> On 15 October 2015 at 17:31, Daniel Fuchs <daniel.fuchs at oracle.com> wrote: >> I have a major concern that the class names 'Logger' and 'Level' >> duplicate those of java.util.logging. While they are inner classes as >> opposed to top level classes, both IntelliJ and Eclipse will find the >> inner class and top level class when typing "Logger". This will no >> doubt cause many users to import the wrong one. I propose that these >> classes are renamed to avoid this problem. The simplest would be to >> change them from inner classes to top level classes "System.Logger" -> >> "SystemLogger". Alternatively, they could stay as inner classes and be >> prefixed "System.Logger" -> "System.SysLogger" or "System.Logger" -> >> "System.BasicLogger". > > > After having worked with it for some time I find that using > inner interfaces/classes for Logger and Level is not that > bad. Certainly better than if it was a top-level class of > the same name. It is fortunately rare that you need to use > both (the System. and the j.u.l one) in the same class. > > It's hard to find a compelling new name though :-) Since I assume the purpose of these new Logger/Level interfaces is simplistic and primarily for the JDK's own use, a name that emphasises that would seem reasonable, hence BasicLogger/BasicLoggerLevel or similar. Stephen From claes.redestad at oracle.com Fri Oct 16 11:49:43 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 16 Oct 2015 13:49:43 +0200 Subject: RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes In-Reply-To: <56205C76.3060201@oracle.com> References: <56200D90.3000406@oracle.com> <d4d54041-b8b9-4d9c-8a97-71f48be1f5cf.maildroid@localhost> <323C4C63-649F-4F20-9E5A-82B9A8BFA8B1@oracle.com> <562023CD.9070406@oracle.com> <56205C76.3060201@oracle.com> Message-ID: <5620E457.2020506@oracle.com> On 2015-10-16 04:09, Xueming Shen wrote: > On 10/15/15 3:08 PM, Claes Redestad wrote: >> >> On 2015-10-15 23:21, Chris Hegarty wrote: >>>> On 15 Oct 2015, at 21:59, ecki at zusammenkunft.net wrote: >>>> >>>> Hello, >>>> >>>> This does change a bit the semantic of the length check. If the >>>> stream would return more bytes than the zipentry says the new >>>> version would ignore them, the old version was consuming then and >>>> then fail the check. However I am not sure if this is relevant. >>> Right, there are certainly some subtle differences resulting from >>> the proposed change. When working on JDK-8138978 I thought >>> about using readNBytes, but played it safe as IOUtils was growing >>> the bye[] lazily too, so no real perf difference. In fact, I think >>> I seen >>> a test failure with using readNBytes here. I?ll have to check. >> >> Seeing no jtreg test failures in java/util/zip nor java/util/jar >> (apart from 2 ignored tests), but I can see a reason for the current >> implementation being conservative: Corrupt/malicious jar files might >> lie about the entry length and report very large values, which could >> bring a down with OOME. >> >> I believe we could be both safe and faster than baseline by adding a >> reasonable limit for when to use readNBytes, e.g., 32k would deal >> with the majority of .class files. >> > getBytes should be used to read the meta-inf files only, not the > .class files. Correct, but this is still enough to cause statistically significant increases on our footprint measures. With a reasonable trust limit this change should be safe while avoiding most temporary byte[] allocations when reading meta-inf files. I've verified the startup and footprint numbers and ran it through all java/util/jar and /zip tests without error. New webrev: http://cr.openjdk.java.net/~redestad/8139706/webrev.02/ /Claes > > -sherman From chris.hegarty at oracle.com Fri Oct 16 12:03:21 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 16 Oct 2015 13:03:21 +0100 Subject: RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes In-Reply-To: <5620E457.2020506@oracle.com> References: <56200D90.3000406@oracle.com> <d4d54041-b8b9-4d9c-8a97-71f48be1f5cf.maildroid@localhost> <323C4C63-649F-4F20-9E5A-82B9A8BFA8B1@oracle.com> <562023CD.9070406@oracle.com> <56205C76.3060201@oracle.com> <5620E457.2020506@oracle.com> Message-ID: <5620E789.3020204@oracle.com> On 16/10/15 12:49, Claes Redestad wrote: > On 2015-10-16 04:09, Xueming Shen wrote: >> On 10/15/15 3:08 PM, Claes Redestad wrote: >>> >>> On 2015-10-15 23:21, Chris Hegarty wrote: >>>>> On 15 Oct 2015, at 21:59, ecki at zusammenkunft.net wrote: >>>>> >>>>> Hello, >>>>> >>>>> This does change a bit the semantic of the length check. If the >>>>> stream would return more bytes than the zipentry says the new >>>>> version would ignore them, the old version was consuming then and >>>>> then fail the check. However I am not sure if this is relevant. >>>> Right, there are certainly some subtle differences resulting from >>>> the proposed change. When working on JDK-8138978 I thought >>>> about using readNBytes, but played it safe as IOUtils was growing >>>> the bye[] lazily too, so no real perf difference. In fact, I think >>>> I seen >>>> a test failure with using readNBytes here. I?ll have to check. >>> >>> Seeing no jtreg test failures in java/util/zip nor java/util/jar >>> (apart from 2 ignored tests), but I can see a reason for the current >>> implementation being conservative: Corrupt/malicious jar files might >>> lie about the entry length and report very large values, which could >>> bring a down with OOME. >>> >>> I believe we could be both safe and faster than baseline by adding a >>> reasonable limit for when to use readNBytes, e.g., 32k would deal >>> with the majority of .class files. >>> >> getBytes should be used to read the meta-inf files only, not the >> .class files. > > Correct, but this is still enough to cause statistically significant > increases on our footprint measures. > > With a reasonable trust limit this change should be safe while avoiding > most temporary byte[] allocations when reading meta-inf files. I've > verified the startup and footprint numbers and ran it through all > java/util/jar and /zip tests without error. > > New webrev: http://cr.openjdk.java.net/~redestad/8139706/webrev.02/ This latest webrev looks good to me. -Chris. > /Claes > >> >> -sherman > From yuka.kamiya at oracle.com Fri Oct 16 12:41:33 2015 From: yuka.kamiya at oracle.com (Yuka Kamiya) Date: Fri, 16 Oct 2015 21:41:33 +0900 Subject: [9] RFR: 8072600: Unicode 8 support Message-ID: <5620F07D.8030109@oracle.com> Hello, Please review a small change for 8072600: Unicode 8 support. Mainly date update from Unicode 7. JEP: http://openjdk.java.net/jeps/267 Issue: https://bugs.openjdk.java.net/browse/JDK-8072600 webrev: http://cr.openjdk.java.net/~peytoia/8072600/ Thanks, -- Yuka From Alan.Bateman at oracle.com Fri Oct 16 13:28:12 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 16 Oct 2015 14:28:12 +0100 Subject: RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes In-Reply-To: <5620E457.2020506@oracle.com> References: <56200D90.3000406@oracle.com> <d4d54041-b8b9-4d9c-8a97-71f48be1f5cf.maildroid@localhost> <323C4C63-649F-4F20-9E5A-82B9A8BFA8B1@oracle.com> <562023CD.9070406@oracle.com> <56205C76.3060201@oracle.com> <5620E457.2020506@oracle.com> Message-ID: <5620FB6C.8030009@oracle.com> On 16/10/2015 12:49, Claes Redestad wrote: > > Correct, but this is still enough to cause statistically significant > increases on our footprint measures. > > With a reasonable trust limit this change should be safe while > avoiding most temporary byte[] allocations when reading meta-inf > files. I've verified the startup and footprint numbers and ran it > through all java/util/jar and /zip tests without error. > > New webrev: http://cr.openjdk.java.net/~redestad/8139706/webrev.02/ You could probably use readNBytes for larger sizes than 64k but what you have looks fine. -Alan. From daniel.fuchs at oracle.com Fri Oct 16 14:16:49 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 16 Oct 2015 16:16:49 +0200 Subject: RFR: JDK-8046565: Platform Logger API and Service In-Reply-To: <17C7339F-2107-49DE-B909-A65D779F0DF1@oracle.com> References: <561660DA.7070900@oracle.com> <8D8890A3-2337-4178-BA5C-CC32DE12F27D@oracle.com> <561E3A9A.9050807@oracle.com> <6241BCF8-C6A3-4E64-94E9-5E70CEF4A829@oracle.com> <561E8CE7.9020609@oracle.com> <17C7339F-2107-49DE-B909-A65D779F0DF1@oracle.com> Message-ID: <562106D1.7080205@oracle.com> Hi Mandy, I have integrated most of your comments and updated the api specdiff and webrev (new links), and also pushed the corresponding changes to the sandbox. Thanks for working with me on the API doc! specdiff: http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/specdiff-api/overview-summary.html webrev: http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/webrev/ sandbox: JDK-8046565-branch instructions: http://cr.openjdk.java.net/~chegar/docs/sandbox.html best regards, -- daniel On 14/10/15 22:57, Mandy Chung wrote: > Addiitional comments: > > JdkLoggerProvider.java > - should the GC?ed referent entries in the application SharedLoggers map be occasionally drained? > > BootstrapLogger.java > In the BootstrapExecutors::join(Runnable r) method: > try { > getExecutor().submit(r).get(); > } catch (InterruptedException | ExecutionException ex) { > // should not happen > ex.printStackTrace(System.err); > } > - we should avoid output any debugging code though. > > typos: > indepedent > temporarilly > > // Unfortunately, if we come to here it means we are in the bootsraping > // phase where using lambdas is not safe yet - so we have to use a > // a data object instead? > FYI. jake has changed the system initialization sequence that allows the use of lambda early at startup. That may help in this case that you can revisit this in the future. > > This reminds me the startup performance. Is there any use System.Logger to log message during startup in JDK 9? Using lambda at startup will have impact to the startup performance. > > Also I?m curious to know the difference of classes loaded at startup if System.getLogger is called in one of the system class loaded during startup but no log message is output (as typical case is to print debugging message) with and without java.logging. > > // Not sure whether this is needed: it was in the original > // PlatformLogger proxy code: > - I don?t understand why sun.util.logger.LazyLoggers$JdkLazyLogger need to be loaded. DetectBackend is loaded only after booted (per the comment) > > Naming nit: > PlatformLoggerBridge - would it be better to move to PlatformLogger.Bridge? It?s nit and I think it reads better and clearly associate with PlatformLogger. > > Mandy > From bob.vandette at oracle.com Fri Oct 16 15:11:23 2015 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 16 Oct 2015 11:11:23 -0400 Subject: RFR: 8136556 - Add the ability to perform static builds of MacOSX x64 binaries In-Reply-To: <5620991B.8050606@oracle.com> References: <EFE473E9-96C6-49D5-BA84-81D6011B579C@oracle.com> <5620991B.8050606@oracle.com> Message-ID: <CE3C1898-11AD-47B5-93CA-0CABD9F33262@oracle.com> > On Oct 16, 2015, at 2:28 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote: > > On 15/10/2015 19:07, Bob Vandette wrote: >> Please review this JDK 9 enhancement which allows a completely static build of the JDK for MacOSX x64 platforms. >> >> https://bugs.openjdk.java.net/browse/JDK-8136556 <https://bugs.openjdk.java.net/browse/JDK-8136556> >> >> The change involves: >> >> 1. Producing ?.a? archives for each native libraries. >> 2. Ensuring that all symbols across the JDK native libraries are unique. >> 3. Changing the JNI_OnLoad and JNI_OnUnload (and the Agent equivalents) to have the each library name appended per >> the JNI specification. >> 4. Modifications to the launcher and launcher Makefiles to allow them to be linked with the java.base and jdk.jdwp.agent libraries >> and function. >> >> http://cr.openjdk.java.net/~bobv/8136556/webrev.00/ <http://cr.openjdk.java.net/~bobv/8136556/webrev.00/> >> http://cr.openjdk.java.net/~bobv/8136556/hotspot/webrev.00/ <http://cr.openjdk.java.net/~bobv/8136556/hotspot/webrev.00/> >> http://cr.openjdk.java.net/~bobv/8136556/jdk/webrev.00/ <http://cr.openjdk.java.net/~bobv/8136556/jdk/webrev.00/> >> >> Note: This change does not link every possible static library with the launchers. It is currently limited to >> the java.base and jdk.jdwp.agent libraries in order to allow for the TCK validation of the base module only. >> > I've skimmed through the patches and the DEF_* macros look okay. The only one that doesn't look right is jawt.h/jawt.c. As jawt.h is shipped by the JDK then I think the include of jni_util.h needs to move from jawt.h to jawt.c. Ok, I?ll take care of that. > > If I read the changes correctly then not loading the JavaRuntimeSupport.framework on Mac means the locale might not be right, is that correct? Brent might remember this issue as we've often pondered the implications of this disappearing in an Mac update. The implementation falls back to the getPosixLocale function when the Framework doesn?t exist. > > Will there be continuous or at least regular builds setup so that build breakages will be reported in a timely manner? It would be easy to change something that breaks the static library build. I will be setting up a period build on a Mac I?ve got running a Hudson server in our lab until we can get JPRT support for this configuration. Bob. > > -Alan From miroslav.kos at oracle.com Fri Oct 16 15:14:16 2015 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Fri, 16 Oct 2015 17:14:16 +0200 Subject: [9] RFR: 8139743 regular JAX-* sync-up from standalone repos Message-ID: <56211448.4040504@oracle.com> Hi, there is a bulk update of JAX-B/WS from upstream projects - webrev: http://cr.openjdk.java.net/~mkos/8139743/jaxws.01/ more details in issue desc: https://bugs.openjdk.java.net/browse/JDK-8139743 Could I ask for a review? It's quite big (2570 lines changed): * many javadoc fixes * some performance and other fixes for SAAJ * findbugs issues There are issue list in the JBS, many of listed bugs were fixed in JDK already (they are on the list because of backporting to standalone) Thanks Miran From lance.andersen at oracle.com Fri Oct 16 15:26:27 2015 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 16 Oct 2015 11:26:27 -0400 Subject: [9] RFR: 8139743 regular JAX-* sync-up from standalone repos In-Reply-To: <56211448.4040504@oracle.com> References: <56211448.4040504@oracle.com> Message-ID: <073C6E0E-87EB-408D-813E-E0E325B4DC40@oracle.com> Hi Miran Can you please provide a specdiff as that makes it easier for javadoc review Best Lance On Oct 16, 2015, at 11:14 AM, Miroslav Kos <miroslav.kos at oracle.com> wrote: > Hi, > there is a bulk update of JAX-B/WS from upstream projects - > webrev: http://cr.openjdk.java.net/~mkos/8139743/jaxws.01/ > more details in issue desc: https://bugs.openjdk.java.net/browse/JDK-8139743 > > Could I ask for a review? > > It's quite big (2570 lines changed): > * many javadoc fixes > * some performance and other fixes for SAAJ > * findbugs issues > > There are issue list in the JBS, many of listed bugs were fixed in JDK already (they are on the list because of backporting to standalone) > > Thanks > Miran > 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 miroslav.kos at oracle.com Fri Oct 16 15:49:44 2015 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Fri, 16 Oct 2015 17:49:44 +0200 Subject: [9] RFR: 8139743 regular JAX-* sync-up from standalone repos In-Reply-To: <073C6E0E-87EB-408D-813E-E0E325B4DC40@oracle.com> References: <56211448.4040504@oracle.com> <073C6E0E-87EB-408D-813E-E0E325B4DC40@oracle.com> Message-ID: <56211C98.3040905@oracle.com> Hi Lance, the javadoc fixes are just about formal issues (<tt>...</tt> for {@code .. }, broken links etc.) - there are no other changes. Thanks Miran On 16/10/15 17:26, Lance Andersen wrote: > Hi Miran > > Can you please provide a specdiff as that makes it easier for javadoc > review > > Best > Lance > On Oct 16, 2015, at 11:14 AM, Miroslav Kos <miroslav.kos at oracle.com > <mailto:miroslav.kos at oracle.com>> wrote: > >> Hi, >> there is a bulk update of JAX-B/WS from upstream projects - >> webrev: http://cr.openjdk.java.net/~mkos/8139743/jaxws.01/ >> <http://cr.openjdk.java.net/%7Emkos/8139743/jaxws.01/> >> more details in issue desc: >> https://bugs.openjdk.java.net/browse/JDK-8139743 >> >> Could I ask for a review? >> >> It's quite big (2570 lines changed): >> * many javadoc fixes >> * some performance and other fixes for SAAJ >> * findbugs issues >> >> There are issue list in the JBS, many of listed bugs were fixed in >> JDK already (they are on the list because of backporting to standalone) >> >> Thanks >> Miran >> > > <http://oracle.com/us/design/oracle-email-sig-198324.gif> > <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif> > <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com> > > > From xueming.shen at oracle.com Fri Oct 16 16:02:20 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 16 Oct 2015 09:02:20 -0700 Subject: RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes In-Reply-To: <5620E457.2020506@oracle.com> References: <56200D90.3000406@oracle.com> <d4d54041-b8b9-4d9c-8a97-71f48be1f5cf.maildroid@localhost> <323C4C63-649F-4F20-9E5A-82B9A8BFA8B1@oracle.com> <562023CD.9070406@oracle.com> <56205C76.3060201@oracle.com> <5620E457.2020506@oracle.com> Message-ID: <56211F8C.4070508@oracle.com> On 10/16/15 4:49 AM, Claes Redestad wrote: > On 2015-10-16 04:09, Xueming Shen wrote: >> On 10/15/15 3:08 PM, Claes Redestad wrote: >>> >>> On 2015-10-15 23:21, Chris Hegarty wrote: >>>>> On 15 Oct 2015, at 21:59, ecki at zusammenkunft.net wrote: >>>>> >>>>> Hello, >>>>> >>>>> This does change a bit the semantic of the length check. If the >>>>> stream would return more bytes than the zipentry says the new >>>>> version would ignore them, the old version was consuming then and >>>>> then fail the check. However I am not sure if this is relevant. >>>> Right, there are certainly some subtle differences resulting from >>>> the proposed change. When working on JDK-8138978 I thought >>>> about using readNBytes, but played it safe as IOUtils was growing >>>> the bye[] lazily too, so no real perf difference. In fact, I think >>>> I seen >>>> a test failure with using readNBytes here. I?ll have to check. >>> >>> Seeing no jtreg test failures in java/util/zip nor java/util/jar >>> (apart from 2 ignored tests), but I can see a reason for the current >>> implementation being conservative: Corrupt/malicious jar files might >>> lie about the entry length and report very large values, which could >>> bring a down with OOME. >>> >>> I believe we could be both safe and faster than baseline by adding a >>> reasonable limit for when to use readNBytes, e.g., 32k would deal >>> with the majority of .class files. >>> >> getBytes should be used to read the meta-inf files only, not the >> .class files. > > Correct, but this is still enough to cause statistically significant > increases on our footprint measures. > > With a reasonable trust limit this change should be safe while > avoiding most temporary byte[] allocations when reading meta-inf > files. I've verified the startup and footprint numbers and ran it > through all java/util/jar and /zip tests without error. > > New webrev: http://cr.openjdk.java.net/~redestad/8139706/webrev.02/ > Why do we no longer check the length of the returned byte[] from is.readAllBytes() against ze.getSize()? I think the original IOUtils.readFully() throws EOFE if we don't get enough bytes. -Sherman From lance.andersen at oracle.com Fri Oct 16 16:12:39 2015 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 16 Oct 2015 12:12:39 -0400 Subject: [9] RFR: 8139743 regular JAX-* sync-up from standalone repos In-Reply-To: <56211C98.3040905@oracle.com> References: <56211448.4040504@oracle.com> <073C6E0E-87EB-408D-813E-E0E325B4DC40@oracle.com> <56211C98.3040905@oracle.com> Message-ID: <7035006E-A338-4D23-B185-EC841E309988@oracle.com> Hi Miran On Oct 16, 2015, at 11:49 AM, Miroslav Kos <miroslav.kos at oracle.com> wrote: > Hi Lance, > the javadoc fixes are just about formal issues (<tt>...</tt> for {@code .. }, broken links etc.) - there are no other changes. Understand, but the specdiff makes it easier to see that there are no untended changes especially with the size. Best Lance > > Thanks > Miran > > > On 16/10/15 17:26, Lance Andersen wrote: >> Hi Miran >> >> Can you please provide a specdiff as that makes it easier for javadoc review >> >> Best >> Lance >> On Oct 16, 2015, at 11:14 AM, Miroslav Kos <miroslav.kos at oracle.com> wrote: >> >>> Hi, >>> there is a bulk update of JAX-B/WS from upstream projects - >>> webrev: http://cr.openjdk.java.net/~mkos/8139743/jaxws.01/ >>> more details in issue desc: https://bugs.openjdk.java.net/browse/JDK-8139743 >>> >>> Could I ask for a review? >>> >>> It's quite big (2570 lines changed): >>> * many javadoc fixes >>> * some performance and other fixes for SAAJ >>> * findbugs issues >>> >>> There are issue list in the JBS, many of listed bugs were fixed in JDK already (they are on the list because of backporting to standalone) >>> >>> Thanks >>> Miran >>> >> >> <Mail Attachment.gif> >> >> 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 claes.redestad at oracle.com Fri Oct 16 16:24:22 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 16 Oct 2015 18:24:22 +0200 Subject: RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes In-Reply-To: <56211F8C.4070508@oracle.com> References: <56200D90.3000406@oracle.com> <d4d54041-b8b9-4d9c-8a97-71f48be1f5cf.maildroid@localhost> <323C4C63-649F-4F20-9E5A-82B9A8BFA8B1@oracle.com> <562023CD.9070406@oracle.com> <56205C76.3060201@oracle.com> <5620E457.2020506@oracle.com> <56211F8C.4070508@oracle.com> Message-ID: <562124B6.4080608@oracle.com> On 2015-10-16 18:02, Xueming Shen wrote: > Why do we no longer check the length of the returned byte[] from > is.readAllBytes() against ze.getSize()? > I think the original IOUtils.readFully() throws EOFE if we don't get > enough bytes. Good catch, this should do it: http://cr.openjdk.java.net/~redestad/8139706/webrev.03/ /Claes > > -Sherman From xueming.shen at oracle.com Fri Oct 16 16:48:06 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 16 Oct 2015 09:48:06 -0700 Subject: RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes In-Reply-To: <562124B6.4080608@oracle.com> References: <56200D90.3000406@oracle.com> <d4d54041-b8b9-4d9c-8a97-71f48be1f5cf.maildroid@localhost> <323C4C63-649F-4F20-9E5A-82B9A8BFA8B1@oracle.com> <562023CD.9070406@oracle.com> <56205C76.3060201@oracle.com> <5620E457.2020506@oracle.com> <56211F8C.4070508@oracle.com> <562124B6.4080608@oracle.com> Message-ID: <56212A46.70103@oracle.com> On 10/16/15 9:24 AM, Claes Redestad wrote: > > > On 2015-10-16 18:02, Xueming Shen wrote: >> Why do we no longer check the length of the returned byte[] from >> is.readAllBytes() against ze.getSize()? >> I think the original IOUtils.readFully() throws EOFE if we don't get >> enough bytes. > > Good catch, this should do it: > > http://cr.openjdk.java.net/~redestad/8139706/webrev.03/ > looks fine. though it might be better to simply check len != b.length, as it's still possible that reallAllBytes returns a byte[] with length > len, if the entry is compressed, and the "length" in entry does not really match the length of the bytes from the inflater. If you go with len != b.length, you can pull two checks out and consolidate them at the end before return. -Sherman > /Claes > >> >> -Sherman > From naoto.sato at oracle.com Fri Oct 16 17:01:52 2015 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 16 Oct 2015 10:01:52 -0700 Subject: RFR: 8136556 - Add the ability to perform static builds of MacOSX x64 binaries In-Reply-To: <CE3C1898-11AD-47B5-93CA-0CABD9F33262@oracle.com> References: <EFE473E9-96C6-49D5-BA84-81D6011B579C@oracle.com> <5620991B.8050606@oracle.com> <CE3C1898-11AD-47B5-93CA-0CABD9F33262@oracle.com> Message-ID: <56212D80.9090404@oracle.com> Hi Bob, Alan, On 10/16/15 8:11 AM, Bob Vandette wrote: >> I've skimmed through the patches and the DEF_* macros look okay. The only one that doesn't look right is jawt.h/jawt.c. As jawt.h is shipped by the JDK then I think the include of jni_util.h needs to move from jawt.h to jawt.c. > Ok, I?ll take care of that. >> >> If I read the changes correctly then not loading the JavaRuntimeSupport.framework on Mac means the locale might not be right, is that correct? Brent might remember this issue as we've often pondered the implications of this disappearing in an Mac update. > The implementation falls back to the getPosixLocale function when the Framework doesn?t exist. In that case, the locale settings in the MacOSX's Settings will not be reflected in Java's default locale. Naoto From mark.reinhold at oracle.com Fri Oct 16 17:35:33 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 16 Oct 2015 10:35:33 -0700 (PDT) Subject: JEP 276: Dynamic Linking of Language-Defined Object Models Message-ID: <20151016173533.8325A7D532@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/276 - Mark From steve.drach at oracle.com Fri Oct 16 18:18:23 2015 From: steve.drach at oracle.com (Steve Drach) Date: Fri, 16 Oct 2015 11:18:23 -0700 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <56207360.6040502@oracle.com> References: <F7C2BACE-2E86-4058-8136-F565799494F8@oracle.com> <561ED8BF.40901@oracle.com> <CC71DAAE-940B-47EB-A2F2-FFB89F2EBAD3@oracle.com> <561F16C1.6090702@oracle.com> <A8D7EE96-1238-401D-813D-E977CCD9E73F@oracle.com> <56207360.6040502@oracle.com> Message-ID: <580E1C71-B62D-40CA-AEEA-BF31D96E8FA9@oracle.com> > So why do you want to put this field into the super class JarEntry, not the JarFileEntry, don't see any > benefit of doing that. I changed it. I put the versionedEntry in JarFileEntry instead of JarEntry. Not too difficult although I had to add a package private method to support JarVerifier. It seems to work as all 27 jar tests pass (some are not specific to multi-release jars). From mandy.chung at oracle.com Fri Oct 16 18:47:37 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 16 Oct 2015 11:47:37 -0700 Subject: RFR: JDK-8046565: Platform Logger API and Service In-Reply-To: <CACzrW9AzE0QkL+TjdOCoMN=4Epadkh27ybgC9nWv=LwHDrvfWg@mail.gmail.com> References: <561660DA.7070900@oracle.com> <8D8890A3-2337-4178-BA5C-CC32DE12F27D@oracle.com> <561E3A9A.9050807@oracle.com> <CACzrW9Dp3wUHk=TY=nfApczW5GfgGpWj7R9bcGRPXr9VGqH7fA@mail.gmail.com> <561FD4C6.1020803@oracle.com> <CACzrW9AzE0QkL+TjdOCoMN=4Epadkh27ybgC9nWv=LwHDrvfWg@mail.gmail.com> Message-ID: <6B90F5D0-C8DC-4010-B8D0-27318133F63E@oracle.com> > On Oct 16, 2015, at 4:16 AM, Stephen Colebourne <scolebourne at joda.org> wrote: > > On 15 October 2015 at 17:31, Daniel Fuchs <daniel.fuchs at oracle.com> wrote: >>> I have a major concern that the class names 'Logger' and 'Level' >>> duplicate those of java.util.logging. While they are inner classes as >>> opposed to top level classes, both IntelliJ and Eclipse will find the >>> inner class and top level class when typing "Logger". This will no >>> doubt cause many users to import the wrong one. I propose that these >>> classes are renamed to avoid this problem. The simplest would be to >>> change them from inner classes to top level classes "System.Logger" -> >>> "SystemLogger". Alternatively, they could stay as inner classes and be >>> prefixed "System.Logger" -> "System.SysLogger" or "System.Logger" -> >>> "System.BasicLogger". >> >> >> After having worked with it for some time I find that using >> inner interfaces/classes for Logger and Level is not that >> bad. Certainly better than if it was a top-level class of >> the same name. It is fortunately rare that you need to use >> both (the System. and the j.u.l one) in the same class. >> >> It's hard to find a compelling new name though :-) > > Since I assume the purpose of these new Logger/Level interfaces is > simplistic and primarily for the JDK's own use, a name that emphasises > that would seem reasonable, hence BasicLogger/BasicLoggerLevel or > similar. I would typically type something like this before fixing the import: Logger logger = System.Logger(?foo?); In this case, IDE should suggest the returned type (System.Logger in this case) as the first one in the import suggested list. It might not be too bad. FWIW Logger is a simple name that people like :) There are 4 classes named Logger in the JDK and TestNG has another one (my project happened to have TestNG library included). I also like Logger than SystemLogger or BasicLogger. Mandy From bob.vandette at oracle.com Fri Oct 16 19:06:15 2015 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 16 Oct 2015 15:06:15 -0400 Subject: RFR: 8136556 - Add the ability to perform static builds of MacOSX x64 binaries In-Reply-To: <56212D80.9090404@oracle.com> References: <EFE473E9-96C6-49D5-BA84-81D6011B579C@oracle.com> <5620991B.8050606@oracle.com> <CE3C1898-11AD-47B5-93CA-0CABD9F33262@oracle.com> <56212D80.9090404@oracle.com> Message-ID: <48D66535-FBBD-469B-A4FF-6DAEF84B45A0@oracle.com> > On Oct 16, 2015, at 1:01 PM, Naoto Sato <naoto.sato at oracle.com> wrote: > > Hi Bob, Alan, > > On 10/16/15 8:11 AM, Bob Vandette wrote: >>> I've skimmed through the patches and the DEF_* macros look okay. The only one that doesn't look right is jawt.h/jawt.c. As jawt.h is shipped by the JDK then I think the include of jni_util.h needs to move from jawt.h to jawt.c. >> Ok, I?ll take care of that. >>> >>> If I read the changes correctly then not loading the JavaRuntimeSupport.framework on Mac means the locale might not be right, is that correct? Brent might remember this issue as we've often pondered the implications of this disappearing in an Mac update. >> The implementation falls back to the getPosixLocale function when the Framework doesn?t exist. > > In that case, the locale settings in the MacOSX's Settings will not be reflected in Java's default locale. Unless we have the sources to the JavaRuntimeSupport, I see no way around this limitation. Any attempt to load the shared library, causes the JavaRuntimeSupport framework to try to initialize itself. The initialization fails since it can?t detect the presence of the Java runtime that?s trying to load it and a dialog box asking to install Java appears. I think we?re going to have to live with this limitation. Bob. > > Naoto From claes.redestad at oracle.com Fri Oct 16 22:20:30 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 17 Oct 2015 00:20:30 +0200 Subject: RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes In-Reply-To: <56212A46.70103@oracle.com> References: <56200D90.3000406@oracle.com> <d4d54041-b8b9-4d9c-8a97-71f48be1f5cf.maildroid@localhost> <323C4C63-649F-4F20-9E5A-82B9A8BFA8B1@oracle.com> <562023CD.9070406@oracle.com> <56205C76.3060201@oracle.com> <5620E457.2020506@oracle.com> <56211F8C.4070508@oracle.com> <562124B6.4080608@oracle.com> <56212A46.70103@oracle.com> Message-ID: <5621782E.2020406@oracle.com> On 2015-10-16 18:48, Xueming Shen wrote: > looks fine. though it might be better to simply check len != b.length, > as it's still possible that reallAllBytes > returns a byte[] with length > len, if the entry is compressed, and > the "length" in entry does not really > match the length of the bytes from the inflater. > > If you go with len != b.length, you can pull two checks out and > consolidate them at the end before return. We'll also need to check that len != -1 in that extracted check, but I guess it's still cleaner: http://cr.openjdk.java.net/~redestad/8139706/webrev.04 /Claes From forax at univ-mlv.fr Fri Oct 16 23:17:52 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 17 Oct 2015 01:17:52 +0200 (CEST) Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <2C0C7E71-4B00-4316-8256-497DDC77592C@oracle.com> References: <5616FEB5.5090104@oracle.com> <CACzrW9A3MZja2wxsHZ7E0vSupkMJXMTQDqMQRjV548ArAF57Hw@mail.gmail.com> <5618498D.2040807@oracle.com> <CAGKkBksRc1u2=ELyYxvKy69ux61uM8UnaUrbzmvXMgkwGLi8jQ@mail.gmail.com> <2C0C7E71-4B00-4316-8256-497DDC77592C@oracle.com> Message-ID: <124515629.2855494.1445037472365.JavaMail.zimbra@u-pem.fr> The other reason I see to avoid methods of on impelmentations is that as i've already said, Java allows to inherits static methods defined on class so adding a method of() on ArrayList will allow people to use of on a subclass of HashMap/ArrayList but did get the expected object, by example, LinkedHashMap.of() will return a HashMap. so +1 to have methods of() only on interfaces. R?mi ----- Mail original ----- > De: "John Rose" <john.r.rose at oracle.com> > ?: "Kevin Bourrillion" <kevinb at google.com> > Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net> > Envoy?: Mercredi 14 Octobre 2015 22:46:40 > Objet: Re: RFC: draft API for JEP 269 Convenience Collection Factories > > On Oct 14, 2015, at 10:56 AM, Kevin Bourrillion <kevinb at google.com> wrote: > > Anyway, since we created these methods, they became an attractive nuisance, > > and thousands of users reach for them who would have been better off in > > every way using an immutable collection. Our fondest desire is to one day > > be able to delete them. So, obviously, my strong recommendation is not to > > add these to ArrayList, etc. > > I agree with Kevin's warning here. Please, (1) make the immutable version > easy to get (List.of not ImmutableList.of), and require users to > thoughtfully opt into mutability (new ArrayList not ArrayList.of). > > ? John From xueming.shen at oracle.com Fri Oct 16 23:37:43 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 16 Oct 2015 16:37:43 -0700 Subject: RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes In-Reply-To: <5621782E.2020406@oracle.com> References: <56200D90.3000406@oracle.com> <d4d54041-b8b9-4d9c-8a97-71f48be1f5cf.maildroid@localhost> <323C4C63-649F-4F20-9E5A-82B9A8BFA8B1@oracle.com> <562023CD.9070406@oracle.com> <56205C76.3060201@oracle.com> <5620E457.2020506@oracle.com> <56211F8C.4070508@oracle.com> <562124B6.4080608@oracle.com> <56212A46.70103@oracle.com> <5621782E.2020406@oracle.com> Message-ID: <56218A47.1020806@oracle.com> On 10/16/2015 3:20 PM, Claes Redestad wrote: > > On 2015-10-16 18:48, Xueming Shen wrote: >> looks fine. though it might be better to simply check len != >> b.length, as it's still possible that reallAllBytes >> returns a byte[] with length > len, if the entry is compressed, and >> the "length" in entry does not really >> match the length of the bytes from the inflater. >> >> If you go with len != b.length, you can pull two checks out and >> consolidate them at the end before return. > > We'll also need to check that len != -1 in that extracted check, but I > guess it's still cleaner: > > http://cr.openjdk.java.net/~redestad/8139706/webrev.04 > > /Claes it looks good. btw, I don't remember where did this len != -1 come from. The is an meta-inf entry from the ZipFile, which should come from the cen table, which means it should always have the correct size set in. Not like the entry from zis, which is from loc table and in case of a compressed entry, the size/csize might be -1 (as they are unknown when you write out the loc entry...). I might be wrong without digging into the code and history a little more deep, and it really does not matter too much. So the change is good for me. -sherman From timo.kinnunen at gmail.com Sat Oct 17 01:27:03 2015 From: timo.kinnunen at gmail.com (Timo Kinnunen) Date: Sat, 17 Oct 2015 01:27:03 +0000 (UTC) Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <124515629.2855494.1445037472365.JavaMail.zimbra@u-pem.fr> References: <5616FEB5.5090104@oracle.com> <CACzrW9A3MZja2wxsHZ7E0vSupkMJXMTQDqMQRjV548ArAF57Hw@mail.gmail.com> <5618498D.2040807@oracle.com> <CAGKkBksRc1u2=ELyYxvKy69ux61uM8UnaUrbzmvXMgkwGLi8jQ@mail.gmail.com> <2C0C7E71-4B00-4316-8256-497DDC77592C@oracle.com> <124515629.2855494.1445037472365.JavaMail.zimbra@u-pem.fr> Message-ID: <81B4C4AAF750542E.C2D1AED6-BCA8-41E8-8456-6D7C87DC0311@mail.outlook.com> Hi, Calling a static method of a superclass using the name of the subclass is already a warming in any decently configured IDE. Fixing such warnings is so trivial that having displayed the warning an IDE could do it automatically.? Such a code sample is not a convincing argument against static factory methods in concrete classes, it is simply an observation that such methods do not provide good support for bad code. If there's any takeaway from such code it is this: improving an API in one place raises expectations for all such APIs. This is great, it means the improvements are real and should be applied in as many places as they can be, and no fewer. Sent from Outlook On Fri, Oct 16, 2015 at 4:18 PM -0700, "Remi Forax" <forax at univ-mlv.fr> wrote: The other reason I see to avoid methods of on impelmentations is that as i've already said, Java allows to inherits static methods defined on class so adding a method of() on ArrayList will allow people to use of on a subclass of HashMap/ArrayList but did get the expected object, by example, LinkedHashMap.of() will return a HashMap. so +1 to have methods of() only on interfaces. R?mi ----- Mail original ----- > De: "John Rose" > ?: "Kevin Bourrillion" > Cc: "core-libs-dev" > Envoy?: Mercredi 14 Octobre 2015 22:46:40 > Objet: Re: RFC: draft API for JEP 269 Convenience Collection Factories > > On Oct 14, 2015, at 10:56 AM, Kevin Bourrillion wrote: > > Anyway, since we created these methods, they became an attractive nuisance, > > and thousands of users reach for them who would have been better off in > > every way using an immutable collection. Our fondest desire is to one day > > be able to delete them. So, obviously, my strong recommendation is not to > > add these to ArrayList, etc. > > I agree with Kevin's warning here. Please, (1) make the immutable version > easy to get (List.of not ImmutableList.of), and require users to > thoughtfully opt into mutability (new ArrayList not ArrayList.of). > > ? John From scolebourne at joda.org Sat Oct 17 08:43:38 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Sat, 17 Oct 2015 09:43:38 +0100 Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <CAGKkBksRc1u2=ELyYxvKy69ux61uM8UnaUrbzmvXMgkwGLi8jQ@mail.gmail.com> References: <5616FEB5.5090104@oracle.com> <CACzrW9A3MZja2wxsHZ7E0vSupkMJXMTQDqMQRjV548ArAF57Hw@mail.gmail.com> <5618498D.2040807@oracle.com> <CAGKkBksRc1u2=ELyYxvKy69ux61uM8UnaUrbzmvXMgkwGLi8jQ@mail.gmail.com> Message-ID: <CACzrW9CEapk9dwgBqSHPRBnQogNr0abb_F-N5-ha4TOs0idq9Q@mail.gmail.com> On 14 October 2015 at 18:56, Kevin Bourrillion <kevinb at google.com> wrote: > Note that we have empirically learned through our Lists/Sets/Maps factory > classes that varargs factory methods for mutable collections are almost > entirely useless. Having taken a few days to think it over, I reluctantly think that Kevin is right. Particularly as static methods on classes are inherited, as Remi says. If someone needs a mutable one, they can simply write: new ArrayList<>(List.of(z, b, c)) Adding immutable implementations just on the interfaces seems like a reasonable balancing point, and provides more API room to add the IntFunction version I mentioned ;-) As a side note, a really nice language change would be to deprecate the ability to refer to static methods from subclasses or instance variables in the JLS. Stephen From martijnverburg at gmail.com Sat Oct 17 11:30:01 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Sat, 17 Oct 2015 12:30:01 +0100 Subject: JEP 276: Dynamic Linking of Language-Defined Object Models In-Reply-To: <20151016173533.8325A7D532@eggemoggin.niobe.net> References: <20151016173533.8325A7D532@eggemoggin.niobe.net> Message-ID: <CAP7YuATPogD2p+15VHCLgd2yQ_vJ2Ax_BpCzimKEnHTYYbpJrw@mail.gmail.com> This looks very, very promising. Would it help to get the language maintainers of the most popular scripting/dynamic JVM languages involved ASAP? Happy to contact Groovy, Clojure, Scala, JRuby folks (although I suspect many of them are on this list). Cheers, Martijn On 16 October 2015 at 18:35, <mark.reinhold at oracle.com> wrote: > New JEP Candidate: http://openjdk.java.net/jeps/276 > > - Mark > From claes.redestad at oracle.com Sat Oct 17 13:11:36 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 17 Oct 2015 15:11:36 +0200 Subject: RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes In-Reply-To: <56218A47.1020806@oracle.com> References: <56200D90.3000406@oracle.com> <d4d54041-b8b9-4d9c-8a97-71f48be1f5cf.maildroid@localhost> <323C4C63-649F-4F20-9E5A-82B9A8BFA8B1@oracle.com> <562023CD.9070406@oracle.com> <56205C76.3060201@oracle.com> <5620E457.2020506@oracle.com> <56211F8C.4070508@oracle.com> <562124B6.4080608@oracle.com> <56212A46.70103@oracle.com> <5621782E.2020406@oracle.com> <56218A47.1020806@oracle.com> Message-ID: <56224908.5080309@oracle.com> On 2015-10-17 01:37, Xueming Shen wrote: > > On 10/16/2015 3:20 PM, Claes Redestad wrote: >> >> On 2015-10-16 18:48, Xueming Shen wrote: >>> looks fine. though it might be better to simply check len != >>> b.length, as it's still possible that reallAllBytes >>> returns a byte[] with length > len, if the entry is compressed, and >>> the "length" in entry does not really >>> match the length of the bytes from the inflater. >>> >>> If you go with len != b.length, you can pull two checks out and >>> consolidate them at the end before return. >> >> We'll also need to check that len != -1 in that extracted check, but >> I guess it's still cleaner: >> >> http://cr.openjdk.java.net/~redestad/8139706/webrev.04 >> >> /Claes > > it looks good. > > btw, I don't remember where did this len != -1 come from. The is an > meta-inf entry from the > ZipFile, which should come from the cen table, which means it should > always have the correct > size set in. Not like the entry from zis, which is from loc table and > in case of a compressed > entry, the size/csize might be -1 (as they are unknown when you write > out the loc entry...). > I might be wrong without digging into the code and history a little > more deep, and it really > does not matter too much. So the change is good for me. > > -sherman Maybe you're right, but you're also right that getting rid of an extra check or two won't matter much here. I'll go ahead and push the latest patch later, unless someone objects. Thanks everyone for reviewing and catching issues! /Claes From aph at redhat.com Sat Oct 17 13:27:58 2015 From: aph at redhat.com (Andrew Haley) Date: Sat, 17 Oct 2015 14:27:58 +0100 Subject: JEP 276: Dynamic Linking of Language-Defined Object Models In-Reply-To: <CAP7YuATPogD2p+15VHCLgd2yQ_vJ2Ax_BpCzimKEnHTYYbpJrw@mail.gmail.com> References: <20151016173533.8325A7D532@eggemoggin.niobe.net> <CAP7YuATPogD2p+15VHCLgd2yQ_vJ2Ax_BpCzimKEnHTYYbpJrw@mail.gmail.com> Message-ID: <56224CDE.7020309@redhat.com> On 10/17/2015 12:30 PM, Martijn Verburg wrote: > This looks very, very promising. Yea, fantastic. How did I manage to miss that one? According to the JEP the functionality is in Java 8 already and used by Nashorn, so it should be easy for language implementers to kick the tyres. Andrew. From stuart.marks at oracle.com Sat Oct 17 16:46:24 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Sat, 17 Oct 2015 09:46:24 -0700 Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <87025428.3530190.1444485358747.JavaMail.zimbra@u-pem.fr> References: <5616FEB5.5090104@oracle.com> <CACzrW9A3MZja2wxsHZ7E0vSupkMJXMTQDqMQRjV548ArAF57Hw@mail.gmail.com> <87025428.3530190.1444485358747.JavaMail.zimbra@u-pem.fr> Message-ID: <56227B60.90709@oracle.com> On 10/10/15 6:55 AM, Remi Forax wrote: > There is an issue with LinkedHashMap (resp LinkedHashSet), > it inherits from HashMap /facepalm/, and static methods are accessible through class inheritance /facepalm/. > So if LinkedHashMap doesn't declare some methods of(), > LinkedHashMap.of("foo") > will return a HashMap :( Hi R?mi, Thanks for pointing this out. I had forgotten about "inheritance" of static methods. /Facepalm/ indeed. The original proposal (July 2014) avoided this issue by adding static methods only on interfaces, which are *not* inherited. When we added statics on concrete classes this problem returned. (I view calling an "inherited" class static method to be poor coding style, but neither javac nor NetBeans warns about it.) Well, perhaps we won't be adding static factories to the concrete collections after all, so maybe we can dodge this issue. See messages downthread. s'marks From aph at redhat.com Sat Oct 17 17:10:15 2015 From: aph at redhat.com (Andrew Haley) Date: Sat, 17 Oct 2015 18:10:15 +0100 Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <56227B60.90709@oracle.com> References: <5616FEB5.5090104@oracle.com> <CACzrW9A3MZja2wxsHZ7E0vSupkMJXMTQDqMQRjV548ArAF57Hw@mail.gmail.com> <87025428.3530190.1444485358747.JavaMail.zimbra@u-pem.fr> <56227B60.90709@oracle.com> Message-ID: <562280F7.9010508@redhat.com> On 10/17/2015 05:46 PM, Stuart Marks wrote: > (I view calling an "inherited" class static method to be poor coding style, but > neither javac nor NetBeans warns about it.) That surely can be fixed. Should we start a feature request? Andrew. From aph at redhat.com Sat Oct 17 17:10:15 2015 From: aph at redhat.com (Andrew Haley) Date: Sat, 17 Oct 2015 18:10:15 +0100 Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <56227B60.90709@oracle.com> References: <5616FEB5.5090104@oracle.com> <CACzrW9A3MZja2wxsHZ7E0vSupkMJXMTQDqMQRjV548ArAF57Hw@mail.gmail.com> <87025428.3530190.1444485358747.JavaMail.zimbra@u-pem.fr> <56227B60.90709@oracle.com> Message-ID: <562280F7.5050005@redhat.com> On 10/17/2015 05:46 PM, Stuart Marks wrote: > (I view calling an "inherited" class static method to be poor coding style, but > neither javac nor NetBeans warns about it.) That surely can be fixed. Should we start a feature request? Andrew. From stuart.marks at oracle.com Sat Oct 17 17:23:53 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Sat, 17 Oct 2015 10:23:53 -0700 Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <561E50FC.3070004@oracle.com> References: <5616FEB5.5090104@oracle.com> <561E50FC.3070004@oracle.com> Message-ID: <56228429.9040406@oracle.com> On 10/14/15 5:56 AM, Ivan Gerasimov wrote: > Map<Integer,Character> m1 = MyCollections.<Integer,Character> > ofKeys( 1, 2, 3, 4, 5) > .vals( 'a', 'b', 'c', 'd', 'e'); Yes, we considered a bunch of different alternatives. It looks like you're wrestling a bit with type inference :-), given that you had to invoke this with a type witness. The issue here is that the target type doesn't back-propagate through the chained method call .vals() to the call of .ofKeys(). Incidentally, a similar problem occurs in the "obvious" builder approach of doing something like this: Map<Integer,Character> map = Map.builder() .add(1, 'a') .add(2, 'b') .... .build(); It's possible to pursue workarounds for this problem, but then you're heading down the rabbit hole.... A quasi-syntactic issue is that it's preferable to have each key and value next to each other, so that each pair can be on its own line. This makes it easier to maintain. If all the keys are listed together first, followed by all the values, the pairing can only be made to work if they're all short and if there are few enough pairs (as in your example). Things start to break down if the keys/values themselves are long, or if there are a lot of them, pushing the keys and values lists onto multiple lines. Consider my example from the head of the thread: Map<String,TypeUse> m = Map.ofEntries( entry("CDATA", CBuiltinLeafInfo.NORMALIZED_STRING), entry("ENTITY", CBuiltinLeafInfo.TOKEN), entry("ENTITIES", CBuiltinLeafInfo.STRING.makeCollection()), entry("ENUMERATION", CBuiltinLeafInfo.STRING.makeCollection()), entry("NMTOKEN", CBuiltinLeafInfo.TOKEN), entry("NMTOKENS", CBuiltinLeafInfo.STRING.makeCollection()), entry("ID", CBuiltinLeafInfo.ID), entry("IDREF", CBuiltinLeafInfo.IDREF), entry("IDREFS", TypeUseFactory.makeCollection(CBuiltinLeafInfo.IDREF)); entry("ENUMERATION", CBuiltinLeafInfo.TOKEN)); Maintaining the association between keys and values is challenge. Here's my attempt, where keys and values are associated by indentation level: Map<String,TypeUse> m = Map.<String,TypeUse> ofKeys("CDATA", "ENTITY", "ENTITIES", "ENUMERATION", "NMTOKEN", "NMTOKENS", "ID", "IDREF", "IDREFS", "ENUMERATION") .vals( CBuiltinLeafInfo.NORMALIZED_STRING, CBuiltinLeafInfo.TOKEN, CBuiltinLeafInfo.STRING.makeCollection(), CBuiltinLeafInfo.STRING.makeCollection(), CBuiltinLeafInfo.TOKEN, CBuiltinLeafInfo.STRING.makeCollection(), CBuiltinLeafInfo.ID, CBuiltinLeafInfo.IDREF), TypeUseFactory.makeCollection(CBuiltinLeafInfo.IDREF), CBuiltinLeafInfo.TOKEN); With more pairs, the distance between each key and its corresponding value also increases. You could try to reduce the vertical distance by filling the lines (more keys/values per line) but that makes the association challenges even harder. Finally, consider the pain of inserting or removing a key/value pair from the middle. s'marks From stuart.marks at oracle.com Sat Oct 17 17:56:50 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Sat, 17 Oct 2015 10:56:50 -0700 Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <CAGKkBksRc1u2=ELyYxvKy69ux61uM8UnaUrbzmvXMgkwGLi8jQ@mail.gmail.com> References: <5616FEB5.5090104@oracle.com> <CACzrW9A3MZja2wxsHZ7E0vSupkMJXMTQDqMQRjV548ArAF57Hw@mail.gmail.com> <5618498D.2040807@oracle.com> <CAGKkBksRc1u2=ELyYxvKy69ux61uM8UnaUrbzmvXMgkwGLi8jQ@mail.gmail.com> Message-ID: <56228BE2.6020107@oracle.com> On 10/14/15 10:56 AM, Kevin Bourrillion wrote: > (Sorry that Guava questions were asked and I didn't notice this thread sooner.) Hi Kevin, thanks for this feedback. It's still timely, as it's helping to improve the proposal. > Note that we have empirically learned through our Lists/Sets/Maps factory > classes that varargs factory methods for /mutable/ collections are almost > entirely useless. For one thing, it's simply not common to have a hardcoded > set of initial values yet still actually need to modify the contents later. > When that does come up, the existing workarounds just aren't bad at all: [...] > > Anyway, since we created these methods, they became an attractive nuisance, > and thousands of users reach for them who would have been better off in every > way using an immutable collection. Our fondest desire is to one day be able to > delete them. So, obviously, my strong recommendation is not to add these to > ArrayList, etc. This is very, very interesting. I have to admit that our rationale in proposing to add the factories to the concrete implementations is fairly weak. It was something along the lines of, "Well these will /obviously/ be useful, so let's go ahead and add them." (Perhaps this is similar to the rationale for adding them to Guava in the first place.) Based on your experience, and feedback from other replies to this email, I'm strongly leaning toward removing the factories from the concrete collections. It could be that not having these would be a mistake. But if it is, it's easier to add them later, than it is to add them now and to try to remove them later if we determine that they were a mistake. (As Dr Deprecator is all too aware.) The class static method inheritance issue is an annoyance, but I don't think it's central to the problem. If we were to add static factories to classes, I'm confident we'd come up with some way to deal with the issue. What I think /is/ central to the issue is what you described as an "attractive nuisance." If the presence of these methods is likely to cause them to be misused more often then not, then that's a good reason not to have the API there at all. More discussion below... > On Fri, Oct 9, 2015 at 4:11 PM, Stuart Marks <stuart.marks at oracle.com > <mailto:stuart.marks at oracle.com>> wrote: > > Now, Guava handles this use case by providing a family of copying > factories that can accept an array, a Collection, an Iterator, or an > Iterable. These are all useful, but for JEP 269, we wanted to focus on the > "collection literal like" APIs and not expand the proposal to include a > bunch of additional factory methods. Since we need to have a varargs > method anyway, it seemed reasonable to arrange it so that it could easily > accept an array as well. > > > A decision to support only varargs and arrays is reasonable. However, I don't > see the advantage in using the same method name for both. In Guava, it's clear > what the difference between ImmutableList.of(aStringArray) and > ImmutableList.copyOf(aStringArray) is. There's a small, but not fundamental, advantage to having the same name. Suppose we have fixed-arg variants up to 5 and a one-arg varargs method: List.of(T, T, T, T, T) List.of(T...) Then it becomes possible to write, List<String> list = List.of("a", "b", "c", "d", "e"); and later modify it to List<String> list = List.of("a", "b", "c", "d", "e", "f"); without having to worry about renaming the method call. Of course, we could solve this by changing the varargs variant so that the varargs parameter occurs after all the fixed parameters, like Guava: List.of(T, T, T, T, T, T, T...) But then we'd need to add another method to handle the array case: List.copyOf(T[]) It's not a huge deal to add another method, I suppose. The only disadvantage I'm aware with List.of(T...) is that it makes it harder to have a list of an array. Are there other disadvantages? > 3. Duplicate handling. > > My current thinking is for the Set and Map factories to throw > IllegalArgumentException if a duplicate element or key is detected. > > > +1 Great, thanks. > To the other question: the reason we chose 11 as the cutoff is that we > determined that there would be no logical basis for exactly where to do it, so > we looked for an illogical basis. Sometimes you'll be at 10, all the way up, > you're at 10 and where can you go from there? Where? Nowhere. So this way, if > we need that extra push over the cliff, we can go up to 11. It seems there are only two interesting numbers in software development, 11 and 42. In this case 42 is right out, so that leaves 11. s'marks From ivan.gerasimov at oracle.com Sat Oct 17 23:09:49 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sun, 18 Oct 2015 02:09:49 +0300 Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <56228429.9040406@oracle.com> References: <5616FEB5.5090104@oracle.com> <561E50FC.3070004@oracle.com> <56228429.9040406@oracle.com> Message-ID: <5622D53D.4070109@oracle.com> Thank you Stuart for yours comments! On 17.10.2015 20:23, Stuart Marks wrote: > On 10/14/15 5:56 AM, Ivan Gerasimov wrote: >> Map<Integer,Character> m1 = MyCollections.<Integer,Character> >> ofKeys( 1, 2, 3, 4, 5) >> .vals( 'a', 'b', 'c', 'd', 'e'); > > Yes, we considered a bunch of different alternatives. > > It looks like you're wrestling a bit with type inference :-), given > that you had to invoke this with a type witness. Yes, I should have been more careful with the types :-) The KeyHolder class, returned by ofKeys should not depend on the V type. Then the inference would work as expected. I totally agree with your point on that it is more preferable to the key and corresponding value next to each other. But what if both are provided, so the user can choose what's more appropriate? Would you take a look at another sample code? First, it's more accurate with type inference. Second, it allows filling a map either as specifying separate entries, or specifying an array of keys and another array of values. -------------------------------------------- import java.util.*; import java.util.function.*; public class MB { public static void main(String[] a) { Map<Integer,Character> m1 = MapBuilder .k(1).v('a') .k(2).v('b') .k(3).v('c') .k(4).v('d') .k(5).v('e') .k( 6, 7, 8) .v('f', 'g', 'h') .build(); m1.forEach((k, v) -> System.out.println("m1[" + k + "] = " + v)); Map<Integer,Character> m2 = MapBuilder .add(101, 'A') .add(102, 'B') .add(103, 'C') .add(104, 'D') .build(); m2.forEach((k, v) -> System.out.println("m2[" + k + "] = " + v)); } } class MapBuilder { public static <K> KeysHolder<K> k(K... keys) { return new KeysHolder<>(keys); } public static <K,V> KeysValsHolder<K,V> add(K key, V val) { return k(key).v(val); } public static class KeysHolder <K> { K[] keys; KeysHolder(K... keys) { this.keys = keys; } public <V> KeysValsHolder<K,V> v(V... vals) { return new KeysValsHolder<>(keys, vals); } } public static class KeysValsHolder <K,V> { K[] keys; V[] vals; KeysValsHolder(K[] keys, V[] vals) { this.keys = keys; this.vals = vals; } public KeysValsHolder<K,V> k(K... keys) { int len0 = this.keys.length; int len1 = keys.length; this.keys = Arrays.copyOf(this.keys, len0 + len1); System.arraycopy(keys, 0, this.keys, len0, len1); return this; } public KeysValsHolder<K,V> v(V... vals) { int len0 = this.vals.length; int len1 = vals.length; this.vals = Arrays.copyOf(this.vals, len0 + len1); System.arraycopy(vals, 0, this.vals, len0, len1); return this; } public KeysValsHolder<K,V> add(K key, V val) { return k(key).v(val); } Map<K,V> build() { int len = keys.length; if (vals.length != len) { throw new IllegalArgumentException(); } if (len == 0) { return Collections.<K,V>emptyMap(); } else if (len == 1) { return Collections.<K,V>singletonMap(keys[0], vals[0]); // } else if (len < 33) { // return new UnsortedArrayBasedMap(keys, vals); // } else if (len < 1025) { // return new SortedArrayBasedMap(keys, vals); } else { Map<K,V> map = new HashMap<>(); for (int i = 0; i < len; ++i) { map.put(keys[i], vals[i]); } return Collections.unmodifiableMap(map); } } } } -------------------------------------------- Sincerely yours, Ivan > The issue here is that the target type doesn't back-propagate through > the chained method call .vals() to the call of .ofKeys(). > Incidentally, a similar problem occurs in the "obvious" builder > approach of doing something like this: > > Map<Integer,Character> map = Map.builder() > .add(1, 'a') > .add(2, 'b') > .... > .build(); > > It's possible to pursue workarounds for this problem, but then you're > heading down the rabbit hole.... > > A quasi-syntactic issue is that it's preferable to have each key and > value next to each other, so that each pair can be on its own line. > This makes it easier to maintain. If all the keys are listed together > first, followed by all the values, the pairing can only be made to > work if they're all short and if there are few enough pairs (as in > your example). Things start to break down if the keys/values > themselves are long, or if there are a lot of them, pushing the keys > and values lists onto multiple lines. Consider my example from the > head of the thread: > > Map<String,TypeUse> m = Map.ofEntries( > entry("CDATA", CBuiltinLeafInfo.NORMALIZED_STRING), > entry("ENTITY", CBuiltinLeafInfo.TOKEN), > entry("ENTITIES", CBuiltinLeafInfo.STRING.makeCollection()), > entry("ENUMERATION", CBuiltinLeafInfo.STRING.makeCollection()), > entry("NMTOKEN", CBuiltinLeafInfo.TOKEN), > entry("NMTOKENS", CBuiltinLeafInfo.STRING.makeCollection()), > entry("ID", CBuiltinLeafInfo.ID), > entry("IDREF", CBuiltinLeafInfo.IDREF), > entry("IDREFS", > TypeUseFactory.makeCollection(CBuiltinLeafInfo.IDREF)); > entry("ENUMERATION", CBuiltinLeafInfo.TOKEN)); > > Maintaining the association between keys and values is challenge. > Here's my attempt, where keys and values are associated by indentation > level: > > Map<String,TypeUse> m = Map.<String,TypeUse> > ofKeys("CDATA", > "ENTITY", > "ENTITIES", > "ENUMERATION", > "NMTOKEN", > "NMTOKENS", > "ID", > "IDREF", > "IDREFS", > "ENUMERATION") > .vals( CBuiltinLeafInfo.NORMALIZED_STRING, > CBuiltinLeafInfo.TOKEN, > CBuiltinLeafInfo.STRING.makeCollection(), > CBuiltinLeafInfo.STRING.makeCollection(), > CBuiltinLeafInfo.TOKEN, > CBuiltinLeafInfo.STRING.makeCollection(), > CBuiltinLeafInfo.ID, > CBuiltinLeafInfo.IDREF), > > TypeUseFactory.makeCollection(CBuiltinLeafInfo.IDREF), > CBuiltinLeafInfo.TOKEN); > > With more pairs, the distance between each key and its corresponding > value also increases. You could try to reduce the vertical distance by > filling the lines (more keys/values per line) but that makes the > association challenges even harder. Finally, consider the pain of > inserting or removing a key/value pair from the middle. > > s'marks > From blackdrag at gmx.org Sun Oct 18 08:49:10 2015 From: blackdrag at gmx.org (Jochen Theodorou) Date: Sun, 18 Oct 2015 10:49:10 +0200 Subject: JEP 276: Dynamic Linking of Language-Defined Object Models In-Reply-To: <CAP7YuATPogD2p+15VHCLgd2yQ_vJ2Ax_BpCzimKEnHTYYbpJrw@mail.gmail.com> References: <20151016173533.8325A7D532@eggemoggin.niobe.net> <CAP7YuATPogD2p+15VHCLgd2yQ_vJ2Ax_BpCzimKEnHTYYbpJrw@mail.gmail.com> Message-ID: <56235D06.5090109@gmx.org> On 17.10.2015 13:30, Martijn Verburg wrote: > This looks very, very promising. Would it help to get the language > maintainers of the most popular scripting/dynamic JVM languages involved > ASAP? Happy to contact Groovy, Clojure, Scala, JRuby folks (although I > suspect many of them are on this list). still easy to miss something like this ;) But I can give some comments for Groovy on this already. As I understand it, this JEP is mostly for calls from Java on objects from other languages. I have basically only main points: * Invokedynamic (like invokeinterface and invokevirtual) does not like calls with null as receiver, quitting the call right away with a NPE. But languages may allow for calls on null. That again means some kind of dummy receiver is required, if this is supposed to work. Then of course, if you want to allow calls on null, every call would have to go through the runtime in the end, thus I suspect this will be out of scope for this JEP. * Another part is the lookup of calls itself. To me the JEP is not fully clear here. Sure, there is a service for this, but is every call checked? That may slow down normal compilation for Java. The JEP speaks of methods provided beyond what Java offers - but what about methods replacing normal Java methods? Btw, one part that would make me very happy, is an official API, that allows some control of phases of the Java compiler as well as make missing classes programatically known to the compiler without requiring the java compiler to write those out as well. And that especially because I assume that jigsaw will put all the api needed for this into hiding by modules. bye Jochen Theodorou From aph at redhat.com Sun Oct 18 08:55:19 2015 From: aph at redhat.com (Andrew Haley) Date: Sun, 18 Oct 2015 09:55:19 +0100 Subject: JEP 276: Dynamic Linking of Language-Defined Object Models In-Reply-To: <56235D06.5090109@gmx.org> References: <20151016173533.8325A7D532@eggemoggin.niobe.net> <CAP7YuATPogD2p+15VHCLgd2yQ_vJ2Ax_BpCzimKEnHTYYbpJrw@mail.gmail.com> <56235D06.5090109@gmx.org> Message-ID: <56235E77.6070506@redhat.com> On 10/18/2015 09:49 AM, Jochen Theodorou wrote: > * Invokedynamic (like invokeinterface and invokevirtual) does not like > calls with null as receiver, quitting the call right away with a NPE. > But languages may allow for calls on null. That again means some kind of > dummy receiver is required, if this is supposed to work. Wouldn't you just insert a null pointer check? That's surely going to be faster (if it's used) than the runtime taking a NullPointerException. And you don't want the runtime to have to trap for null when many languages don't need it. Andrew. From attila.szegedi at oracle.com Sun Oct 18 16:19:58 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Sun, 18 Oct 2015 18:19:58 +0200 Subject: JEP 276: Dynamic Linking of Language-Defined Object Models In-Reply-To: <56235D06.5090109@gmx.org> References: <20151016173533.8325A7D532@eggemoggin.niobe.net> <CAP7YuATPogD2p+15VHCLgd2yQ_vJ2Ax_BpCzimKEnHTYYbpJrw@mail.gmail.com> <56235D06.5090109@gmx.org> Message-ID: <8B20E21F-36C4-41AA-B13A-6CB18389A236@oracle.com> > On Oct 18, 2015, at 10:49 AM, Jochen Theodorou <blackdrag at gmx.org> wrote: > > On 17.10.2015 13:30, Martijn Verburg wrote: >> This looks very, very promising. Would it help to get the language >> maintainers of the most popular scripting/dynamic JVM languages involved >> ASAP? Happy to contact Groovy, Clojure, Scala, JRuby folks (although I >> suspect many of them are on this list). > > still easy to miss something like this ;) > > But I can give some comments for Groovy on this already. As I understand it, this JEP is mostly for calls from Java on objects from other languages. I would say that understanding is incomplete. It is used to call from any language to any language. You can certainly use it to call from Java to another language, as well as to do dynamic calls within a single language, and across two different languages, neither of them necessarily being Java. > I have basically only main points: > > * Invokedynamic (like invokeinterface and invokevirtual) does not like calls with null as receiver, quitting the call right away with a NPE. This is fortunately not true, and Nashorn can show you that it isn?t. Launch it with: $JAVA_HOME/bin/jjs -doe -J-XX:+UnlockDiagnosticVMOptions -J-XX:+ShowHiddenFrames and type ?null()? at the command prompt (Nashorn?s JS null is also Java null). You?ll get this stack trace: <shell>:1 TypeError: null is not a function at jdk.nashorn.internal.runtime.ECMAErrors.error(ECMAErrors.java:57) at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:213) at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:185) at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:172) at jdk.nashorn.internal.runtime.linker.NashornBottomLinker.linkNull(NashornBottomLinker.java:176) at jdk.nashorn.internal.runtime.linker.NashornBottomLinker.getGuardedInvocation(NashornBottomLinker.java:66) at jdk.internal.dynalink.support.CompositeGuardingDynamicLinker.getGuardedInvocation(CompositeGuardingDynamicLinker.java:124) at jdk.internal.dynalink.support.LinkerServicesImpl.getGuardedInvocation(LinkerServicesImpl.java:154) at jdk.internal.dynalink.DynamicLinker.relink(DynamicLinker.java:253) >> at java.lang.invoke.LambdaForm$DMH/348100441.invokeSpecial_LLIL_L(LambdaForm$DMH:1000016) >> at java.lang.invoke.LambdaForm$BMH/827966648.reinvoke(LambdaForm$BMH:1000054) >> at java.lang.invoke.LambdaForm$MH/1273765644.exactInvoker(LambdaForm$MH:1000016) >> at java.lang.invoke.LambdaForm$MH/2013559698.linkToCallSite(LambdaForm$MH:1000011) at jdk.nashorn.internal.scripts.Script$Recompilation$1$\^shell\_.:program(<shell>:1) at ... The frames I marked with ?>>? are all java.lang.invoke internals going from the invokedynamic instruction with a null receiver, successfully dispatching into Dynalink and then Nashorn. (The bottommost frame before the cutoff is the invokedynamic instruction itself). It?s Nashorn that will ultimately respond to this throwing a JavaScript-specific TypeError from within the linker. invokedynamic doesn?t treat the first argument specially (in this one sense it?s more like invokestatic). > But languages may allow for calls on null. That again means some kind of dummy receiver is required, if this is supposed to work. Then of course, if you want to allow calls on null, every call would have to go through the runtime in the end, thus I suspect this will be out of scope for this JEP. > > * Another part is the lookup of calls itself. To me the JEP is not fully clear here. Sure, there is a service for this, but is every call checked? That may slow down normal compilation for Java. The JEP speaks of methods provided beyond what Java offers - but what about methods replacing normal Java methods? JEP 276 does not concern itself with any aspect of a compilation. It concerns itself with what happens at run time when an invokedynamic instructions needs to be linked. It is the job of the language-specific linkers to resolve the method handle to be linked. JEP 276 specifies one built-in linker named BeansLinker which provides the ?usual? operational semantics for POJOs that can be used standalone or composed with other linkers (Nashorn obviously composes it with its own linkers so it can link both POJOs and native JS objects at any call site). BeansLinker looks up method handles mostly through unreflection. I?m not sure what do you mean by ?checked? either - only public methods on publicly accessible classes are considered at this time. Hope this clarifies few things. Attila. > > Btw, one part that would make me very happy, is an official API, that allows some control of phases of the Java compiler as well as make missing classes programatically known to the compiler without requiring the java compiler to write those out as well. And that especially because I assume that jigsaw will put all the api needed for this into hiding by modules. > > bye Jochen Theodorou > From joe.darcy at oracle.com Sun Oct 18 17:45:21 2015 From: joe.darcy at oracle.com (joe darcy) Date: Sun, 18 Oct 2015 10:45:21 -0700 Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <562280F7.5050005@redhat.com> References: <5616FEB5.5090104@oracle.com> <CACzrW9A3MZja2wxsHZ7E0vSupkMJXMTQDqMQRjV548ArAF57Hw@mail.gmail.com> <87025428.3530190.1444485358747.JavaMail.zimbra@u-pem.fr> <56227B60.90709@oracle.com> <562280F7.5050005@redhat.com> Message-ID: <5623DAB1.4050701@oracle.com> On 10/17/2015 10:10 AM, Andrew Haley wrote: > On 10/17/2015 05:46 PM, Stuart Marks wrote: >> (I view calling an "inherited" class static method to be poor coding style, but >> neither javac nor NetBeans warns about it.) > That surely can be fixed. Should we start a feature request? I believe javac -Xlint:static ... does the check of interest; from running javac -X static Warn about accessing a static member using an instance HTH, -Joe From peter.levart at gmail.com Sun Oct 18 18:41:33 2015 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 18 Oct 2015 20:41:33 +0200 Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <56227B60.90709@oracle.com> References: <5616FEB5.5090104@oracle.com> <CACzrW9A3MZja2wxsHZ7E0vSupkMJXMTQDqMQRjV548ArAF57Hw@mail.gmail.com> <87025428.3530190.1444485358747.JavaMail.zimbra@u-pem.fr> <56227B60.90709@oracle.com> Message-ID: <5623E7DD.200@gmail.com> On 10/17/2015 06:46 PM, Stuart Marks wrote: > > > On 10/10/15 6:55 AM, Remi Forax wrote: >> There is an issue with LinkedHashMap (resp LinkedHashSet), >> it inherits from HashMap /facepalm/, and static methods are >> accessible through class inheritance /facepalm/. >> So if LinkedHashMap doesn't declare some methods of(), >> LinkedHashMap.of("foo") >> will return a HashMap :( > > Hi R?mi, > > Thanks for pointing this out. I had forgotten about "inheritance" of > static methods. /Facepalm/ indeed. The original proposal (July 2014) > avoided this issue by adding static methods only on interfaces, which > are *not* inherited. When we added statics on concrete classes this > problem returned. > > (I view calling an "inherited" class static method to be poor coding > style, but neither javac nor NetBeans warns about it.) > > Well, perhaps we won't be adding static factories to the concrete > collections after all, so maybe we can dodge this issue. See messages > downthread. > > s'marks > Concrete classes have constructors. With diamonds, if you are lucky. ;-) Why not adding some constructors like: public class ArrayList<E> { // existing public ArrayList(int initialCapacity) public ArrayList() public ArrayList(Collection<? extends E> c) // new public ArrayList(E e1) public ArrayList(E e1, E e2) public ArrayList(E e1, E e2, E e3) ... public ArrayList(E... es) There might be some problems with a few cases like: List<Integer> list1 = new ArrayList<>(42); // empty list with capacity 42 List<Integer> list2 = new ArrayList<>((Integer) 42); // list with single element And consequently some source incompatibilities in rare occasions. But would that hurt too much? The question is, and that applies to .of() static methods too, whether there should be overloads that take 'initialCapacity' too. The programmer's choice of mutable collection (instead of immutable one) is probably a consequence of expanding the collection later. So pre-sizing it to the number of initial elements is rarely optimal. Mutable collections maybe just need a set of instance methods (defaults on Collection with covariant overrides on implementations?) that are used to add a bunch of elements and return 'this', like: public class ArrayList<E> { public ArrayList<E> addElements(E e1) public ArrayList<E> addElements(E e1, E e2) public ArrayList<E> addElements(E e1, E e2, E e3) ... public ArrayList<E> addElements(E ... es) Unfortunately, diamonds are not possible in such arrangement as javac infers ArrayList<Object> for the following: ArrayList<String> als = new ArrayList<>().addElements("a", "b", "c"); Error:(16, 61) java: incompatible types: ArrayList<java.lang.Object> cannot be converted to ArrayList<java.lang.String> So it would have to be written explicitly as: ArrayList<String> als = new ArrayList<String>().addElements("a", "b", "c"); The question is also whether initialization expressions with mutable collections and initial sets of elements would really be that frequent in practice. Currently we can use this: ArrayList<String> als = new ArrayList<>(Arrays.asList("a", "b", "c")); If it can be changed to this: ArrayList<String> als = new ArrayList<>(List.of("a", "b", "c")); ...it's an improvement. Regards, Peter From attila.szegedi at oracle.com Sun Oct 18 20:57:40 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Sun, 18 Oct 2015 22:57:40 +0200 Subject: JEP 276: Dynamic Linking of Language-Defined Object Models In-Reply-To: <CAP7YuATPogD2p+15VHCLgd2yQ_vJ2Ax_BpCzimKEnHTYYbpJrw@mail.gmail.com> References: <20151016173533.8325A7D532@eggemoggin.niobe.net> <CAP7YuATPogD2p+15VHCLgd2yQ_vJ2Ax_BpCzimKEnHTYYbpJrw@mail.gmail.com> Message-ID: <C6053203-2DCD-4AEC-B3A4-6449D9AEBE0D@oracle.com> Sure. For what?s it worth, this is for all practical purposes Dynalink, in the form I?ve been developing for years as a standalone library on GitHub and presenting about it at JVM Language Summits over several years, so I?d expect a significant amount of awareness is there. The primary motivator for this JEP is that I finally came to the point where I want to take it out of the jdk.internal.* space and into jdk.* space, so it is a supported API available to others as well, not just Nashorn. There were already people trying to do so something with the jdk.internal.* APIs, e.g. <http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-March/004250.html <http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-March/004250.html>> and discovering that JDK 9 is blocking that path. For quite long I was reluctant to bring it out into the open as we were making lots of improvements on it internally driven by real-world use requirements coming from Nashorn, but it was always the intent to eventually do so. It was just a matter of finding the right time to do it: after it seems to have stabilized internally (so we feel fairly confident that there?s nothing in the design that could be invalidated or incomplete), but before people really want to use it but can?t. We?re obviously somewhat late on ?people want to use it" metric, see above linked e-mail, but I feel we?re now reached the right time with regard to stabilization. Which of course is not to say that we won?t discuss this with other language implementers further; getting the current machinery underlying Nashorn out there as an accessible API (with a lot of cleanup and exhaustive documentation, as befitting a supported API) is the first step, and then when it?s out there and people can - as somene said - kick the tires we can mold it further with input from the community as necessary. On a purely personal sidenote, I?m extremely excited to move forward with this. Maybe I?ll eventually write a (highly romanticized, of course) story of how Dynalink got started, but if I just look at it chronologically, it is something I?ve started thinking about circa 2007, wrote an initial prototype in 2008, and the first invokedynamic-based reformulation in 2009, a later iteration of which got integrated into Nashorn in 2012, and then developed alongside it ever since. So, it?s been part of my work life, on and off for good 7-8 years now. I?m obviously thrilled to be taking it to maturation with OpenJDK community :-) Attila. > On Oct 17, 2015, at 1:30 PM, Martijn Verburg <martijnverburg at gmail.com> wrote: > > This looks very, very promising. Would it help to get the language maintainers of the most popular scripting/dynamic JVM languages involved ASAP? Happy to contact Groovy, Clojure, Scala, JRuby folks (although I suspect many of them are on this list). > > Cheers, > Martijn > > On 16 October 2015 at 18:35, <mark.reinhold at oracle.com <mailto:mark.reinhold at oracle.com>> wrote: > New JEP Candidate: http://openjdk.java.net/jeps/276 <http://openjdk.java.net/jeps/276> > > - Mark > From john.r.rose at oracle.com Mon Oct 19 01:09:14 2015 From: john.r.rose at oracle.com (John Rose) Date: Sun, 18 Oct 2015 18:09:14 -0700 Subject: JEP 276: Dynamic Linking of Language-Defined Object Models In-Reply-To: <56235D06.5090109@gmx.org> References: <20151016173533.8325A7D532@eggemoggin.niobe.net> <CAP7YuATPogD2p+15VHCLgd2yQ_vJ2Ax_BpCzimKEnHTYYbpJrw@mail.gmail.com> <56235D06.5090109@gmx.org> Message-ID: <5CF68D7E-5B78-482A-92A1-973EB799B1BF@oracle.com> On Oct 18, 2015, at 1:49 AM, Jochen Theodorou <blackdrag at gmx.org> wrote: > > * Invokedynamic (like invokeinterface and invokevirtual) does not like calls with null as receiver :-) Jochen, you are one of the few people on the planet who was around JSR 292 when this *was* true. A very early draft of indy piggy-backed on top of the invokeinterface instruction. Eventually we made it symmetrical in all its arguments, like invokestatic, as Attila pointed out. ? John From stuart.marks at oracle.com Mon Oct 19 01:13:17 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Sun, 18 Oct 2015 18:13:17 -0700 Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <5623DAB1.4050701@oracle.com> References: <5616FEB5.5090104@oracle.com> <CACzrW9A3MZja2wxsHZ7E0vSupkMJXMTQDqMQRjV548ArAF57Hw@mail.gmail.com> <87025428.3530190.1444485358747.JavaMail.zimbra@u-pem.fr> <56227B60.90709@oracle.com> <562280F7.5050005@redhat.com> <5623DAB1.4050701@oracle.com> Message-ID: <562443AD.1010705@oracle.com> On 10/18/15 10:45 AM, joe darcy wrote: > On 10/17/2015 10:10 AM, Andrew Haley wrote: >> On 10/17/2015 05:46 PM, Stuart Marks wrote: >>> (I view calling an "inherited" class static method to be poor coding style, but >>> neither javac nor NetBeans warns about it.) >> That surely can be fixed. Should we start a feature request? > > I believe > > javac -Xlint:static ... > > does the check of interest; from running javac -X > > static Warn about accessing a static member using an instance Nope, it doesn't, I was surprised too. class A { static void foo() { System.out.println("A.foo()"); } } class B extends A { } B.foo(); // no warning A a = new A(); a.foo(); // warning B b = new B(); b.foo(); // warning I've filed https://bugs.openjdk.java.net/browse/JDK-8139827 I checked NetBeans but I only looked briefly at the hints and style options, and nothing I enabled generated a warning. But it would probably be worth it for someone to take another look. It would also be helpful if somebody could check this with other IDEs as well. s'marks From nadeesh.tv at oracle.com Mon Oct 19 06:59:30 2015 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Mon, 19 Oct 2015 12:29:30 +0530 Subject: RFR:8134928:java.time.Instant.truncatedTo(TemporalUnit unit) is truncating up if the year < 1970 In-Reply-To: <CACzrW9Bzt64hHO=g8eECdteO75Zn7HYx_bWhWtvshsYa7EJwoQ@mail.gmail.com> References: <561E260A.8050103@oracle.com> <CACzrW9Bzt64hHO=g8eECdteO75Zn7HYx_bWhWtvshsYa7EJwoQ@mail.gmail.com> Message-ID: <562494D2.3090702@oracle.com> HI all, Please review the updated webrev http://cr.openjdk.java.net/~ntv/8134928/webrev.01/ Regards, Nadeesh On 10/14/2015 4:06 PM, Stephen Colebourne wrote: > I'd like to see an additional test case for the cases where rounding > is *not* needed. Currently, there are only tests for where rounding is > needed. It needs one more test line for after 1970 and one for before > 1970. > > thanks > Stephen > > > On 14 October 2015 at 10:53, nadeesh tv <nadeesh.tv at oracle.com> wrote: >> Hi all, >> >> Please review a fix for https://bugs.openjdk.java.net/browse/JDK-8134928 >> >> Issue- java.time.Instant.truncatedTo(TemporalUnit unit) is truncating up if >> the year < 1970 >> >> BugId - https://bugs.openjdk.java.net/browse/JDK-8134928 >> >> webrev - http://cr.openjdk.java.net/~pchopra/8134928/webrev.01/ >> >> -- >> Thanks and Regards, >> Nadeesh TV >> -- Thanks and Regards, Nadeesh TV From blackdrag at gmx.org Mon Oct 19 07:33:37 2015 From: blackdrag at gmx.org (Jochen Theodorou) Date: Mon, 19 Oct 2015 09:33:37 +0200 Subject: JEP 276: Dynamic Linking of Language-Defined Object Models In-Reply-To: <5CF68D7E-5B78-482A-92A1-973EB799B1BF@oracle.com> References: <20151016173533.8325A7D532@eggemoggin.niobe.net> <CAP7YuATPogD2p+15VHCLgd2yQ_vJ2Ax_BpCzimKEnHTYYbpJrw@mail.gmail.com> <56235D06.5090109@gmx.org> <5CF68D7E-5B78-482A-92A1-973EB799B1BF@oracle.com> Message-ID: <56249CD1.5090102@gmx.org> On 19.10.2015 03:09, John Rose wrote: > On Oct 18, 2015, at 1:49 AM, Jochen Theodorou <blackdrag at gmx.org > <mailto:blackdrag at gmx.org>> wrote: >> >> * Invokedynamic (like invokeinterface and invokevirtual) does not like >> calls with null as receiver > > :-) Jochen, you are one of the few people on the planet who was around > JSR 292 when this *was* true. > A very early draft of indy piggy-backed on top of the invokeinterface > instruction. > Eventually we made it symmetrical in all its arguments, like > invokestatic, as Attila pointed out. ups... looks like I missed that. Well, then sorry for the fuzz ;) Can you tell me since what version this has been changed? Because I thought I had this problem with 1.8 still, but I could be wrong and it was only 1.7.. Was it done along with the lambda forms rewrite? bye blackdrag From blackdrag at gmx.org Mon Oct 19 07:34:11 2015 From: blackdrag at gmx.org (Jochen Theodorou) Date: Mon, 19 Oct 2015 09:34:11 +0200 Subject: JEP 276: Dynamic Linking of Language-Defined Object Models In-Reply-To: <56235E77.6070506@redhat.com> References: <20151016173533.8325A7D532@eggemoggin.niobe.net> <CAP7YuATPogD2p+15VHCLgd2yQ_vJ2Ax_BpCzimKEnHTYYbpJrw@mail.gmail.com> <56235D06.5090109@gmx.org> <56235E77.6070506@redhat.com> Message-ID: <56249CF3.1020706@gmx.org> On 18.10.2015 10:55, Andrew Haley wrote: > On 10/18/2015 09:49 AM, Jochen Theodorou wrote: >> * Invokedynamic (like invokeinterface and invokevirtual) does not like >> calls with null as receiver, quitting the call right away with a NPE. >> But languages may allow for calls on null. That again means some kind of >> dummy receiver is required, if this is supposed to work. > > Wouldn't you just insert a null pointer check? That's surely going to > be faster (if it's used) than the runtime taking a > NullPointerException. And you don't want the runtime to have to trap > for null when many languages don't need it. Let's scrap that, outdated information on my side From blackdrag at gmx.org Mon Oct 19 08:46:21 2015 From: blackdrag at gmx.org (Jochen Theodorou) Date: Mon, 19 Oct 2015 10:46:21 +0200 Subject: JEP 276: Dynamic Linking of Language-Defined Object Models In-Reply-To: <8B20E21F-36C4-41AA-B13A-6CB18389A236@oracle.com> References: <20151016173533.8325A7D532@eggemoggin.niobe.net> <CAP7YuATPogD2p+15VHCLgd2yQ_vJ2Ax_BpCzimKEnHTYYbpJrw@mail.gmail.com> <56235D06.5090109@gmx.org> <8B20E21F-36C4-41AA-B13A-6CB18389A236@oracle.com> Message-ID: <5624ADDD.5000507@gmx.org> On 18.10.2015 18:19, Attila Szegedi wrote: [...] >> I have basically only main points: >> >> * Invokedynamic (like invokeinterface and invokevirtual) does not like calls with null as receiver, quitting the call right away with a NPE. > > This is fortunately not true, and Nashorn can show you that it isn?t. not true anymore, yes, now I know ;) [...] >> * Another part is the lookup of calls itself. To me the JEP is not fully clear here. Sure, there is a service for this, but is every call checked? That may slow down normal compilation for Java. The JEP speaks of methods provided beyond what Java offers - but what about methods replacing normal Java methods? > > JEP 276 does not concern itself with any aspect of a compilation. It concerns itself with what happens at run time when an invokedynamic instructions needs to be linked. Ok, I get it, the JEP is mostly to move the internal dynalink into a public package and maybe adapt in some ways to make it more usable for other languages. > It is the job of the language-specific linkers to resolve the method handle to be linked. JEP 276 specifies one built-in linker named BeansLinker which provides the ?usual? operational semantics for POJOs that can be used standalone or composed with other linkers (Nashorn obviously composes it with its own linkers so it can link both POJOs and native JS objects at any call site). BeansLinker looks up method handles mostly through unreflection. I?m not sure what do you mean by ?checked? either - only public methods on publicly accessible classes are considered at this time. since it is dynalink there is I guess only one master linker in the end. Can you point me to some code showing how the composition of linkers is done to refresh my memory on that? bye blackdrag From attila.szegedi at oracle.com Mon Oct 19 10:56:51 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 19 Oct 2015 12:56:51 +0200 Subject: JEP 276: Dynamic Linking of Language-Defined Object Models In-Reply-To: <5624ADDD.5000507@gmx.org> References: <20151016173533.8325A7D532@eggemoggin.niobe.net> <CAP7YuATPogD2p+15VHCLgd2yQ_vJ2Ax_BpCzimKEnHTYYbpJrw@mail.gmail.com> <56235D06.5090109@gmx.org> <8B20E21F-36C4-41AA-B13A-6CB18389A236@oracle.com> <5624ADDD.5000507@gmx.org> Message-ID: <F6045FDE-F3F1-4587-881F-169386C1EA27@oracle.com> On Oct 19, 2015, at 10:46 AM, Jochen Theodorou <blackdrag at gmx.org> wrote: > since it is dynalink there is I guess only one master linker in the end. Can you point me to some code showing how the composition of linkers is done to refresh my memory on that? Sure, here?s how Nashorn does it: http://hg.openjdk.java.net/jdk9/dev/nashorn/file/f93753325c7b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/Bootstrap.java#l92 <http://hg.openjdk.java.net/jdk9/dev/nashorn/file/f93753325c7b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/Bootstrap.java#l92> You?ll notice that Nashorn has a total of 10 linkers - they?re modularized per purpose. Some of them are internal, that is, they only operate on call sites within Nashorn: - NashornPrimitiveLinker deals with linking java.lang.Number, java.lang.Boolean, and java.lang.String objects as if they were JS number, boolean, and string primitive values. - BrowserJSObjectLinker that allows linking of netscape.javascript.JSObject objects (should they somehow be passed to Nashorn) - NashornStaticClassLinker links the NEW operation to enable the ?new java.lang.Runnable() { ? }? anonymous-class style creation of adapters for Java interfaces. - NashornBottomLinker deals with linking missing properties on POJOs as well as linking operations on null, mostly supplying language-specific error-raising behavior. - NashornBeansLinker is a bit weird one, as it mostly delegates to ordinary BeansLinker, but it deals with some odds and ends, namely allowing @FunctionalInterface objects to be linked as JS callables and smoothing over the fact that internally we don?t always use java.lang.String for representing strings. - ReflectionCheckLinker is an interesting beastie as it doesn?t link anything itself, but can prevent linking Java reflective operations (they are specifically disallowed in Nashorn; this is policy due to the fact Nashorn is part of the JDK and we?d rather conservatively take that functionality away from JS programs than deal with a security risk). Then we have those that could be exported: - NashornLinker obviously, as it?s the primary linker for all native JS objects, as well as JSObject linker as it?s the primary linker for exported JS objects - BoundCallableLinker that is a nice example of how you provide linking by delegation; it provides linking of bound callables by delegating to the linker for the underlying unbound callable, and then re-binding the result of that linkage - JavaSuperAdapterLinker is another delegating example working similarly to the previous one; this one handles the Nashorn?s feature for allowing super-calls to Java objects from adapters The first 8 (prioritized) linkers all implement the TypeBasedGuardingDynamicLinker interface, meaning the factory will internally compose them into a fast (constant time) dispatch-by-receiver-type CompositeTypeBasedGuardingDynamicLinker instance; you could have any number of those without impacting the linking performance (not that finding the right linker is the slow operation usually). Attila. From martijnverburg at gmail.com Mon Oct 19 12:08:23 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 19 Oct 2015 13:08:23 +0100 Subject: JEP 276: Dynamic Linking of Language-Defined Object Models In-Reply-To: <C6053203-2DCD-4AEC-B3A4-6449D9AEBE0D@oracle.com> References: <20151016173533.8325A7D532@eggemoggin.niobe.net> <CAP7YuATPogD2p+15VHCLgd2yQ_vJ2Ax_BpCzimKEnHTYYbpJrw@mail.gmail.com> <C6053203-2DCD-4AEC-B3A4-6449D9AEBE0D@oracle.com> Message-ID: <CAP7YuAQUewvkPCYrxNtmmKtsCx7Jw6H1OtpfRUVX4-MGFxa55Q@mail.gmail.com> Hi Attila, Cool, reached out to a few people (Scala & Clojure in particular) JIC they missed it and pointed them directly at the JEP and this thread. I think the API will be all the richer when it hits its 2nd real enemy (so to speak) :-). Cheers, Martijn On 18 October 2015 at 21:57, Attila Szegedi <attila.szegedi at oracle.com> wrote: > Sure. For what?s it worth, this is for all practical purposes Dynalink, in > the form I?ve been developing for years as a standalone library on GitHub > and presenting about it at JVM Language Summits over several years, so I?d > expect a significant amount of awareness is there. > > The primary motivator for this JEP is that I finally came to the point > where I want to take it out of the jdk.internal.* space and into jdk.* > space, so it is a supported API available to others as well, not just > Nashorn. There were already people trying to do so something with the > jdk.internal.* APIs, e.g. < > http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-March/004250.html> > and discovering that JDK 9 is blocking that path. > > For quite long I was reluctant to bring it out into the open as we were > making lots of improvements on it internally driven by real-world use > requirements coming from Nashorn, but it was always the intent to > eventually do so. It was just a matter of finding the right time to do it: > after it seems to have stabilized internally (so we feel fairly confident > that there?s nothing in the design that could be invalidated or > incomplete), but before people really want to use it but can?t. We?re > obviously somewhat late on ?people want to use it" metric, see above linked > e-mail, but I feel we?re now reached the right time with regard to > stabilization. > > Which of course is not to say that we won?t discuss this with other > language implementers further; getting the current machinery underlying > Nashorn out there as an accessible API (with a lot of cleanup and > exhaustive documentation, as befitting a supported API) is the first step, > and then when it?s out there and people can - as somene said - kick the > tires we can mold it further with input from the community as necessary. > > On a purely personal sidenote, I?m extremely excited to move forward with > this. Maybe I?ll eventually write a (highly romanticized, of course) story > of how Dynalink got started, but if I just look at it chronologically, it > is something I?ve started thinking about circa 2007, wrote an initial > prototype in 2008, and the first invokedynamic-based reformulation in 2009, > a later iteration of which got integrated into Nashorn in 2012, and then > developed alongside it ever since. So, it?s been part of my work life, on > and off for good 7-8 years now. I?m obviously thrilled to be taking it to > maturation with OpenJDK community :-) > > Attila. > > > On Oct 17, 2015, at 1:30 PM, Martijn Verburg <martijnverburg at gmail.com> > wrote: > > This looks very, very promising. Would it help to get the language > maintainers of the most popular scripting/dynamic JVM languages involved > ASAP? Happy to contact Groovy, Clojure, Scala, JRuby folks (although I > suspect many of them are on this list). > > Cheers, > Martijn > > On 16 October 2015 at 18:35, <mark.reinhold at oracle.com> wrote: > >> New JEP Candidate: http://openjdk.java.net/jeps/276 >> >> - Mark >> > > > From timo.kinnunen at gmail.com Mon Oct 19 14:40:22 2015 From: timo.kinnunen at gmail.com (Timo Kinnunen) Date: Mon, 19 Oct 2015 16:40:22 +0200 Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <5623E7DD.200@gmail.com> References: <5616FEB5.5090104@oracle.com> <CACzrW9A3MZja2wxsHZ7E0vSupkMJXMTQDqMQRjV548ArAF57Hw@mail.gmail.com> <87025428.3530190.1444485358747.JavaMail.zimbra@u-pem.fr> <56227B60.90709@oracle.com> <5623E7DD.200@gmail.com> Message-ID: <562500dc.84adc20a.59048.ffffce56@mx.google.com> Having one less import-statement that has to be written -- while editing a file -- by Content Assist/IntelliSense/Code Completion is a small improvement, but apart from that going from: ArrayList<String> als = new ArrayList<>(Arrays.asList("a", "b", "c")); to: ArrayList<String> als = new ArrayList<>(List.of("a", "b", "c")); may otherwise be a regression. Arrays.asList() isn't immutable so it can just wrap the array without copying, but an immutable List.of() has to make a defensive copy. The ArrayList constructor can't easily pick up the slack either, it needs to create a copy too. Otherwise stashing a reference as in the following could be used to create a mutable immutable List: String[] mutableArray; List<String> immutableList; ArrayList<String> als = new ArrayList<>(immutableList = List.of(mutableArray = new String[] { "a", "b", "c" })); Then again a mutable List looking like an immutable List can also be easily created with: List<String> immaybemutableList = new ArrayList<>(Arrays.asList("a", "b", "c")); and I'm left wondering how much utility is in a truly immutable List that no-one else can freely share trusting it to be immutable. Having to sprinkle some List.ensureImmutable(immaybemutableList) method calls everywhere would be pretty bad. Sent from Mail for Windows 10 From: Peter Levart Sent: Sunday, October 18, 2015 20:42 To: Stuart Marks;Remi Forax Cc: core-libs-dev Subject: Re: RFC: draft API for JEP 269 Convenience Collection Factories On 10/17/2015 06:46 PM, Stuart Marks wrote: > > > On 10/10/15 6:55 AM, Remi Forax wrote: >> There is an issue with LinkedHashMap (resp LinkedHashSet), >> it inherits from HashMap /facepalm/, and static methods are >> accessible through class inheritance /facepalm/. >> So if LinkedHashMap doesn't declare some methods of(), >> LinkedHashMap.of("foo") >> will return a HashMap :( > > Hi R?mi, > > Thanks for pointing this out. I had forgotten about "inheritance" of > static methods. /Facepalm/ indeed. The original proposal (July 2014) > avoided this issue by adding static methods only on interfaces, which > are *not* inherited. When we added statics on concrete classes this > problem returned. > > (I view calling an "inherited" class static method to be poor coding > style, but neither javac nor NetBeans warns about it.) > > Well, perhaps we won't be adding static factories to the concrete > collections after all, so maybe we can dodge this issue. See messages > downthread. > > s'marks > Concrete classes have constructors. With diamonds, if you are lucky. ;-) Why not adding some constructors like: public class ArrayList<E> { // existing public ArrayList(int initialCapacity) public ArrayList() public ArrayList(Collection<? extends E> c) // new public ArrayList(E e1) public ArrayList(E e1, E e2) public ArrayList(E e1, E e2, E e3) ... public ArrayList(E... es) There might be some problems with a few cases like: List<Integer> list1 = new ArrayList<>(42); // empty list with capacity 42 List<Integer> list2 = new ArrayList<>((Integer) 42); // list with single element And consequently some source incompatibilities in rare occasions. But would that hurt too much? The question is, and that applies to .of() static methods too, whether there should be overloads that take 'initialCapacity' too. The programmer's choice of mutable collection (instead of immutable one) is probably a consequence of expanding the collection later. So pre-sizing it to the number of initial elements is rarely optimal. Mutable collections maybe just need a set of instance methods (defaults on Collection with covariant overrides on implementations?) that are used to add a bunch of elements and return 'this', like: public class ArrayList<E> { public ArrayList<E> addElements(E e1) public ArrayList<E> addElements(E e1, E e2) public ArrayList<E> addElements(E e1, E e2, E e3) ... public ArrayList<E> addElements(E ... es) Unfortunately, diamonds are not possible in such arrangement as javac infers ArrayList<Object> for the following: ArrayList<String> als = new ArrayList<>().addElements("a", "b", "c"); Error:(16, 61) java: incompatible types: ArrayList<java.lang.Object> cannot be converted to ArrayList<java.lang.String> So it would have to be written explicitly as: ArrayList<String> als = new ArrayList<String>().addElements("a", "b", "c"); The question is also whether initialization expressions with mutable collections and initial sets of elements would really be that frequent in practice. Currently we can use this: ArrayList<String> als = new ArrayList<>(Arrays.asList("a", "b", "c")); If it can be changed to this: ArrayList<String> als = new ArrayList<>(List.of("a", "b", "c")); ...it's an improvement. Regards, Peter From timo.kinnunen at gmail.com Mon Oct 19 15:17:34 2015 From: timo.kinnunen at gmail.com (Timo Kinnunen) Date: Mon, 19 Oct 2015 17:17:34 +0200 Subject: RFC: draft API for JEP 269 Convenience Collection Factories In-Reply-To: <562443AD.1010705@oracle.com> References: <5616FEB5.5090104@oracle.com> <CACzrW9A3MZja2wxsHZ7E0vSupkMJXMTQDqMQRjV548ArAF57Hw@mail.gmail.com> <87025428.3530190.1444485358747.JavaMail.zimbra@u-pem.fr> <56227B60.90709@oracle.com> <562280F7.5050005@redhat.com> <5623DAB1.4050701@oracle.com> <562443AD.1010705@oracle.com> Message-ID: <56250994.a472c20a.226ae.ffff9c14@mx.google.com> They are warnings in Eclipse and IntelliJ IDEA: ?The static method foo() from the type A should be accessed directly? ?The static method foo() from the type A should be accessed in a static way? ?The static method foo() from the type A should be accessed directly? ?Static method 'foo()' declared in class 'test.A' but referenced via subclass? ?Static member 'test.A.foo()' accessed via instance reference? ?Static member 'test.B.foo()' accessed via instance reference? Neither one has the warning for B.foo() enabled by default but provide it under their ?potential problems? categories. Sent from Mail for Windows 10 From: Stuart Marks Sent: Monday, October 19, 2015 03:13 To: joe darcy;Andrew Haley Cc: core-libs-dev Subject: Re: RFC: draft API for JEP 269 Convenience Collection Factories On 10/18/15 10:45 AM, joe darcy wrote: > On 10/17/2015 10:10 AM, Andrew Haley wrote: >> On 10/17/2015 05:46 PM, Stuart Marks wrote: >>> (I view calling an "inherited" class static method to be poor coding style, but >>> neither javac nor NetBeans warns about it.) >> That surely can be fixed. Should we start a feature request? > > I believe > > javac -Xlint:static ... > > does the check of interest; from running javac -X > > static Warn about accessing a static member using an instance Nope, it doesn't, I was surprised too. class A { static void foo() { System.out.println("A.foo()"); } } class B extends A { } B.foo(); // no warning A a = new A(); a.foo(); // warning B b = new B(); b.foo(); // warning I've filed https://bugs.openjdk.java.net/browse/JDK-8139827 I checked NetBeans but I only looked briefly at the hints and style options, and nothing I enabled generated a warning. But it would probably be worth it for someone to take another look. It would also be helpful if somebody could check this with other IDEs as well. s'marks From bob.vandette at oracle.com Mon Oct 19 18:09:21 2015 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 19 Oct 2015 14:09:21 -0400 Subject: RFR: 8136556 - Add the ability to perform static builds of MacOSX x64 binaries In-Reply-To: <5620991B.8050606@oracle.com> References: <EFE473E9-96C6-49D5-BA84-81D6011B579C@oracle.com> <5620991B.8050606@oracle.com> Message-ID: <68E34DF5-8759-4614-AB69-F5301D183716@oracle.com> Here?s the updated set of webrev?s that address two issues: 1. Move jni_util.h out of jawt.h 2. Christians concern over using a single variable name for Makefile and C/C++ logic. http://cr.openjdk.java.net/~bobv/8136556/webrev.01 <http://cr.openjdk.java.net/~bobv/8136556/webrev.01> http://cr.openjdk.java.net/~bobv/8136556/hotspot/webrev.01 <http://cr.openjdk.java.net/~bobv/8136556/hotspot/webrev.01> http://cr.openjdk.java.net/~bobv/8136556/jdk/webrev.01 <http://cr.openjdk.java.net/~bobv/8136556/jdk/webrev.01> Bob. > On Oct 16, 2015, at 2:28 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote: > > On 15/10/2015 19:07, Bob Vandette wrote: >> Please review this JDK 9 enhancement which allows a completely static build of the JDK for MacOSX x64 platforms. >> >> https://bugs.openjdk.java.net/browse/JDK-8136556 <https://bugs.openjdk.java.net/browse/JDK-8136556> >> >> The change involves: >> >> 1. Producing ?.a? archives for each native libraries. >> 2. Ensuring that all symbols across the JDK native libraries are unique. >> 3. Changing the JNI_OnLoad and JNI_OnUnload (and the Agent equivalents) to have the each library name appended per >> the JNI specification. >> 4. Modifications to the launcher and launcher Makefiles to allow them to be linked with the java.base and jdk.jdwp.agent libraries >> and function. >> >> http://cr.openjdk.java.net/~bobv/8136556/webrev.00/ <http://cr.openjdk.java.net/~bobv/8136556/webrev.00/> >> http://cr.openjdk.java.net/~bobv/8136556/hotspot/webrev.00/ <http://cr.openjdk.java.net/~bobv/8136556/hotspot/webrev.00/> >> http://cr.openjdk.java.net/~bobv/8136556/jdk/webrev.00/ <http://cr.openjdk.java.net/~bobv/8136556/jdk/webrev.00/> >> >> Note: This change does not link every possible static library with the launchers. It is currently limited to >> the java.base and jdk.jdwp.agent libraries in order to allow for the TCK validation of the base module only. >> > I've skimmed through the patches and the DEF_* macros look okay. The only one that doesn't look right is jawt.h/jawt.c. As jawt.h is shipped by the JDK then I think the include of jni_util.h needs to move from jawt.h to jawt.c. > > If I read the changes correctly then not loading the JavaRuntimeSupport.framework on Mac means the locale might not be right, is that correct? Brent might remember this issue as we've often pondered the implications of this disappearing in an Mac update. > > Will there be continuous or at least regular builds setup so that build breakages will be reported in a timely manner? It would be easy to change something that breaks the static library build. > > -Alan From daniel.fuchs at oracle.com Mon Oct 19 18:18:58 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 19 Oct 2015 20:18:58 +0200 Subject: RFR: JDK-8046565: Platform Logger API and Service In-Reply-To: <17C7339F-2107-49DE-B909-A65D779F0DF1@oracle.com> References: <561660DA.7070900@oracle.com> <8D8890A3-2337-4178-BA5C-CC32DE12F27D@oracle.com> <561E3A9A.9050807@oracle.com> <6241BCF8-C6A3-4E64-94E9-5E70CEF4A829@oracle.com> <561E8CE7.9020609@oracle.com> <17C7339F-2107-49DE-B909-A65D779F0DF1@oracle.com> Message-ID: <56253412.4030800@oracle.com> Hi Mandy, I have updated the links with the modifications we discussed last Friday: - I have removed the tag @apiNote from System.LoggerFinder - I have relaxed the constraint of what happens if several implementations of LoggerFinder are present - the specification no longer mandate that ServiceConfigurationError is thrown, and the implementation will simply take the first one returned by the ServiceLoader. - I have moved PlatformLoggerBridge and ConfigurableLoggerBridge to be inner interfaces of PlatformLogger: PlatformLoggerBridge => PlatformLogger.Bridge ConfigurableLoggerBridge => PlatformLogger.ConfigurableBridge (and fixed their class-level javadoc as well) I have pushed the changes to the sandbox (JDK-8046565-branch) and updated the content of 'proto.02' (same link as before: specdiff: http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/specdiff-api/overview-summary.html webrev: http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/webrev/index.html best regards, -- daniel On 14/10/15 22:57, Mandy Chung wrote: > Addiitional comments: > > JdkLoggerProvider.java > - should the GC?ed referent entries in the application SharedLoggers map be occasionally drained? > > BootstrapLogger.java > In the BootstrapExecutors::join(Runnable r) method: > try { > getExecutor().submit(r).get(); > } catch (InterruptedException | ExecutionException ex) { > // should not happen > ex.printStackTrace(System.err); > } > - we should avoid output any debugging code though. > > typos: > indepedent > temporarilly > > // Unfortunately, if we come to here it means we are in the bootsraping > // phase where using lambdas is not safe yet - so we have to use a > // a data object instead? > FYI. jake has changed the system initialization sequence that allows the use of lambda early at startup. That may help in this case that you can revisit this in the future. > > This reminds me the startup performance. Is there any use System.Logger to log message during startup in JDK 9? Using lambda at startup will have impact to the startup performance. > > Also I?m curious to know the difference of classes loaded at startup if System.getLogger is called in one of the system class loaded during startup but no log message is output (as typical case is to print debugging message) with and without java.logging. > > // Not sure whether this is needed: it was in the original > // PlatformLogger proxy code: > - I don?t understand why sun.util.logger.LazyLoggers$JdkLazyLogger need to be loaded. DetectBackend is loaded only after booted (per the comment) > > Naming nit: > PlatformLoggerBridge - would it be better to move to PlatformLogger.Bridge? It?s nit and I think it reads better and clearly associate with PlatformLogger. > > Mandy > From christian.thalinger at oracle.com Mon Oct 19 19:25:57 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 19 Oct 2015 09:25:57 -1000 Subject: RFR: 8136556 - Add the ability to perform static builds of MacOSX x64 binaries In-Reply-To: <68E34DF5-8759-4614-AB69-F5301D183716@oracle.com> References: <EFE473E9-96C6-49D5-BA84-81D6011B579C@oracle.com> <5620991B.8050606@oracle.com> <68E34DF5-8759-4614-AB69-F5301D183716@oracle.com> Message-ID: <D43701BD-FF19-4911-90CF-89CF55D8357A@oracle.com> > On Oct 19, 2015, at 8:09 AM, Bob Vandette <bob.vandette at oracle.com> wrote: > > Here?s the updated set of webrev?s that address two issues: > > 1. Move jni_util.h out of jawt.h > 2. Christians concern over using a single variable name for Makefile and C/C++ logic. Thanks. Looks good to me. > > http://cr.openjdk.java.net/~bobv/8136556/webrev.01 <http://cr.openjdk.java.net/~bobv/8136556/webrev.01> > http://cr.openjdk.java.net/~bobv/8136556/hotspot/webrev.01 <http://cr.openjdk.java.net/~bobv/8136556/hotspot/webrev.01> > http://cr.openjdk.java.net/~bobv/8136556/jdk/webrev.01 <http://cr.openjdk.java.net/~bobv/8136556/jdk/webrev.01> > > Bob. > >> On Oct 16, 2015, at 2:28 AM, Alan Bateman <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>> wrote: >> >> On 15/10/2015 19:07, Bob Vandette wrote: >>> Please review this JDK 9 enhancement which allows a completely static build of the JDK for MacOSX x64 platforms. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8136556 <https://bugs.openjdk.java.net/browse/JDK-8136556> <https://bugs.openjdk.java.net/browse/JDK-8136556 <https://bugs.openjdk.java.net/browse/JDK-8136556>> >>> >>> The change involves: >>> >>> 1. Producing ?.a? archives for each native libraries. >>> 2. Ensuring that all symbols across the JDK native libraries are unique. >>> 3. Changing the JNI_OnLoad and JNI_OnUnload (and the Agent equivalents) to have the each library name appended per >>> the JNI specification. >>> 4. Modifications to the launcher and launcher Makefiles to allow them to be linked with the java.base and jdk.jdwp.agent libraries >>> and function. >>> >>> http://cr.openjdk.java.net/~bobv/8136556/webrev.00/ <http://cr.openjdk.java.net/~bobv/8136556/webrev.00/> <http://cr.openjdk.java.net/~bobv/8136556/webrev.00/ <http://cr.openjdk.java.net/~bobv/8136556/webrev.00/>> >>> http://cr.openjdk.java.net/~bobv/8136556/hotspot/webrev.00/ <http://cr.openjdk.java.net/~bobv/8136556/hotspot/webrev.00/> <http://cr.openjdk.java.net/~bobv/8136556/hotspot/webrev.00/ <http://cr.openjdk.java.net/~bobv/8136556/hotspot/webrev.00/>> >>> http://cr.openjdk.java.net/~bobv/8136556/jdk/webrev.00/ <http://cr.openjdk.java.net/~bobv/8136556/jdk/webrev.00/> <http://cr.openjdk.java.net/~bobv/8136556/jdk/webrev.00/ <http://cr.openjdk.java.net/~bobv/8136556/jdk/webrev.00/>> >>> >>> Note: This change does not link every possible static library with the launchers. It is currently limited to >>> the java.base and jdk.jdwp.agent libraries in order to allow for the TCK validation of the base module only. >>> >> I've skimmed through the patches and the DEF_* macros look okay. The only one that doesn't look right is jawt.h/jawt.c. As jawt.h is shipped by the JDK then I think the include of jni_util.h needs to move from jawt.h to jawt.c. >> >> If I read the changes correctly then not loading the JavaRuntimeSupport.framework on Mac means the locale might not be right, is that correct? Brent might remember this issue as we've often pondered the implications of this disappearing in an Mac update. >> >> Will there be continuous or at least regular builds setup so that build breakages will be reported in a timely manner? It would be easy to change something that breaks the static library build. >> >> -Alan > From joe.darcy at oracle.com Mon Oct 19 19:43:20 2015 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 19 Oct 2015 12:43:20 -0700 Subject: JDK 9 RFR of JDK-8139925 Problem list LFMultiThreadCachingTest.java on windows Message-ID: <562547D8.9010300@oracle.com> Hello, Please review the fix below to address JDK-8139925: Problem list LFMultiThreadCachingTest.java on windows The test in question, test/java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java suffers from a continuing low-frequency intermittent failure on windows due to JDK-8131129. Until the underlying problem is addressed, the test should be problem listed on the affected platforms, windows in this case. Thanks, -Joe diff -r 91fc3c3826e6 test/ProblemList.txt --- a/test/ProblemList.txt Thu Oct 15 14:41:37 2015 +0100 +++ b/test/ProblemList.txt Mon Oct 19 12:42:13 2015 -0700 @@ -133,6 +133,9 @@ # 8029891 java/lang/ClassLoader/deadlock/GetResource.java generic-all +# 8131129 +java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java windows-all + ############################################################################ # jdk_instrument From Roger.Riggs at Oracle.com Mon Oct 19 19:59:59 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 19 Oct 2015 15:59:59 -0400 Subject: JDK 9 RFR of JDK-8139925 Problem list LFMultiThreadCachingTest.java on windows In-Reply-To: <562547D8.9010300@oracle.com> References: <562547D8.9010300@oracle.com> Message-ID: <56254BBF.5090707@Oracle.com> +1 On 10/19/2015 3:43 PM, joe darcy wrote: > Hello, > > Please review the fix below to address > > JDK-8139925: Problem list LFMultiThreadCachingTest.java on windows > > The test in question, > > test/java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java > > suffers from a continuing low-frequency intermittent failure on > windows due to JDK-8131129. Until the underlying problem is > addressed, the test should be problem listed on the affected > platforms, windows in this case. > > Thanks, > > -Joe > > diff -r 91fc3c3826e6 test/ProblemList.txt > --- a/test/ProblemList.txt Thu Oct 15 14:41:37 2015 +0100 > +++ b/test/ProblemList.txt Mon Oct 19 12:42:13 2015 -0700 > @@ -133,6 +133,9 @@ > # 8029891 > java/lang/ClassLoader/deadlock/GetResource.java generic-all > > +# 8131129 > +java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java windows-all > + > ############################################################################ > > > # jdk_instrument > From chris.hegarty at oracle.com Mon Oct 19 20:36:25 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 19 Oct 2015 21:36:25 +0100 Subject: JDK 9 RFR of JDK-8139925 Problem list LFMultiThreadCachingTest.java on windows In-Reply-To: <562547D8.9010300@oracle.com> References: <562547D8.9010300@oracle.com> Message-ID: <1D55C9BC-85AE-4862-8313-B6DC1978B478@oracle.com> Looks fine Joe. -Chris. > On 19 Oct 2015, at 8:43 p.m., joe darcy <joe.darcy at oracle.com> wrote: > > Hello, > > Please review the fix below to address > > JDK-8139925: Problem list LFMultiThreadCachingTest.java on windows > > The test in question, > > test/java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java > > suffers from a continuing low-frequency intermittent failure on windows due to JDK-8131129. Until the underlying problem is addressed, the test should be problem listed on the affected platforms, windows in this case. > > Thanks, > > -Joe > > diff -r 91fc3c3826e6 test/ProblemList.txt > --- a/test/ProblemList.txt Thu Oct 15 14:41:37 2015 +0100 > +++ b/test/ProblemList.txt Mon Oct 19 12:42:13 2015 -0700 > @@ -133,6 +133,9 @@ > # 8029891 > java/lang/ClassLoader/deadlock/GetResource.java generic-all > > +# 8131129 > +java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java windows-all > + > ############################################################################ > > # jdk_instrument > From mandy.chung at oracle.com Tue Oct 20 07:10:38 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 20 Oct 2015 00:10:38 -0700 Subject: RFR: JDK-8046565: Platform Logger API and Service In-Reply-To: <56253412.4030800@oracle.com> References: <561660DA.7070900@oracle.com> <8D8890A3-2337-4178-BA5C-CC32DE12F27D@oracle.com> <561E3A9A.9050807@oracle.com> <6241BCF8-C6A3-4E64-94E9-5E70CEF4A829@oracle.com> <561E8CE7.9020609@oracle.com> <17C7339F-2107-49DE-B909-A65D779F0DF1@oracle.com> <56253412.4030800@oracle.com> Message-ID: <DA2E5F29-1DB4-483D-B80A-FE75D016A878@oracle.com> > On Oct 19, 2015, at 11:18 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote: > > webrev: > http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/webrev/index.html Looks good in general. Some minor comments: Good to see limited privileges being used that limits the permissions when invoking logger finder which is good. LoggerFinderLoader.java 110 (PrivilegedAction<ServiceLoader<DefaultLoggerFinder>>) - can this use diamond operation (PrivilegedAction<>)? System.java 1547 return LazyLoggers.getLogger(Objects.requireNonNull(name), caller); Objects.requireNonNull(name) - already called. It can just do getLogger(name, caller). RuntimePermission.java 360 * to JDK classes.</td> s/JDK/system/ LazyLoggers.java sun/management/ManagementFactoryHelper.java 172 public interface LoggingMXBean 173 extends PlatformLoggingMXBean, java.util.logging.LoggingMXBean { 174 } LazyLoggers.java 68 this(Objects.requireNonNull(loggerSupplier), 69 (Void)null); 130 this(Objects.requireNonNull(name), Objects.requireNonNull(factories), 131 Objects.requireNonNull(caller), null); I would expect Objects.requireNonNull on the constructor initializes all the fields. But the above lines checks non-null before calling this(?.). Does the other constructor allow null parameters? Why not moving Objects.requireNonNull to the other constructor? 365 new BiFunction<String, Class<?>, Logger>() { - it can use diamond operator BootstrapLogger.DetectBackend looks like have some duplication as LoggerFinderLoader. - does it make sense to merge them? 923 boolean cleared; - should that be volatile field? AbstractLoggerWrapper.java 212 if (sourceClass==null && sourceMethod==null) { 234 if (sourceClass==null && sourceMethod==null) { Missing space around ?==? and also in a few other lines. java.util.logging.LogManager.demandLoggerFor - I think this method is intended for the LoggerFinder provider to use. Perhaps we should add a note in the javadoc to say that. SimpleConsoleLogger.skipLoggingFrame and another place is finding the caller information. JEP 259 may be useful for stack walking with filtering. I skimmed through the tests and nothing pops up. There are multiple copies of AccessSystemLogger that can be shared as I comment last time. Mandy From masayoshi.okutsu at oracle.com Tue Oct 20 08:06:06 2015 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Tue, 20 Oct 2015 17:06:06 +0900 Subject: [9] RFR: 8072600: Unicode 8 support In-Reply-To: <5620F07D.8030109@oracle.com> References: <5620F07D.8030109@oracle.com> Message-ID: <5625F5EE.7020203@oracle.com> Looks good to me. Masayoshi On 10/16/2015 9:41 PM, Yuka Kamiya wrote: > Hello, > > Please review a small change for 8072600: Unicode 8 support. > Mainly date update from Unicode 7. > > JEP: http://openjdk.java.net/jeps/267 > Issue: https://bugs.openjdk.java.net/browse/JDK-8072600 > webrev: http://cr.openjdk.java.net/~peytoia/8072600/ > > Thanks, > -- > Yuka From blackdrag at gmx.org Tue Oct 20 08:17:34 2015 From: blackdrag at gmx.org (Jochen Theodorou) Date: Tue, 20 Oct 2015 10:17:34 +0200 Subject: JEP 276: Dynamic Linking of Language-Defined Object Models In-Reply-To: <F6045FDE-F3F1-4587-881F-169386C1EA27@oracle.com> References: <20151016173533.8325A7D532@eggemoggin.niobe.net> <CAP7YuATPogD2p+15VHCLgd2yQ_vJ2Ax_BpCzimKEnHTYYbpJrw@mail.gmail.com> <56235D06.5090109@gmx.org> <8B20E21F-36C4-41AA-B13A-6CB18389A236@oracle.com> <5624ADDD.5000507@gmx.org> <F6045FDE-F3F1-4587-881F-169386C1EA27@oracle.com> Message-ID: <5625F89E.6070000@gmx.org> On 19.10.2015 12:56, Attila Szegedi wrote: > On Oct 19, 2015, at 10:46 AM, Jochen Theodorou <blackdrag at gmx.org > <mailto:blackdrag at gmx.org>> wrote: > >> since it is dynalink there is I guess only one master linker in the >> end. Can you point me to some code showing how the composition of >> linkers is done to refresh my memory on that? > > Sure, here?s how Nashorn does it: > > http://hg.openjdk.java.net/jdk9/dev/nashorn/file/f93753325c7b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/Bootstrap.java#l92 > > You?ll notice that Nashorn has a total of 10 linkers - they?re > modularized per purpose. [...] interesting... I will take a closer look at those some time later this week So am I right in assuming that if for example there is the public nashorn linker and the linker from Groovy, that we simply go through the list of linkers (from a service based lookup I guess) and the first linker claiming to be able to link that gets to do it? bye Jochen From attila.szegedi at oracle.com Tue Oct 20 08:23:39 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 20 Oct 2015 10:23:39 +0200 Subject: JEP 276: Dynamic Linking of Language-Defined Object Models In-Reply-To: <5625F89E.6070000@gmx.org> References: <20151016173533.8325A7D532@eggemoggin.niobe.net> <CAP7YuATPogD2p+15VHCLgd2yQ_vJ2Ax_BpCzimKEnHTYYbpJrw@mail.gmail.com> <56235D06.5090109@gmx.org> <8B20E21F-36C4-41AA-B13A-6CB18389A236@oracle.com> <5624ADDD.5000507@gmx.org> <F6045FDE-F3F1-4587-881F-169386C1EA27@oracle.com> <5625F89E.6070000@gmx.org> Message-ID: <044950A1-E654-4F6C-86EC-C4C7C6CAB071@oracle.com> > On Oct 20, 2015, at 10:17 AM, Jochen Theodorou <blackdrag at gmx.org> wrote: > > On 19.10.2015 12:56, Attila Szegedi wrote: >> On Oct 19, 2015, at 10:46 AM, Jochen Theodorou <blackdrag at gmx.org >> <mailto:blackdrag at gmx.org>> wrote: >> >>> since it is dynalink there is I guess only one master linker in the >>> end. Can you point me to some code showing how the composition of >>> linkers is done to refresh my memory on that? >> >> Sure, here?s how Nashorn does it: >> >> http://hg.openjdk.java.net/jdk9/dev/nashorn/file/f93753325c7b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/Bootstrap.java#l92 >> >> You?ll notice that Nashorn has a total of 10 linkers - they?re >> modularized per purpose. > [...] > > interesting... I will take a closer look at those some time later this week > > So am I right in assuming that if for example there is the public nashorn linker and the linker from Groovy, that we simply go through the list of linkers (from a service based lookup I guess) and the first linker claiming to be able to link that gets to do it? Indeed. That?s exactly how it works :-) Additionally, if a linker claiming to be able to link it is asked to do it and it returns null instead of producing a linkage, then the next applicable will be consulted too. Therefore, TypeBasedGuardingDynamicLinker?s ?boolean canLinkType()? expresses a conditional ability to link (it?s ?likely can?, not ?always can?). Attila. > > bye Jochen > From daniel.fuchs at oracle.com Tue Oct 20 15:44:28 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 20 Oct 2015 17:44:28 +0200 Subject: RFR: JDK-8046565: Platform Logger API and Service In-Reply-To: <DA2E5F29-1DB4-483D-B80A-FE75D016A878@oracle.com> References: <561660DA.7070900@oracle.com> <8D8890A3-2337-4178-BA5C-CC32DE12F27D@oracle.com> <561E3A9A.9050807@oracle.com> <6241BCF8-C6A3-4E64-94E9-5E70CEF4A829@oracle.com> <561E8CE7.9020609@oracle.com> <17C7339F-2107-49DE-B909-A65D779F0DF1@oracle.com> <56253412.4030800@oracle.com> <DA2E5F29-1DB4-483D-B80A-FE75D016A878@oracle.com> Message-ID: <5626615C.5040208@oracle.com> Hi Mandy, All feedback integrated - except those discussed below. public URL content has been refreshed: http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/webrev/index.html http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/specdiff-api/overview-summary.html sandbox branch JDK-8046565-branch updated as well. Please find answers to some of the points you raised: On 20/10/15 09:10, Mandy Chung wrote: > >> On Oct 19, 2015, at 11:18 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote: >> >> webrev: >> http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/webrev/index.html [...] > LoggerFinderLoader.java > > 110 (PrivilegedAction<ServiceLoader<DefaultLoggerFinder>>) > > - can this use diamond operation (PrivilegedAction<>)? jdk/src/java.base/share/classes/jdk/internal/logger/LoggerFinderLoader.java:110: error: illegal start of type (PrivilegedAction<>) > sun/management/ManagementFactoryHelper.java > > 172 public interface LoggingMXBean > 173 extends PlatformLoggingMXBean, java.util.logging.LoggingMXBean { > 174 } Was there a comment related to that? This is a thorn that will prevent java.management from not requiring java.logging. We may be able to workaround it if we change java.management to use System.Logger directly - then we could perhaps revert the require clause and have java.logging requires javax.management instead (so that j.u.l.LoggingMXBean can extend j.l.PlatformLoggingMXBean) but I'm not sure we would be in a better situation. Or we could possibly move that to jdk.management. Maybe. Anyway - nothing we can do here - this will have to be examined later. > > LazyLoggers.java > 68 this(Objects.requireNonNull(loggerSupplier), > 69 (Void)null); > > 130 this(Objects.requireNonNull(name), Objects.requireNonNull(factories), > 131 Objects.requireNonNull(caller), null); > > I would expect Objects.requireNonNull on the constructor initializes all the fields. But the above lines checks non-null before calling this(?.). Does the other constructor allow null parameters? Why not moving Objects.requireNonNull to the other constructor? Just a way to throw the exception before the super constructor is called. The other constructor is private. When we reach it the check will already have been made. We could check again but for what purpose? > BootstrapLogger.DetectBackend looks like have some duplication as LoggerFinderLoader. > - does it make sense to merge them? I will consider it. I'd prefer not to. > 923 boolean cleared; > - should that be volatile field? No. It's accessed only within a synchronized block. > java.util.logging.LogManager.demandLoggerFor > - I think this method is intended for the LoggerFinder provider to use. Perhaps we should add a note in the javadoc to say that. Would you have something to suggest? I was thinking that this method could also provide a solution for JDK-8023163. > SimpleConsoleLogger.skipLoggingFrame and another place is finding the caller information. JEP 259 may be useful for stack walking with filtering. > > I skimmed through the tests and nothing pops up. There are multiple copies of AccessSystemLogger that can be shared as I comment last time. AccessSystemLogger is a trick to have a class in the BCL so that it gets a system logger as a platform class. I have a local workspace where I ported 8046565 to jake (not replacing 'Class<?> caller' with 'Module caller' yet to avoid merging issue while integrating review feedback), but last time I checked all these tests were passing on jake without modification. I know that we will have additional/different ways of unit testing unexported internal APIs with the module system, so I'd rather revisit that after the initial push. I can add a subtask to JDK-8046565 so that your input doesn't get forgotten. best regards, -- daniel > > Mandy > From Roger.Riggs at Oracle.com Tue Oct 20 17:08:56 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 20 Oct 2015 13:08:56 -0400 Subject: RFR:8134928:java.time.Instant.truncatedTo(TemporalUnit unit) is truncating up if the year < 1970 In-Reply-To: <562494D2.3090702@oracle.com> References: <561E260A.8050103@oracle.com> <CACzrW9Bzt64hHO=g8eECdteO75Zn7HYx_bWhWtvshsYa7EJwoQ@mail.gmail.com> <562494D2.3090702@oracle.com> Message-ID: <56267528.4050202@Oracle.com> Hi Nadeesh, Looks good, thanks for the extra test cases. I'll sponsor this for you a push it presently. Roger On 10/19/2015 2:59 AM, nadeesh tv wrote: > HI all, > Please review the updated webrev > http://cr.openjdk.java.net/~ntv/8134928/webrev.01/ > Regards, > Nadeesh > On 10/14/2015 4:06 PM, Stephen Colebourne wrote: >> I'd like to see an additional test case for the cases where rounding >> is *not* needed. Currently, there are only tests for where rounding is >> needed. It needs one more test line for after 1970 and one for before >> 1970. >> >> thanks >> Stephen >> >> >> On 14 October 2015 at 10:53, nadeesh tv <nadeesh.tv at oracle.com> wrote: >>> Hi all, >>> >>> Please review a fix for >>> https://bugs.openjdk.java.net/browse/JDK-8134928 >>> >>> Issue- java.time.Instant.truncatedTo(TemporalUnit unit) is >>> truncating up if >>> the year < 1970 >>> >>> BugId - https://bugs.openjdk.java.net/browse/JDK-8134928 >>> >>> webrev - http://cr.openjdk.java.net/~pchopra/8134928/webrev.01/ >>> >>> -- >>> Thanks and Regards, >>> Nadeesh TV >>> > From Roger.Riggs at Oracle.com Tue Oct 20 18:28:24 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 20 Oct 2015 14:28:24 -0400 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <561FCDB9.5080306@Oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> Message-ID: <562687C8.1040106@Oracle.com> Sorry for the silence, JavaOne preparations and the availability of folks who wanted to review have stretched things out. The Cleaner API was very simple and saw feature creep as the ideas for how it might be used were explored. There are concerns about committing to supporting subclassable CleanableReferences in all future JDK versions before there had been a chance to see how if they would be useful and necessary to address the need to reduce the use of finalization within the OpenJDK and beyond. Recent updates: - The Cleaner implementation classes and the CleanableReference abstract classes are now in the jdk.internal.misc package and are available within the java.base module. - The Cleanable.clear method has been dropped; there is no current use case. Since the CleanableReferences extend Reference, clear() is available when subclassing. - The tests have been extended to cover the exported and internal APIs The Runnable thunk version is very convenient to code but does transparently create an additional object to hold the bindings. As the Cleaner is applied to the various uses of finalize we'll see how they would be used and can re-evaluate the exported API needs. Updated Javadoc: http://cr.openjdk.java.net/~rriggs/cleaner-doc/ Updated Webrev: http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ Thanks, Roger From lance.andersen at oracle.com Tue Oct 20 20:19:21 2015 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 20 Oct 2015 16:19:21 -0400 Subject: RFR 8139056: Add convenience methods to Statement.java Message-ID: <DF22179F-7B18-445E-BD68-4CF9205851EF@oracle.com> Hi, Looking for a reviewer for http://cr.openjdk.java.net/~lancea/8139056/webrev.00/. This change Adds two convenience methods to Statement.java: - enquoteLiteral which returns a string enclosed in single quotes where all occurrences of a single quote are converted to two single quotes - enquoteIdentifier returns a SQL identifier The CCC has been approved. 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 Roger.Riggs at Oracle.com Tue Oct 20 21:33:24 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 20 Oct 2015 17:33:24 -0400 Subject: RFR 8139056: Add convenience methods to Statement.java In-Reply-To: <DF22179F-7B18-445E-BD68-4CF9205851EF@oracle.com> References: <DF22179F-7B18-445E-BD68-4CF9205851EF@oracle.com> Message-ID: <5626B324.4010606@Oracle.com> Hi Lance, The logic looks correct but enquoteLiteral is going to create an lot of garbage Strings, about one for every character. I'm not sure Streams are the right tool for this task. Can't String.replace("'", "''") do the same job? Roger On 10/20/2015 4:19 PM, Lance Andersen wrote: > Hi, > > Looking for a reviewer for http://cr.openjdk.java.net/~lancea/8139056/webrev.00/. > > This change Adds two convenience methods to Statement.java: > > - enquoteLiteral which returns a string enclosed in single quotes where all occurrences of a single quote are converted to two single quotes > > - enquoteIdentifier returns a SQL identifier > > > The CCC has been approved. > > 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 huizhe.wang at oracle.com Tue Oct 20 21:33:38 2015 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 20 Oct 2015 14:33:38 -0700 Subject: RFR 8139056: Add convenience methods to Statement.java In-Reply-To: <DF22179F-7B18-445E-BD68-4CF9205851EF@oracle.com> References: <DF22179F-7B18-445E-BD68-4CF9205851EF@oracle.com> Message-ID: <5626B332.4080502@oracle.com> Hi Lance, The change looks good. Noticed two minor things in StatementTests.java: A typo at 52 * Validate a NullPointerException is thrown is the string passed to. The 2nd "is" was meant to be "if" For test03, param "expected" may be not needed. Best, Joe On 10/20/2015 1:19 PM, Lance Andersen wrote: > Hi, > > Looking for a reviewer for http://cr.openjdk.java.net/~lancea/8139056/webrev.00/. > > This change Adds two convenience methods to Statement.java: > > - enquoteLiteral which returns a string enclosed in single quotes where all occurrences of a single quote are converted to two single quotes > > - enquoteIdentifier returns a SQL identifier > > > The CCC has been approved. > > 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 lance.andersen at oracle.com Tue Oct 20 21:44:04 2015 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 20 Oct 2015 17:44:04 -0400 Subject: RFR 8139056: Add convenience methods to Statement.java In-Reply-To: <5626B332.4080502@oracle.com> References: <DF22179F-7B18-445E-BD68-4CF9205851EF@oracle.com> <5626B332.4080502@oracle.com> Message-ID: <9FF6EE4F-AC22-4BB3-9C02-9133C6720F75@oracle.com> Hi Joe, On Oct 20, 2015, at 5:33 PM, Joe Wang <huizhe.wang at oracle.com> wrote: > Hi Lance, > > The change looks good. > > Noticed two minor things in StatementTests.java: > A typo at 52 * Validate a NullPointerException is thrown is the string passed to. The 2nd "is" was meant to be "if" Thanks for catching the typo. > > For test03, param "expected" may be not needed. I could probably remove it. I had left intentionally but will remove it. Best Lance > > Best, > Joe > > On 10/20/2015 1:19 PM, Lance Andersen wrote: >> Hi, >> >> Looking for a reviewer for http://cr.openjdk.java.net/~lancea/8139056/webrev.00/. >> >> This change Adds two convenience methods to Statement.java: >> - enquoteLiteral which returns a string enclosed in single quotes where all occurrences of a single quote are converted to two single quotes >> - enquoteIdentifier returns a SQL identifier >> >> >> The CCC has been approved. >> >> 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 >> >> >> > 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 daniel.fuchs at oracle.com Tue Oct 20 21:48:39 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 20 Oct 2015 23:48:39 +0200 Subject: RFR: JDK-8046565: Platform Logger API and Service In-Reply-To: <56253412.4030800@oracle.com> References: <561660DA.7070900@oracle.com> <8D8890A3-2337-4178-BA5C-CC32DE12F27D@oracle.com> <561E3A9A.9050807@oracle.com> <6241BCF8-C6A3-4E64-94E9-5E70CEF4A829@oracle.com> <561E8CE7.9020609@oracle.com> <17C7339F-2107-49DE-B909-A65D779F0DF1@oracle.com> <56253412.4030800@oracle.com> Message-ID: <5626B6B7.2040501@oracle.com> Hi Mandy, As we discussed I have also made LogManager.demandLoggerFor package protected. As a result I also reverted the changes to LoggingPermission - there's no reason for exposing a LoggingPermission("demandLogger", null) if LogManager.demandLoggerFor is no longer visible. I have refreshed the content of the links & the sandbox. specdiff: http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/specdiff-api/overview-summary.html webrev: http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/webrev/index.html sandbox: JDK-8046565-branch best regards, -- daniel On 19/10/15 20:18, Daniel Fuchs wrote: > Hi Mandy, > > I have updated the links with the modifications we discussed > last Friday: > > - I have removed the tag @apiNote from System.LoggerFinder > - I have relaxed the constraint of what happens if several > implementations of LoggerFinder are present - the specification > no longer mandate that ServiceConfigurationError is thrown, and > the implementation will simply take the first one returned > by the ServiceLoader. > - I have moved PlatformLoggerBridge and ConfigurableLoggerBridge > to be inner interfaces of PlatformLogger: > PlatformLoggerBridge => PlatformLogger.Bridge > ConfigurableLoggerBridge => PlatformLogger.ConfigurableBridge > (and fixed their class-level javadoc as well) > > I have pushed the changes to the sandbox (JDK-8046565-branch) > and updated the content of 'proto.02' (same link as before: > > specdiff: > http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/specdiff-api/overview-summary.html > > > webrev: > http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/webrev/index.html > > best regards, > > -- daniel > > On 14/10/15 22:57, Mandy Chung wrote: >> Addiitional comments: >> >> JdkLoggerProvider.java >> - should the GC?ed referent entries in the application SharedLoggers >> map be occasionally drained? >> >> BootstrapLogger.java >> In the BootstrapExecutors::join(Runnable r) method: >> try { >> getExecutor().submit(r).get(); >> } catch (InterruptedException | ExecutionException ex) { >> // should not happen >> ex.printStackTrace(System.err); >> } >> - we should avoid output any debugging code though. >> >> typos: >> indepedent >> temporarilly >> >> // Unfortunately, if we come to here it means we are in the bootsraping >> // phase where using lambdas is not safe yet - so we have to use a >> // a data object instead? >> FYI. jake has changed the system initialization sequence that allows >> the use of lambda early at startup. That may help in this case that >> you can revisit this in the future. >> >> This reminds me the startup performance. Is there any use >> System.Logger to log message during startup in JDK 9? Using lambda at >> startup will have impact to the startup performance. >> >> Also I?m curious to know the difference of classes loaded at startup >> if System.getLogger is called in one of the system class loaded during >> startup but no log message is output (as typical case is to print >> debugging message) with and without java.logging. >> >> // Not sure whether this is needed: it was in the original >> // PlatformLogger proxy code: >> - I don?t understand why sun.util.logger.LazyLoggers$JdkLazyLogger >> need to be loaded. DetectBackend is loaded only after booted (per the >> comment) >> >> Naming nit: >> PlatformLoggerBridge - would it be better to move to >> PlatformLogger.Bridge? It?s nit and I think it reads better and >> clearly associate with PlatformLogger. >> >> Mandy >> > From lance.andersen at oracle.com Tue Oct 20 21:49:06 2015 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 20 Oct 2015 17:49:06 -0400 Subject: RFR 8139056: Add convenience methods to Statement.java In-Reply-To: <5626B324.4010606@Oracle.com> References: <DF22179F-7B18-445E-BD68-4CF9205851EF@oracle.com> <5626B324.4010606@Oracle.com> Message-ID: <ACB3200B-20BF-43D8-A392-DF936D8637EE@oracle.com> Hi Roger, On Oct 20, 2015, at 5:33 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote: > Hi Lance, > > The logic looks correct but enquoteLiteral is going to create an lot of garbage Strings, > about one for every character. I'm not sure Streams are the right tool for this task. > > Can't String.replace("'", "''") do the same job? Yes, I could use replace, but talked myself into Streams :-) I can change it though for the initial push (after sending another webrev) Best Lance > > Roger > > > On 10/20/2015 4:19 PM, Lance Andersen wrote: >> Hi, >> >> Looking for a reviewer for http://cr.openjdk.java.net/~lancea/8139056/webrev.00/. >> >> This change Adds two convenience methods to Statement.java: >> - enquoteLiteral which returns a string enclosed in single quotes where all occurrences of a single quote are converted to two single quotes >> - enquoteIdentifier returns a SQL identifier >> >> >> The CCC has been approved. >> >> 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 >> >> >> > 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 Tue Oct 20 22:43:22 2015 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 20 Oct 2015 18:43:22 -0400 Subject: RFR 8139056: Add convenience methods to Statement.java In-Reply-To: <ACB3200B-20BF-43D8-A392-DF936D8637EE@oracle.com> References: <DF22179F-7B18-445E-BD68-4CF9205851EF@oracle.com> <5626B324.4010606@Oracle.com> <ACB3200B-20BF-43D8-A392-DF936D8637EE@oracle.com> Message-ID: <A07B2FC8-AA94-4CC8-86D8-4A49015B694D@oracle.com> Here is the revised webrev http://cr.openjdk.java.net/~lancea/8139056/webrev.01/ Addresses your and Joe's comments Best Lance On Oct 20, 2015, at 5:49 PM, Lance Andersen <lance.andersen at oracle.com> wrote: > Hi Roger, > On Oct 20, 2015, at 5:33 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote: > >> Hi Lance, >> >> The logic looks correct but enquoteLiteral is going to create an lot of garbage Strings, >> about one for every character. I'm not sure Streams are the right tool for this task. >> >> Can't String.replace("'", "''") do the same job? > > Yes, I could use replace, but talked myself into Streams :-) > > I can change it though for the initial push (after sending another webrev) > > Best > Lance >> >> Roger >> >> >> On 10/20/2015 4:19 PM, Lance Andersen wrote: >>> Hi, >>> >>> Looking for a reviewer for http://cr.openjdk.java.net/~lancea/8139056/webrev.00/. >>> >>> This change Adds two convenience methods to Statement.java: >>> - enquoteLiteral which returns a string enclosed in single quotes where all occurrences of a single quote are converted to two single quotes >>> - enquoteIdentifier returns a SQL identifier >>> >>> >>> The CCC has been approved. >>> >>> 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 >>> >>> >>> >> > > <oracle_sig_logo.gif> > > 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 huizhe.wang at oracle.com Tue Oct 20 22:52:18 2015 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 20 Oct 2015 15:52:18 -0700 Subject: RFR 8139056: Add convenience methods to Statement.java In-Reply-To: <A07B2FC8-AA94-4CC8-86D8-4A49015B694D@oracle.com> References: <DF22179F-7B18-445E-BD68-4CF9205851EF@oracle.com> <5626B324.4010606@Oracle.com> <ACB3200B-20BF-43D8-A392-DF936D8637EE@oracle.com> <A07B2FC8-AA94-4CC8-86D8-4A49015B694D@oracle.com> Message-ID: <5626C5A2.4060509@oracle.com> Looks good, Lance. Best, Joe On 10/20/2015 3:43 PM, Lance Andersen wrote: > Here is the revised webrev http://cr.openjdk.java.net/~lancea/8139056/webrev.01/ > > Addresses your and Joe's comments > > Best > Lance > On Oct 20, 2015, at 5:49 PM, Lance Andersen <lance.andersen at oracle.com> wrote: > >> Hi Roger, >> On Oct 20, 2015, at 5:33 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote: >> >>> Hi Lance, >>> >>> The logic looks correct but enquoteLiteral is going to create an lot of garbage Strings, >>> about one for every character. I'm not sure Streams are the right tool for this task. >>> >>> Can't String.replace("'", "''") do the same job? >> Yes, I could use replace, but talked myself into Streams :-) >> >> I can change it though for the initial push (after sending another webrev) >> >> Best >> Lance >>> Roger >>> >>> >>> On 10/20/2015 4:19 PM, Lance Andersen wrote: >>>> Hi, >>>> >>>> Looking for a reviewer for http://cr.openjdk.java.net/~lancea/8139056/webrev.00/. >>>> >>>> This change Adds two convenience methods to Statement.java: >>>> - enquoteLiteral which returns a string enclosed in single quotes where all occurrences of a single quote are converted to two single quotes >>>> - enquoteIdentifier returns a SQL identifier >>>> >>>> >>>> The CCC has been approved. >>>> >>>> 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 >>>> >>>> >>>> >> <oracle_sig_logo.gif> >> >> 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 steve.drach at oracle.com Wed Oct 21 00:16:15 2015 From: steve.drach at oracle.com (Steve Drach) Date: Tue, 20 Oct 2015 17:16:15 -0700 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <56207360.6040502@oracle.com> References: <F7C2BACE-2E86-4058-8136-F565799494F8@oracle.com> <561ED8BF.40901@oracle.com> <CC71DAAE-940B-47EB-A2F2-FFB89F2EBAD3@oracle.com> <561F16C1.6090702@oracle.com> <A8D7EE96-1238-401D-813D-E977CCD9E73F@oracle.com> <56207360.6040502@oracle.com> Message-ID: <F6F1FFD6-16F6-4AA6-A333-FDC549B17ED4@oracle.com> Hi, Let?s try again. I considered the issues brought up in the last review and was able to not only remove the versionedEntry altogether, I was able to greatly simplify the entire changeset. I removed all changes to JarEntry and JarVerifier, and added a name field and some simple methods to JarFileEntry. This solved a whole bunch of potential issues. I?m also creating the jar files used in the tests so there are no binaries in the changeset. One test, MultiReleaseJarURLConnection, has an error on windows because it can?t delete one of the created jar files. I don?t think I can do anything about it ? JDK-4823678 is a 12 year old bug that describes the problem. If anyone has an idea on what I can do to make this a clean test, please let me know. Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 <https://bugs.openjdk.java.net/browse/JDK-8132734> JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305 <https://bugs.openjdk.java.net/browse/JDK-8047305> Webrev: http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ <http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/> Thanks, Steve > On Oct 15, 2015, at 8:47 PM, Xueming Shen <xueming.shen at oracle.com> wrote: > > On 10/15/15 1:53 AM, Paul Sandoz wrote: >>> On 15 Oct 2015, at 05:00, Xueming Shen <xueming.shen at oracle.com> wrote: >>> >>> I'm not sure if it is a good idea, from performance perspective, to add a "versionEntry" field into the JarEntry >>> to support this feature, given most of the jar files might not be multi-release-jar aware, and the Jar input& >>> output streams dont work with a multi-release jar directly. Why should they all pay a runtime price for it. If >>> we really have to add an extra field, the JarFileEntry might be a better place, and it might be desired to >>> define a new subclass JarFileEntryMR to use when the MR is enabled, instead of adding directly into the existing >>> JarFileEntry. >>> >> According to jol there is currently space available due to alignment. If there was not it would add about 4% in direct instance size. But the actual footprint is likely to be chunkier because of the string character storage for the name so the % increase in size would be smaller e.g. perhaps on average < 2% which might be ok given that i presume such entries are unlikely to be cached. >> >> So i am not concerned about the size. If there was a way to design it to avoid modification of existing classes all the better, but i dunno if it is possible. Steve will surely know more. >> >> Paul. >> > > Let's try it from another angle:-) Based on the webrev, no one need to and actually does create a > JarEntry with a versionedEntry, except JarFile, and JarFile only creates its own version of JarEntry, > the JarFileEntry. > > The only non-JarFile consumer of "versioned" JarEntry is the package private JarVerifier.getCoderSigners, > and obviously it takes a JarFile together with the source JarEntry (again, if this jarEntry is not from A > JarFile, it should never have a "versionedEntry") > > So why do you want to put this field into the super class JarEntry, not the JarFileEntry, don't see any > benefit of doing that. > > While I'm writing this email, it appears to me that we might have a more "severe" issue with the > general/base JarEntry class to hold the link to the "versionedEntry". The "general" JarEntry object is > not associated with a specific JarFile (the JarFileEntry does). So there is no way for > JarFile.getInputStream(ZipFile ze) to verify that the JarEntry passed in and its "versionedEntry" is > actually belong to "this" JarFile in the following implementation, if the "ze" is just a JarEntry but > NOT instanceof of a JarFileEntry > > 759 public synchronized InputStream getInputStream(ZipEntry ze) > 760 throws IOException > 761 { > 762 maybeInstantiateVerifier(); > 763 > 764 if (ze instanceof JarEntry) { > 765 ZipEntry vze = ((JarEntry)ze).versionedEntry; > 766 if (vze != null) { > 767 return getInputStream(vze); > 768 } > 769 } > 770 > > I think it's a bug of the implementation if we don't check, as the "versioned entry" is really > associated to the jar file that creates it. Sure, as I said above, there is actually no way you can > create a general JarEntry or a JarFileEntry with a "versionedEntry" from "outside", but it appears > to be possible (have not tried, just in theory) to mess up the current mechanism by passing a > "jar entry" from one JarFile instance to another one, if two JarFile instances are open on the same > multi-release-jar, but with different "version setting" policy... > > But again, I still believe it might be a wrong approach to add such a "versionedEntry" into any of the > JarEntry, including the JarFileEntry. As specified by the specification, the returned entry should be the > jar entry pointing to the versioned entity in the Jar File, not the root one. The question I would like to > ask is why do you even need the "root entry" at all, if there is a matched versioned one. It might be > desired to have a mechanism to return the "base/root name" for such an entry, but it probably does > not deserve a "dedicate" entry object. > > -Sherman > >> >> > From roger.riggs at oracle.com Wed Oct 21 00:58:30 2015 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 20 Oct 2015 20:58:30 -0400 Subject: RFR 8139056: Add convenience methods to Statement.java Message-ID: <gic7si8uy1aliwvwlerf1vgs.1445389086370@email.android.com> Looks fine. Roger -------- Original message -------- From: Joe Wang <huizhe.wang at oracle.com> Date:10/20/2015 6:52 PM (GMT-05:00) To: Lance Andersen <lance.andersen at oracle.com>,Roger Riggs <Roger.Riggs at oracle.com> Cc: core-libs-dev at openjdk.java.net Subject: Re: RFR 8139056: Add convenience methods to Statement.java Looks good, Lance. Best, Joe On 10/20/2015 3:43 PM, Lance Andersen wrote: > Here is the revised webrev http://cr.openjdk.java.net/~lancea/8139056/webrev.01/ > > Addresses your and Joe's comments > > Best > Lance > On Oct 20, 2015, at 5:49 PM, Lance Andersen <lance.andersen at oracle.com> wrote: > >> Hi Roger, >> On Oct 20, 2015, at 5:33 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote: >> >>> Hi Lance, >>> >>> The logic looks correct but enquoteLiteral is going to create an lot of garbage Strings, >>> about one for every character. I'm not sure Streams are the right tool for this task. >>> >>> Can't String.replace("'", "''") do the same job? >> Yes, I could use replace, but talked myself into Streams :-) >> >> I can change it though for the initial push (after sending another webrev) >> >> Best >> Lance >>> Roger >>> >>> >>> On 10/20/2015 4:19 PM, Lance Andersen wrote: >>>> Hi, >>>> >>>> Looking for a reviewer for http://cr.openjdk.java.net/~lancea/8139056/webrev.00/. >>>> >>>> This change Adds two convenience methods to Statement.java: >>>> - enquoteLiteral which returns a string enclosed in single quotes where all occurrences of a single quote are converted to two single quotes >>>> - enquoteIdentifier returns a SQL identifier >>>> >>>> >>>> The CCC has been approved. >>>> >>>> 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 >>>> >>>> >>>> >> <oracle_sig_logo.gif> >> >> 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 xueming.shen at oracle.com Wed Oct 21 07:17:01 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 21 Oct 2015 00:17:01 -0700 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <F6F1FFD6-16F6-4AA6-A333-FDC549B17ED4@oracle.com> References: <F7C2BACE-2E86-4058-8136-F565799494F8@oracle.com> <561ED8BF.40901@oracle.com> <CC71DAAE-940B-47EB-A2F2-FFB89F2EBAD3@oracle.com> <561F16C1.6090702@oracle.com> <A8D7EE96-1238-401D-813D-E977CCD9E73F@oracle.com> <56207360.6040502@oracle.com> <F6F1FFD6-16F6-4AA6-A333-FDC549B17ED4@oracle.com> Message-ID: <56273BED.5080106@oracle.com> Hi Steve, The reifiedEntry() approach probably can help the default JarVerifier work as expected, but if I read the code correctly I doubt you can get the expected CodSigner[] and Certificatte[] result from a "versioned" JarFileEntry, after having read all bytes from the input stream (obtained via jzf.getInputStream(JarFileEntry)), as the JarEntry spec suggests,. As we are passing the "reified" entry into the VerifierStream alone, without any reference to the original jar file entry. It seems impossible for the original jar file entry can trace back to the corresponding certificates and code signers. This might be fixed by passing in the original entry together into the JarVerifier, but I doubt we might have a bigger issue here. I suspect with this approach an external verifier will have no easy way to verify the digit signature of the jar entry via java.security APIs. I would assume this is doable right now with current JarFile APIs, via a JarFile object, a Manifest and a target JarEntry. The external can get the signature via name -> manifest->attributes->signature (basically just consider to move the JarVerifier and couple sun.security.util classes out and use it as user code)... but with this implementation the name now is the root entry, but the bytes you can read from the stream is from the versioned one. We might want to bring in Max to take a look if what I said is really a supported use scenario. I might be wrong, not a security expert :-) Btw, for a "normal" JarEntry/ZipEntry (not a JarFileEntry), shouldn't the getInputStream(ze) simply return the stream for the root entry? The current implementation of getJarEntry(ze) does not seem right, as it returns a "versioned" JarFileEntry. I don't think you want to pass this one into VerifierStream directly, right? Again, I think it might be desired (at least the spec is not updated to say anything about "version") to simply return the input stream for the root entry. One more "nitpick". searchForVersionedEntry() now lookups the versioned candidate via super.getEntry() from version to BASE_VERSION, if the version is the latest version 9, the base is 0, we are basically doing this search for each non-versioned-entry inside this multi-release-jar file 9 times everytime when the entry is asked. In worse case scenario, a multi-release-jar, with huge number of entries with a small portion are versioned to 9, and you are iterating it via "entries". Each lookup might be cheap, but it might be worth considering adding some optimization. Best, Sherman On 10/20/2015 5:16 PM, Steve Drach wrote: > Hi, > > Let?s try again. I considered the issues brought up in the last > review and was able to not only remove the versionedEntry altogether, > I was able to greatly simplify the entire changeset. I removed all > changes to JarEntry and JarVerifier, and added a name field and some > simple methods to JarFileEntry. This solved a whole bunch of > potential issues. I?m also creating the jar files used in the tests so > there are no binaries in the changeset. One test, > MultiReleaseJarURLConnection, has an error on windows because it can?t > delete one of the created jar files. I don?t think I can do anything > about it ? JDK-4823678 is a 12 year old bug that describes the > problem. If anyone has an idea on what I can do to make this a clean > test, please let me know. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 > JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305 > Webrev: > http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ > <http://cr.openjdk.java.net/%7Epsandoz/multiversion-jar/jar-webrev/> > > Thanks, > Steve > >> On Oct 15, 2015, at 8:47 PM, Xueming Shen <xueming.shen at oracle.com >> <mailto:xueming.shen at oracle.com>> wrote: >> >> On 10/15/15 1:53 AM, Paul Sandoz wrote: >>>> On 15 Oct 2015, at 05:00, Xueming Shen <xueming.shen at oracle.com >>>> <mailto:xueming.shen at oracle.com>> wrote: >>>> >>>> I'm not sure if it is a good idea, from performance perspective, to >>>> add a "versionEntry" field into the JarEntry >>>> to support this feature, given most of the jar files might not be >>>> multi-release-jar aware, and the Jar input& >>>> output streams dont work with a multi-release jar directly. Why >>>> should they all pay a runtime price for it. If >>>> we really have to add an extra field, the JarFileEntry might be a >>>> better place, and it might be desired to >>>> define a new subclass JarFileEntryMR to use when the MR is enabled, >>>> instead of adding directly into the existing >>>> JarFileEntry. >>>> >>> According to jol there is currently space available due to >>> alignment. If there was not it would add about 4% in direct instance >>> size. But the actual footprint is likely to be chunkier because of >>> the string character storage for the name so the % increase in size >>> would be smaller e.g. perhaps on average < 2% which might be ok >>> given that i presume such entries are unlikely to be cached. >>> >>> So i am not concerned about the size. If there was a way to design >>> it to avoid modification of existing classes all the better, but i >>> dunno if it is possible. Steve will surely know more. >>> >>> Paul. >>> >> >> Let's try it from another angle:-) Based on the webrev, no one need >> to and actually does create a >> JarEntry with a versionedEntry, except JarFile, and JarFile only >> creates its own version of JarEntry, >> the JarFileEntry. >> >> The only non-JarFile consumer of "versioned" JarEntry is the package >> private JarVerifier.getCoderSigners, >> and obviously it takes a JarFile together with the source JarEntry >> (again, if this jarEntry is not from A >> JarFile, it should never have a "versionedEntry") >> >> So why do you want to put this field into the super class JarEntry, >> not the JarFileEntry, don't see any >> benefit of doing that. >> >> While I'm writing this email, it appears to me that we might have a >> more "severe" issue with the >> general/base JarEntry class to hold the link to the "versionedEntry". >> The "general" JarEntry object is >> not associated with a specific JarFile (the JarFileEntry does). So >> there is no way for >> JarFile.getInputStream(ZipFile ze) to verify that the JarEntry passed >> in and its "versionedEntry" is >> actually belong to "this" JarFile in the following implementation, if >> the "ze" is just a JarEntry but >> NOT instanceof of a JarFileEntry >> >> 759 public synchronized InputStream getInputStream(ZipEntry ze) >> 760 throws IOException >> 761 { >> 762 maybeInstantiateVerifier(); >> 763 >> 764 if (ze instanceof JarEntry) { >> 765 ZipEntry vze = ((JarEntry)ze).versionedEntry; >> 766 if (vze != null) { >> 767 return getInputStream(vze); >> 768 } >> 769 } >> 770 >> >> I think it's a bug of the implementation if we don't check, as the >> "versioned entry" is really >> associated to the jar file that creates it. Sure, as I said above, >> there is actually no way you can >> create a general JarEntry or a JarFileEntry with a "versionedEntry" >> from "outside", but it appears >> to be possible (have not tried, just in theory) to mess up the >> current mechanism by passing a >> "jar entry" from one JarFile instance to another one, if two JarFile >> instances are open on the same >> multi-release-jar, but with different "version setting" policy... >> >> But again, I still believe it might be a wrong approach to add such a >> "versionedEntry" into any of the >> JarEntry, including the JarFileEntry. As specified by the >> specification, the returned entry should be the >> jar entry pointing to the versioned entity in the Jar File, not the >> root one. The question I would like to >> ask is why do you even need the "root entry" at all, if there is a >> matched versioned one. It might be >> desired to have a mechanism to return the "base/root name" for such >> an entry, but it probably does >> not deserve a "dedicate" entry object. >> >> -Sherman >> >>> >>> >> > From weijun.wang at oracle.com Wed Oct 21 07:54:10 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 21 Oct 2015 15:54:10 +0800 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <56273BED.5080106@oracle.com> References: <F7C2BACE-2E86-4058-8136-F565799494F8@oracle.com> <561ED8BF.40901@oracle.com> <CC71DAAE-940B-47EB-A2F2-FFB89F2EBAD3@oracle.com> <561F16C1.6090702@oracle.com> <A8D7EE96-1238-401D-813D-E977CCD9E73F@oracle.com> <56207360.6040502@oracle.com> <F6F1FFD6-16F6-4AA6-A333-FDC549B17ED4@oracle.com> <56273BED.5080106@oracle.com> Message-ID: <46D77830-9F85-43A4-995A-4388E39FDFC5@oracle.com> > On Oct 21, 2015, at 3:17 PM, Xueming Shen <xueming.shen at oracle.com> wrote: > > We might want to bring in Max to take a look if what I said is really a supported use scenario. I haven't read Steve's latest code change. I will read if you think it's necessary. First, I think we agree that the multi-release jar file feature is only making use of the existing jar file format and does not intend to introduce any change to its specification. This means a JarFile signed by one JDK release should be verified by another JDK release. Ok, the next question is, should it modify the JarFile API? I hope not, because the JarFile API is the single entry we access a JarFile when we want to sign or verify it. I hope there is a brand new API for a multi-versioned jar file, probably a child class of JarFile, so that no matter you call getJarEntry() or entries() on it, you always get the versioned one and the unrelated ones are completely invisible. If this is not OK, maybe we can rename the current JarFile to RawJarFile and name the new API JarFile. Signing and verification will work on RawJarFile. Not sure if it's easy. --Max From peter.levart at gmail.com Wed Oct 21 08:02:29 2015 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 21 Oct 2015 10:02:29 +0200 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <562687C8.1040106@Oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> Message-ID: <56274695.8060503@gmail.com> Hi Roger, I think this is a good compromise. Having the low-level extended functionality in the JDK for internal use until it is proven. Dropping Cleanable.clear() is also a correct move. I currently don't see a use for it. If one registers a cleaning function, why would one then try to change his mind? It's better to decide upfront before registering. You could make final clear() in XxxCleanable classes throw UOE like it's done for get() in XxxCleanableRef. This way no Reference methods will be usefully accessible from Cleanable instance that is given to users and nobody will be tempted to cast it to Reference. Regards, Peter On 10/20/2015 08:28 PM, Roger Riggs wrote: > Sorry for the silence, JavaOne preparations and the availability of > folks who wanted > to review have stretched things out. > > The Cleaner API was very simple and saw feature creep as the ideas for > how it might be used > were explored. There are concerns about committing to supporting > subclassable > CleanableReferences in all future JDK versions before there had been a > chance to > see how if they would be useful and necessary to address the need to > reduce the > use of finalization within the OpenJDK and beyond. > > Recent updates: > - The Cleaner implementation classes and the CleanableReference > abstract classes are > now in the jdk.internal.misc package and are available within the > java.base module. > - The Cleanable.clear method has been dropped; there is no current > use case. > Since the CleanableReferences extend Reference, clear() is > available when subclassing. > - The tests have been extended to cover the exported and internal APIs > > The Runnable thunk version is very convenient to code but does > transparently create > an additional object to hold the bindings. > As the Cleaner is applied to the various uses of finalize we'll see > how they would be used > and can re-evaluate the exported API needs. > > Updated Javadoc: > http://cr.openjdk.java.net/~rriggs/cleaner-doc/ > > Updated Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > > Thanks, Roger > > > > From peter.levart at gmail.com Wed Oct 21 11:50:42 2015 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 21 Oct 2015 13:50:42 +0200 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <562687C8.1040106@Oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> Message-ID: <56277C12.6040509@gmail.com> Hi Roger, I think I have another race ;-) This time it is more theoretical than practical. If we take a look at say PhantomCleanable constructor: public PhantomCleanable(T referent, Cleaner cleaner) { super(Objects.requireNonNull(referent), getCleanerImpl(cleaner).queue); this.cleanerImpl = getCleanerImpl(cleaner); insert(); } ...somewhere in the getCleanerImpl(cleaner) method where 'cleaner' is last dereferenced and before assignment of extracted CleanerImpl to this.cleanerImpl, 'cleaner' is not needed any more. If it is not referenced from anywhere else in the program and JVM can prove it will not be used any more, JVM is free to declare it phantom reachable. The PhantomCleanable that is used to track the 'cleaner' can therefore be enqueued and the cleaner thread can process it, effectively emptying the 'phantomCleanableList' before this PhantomCleanable constructor insert()s itself into the 'phantomCleanableList'. The cleaner thread can therefore exit the loop and terminate prematurely. The fix would be to reverse the last two statements of the XxxCleanable constructor(s): public PhantomCleanable(T referent, Cleaner cleaner) { super(Objects.requireNonNull(referent), getCleanerImpl(cleaner).queue); insert(); this.cleanerImpl = getCleanerImpl(cleaner); } ... or to add a call to the (not yet in jdk9 but coming soon) reachabilityFence(): public PhantomCleanable(T referent, Cleaner cleaner) { super(Objects.requireNonNull(referent), getCleanerImpl(cleaner).queue); this.cleanerImpl = getCleanerImpl(cleaner); insert(); Reference.reachabilityFence(cleaner); } Regards, Peter On 10/20/2015 08:28 PM, Roger Riggs wrote: > Sorry for the silence, JavaOne preparations and the availability of > folks who wanted > to review have stretched things out. > > The Cleaner API was very simple and saw feature creep as the ideas for > how it might be used > were explored. There are concerns about committing to supporting > subclassable > CleanableReferences in all future JDK versions before there had been a > chance to > see how if they would be useful and necessary to address the need to > reduce the > use of finalization within the OpenJDK and beyond. > > Recent updates: > - The Cleaner implementation classes and the CleanableReference > abstract classes are > now in the jdk.internal.misc package and are available within the > java.base module. > - The Cleanable.clear method has been dropped; there is no current > use case. > Since the CleanableReferences extend Reference, clear() is > available when subclassing. > - The tests have been extended to cover the exported and internal APIs > > The Runnable thunk version is very convenient to code but does > transparently create > an additional object to hold the bindings. > As the Cleaner is applied to the various uses of finalize we'll see > how they would be used > and can re-evaluate the exported API needs. > > Updated Javadoc: > http://cr.openjdk.java.net/~rriggs/cleaner-doc/ > > Updated Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > > Thanks, Roger > > > > From peter.levart at gmail.com Wed Oct 21 12:13:52 2015 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 21 Oct 2015 14:13:52 +0200 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <56277C12.6040509@gmail.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <56277C12.6040509@gmail.com> Message-ID: <56278180.6020402@gmail.com> Not so fast, there's more... On 10/21/2015 01:50 PM, Peter Levart wrote: > Hi Roger, > > I think I have another race ;-) > > This time it is more theoretical than practical. If we take a look at > say PhantomCleanable constructor: > > public PhantomCleanable(T referent, Cleaner cleaner) { > super(Objects.requireNonNull(referent), > getCleanerImpl(cleaner).queue); > this.cleanerImpl = getCleanerImpl(cleaner); > insert(); > } > > ...somewhere in the getCleanerImpl(cleaner) method where 'cleaner' is > last dereferenced and before assignment of extracted CleanerImpl to > this.cleanerImpl, 'cleaner' is not needed any more. If it is not > referenced from anywhere else in the program and JVM can prove it will > not be used any more, JVM is free to declare it phantom reachable. The > PhantomCleanable that is used to track the 'cleaner' can therefore be > enqueued and the cleaner thread can process it, effectively emptying > the 'phantomCleanableList' before this PhantomCleanable constructor > insert()s itself into the 'phantomCleanableList'. The cleaner thread > can therefore exit the loop and terminate prematurely. > > The fix would be to reverse the last two statements of the > XxxCleanable constructor(s): > > public PhantomCleanable(T referent, Cleaner cleaner) { > super(Objects.requireNonNull(referent), > getCleanerImpl(cleaner).queue); > insert(); > this.cleanerImpl = getCleanerImpl(cleaner); > } > > ... or to add a call to the (not yet in jdk9 but coming soon) > reachabilityFence(): > > public PhantomCleanable(T referent, Cleaner cleaner) { > super(Objects.requireNonNull(referent), > getCleanerImpl(cleaner).queue); > this.cleanerImpl = getCleanerImpl(cleaner); > insert(); > Reference.reachabilityFence(cleaner); > } > ...similar race could be devised around the reachability of 'referent'. As soon as it is assigned to the Reference.referent field, it is not needed any more, so it can be declared (phantom|weakly|softly)-reachable by JVM before the XxxCleanable instance is insert()ed causing it to be attempted to be remove()d before it is insert()ed. The full fix therefore needs this: public PhantomCleanable(T referent, Cleaner cleaner) { super(Objects.requireNonNull(referent), getCleanerImpl(cleaner).queue); this.cleanerImpl = getCleanerImpl(cleaner); insert(); Reference.reachabilityFence(cleaner); Reference.reachabilityFence(referent); } Regards, Peter > > Regards, Peter > > On 10/20/2015 08:28 PM, Roger Riggs wrote: >> Sorry for the silence, JavaOne preparations and the availability of >> folks who wanted >> to review have stretched things out. >> >> The Cleaner API was very simple and saw feature creep as the ideas >> for how it might be used >> were explored. There are concerns about committing to supporting >> subclassable >> CleanableReferences in all future JDK versions before there had been >> a chance to >> see how if they would be useful and necessary to address the need to >> reduce the >> use of finalization within the OpenJDK and beyond. >> >> Recent updates: >> - The Cleaner implementation classes and the CleanableReference >> abstract classes are >> now in the jdk.internal.misc package and are available within the >> java.base module. >> - The Cleanable.clear method has been dropped; there is no current >> use case. >> Since the CleanableReferences extend Reference, clear() is >> available when subclassing. >> - The tests have been extended to cover the exported and internal APIs >> >> The Runnable thunk version is very convenient to code but does >> transparently create >> an additional object to hold the bindings. >> As the Cleaner is applied to the various uses of finalize we'll see >> how they would be used >> and can re-evaluate the exported API needs. >> >> Updated Javadoc: >> http://cr.openjdk.java.net/~rriggs/cleaner-doc/ >> >> Updated Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >> >> Thanks, Roger >> >> >> >> > From peter.levart at gmail.com Wed Oct 21 12:34:27 2015 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 21 Oct 2015 14:34:27 +0200 Subject: Is Reference.reachabilityFence() needed in Reference constructor? Message-ID: <56278653.9080501@gmail.com> Hi, I have a question about a use-case for Reference.reachabilityFence(). While reviewing code of new Cleaner API that is being proposed on core-libs-dev, the following java.lang.Reference constructor caught my eye: Reference(T referent, ReferenceQueue<? super T> queue) { this.referent = referent; this.queue = (queue == null) ? ReferenceQueue.NULL : queue; } Say it is being used like that: ReferenceQueue<Object> queue = ...; WeakReference<Object> wr = new WeakReference(new Object(), queue); Is it possible that the newly constructed Object is found weakly-reachable before the 'queue' is assigned to the Reference.queue field or is there something in the JVM that prevents this happening (like all the constructor parameters are reachable at least until the constructor is finished)? Might the following be needed or not: Reference(T referent, ReferenceQueue<? super T> queue) { this.referent = referent; this.queue = (queue == null) ? ReferenceQueue.NULL : queue; reachabilityFence(referent); } Regards, Peter From aph at redhat.com Wed Oct 21 13:28:09 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 21 Oct 2015 14:28:09 +0100 Subject: [concurrency-interest] Is Reference.reachabilityFence() needed in Reference constructor? In-Reply-To: <56278653.9080501@gmail.com> References: <56278653.9080501@gmail.com> Message-ID: <562792E9.8030201@redhat.com> On 10/21/2015 01:34 PM, Peter Levart wrote: > Is it possible that the newly constructed Object is found > weakly-reachable before the 'queue' is assigned to the Reference.queue > field or is there something in the JVM that prevents this happening > (like all the constructor parameters are reachable at least until the > constructor is finished)? No, there's nothing like that. I think you're right: from the point where the reference is assigned to the referent field of the WeakReference it is only reachable by traversing a weak reference, therefore it is weakly reachable. Adding the reachabilityFence would not hurt anything, and if it did make a difference to generated code it'd eliminate a bug. There may be a few more of these. Andrew. From Roger.Riggs at Oracle.com Wed Oct 21 13:35:51 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 21 Oct 2015 09:35:51 -0400 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <56274695.8060503@gmail.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <56274695.8060503@gmail.com> Message-ID: <562794B7.6030505@Oracle.com> Hi Peter, On 10/21/2015 4:02 AM, Peter Levart wrote: > Hi Roger, > > I think this is a good compromise. Having the low-level extended > functionality in the JDK for internal use until it is proven. Dropping > Cleanable.clear() is also a correct move. I currently don't see a use > for it. If one registers a cleaning function, why would one then try > to change his mind? It's better to decide upfront before registering. > You could make final clear() in XxxCleanable classes throw UOE like > it's done for get() in XxxCleanableRef. This way no Reference methods > will be usefully accessible from Cleanable instance that is given to > users and nobody will be tempted to cast it to Reference. The Reference.clear() function cannot be disabled completely. During a normal close of a resource the Cleanable.clean() is invoked and it needs to clear() the Reference. This eliminates the overhead on the Reference processing system when closes occur properly. We're currently investigating an application with 12 million finalizable References; that puts quite a load on gc. It is better to clear the references when the GC behavior is no long needed. About clear(); in the case you raised about coordinating cleanup between the subclass and superclass. One design is for the superclass to expose the Cleanable object it creates to the subclass. The subclass would register its own cleanup arranging to call the performCleanup of the super's Cleanable. It would also want to clear() the super's Cleanable so it never was invoked by the GC but still encapsulates the super's cleanup behavior. Thanks, Roger > > Regards, Peter > > > On 10/20/2015 08:28 PM, Roger Riggs wrote: >> Sorry for the silence, JavaOne preparations and the availability of >> folks who wanted >> to review have stretched things out. >> >> The Cleaner API was very simple and saw feature creep as the ideas >> for how it might be used >> were explored. There are concerns about committing to supporting >> subclassable >> CleanableReferences in all future JDK versions before there had been >> a chance to >> see how if they would be useful and necessary to address the need to >> reduce the >> use of finalization within the OpenJDK and beyond. >> >> Recent updates: >> - The Cleaner implementation classes and the CleanableReference >> abstract classes are >> now in the jdk.internal.misc package and are available within the >> java.base module. >> - The Cleanable.clear method has been dropped; there is no current >> use case. >> Since the CleanableReferences extend Reference, clear() is >> available when subclassing. >> - The tests have been extended to cover the exported and internal APIs >> >> The Runnable thunk version is very convenient to code but does >> transparently create >> an additional object to hold the bindings. >> As the Cleaner is applied to the various uses of finalize we'll see >> how they would be used >> and can re-evaluate the exported API needs. >> >> Updated Javadoc: >> http://cr.openjdk.java.net/~rriggs/cleaner-doc/ >> >> Updated Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >> >> Thanks, Roger >> >> >> >> > From Roger.Riggs at Oracle.com Wed Oct 21 13:38:34 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 21 Oct 2015 09:38:34 -0400 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <56278180.6020402@gmail.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <56277C12.6040509@gmail.com> <56278180.6020402@gmail.com> Message-ID: <5627955A.30706@Oracle.com> Hi Peter, I've always assumed that the arguments could not be gc'd at least until the method returns in part because the caller was holding references. But I suppose in a completely inlined case an optimizer might try to make more relaxed conclusions. Since the new object has not yet been published, the reachability of objects in a constructor must have some additional rules to keep objects alive until it is published. On 10/21/2015 8:13 AM, Peter Levart wrote: > Not so fast, there's more... > > On 10/21/2015 01:50 PM, Peter Levart wrote: >> Hi Roger, >> >> I think I have another race ;-) >> >> This time it is more theoretical than practical. If we take a look at >> say PhantomCleanable constructor: >> >> public PhantomCleanable(T referent, Cleaner cleaner) { >> super(Objects.requireNonNull(referent), >> getCleanerImpl(cleaner).queue); >> this.cleanerImpl = getCleanerImpl(cleaner); >> insert(); >> } >> >> ...somewhere in the getCleanerImpl(cleaner) method where 'cleaner' is >> last dereferenced and before assignment of extracted CleanerImpl to >> this.cleanerImpl, 'cleaner' is not needed any more. If it is not >> referenced from anywhere else in the program and JVM can prove it >> will not be used any more, JVM is free to declare it phantom >> reachable. The PhantomCleanable that is used to track the 'cleaner' >> can therefore be enqueued and the cleaner thread can process it, >> effectively emptying the 'phantomCleanableList' before this >> PhantomCleanable constructor insert()s itself into the >> 'phantomCleanableList'. The cleaner thread can therefore exit the >> loop and terminate prematurely. >> >> The fix would be to reverse the last two statements of the >> XxxCleanable constructor(s): >> >> public PhantomCleanable(T referent, Cleaner cleaner) { >> super(Objects.requireNonNull(referent), >> getCleanerImpl(cleaner).queue); >> insert(); >> this.cleanerImpl = getCleanerImpl(cleaner); Except that insert() uses cleanerImpl to know what list to insert it in. (It could be passed as an argument; if the concern about the Cleaner becoming phantomReachable at that moment was valid) >> } >> >> ... or to add a call to the (not yet in jdk9 but coming soon) >> reachabilityFence(): >> >> public PhantomCleanable(T referent, Cleaner cleaner) { >> super(Objects.requireNonNull(referent), >> getCleanerImpl(cleaner).queue); >> this.cleanerImpl = getCleanerImpl(cleaner); >> insert(); >> Reference.reachabilityFence(cleaner); >> } >> > > ...similar race could be devised around the reachability of > 'referent'. As soon as it is assigned to the Reference.referent field, > it is not needed any more, so it can be declared > (phantom|weakly|softly)-reachable by JVM before the XxxCleanable > instance is insert()ed causing it to be attempted to be remove()d > before it is insert()ed. The full fix therefore needs this: > > public PhantomCleanable(T referent, Cleaner cleaner) { > super(Objects.requireNonNull(referent), > getCleanerImpl(cleaner).queue); > this.cleanerImpl = getCleanerImpl(cleaner); > insert(); > Reference.reachabilityFence(cleaner); > Reference.reachabilityFence(referent); > } > Someone more familiar with the constructor/gc interactions might need to weigh in on this. There must be some accommodation or lots of existing code in constructors would be/have broken. Thanks, Roger > > Regards, Peter > >> >> Regards, Peter >> >> On 10/20/2015 08:28 PM, Roger Riggs wrote: >>> Sorry for the silence, JavaOne preparations and the availability of >>> folks who wanted >>> to review have stretched things out. >>> >>> The Cleaner API was very simple and saw feature creep as the ideas >>> for how it might be used >>> were explored. There are concerns about committing to supporting >>> subclassable >>> CleanableReferences in all future JDK versions before there had been >>> a chance to >>> see how if they would be useful and necessary to address the need to >>> reduce the >>> use of finalization within the OpenJDK and beyond. >>> >>> Recent updates: >>> - The Cleaner implementation classes and the CleanableReference >>> abstract classes are >>> now in the jdk.internal.misc package and are available within the >>> java.base module. >>> - The Cleanable.clear method has been dropped; there is no current >>> use case. >>> Since the CleanableReferences extend Reference, clear() is >>> available when subclassing. >>> - The tests have been extended to cover the exported and internal APIs >>> >>> The Runnable thunk version is very convenient to code but does >>> transparently create >>> an additional object to hold the bindings. >>> As the Cleaner is applied to the various uses of finalize we'll see >>> how they would be used >>> and can re-evaluate the exported API needs. >>> >>> Updated Javadoc: >>> http://cr.openjdk.java.net/~rriggs/cleaner-doc/ >>> >>> Updated Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>> >>> Thanks, Roger >>> >>> >>> >>> >> > From kumar.x.srinivasan at oracle.com Wed Oct 21 13:42:59 2015 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 21 Oct 2015 06:42:59 -0700 Subject: RFR: 8066272: pack200 must support Multi-Release Jars Message-ID: <56279663.70308@oracle.com> Hi John, Steve, Please review a fix for bug: https://bugs.openjdk.java.net/browse/JDK-8066272 The webrev: http://cr.openjdk.java.net/~ksrini/8066272/webrev.0/ To support Multi versioned jar files all versioned class files in the META-INF directory will be excluded from the global constant pool, instead these will be regarded as resources and stored in the resource specific bands. Thanks Kumar From daniel.fuchs at oracle.com Wed Oct 21 13:58:18 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 21 Oct 2015 15:58:18 +0200 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5627955A.30706@Oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <56277C12.6040509@gmail.com> <56278180.6020402@gmail.com> <5627955A.30706@Oracle.com> Message-ID: <562799FA.5060702@oracle.com> Hi Roger, Peter, On 21/10/15 15:38, Roger Riggs wrote: > Hi Peter, > > I've always assumed that the arguments could not be gc'd at least until > the method returns > in part because the caller was holding references. But I suppose in a > completely inlined > case an optimizer might try to make more relaxed conclusions. > > Since the new object has not yet been published, the reachability of > objects in a constructor > must have some additional rules to keep objects alive until it is > published. I've recently been bitten by a test that did the rough equivalent of this: Object o = new Object(); ReferenceQueue<Object> queue = new ReferenceQueue<>(); WeakReference<Object> ref = new WeakReference(o, queue); o = null; System.gc(); WeakReference<?> wr = queue.remove(); The issue was that the reference 'ref' was sometime eagerly garbage collected before 'o', and the call to queue.remove() sometimes never returned. I should have known (because it had happened to me before) but these kind of issues are quite easy to miss, and have a propensity to wait for some weeks after integration before making themselves known... I do hope that method parameters are not eagerly gc'ed before the method returns - that would be yet another thing to easily miss :-( best regards, -- daniel From aph at redhat.com Wed Oct 21 14:45:31 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 21 Oct 2015 15:45:31 +0100 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <562799FA.5060702@oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <56277C12.6040509@gmail.com> <56278180.6020402@gmail.com> <5627955A.30706@Oracle.com> <562799FA.5060702@oracle.com> Message-ID: <5627A50B.6020206@redhat.com> On 10/21/2015 02:58 PM, Daniel Fuchs wrote: > I do hope that method parameters are not eagerly gc'ed before > the method returns They are -- that's what reachabilityFence() is for. I don't think that constructors have any special rules, and nor should they. Andrew. From Roger.Riggs at Oracle.com Wed Oct 21 14:52:09 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 21 Oct 2015 10:52:09 -0400 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5627A50B.6020206@redhat.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <56277C12.6040509@gmail.com> <56278180.6020402@gmail.com> <5627955A.30706@Oracle.com> <562799FA.5060702@oracle.com> <5627A50B.6020206@redhat.com> Message-ID: <5627A699.102@Oracle.com> Hi Andrew, So then is is correct to conclude that the gc does examine fields in instances still being constructed to determine reachability? How is that we have gone so long without needing reachabilityFence? Or is it just because optimizers have taken so long to get a perfect view of reference scope? Thanks, Roger On 10/21/2015 10:45 AM, Andrew Haley wrote: > On 10/21/2015 02:58 PM, Daniel Fuchs wrote: >> I do hope that method parameters are not eagerly gc'ed before >> the method returns > They are -- that's what reachabilityFence() is for. I don't think > that constructors have any special rules, and nor should they. > > Andrew. From vitalyd at gmail.com Wed Oct 21 15:08:44 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 21 Oct 2015 11:08:44 -0400 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5627A699.102@Oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <56277C12.6040509@gmail.com> <56278180.6020402@gmail.com> <5627955A.30706@Oracle.com> <562799FA.5060702@oracle.com> <5627A50B.6020206@redhat.com> <5627A699.102@Oracle.com> Message-ID: <CAHjP37FCROGPzLK45ouhvPe40paSAQ=SOYLM9uJfwY2iMAdQ3g@mail.gmail.com> I think this issue is specific to References since they're not treated as strong roots by GC and therefore do not participate in strong reachability graphs. On Wed, Oct 21, 2015 at 10:52 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote: > Hi Andrew, > > So then is is correct to conclude that the gc does examine fields in > instances > still being constructed to determine reachability? > > How is that we have gone so long without needing reachabilityFence? > Or is it just because optimizers have taken so long to get a perfect view > of reference scope? > > Thanks, Roger > > > > On 10/21/2015 10:45 AM, Andrew Haley wrote: > >> On 10/21/2015 02:58 PM, Daniel Fuchs wrote: >> >>> I do hope that method parameters are not eagerly gc'ed before >>> the method returns >>> >> They are -- that's what reachabilityFence() is for. I don't think >> that constructors have any special rules, and nor should they. >> >> Andrew. >> > > From aph at redhat.com Wed Oct 21 15:36:08 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 21 Oct 2015 16:36:08 +0100 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5627A699.102@Oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <56277C12.6040509@gmail.com> <56278180.6020402@gmail.com> <5627955A.30706@Oracle.com> <562799FA.5060702@oracle.com> <5627A50B.6020206@redhat.com> <5627A699.102@Oracle.com> Message-ID: <5627B0E8.1030009@redhat.com> On 10/21/2015 03:52 PM, Roger Riggs wrote: > So then is is correct to conclude that the gc does examine fields in > instances > still being constructed to determine reachability? Oh sure, it has to. The issue here is that the object being constructed is a weak reference, and therefore its referent is weakly reachable. If it were any other kind of object it'd be OK. > How is that we have gone so long without needing reachabilityFence? There have been objects finalized early on some systems, particularly J9 which for some reason finalizes objects much more quickly than HotSpot does. > Or is it just because optimizers have taken so long to get a perfect > view of reference scope? That too. Andrew. From aleksey.shipilev at oracle.com Wed Oct 21 15:44:36 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 21 Oct 2015 18:44:36 +0300 Subject: [concurrency-interest] Is Reference.reachabilityFence() needed in Reference constructor? In-Reply-To: <56278653.9080501@gmail.com> References: <56278653.9080501@gmail.com> Message-ID: <5627B2E4.205@oracle.com> Hi, On 10/21/2015 03:34 PM, Peter Levart wrote: > Say it is being used like that: > > ReferenceQueue<Object> queue = ...; > > WeakReference<Object> wr = new WeakReference(new Object(), queue); > > Is it possible that the newly constructed Object is found > weakly-reachable before the 'queue' is assigned to the Reference.queue > field or is there something in the JVM that prevents this happening > (like all the constructor parameters are reachable at least until the > constructor is finished)? I think this is largely dependent on VM implementation. IIRC, Hotspot does not treat constructors differently from regular methods w.r.t. reachability analysis. But, I suppose when you are storing the incoming argument in the instance field, then a story gets simpler, since you now "switch" the reachability via the argument (which is obviously alive up to the last use) for the reachability via $this itself. The Reference case is a bit special here. If we were to store the referent in the "ordinary" instance, then we are changing one strong ref for another strong one. But for Reference, we are changing strong ref for a weak ref, and so we need to make sure there is a strong ref until the end of the method, with reachabilityFence. In other words, this seems to be needed, but only for Reference.referent: > Might the following be needed or not: > > Reference(T referent, ReferenceQueue<? super T> queue) { > this.referent = referent; > this.queue = (queue == null) ? ReferenceQueue.NULL : queue; > reachabilityFence(referent); > } Of course, this does not tell another (scary) part of the story, what if the Reference itself is not discovered as strong ref by GC, e.g. when it isn't published on heap, or scalarized by compiler, etc. reachabilityFence, as currently implemented, extends the "liveness" scope of the local variable, but does not convey anything special to the GC/runtime otherwise. Thanks, -Aleksey P.S. Tried to reproduce the failure in jcstress case to no avail. Maybe somebody else is more lucky: @JCStressTest @Outcome(id = "[true]", expect = Expect.ACCEPTABLE, desc = "TBD") @State public class ReferenceNew { final ReferenceQueue<Object> refq = new ReferenceQueue<>(); WeakReference<Object> wr; @Actor public void producer() { wr = new WeakReference<>(new Object(), refq); } @Actor public void consumer(BooleanResult1 r) { try { for (int c = 0; c < 10; c++) { Reference<?> ref = refq.remove(100); if (ref != null) { r.r1 = true; return; } } r.r1 = false; } catch (Throwable e) { r.r1 = false; } } static { Executors.newScheduledThreadPool(1, r -> { Thread t = new Thread(r); t.setDaemon(true); return t; }).scheduleAtFixedRate( System::gc, 10L, 10L, TimeUnit.MILLISECONDS ); } } From aph at redhat.com Wed Oct 21 15:53:38 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 21 Oct 2015 16:53:38 +0100 Subject: [concurrency-interest] Is Reference.reachabilityFence() needed in Reference constructor? In-Reply-To: <5627B2E4.205@oracle.com> References: <56278653.9080501@gmail.com> <5627B2E4.205@oracle.com> Message-ID: <5627B502.2010007@redhat.com> On 10/21/2015 04:44 PM, Aleksey Shipilev wrote: > Of course, this does not tell another (scary) part of the story, what if > the Reference itself is not discovered as strong ref by GC, e.g. when it > isn't published on heap, or scalarized by compiler, etc. > reachabilityFence, as currently implemented, extends the "liveness" > scope of the local variable, but does not convey anything special to the > GC/runtime otherwise. If the Reference itself is not reachable from a strong root then the Reference is dead so we don't care what happens to it. But if the Reference is put on a reachable ReferenceQueue, then it's fine. Andrew. From miroslav.kos at oracle.com Wed Oct 21 16:42:14 2015 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Wed, 21 Oct 2015 18:42:14 +0200 Subject: [9] RFR: 8139743 regular JAX-* sync-up from standalone repos In-Reply-To: <7035006E-A338-4D23-B185-EC841E309988@oracle.com> References: <56211448.4040504@oracle.com> <073C6E0E-87EB-408D-813E-E0E325B4DC40@oracle.com> <56211C98.3040905@oracle.com> <7035006E-A338-4D23-B185-EC841E309988@oracle.com> Message-ID: <5627C066.3040306@oracle.com> Hi Lance, yes, it makes sense - after creating it and reviewing I fixed additional issues - please, check new version of a patch: http://cr.openjdk.java.net/~mkos/8139743/jaxws.02/ http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/ Thanks Miran On 16/10/15 18:12, Lance Andersen wrote: > Hi Miran > > On Oct 16, 2015, at 11:49 AM, Miroslav Kos <miroslav.kos at oracle.com > <mailto:miroslav.kos at oracle.com>> wrote: > >> Hi Lance, >> the javadoc fixes are just about formal issues (<tt>...</tt> for >> {@code .. }, broken links etc.) - there are no other changes. > > Understand, but the specdiff makes it easier to see that there are no > untended changes especially with the size. > > Best > Lance >> >> Thanks >> Miran >> >> >> On 16/10/15 17:26, Lance Andersen wrote: >>> Hi Miran >>> >>> Can you please provide a specdiff as that makes it easier for >>> javadoc review >>> >>> Best >>> Lance >>> On Oct 16, 2015, at 11:14 AM, Miroslav Kos <miroslav.kos at oracle.com> >>> wrote: >>> >>>> Hi, >>>> there is a bulk update of JAX-B/WS from upstream projects - >>>> webrev: http://cr.openjdk.java.net/~mkos/8139743/jaxws.01/ >>>> <http://cr.openjdk.java.net/%7Emkos/8139743/jaxws.01/> >>>> more details in issue desc: >>>> https://bugs.openjdk.java.net/browse/JDK-8139743 >>>> >>>> Could I ask for a review? >>>> >>>> It's quite big (2570 lines changed): >>>> * many javadoc fixes >>>> * some performance and other fixes for SAAJ >>>> * findbugs issues >>>> >>>> There are issue list in the JBS, many of listed bugs were fixed in >>>> JDK already (they are on the list because of backporting to standalone) >>>> >>>> Thanks >>>> Miran >>>> >>> >>> <Mail Attachment.gif> >>> <http://oracle.com/us/design/oracle-email-sig-198324.gif> >>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif> >>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com> >>> >>> >>> >> > > <http://oracle.com/us/design/oracle-email-sig-198324.gif> > <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif> > <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com> > > > From mandy.chung at oracle.com Wed Oct 21 17:08:40 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 21 Oct 2015 10:08:40 -0700 Subject: RFR: JDK-8046565: Platform Logger API and Service In-Reply-To: <5626615C.5040208@oracle.com> References: <561660DA.7070900@oracle.com> <8D8890A3-2337-4178-BA5C-CC32DE12F27D@oracle.com> <561E3A9A.9050807@oracle.com> <6241BCF8-C6A3-4E64-94E9-5E70CEF4A829@oracle.com> <561E8CE7.9020609@oracle.com> <17C7339F-2107-49DE-B909-A65D779F0DF1@oracle.com> <56253412.4030800@oracle.com> <DA2E5F29-1DB4-483D-B80A-FE75D016A878@oracle.com> <5626615C.5040208@oracle.com> Message-ID: <09D0C937-F38F-404B-923C-DCEC07239B20@oracle.com> > On Oct 20, 2015, at 8:44 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote: > > Hi Mandy, > > All feedback integrated - except those discussed below. Thanks. > > public URL content has been refreshed: > http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/webrev/index.html > http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/specdiff-api/overview-summary.html > > sandbox branch JDK-8046565-branch updated as well. > : > >> sun/management/ManagementFactoryHelper.java >> >> 172 public interface LoggingMXBean >> 173 extends PlatformLoggingMXBean, java.util.logging.LoggingMXBean { >> 174 } > > Was there a comment related to that? This is a thorn that will prevent > java.management from not requiring java.logging. > Sorry I missed to go back and include my comment. The main thing I wanted to point out is that java.management will always require java.logging because the above interface. Just a note to you that the Class.forName call to find if java.util.logging.Logging class is present isn?t strictly necessary. It?s okay to keep it there to prepare if such dependency can be eliminated. I have filed JDK-8139982 to follow-up this dependency (this is unrelated to your change) > >> >> LazyLoggers.java >> 68 this(Objects.requireNonNull(loggerSupplier), >> 69 (Void)null); >> >> 130 this(Objects.requireNonNull(name), Objects.requireNonNull(factories), >> 131 Objects.requireNonNull(caller), null); >> >> I would expect Objects.requireNonNull on the constructor initializes all the fields. But the above lines checks non-null before calling this(?.). Does the other constructor allow null parameters? Why not moving Objects.requireNonNull to the other constructor? > > Just a way to throw the exception before the super constructor > is called. > The other constructor is private. When we reach it the check > will already have been made. We could check again but for what purpose? My suggestion was to do the check for non-null in the other constructor (not to duplicate the check). Since they are private, it?s okay. > > >> java.util.logging.LogManager.demandLoggerFor >> - I think this method is intended for the LoggerFinder provider to use. Perhaps we should add a note in the javadoc to say that. > > Would you have something to suggest? > I was thinking that this method could also provide a > solution for JDK-8023163. As we discussed offline and you already made the change, this is not needed to be public for this JEP. Thanks Mandy From aleksey.shipilev at oracle.com Wed Oct 21 17:08:38 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 21 Oct 2015 20:08:38 +0300 Subject: [concurrency-interest] Is Reference.reachabilityFence() needed in Reference constructor? In-Reply-To: <5627B502.2010007@redhat.com> References: <56278653.9080501@gmail.com> <5627B2E4.205@oracle.com> <5627B502.2010007@redhat.com> Message-ID: <5627C696.1070806@oracle.com> On 10/21/2015 06:53 PM, Andrew Haley wrote: > On 10/21/2015 04:44 PM, Aleksey Shipilev wrote: >> Of course, this does not tell another (scary) part of the story, what if >> the Reference itself is not discovered as strong ref by GC, e.g. when it >> isn't published on heap, or scalarized by compiler, etc. >> reachabilityFence, as currently implemented, extends the "liveness" >> scope of the local variable, but does not convey anything special to the >> GC/runtime otherwise. > > If the Reference itself is not reachable from a strong root then the > Reference is dead so we don't care what happens to it. But if the > Reference is put on a reachable ReferenceQueue, then it's fine. Yes, if runtime stripes that instance before it is exposed anywhere (e.g. scalarizes the weakref), or those references are dead (e.g. the weakref is buried somewhere deep in garbage subgraph, and purged on sweep), then everything goes awry. But the thing is, a WeakReference is put on ReferenceQueue by the GC itself. In the object graph, ReferenceQueue does not normally reference weakrefs back. Before enqueueing the reference GC has to first discover that WeakReference -- but from where? In other words, "registering" on a reachable RefQueue does not make weakref to be reachable. Case in point: public class WhereIsWaldo { public static void main(String... args) throws Exception { for (int c = 0; true; c++) { new WhereIsWaldo().work(c); } } final ReferenceQueue<Object> rq = new ReferenceQueue<>(); void work(int id) throws Exception { hideWaldo(id); findWaldo(id); } WeakReference<Object> gwr; void hideWaldo(int id) { // Does not work, d'uh new WeakReference<>(new Object(), rq); // Does not work either :( WeakReference<Object> wr = new WeakReference<>(new Object(), rq); // This also does not help... once you leave the method, // the weakref is gone. Reference.reachabilityFence(wr); // This one helps, makes Waldo reachable // gwr = wr; } void findWaldo(int id) throws Exception { while (Thread.currentThread().isAlive()) { System.gc(); Reference ref = rq.remove(1000); if (ref != null) { return; } else { System.out.println("Where's Waldo #" + id + "?"); } } } } Thanks, -Aleksey From Mohammad.Rezaei at gs.com Wed Oct 21 17:10:03 2015 From: Mohammad.Rezaei at gs.com (Rezaei, Mohammad A.) Date: Wed, 21 Oct 2015 13:10:03 -0400 Subject: [concurrency-interest] Is Reference.reachabilityFence() needed in Reference constructor? In-Reply-To: <5627B2E4.205@oracle.com> References: <56278653.9080501@gmail.com> <5627B2E4.205@oracle.com> Message-ID: <6882C9A35DFB9B4FA2779F7BF5B9757D2084F9606A@GSCMAMP06EX.firmwide.corp.gs.com> >> Might the following be needed or not: >> >> Reference(T referent, ReferenceQueue<? super T> queue) { >> this.referent = referent; >> this.queue = (queue == null) ? ReferenceQueue.NULL : queue; >> reachabilityFence(referent); >> } > queue is marked volatile, so a simple reordering of the lines should be just as effective: Reference(T referent, ReferenceQueue<? super T> queue) { this.queue = (queue == null) ? ReferenceQueue.NULL : queue; this.referent = referent; } A simplistic interpretation of GC (as for example seen here: http://stackoverflow.com/questions/10795505/how-do-garbage-collectors-know-about-references-on-the-stack-frame ) might lead one to believe that referent is reachable until the end of the constructor because it's in the stack frame. The point at which reachability analysis kicks in, in the middle of such a simple two liner and removes the referent from the stack (or other variations such as inlining) is presumably highly implementation dependent and should not be relied on, but I'm guessing that's the reason you're not able to reproduce an early GC. Thanks Moh From vitalyd at gmail.com Wed Oct 21 17:18:08 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 21 Oct 2015 13:18:08 -0400 Subject: [concurrency-interest] Is Reference.reachabilityFence() needed in Reference constructor? In-Reply-To: <6882C9A35DFB9B4FA2779F7BF5B9757D2084F9606A@GSCMAMP06EX.firmwide.corp.gs.com> References: <56278653.9080501@gmail.com> <5627B2E4.205@oracle.com> <6882C9A35DFB9B4FA2779F7BF5B9757D2084F9606A@GSCMAMP06EX.firmwide.corp.gs.com> Message-ID: <CAHjP37FJG=PPXsxif3jvLCRPTJ1gzMuqYUh5GZKgvwnrNKkwbQ@mail.gmail.com> > > queue is marked volatile, so a simple reordering of the lines should be > just as effective: > Reference(T referent, ReferenceQueue<? super T> queue) { > this.queue = (queue == null) ? ReferenceQueue.NULL : queue; > this.referent = referent; > } Won't mean much since the plain referent store can move above the queue store. On Wed, Oct 21, 2015 at 1:10 PM, Rezaei, Mohammad A. <Mohammad.Rezaei at gs.com > wrote: > >> Might the following be needed or not: > >> > >> Reference(T referent, ReferenceQueue<? super T> queue) { > >> this.referent = referent; > >> this.queue = (queue == null) ? ReferenceQueue.NULL : queue; > >> reachabilityFence(referent); > >> } > > > > queue is marked volatile, so a simple reordering of the lines should be > just as effective: > > Reference(T referent, ReferenceQueue<? super T> queue) { > this.queue = (queue == null) ? ReferenceQueue.NULL : queue; > this.referent = referent; > } > > A simplistic interpretation of GC (as for example seen here: > http://stackoverflow.com/questions/10795505/how-do-garbage-collectors-know-about-references-on-the-stack-frame > ) might lead one to believe that referent is reachable until the end of the > constructor because it's in the stack frame. The point at which > reachability analysis kicks in, in the middle of such a simple two liner > and removes the referent from the stack (or other variations such as > inlining) is presumably highly implementation dependent and should not be > relied on, but I'm guessing that's the reason you're not able to reproduce > an early GC. > > Thanks > Moh > From lance.andersen at oracle.com Wed Oct 21 19:55:50 2015 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 21 Oct 2015 15:55:50 -0400 Subject: [9] RFR: 8139743 regular JAX-* sync-up from standalone repos In-Reply-To: <5627C066.3040306@oracle.com> References: <56211448.4040504@oracle.com> <073C6E0E-87EB-408D-813E-E0E325B4DC40@oracle.com> <56211C98.3040905@oracle.com> <7035006E-A338-4D23-B185-EC841E309988@oracle.com> <5627C066.3040306@oracle.com> Message-ID: <FDDAA3A1-4FD9-496B-B653-912AC77A345D@oracle.com> Hi Miran I just made a pass through the spec diff and have a few comments/questions: http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/jxc/gen/config/NGCCRuntime.html is the &lt, &gt correct in the new version? http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/xjc/generator/bean/PackageOutlineImpl.html : still a period in @see for getMostUsedNamespaceURI http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/xjc/model/CPropertyInfo.html: extra space before the period in getName http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/xjc/reader/Const.html : Extra space before the comma http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/xjc/reader/relaxng/package-summary.html: The package summary changes seem wrong (extra and for example) http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/xjc/reader/relaxng/RELAXNGInternalizationLogic.ReferenceFinder.html: change seems wrong (extra and for example) http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/core/ElementInfo.html: extra semi-colon after <contentMemoryType> I believe http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/ElementInfoImpl.html extra semi-colon after <contentMemoryType> I believe http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/ElementInfoImpl.PropertyImpl.html looks like @XmlElement was changed incorrectly? http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/ElementPropertyInfoImpl.html looks like @XmlElement was changed incorrectly? http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/RuntimeElementInfoImpl.html extra semi-colon? http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/RuntimeElementInfoImpl.RuntimePropertyImpl.html looks like @XmlElement was changed incorrectly? http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/runtime/RuntimeElementPropertyInfo.html looks like @XmlElement was changed incorrectly? http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/MarshallerImpl.html extra space before ')' did you really mean to change & to &amp; in the following: ------------------------ http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/FastInfosetStreamWriterOutput.html http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/ForkXmlOutput.html http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/IndentingUTF8XmlOutput.html http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/MTOMXmlOutput.html http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/SAXOutput.html http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/StAXExStreamWriterOutput.html http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/UTF8XmlOutput.html http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/XMLEventWriterOutput.html http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/XMLStreamWriterOutput.html http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/XmlOutput.html ------------------------ http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/ws/api/pipe/PipeClonerImpl.html - looks like this was missing from the specdiff http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/javax/xml/bind/Marshaller.html extra space before ')' http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/javax/xml/bind/helpers/AbstractMarshallerImpl.html extra space before ')' Best, Lance On Oct 21, 2015, at 12:42 PM, Miroslav Kos <miroslav.kos at oracle.com> wrote: > Hi Lance, > yes, it makes sense - after creating it and reviewing I fixed additional issues - please, check new version of a patch: > http://cr.openjdk.java.net/~mkos/8139743/jaxws.02/ > http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/ > > Thanks > Miran > > On 16/10/15 18:12, Lance Andersen wrote: >> Hi Miran >> >> On Oct 16, 2015, at 11:49 AM, Miroslav Kos <miroslav.kos at oracle.com> wrote: >> >>> Hi Lance, >>> the javadoc fixes are just about formal issues (<tt>...</tt> for {@code .. }, broken links etc.) - there are no other changes. >> >> Understand, but the specdiff makes it easier to see that there are no untended changes especially with the size. >> >> Best >> Lance >>> >>> Thanks >>> Miran >>> >>> >>> On 16/10/15 17:26, Lance Andersen wrote: >>>> Hi Miran >>>> >>>> Can you please provide a specdiff as that makes it easier for javadoc review >>>> >>>> Best >>>> Lance >>>> On Oct 16, 2015, at 11:14 AM, Miroslav Kos <miroslav.kos at oracle.com> wrote: >>>> >>>>> Hi, >>>>> there is a bulk update of JAX-B/WS from upstream projects - >>>>> webrev: http://cr.openjdk.java.net/~mkos/8139743/jaxws.01/ >>>>> more details in issue desc: https://bugs.openjdk.java.net/browse/JDK-8139743 >>>>> >>>>> Could I ask for a review? >>>>> >>>>> It's quite big (2570 lines changed): >>>>> * many javadoc fixes >>>>> * some performance and other fixes for SAAJ >>>>> * findbugs issues >>>>> >>>>> There are issue list in the JBS, many of listed bugs were fixed in JDK already (they are on the list because of backporting to standalone) >>>>> >>>>> Thanks >>>>> Miran >>>>> >>>> >>>> <Mail Attachment.gif> >>>> >>>> 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 >>>> >>>> >>>> >>> >> >> <Mail Attachment.gif> >> >> 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 vitalyd at gmail.com Wed Oct 21 22:25:01 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 21 Oct 2015 18:25:01 -0400 Subject: [concurrency-interest] Is Reference.reachabilityFence() needed in Reference constructor? In-Reply-To: <5627C696.1070806@oracle.com> References: <56278653.9080501@gmail.com> <5627B2E4.205@oracle.com> <5627B502.2010007@redhat.com> <5627C696.1070806@oracle.com> Message-ID: <CAHjP37FD24s9GuJhcf90HqDppuFZhCX5rrcUXTS7qROs7BjxSw@mail.gmail.com> > > Yes, if runtime stripes that instance before it is exposed anywhere > (e.g. scalarizes the weakref) If you look at escape analysis code ( http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/a60bd3d34158/src/share/vm/opto/escape.cpp#l803), Reference and subclasses get special treatment and marked as GlobalEscape. On Wed, Oct 21, 2015 at 1:08 PM, Aleksey Shipilev < aleksey.shipilev at oracle.com> wrote: > On 10/21/2015 06:53 PM, Andrew Haley wrote: > > On 10/21/2015 04:44 PM, Aleksey Shipilev wrote: > >> Of course, this does not tell another (scary) part of the story, what if > >> the Reference itself is not discovered as strong ref by GC, e.g. when it > >> isn't published on heap, or scalarized by compiler, etc. > >> reachabilityFence, as currently implemented, extends the "liveness" > >> scope of the local variable, but does not convey anything special to the > >> GC/runtime otherwise. > > > > If the Reference itself is not reachable from a strong root then the > > Reference is dead so we don't care what happens to it. But if the > > Reference is put on a reachable ReferenceQueue, then it's fine. > > Yes, if runtime stripes that instance before it is exposed anywhere > (e.g. scalarizes the weakref), or those references are dead (e.g. the > weakref is buried somewhere deep in garbage subgraph, and purged on > sweep), then everything goes awry. > > But the thing is, a WeakReference is put on ReferenceQueue by the GC > itself. In the object graph, ReferenceQueue does not normally reference > weakrefs back. Before enqueueing the reference GC has to first discover > that WeakReference -- but from where? In other words, "registering" on a > reachable RefQueue does not make weakref to be reachable. > > Case in point: > > public class WhereIsWaldo { > > public static void main(String... args) throws Exception { > for (int c = 0; true; c++) { > new WhereIsWaldo().work(c); > } > } > > final ReferenceQueue<Object> rq = new ReferenceQueue<>(); > > void work(int id) throws Exception { > hideWaldo(id); > findWaldo(id); > } > > WeakReference<Object> gwr; > > void hideWaldo(int id) { > // Does not work, d'uh > new WeakReference<>(new Object(), rq); > > // Does not work either :( > WeakReference<Object> wr = > new WeakReference<>(new Object(), rq); > > // This also does not help... once you leave the method, > // the weakref is gone. > Reference.reachabilityFence(wr); > > // This one helps, makes Waldo reachable > // gwr = wr; > } > > void findWaldo(int id) throws Exception { > while (Thread.currentThread().isAlive()) { > System.gc(); > Reference ref = rq.remove(1000); > if (ref != null) { > return; > } else { > System.out.println("Where's Waldo #" + id + "?"); > } > } > } > } > > > Thanks, > -Aleksey > > From martinrb at google.com Wed Oct 21 22:55:10 2015 From: martinrb at google.com (Martin Buchholz) Date: Wed, 21 Oct 2015 15:55:10 -0700 Subject: The Great jsr166 openjdk9 integration is over! Message-ID: <CA+kOe08=Hoi1XYJb4qKD=ZTe6wD1v8MYOFHHRCL8JcTfFijopw@mail.gmail.com> (Almost) all the latest good stuff from Doug's jsr166 CVS repository has been merged into openjdk9 (JEP 266). We're very close to "no known bugs". Thanks to everyone who helped! Another minor round of bug fixing will follow. We will probably try to switch from use of Unsafe to use of Varhandles, which will in turn introduce a requirement for jsr166 files in src/main to run with jdk9 only (today they can run on jdk8), so we will probably have a "branch" in CVS that will continue to run on jdk8. From sandhya.viswanathan at intel.com Thu Oct 22 01:08:49 2015 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Thu, 22 Oct 2015 01:08:49 +0000 Subject: SO_REUSEPORT feature support in JDK 9 for socket communication Message-ID: <02FCFB8477C4EF43A2AD8E0C60F3DA2B647681C8@FMSMSX112.amr.corp.intel.com> This is a proposal for adding SO_REUSEPORT support in JDK 9 for socket communication. The feature is supported since Linux Kernel 3.9 in OS. It is also supported in some of BSD flavors. It removes 1:1 assignment between listen socket and IP:PORT pair and enables multiple sockets listening to the same address. This improves the scalability and parallelism of network traffic handling. For more details, please refer to https://lwn.net/Articles/542629/ The proposal is to add the SO_REUSEPORT feature on similar lines as SO_REUSEADDR which was included in JDK7. Add the following two API methods to java/net/ServerSocket.java and java/net/Socket.java: public void setReusePort(boolean on) throws SocketException Enable/disable the SO_REUSEPORT socket option. Enabling SO_REUSEPORT prior to binding the socket using bind(SocketAddress) allows the socket and all the sockets created after this socket being able to listen to same IP:PORT. Applications can use getReusePort() to determine the initial setting of SO_REUSEPORT. Parameters: on - whether to enable or disable the socket option Throws: SocketException - if an error occurs enabling or disabling the SO_RESUEPORT socket option, or the socket is closed. public boolean getReusePort() throws SocketException Tests if SO_REUSEPORT is enabled. Returns: A boolean indicating whether or not SO_REUSEPORT is enabled. Throws: SocketException - if there is an error in the underlying protocol, such as a TCP error. Also add the SO_REUSEPORT to the SocketOptions in various files. We implemented a prototype on JDK 8 and see very good results in HDFS latency reduction and network connection scaling; about ~1.9x improvement in latency for OSU HiBD Benchmark (http://hibd.cse.ohio-state.edu/downloads/) on a small cluster of 1 Namenode and 2 DataNodes. We plan to port it to JDK 9 sources and submit it for consideration. Please let us know if there is interest and if you would like to sponsor this patch. Many applications, especially Linux or BSD based webservers such as Apache httpd and Nginx are already supporting it now. Ruby and Python have it supported as well. Other Java applications such as Netty webserver have it support it via JNI function since JDK has not supported it yet. Significant throughput and latency improvement have been observed from various applications. Best Regards, Sandhya From peter.levart at gmail.com Thu Oct 22 11:22:48 2015 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 22 Oct 2015 13:22:48 +0200 Subject: [concurrency-interest] Is Reference.reachabilityFence() needed in Reference constructor? In-Reply-To: <CAHjP37FD24s9GuJhcf90HqDppuFZhCX5rrcUXTS7qROs7BjxSw@mail.gmail.com> References: <56278653.9080501@gmail.com> <5627B2E4.205@oracle.com> <5627B502.2010007@redhat.com> <5627C696.1070806@oracle.com> <CAHjP37FD24s9GuJhcf90HqDppuFZhCX5rrcUXTS7qROs7BjxSw@mail.gmail.com> Message-ID: <5628C708.5010109@gmail.com> Hi, Thanks for the insight. I'd like to note that I'm not concerned about the reachability of the Reference object itself (program code takes care of that - for example in Cleaner API it hooks Reference objects into a doubly-linked list exactly for them to stay reachable until discovered by GC and enqueued by ReferenceHandler thread into the associated ReferenceQueue). I'm merely interested in the reachability of the referent until the Reference (and any possible Reference subclass constructor) fully constructs the Reference instance. The situation where this would manifest as a malfunction is improbable (as the referent is usually passed to other parts of code too and is reachable from elsewhere for some time). But in case it isn't, the following is possible: Reference(T referent, ReferenceQueue<? super T> queue) { this.referent = referent; // - safepoint with GC happens, 'referent' is found weakly-reachable, 'this' Reference is hooked on the pending chain // - ReferenceHandler thread unhooks 'this' from pending chain and tries to enqueue it, but this.queue is still null // - BANG! NPE in Referencehandler thread which terminates it! this.queue = (queue == null) ? ReferenceQueue.NULL : queue; } A pre-requisite for above scenario is a safepoint between "this.referent = referent" and "this.queue = ...". In interpreter, safepoint check is after every bytecode instruction right? But in Interpreter, I think arguments are also kept on the stack and are therefore reachable at least until the end of constructor. How probable is a safepoint between those two statements in JIT-ed code? Maybe the Reference constructor itself is not in danger because it is very trivial, but what about subclasses that must do their own part of initialization too (for example Cleaner API discussed on core-libs-dev)? Regards, Peter On 10/22/2015 12:25 AM, Vitaly Davidovich wrote: > > Yes, if runtime stripes that instance before it is exposed anywhere > (e.g. scalarizes the weakref) > > > If you look at escape analysis code > (http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/a60bd3d34158/src/share/vm/opto/escape.cpp#l803), > Reference and subclasses get special treatment and marked as GlobalEscape. > > On Wed, Oct 21, 2015 at 1:08 PM, Aleksey Shipilev > <aleksey.shipilev at oracle.com <mailto:aleksey.shipilev at oracle.com>> wrote: > > On 10/21/2015 06:53 PM, Andrew Haley wrote: > > On 10/21/2015 04:44 PM, Aleksey Shipilev wrote: > >> Of course, this does not tell another (scary) part of the > story, what if > >> the Reference itself is not discovered as strong ref by GC, > e.g. when it > >> isn't published on heap, or scalarized by compiler, etc. > >> reachabilityFence, as currently implemented, extends the "liveness" > >> scope of the local variable, but does not convey anything > special to the > >> GC/runtime otherwise. > > > > If the Reference itself is not reachable from a strong root then the > > Reference is dead so we don't care what happens to it. But if the > > Reference is put on a reachable ReferenceQueue, then it's fine. > > Yes, if runtime stripes that instance before it is exposed anywhere > (e.g. scalarizes the weakref), or those references are dead (e.g. the > weakref is buried somewhere deep in garbage subgraph, and purged on > sweep), then everything goes awry. > > But the thing is, a WeakReference is put on ReferenceQueue by the GC > itself. In the object graph, ReferenceQueue does not normally > reference > weakrefs back. Before enqueueing the reference GC has to first > discover > that WeakReference -- but from where? In other words, > "registering" on a > reachable RefQueue does not make weakref to be reachable. > > Case in point: > > public class WhereIsWaldo { > > public static void main(String... args) throws Exception { > for (int c = 0; true; c++) { > new WhereIsWaldo().work(c); > } > } > > final ReferenceQueue<Object> rq = new ReferenceQueue<>(); > > void work(int id) throws Exception { > hideWaldo(id); > findWaldo(id); > } > > WeakReference<Object> gwr; > > void hideWaldo(int id) { > // Does not work, d'uh > new WeakReference<>(new Object(), rq); > > // Does not work either :( > WeakReference<Object> wr = > new WeakReference<>(new Object(), rq); > > // This also does not help... once you leave the method, > // the weakref is gone. > Reference.reachabilityFence(wr); > > // This one helps, makes Waldo reachable > // gwr = wr; > } > > void findWaldo(int id) throws Exception { > while (Thread.currentThread().isAlive()) { > System.gc(); > Reference ref = rq.remove(1000); > if (ref != null) { > return; > } else { > System.out.println("Where's Waldo #" + id + "?"); > } > } > } > } > > > Thanks, > -Aleksey > > From vitalyd at gmail.com Thu Oct 22 11:35:58 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 22 Oct 2015 07:35:58 -0400 Subject: [concurrency-interest] Is Reference.reachabilityFence() needed in Reference constructor? In-Reply-To: <5628C708.5010109@gmail.com> References: <56278653.9080501@gmail.com> <5627B2E4.205@oracle.com> <5627B502.2010007@redhat.com> <5627C696.1070806@oracle.com> <CAHjP37FD24s9GuJhcf90HqDppuFZhCX5rrcUXTS7qROs7BjxSw@mail.gmail.com> <5628C708.5010109@gmail.com> Message-ID: <CAHjP37GZz5XybJmBTb5VzmJ0qbLodVpvJrvjYHKe9M0+cFs2wg@mail.gmail.com> It's unlikely there would be a safepoint between those two statements in compiled code. Polls are typically placed at method exit (modulo polls inserted for some types of loops, but that's irrelevant to this instance). With inlining, the poll distance is likely to increase as well. However, there's nothing stopping compiler from scheduling these two statements sufficiently apart, particularly since there's no data or control flow dependence between them, and ending up with a safepoint in between. It's unlikely probably, but possible. The bottom line is this code needs manual lifetime extension facility. sent from my phone On Oct 22, 2015 7:22 AM, "Peter Levart" <peter.levart at gmail.com> wrote: > Hi, > > Thanks for the insight. > > I'd like to note that I'm not concerned about the reachability of the > Reference object itself (program code takes care of that - for example in > Cleaner API it hooks Reference objects into a doubly-linked list exactly > for them to stay reachable until discovered by GC and enqueued by > ReferenceHandler thread into the associated ReferenceQueue). I'm merely > interested in the reachability of the referent until the Reference (and any > possible Reference subclass constructor) fully constructs the Reference > instance. > > The situation where this would manifest as a malfunction is improbable (as > the referent is usually passed to other parts of code too and is reachable > from elsewhere for some time). But in case it isn't, the following is > possible: > > Reference(T referent, ReferenceQueue<? super T> queue) { > this.referent = referent; > // - safepoint with GC happens, 'referent' is found > weakly-reachable, 'this' Reference is hooked on the pending chain > // - ReferenceHandler thread unhooks 'this' from pending chain and > tries to enqueue it, but this.queue is still null > // - BANG! NPE in Referencehandler thread which terminates it! > this.queue = (queue == null) ? ReferenceQueue.NULL : queue; > } > > A pre-requisite for above scenario is a safepoint between "this.referent = > referent" and "this.queue = ...". In interpreter, safepoint check is after > every bytecode instruction right? But in Interpreter, I think arguments are > also kept on the stack and are therefore reachable at least until the end > of constructor. How probable is a safepoint between those two statements in > JIT-ed code? Maybe the Reference constructor itself is not in danger > because it is very trivial, but what about subclasses that must do their > own part of initialization too (for example Cleaner API discussed on > core-libs-dev)? > > Regards, Peter > > On 10/22/2015 12:25 AM, Vitaly Davidovich wrote: > > Yes, if runtime stripes that instance before it is exposed anywhere >> (e.g. scalarizes the weakref) > > > If you look at escape analysis code ( > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/a60bd3d34158/src/share/vm/opto/escape.cpp#l803), > Reference and subclasses get special treatment and marked as GlobalEscape. > > On Wed, Oct 21, 2015 at 1:08 PM, Aleksey Shipilev < > aleksey.shipilev at oracle.com> wrote: > >> On 10/21/2015 06:53 PM, Andrew Haley wrote: >> > On 10/21/2015 04:44 PM, Aleksey Shipilev wrote: >> >> Of course, this does not tell another (scary) part of the story, what >> if >> >> the Reference itself is not discovered as strong ref by GC, e.g. when >> it >> >> isn't published on heap, or scalarized by compiler, etc. >> >> reachabilityFence, as currently implemented, extends the "liveness" >> >> scope of the local variable, but does not convey anything special to >> the >> >> GC/runtime otherwise. >> > >> > If the Reference itself is not reachable from a strong root then the >> > Reference is dead so we don't care what happens to it. But if the >> > Reference is put on a reachable ReferenceQueue, then it's fine. >> >> Yes, if runtime stripes that instance before it is exposed anywhere >> (e.g. scalarizes the weakref), or those references are dead (e.g. the >> weakref is buried somewhere deep in garbage subgraph, and purged on >> sweep), then everything goes awry. >> >> But the thing is, a WeakReference is put on ReferenceQueue by the GC >> itself. In the object graph, ReferenceQueue does not normally reference >> weakrefs back. Before enqueueing the reference GC has to first discover >> that WeakReference -- but from where? In other words, "registering" on a >> reachable RefQueue does not make weakref to be reachable. >> >> Case in point: >> >> public class WhereIsWaldo { >> >> public static void main(String... args) throws Exception { >> for (int c = 0; true; c++) { >> new WhereIsWaldo().work(c); >> } >> } >> >> final ReferenceQueue<Object> rq = new ReferenceQueue<>(); >> >> void work(int id) throws Exception { >> hideWaldo(id); >> findWaldo(id); >> } >> >> WeakReference<Object> gwr; >> >> void hideWaldo(int id) { >> // Does not work, d'uh >> new WeakReference<>(new Object(), rq); >> >> // Does not work either :( >> WeakReference<Object> wr = >> new WeakReference<>(new Object(), rq); >> >> // This also does not help... once you leave the method, >> // the weakref is gone. >> Reference.reachabilityFence(wr); >> >> // This one helps, makes Waldo reachable >> // gwr = wr; >> } >> >> void findWaldo(int id) throws Exception { >> while (Thread.currentThread().isAlive()) { >> System.gc(); >> Reference ref = rq.remove(1000); >> if (ref != null) { >> return; >> } else { >> System.out.println("Where's Waldo #" + id + "?"); >> } >> } >> } >> } >> >> >> Thanks, >> -Aleksey >> >> > > From Roger.Riggs at Oracle.com Thu Oct 22 13:04:44 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 22 Oct 2015 09:04:44 -0400 Subject: SO_REUSEPORT feature support in JDK 9 for socket communication In-Reply-To: <02FCFB8477C4EF43A2AD8E0C60F3DA2B647681C8@FMSMSX112.amr.corp.intel.com> References: <02FCFB8477C4EF43A2AD8E0C60F3DA2B647681C8@FMSMSX112.amr.corp.intel.com> Message-ID: <5628DEEC.5080407@Oracle.com> Hi Sandhya, The folks on net-dev at openjdk.java.net will be interested too. Roger On 10/21/2015 9:08 PM, Viswanathan, Sandhya wrote: > > This is a proposal for adding SO_REUSEPORT support in JDK 9 for socket communication. The feature is supported since Linux Kernel 3.9 in OS. It is also supported in some of BSD flavors. It removes 1:1 assignment between listen socket and IP:PORT pair and enables multiple sockets listening to the same address. This improves the scalability and parallelism of network traffic handling. For more details, please refer to https://lwn.net/Articles/542629/ > > The proposal is to add the SO_REUSEPORT feature on similar lines as SO_REUSEADDR which was included in JDK7. > Add the following two API methods to java/net/ServerSocket.java and java/net/Socket.java: > > public void setReusePort(boolean on) > > throws SocketException > > Enable/disable the SO_REUSEPORT socket option. > > Enabling SO_REUSEPORT prior to binding the socket using bind(SocketAddress) allows the socket and all the sockets created after this socket being able to listen to > > same IP:PORT. Applications can use getReusePort() to determine the initial setting of SO_REUSEPORT. > > Parameters: > > on - whether to enable or disable the socket option > > Throws: > > SocketException - if an error occurs enabling or disabling the SO_RESUEPORT socket option, or the socket is closed. > > > > public boolean getReusePort() > > throws SocketException > > Tests if SO_REUSEPORT is enabled. > > Returns: > > A boolean indicating whether or not SO_REUSEPORT is enabled. > > Throws: > > SocketException - if there is an error in the underlying protocol, such as a TCP error. > > > Also add the SO_REUSEPORT to the SocketOptions in various files. > > > > We implemented a prototype on JDK 8 and see very good results in HDFS latency reduction and network connection scaling; about ~1.9x improvement in latency for OSU HiBD Benchmark (http://hibd.cse.ohio-state.edu/downloads/) on a small cluster of 1 Namenode and 2 DataNodes. > We plan to port it to JDK 9 sources and submit it for consideration. > Please let us know if there is interest and if you would like to sponsor this patch. > > > Many applications, especially Linux or BSD based webservers such as Apache httpd and Nginx are already supporting it now. Ruby and Python have it supported as well. Other Java applications such as Netty webserver have it support it via JNI function since JDK has not supported it yet. Significant throughput and latency improvement have been observed from various applications. > > > > Best Regards, > > Sandhya > > From Alan.Bateman at oracle.com Thu Oct 22 13:24:18 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 22 Oct 2015 14:24:18 +0100 Subject: SO_REUSEPORT feature support in JDK 9 for socket communication In-Reply-To: <5628DEEC.5080407@Oracle.com> References: <02FCFB8477C4EF43A2AD8E0C60F3DA2B647681C8@FMSMSX112.amr.corp.intel.com> <5628DEEC.5080407@Oracle.com> Message-ID: <5628E382.3070509@oracle.com> On 22/10/2015 14:04, Roger Riggs wrote: > Hi Sandhya, > > The folks on net-dev at openjdk.java.net will be interested too. Yes, net-dev is the best list for this. One other thing to mention is the SocketOption interface and the setOption/getOption methods. This allows for platform or JDK-specific specific socket options, it also allows it to be implemented by the NIO SocketChannel and friends. -Alan From michael.x.mcmahon at oracle.com Thu Oct 22 13:33:10 2015 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 22 Oct 2015 14:33:10 +0100 Subject: SO_REUSEPORT feature support in JDK 9 for socket communication In-Reply-To: <5628E382.3070509@oracle.com> References: <02FCFB8477C4EF43A2AD8E0C60F3DA2B647681C8@FMSMSX112.amr.corp.intel.com> <5628DEEC.5080407@Oracle.com> <5628E382.3070509@oracle.com> Message-ID: <5628E596.5000203@oracle.com> On 22/10/15 14:24, Alan Bateman wrote: > > > On 22/10/2015 14:04, Roger Riggs wrote: >> Hi Sandhya, >> >> The folks on net-dev at openjdk.java.net will be interested too. > Yes, net-dev is the best list for this. > > One other thing to mention is the SocketOption interface and the > setOption/getOption methods. This allows for platform or JDK-specific > specific socket options, it also allows it to be implemented by the > NIO SocketChannel and friends. > > -Alan and there is the jdk.net API which extends this to the java.net socket types. I think a Java SE API would be fine if it is widely and consistently implemented across all the reference platforms and if it does not cause compatibility issues. If it only works on some platforms then maybe jdk.net could be the place for it. - Michael From chris.hegarty at oracle.com Thu Oct 22 14:28:02 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 22 Oct 2015 15:28:02 +0100 Subject: 8139891: Prepare Unsafe for true encapsulation Message-ID: <70AE5E05-2BA2-457A-B65F-E819238509DC@oracle.com> As part of the preparation for JEP 260 [1], Unsafe needs to be separable from the base module [2], so it can be exported by a new, yet to be defined, jdk.unsupported module, and have a separate evolution policy that is not exposed. That is, the JDK needs an internal Unsafe that can be evolved and added to in future releases, while maintaining the existing Unsafe API that developers are using. Many uses of Unsafe are for performance reasons. Any changes made should preserve the current performance characteristics. To achieve this the existing Unsafe intrinsic candidate methods should remain intrinsic candidate methods. The VM can provide aliases for these intrinsics so they are common to both the internal and sun.misc versions of Unsafe. The JDK implementation will be updated to use the new internal version of Unsafe. For the purposes of making progress, I think this work can be split into several steps: 1) Create the new internal Unsafe class and provide intrinsic support for both. 2) Update existing, and possibly add new, tests to use the new internal Unsafe. Some tests may need to be duplicated, or reworked, to test both versions of Unsafe. 3) Update the Unsafe usages in the JDK so that there is no longer any dependency on sun.misc.Unsafe. To this end I've put together a webrev containing the changes required for step 1. It contains - the intrinsic aliasing, - the new internal Unsafe ( copy of sun.misc.Unsafe ), - reverts sun.misc.Unsafe to, almost, its 1.8 API, - minimal test and implementation updates, since there some usages of unaligned access that is new in the 1.9. http://cr.openjdk.java.net/~chegar/unsafe_phase1/ All JPRT hotspot and core libraries tests pass. I have most of the work for steps 2 and 3 done, but some discussion and clean up is required. It also increase the level of difficult to review the changes in phase 1, which is mostly what I'd like to get agreement on first. -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8132928 [2] https://bugs.openjdk.java.net/browse/JDK-8139891 From me at noctarius.com Thu Oct 22 14:48:31 2015 From: me at noctarius.com (Christoph Engelbert) Date: Thu, 22 Oct 2015 16:48:31 +0200 Subject: 8139891: Prepare Unsafe for true encapsulation In-Reply-To: <70AE5E05-2BA2-457A-B65F-E819238509DC@oracle.com> References: <70AE5E05-2BA2-457A-B65F-E819238509DC@oracle.com> Message-ID: <964676D6-A142-4B2F-AC77-59B21E7946CA@noctarius.com> Hey Chris, I don?t like to say it but it sounds very wrong to have another Unsafe like thinggy in the future instead of providing public alternatives right from the start. I agree it might be a faster to just write adapter classes and I really don?t like to repeat what I said in the past but why should Oracle be able to write fast Java code than the public? It just doesn?t make sense to me. Just to clarify, I don?t want to start another fight I just want to make sure I understand the reason for another class like Unsafe and why it seems like that there is another move to hide performance relevant details from Java developers around the world. Thanks Chris > On 22 Oct 2015, at 16:28, Chris Hegarty <chris.hegarty at oracle.com> wrote: > > As part of the preparation for JEP 260 [1], Unsafe needs to be separable > from the base module [2], so it can be exported by a new, yet to be > defined, jdk.unsupported module, and have a separate evolution policy > that is not exposed. That is, the JDK needs an internal Unsafe that can > be evolved and added to in future releases, while maintaining the > existing Unsafe API that developers are using. > > Many uses of Unsafe are for performance reasons. Any changes made > should preserve the current performance characteristics. To achieve this > the existing Unsafe intrinsic candidate methods should remain intrinsic > candidate methods. The VM can provide aliases for these intrinsics so > they are common to both the internal and sun.misc versions of Unsafe. > > The JDK implementation will be updated to use the new internal version > of Unsafe. > > For the purposes of making progress, I think this work can be split into > several steps: > > 1) Create the new internal Unsafe class and provide intrinsic support > for both. > 2) Update existing, and possibly add new, tests to use the new > internal Unsafe. Some tests may need to be duplicated, or reworked, > to test both versions of Unsafe. > 3) Update the Unsafe usages in the JDK so that there is no longer any > dependency on sun.misc.Unsafe. > > To this end I've put together a webrev containing the changes required > for step 1. It contains > - the intrinsic aliasing, > - the new internal Unsafe ( copy of sun.misc.Unsafe ), > - reverts sun.misc.Unsafe to, almost, its 1.8 API, > - minimal test and implementation updates, since there some usages > of unaligned access that is new in the 1.9. > > http://cr.openjdk.java.net/~chegar/unsafe_phase1/ > > All JPRT hotspot and core libraries tests pass. > > I have most of the work for steps 2 and 3 done, but some discussion and > clean up is required. It also increase the level of difficult to review > the changes in phase 1, which is mostly what I'd like to get agreement > on first. > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8132928 > [2] https://bugs.openjdk.java.net/browse/JDK-8139891 From mark.sheppard at oracle.com Thu Oct 22 15:05:47 2015 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Thu, 22 Oct 2015 16:05:47 +0100 Subject: SO_REUSEPORT feature support in JDK 9 for socket communication In-Reply-To: <5628E596.5000203@oracle.com> References: <02FCFB8477C4EF43A2AD8E0C60F3DA2B647681C8@FMSMSX112.amr.corp.intel.com> <5628DEEC.5080407@Oracle.com> <5628E382.3070509@oracle.com> <5628E596.5000203@oracle.com> Message-ID: <5628FB4B.8090305@oracle.com> the following JBS item exists: https://bugs.openjdk.java.net/browse/JDK-6432031 search of windows documentation suggests that SO_REUSEPORT is still not an option man setsockopt on Solaris shows it as an option, but without precise description of semantics regards Mark On 22/10/2015 14:33, Michael McMahon wrote: > On 22/10/15 14:24, Alan Bateman wrote: >> >> >> On 22/10/2015 14:04, Roger Riggs wrote: >>> Hi Sandhya, >>> >>> The folks on net-dev at openjdk.java.net will be interested too. >> Yes, net-dev is the best list for this. >> >> One other thing to mention is the SocketOption interface and the >> setOption/getOption methods. This allows for platform or JDK-specific >> specific socket options, it also allows it to be implemented by the >> NIO SocketChannel and friends. >> >> -Alan > > and there is the jdk.net API which extends this to the java.net socket > types. > > I think a Java SE API would be fine if it is widely and consistently > implemented > across all the reference platforms and if it does not cause > compatibility issues. > > If it only works on some platforms then maybe jdk.net could be the > place for it. > > - Michael From attila.szegedi at oracle.com Thu Oct 22 16:22:30 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 22 Oct 2015 18:22:30 +0200 Subject: JEP 276: Dynamic Linking of Language-Defined Object Models In-Reply-To: <20151016173533.8325A7D532@eggemoggin.niobe.net> References: <20151016173533.8325A7D532@eggemoggin.niobe.net> Message-ID: <9AE3A5F8-1644-4BD2-BF19-9DABDFEECDCF@oracle.com> Folks, here?s some updates on this JEP, mostly making the code and docs available to the community for evaluation. Where?s the code? ================= The JDK 9 sandbox repo now has a branch named ?JEP-276-branch? where the work is ongoing. If you aren?t familiar with the JDK 9 sandbox, you can read all about it here: <http://cr.openjdk.java.net/~chegar/docs/sandbox.html> If you clone this repo, the source code is in nashorn/src/jdk.dynalink directory. (It being in the nashorn subrepo is not necessarily final, we just peeled it off of Nashorn in the first step.) How to get the docs? ==================== Again, go to nashorn/make and issue "ant dynalinkapi". You'll get the docs in nashorn/dist/javadoc directory. They should be quite comprehensive. For your convenience I also uploaded the docs to <http://cr.openjdk.java.net/~attila/jep276/javadoc.20151022/> How to get a binary? ==================== If you go to nashorn/make directory and issue "ant jar" you?ll get a JAR file in nashorn/dist/nashorn.jar that includes the Dynalink classes. Again, they're colocated with Nashorn for the time being, but you can use Dynalink and ignore Nashorn. (There's no dependencies from Dynalink to Nashorn, mind you, they just share the JAR file at the moment.) You can use the latest Early Access Release of JDK9 from <https://jdk9.java.net/download/> and launch the JVM with nashorn.jar prepended to boot class path with "-Xbootclasspath/p:" option. Mind you, we haven't gotten to updating the makefiles yet, so at the time of this writing an attempt to build a full JDK from the branch will fail. That's why I'm suggesting you take the EA build and add the nashorn.jar to its boot class path. That's all for now - give it a try and I'll be happy to hear your feedback. I will be at JavaOne in San Francisco next week; if you happen to be around, get in touch and I would be happy to discuss it in person too. Thanks, Attila. From paul.sandoz at oracle.com Thu Oct 22 16:31:45 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 22 Oct 2015 09:31:45 -0700 Subject: 8139891: Prepare Unsafe for true encapsulation In-Reply-To: <70AE5E05-2BA2-457A-B65F-E819238509DC@oracle.com> References: <70AE5E05-2BA2-457A-B65F-E819238509DC@oracle.com> Message-ID: <DB96EE4D-0CD0-4DF3-9480-4E22E84859E2@oracle.com> Hi Chris, This looks like a good first step. I am sure hotspot devs will have more concrete review comments, but i like the way the method aliasing (copying the same technique StrictMath -> Math) avoids any changes to the intrinsics, thus the changes are much more localized. It may be worth having some fast debugging output for the aliasing in case internal refactoring messes things up. Paul. > On 22 Oct 2015, at 07:28, Chris Hegarty <chris.hegarty at oracle.com> wrote: > > As part of the preparation for JEP 260 [1], Unsafe needs to be separable > from the base module [2], so it can be exported by a new, yet to be > defined, jdk.unsupported module, and have a separate evolution policy > that is not exposed. That is, the JDK needs an internal Unsafe that can > be evolved and added to in future releases, while maintaining the > existing Unsafe API that developers are using. > > Many uses of Unsafe are for performance reasons. Any changes made > should preserve the current performance characteristics. To achieve this > the existing Unsafe intrinsic candidate methods should remain intrinsic > candidate methods. The VM can provide aliases for these intrinsics so > they are common to both the internal and sun.misc versions of Unsafe. > > The JDK implementation will be updated to use the new internal version > of Unsafe. > > For the purposes of making progress, I think this work can be split into > several steps: > > 1) Create the new internal Unsafe class and provide intrinsic support > for both. > 2) Update existing, and possibly add new, tests to use the new > internal Unsafe. Some tests may need to be duplicated, or reworked, > to test both versions of Unsafe. > 3) Update the Unsafe usages in the JDK so that there is no longer any > dependency on sun.misc.Unsafe. > > To this end I've put together a webrev containing the changes required > for step 1. It contains > - the intrinsic aliasing, > - the new internal Unsafe ( copy of sun.misc.Unsafe ), > - reverts sun.misc.Unsafe to, almost, its 1.8 API, > - minimal test and implementation updates, since there some usages > of unaligned access that is new in the 1.9. > > http://cr.openjdk.java.net/~chegar/unsafe_phase1/ > > All JPRT hotspot and core libraries tests pass. > > I have most of the work for steps 2 and 3 done, but some discussion and > clean up is required. It also increase the level of difficult to review > the changes in phase 1, which is mostly what I'd like to get agreement > on first. > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8132928 > [2] https://bugs.openjdk.java.net/browse/JDK-8139891 From jonathan.gibbons at oracle.com Thu Oct 22 17:23:11 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 22 Oct 2015 10:23:11 -0700 Subject: RFR: 8140325 Incorrect package.html file Message-ID: <56291B7F.5090908@oracle.com> A couple of small fixes for duplicate <body> tags in HTML files. Full webrev: http://cr.openjdk.java.net/~jjg/8140325/webrev.00/ Diffs here: diff -r d93844d0cdd5 src/java.base/share/classes/overview-core.html --- a/src/java.base/share/classes/overview-core.html Thu Oct 22 11:36:17 2015 -0400 +++ b/src/java.base/share/classes/overview-core.html Thu Oct 22 10:21:53 2015 -0700 @@ -30,9 +30,6 @@ </head> <body bgcolor="white"> - -<body> - This document is the API specification for the Java&#x2122; Platform, Standard Edition. diff -r d93844d0cdd5 src/java.naming/share/classes/javax/naming/spi/package.html --- a/src/java.naming/share/classes/javax/naming/spi/package.html Thu Oct 22 11:36:17 2015 -0400 +++ b/src/java.naming/share/classes/javax/naming/spi/package.html Thu Oct 22 10:21:53 2015 -0700 @@ -88,5 +88,3 @@ </body> </html> -<body> -</body> From joe.darcy at oracle.com Thu Oct 22 17:25:15 2015 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 22 Oct 2015 10:25:15 -0700 Subject: RFR: 8140325 Incorrect package.html file In-Reply-To: <56291B7F.5090908@oracle.com> References: <56291B7F.5090908@oracle.com> Message-ID: <56291BFB.8020304@oracle.com> Looks good Jon, -Joe On 10/22/2015 10:23 AM, Jonathan Gibbons wrote: > A couple of small fixes for duplicate <body> tags in HTML files. > Full webrev: http://cr.openjdk.java.net/~jjg/8140325/webrev.00/ > > Diffs here: > > > diff -r d93844d0cdd5 src/java.base/share/classes/overview-core.html > --- a/src/java.base/share/classes/overview-core.html Thu Oct 22 > 11:36:17 2015 -0400 > +++ b/src/java.base/share/classes/overview-core.html Thu Oct 22 > 10:21:53 2015 -0700 > @@ -30,9 +30,6 @@ > </head> > <body bgcolor="white"> > > - > -<body> > - > This document is the API specification for the Java&#x2122; > Platform, Standard Edition. > > diff -r d93844d0cdd5 > src/java.naming/share/classes/javax/naming/spi/package.html > --- a/src/java.naming/share/classes/javax/naming/spi/package.html Thu > Oct 22 11:36:17 2015 -0400 > +++ b/src/java.naming/share/classes/javax/naming/spi/package.html Thu > Oct 22 10:21:53 2015 -0700 > @@ -88,5 +88,3 @@ > > </body> > </html> > -<body> > -</body> > From christian.thalinger at oracle.com Thu Oct 22 20:23:46 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 22 Oct 2015 10:23:46 -1000 Subject: 8139891: Prepare Unsafe for true encapsulation In-Reply-To: <DB96EE4D-0CD0-4DF3-9480-4E22E84859E2@oracle.com> References: <70AE5E05-2BA2-457A-B65F-E819238509DC@oracle.com> <DB96EE4D-0CD0-4DF3-9480-4E22E84859E2@oracle.com> Message-ID: <72D16E3B-EEB8-47B4-9670-6654E3DE5138@oracle.com> > On Oct 22, 2015, at 6:31 AM, Paul Sandoz <Paul.Sandoz at oracle.com> wrote: > > Hi Chris, > > This looks like a good first step. I am sure hotspot devs will have more concrete review comments, but i like the way the method aliasing (copying the same technique StrictMath -> Math) avoids any changes to the intrinsics, thus the changes are much more localized. Yes, me too. I was worried about a lot of changes in compiler code so I?m really happy to see this is not the case. > > It may be worth having some fast debugging output for the aliasing in case internal refactoring messes things up. > > Paul. > >> On 22 Oct 2015, at 07:28, Chris Hegarty <chris.hegarty at oracle.com> wrote: >> >> As part of the preparation for JEP 260 [1], Unsafe needs to be separable >> from the base module [2], so it can be exported by a new, yet to be >> defined, jdk.unsupported module, and have a separate evolution policy >> that is not exposed. That is, the JDK needs an internal Unsafe that can >> be evolved and added to in future releases, while maintaining the >> existing Unsafe API that developers are using. >> >> Many uses of Unsafe are for performance reasons. Any changes made >> should preserve the current performance characteristics. To achieve this >> the existing Unsafe intrinsic candidate methods should remain intrinsic >> candidate methods. The VM can provide aliases for these intrinsics so >> they are common to both the internal and sun.misc versions of Unsafe. >> >> The JDK implementation will be updated to use the new internal version >> of Unsafe. >> >> For the purposes of making progress, I think this work can be split into >> several steps: >> >> 1) Create the new internal Unsafe class and provide intrinsic support >> for both. >> 2) Update existing, and possibly add new, tests to use the new >> internal Unsafe. Some tests may need to be duplicated, or reworked, >> to test both versions of Unsafe. >> 3) Update the Unsafe usages in the JDK so that there is no longer any >> dependency on sun.misc.Unsafe. >> >> To this end I've put together a webrev containing the changes required >> for step 1. It contains >> - the intrinsic aliasing, >> - the new internal Unsafe ( copy of sun.misc.Unsafe ), >> - reverts sun.misc.Unsafe to, almost, its 1.8 API, >> - minimal test and implementation updates, since there some usages >> of unaligned access that is new in the 1.9. >> >> http://cr.openjdk.java.net/~chegar/unsafe_phase1/ >> >> All JPRT hotspot and core libraries tests pass. >> >> I have most of the work for steps 2 and 3 done, but some discussion and >> clean up is required. It also increase the level of difficult to review >> the changes in phase 1, which is mostly what I'd like to get agreement >> on first. >> >> -Chris. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8132928 >> [2] https://bugs.openjdk.java.net/browse/JDK-8139891 > From john.r.rose at oracle.com Fri Oct 23 01:06:27 2015 From: john.r.rose at oracle.com (John Rose) Date: Thu, 22 Oct 2015 18:06:27 -0700 Subject: 8139891: Prepare Unsafe for true encapsulation In-Reply-To: <70AE5E05-2BA2-457A-B65F-E819238509DC@oracle.com> References: <70AE5E05-2BA2-457A-B65F-E819238509DC@oracle.com> Message-ID: <85997256-3501-45DD-86B4-1F9B5E397233@oracle.com> On Oct 22, 2015, at 7:28 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote: > > To this end I've put together a webrev containing the changes required > for step 1. It contains > - the intrinsic aliasing, > - the new internal Unsafe ( copy of sun.misc.Unsafe ), > - reverts sun.misc.Unsafe to, almost, its 1.8 API, > - minimal test and implementation updates, since there some usages > of unaligned access that is new in the 1.9. > > http://cr.openjdk.java.net/~chegar/unsafe_phase1/ <http://cr.openjdk.java.net/~chegar/unsafe_phase1/> Looks good. The name jvm.internal.misc.Unsafe is begging to be split and renamed. See http://www.inf.usi.ch/faculty/lanza/Downloads/Mast2015a.pdf <http://www.inf.usi.ch/faculty/lanza/Downloads/Mast2015a.pdf> for a good example of how to put parts of Unsafe into logical buckets. But that is a task for another day. The VM changes will have to happen a second time when jvm.internal.misc.Unsafe is refactored. It is not clear how to pivot the current changes to prepare for that, since the naming conventions in the JVM are very explicit about the concrete names of intrinsics. One suggestion: I think the Method:: is_unsafe_alias is not a useful API point. I suggest making that function be a local, static helper for init_intrinsic_id. That way it doesn't have to show up in method.hpp, and that file won't have to be edited when we refactor. For a similar reason, I suggest changing the comments in library_call.cpp so that they become more vague about the location of Unsafe: -// public native void sun.misc.Unsafe.putOrderedObject(Object o, long offset, Object x); +-// public native void [sun|jdk.internal].misc.Unsafe.putOrderedObject(Object o, long offset, Object x); ++// public native void Unsafe.putOrderedObject(Object o, long offset, Object x); That way the file won't have to be re-edited if we refactor. Same point for memnode.hpp and unsafe.cpp (and maybe other spots which say too much?). It's already good in heapDumper.cpp. In globals.hpp it's half good and half not-good. BTW, I think the name SystemDictionary::internal_Unsafe_klass is future-proof in this respect. Thanks for taking this on! ? John P.S. Just for the record, the native-heap-only memory accessors should not be intrinsics, since they can be trivially derived from the normal two-argument accessors: - public native byte getByte(long address); + public native byte getByte(long address) { return getByte(null, address); } From mandy.chung at oracle.com Fri Oct 23 02:32:25 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 22 Oct 2015 19:32:25 -0700 Subject: RFR: JDK-8046565: Platform Logger API and Service In-Reply-To: <5626B6B7.2040501@oracle.com> References: <561660DA.7070900@oracle.com> <8D8890A3-2337-4178-BA5C-CC32DE12F27D@oracle.com> <561E3A9A.9050807@oracle.com> <6241BCF8-C6A3-4E64-94E9-5E70CEF4A829@oracle.com> <561E8CE7.9020609@oracle.com> <17C7339F-2107-49DE-B909-A65D779F0DF1@oracle.com> <56253412.4030800@oracle.com> <5626B6B7.2040501@oracle.com> Message-ID: <54D9FB8E-A69D-4A41-B81D-D8C1BBFC50EF@oracle.com> (sorry for the delay. I realized just now that my reply is not sent ? sigh) > On Oct 20, 2015, at 2:48 PM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote: > > Hi Mandy, > > As we discussed I have also made LogManager.demandLoggerFor > package protected. As a result I also reverted the changes > to LoggingPermission - there's no reason for exposing > a LoggingPermission("demandLogger", null) if LogManager.demandLoggerFor > is no longer visible. > I am happy that this is no longer needed to be public. > I have refreshed the content of the links & the sandbox. > > specdiff: > http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/specdiff-api/overview-summary.html > > webrev: > http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/webrev/index.html > Looking quite good. Minor nit on the javadoc: System.java 1564 * Platform classes which may be loaded early in the boot sequence and s/Platform/System/ java.util.logging.Logger The new logrb methods are missing @throws NPE if level is null. It?s also missing in existing logrb methods too. If bundle is not null, does it require msg to be non-null? I?m not certain but I see: format = catalog.getString(record.getMessage()); ResourceBundle.getString throws NPE if the key is null. 1299 * @param bundle Resource bundle to localize {@code msg}, Formatting - ?Resource bundle?? not aligned with other @param Mandy From chris.plummer at oracle.com Fri Oct 23 05:54:47 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 22 Oct 2015 22:54:47 -0700 Subject: [RFR] (S) 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests Message-ID: <5629CBA7.9070007@oracle.com> Hello, Please review the following fix for 8140189: http://cr.openjdk.java.net/~cjplummer/8140189/webrev.00/webrev.hotspot http://cr.openjdk.java.net/~cjplummer/8140189/webrev.00/webrev.jdk https://bugs.openjdk.java.net/browse/JDK-8140189 Please also see the following CR, which has much more extensive discussion of the problem: jtreg produces class files outside the JTwork directory https://bugs.openjdk.java.net/browse/CODETOOLS-7901527 All the diffs for the tests simply replace "/../../test/lib" with "/test/lib". The changes in TEST.ROOT are what allow this. It is probably much easier to look at the patch than to look at each file in the webrev. All the test diffs look pretty much like the following: - * @library /testlibrary /../../test/lib + * @library /testlibrary /test/lib or - * @library /../../test/lib/share/classes + * @library /test/lib/share/classes Tested with jprt. Also ran the following jtreg tests on a linux/x64 host with a fastdebug build: -Ran all hotspot jtreg tests. -Ran all modified jdk jtreg tests. -Ran jdk tier1 and tier2 jtreg tests. There were some failures and errors, but they were replicated when testing with a clean repo also and are unrelated to my changes. thanks, Chris From sha.jiang at oracle.com Fri Oct 23 07:48:11 2015 From: sha.jiang at oracle.com (John Jiang) Date: Fri, 23 Oct 2015 15:48:11 +0800 Subject: RFR (JAXP) - JDK-8077931: Develop tests for XML Catalog API Message-ID: <5629E63B.9070906@oracle.com> Hi all, Please help review the tests for XML Catalog API: https://bugs.openjdk.java.net/browse/JDK-8077931 The webrev is at http://cr.openjdk.java.net/~fyuan/jjiang/8077931/webrev.00/ Best regards, John Jiang From aph at redhat.com Fri Oct 23 09:14:49 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 23 Oct 2015 10:14:49 +0100 Subject: 8139891: Prepare Unsafe for true encapsulation In-Reply-To: <964676D6-A142-4B2F-AC77-59B21E7946CA@noctarius.com> References: <70AE5E05-2BA2-457A-B65F-E819238509DC@oracle.com> <964676D6-A142-4B2F-AC77-59B21E7946CA@noctarius.com> Message-ID: <5629FA89.5080605@redhat.com> On 22/10/15 15:48, Christoph Engelbert wrote: > I don?t like to say it but it sounds very wrong to have another > Unsafe like thinggy in the future instead of providing public > alternatives right from the start. I agree it might be a faster to > just write adapter classes and I really don?t like to repeat what I > said in the past but why should Oracle be able to write fast Java > code than the public? It just doesn?t make sense to me. There is a basic entitlement that anyone, within or outside Oracle, who wants to write a Java API should be able to prototype and test it on existing systems. For that to work it must be possible to enable the use of Unsafe, and this will require a command-line option. I have discussed this at some length with Oracle representatives, and it has also been discussed by the JCP Executive. We have been assured by Oracle that this will be possible. I am sure that the core library developers are aware of this and would do nothing to prevent it. Andrew. From staffan.larsen at oracle.com Fri Oct 23 14:50:59 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 23 Oct 2015 16:50:59 +0200 Subject: [RFR] (S) 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests In-Reply-To: <5629CBA7.9070007@oracle.com> References: <5629CBA7.9070007@oracle.com> Message-ID: <E547095E-4726-4F35-B3B5-AB636BF9373A@oracle.com> Looks good! Thanks for doing this. /Staffan > On 23 okt. 2015, at 07:54, Chris Plummer <chris.plummer at oracle.com> wrote: > > Hello, > > Please review the following fix for 8140189: > > http://cr.openjdk.java.net/~cjplummer/8140189/webrev.00/webrev.hotspot > http://cr.openjdk.java.net/~cjplummer/8140189/webrev.00/webrev.jdk > > https://bugs.openjdk.java.net/browse/JDK-8140189 > > Please also see the following CR, which has much more extensive discussion of the problem: > > jtreg produces class files outside the JTwork directory > https://bugs.openjdk.java.net/browse/CODETOOLS-7901527 > > All the diffs for the tests simply replace "/../../test/lib" with "/test/lib". The changes in TEST.ROOT are what allow this. It is probably much easier to look at the patch than to look at each file in the webrev. All the test diffs look pretty much like the following: > > - * @library /testlibrary /../../test/lib > + * @library /testlibrary /test/lib > > or > > - * @library /../../test/lib/share/classes > + * @library /test/lib/share/classes > > Tested with jprt. Also ran the following jtreg tests on a linux/x64 host with a fastdebug build: > > -Ran all hotspot jtreg tests. > -Ran all modified jdk jtreg tests. > -Ran jdk tier1 and tier2 jtreg tests. > > There were some failures and errors, but they were replicated when testing with a clean repo also and are unrelated to my changes. > > thanks, > > Chris > From chris.hegarty at oracle.com Fri Oct 23 14:52:28 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 23 Oct 2015 15:52:28 +0100 Subject: 8139891: Prepare Unsafe for true encapsulation In-Reply-To: <5629FA89.5080605@redhat.com> References: <70AE5E05-2BA2-457A-B65F-E819238509DC@oracle.com> <964676D6-A142-4B2F-AC77-59B21E7946CA@noctarius.com> <5629FA89.5080605@redhat.com> Message-ID: <562A49AC.8060807@oracle.com> On 23/10/15 10:14, Andrew Haley wrote: > On 22/10/15 15:48, Christoph Engelbert wrote: > >> I don?t like to say it but it sounds very wrong to have another >> Unsafe like thinggy in the future instead of providing public >> alternatives right from the start. I agree it might be a faster to >> just write adapter classes and I really don?t like to repeat what I >> said in the past but why should Oracle be able to write fast Java >> code than the public? It just doesn?t make sense to me. > > There is a basic entitlement that anyone, within or outside Oracle, > who wants to write a Java API should be able to prototype and test it > on existing systems. For that to work it must be possible to enable > the use of Unsafe, and this will require a command-line option. Yes, exactly. > I have discussed this at some length with Oracle representatives, and > it has also been discussed by the JCP Executive. We have been assured > by Oracle that this will be possible. I am sure that the core library > developers are aware of this and would do nothing to prevent it. Yes, I am aware of this. What I am proposing will in no way prevent it. The motivation for this change is so that we can maintain the existing sun.misc.Unsafe, from 1.8, to support applications and libraries currently using it. Future Unsafe enhancements should take place in the internal Unsafe equivalent, which will be accessible by a command-line flag. -Chris. > Andrew. > From daniel.fuchs at oracle.com Fri Oct 23 14:52:43 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 23 Oct 2015 16:52:43 +0200 Subject: RFR: JDK-8140364: JEP 264 Platform Logger API and Service Implementation In-Reply-To: <54D9FB8E-A69D-4A41-B81D-D8C1BBFC50EF@oracle.com> References: <561660DA.7070900@oracle.com> <8D8890A3-2337-4178-BA5C-CC32DE12F27D@oracle.com> <561E3A9A.9050807@oracle.com> <6241BCF8-C6A3-4E64-94E9-5E70CEF4A829@oracle.com> <561E8CE7.9020609@oracle.com> <17C7339F-2107-49DE-B909-A65D779F0DF1@oracle.com> <56253412.4030800@oracle.com> <5626B6B7.2040501@oracle.com> <54D9FB8E-A69D-4A41-B81D-D8C1BBFC50EF@oracle.com> Message-ID: <562A49BB.7070206@oracle.com> Hi, Please find below the online link integrating the latest editorial comments I received (from Mandy): http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/webrev/index.html http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/specdiff-api/overview-summary.html sandbox branch JDK-8046565-branch updated as well. best regards -- daniel Start of the review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035715.html Subject: RFR: JDK-8046565: Platform Logger API and Service JEP 264 JBS Issue (8046565): https://bugs.openjdk.java.net/browse/JDK-8046565 RFE that will be ultimately used to commit (8140364): https://bugs.openjdk.java.net/browse/JDK-8140364 On 23/10/15 04:32, Mandy Chung wrote: > (sorry for the delay. I realized just now that my reply is not sent ? sigh) > >> On Oct 20, 2015, at 2:48 PM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote: >> >> Hi Mandy, >> >> As we discussed I have also made LogManager.demandLoggerFor >> package protected. As a result I also reverted the changes >> to LoggingPermission - there's no reason for exposing >> a LoggingPermission("demandLogger", null) if LogManager.demandLoggerFor >> is no longer visible. >> > > I am happy that this is no longer needed to be public. > >> I have refreshed the content of the links & the sandbox. >> >> specdiff: >> http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/specdiff-api/overview-summary.html >> >> webrev: >> http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/webrev/index.html >> > > Looking quite good. > > Minor nit on the javadoc: > > System.java > 1564 * Platform classes which may be loaded early in the boot sequence and > > s/Platform/System/ > > java.util.logging.Logger > > The new logrb methods are missing @throws NPE if level is null. It?s also missing in existing logrb methods too. > > If bundle is not null, does it require msg to be non-null? I?m not certain but I see: > format = catalog.getString(record.getMessage()); > > ResourceBundle.getString throws NPE if the key is null. > > 1299 * @param bundle Resource bundle to localize {@code msg}, > > Formatting - ?Resource bundle?? not aligned with other @param > > Mandy > From miroslav.kos at oracle.com Fri Oct 23 15:07:29 2015 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Fri, 23 Oct 2015 17:07:29 +0200 Subject: [9] RFR: 8139743 regular JAX-* sync-up from standalone repos In-Reply-To: <FDDAA3A1-4FD9-496B-B653-912AC77A345D@oracle.com> References: <56211448.4040504@oracle.com> <073C6E0E-87EB-408D-813E-E0E325B4DC40@oracle.com> <56211C98.3040905@oracle.com> <7035006E-A338-4D23-B185-EC841E309988@oracle.com> <5627C066.3040306@oracle.com> <FDDAA3A1-4FD9-496B-B653-912AC77A345D@oracle.com> Message-ID: <562A4D31.9030607@oracle.com> Hi Lance, here is the new version - all the issues addressed, except for ones with extraspace - it looks it's only in specdiff, not in javadoc. http://cr.openjdk.java.net/~mkos/8139743/jaxws.03/ http://cr.openjdk.java.net/~mkos/8139743/specdiff.03/ Thanks a lot for catching all these Miran On 21/10/15 21:55, Lance Andersen wrote: > Hi Miran > > I just made a pass through the spec diff and have a few > comments/questions: > > http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/jxc/gen/config/NGCCRuntime.html > <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/tools/internal/jxc/gen/config/NGCCRuntime.html> > is the &lt, &gt correct in the new version? > > http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/xjc/generator/bean/PackageOutlineImpl.html > <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/tools/internal/xjc/generator/bean/PackageOutlineImpl.html> : > still a period in @see for getMostUsedNamespaceURI > > http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/xjc/model/CPropertyInfo.html > <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/tools/internal/xjc/model/CPropertyInfo.html>: > extra space before the period in getName > > http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/xjc/reader/Const.html > <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/tools/internal/xjc/reader/Const.html> : > Extra space before the comma > > http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/xjc/reader/relaxng/package-summary.html > <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/tools/internal/xjc/reader/relaxng/package-summary.html>: > The package summary changes seem wrong (extra and for example) > > http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/xjc/reader/relaxng/RELAXNGInternalizationLogic.ReferenceFinder.html > <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/tools/internal/xjc/reader/relaxng/RELAXNGInternalizationLogic.ReferenceFinder.html>: > change seems wrong (extra and for example) > > http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/core/ElementInfo.html > <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/core/ElementInfo.html>: > extra semi-colon after <contentMemoryType> I believe > > http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/ElementInfoImpl.html > <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/ElementInfoImpl.html> extra > semi-colon after <contentMemoryType> I believe > > http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/ElementInfoImpl.PropertyImpl.html > <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/ElementInfoImpl.PropertyImpl.html> looks > like @XmlElement was changed incorrectly? > > http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/ElementPropertyInfoImpl.html > <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/ElementPropertyInfoImpl.html> looks > like @XmlElement was changed incorrectly? > > http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/RuntimeElementInfoImpl.html > <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/RuntimeElementInfoImpl.html> extra > semi-colon? > > http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/RuntimeElementInfoImpl.RuntimePropertyImpl.html > <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/RuntimeElementInfoImpl.RuntimePropertyImpl.html> looks > like @XmlElement was changed incorrectly? > > http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/runtime/RuntimeElementPropertyInfo.html > <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/runtime/RuntimeElementPropertyInfo.html> looks > like @XmlElement was changed incorrectly? > > http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/MarshallerImpl.html > <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/MarshallerImpl.html> extra > space before ')' > > did you really mean to change & to &amp; in the following: > ------------------------ > > http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/FastInfosetStreamWriterOutput.html > <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/FastInfosetStreamWriterOutput.html> > > > http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/ForkXmlOutput.html > <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/ForkXmlOutput.html> > > > http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/IndentingUTF8XmlOutput.html > <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/IndentingUTF8XmlOutput.html> > > > http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/MTOMXmlOutput.html > <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/MTOMXmlOutput.html> > > > http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/SAXOutput.html > <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/SAXOutput.html> > > http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/StAXExStreamWriterOutput.html > <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/StAXExStreamWriterOutput.html> > > http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/UTF8XmlOutput.html > <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/UTF8XmlOutput.html> > > http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/XMLEventWriterOutput.html > <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/XMLEventWriterOutput.html> > > http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/XMLStreamWriterOutput.html > <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/XMLStreamWriterOutput.html> > > http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/XmlOutput.html > <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/XmlOutput.html> > > ------------------------ > > > http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/ws/api/pipe/PipeClonerImpl.html > <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/ws/api/pipe/PipeClonerImpl.html> - > looks like this was missing from the specdiff > > http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/javax/xml/bind/Marshaller.html > <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/javax/xml/bind/Marshaller.html> extra > space before ')' > > http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/javax/xml/bind/helpers/AbstractMarshallerImpl.html > <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/javax/xml/bind/helpers/AbstractMarshallerImpl.html> extra > space before ')' > > Best, > Lance > > On Oct 21, 2015, at 12:42 PM, Miroslav Kos <miroslav.kos at oracle.com > <mailto:miroslav.kos at oracle.com>> wrote: > >> Hi Lance, >> yes, it makes sense - after creating it and reviewing I fixed >> additional issues - please, check new version of a patch: >> http://cr.openjdk.java.net/~mkos/8139743/jaxws.02/ >> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/ >> >> Thanks >> Miran >> >> On 16/10/15 18:12, Lance Andersen wrote: >>> Hi Miran >>> >>> On Oct 16, 2015, at 11:49 AM, Miroslav Kos <miroslav.kos at oracle.com> >>> wrote: >>> >>>> Hi Lance, >>>> the javadoc fixes are just about formal issues (<tt>...</tt> for >>>> {@code .. }, broken links etc.) - there are no other changes. >>> >>> Understand, but the specdiff makes it easier to see that there are >>> no untended changes especially with the size. >>> >>> Best >>> Lance >>>> >>>> Thanks >>>> Miran >>>> >>>> >>>> On 16/10/15 17:26, Lance Andersen wrote: >>>>> Hi Miran >>>>> >>>>> Can you please provide a specdiff as that makes it easier for >>>>> javadoc review >>>>> >>>>> Best >>>>> Lance >>>>> On Oct 16, 2015, at 11:14 AM, Miroslav Kos >>>>> <miroslav.kos at oracle.com> wrote: >>>>> >>>>>> Hi, >>>>>> there is a bulk update of JAX-B/WS from upstream projects - >>>>>> webrev: http://cr.openjdk.java.net/~mkos/8139743/jaxws.01/ >>>>>> <http://cr.openjdk.java.net/%7Emkos/8139743/jaxws.01/> >>>>>> more details in issue desc: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8139743 >>>>>> >>>>>> Could I ask for a review? >>>>>> >>>>>> It's quite big (2570 lines changed): >>>>>> * many javadoc fixes >>>>>> * some performance and other fixes for SAAJ >>>>>> * findbugs issues >>>>>> >>>>>> There are issue list in the JBS, many of listed bugs were fixed >>>>>> in JDK already (they are on the list because of backporting to >>>>>> standalone) >>>>>> >>>>>> Thanks >>>>>> Miran >>>>>> >>>>> >>>>> <Mail Attachment.gif> >>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif> >>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif> >>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com> >>>>> >>>>> >>>>> >>>> >>> >>> <Mail Attachment.gif> >>> <http://oracle.com/us/design/oracle-email-sig-198324.gif> >>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif> >>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com> >>> >>> >>> >> > > <http://oracle.com/us/design/oracle-email-sig-198324.gif> > <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif> > <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com> > > > From chris.hegarty at oracle.com Fri Oct 23 19:44:54 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 23 Oct 2015 20:44:54 +0100 Subject: 8139891: Prepare Unsafe for true encapsulation In-Reply-To: <85997256-3501-45DD-86B4-1F9B5E397233@oracle.com> References: <70AE5E05-2BA2-457A-B65F-E819238509DC@oracle.com> <85997256-3501-45DD-86B4-1F9B5E397233@oracle.com> Message-ID: <1CBC95B9-9E93-4718-A00A-2A05D12820F6@oracle.com> Thanks for looking at this John. Comments inline? On 23 Oct 2015, at 02:06, John Rose <john.r.rose at oracle.com> wrote: > On Oct 22, 2015, at 7:28 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote: >> >> To this end I've put together a webrev containing the changes required >> for step 1. It contains >> - the intrinsic aliasing, >> - the new internal Unsafe ( copy of sun.misc.Unsafe ), >> - reverts sun.misc.Unsafe to, almost, its 1.8 API, >> - minimal test and implementation updates, since there some usages >> of unaligned access that is new in the 1.9. >> >> http://cr.openjdk.java.net/~chegar/unsafe_phase1/ > > Looks good. Thanks. > The name jvm.internal.misc.Unsafe is begging to be split and renamed. > See http://www.inf.usi.ch/faculty/lanza/Downloads/Mast2015a.pdf for a good example > of how to put parts of Unsafe into logical buckets. > But that is a task for another day. Right. Hopefully, once we decouple from the sun.misc namespace future refactoring will be possible. > The VM changes will have to happen a second time when jvm.internal.misc.Unsafe > is refactored. It is not clear how to pivot the current changes to prepare for that, > since the naming conventions in the JVM are very explicit about the concrete names > of intrinsics. Right. I just don?t want to make it, much, more difficult. > One suggestion: I think the Method:: is_unsafe_alias is not a useful API point. > I suggest making that function be a local, static helper for init_intrinsic_id. > That way it doesn't have to show up in method.hpp, and that file won't have > to be edited when we refactor. Thanks. Update. > For a similar reason, I suggest changing the comments in library_call.cpp > so that they become more vague about the location of Unsafe: Good idea. I had this in a previous local version, but wasn?t sure which way to go. All references, in comments, to Unsafe are now more vague. > -// public native void sun.misc.Unsafe.putOrderedObject(Object o, long offset, Object x); > +-// public native void [sun|jdk.internal].misc.Unsafe.putOrderedObject(Object o, long offset, Object x); > ++// public native void Unsafe.putOrderedObject(Object o, long offset, Object x); > > That way the file won't have to be re-edited if we refactor. Same point for > memnode.hpp and unsafe.cpp (and maybe other spots which say too much?). > It's already good in heapDumper.cpp. In globals.hpp it's half good and half not-good. Done. > BTW, I think the name SystemDictionary::internal_Unsafe_klass is future-proof in this respect. Updated webrev: http://cr.openjdk.java.net/~chegar/unsafe_phase1.01/ > Thanks for taking this on! If you are in agreement, is it best to move this first step on and push it into hs-rt. I can then follow up with the additional steps: hotspot test updates in hs-rt, and the library changes in jdk9/dev, in parallel. -Chris. > ? John > > P.S. Just for the record, the native-heap-only memory accessors should not be intrinsics, > since they can be trivially derived from the normal two-argument accessors: > - public native byte getByte(long address); > + public native byte getByte(long address) { return getByte(null, address); } > From huizhe.wang at oracle.com Fri Oct 23 19:45:35 2015 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 23 Oct 2015 12:45:35 -0700 Subject: RFR (JAXP) - JDK-8077931: Develop tests for XML Catalog API In-Reply-To: <5629E63B.9070906@oracle.com> References: <5629E63B.9070906@oracle.com> Message-ID: <562A8E5F.9050907@oracle.com> Looks good to me, John. Best regards, Joe On 10/23/2015 12:48 AM, John Jiang wrote: > Hi all, > Please help review the tests for XML Catalog API: > https://bugs.openjdk.java.net/browse/JDK-8077931 > The webrev is at > http://cr.openjdk.java.net/~fyuan/jjiang/8077931/webrev.00/ > > Best regards, > John Jiang From chris.hegarty at oracle.com Fri Oct 23 19:50:19 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 23 Oct 2015 20:50:19 +0100 Subject: 8139891: Prepare Unsafe for true encapsulation In-Reply-To: <72D16E3B-EEB8-47B4-9670-6654E3DE5138@oracle.com> References: <70AE5E05-2BA2-457A-B65F-E819238509DC@oracle.com> <DB96EE4D-0CD0-4DF3-9480-4E22E84859E2@oracle.com> <72D16E3B-EEB8-47B4-9670-6654E3DE5138@oracle.com> Message-ID: <2257344E-B5CE-43F2-973A-591A209AD49C@oracle.com> On 22 Oct 2015, at 21:23, Christian Thalinger <christian.thalinger at oracle.com> wrote: > >> On Oct 22, 2015, at 6:31 AM, Paul Sandoz <Paul.Sandoz at oracle.com> wrote: >> >> Hi Chris, >> >> This looks like a good first step. I am sure hotspot devs will have more concrete review comments, but i like the way the method aliasing (copying the same technique StrictMath -> Math) avoids any changes to the intrinsics, thus the changes are much more localized. > > Yes, me too. I was worried about a lot of changes in compiler code so I?m really happy to see this is not the case. Thanks for looking at this Christian. An earlier local version of this change did modify a lot of compiler code, but I?m relatively happy with how this turned out. >> It may be worth having some fast debugging output for the aliasing in case internal refactoring messes things up. Possibly. CheckIntrinsics, in a fast debug build, will catch if there is a mismatch. I hope to also add some new tests to the hotspot forest to make sure Unsafe continues to work as expected. -Chris. >> Paul. >> >>> On 22 Oct 2015, at 07:28, Chris Hegarty <chris.hegarty at oracle.com> wrote: >>> >>> As part of the preparation for JEP 260 [1], Unsafe needs to be separable >>> from the base module [2], so it can be exported by a new, yet to be >>> defined, jdk.unsupported module, and have a separate evolution policy >>> that is not exposed. That is, the JDK needs an internal Unsafe that can >>> be evolved and added to in future releases, while maintaining the >>> existing Unsafe API that developers are using. >>> >>> Many uses of Unsafe are for performance reasons. Any changes made >>> should preserve the current performance characteristics. To achieve this >>> the existing Unsafe intrinsic candidate methods should remain intrinsic >>> candidate methods. The VM can provide aliases for these intrinsics so >>> they are common to both the internal and sun.misc versions of Unsafe. >>> >>> The JDK implementation will be updated to use the new internal version >>> of Unsafe. >>> >>> For the purposes of making progress, I think this work can be split into >>> several steps: >>> >>> 1) Create the new internal Unsafe class and provide intrinsic support >>> for both. >>> 2) Update existing, and possibly add new, tests to use the new >>> internal Unsafe. Some tests may need to be duplicated, or reworked, >>> to test both versions of Unsafe. >>> 3) Update the Unsafe usages in the JDK so that there is no longer any >>> dependency on sun.misc.Unsafe. >>> >>> To this end I've put together a webrev containing the changes required >>> for step 1. It contains >>> - the intrinsic aliasing, >>> - the new internal Unsafe ( copy of sun.misc.Unsafe ), >>> - reverts sun.misc.Unsafe to, almost, its 1.8 API, >>> - minimal test and implementation updates, since there some usages >>> of unaligned access that is new in the 1.9. >>> >>> http://cr.openjdk.java.net/~chegar/unsafe_phase1/ >>> >>> All JPRT hotspot and core libraries tests pass. >>> >>> I have most of the work for steps 2 and 3 done, but some discussion and >>> clean up is required. It also increase the level of difficult to review >>> the changes in phase 1, which is mostly what I'd like to get agreement >>> on first. >>> >>> -Chris. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8132928 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8139891 >> > From sandhya.viswanathan at intel.com Fri Oct 23 22:57:12 2015 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Fri, 23 Oct 2015 22:57:12 +0000 Subject: SO_REUSEPORT feature support in JDK 9 for socket communication In-Reply-To: <5628FB4B.8090305@oracle.com> References: <02FCFB8477C4EF43A2AD8E0C60F3DA2B647681C8@FMSMSX112.amr.corp.intel.com> <5628DEEC.5080407@Oracle.com> <5628E382.3070509@oracle.com> <5628E596.5000203@oracle.com> <5628FB4B.8090305@oracle.com> Message-ID: <02FCFB8477C4EF43A2AD8E0C60F3DA2B6476958F@FMSMSX112.amr.corp.intel.com> Thanks for all your inputs. To start with, we will create a patch for JDK-6432031 based on JDK 9 and submit to both the core-libs-dev and net-dev mailing lists. We will include the SocketOption interface (getOption/setOption) also for this feature (we had that in our JDK 8 based prototype). As most of the platforms support SO_REUSEPORT and this feature shows significant performance benefit, it would be worthwhile to give it a try. There are other features in SocketOptions like SO_REUSEADDR which has the mechanism to handle if it is not supported by all existing platforms. Excerpts from file java/net/DatagramSocket.java below: * Note: This functionality is not supported by all existing platforms, * so it is implementation specific whether this option will be ignored * or not. However, if it is not supported then * {@link #getReuseAddress()} will always return {@code false}. * <p> * When a {@code DatagramSocket} is created the initial setting * of {@code SO_REUSEADDR} is disabled. I am hoping that we could do something similar for SO_REUSEPORT as well. Best Regards, Sandhya -----Original Message----- From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf Of Mark Sheppard Sent: Thursday, October 22, 2015 8:06 AM To: Michael McMahon; Alan Bateman; Roger Riggs; OpenJDK Dev list Cc: core-libs-dev at openjdk.java.net Subject: Re: SO_REUSEPORT feature support in JDK 9 for socket communication the following JBS item exists: https://bugs.openjdk.java.net/browse/JDK-6432031 search of windows documentation suggests that SO_REUSEPORT is still not an option man setsockopt on Solaris shows it as an option, but without precise description of semantics regards Mark On 22/10/2015 14:33, Michael McMahon wrote: > On 22/10/15 14:24, Alan Bateman wrote: >> >> >> On 22/10/2015 14:04, Roger Riggs wrote: >>> Hi Sandhya, >>> >>> The folks on net-dev at openjdk.java.net will be interested too. >> Yes, net-dev is the best list for this. >> >> One other thing to mention is the SocketOption interface and the >> setOption/getOption methods. This allows for platform or JDK-specific >> specific socket options, it also allows it to be implemented by the >> NIO SocketChannel and friends. >> >> -Alan > > and there is the jdk.net API which extends this to the java.net socket > types. > > I think a Java SE API would be fine if it is widely and consistently > implemented > across all the reference platforms and if it does not cause > compatibility issues. > > If it only works on some platforms then maybe jdk.net could be the > place for it. > > - Michael From lance.andersen at oracle.com Fri Oct 23 23:00:30 2015 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 23 Oct 2015 19:00:30 -0400 Subject: RFR (JAXP) - JDK-8077931: Develop tests for XML Catalog API In-Reply-To: <5629E63B.9070906@oracle.com> References: <5629E63B.9070906@oracle.com> Message-ID: <25647477-1297-44C6-BD0A-66BA78B355B4@oracle.com> looks ok On Oct 23, 2015, at 3:48 AM, John Jiang <sha.jiang at oracle.com> wrote: > Hi all, > Please help review the tests for XML Catalog API: https://bugs.openjdk.java.net/browse/JDK-8077931 > The webrev is at http://cr.openjdk.java.net/~fyuan/jjiang/8077931/webrev.00/ > > Best regards, > John Jiang 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 dl at cs.oswego.edu Sat Oct 24 18:09:44 2015 From: dl at cs.oswego.edu (Doug Lea) Date: Sat, 24 Oct 2015 14:09:44 -0400 Subject: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal In-Reply-To: <25B8ED3D-4B35-48F4-BF24-32D48E85343E@azul.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56164C3C.4050800@cs.oswego.edu> <561E6F04.9030708@cs.oswego.edu> <54AE479E-9891-48FB-AD47-ECED8147DABE@azul.com> <561FC6F9.1080701@cs.oswego.edu> <25B8ED3D-4B35-48F4-BF24-32D48E85343E@azul.com> Message-ID: <562BC968.70603@cs.oswego.edu> Here's one more attempt to explain why it would be a good idea to place, name, and specify this method in a way that is more general than "call this method only if you want a PAUSE instruction on a dedicated multicore x86": On 10/15/2015 01:23 PM, Gil Tene wrote: > I also don't think that the "?momentarily unable to progress until the > occurrence of one or more actions of one or more other threads. " is true: > while (!(done || (count++ > threshold))) { spinLoopHint(); } can progress > without any action by any other thread. OK, this needs better wording to rule out silly interpretations about loop bounds. See below. > > As noted in my proposed JavaDoc, I see the primary indication of the hint to > be that the reaction time to events that would cause the loop to exit (e.g. > in nanosecond units) is more important to the caller than the speed at which > the loop is executing (e.g. in "number of loop iterations per second" units). Sure. This can also be stated: class Thread { ... /** * A hint to the platform that the current thread is momentarily * unable to progress until the occurrence of one or more actions of * one or more other threads (or that its containing loop is * otherwise terminated). The method is mainly applicable in * spin-then-block constructions entailing a bounded number of * re-checks of a condition, separated by spinYield(), followed if * necessary with use of a blocking synchronization mechanism. A * spin-loop that invokes this method on each iteration is likely to * be more responsive than it would otherwise be. */ public static void spinYield(); } > Anyone running indefinite spin loops on a uniprocessor deserves whatever they > get. Yielding in order to help them out is not mercy. Let Darwin take care of > them instead. > > But indefinite user-mode spinning on many-core systems is a valid and common > use case (see the disruptor link in my previous e-mail). > In such situations the spinning loop should just be calling yield(), or > looping for a very short count (like your magic 64) and then yielding. A > "magically choose for me whether reaction time or throughput or being nice to > others is more important" call is not a useful hint IMO. > > Like in my uniprocessor comment above, any program spinning indefinitely (or > for a non-trivial amount of time) with load > # cpus deserves what it gets. The main problem here is that there are no APIs reporting whether load > # cpus, and no good prospects for them either, especially considering the use of hypervisors (that may intentionally mis-report) and tightly packed cloud nodes where the number of cpus currently available to a program may depend on random transient effects of co-placement with other services running on that node. And given that programmers cannot portably comply, the method must allow implementations that take the best course of action known to the JVM. Despite all of the above, I agree that an OK initial hotspot implementation is just to emit PAUSE if on x86 else no-op. It might be worth then experimenting with randomized branching etc on other platforms, and someday further exploring some cheap form of load detection, perhaps kicking in only upon repeated invocation. -Doug From claes.redestad at oracle.com Sat Oct 24 20:54:39 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 24 Oct 2015 22:54:39 +0200 Subject: RFR: 8066644: Fix deprecation warnings in jdk.zipfs module Message-ID: <562BF00F.6050804@oracle.com> Hiall, please review this patch which addresses deprecation warnings in jdk.zipfs module while applying the same code improvements to similar code java.util.zip.ZipUtils webrev: http://cr.openjdk.java.net/~redestad/8066644/webrev.02 bug: https://bugs.openjdk.java.net/browse/JDK-8066644 Peter Levart brought this up and provided a patch for java.util.zip.ZipUtils earlier on this list[1], but this got delayed for various reasons. I've now included a fix to an integer overflow issue[2] since discovered in java.util.zip.ZipUtils and applied it to jdk.nio.zipfs.ZipUtils as well for consistency. I've updated and given themicrobenchmarks a spin, verifying that the LocalDateTime version is still the fastest known approach. /Claes [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031714.html [2] https://bugs.openjdk.java.net/browse/JDK-8130914 From claes.redestad at oracle.com Sun Oct 25 01:27:27 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 25 Oct 2015 02:27:27 +0100 Subject: RFR: 6823565: Excessive use of HandleList class in de-serialization code causes OutOfMemory Message-ID: <562C2FFF.4020406@oracle.com> Hi, when deserializing objects with references to themselves, ObjectInputStream pointlessly marks the object as a dependency of itself, which increases memory required to deserialize certain memory graphs. bug: https://bugs.openjdk.java.net/browse/JDK-6823565 webrev: http://cr.openjdk.java.net/~redestad/6823565/webrev.01/ Testing: jtreg java/io; verified memory allocation/usage drops when reading self-referencing objects. /Claes From amaembo at gmail.com Sun Oct 25 09:29:03 2015 From: amaembo at gmail.com (Tagir F. Valeev) Date: Sun, 25 Oct 2015 15:29:03 +0600 Subject: [PATCH] Re: Incomplete JavaDoc for Collections.synchronizedXYZ In-Reply-To: <A9B48EFE-4511-47C4-BAFF-CFC48B131741@oracle.com> References: <1322955461.20151012191816@gmail.com> <A9B48EFE-4511-47C4-BAFF-CFC48B131741@oracle.com> Message-ID: <1595280341.20151025152903@gmail.com> Hello! Here's the patch. I updated JavaDoc for synchronizedSet, synchronizedSortedSet, synchronizedNavigableSet, synchronizedList, synchronizedMap, synchronizedSortedMap and synchronizedNavigableMap. Hopefully my wording is correct (English is not my native language). With best regards, Tagir Valeev. diff --git a/src/java.base/share/classes/java/util/Collections.java b/src/java.base/share/classes/java/util/Collections.java --- a/src/java.base/share/classes/java/util/Collections.java +++ b/src/java.base/share/classes/java/util/Collections.java @@ -2090,7 +2090,8 @@ * through the returned set.<p> * * It is imperative that the user manually synchronize on the returned - * set when iterating over it: + * set when traversing it via {@link Iterator}, {@link Spliterator} + * or {@link Stream}: * <pre> * Set s = Collections.synchronizedSet(new HashSet()); * ... @@ -2149,8 +2150,9 @@ * through the returned sorted set (or its views).<p> * * It is imperative that the user manually synchronize on the returned - * sorted set when iterating over it or any of its {@code subSet}, - * {@code headSet}, or {@code tailSet} views. + * sorted set when traversing it or any of its {@code subSet}, + * {@code headSet}, or {@code tailSet} views via {@link Iterator}, + * {@link Spliterator} or {@link Stream}: * <pre> * SortedSet s = Collections.synchronizedSortedSet(new TreeSet()); * ... @@ -2240,8 +2242,9 @@ * accomplished through the returned navigable set (or its views).<p> * * It is imperative that the user manually synchronize on the returned - * navigable set when iterating over it or any of its {@code subSet}, - * {@code headSet}, or {@code tailSet} views. + * navigable set when traversing it or any of its {@code subSet}, + * {@code headSet}, or {@code tailSet} views via {@link Iterator}, + * {@link Spliterator} or {@link Stream}: * <pre> * NavigableSet s = Collections.synchronizedNavigableSet(new TreeSet()); * ... @@ -2355,7 +2358,8 @@ * through the returned list.<p> * * It is imperative that the user manually synchronize on the returned - * list when iterating over it: + * list when traversing it via {@link Iterator}, {@link Spliterator} + * or {@link Stream}: * <pre> * List list = Collections.synchronizedList(new ArrayList()); * ... @@ -2523,7 +2527,8 @@ * through the returned map.<p> * * It is imperative that the user manually synchronize on the returned - * map when iterating over any of its collection views: + * map when traversing any of its collection views via {@link Iterator}, + * {@link Spliterator} or {@link Stream}: * <pre> * Map m = Collections.synchronizedMap(new HashMap()); * ... @@ -2700,9 +2705,9 @@ * through the returned sorted map (or its views).<p> * * It is imperative that the user manually synchronize on the returned - * sorted map when iterating over any of its collection views, or the - * collections views of any of its {@code subMap}, {@code headMap} or - * {@code tailMap} views. + * sorted map when traversing via {@link Iterator}, {@link Spliterator} + * or {@link Stream} any of its collection views, or the collections views + * of any of its {@code subMap}, {@code headMap} or {@code tailMap} views: * <pre> * SortedMap m = Collections.synchronizedSortedMap(new TreeMap()); * ... @@ -2797,9 +2802,9 @@ * accomplished through the returned navigable map (or its views).<p> * * It is imperative that the user manually synchronize on the returned - * navigable map when iterating over any of its collection views, or the - * collections views of any of its {@code subMap}, {@code headMap} or - * {@code tailMap} views. + * navigable map when traversing via {@link Iterator}, {@link Spliterator} + * or {@link Stream} any of its collection views, or the collections views + * of any of its {@code subMap}, {@code headMap} or {@code tailMap} views: * <pre> * NavigableMap m = Collections.synchronizedNavigableMap(new TreeMap()); * ... PS> Hi Tagir, PS> Agreed. If you wanna send a patch to this list with updates to PS> the other synchronized* methods i can review push it for you. PS> Paul. >> On 12 Oct 2015, at 15:18, Tagir F. Valeev <amaembo at gmail.com> wrote: >> >> Hello! >> >> With the introduction of Stream API the JavaDoc for >> Collections.synchronizedCollection was updated (as part of work on >> JDK-8023275): >> >> * It is imperative that the user manually synchronize on the returned >> * collection when traversing it via {@link Iterator}, {@link Spliterator} >> * or {@link Stream}: >> >> This sounds fine, but the same update is missing on other >> synchronizedXYZ methods. For example, Collections.synchronizedList >> documentation still states: >> >> * It is imperative that the user manually synchronize on the returned >> * list when iterating over it: >> >> Nothing about Spliterator and especially about Stream. The same for >> synchronizedSet, synchronizedSortedSet, synchronizedNavigableSet. Even >> though internally all of them inherit the SynchronizedCollection >> implementation, it's not specified that, for example, synchronizedSet >> behavior is somehow connected with synchronizedCollection behavior. >> >> I think, the corresponding documentation update should be added. It's >> especially important for the Stream as many people see no difference >> between >> >> collection.forEach(...); >> >> And >> >> collection.stream().forEach(...); >> >> But with synchronized collections these two lines are very different: >> the second call is not synchronized. >> >> What do you think? >> >> With best regards, >> Tagir Valeev. >> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: synch-doc-patch.txt URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20151025/84978970/synch-doc-patch.txt> From amaembo at gmail.com Sun Oct 25 16:49:26 2015 From: amaembo at gmail.com (Tagir F. Valeev) Date: Sun, 25 Oct 2015 22:49:26 +0600 Subject: Collections.emptyList().spliterator() is not ORDERED In-Reply-To: <3D197E7F-CF35-44C1-B0B7-DC9C9DAE513E@oracle.com> References: <726458471.20150906162111@gmail.com> <4B4AA2BA-DA81-486A-ACFA-8CBF2FB57DDE@oracle.com> <792598028.20150907152032@gmail.com> <3D197E7F-CF35-44C1-B0B7-DC9C9DAE513E@oracle.com> Message-ID: <18510415644.20151025224926@gmail.com> Hello! >> PS> In this case we should fix Stream.concat to check if a >> PS> spliterator reporting SIZED is empty, which will allow us to optimize the concatenation [1]. >> PS> [1] https://bugs.openjdk.java.net/browse/JDK-8022805 I tried to fix this issue, but stuck into subtle behavior change. My idea is quite straightforward: public static <T> Stream<T> concat(Stream<? extends T> a, Stream<? extends T> b) { Objects.requireNonNull(a); Objects.requireNonNull(b); @SuppressWarnings("unchecked") Spliterator<T> asplit = (Spliterator<T>) a.spliterator(); @SuppressWarnings("unchecked") Spliterator<T> bsplit = (Spliterator<T>) b.spliterator(); Spliterator<T> split; if (asplit.getExactSizeIfKnown() == 0) split = bsplit; else if (bsplit.getExactSizeIfKnown() == 0) split = asplit; else split = new Streams.ConcatSpliterator.OfRef<>(asplit, bsplit); Stream<T> stream = StreamSupport.stream(split, a.isParallel() || b.isParallel()); return stream.onClose(Streams.composedClose(a, b)); } Similar for primitive streams. The difference occurs when the fail-fast source is modified after concat operation: List<Integer> l1 = Arrays.asList(1,2,3); List<Integer> l2 = new ArrayList<>(); Stream<Integer> s = Stream.concat(l1.stream(), l2.stream()); l2.add(4); s.forEach(System.out::println); In current implementation concat binds the late-binding spliterators (by the way it's not documented and not very obvious that concat binds; probably documentation update should be considered). Thus currently this code produces 1 2 3 Exception in thread "main" java.util.ConcurrentModificationException ... However after my change the exception disappears as the l2 spliterator is not traversed at all. So do you think such behavior change is acceptable or not? Also some tests in tests/java/util/stream/ConcatTest.java which check whether the resulting spliterator is ordered should be updated as now concat may return ORDERED stream if one of the parties is UNORDERED, but SIZED and empty. Next, I'm not absolutely sure whether the case when both input streams are SIZED/empty should be handled separately (return stream on Spliterators.emptySpliterator()?) or current implementation (returning stream on second spliterator) is ok. Finally the documentation probably should mention about special handling of SIZED/empty stream. On the other hand currently it says: > The resulting stream is ordered if both of the input streams are > ordered... It does not say "if and only if", thus probably the update is unnecessary here. So what do you think about this fix in general? Is it reasonable for me to continue working on it and prepare full-fledged patch? Is there any chance that this patch will be sponsored? With best regards, Tagir Valeev. From david.holmes at oracle.com Mon Oct 26 01:41:23 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 26 Oct 2015 11:41:23 +1000 Subject: 8139891: Prepare Unsafe for true encapsulation In-Reply-To: <1CBC95B9-9E93-4718-A00A-2A05D12820F6@oracle.com> References: <70AE5E05-2BA2-457A-B65F-E819238509DC@oracle.com> <85997256-3501-45DD-86B4-1F9B5E397233@oracle.com> <1CBC95B9-9E93-4718-A00A-2A05D12820F6@oracle.com> Message-ID: <562D84C3.3040905@oracle.com> Hi Chris, > Updated webrev: > http://cr.openjdk.java.net/~chegar/unsafe_phase1.01/ > This all looks fine to me. > If you are in agreement, is it best to move this first step on and > push it into hs-rt. I can then follow up with the additional steps: > hotspot test updates in hs-rt, and the library changes in jdk9/dev, > in parallel. I would have expected all changes to stay together in the same forest (hs-rt), so I'm not clear what additional library changes in jdk9/dev you are referring to here. Thanks, David On 24/10/2015 5:44 AM, Chris Hegarty wrote: > Thanks for looking at this John. Comments inline? > > On 23 Oct 2015, at 02:06, John Rose <john.r.rose at oracle.com> wrote: > >> On Oct 22, 2015, at 7:28 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote: >>> >>> To this end I've put together a webrev containing the changes required >>> for step 1. It contains >>> - the intrinsic aliasing, >>> - the new internal Unsafe ( copy of sun.misc.Unsafe ), >>> - reverts sun.misc.Unsafe to, almost, its 1.8 API, >>> - minimal test and implementation updates, since there some usages >>> of unaligned access that is new in the 1.9. >>> >>> http://cr.openjdk.java.net/~chegar/unsafe_phase1/ >> >> Looks good. > > Thanks. > >> The name jvm.internal.misc.Unsafe is begging to be split and renamed. >> See http://www.inf.usi.ch/faculty/lanza/Downloads/Mast2015a.pdf for a good example >> of how to put parts of Unsafe into logical buckets. >> But that is a task for another day. > > Right. Hopefully, once we decouple from the sun.misc namespace future > refactoring will be possible. > >> The VM changes will have to happen a second time when jvm.internal.misc.Unsafe >> is refactored. It is not clear how to pivot the current changes to prepare for that, >> since the naming conventions in the JVM are very explicit about the concrete names >> of intrinsics. > > Right. I just don?t want to make it, much, more difficult. > >> One suggestion: I think the Method:: is_unsafe_alias is not a useful API point. >> I suggest making that function be a local, static helper for init_intrinsic_id. >> That way it doesn't have to show up in method.hpp, and that file won't have >> to be edited when we refactor. > > Thanks. Update. > >> For a similar reason, I suggest changing the comments in library_call.cpp >> so that they become more vague about the location of Unsafe: > > Good idea. I had this in a previous local version, but wasn?t sure > which way to go. All references, in comments, to Unsafe are now > more vague. > >> -// public native void sun.misc.Unsafe.putOrderedObject(Object o, long offset, Object x); >> +-// public native void [sun|jdk.internal].misc.Unsafe.putOrderedObject(Object o, long offset, Object x); >> ++// public native void Unsafe.putOrderedObject(Object o, long offset, Object x); >> >> That way the file won't have to be re-edited if we refactor. Same point for >> memnode.hpp and unsafe.cpp (and maybe other spots which say too much?). >> It's already good in heapDumper.cpp. In globals.hpp it's half good and half not-good. > > Done. > >> BTW, I think the name SystemDictionary::internal_Unsafe_klass is future-proof in this respect. > > Updated webrev: > http://cr.openjdk.java.net/~chegar/unsafe_phase1.01/ > >> Thanks for taking this on! > > If you are in agreement, is it best to move this first step on and > push it into hs-rt. I can then follow up with the additional steps: > hotspot test updates in hs-rt, and the library changes in jdk9/dev, > in parallel. > > -Chris. > > >> ? John >> >> P.S. Just for the record, the native-heap-only memory accessors should not be intrinsics, >> since they can be trivially derived from the normal two-argument accessors: >> - public native byte getByte(long address); >> + public native byte getByte(long address) { return getByte(null, address); } >> > From Alan.Bateman at oracle.com Mon Oct 26 01:49:35 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 26 Oct 2015 01:49:35 +0000 Subject: 8139891: Prepare Unsafe for true encapsulation In-Reply-To: <562D84C3.3040905@oracle.com> References: <70AE5E05-2BA2-457A-B65F-E819238509DC@oracle.com> <85997256-3501-45DD-86B4-1F9B5E397233@oracle.com> <1CBC95B9-9E93-4718-A00A-2A05D12820F6@oracle.com> <562D84C3.3040905@oracle.com> Message-ID: <562D86AF.8040800@oracle.com> On 26/10/2015 01:41, David Holmes wrote: >> If you are in agreement, is it best to move this first step on and >> push it into hs-rt. I can then follow up with the additional steps: >> hotspot test updates in hs-rt, and the library changes in jdk9/dev, >> in parallel. > > I would have expected all changes to stay together in the same forest > (hs-rt), so I'm not clear what additional library changes in jdk9/dev > you are referring to here. It all looks fine to me too. Once this first phase gets to jdk9/dev then the rest of the library code using sun.misc.Unsafe can be switched to the jdk.internal version. They could move in the first phase too but that makes it a bigger patch so I think Chris has wisely limited the library changes to just those that are using methods that are new in 9. -Alan From david.holmes at oracle.com Mon Oct 26 02:02:14 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 26 Oct 2015 12:02:14 +1000 Subject: 8139891: Prepare Unsafe for true encapsulation In-Reply-To: <562D86AF.8040800@oracle.com> References: <70AE5E05-2BA2-457A-B65F-E819238509DC@oracle.com> <85997256-3501-45DD-86B4-1F9B5E397233@oracle.com> <1CBC95B9-9E93-4718-A00A-2A05D12820F6@oracle.com> <562D84C3.3040905@oracle.com> <562D86AF.8040800@oracle.com> Message-ID: <562D89A6.7060200@oracle.com> On 26/10/2015 11:49 AM, Alan Bateman wrote: > On 26/10/2015 01:41, David Holmes wrote: > >>> If you are in agreement, is it best to move this first step on and >>> push it into hs-rt. I can then follow up with the additional steps: >>> hotspot test updates in hs-rt, and the library changes in jdk9/dev, >>> in parallel. >> >> I would have expected all changes to stay together in the same forest >> (hs-rt), so I'm not clear what additional library changes in jdk9/dev >> you are referring to here. > It all looks fine to me too. Once this first phase gets to jdk9/dev then > the rest of the library code using sun.misc.Unsafe can be switched to > the jdk.internal version. They could move in the first phase too but > that makes it a bigger patch so I think Chris has wisely limited the > library changes to just those that are using methods that are new in 9. Thanks Alan! Phased approach is perfectly fine and understandable, but waiting till phase 1 hits jdk9/dev will introduce a delay that need not occur if phase 2 also goes to hs-rt. Up to Chris of course - he may have other things to keep him busy until these changes propagate. :) Thanks, David > -Alan From sha.jiang at oracle.com Mon Oct 26 02:42:19 2015 From: sha.jiang at oracle.com (John Jiang) Date: Mon, 26 Oct 2015 10:42:19 +0800 Subject: RFR (JAXP) - JDK-8077931: Develop tests for XML Catalog API In-Reply-To: <562A8E5F.9050907@oracle.com> References: <5629E63B.9070906@oracle.com> <562A8E5F.9050907@oracle.com> Message-ID: <562D930B.2090706@oracle.com> Hi Joe, Thanks for your review! Best regards, John Jiang On 2015/10/24 3:45, huizhe wang wrote: > Looks good to me, John. > > Best regards, > Joe > > On 10/23/2015 12:48 AM, John Jiang wrote: >> Hi all, >> Please help review the tests for XML Catalog API: >> https://bugs.openjdk.java.net/browse/JDK-8077931 >> The webrev is at >> http://cr.openjdk.java.net/~fyuan/jjiang/8077931/webrev.00/ >> >> Best regards, >> John Jiang > > From sha.jiang at oracle.com Mon Oct 26 02:44:16 2015 From: sha.jiang at oracle.com (John Jiang) Date: Mon, 26 Oct 2015 10:44:16 +0800 Subject: RFR (JAXP) - JDK-8077931: Develop tests for XML Catalog API In-Reply-To: <25647477-1297-44C6-BD0A-66BA78B355B4@oracle.com> References: <5629E63B.9070906@oracle.com> <25647477-1297-44C6-BD0A-66BA78B355B4@oracle.com> Message-ID: <562D937F.3000004@oracle.com> Hi Lance, Thanks for your review! Best regards. John Jiang On 2015/10/24 7:00, Lance Andersen wrote: > looks ok > On Oct 23, 2015, at 3:48 AM, John Jiang <sha.jiang at oracle.com > <mailto:sha.jiang at oracle.com>> wrote: > >> Hi all, >> Please help review the tests for XML Catalog API: >> https://bugs.openjdk.java.net/browse/JDK-8077931 >> The webrev is at >> http://cr.openjdk.java.net/~fyuan/jjiang/8077931/webrev.00/ >> <http://cr.openjdk.java.net/%7Efyuan/jjiang/8077931/webrev.00/> >> >> Best regards, >> John Jiang > > <http://oracle.com/us/design/oracle-email-sig-198324.gif> > <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif> > <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com> > > > From chris.hegarty at oracle.com Mon Oct 26 09:06:24 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 26 Oct 2015 09:06:24 +0000 Subject: 8139891: Prepare Unsafe for true encapsulation In-Reply-To: <562D86AF.8040800@oracle.com> References: <70AE5E05-2BA2-457A-B65F-E819238509DC@oracle.com> <85997256-3501-45DD-86B4-1F9B5E397233@oracle.com> <1CBC95B9-9E93-4718-A00A-2A05D12820F6@oracle.com> <562D84C3.3040905@oracle.com> <562D86AF.8040800@oracle.com> Message-ID: <D769400C-5151-4C48-A72B-C3437B640F8A@oracle.com> Hi David, Alan, > On 26 Oct 2015, at 01:49, Alan Bateman <Alan.Bateman at oracle.com> wrote: > > On 26/10/2015 01:41, David Holmes wrote: > >>> If you are in agreement, is it best to move this first step on and >>> push it into hs-rt. I can then follow up with the additional steps: >>> hotspot test updates in hs-rt, and the library changes in jdk9/dev, >>> in parallel. >> >> I would have expected all changes to stay together in the same forest (hs-rt), so I'm not clear what additional library changes in jdk9/dev you are referring to here. > It all looks fine to me too. Thanks David and Alan for the reviews. > Once this first phase gets to jdk9/dev then the rest of the library code using sun.misc.Unsafe can be switched to the jdk.internal version. They could move in the first phase too but that makes it a bigger patch so I think Chris has wisely limited the library changes to just those that are using methods that are new in 9. Exactly. I have a little more work to do converting the library code to use the internal Unsafe. For one, I?m running into a build issue with idk.vm.ci, I think it may be built with the boot JDK? Anyway, I don?t want to block the changes for phase 1, the remainder of the changes are not so significant ( in that they effectively amount to import changes ). Thanks, -Chris From miroslav.kos at oracle.com Mon Oct 26 12:59:42 2015 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Mon, 26 Oct 2015 13:59:42 +0100 Subject: [RFR]: 8131334: SAAJ Plugability Layer: using java.util.ServiceLoader Message-ID: <562E23BE.5030607@oracle.com> Hi everybody, I'd like to ask you for a review for 8131334: SAAJ Plugability Layer: using java.util.ServiceLoader It is about changes in pluggability layer - there was a proprietary service loading implementation which was not fully compatible with to use java.util.ServiceLoader facility. There are similar changes in all JAX-* APIs specs - JAX-B, JAX-WS and SAAJ. JBS: https://bugs.openjdk.java.net/browse/JDK-8131334 webrev: http://cr.openjdk.java.net/~mkos/8131334/jaxws.01/ specdiff: http://cr.openjdk.java.net/~mkos/8131334/specdiff.09/ Testing - there are tests in standalone project to ensure there that the old behavior is still supported. Thanks Miran From michael.haupt at oracle.com Mon Oct 26 15:13:51 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 26 Oct 2015 16:13:51 +0100 Subject: RFR(XS): 8136967: revert all changes applied to obtain information about 8131129 Message-ID: <D91EEBF6-AEAE-4F46-9139-705389CF4327@oracle.com> Dear all, please review this change. Issue: https://bugs.openjdk.java.net/browse/JDK-8136967 Webrev: http://cr.openjdk.java.net/~mhaupt/8136967/webrev.00/ This reverts the changes introduced with http://hg.openjdk.java.net/jdk9/dev/jdk/rev/69f78bcd65f8, which were supposed to deliver more detailed error logging for 8131129. These are no longer needed. Thanks, Michael -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment From steve.drach at oracle.com Mon Oct 26 17:26:29 2015 From: steve.drach at oracle.com (Steve Drach) Date: Mon, 26 Oct 2015 10:26:29 -0700 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <56207360.6040502@oracle.com> References: <F7C2BACE-2E86-4058-8136-F565799494F8@oracle.com> <561ED8BF.40901@oracle.com> <CC71DAAE-940B-47EB-A2F2-FFB89F2EBAD3@oracle.com> <561F16C1.6090702@oracle.com> <A8D7EE96-1238-401D-813D-E977CCD9E73F@oracle.com> <56207360.6040502@oracle.com> Message-ID: <18A22B13-E31D-45D6-A350-40C35BDDEE73@oracle.com> Hi, We?ve published another webrev for review. Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305 Webrev: http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ This one addresses the issues regarding CodeSigners, Certificates, verification, and other security issues raised in the last round, including whether third party verification is a supported use case. I also partially fixed a nitpick involving performance while searching for versioned entries, by putting in a cache for previously searched entries. And I found a way around the issue with windows being unable to delete jar files accessed through URL?s in one test. Steve > On Oct 21, 2015, at 12:54 AM, Wang Weijun <weijun.wang at oracle.com> wrote: > >> On Oct 21, 2015, at 3:17 PM, Xueming Shen <xueming.shen at oracle.com> wrote: >> >> We might want to bring in Max to take a look if what I said is really a supported use scenario. > > I haven't read Steve's latest code change. I will read if you think it's necessary. > > First, I think we agree that the multi-release jar file feature is only making use of the existing jar file format and does not intend to introduce any change to its specification. This means a JarFile signed by one JDK release should be verified by another JDK release. > > Ok, the next question is, should it modify the JarFile API? I hope not, because the JarFile API is the single entry we access a JarFile when we want to sign or verify it. I hope there is a brand new API for a multi-versioned jar file, probably a child class of JarFile, so that no matter you call getJarEntry() or entries() on it, you always get the versioned one and the unrelated ones are completely invisible. > > If this is not OK, maybe we can rename the current JarFile to RawJarFile and name the new API JarFile. Signing and verification will work on RawJarFile. > > Not sure if it's easy. > > --Max > On Oct 21, 2015, at 12:17 AM, Xueming Shen <xueming.shen at oracle.com> wrote: > > Hi Steve, > > The reifiedEntry() approach probably can help the default JarVerifier work as expected, but if I read the > code correctly I doubt you can get the expected CodSigner[] and Certificatte[] result from a "versioned" > JarFileEntry, after having read all bytes from the input stream (obtained via jzf.getInputStream(JarFileEntry)), > as the JarEntry spec suggests,. As we are passing the "reified" entry into the VerifierStream alone, without > any reference to the original jar file entry. It seems impossible for the original jar file entry can trace back to > the corresponding certificates and code signers. This might be fixed by passing in the original entry together > into the JarVerifier, but I doubt we might have a bigger issue here. I suspect with this approach an external > verifier will have no easy way to verify the digit signature of the jar entry via java.security APIs. I would assume > this is doable right now with current JarFile APIs, via a JarFile object, a Manifest and a target JarEntry. The external > can get the signature via name -> manifest->attributes->signature (basically just consider to move the > JarVerifier and couple sun.security.util classes out and use it as user code)... but with this implementation > the name now is the root entry, but the bytes you can read from the stream is from the versioned one. > We might want to bring in Max to take a look if what I said is really a supported use scenario. I might be > wrong, not a security expert :-) > > Btw, for a "normal" JarEntry/ZipEntry (not a JarFileEntry), shouldn't the getInputStream(ze) simply return > the stream for the root entry? The current implementation of getJarEntry(ze) does not seem right, as it > returns a "versioned" JarFileEntry. I don't think you want to pass this one into VerifierStream directly, > right? Again, I think it might be desired (at least the spec is not updated to say anything about "version") > to simply return the input stream for the root entry. > > One more "nitpick". searchForVersionedEntry() now lookups the versioned candidate via super.getEntry() > from version to BASE_VERSION, if the version is the latest version 9, the base is 0, we are basically doing > this search for each non-versioned-entry inside this multi-release-jar file 9 times everytime when the entry > is asked. In worse case scenario, a multi-release-jar, with huge number of entries with a small portion are > versioned to 9, and you are iterating it via "entries". Each lookup might be cheap, but it might be worth > considering adding some optimization. > > Best, > Sherman From lance.andersen at oracle.com Mon Oct 26 19:09:03 2015 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 26 Oct 2015 15:09:03 -0400 Subject: [9] RFR: 8139743 regular JAX-* sync-up from standalone repos In-Reply-To: <562A4D31.9030607@oracle.com> References: <56211448.4040504@oracle.com> <073C6E0E-87EB-408D-813E-E0E325B4DC40@oracle.com> <56211C98.3040905@oracle.com> <7035006E-A338-4D23-B185-EC841E309988@oracle.com> <5627C066.3040306@oracle.com> <FDDAA3A1-4FD9-496B-B653-912AC77A345D@oracle.com> <562A4D31.9030607@oracle.com> Message-ID: <B9378E3C-C7A5-4D5D-8746-A8EC2170174E@oracle.com> Hi Miran Overall looks OK. Couple quick points: Does the picture look correct at http://cr.openjdk.java.net/~mkos/8139743/specdiff.03/com/sun/xml/internal/bind/v2/package-summary.html? Might be made more readable http://cr.openjdk.java.net/~mkos/8139743/specdiff.03/com/sun/xml/internal/ws/api/pipe/PipeClonerImpl.html is not in the specdiff and not in the webrev. Intentional? Best Lance On Oct 23, 2015, at 11:07 AM, Miroslav Kos <miroslav.kos at oracle.com> wrote: > Hi Lance, > here is the new version - all the issues addressed, except for ones with extraspace - it looks it's only in specdiff, not in javadoc. > > http://cr.openjdk.java.net/~mkos/8139743/jaxws.03/ > http://cr.openjdk.java.net/~mkos/8139743/specdiff.03/ > > > Thanks a lot for catching all these > Miran > > > > > > On 21/10/15 21:55, Lance Andersen wrote: >> Hi Miran >> >> I just made a pass through the spec diff and have a few comments/questions: >> >> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/jxc/gen/config/NGCCRuntime.html is the &lt, &gt correct in the new version? >> >> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/xjc/generator/bean/PackageOutlineImpl.html : still a period in @see for getMostUsedNamespaceURI >> >> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/xjc/model/CPropertyInfo.html: extra space before the period in getName >> >> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/xjc/reader/Const.html : Extra space before the comma >> >> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/xjc/reader/relaxng/package-summary.html: The package summary changes seem wrong (extra and for example) >> >> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/xjc/reader/relaxng/RELAXNGInternalizationLogic.ReferenceFinder.html: change seems wrong (extra and for example) >> >> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/core/ElementInfo.html: extra semi-colon after <contentMemoryType> I believe >> >> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/ElementInfoImpl.html extra semi-colon after <contentMemoryType> I believe >> >> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/ElementInfoImpl.PropertyImpl.html looks like @XmlElement was changed incorrectly? >> >> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/ElementPropertyInfoImpl.html looks like @XmlElement was changed incorrectly? >> >> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/RuntimeElementInfoImpl.html extra semi-colon? >> >> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/RuntimeElementInfoImpl.RuntimePropertyImpl.html looks like @XmlElement was changed incorrectly? >> >> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/runtime/RuntimeElementPropertyInfo.html looks like @XmlElement was changed incorrectly? >> >> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/MarshallerImpl.html extra space before ')' >> >> did you really mean to change & to &amp; in the following: >> ------------------------ >> >> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/FastInfosetStreamWriterOutput.html >> >> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/ForkXmlOutput.html >> >> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/IndentingUTF8XmlOutput.html >> >> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/MTOMXmlOutput.html >> >> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/SAXOutput.html >> >> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/StAXExStreamWriterOutput.html >> >> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/UTF8XmlOutput.html >> >> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/XMLEventWriterOutput.html >> >> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/XMLStreamWriterOutput.html >> >> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/XmlOutput.html >> >> ------------------------ >> >> >> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/ws/api/pipe/PipeClonerImpl.html - looks like this was missing from the specdiff >> >> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/javax/xml/bind/Marshaller.html extra space before ')' >> >> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/javax/xml/bind/helpers/AbstractMarshallerImpl.html extra space before ')' >> >> Best, >> Lance >> >> On Oct 21, 2015, at 12:42 PM, Miroslav Kos <miroslav.kos at oracle.com> wrote: >> >>> Hi Lance, >>> yes, it makes sense - after creating it and reviewing I fixed additional issues - please, check new version of a patch: >>> http://cr.openjdk.java.net/~mkos/8139743/jaxws.02/ >>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/ >>> >>> Thanks >>> Miran >>> >>> On 16/10/15 18:12, Lance Andersen wrote: >>>> Hi Miran >>>> >>>> On Oct 16, 2015, at 11:49 AM, Miroslav Kos <miroslav.kos at oracle.com> wrote: >>>> >>>>> Hi Lance, >>>>> the javadoc fixes are just about formal issues (<tt>...</tt> for {@code .. }, broken links etc.) - there are no other changes. >>>> >>>> Understand, but the specdiff makes it easier to see that there are no untended changes especially with the size. >>>> >>>> Best >>>> Lance >>>>> >>>>> Thanks >>>>> Miran >>>>> >>>>> >>>>> On 16/10/15 17:26, Lance Andersen wrote: >>>>>> Hi Miran >>>>>> >>>>>> Can you please provide a specdiff as that makes it easier for javadoc review >>>>>> >>>>>> Best >>>>>> Lance >>>>>> On Oct 16, 2015, at 11:14 AM, Miroslav Kos <miroslav.kos at oracle.com> wrote: >>>>>> >>>>>>> Hi, >>>>>>> there is a bulk update of JAX-B/WS from upstream projects - >>>>>>> webrev: http://cr.openjdk.java.net/~mkos/8139743/jaxws.01/ >>>>>>> more details in issue desc: https://bugs.openjdk.java.net/browse/JDK-8139743 >>>>>>> >>>>>>> Could I ask for a review? >>>>>>> >>>>>>> It's quite big (2570 lines changed): >>>>>>> * many javadoc fixes >>>>>>> * some performance and other fixes for SAAJ >>>>>>> * findbugs issues >>>>>>> >>>>>>> There are issue list in the JBS, many of listed bugs were fixed in JDK already (they are on the list because of backporting to standalone) >>>>>>> >>>>>>> Thanks >>>>>>> Miran >>>>>>> >>>>>> >>>>>> <Mail Attachment.gif> >>>>>> >>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> <Mail Attachment.gif> >>>> >>>> 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 >>>> >>>> >>>> >>> >> >> <Mail Attachment.gif> >> >> 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.plummer at oracle.com Mon Oct 26 21:13:36 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 26 Oct 2015 14:13:36 -0700 Subject: [RFR] (S) 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests In-Reply-To: <E547095E-4726-4F35-B3B5-AB636BF9373A@oracle.com> References: <5629CBA7.9070007@oracle.com> <E547095E-4726-4F35-B3B5-AB636BF9373A@oracle.com> Message-ID: <562E9780.3090309@oracle.com> I just pulled the latest hs-rt, and got about 30 new jvmci tests that are using "/../../test/lib". I can fix them with this push, or file a separate bug or send out a fix after I do this push. If I fix with this push, do you want another review? I'll test with jprt and run the jvmci tests locally. thanks, Chris On 10/23/15 7:50 AM, Staffan Larsen wrote: > Looks good! Thanks for doing this. > > /Staffan > >> On 23 okt. 2015, at 07:54, Chris Plummer <chris.plummer at oracle.com> wrote: >> >> Hello, >> >> Please review the following fix for 8140189: >> >> http://cr.openjdk.java.net/~cjplummer/8140189/webrev.00/webrev.hotspot >> http://cr.openjdk.java.net/~cjplummer/8140189/webrev.00/webrev.jdk >> >> https://bugs.openjdk.java.net/browse/JDK-8140189 >> >> Please also see the following CR, which has much more extensive discussion of the problem: >> >> jtreg produces class files outside the JTwork directory >> https://bugs.openjdk.java.net/browse/CODETOOLS-7901527 >> >> All the diffs for the tests simply replace "/../../test/lib" with "/test/lib". The changes in TEST.ROOT are what allow this. It is probably much easier to look at the patch than to look at each file in the webrev. All the test diffs look pretty much like the following: >> >> - * @library /testlibrary /../../test/lib >> + * @library /testlibrary /test/lib >> >> or >> >> - * @library /../../test/lib/share/classes >> + * @library /test/lib/share/classes >> >> Tested with jprt. Also ran the following jtreg tests on a linux/x64 host with a fastdebug build: >> >> -Ran all hotspot jtreg tests. >> -Ran all modified jdk jtreg tests. >> -Ran jdk tier1 and tier2 jtreg tests. >> >> There were some failures and errors, but they were replicated when testing with a clean repo also and are unrelated to my changes. >> >> thanks, >> >> Chris >> From vitalyd at gmail.com Tue Oct 27 01:07:22 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 26 Oct 2015 21:07:22 -0400 Subject: [concurrency-interest] Is Reference.reachabilityFence() needed in Reference constructor? In-Reply-To: <DM2PR0501MB8758F01BC38A742903D7C79D1230@DM2PR0501MB875.namprd05.prod.outlook.com> References: <56278653.9080501@gmail.com> <5627B2E4.205@oracle.com> <5627B502.2010007@redhat.com> <5627C696.1070806@oracle.com> <B2771568-0B1B-4CD6-849F-4D4B48BCD81B@gmail.com> <DM2PR0501MB8758F01BC38A742903D7C79D1230@DM2PR0501MB875.namprd05.prod.outlook.com> Message-ID: <CAHjP37HhfcOVM4kaQrX2pWSHDy-7VsHdJcbVECCDV=o0ANP4qw@mail.gmail.com> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/5d13c9b094c4/src/share/vm/opto/library_call.cpp#l5629 C2 does inline it but intentionally forbids commoning out reads of Reference.get. However, this needs a real fix not a hack. sent from my phone On Oct 26, 2015 3:22 PM, "Justin Sampson" <jsampson at guidewire.com> wrote: > Alex Otenko wrote: > > > Wouldn't it be possible to add a test that will always be false? > > > > eg > > [...] > > if (get() != referent) { > > [...] > > > > The point being that referent would need to stay alive due to > > Java semantics to align with get() and queue assignment. > > Couldn't the compiler just inline get() as this.referent, see that > this.referent was just set to referent, and simplify this.referent > != referent to false? > > Cheers, > Justin > > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest at cs.oswego.edu > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > From xueming.shen at oracle.com Tue Oct 27 04:37:35 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 26 Oct 2015 21:37:35 -0700 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <18A22B13-E31D-45D6-A350-40C35BDDEE73@oracle.com> References: <F7C2BACE-2E86-4058-8136-F565799494F8@oracle.com> <561ED8BF.40901@oracle.com> <CC71DAAE-940B-47EB-A2F2-FFB89F2EBAD3@oracle.com> <561F16C1.6090702@oracle.com> <A8D7EE96-1238-401D-813D-E977CCD9E73F@oracle.com> <56207360.6040502@oracle.com> <18A22B13-E31D-45D6-A350-40C35BDDEE73@oracle.com> Message-ID: <562EFF8F.6070501@oracle.com> Hi Steve, I know I stared to sound like a broken record :-) But I would like to suggest the team one more time to reconsider the current decision of using the "set" methods to change the configuration setting/status of an existing JarFile to enable the multi-version support. public JarFile setVersioned(int version); public JarFile setRuntimeVersioned(); The main concern here is the current approach basically transfers the JarFile from a read-only/ immutable object with consistent behavior (to entry inquiry) to a mutable container of entries with possibility of inconsistent behavior. The newly introduced setVersioned/setRuntimeVersioned really have no way to guarantee A expected result from the updated version-enabled getEntry() method, as someone else might set an unexpected different "version" between your setting and getting, or even worse, in the middle of your entries() invocation, for example, in which you get part of your entries to version N and the rest to version M. So It might be desired to have the "versioned support" enabled in the constructor, so once you get that version enabled JarFile, it stays that way for its lifetime with consistent result for the entry inquiry, as the current API does. I do realize that there might be use case that the getEntry invoker might not have the access to the creation of the corresponding jar file (such as the use scenario in that JarURLConnection?), so you can't create a version-enabled JarFile at the very beginning via the constructor. But doesn't this also make my concern more real. If you don't have the control of the lifetime of that JarFile, you don't really have the control of who is setting or going to set the version of that mutable JarFile, right? An alternative might be to have change the setVersioned/setRuntimeVersioned() to public jarFile getVersioned(int version); public jarFile getRuntimeVersioned(); to return a new copy of the existing JarFile with the desired verisoning support. Yes, it might be too heavy from performance perspective :-) and we might have to do some tricky stuff (it would be easier if ZipJarFile is interface ...) to have a light wrapper class to delegate everything to the real one. That said, I'm fine to be told "the pros and cons were considered, and this is the best for the supported use scenario":-) In that case, it might deserve some wording in the spec notes to prepare the developer the possible unexpected. Thanks, Sherman On 10/26/15 10:26 AM, Steve Drach wrote: > Hi, > > We?ve published another webrev for review. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 > JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305 > Webrev: http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ > > This one addresses the issues regarding CodeSigners, Certificates, verification, and other security issues raised in the last round, including whether third party verification is a supported use case. I also partially fixed a nitpick involving performance while searching for versioned entries, by putting in a cache for previously searched entries. And I found a way around the issue with windows being unable to delete jar files accessed through URL?s in one test. > > Steve > >> On Oct 21, 2015, at 12:54 AM, Wang Weijun <weijun.wang at oracle.com> wrote: >> >>> On Oct 21, 2015, at 3:17 PM, Xueming Shen <xueming.shen at oracle.com> wrote: >>> >>> We might want to bring in Max to take a look if what I said is really a supported use scenario. >> I haven't read Steve's latest code change. I will read if you think it's necessary. >> >> First, I think we agree that the multi-release jar file feature is only making use of the existing jar file format and does not intend to introduce any change to its specification. This means a JarFile signed by one JDK release should be verified by another JDK release. >> >> Ok, the next question is, should it modify the JarFile API? I hope not, because the JarFile API is the single entry we access a JarFile when we want to sign or verify it. I hope there is a brand new API for a multi-versioned jar file, probably a child class of JarFile, so that no matter you call getJarEntry() or entries() on it, you always get the versioned one and the unrelated ones are completely invisible. >> >> If this is not OK, maybe we can rename the current JarFile to RawJarFile and name the new API JarFile. Signing and verification will work on RawJarFile. >> >> Not sure if it's easy. >> >> --Max >> On Oct 21, 2015, at 12:17 AM, Xueming Shen <xueming.shen at oracle.com> wrote: >> >> Hi Steve, >> >> The reifiedEntry() approach probably can help the default JarVerifier work as expected, but if I read the >> code correctly I doubt you can get the expected CodSigner[] and Certificatte[] result from a "versioned" >> JarFileEntry, after having read all bytes from the input stream (obtained via jzf.getInputStream(JarFileEntry)), >> as the JarEntry spec suggests,. As we are passing the "reified" entry into the VerifierStream alone, without >> any reference to the original jar file entry. It seems impossible for the original jar file entry can trace back to >> the corresponding certificates and code signers. This might be fixed by passing in the original entry together >> into the JarVerifier, but I doubt we might have a bigger issue here. I suspect with this approach an external >> verifier will have no easy way to verify the digit signature of the jar entry via java.security APIs. I would assume >> this is doable right now with current JarFile APIs, via a JarFile object, a Manifest and a target JarEntry. The external >> can get the signature via name -> manifest->attributes->signature (basically just consider to move the >> JarVerifier and couple sun.security.util classes out and use it as user code)... but with this implementation >> the name now is the root entry, but the bytes you can read from the stream is from the versioned one. >> We might want to bring in Max to take a look if what I said is really a supported use scenario. I might be >> wrong, not a security expert :-) >> >> Btw, for a "normal" JarEntry/ZipEntry (not a JarFileEntry), shouldn't the getInputStream(ze) simply return >> the stream for the root entry? The current implementation of getJarEntry(ze) does not seem right, as it >> returns a "versioned" JarFileEntry. I don't think you want to pass this one into VerifierStream directly, >> right? Again, I think it might be desired (at least the spec is not updated to say anything about "version") >> to simply return the input stream for the root entry. >> >> One more "nitpick". searchForVersionedEntry() now lookups the versioned candidate via super.getEntry() >> from version to BASE_VERSION, if the version is the latest version 9, the base is 0, we are basically doing >> this search for each non-versioned-entry inside this multi-release-jar file 9 times everytime when the entry >> is asked. In worse case scenario, a multi-release-jar, with huge number of entries with a small portion are >> versioned to 9, and you are iterating it via "entries". Each lookup might be cheap, but it might be worth >> considering adding some optimization. >> >> Best, >> Sherman From sundararajan.athijegannathan at oracle.com Tue Oct 27 07:55:05 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 27 Oct 2015 13:25:05 +0530 Subject: RFR(XS): 8136967: revert all changes applied to obtain information about 8131129 Message-ID: <562F2DD9.9000605@oracle.com> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/036083.html +1 -Sundar From miroslav.kos at oracle.com Tue Oct 27 10:34:33 2015 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Tue, 27 Oct 2015 11:34:33 +0100 Subject: [9] RFR: 8139743 regular JAX-* sync-up from standalone repos In-Reply-To: <B9378E3C-C7A5-4D5D-8746-A8EC2170174E@oracle.com> References: <56211448.4040504@oracle.com> <073C6E0E-87EB-408D-813E-E0E325B4DC40@oracle.com> <56211C98.3040905@oracle.com> <7035006E-A338-4D23-B185-EC841E309988@oracle.com> <5627C066.3040306@oracle.com> <FDDAA3A1-4FD9-496B-B653-912AC77A345D@oracle.com> <562A4D31.9030607@oracle.com> <B9378E3C-C7A5-4D5D-8746-A8EC2170174E@oracle.com> Message-ID: <562F5339.4000803@oracle.com> Thanks, good catch - fixed: http://cr.openjdk.java.net/~mkos/8139743/jaxws.04/index.html http://cr.openjdk.java.net/~mkos/8139743/specdiff.04/index.html Regarding PipeClonerImpl - yes, there is no change - originally there was probably some unintentional change (?) Thanks Miran On 26/10/15 20:09, Lance Andersen wrote: > Hi Miran > > Overall looks OK. Couple quick points: > > > Does the picture look correct at > http://cr.openjdk.java.net/~mkos/8139743/specdiff.03/com/sun/xml/internal/bind/v2/package-summary.html > <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.03/com/sun/xml/internal/bind/v2/package-summary.html>? > Might be made more readable > > http://cr.openjdk.java.net/~mkos/8139743/specdiff.03/com/sun/xml/internal/ws/api/pipe/PipeClonerImpl.html > <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.03/com/sun/xml/internal/ws/api/pipe/PipeClonerImpl.html> is > not in the specdiff and not in the webrev. Intentional? > > > Best > Lance > > > On Oct 23, 2015, at 11:07 AM, Miroslav Kos <miroslav.kos at oracle.com > <mailto:miroslav.kos at oracle.com>> wrote: > >> Hi Lance, >> here is the new version - all the issues addressed, except for ones >> with extraspace - it looks it's only in specdiff, not in javadoc. >> >> http://cr.openjdk.java.net/~mkos/8139743/jaxws.03/ >> http://cr.openjdk.java.net/~mkos/8139743/specdiff.03/ >> >> >> Thanks a lot for catching all these >> Miran >> >> >> >> >> >> On 21/10/15 21:55, Lance Andersen wrote: >>> Hi Miran >>> >>> I just made a pass through the spec diff and have a few >>> comments/questions: >>> >>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/jxc/gen/config/NGCCRuntime.html >>> <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/tools/internal/jxc/gen/config/NGCCRuntime.html> >>> is the &lt, &gt correct in the new version? >>> >>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/xjc/generator/bean/PackageOutlineImpl.html >>> <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/tools/internal/xjc/generator/bean/PackageOutlineImpl.html> : >>> still a period in @see for getMostUsedNamespaceURI >>> >>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/xjc/model/CPropertyInfo.html >>> <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/tools/internal/xjc/model/CPropertyInfo.html>: >>> extra space before the period in getName >>> >>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/xjc/reader/Const.html >>> <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/tools/internal/xjc/reader/Const.html> : >>> Extra space before the comma >>> >>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/xjc/reader/relaxng/package-summary.html >>> <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/tools/internal/xjc/reader/relaxng/package-summary.html>: >>> The package summary changes seem wrong (extra and for example) >>> >>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/xjc/reader/relaxng/RELAXNGInternalizationLogic.ReferenceFinder.html >>> <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/tools/internal/xjc/reader/relaxng/RELAXNGInternalizationLogic.ReferenceFinder.html>: >>> change seems wrong (extra and for example) >>> >>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/core/ElementInfo.html >>> <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/core/ElementInfo.html>: >>> extra semi-colon after <contentMemoryType> I believe >>> >>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/ElementInfoImpl.html >>> <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/ElementInfoImpl.html> extra >>> semi-colon after <contentMemoryType> I believe >>> >>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/ElementInfoImpl.PropertyImpl.html >>> <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/ElementInfoImpl.PropertyImpl.html> looks >>> like @XmlElement was changed incorrectly? >>> >>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/ElementPropertyInfoImpl.html >>> <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/ElementPropertyInfoImpl.html> looks >>> like @XmlElement was changed incorrectly? >>> >>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/RuntimeElementInfoImpl.html >>> <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/RuntimeElementInfoImpl.html> extra >>> semi-colon? >>> >>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/RuntimeElementInfoImpl.RuntimePropertyImpl.html >>> <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/RuntimeElementInfoImpl.RuntimePropertyImpl.html> looks >>> like @XmlElement was changed incorrectly? >>> >>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/runtime/RuntimeElementPropertyInfo.html >>> <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/runtime/RuntimeElementPropertyInfo.html> looks >>> like @XmlElement was changed incorrectly? >>> >>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/MarshallerImpl.html >>> <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/MarshallerImpl.html> extra >>> space before ')' >>> >>> did you really mean to change & to &amp; in the following: >>> ------------------------ >>> >>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/FastInfosetStreamWriterOutput.html >>> <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/FastInfosetStreamWriterOutput.html> >>> >>> >>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/ForkXmlOutput.html >>> <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/ForkXmlOutput.html> >>> >>> >>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/IndentingUTF8XmlOutput.html >>> <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/IndentingUTF8XmlOutput.html> >>> >>> >>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/MTOMXmlOutput.html >>> <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/MTOMXmlOutput.html> >>> >>> >>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/SAXOutput.html >>> <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/SAXOutput.html> >>> >>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/StAXExStreamWriterOutput.html >>> <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/StAXExStreamWriterOutput.html> >>> >>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/UTF8XmlOutput.html >>> <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/UTF8XmlOutput.html> >>> >>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/XMLEventWriterOutput.html >>> <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/XMLEventWriterOutput.html> >>> >>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/XMLStreamWriterOutput.html >>> <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/XMLStreamWriterOutput.html> >>> >>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/XmlOutput.html >>> <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/XmlOutput.html> >>> >>> ------------------------ >>> >>> >>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/ws/api/pipe/PipeClonerImpl.html >>> <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/ws/api/pipe/PipeClonerImpl.html> - >>> looks like this was missing from the specdiff >>> >>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/javax/xml/bind/Marshaller.html >>> <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/javax/xml/bind/Marshaller.html> extra >>> space before ')' >>> >>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/javax/xml/bind/helpers/AbstractMarshallerImpl.html >>> <http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/javax/xml/bind/helpers/AbstractMarshallerImpl.html> extra >>> space before ')' >>> >>> Best, >>> Lance >>> >>> On Oct 21, 2015, at 12:42 PM, Miroslav Kos <miroslav.kos at oracle.com> >>> wrote: >>> >>>> Hi Lance, >>>> yes, it makes sense - after creating it and reviewing I fixed >>>> additional issues - please, check new version of a patch: >>>> http://cr.openjdk.java.net/~mkos/8139743/jaxws.02/ >>>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/ >>>> >>>> Thanks >>>> Miran >>>> >>>> On 16/10/15 18:12, Lance Andersen wrote: >>>>> Hi Miran >>>>> >>>>> On Oct 16, 2015, at 11:49 AM, Miroslav Kos >>>>> <miroslav.kos at oracle.com> wrote: >>>>> >>>>>> Hi Lance, >>>>>> the javadoc fixes are just about formal issues (<tt>...</tt> for >>>>>> {@code .. }, broken links etc.) - there are no other changes. >>>>> >>>>> Understand, but the specdiff makes it easier to see that there are >>>>> no untended changes especially with the size. >>>>> >>>>> Best >>>>> Lance >>>>>> >>>>>> Thanks >>>>>> Miran >>>>>> >>>>>> >>>>>> On 16/10/15 17:26, Lance Andersen wrote: >>>>>>> Hi Miran >>>>>>> >>>>>>> Can you please provide a specdiff as that makes it easier for >>>>>>> javadoc review >>>>>>> >>>>>>> Best >>>>>>> Lance >>>>>>> On Oct 16, 2015, at 11:14 AM, Miroslav Kos >>>>>>> <miroslav.kos at oracle.com> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> there is a bulk update of JAX-B/WS from upstream projects - >>>>>>>> webrev: http://cr.openjdk.java.net/~mkos/8139743/jaxws.01/ >>>>>>>> <http://cr.openjdk.java.net/%7Emkos/8139743/jaxws.01/> >>>>>>>> more details in issue desc: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8139743 >>>>>>>> >>>>>>>> Could I ask for a review? >>>>>>>> >>>>>>>> It's quite big (2570 lines changed): >>>>>>>> * many javadoc fixes >>>>>>>> * some performance and other fixes for SAAJ >>>>>>>> * findbugs issues >>>>>>>> >>>>>>>> There are issue list in the JBS, many of listed bugs were fixed >>>>>>>> in JDK already (they are on the list because of backporting to >>>>>>>> standalone) >>>>>>>> >>>>>>>> Thanks >>>>>>>> Miran >>>>>>>> >>>>>>> >>>>>>> <Mail Attachment.gif> >>>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif> >>>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif> >>>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> <Mail Attachment.gif> >>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif> >>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif> >>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com> >>>>> >>>>> >>>>> >>>> >>> >>> <Mail Attachment.gif> >>> <http://oracle.com/us/design/oracle-email-sig-198324.gif> >>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif> >>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com> >>> >>> >>> >> > > <http://oracle.com/us/design/oracle-email-sig-198324.gif> > <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif> > <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com> > > > From david.lloyd at redhat.com Tue Oct 27 11:19:42 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 27 Oct 2015 06:19:42 -0500 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <562EFF8F.6070501@oracle.com> References: <F7C2BACE-2E86-4058-8136-F565799494F8@oracle.com> <561ED8BF.40901@oracle.com> <CC71DAAE-940B-47EB-A2F2-FFB89F2EBAD3@oracle.com> <561F16C1.6090702@oracle.com> <A8D7EE96-1238-401D-813D-E977CCD9E73F@oracle.com> <56207360.6040502@oracle.com> <18A22B13-E31D-45D6-A350-40C35BDDEE73@oracle.com> <562EFF8F.6070501@oracle.com> Message-ID: <562F5DCE.5020703@redhat.com> FWIW I agree - it's just weird to have the behavior change after the fact like that. On 10/26/2015 11:37 PM, Xueming Shen wrote: > Hi Steve, > > I know I stared to sound like a broken record :-) But I would like to > suggest the team one more > time to reconsider the current decision of using the "set" methods to > change the configuration > setting/status of an existing JarFile to enable the multi-version support. > > public JarFile setVersioned(int version); > public JarFile setRuntimeVersioned(); > > The main concern here is the current approach basically transfers the > JarFile from a read-only/ > immutable object with consistent behavior (to entry inquiry) to a > mutable container of entries > with possibility of inconsistent behavior. The newly introduced > setVersioned/setRuntimeVersioned > really have no way to guarantee A expected result from the updated > version-enabled getEntry() > method, as someone else might set an unexpected different "version" > between your setting and > getting, or even worse, in the middle of your entries() invocation, for > example, in which you get > part of your entries to version N and the rest to version M. > > So It might be desired to have the "versioned support" enabled in the > constructor, so once you > get that version enabled JarFile, it stays that way for its lifetime > with consistent result for the > entry inquiry, as the current API does. > > I do realize that there might be use case that the getEntry invoker > might not have the access to > the creation of the corresponding jar file (such as the use scenario in > that JarURLConnection?), so > you can't create a version-enabled JarFile at the very beginning via the > constructor. But doesn't > this also make my concern more real. If you don't have the control of > the lifetime of that JarFile, > you don't really have the control of who is setting or going to set the > version of that mutable JarFile, > right? > > An alternative might be to have change the > setVersioned/setRuntimeVersioned() to > > public jarFile getVersioned(int version); > public jarFile getRuntimeVersioned(); > > to return a new copy of the existing JarFile with the desired verisoning > support. Yes, it might be > too heavy from performance perspective :-) and we might have to do some > tricky stuff (it would > be easier if ZipJarFile is interface ...) to have a light wrapper class > to delegate everything to the > real one. > > That said, I'm fine to be told "the pros and cons were considered, and > this is the best for the > supported use scenario":-) In that case, it might deserve some wording > in the spec notes to > prepare the developer the possible unexpected. > > Thanks, > Sherman > > > On 10/26/15 10:26 AM, Steve Drach wrote: >> Hi, >> >> We?ve published another webrev for review. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 >> JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305 >> Webrev: http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ >> >> This one addresses the issues regarding CodeSigners, Certificates, >> verification, and other security issues raised in the last round, >> including whether third party verification is a supported use case. I >> also partially fixed a nitpick involving performance while searching >> for versioned entries, by putting in a cache for previously searched >> entries. And I found a way around the issue with windows being unable >> to delete jar files accessed through URL?s in one test. >> >> Steve >> >>> On Oct 21, 2015, at 12:54 AM, Wang Weijun <weijun.wang at oracle.com> >>> wrote: >>> >>>> On Oct 21, 2015, at 3:17 PM, Xueming Shen <xueming.shen at oracle.com> >>>> wrote: >>>> >>>> We might want to bring in Max to take a look if what I said is >>>> really a supported use scenario. >>> I haven't read Steve's latest code change. I will read if you think >>> it's necessary. >>> >>> First, I think we agree that the multi-release jar file feature is >>> only making use of the existing jar file format and does not intend >>> to introduce any change to its specification. This means a JarFile >>> signed by one JDK release should be verified by another JDK release. >>> >>> Ok, the next question is, should it modify the JarFile API? I hope >>> not, because the JarFile API is the single entry we access a JarFile >>> when we want to sign or verify it. I hope there is a brand new API >>> for a multi-versioned jar file, probably a child class of JarFile, so >>> that no matter you call getJarEntry() or entries() on it, you always >>> get the versioned one and the unrelated ones are completely invisible. >>> >>> If this is not OK, maybe we can rename the current JarFile to >>> RawJarFile and name the new API JarFile. Signing and verification >>> will work on RawJarFile. >>> >>> Not sure if it's easy. >>> >>> --Max >>> On Oct 21, 2015, at 12:17 AM, Xueming Shen <xueming.shen at oracle.com> >>> wrote: >>> >>> Hi Steve, >>> >>> The reifiedEntry() approach probably can help the default JarVerifier >>> work as expected, but if I read the >>> code correctly I doubt you can get the expected CodSigner[] and >>> Certificatte[] result from a "versioned" >>> JarFileEntry, after having read all bytes from the input stream >>> (obtained via jzf.getInputStream(JarFileEntry)), >>> as the JarEntry spec suggests,. As we are passing the "reified" entry >>> into the VerifierStream alone, without >>> any reference to the original jar file entry. It seems impossible >>> for the original jar file entry can trace back to >>> the corresponding certificates and code signers. This might be fixed >>> by passing in the original entry together >>> into the JarVerifier, but I doubt we might have a bigger issue here. >>> I suspect with this approach an external >>> verifier will have no easy way to verify the digit signature of the >>> jar entry via java.security APIs. I would assume >>> this is doable right now with current JarFile APIs, via a JarFile >>> object, a Manifest and a target JarEntry. The external >>> can get the signature via name -> manifest->attributes->signature >>> (basically just consider to move the >>> JarVerifier and couple sun.security.util classes out and use it as >>> user code)... but with this implementation >>> the name now is the root entry, but the bytes you can read from the >>> stream is from the versioned one. >>> We might want to bring in Max to take a look if what I said is really >>> a supported use scenario. I might be >>> wrong, not a security expert :-) >>> >>> Btw, for a "normal" JarEntry/ZipEntry (not a JarFileEntry), shouldn't >>> the getInputStream(ze) simply return >>> the stream for the root entry? The current implementation of >>> getJarEntry(ze) does not seem right, as it >>> returns a "versioned" JarFileEntry. I don't think you want to pass >>> this one into VerifierStream directly, >>> right? Again, I think it might be desired (at least the spec is not >>> updated to say anything about "version") >>> to simply return the input stream for the root entry. >>> >>> One more "nitpick". searchForVersionedEntry() now lookups the >>> versioned candidate via super.getEntry() >>> from version to BASE_VERSION, if the version is the latest version 9, >>> the base is 0, we are basically doing >>> this search for each non-versioned-entry inside this >>> multi-release-jar file 9 times everytime when the entry >>> is asked. In worse case scenario, a multi-release-jar, with huge >>> number of entries with a small portion are >>> versioned to 9, and you are iterating it via "entries". Each lookup >>> might be cheap, but it might be worth >>> considering adding some optimization. >>> >>> Best, >>> Sherman > -- - DML From aleksey.shipilev at oracle.com Tue Oct 27 13:21:18 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 27 Oct 2015 16:21:18 +0300 Subject: RFR: 6823565: Excessive use of HandleList class in de-serialization code causes OutOfMemory In-Reply-To: <562C2FFF.4020406@oracle.com> References: <562C2FFF.4020406@oracle.com> Message-ID: <562F7A4E.1010703@oracle.com> On 10/25/2015 04:27 AM, Claes Redestad wrote: > when deserializing objects with references to themselves, > ObjectInputStream pointlessly marks the object as a dependency of > itself, which increases memory required to deserialize certain memory > graphs. > > bug: https://bugs.openjdk.java.net/browse/JDK-6823565 > webrev: http://cr.openjdk.java.net/~redestad/6823565/webrev.01/ Looks fine. A comment in markDependency should probably be updated to explain that self-referenced objects are skipped. Thanks, -Aleksey From aleksey.shipilev at oracle.com Tue Oct 27 13:40:37 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 27 Oct 2015 16:40:37 +0300 Subject: RFR: 8066644: Fix deprecation warnings in jdk.zipfs module In-Reply-To: <562BF00F.6050804@oracle.com> References: <562BF00F.6050804@oracle.com> Message-ID: <562F7ED5.1020600@oracle.com> On 10/24/2015 11:54 PM, Claes Redestad wrote: > webrev: http://cr.openjdk.java.net/~redestad/8066644/webrev.02 > bug: https://bugs.openjdk.java.net/browse/JDK-8066644 Looks good. Is there really no way to use the new DateTime API, and ditch the multiplication by 1000L here? 116 return ldt.toEpochSecond( 117 ZoneId.systemDefault().getRules().getOffset(ldt)) * 1000L; Thanks, -Aleksey From claes.redestad at oracle.com Tue Oct 27 13:51:53 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 27 Oct 2015 14:51:53 +0100 Subject: RFR: 6823565: Excessive use of HandleList class in de-serialization code causes OutOfMemory In-Reply-To: <562F7A4E.1010703@oracle.com> References: <562C2FFF.4020406@oracle.com> <562F7A4E.1010703@oracle.com> Message-ID: <562F8179.9030808@oracle.com> On 2015-10-27 14:21, Aleksey Shipilev wrote: > On 10/25/2015 04:27 AM, Claes Redestad wrote: >> when deserializing objects with references to themselves, >> ObjectInputStream pointlessly marks the object as a dependency of >> itself, which increases memory required to deserialize certain memory >> graphs. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-6823565 >> webrev: http://cr.openjdk.java.net/~redestad/6823565/webrev.01/ > Looks fine. A comment in markDependency should probably be updated to > explain that self-referenced objects are skipped. Thanks for reviewing, Aleksey! How about "Additionally, no action is taken if the dependent and target are the same."? http://cr.openjdk.java.net/~redestad/6823565/webrev.02/ /Claes > > Thanks, > -Aleksey > From aleksey.shipilev at oracle.com Tue Oct 27 13:56:10 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 27 Oct 2015 16:56:10 +0300 Subject: RFR: 6823565: Excessive use of HandleList class in de-serialization code causes OutOfMemory In-Reply-To: <562F8179.9030808@oracle.com> References: <562C2FFF.4020406@oracle.com> <562F7A4E.1010703@oracle.com> <562F8179.9030808@oracle.com> Message-ID: <562F827A.1030904@oracle.com> On 10/27/2015 04:51 PM, Claes Redestad wrote: > > > On 2015-10-27 14:21, Aleksey Shipilev wrote: >> On 10/25/2015 04:27 AM, Claes Redestad wrote: >>> when deserializing objects with references to themselves, >>> ObjectInputStream pointlessly marks the object as a dependency of >>> itself, which increases memory required to deserialize certain memory >>> graphs. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-6823565 >>> webrev: http://cr.openjdk.java.net/~redestad/6823565/webrev.01/ >> Looks fine. A comment in markDependency should probably be updated to >> explain that self-referenced objects are skipped. > > Thanks for reviewing, Aleksey! > > How about "Additionally, no action is taken if the dependent and target > are the same."? > > http://cr.openjdk.java.net/~redestad/6823565/webrev.02/ Good. Thanks, -Aleksey From peter.levart at gmail.com Tue Oct 27 14:03:44 2015 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 27 Oct 2015 07:03:44 -0700 Subject: RFR: 8066644: Fix deprecation warnings in jdk.zipfs module In-Reply-To: <562BF00F.6050804@oracle.com> References: <562BF00F.6050804@oracle.com> Message-ID: <CAJUsCJBObNz3N2Tzdrkna5mZMaHoLz9i1KqhyD6JpFyQVU=EOw@mail.gmail.com> Hi Claes, Nice to see this getting in. Perhaps, as Aleksey notes, the conversion from epoch seconds to millis could be performed with TimeUnit? Regards, Peter Hiall, please review this patch which addresses deprecation warnings in jdk.zipfs module while applying the same code improvements to similar code java.util.zip.ZipUtils webrev: http://cr.openjdk.java.net/~redestad/8066644/webrev.02 bug: https://bugs.openjdk.java.net/browse/JDK-8066644 Peter Levart brought this up and provided a patch for java.util.zip.ZipUtils earlier on this list[1], but this got delayed for various reasons. I've now included a fix to an integer overflow issue[2] since discovered in java.util.zip.ZipUtils and applied it to jdk.nio.zipfs.ZipUtils as well for consistency. I've updated and given themicrobenchmarks a spin, verifying that the LocalDateTime version is still the fastest known approach. /Claes [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031714.html [2] https://bugs.openjdk.java.net/browse/JDK-8130914 From claes.redestad at oracle.com Tue Oct 27 14:09:03 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 27 Oct 2015 15:09:03 +0100 Subject: RFR: 8066644: Fix deprecation warnings in jdk.zipfs module In-Reply-To: <562F7ED5.1020600@oracle.com> References: <562BF00F.6050804@oracle.com> <562F7ED5.1020600@oracle.com> Message-ID: <562F857F.6070307@oracle.com> On 2015-10-27 14:40, Aleksey Shipilev wrote: > On 10/24/2015 11:54 PM, Claes Redestad wrote: >> webrev: http://cr.openjdk.java.net/~redestad/8066644/webrev.02 >> bug: https://bugs.openjdk.java.net/browse/JDK-8066644 > Looks good. > > Is there really no way to use the new DateTime API, and ditch the > multiplication by 1000L here? > > 116 return ldt.toEpochSecond( > 117 ZoneId.systemDefault().getRules().getOffset(ldt)) * 1000L; I guess using java.util.concurrent.TimeUnit might suffice: return TimeUnit.MILLISECONDS.convert(ldt.toEpochSecond(...), TimeUnit.SECONDS); The idiomatic DateTime way I guess would be to do: return Duration.ofSeconds(ldt.toEpochSecond(), 0).toMillis(); I'll take these for a spin; properly inlined either variant might be performance neutral. /Claes > > Thanks, > -Aleksey > > From roger.riggs at oracle.com Tue Oct 27 14:28:05 2015 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 27 Oct 2015 07:28:05 -0700 Subject: RFR 9: 8139345: java/lang/ProcessHandle/TreeTest.java test fails... Message-ID: <562F89F5.7000307@oracle.com> The ProcessHandle TreeTest continues to fail intermittently. Please review adding additions to diagnose the failure. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-treetest-8139345/ Thanks, Roger From roger.riggs at oracle.com Tue Oct 27 14:48:12 2015 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 27 Oct 2015 07:48:12 -0700 Subject: RFR 9 8140598 : Unused variable stream in freetypeScaler.c fails compilation Message-ID: <562F8EAC.1090401@oracle.com> Please review a minor fix to remove an unused variable that can causes a build warning/failure. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-unused-local-stream-8140598/ Thanks, Roger From roger.riggs at oracle.com Tue Oct 27 14:52:33 2015 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 27 Oct 2015 07:52:33 -0700 Subject: RFR 9 8140598 : Unused variable stream in freetypeScaler.c fails compilation (never mind) In-Reply-To: <562F8EAC.1090401@oracle.com> References: <562F8EAC.1090401@oracle.com> Message-ID: <562F8FB1.5070000@oracle.com> It seems to already have been taken care of. Sorry for the noise. http://mail.openjdk.java.net/pipermail/2d-dev/2015-October/005785.html Roger On 10/27/15 7:48 AM, Roger Riggs wrote: > Please review a minor fix to remove an unused variable that can causes > a build warning/failure. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-unused-local-stream-8140598/ > > Thanks, Roger > From aleksey.shipilev at oracle.com Tue Oct 27 14:53:02 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 27 Oct 2015 17:53:02 +0300 Subject: RFR 9 8140598 : Unused variable stream in freetypeScaler.c fails compilation In-Reply-To: <562F8EAC.1090401@oracle.com> References: <562F8EAC.1090401@oracle.com> Message-ID: <562F8FCE.3060601@oracle.com> On 10/27/2015 05:48 PM, Roger Riggs wrote: > Please review a minor fix to remove an unused variable that can causes a > build warning/failure. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-unused-local-stream-8140598/ I think that one is already fixed: http://hg.openjdk.java.net/jdk9/client/jdk/rev/dfeaf40df800 Thanks, -Aleksey From sebastian.sickelmann at gmx.de Tue Oct 27 04:32:47 2015 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Tue, 27 Oct 2015 05:32:47 +0100 Subject: RFR: 5108778 Too many instances of java.lang.Boolean created in Java application(core-libs) Message-ID: <562EFE6F.7050407@gmx.de> Hello, Actually I am searching through the JBS for low hanging fruits. Right now i am looking through the openjdk-sources and try to evaluate if i can make something about JDK-5108778. Please find my webrevs for the jaxp, jaxws and corba repos at: http://cr.openjdk.java.net/~sebastian/5108778/jaxp/webrev.00/ http://cr.openjdk.java.net/~sebastian/5108778/jaxws/webrev.00/ http://cr.openjdk.java.net/~sebastian/5108778/corba/webrev.00/ I hope for jaxp,jaxws and corba this mailinglist is also the right place. jaxp: For the change in XBoolean (jaxp) i thought it would be more readable than the autoboxing solution. jaxws: The changes in jaxws are in a generated class. I would love to fix this in the source, but i have no clue where the real source could be. corba: For all calls against com.sun.tools.corba.se.idl.constExpr.Expression.value(Object) i used the valueOf solution instead of the autoboxing for better readability. -- Sebastian From claes.redestad at oracle.com Tue Oct 27 15:37:29 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 27 Oct 2015 16:37:29 +0100 Subject: RFR: 8066644: Fix deprecation warnings in jdk.zipfs module In-Reply-To: <562F857F.6070307@oracle.com> References: <562BF00F.6050804@oracle.com> <562F7ED5.1020600@oracle.com> <562F857F.6070307@oracle.com> Message-ID: <562F9A39.70200@oracle.com> On 2015-10-27 15:09, Claes Redestad wrote: > > > On 2015-10-27 14:40, Aleksey Shipilev wrote: >> On 10/24/2015 11:54 PM, Claes Redestad wrote: >>> webrev: <redacted> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8066644 >> Looks good. >> >> Is there really no way to use the new DateTime API, and ditch the >> multiplication by 1000L here? >> >> 116 return ldt.toEpochSecond( >> 117 ZoneId.systemDefault().getRules().getOffset(ldt)) * 1000L; > > I guess using java.util.concurrent.TimeUnit might suffice: > > return TimeUnit.MILLISECONDS.convert(ldt.toEpochSecond(...), > TimeUnit.SECONDS); > > The idiomatic DateTime way I guess would be to do: > > return Duration.ofSeconds(ldt.toEpochSecond(), 0).toMillis(); > > I'll take these for a spin; properly inlined either variant might be > performance neutral. It seems any difference between the second-to-millisecond conversion approaches is negligible under repeated testing[1], thus I think the preferred approach is to use be Duration.ofSeconds(..).toMillis(): http://cr.openjdk.java.net/~redestad/8066644/webrev.03 Thanks! /Claes Benchmark Mode Cnt Score Error Units ZipUtilsTest.dosToJavaTime_Original avgt 25 108.056 ? 1.622 ns/op ZipUtilsTest.dosToJavaTime_Duration avgt 25 105.468 ? 2.076 ns/op ZipUtilsTest.dosToJavaTime_TimeUnit avgt 25 104.318 ? 2.456 ns/op From chris.hegarty at oracle.com Tue Oct 27 15:41:29 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 27 Oct 2015 15:41:29 +0000 Subject: RFR: 6823565: Excessive use of HandleList class in de-serialization code causes OutOfMemory In-Reply-To: <562F827A.1030904@oracle.com> References: <562C2FFF.4020406@oracle.com> <562F7A4E.1010703@oracle.com> <562F8179.9030808@oracle.com> <562F827A.1030904@oracle.com> Message-ID: <674CACDD-DA8C-45AA-ABC0-6331B22EB847@oracle.com> On 27 Oct 2015, at 13:56, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote: > On 10/27/2015 04:51 PM, Claes Redestad wrote: >> >> >> On 2015-10-27 14:21, Aleksey Shipilev wrote: >>> On 10/25/2015 04:27 AM, Claes Redestad wrote: >>>> when deserializing objects with references to themselves, >>>> ObjectInputStream pointlessly marks the object as a dependency of >>>> itself, which increases memory required to deserialize certain memory >>>> graphs. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-6823565 >>>> webrev: http://cr.openjdk.java.net/~redestad/6823565/webrev.01/ >>> Looks fine. A comment in markDependency should probably be updated to >>> explain that self-referenced objects are skipped. >> >> Thanks for reviewing, Aleksey! >> >> How about "Additionally, no action is taken if the dependent and target >> are the same."? >> >> http://cr.openjdk.java.net/~redestad/6823565/webrev.02/ This looks good to me too. -Chris. > Good. > > Thanks, > -Aleksey From claes.redestad at oracle.com Tue Oct 27 15:45:53 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 27 Oct 2015 16:45:53 +0100 Subject: RFR: 6823565: Excessive use of HandleList class in de-serialization code causes OutOfMemory In-Reply-To: <674CACDD-DA8C-45AA-ABC0-6331B22EB847@oracle.com> References: <562C2FFF.4020406@oracle.com> <562F7A4E.1010703@oracle.com> <562F8179.9030808@oracle.com> <562F827A.1030904@oracle.com> <674CACDD-DA8C-45AA-ABC0-6331B22EB847@oracle.com> Message-ID: <562F9C31.4060701@oracle.com> On 2015-10-27 16:41, Chris Hegarty wrote: > On 27 Oct 2015, at 13:56, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote: > >> On 10/27/2015 04:51 PM, Claes Redestad wrote: >>> >>> On 2015-10-27 14:21, Aleksey Shipilev wrote: >>>> On 10/25/2015 04:27 AM, Claes Redestad wrote: >>>>> when deserializing objects with references to themselves, >>>>> ObjectInputStream pointlessly marks the object as a dependency of >>>>> itself, which increases memory required to deserialize certain memory >>>>> graphs. >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-6823565 >>>>> webrev: http://cr.openjdk.java.net/~redestad/6823565/webrev.01/ >>>> Looks fine. A comment in markDependency should probably be updated to >>>> explain that self-referenced objects are skipped. >>> Thanks for reviewing, Aleksey! >>> >>> How about "Additionally, no action is taken if the dependent and target >>> are the same."? >>> >>> http://cr.openjdk.java.net/~redestad/6823565/webrev.02/ > This looks good to me too. > > -Chris. Thanks for reviewing! /Claes From volker.simonis at gmail.com Tue Oct 27 18:02:07 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 27 Oct 2015 19:02:07 +0100 Subject: RFR(XXS): 8140514: [TESTBUG] enable sun/security/pkcs11 tests on Linux/ppc64 In-Reply-To: <CA+3eh138XaCped1JCKmnDC8wgurWn=ZJFqO8=y5x3adr1ov+Lw@mail.gmail.com> References: <CA+3eh138XaCped1JCKmnDC8wgurWn=ZJFqO8=y5x3adr1ov+Lw@mail.gmail.com> Message-ID: <CA+3eh13Bdd2R0NnV=ZYkee-Gd3jmpYwb5g3xc7hQUY9c4NiiTg@mail.gmail.com> Resend to core-libs-dev to attract a broader audience :) On Mon, Oct 26, 2015 at 3:32 PM, Volker Simonis <volker.simonis at gmail.com> wrote: > Hi, > > can somebody please review the following trivial fix to enable the > pkcs11 tests for linux/ppc64: > > http://cr.openjdk.java.net/~simonis/webrevs/2015/8140514/ > https://bugs.openjdk.java.net/browse/JDK-8140514 > > The pkcs11 tests need to load the native library libnss3.so the > location of which is system dependent. Until now, the test didn't > consider Linux/ppc64 systems. > > The fix is simple: just add a corresponding map entry which maps the > platform to the correct library path. All the systems I've checked > (various Fedora, OpenSUSE, SLES and RHEL distros) have libnss3.so > under /usr/lib64. > > Thank you and best regards, > Volker From lance.andersen at oracle.com Tue Oct 27 20:05:23 2015 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 27 Oct 2015 16:05:23 -0400 Subject: [9] RFR: 8139743 regular JAX-* sync-up from standalone repos In-Reply-To: <562F5339.4000803@oracle.com> References: <56211448.4040504@oracle.com> <073C6E0E-87EB-408D-813E-E0E325B4DC40@oracle.com> <56211C98.3040905@oracle.com> <7035006E-A338-4D23-B185-EC841E309988@oracle.com> <5627C066.3040306@oracle.com> <FDDAA3A1-4FD9-496B-B653-912AC77A345D@oracle.com> <562A4D31.9030607@oracle.com> <B9378E3C-C7A5-4D5D-8746-A8EC2170174E@oracle.com> <562F5339.4000803@oracle.com> Message-ID: <D807432A-CDEF-4561-B56C-D7ACCD314145@oracle.com> Ok, looks fine now On Oct 27, 2015, at 6:34 AM, Miroslav Kos <miroslav.kos at oracle.com> wrote: > Thanks, good catch - fixed: > http://cr.openjdk.java.net/~mkos/8139743/jaxws.04/index.html > http://cr.openjdk.java.net/~mkos/8139743/specdiff.04/index.html > > Regarding PipeClonerImpl - yes, there is no change - originally there was probably some unintentional change (?) > > Thanks > Miran > > > > On 26/10/15 20:09, Lance Andersen wrote: >> Hi Miran >> >> Overall looks OK. Couple quick points: >> >> >> Does the picture look correct at http://cr.openjdk.java.net/~mkos/8139743/specdiff.03/com/sun/xml/internal/bind/v2/package-summary.html? Might be made more readable >> >> http://cr.openjdk.java.net/~mkos/8139743/specdiff.03/com/sun/xml/internal/ws/api/pipe/PipeClonerImpl.html is not in the specdiff and not in the webrev. Intentional? >> >> >> Best >> Lance >> >> >> On Oct 23, 2015, at 11:07 AM, Miroslav Kos <miroslav.kos at oracle.com> wrote: >> >>> Hi Lance, >>> here is the new version - all the issues addressed, except for ones with extraspace - it looks it's only in specdiff, not in javadoc. >>> >>> http://cr.openjdk.java.net/~mkos/8139743/jaxws.03/ >>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.03/ >>> >>> >>> Thanks a lot for catching all these >>> Miran >>> >>> >>> >>> >>> >>> On 21/10/15 21:55, Lance Andersen wrote: >>>> Hi Miran >>>> >>>> I just made a pass through the spec diff and have a few comments/questions: >>>> >>>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/jxc/gen/config/NGCCRuntime.html is the &lt, &gt correct in the new version? >>>> >>>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/xjc/generator/bean/PackageOutlineImpl.html : still a period in @see for getMostUsedNamespaceURI >>>> >>>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/xjc/model/CPropertyInfo.html: extra space before the period in getName >>>> >>>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/xjc/reader/Const.html : Extra space before the comma >>>> >>>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/xjc/reader/relaxng/package-summary.html: The package summary changes seem wrong (extra and for example) >>>> >>>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/xjc/reader/relaxng/RELAXNGInternalizationLogic.ReferenceFinder.html: change seems wrong (extra and for example) >>>> >>>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/core/ElementInfo.html: extra semi-colon after <contentMemoryType> I believe >>>> >>>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/ElementInfoImpl.html extra semi-colon after <contentMemoryType> I believe >>>> >>>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/ElementInfoImpl.PropertyImpl.html looks like @XmlElement was changed incorrectly? >>>> >>>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/ElementPropertyInfoImpl.html looks like @XmlElement was changed incorrectly? >>>> >>>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/RuntimeElementInfoImpl.html extra semi-colon? >>>> >>>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/RuntimeElementInfoImpl.RuntimePropertyImpl.html looks like @XmlElement was changed incorrectly? >>>> >>>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/runtime/RuntimeElementPropertyInfo.html looks like @XmlElement was changed incorrectly? >>>> >>>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/MarshallerImpl.html extra space before ')' >>>> >>>> did you really mean to change & to &amp; in the following: >>>> ------------------------ >>>> >>>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/FastInfosetStreamWriterOutput.html >>>> >>>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/ForkXmlOutput.html >>>> >>>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/IndentingUTF8XmlOutput.html >>>> >>>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/MTOMXmlOutput.html >>>> >>>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/SAXOutput.html >>>> >>>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/StAXExStreamWriterOutput.html >>>> >>>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/UTF8XmlOutput.html >>>> >>>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/XMLEventWriterOutput.html >>>> >>>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/XMLStreamWriterOutput.html >>>> >>>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/XmlOutput.html >>>> >>>> ------------------------ >>>> >>>> >>>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/ws/api/pipe/PipeClonerImpl.html - looks like this was missing from the specdiff >>>> >>>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/javax/xml/bind/Marshaller.html extra space before ')' >>>> >>>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/javax/xml/bind/helpers/AbstractMarshallerImpl.html extra space before ')' >>>> >>>> Best, >>>> Lance >>>> >>>> On Oct 21, 2015, at 12:42 PM, Miroslav Kos <miroslav.kos at oracle.com> wrote: >>>> >>>>> Hi Lance, >>>>> yes, it makes sense - after creating it and reviewing I fixed additional issues - please, check new version of a patch: >>>>> http://cr.openjdk.java.net/~mkos/8139743/jaxws.02/ >>>>> http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/ >>>>> >>>>> Thanks >>>>> Miran >>>>> >>>>> On 16/10/15 18:12, Lance Andersen wrote: >>>>>> Hi Miran >>>>>> >>>>>> On Oct 16, 2015, at 11:49 AM, Miroslav Kos <miroslav.kos at oracle.com> wrote: >>>>>> >>>>>>> Hi Lance, >>>>>>> the javadoc fixes are just about formal issues (<tt>...</tt> for {@code .. }, broken links etc.) - there are no other changes. >>>>>> >>>>>> Understand, but the specdiff makes it easier to see that there are no untended changes especially with the size. >>>>>> >>>>>> Best >>>>>> Lance >>>>>>> >>>>>>> Thanks >>>>>>> Miran >>>>>>> >>>>>>> >>>>>>> On 16/10/15 17:26, Lance Andersen wrote: >>>>>>>> Hi Miran >>>>>>>> >>>>>>>> Can you please provide a specdiff as that makes it easier for javadoc review >>>>>>>> >>>>>>>> Best >>>>>>>> Lance >>>>>>>> On Oct 16, 2015, at 11:14 AM, Miroslav Kos <miroslav.kos at oracle.com> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> there is a bulk update of JAX-B/WS from upstream projects - >>>>>>>>> webrev: http://cr.openjdk.java.net/~mkos/8139743/jaxws.01/ >>>>>>>>> more details in issue desc: https://bugs.openjdk.java.net/browse/JDK-8139743 >>>>>>>>> >>>>>>>>> Could I ask for a review? >>>>>>>>> >>>>>>>>> It's quite big (2570 lines changed): >>>>>>>>> * many javadoc fixes >>>>>>>>> * some performance and other fixes for SAAJ >>>>>>>>> * findbugs issues >>>>>>>>> >>>>>>>>> There are issue list in the JBS, many of listed bugs were fixed in JDK already (they are on the list because of backporting to standalone) >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Miran >>>>>>>>> >>>>>>>> >>>>>>>> <Mail Attachment.gif> >>>>>>>> >>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> <Mail Attachment.gif> >>>>>> >>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> <Mail Attachment.gif> >>>> >>>> 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 >>>> >>>> >>>> >>> >> >> <Mail Attachment.gif> >> >> 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.plummer at oracle.com Wed Oct 28 05:42:52 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 27 Oct 2015 22:42:52 -0700 Subject: [RFR] (S) 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests In-Reply-To: <562EA70D.3090806@oracle.com> References: <5629CBA7.9070007@oracle.com> <E547095E-4726-4F35-B3B5-AB636BF9373A@oracle.com> <562E9780.3090309@oracle.com> <562EA70D.3090806@oracle.com> Message-ID: <5630605C.6070708@oracle.com> Hello, I've fixed the new jvmci tests. New webrevs found here: http://cr.openjdk.java.net/~cjplummer/8140189/webrev.01/webrev.hotspot http://cr.openjdk.java.net/~cjplummer/8140189/webrev.01/webrev.jdk Only the hotspot/test/compiler/jvmci files have changed since the previous webrev. If you just want to look at a patch of those changes, they can be found here: http://cr.openjdk.java.net/~cjplummer/8140189/webrev.01/jvmci.patch The changes were straight forward. In all cases for the jvmci tests the diff is: - * @library / /testlibrary /../../test/lib + * @library / /testlibrary /test/lib thanks, Chris On 10/26/15 3:19 PM, Ioi Lam wrote: > Hi Chris, > > Your changes look good to me. I think it's better to fix the jvmci > tests as well in a single push. > > Thanks > - Ioi > > On 10/26/15 2:13 PM, Chris Plummer wrote: >> I just pulled the latest hs-rt, and got about 30 new jvmci tests that >> are using "/../../test/lib". I can fix them with this push, or file a >> separate bug or send out a fix after I do this push. If I fix with >> this push, do you want another review? I'll test with jprt and run >> the jvmci tests locally. >> >> thanks, >> >> Chris >> >> >> On 10/23/15 7:50 AM, Staffan Larsen wrote: >>> Looks good! Thanks for doing this. >>> >>> /Staffan >>> >>>> On 23 okt. 2015, at 07:54, Chris Plummer <chris.plummer at oracle.com> >>>> wrote: >>>> >>>> Hello, >>>> >>>> Please review the following fix for 8140189: >>>> >>>> http://cr.openjdk.java.net/~cjplummer/8140189/webrev.00/webrev.hotspot >>>> http://cr.openjdk.java.net/~cjplummer/8140189/webrev.00/webrev.jdk >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8140189 >>>> >>>> Please also see the following CR, which has much more extensive >>>> discussion of the problem: >>>> >>>> jtreg produces class files outside the JTwork directory >>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901527 >>>> >>>> All the diffs for the tests simply replace "/../../test/lib" with >>>> "/test/lib". The changes in TEST.ROOT are what allow this. It is >>>> probably much easier to look at the patch than to look at each file >>>> in the webrev. All the test diffs look pretty much like the following: >>>> >>>> - * @library /testlibrary /../../test/lib >>>> + * @library /testlibrary /test/lib >>>> >>>> or >>>> >>>> - * @library /../../test/lib/share/classes >>>> + * @library /test/lib/share/classes >>>> >>>> Tested with jprt. Also ran the following jtreg tests on a linux/x64 >>>> host with a fastdebug build: >>>> >>>> -Ran all hotspot jtreg tests. >>>> -Ran all modified jdk jtreg tests. >>>> -Ran jdk tier1 and tier2 jtreg tests. >>>> >>>> There were some failures and errors, but they were replicated when >>>> testing with a clean repo also and are unrelated to my changes. >>>> >>>> thanks, >>>> >>>> Chris >>>> >> > From michael.haupt at oracle.com Wed Oct 28 09:19:14 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 28 Oct 2015 10:19:14 +0100 Subject: RFR(S): 8131129: Attempt to define a duplicate BMH$Species class Message-ID: <A60BF64A-8C53-4D51-A630-79E58D1A4AD8@oracle.com> Dear all, please review this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8131129 Webrev: http://cr.openjdk.java.net/~mhaupt/8131129/webrev.00/ Thanks to Peter Levart, who has contributed the actual code to fix the issue. The background of this is as follows. Bug 8131129 is an intermittent failure in a multi-threaded test for LambdaForm caching. The failure was not reproducible but used to occur on various platforms every now and then. I was able to dig up some stack traces that reveal the real cause in internal test logs. These traces finally confirmed a suspicion that both Peter and I had had but could, for lack of complete failure information, not pin down as the cause of the issue. (Most traces from failures of the test were only partial, as the test harness is selective about traces it logs.) At the heart of the problem is an overflowing code cache for adapters in the VM. The test, dynamically generating considerable amounts of LambdaForm and BoundMethodHandle species classes, would eventually trigger this overflow. The place at which the problem would surface is this, in BoundMethodHandle.Factory.generateConcreteBMHClass(): Class<? extends BoundMethodHandle> bmhClass = //UNSAFE.defineAnonymousClass(BoundMethodHandle.class, classFile, null).asSubclass(BoundMethodHandle.class); UNSAFE.defineClass(className, classFile, 0, classFile.length, BoundMethodHandle.class.getClassLoader(), null) .asSubclass(BoundMethodHandle.class); UNSAFE.ensureClassInitialized(bmhClass); The test would generate a BMH species with a given type signature via defineClass and immediately thereafter force initialisation of that class, in the course of which a SpeciesData instance is supposed to be created and entered in the BMH species cache. In case the VM's adapter code cache overflowed during this operation, the BMH species' class initialiser would not finish its execution properly, leading to a stale placeholder entry left behind in the cache. The presence of this very placeholder would trick the next request for a BMH species with the same type signature into believing the class needed to be defined, leading to the observed failure. An exemplary stack trace is appended below. Both Peter and I had come up with solutions, but I think Peter's is better as it gets rid of the somewhat intricate and semi-hidden cache registration call made from generated code. With Peter's fix, it's all visible in library code now. Thanks, Michael ----- java.lang.InternalError: java.lang.NoSuchMethodException: no such method: java.lang.invoke.MethodHandle.linkToStatic(Object,Object,int,Object,Object,Object,Object,Object,Object,Object,MemberName)Object/invokeStatic at java.lang.invoke.MethodHandleStatics.newInternalError(MethodHandleStatics.java:120) at java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:214) at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:188) at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:177) at java.lang.invoke.DirectMethodHandle.make(DirectMethodHandle.java:84) at java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:1655) at java.lang.invoke.MethodHandles$Lookup.getDirectMethod(MethodHandles.java:1600) at java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:777) at java.lang.invoke.BoundMethodHandle$Factory.makeCbmhCtor(BoundMethodHandle.java:817) at java.lang.invoke.BoundMethodHandle$Factory.makeCtors(BoundMethodHandle.java:772) at java.lang.invoke.BoundMethodHandle$SpeciesData.<init>(BoundMethodHandle.java:347) at java.lang.invoke.BoundMethodHandle$SpeciesData.getForClass(BoundMethodHandle.java:411) at java.lang.invoke.BoundMethodHandle$Species_IL7.<clinit>(Species_IL7) at sun.misc.Unsafe.ensureClassInitialized(Native Method) at java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:718) at java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) at java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:388) at java.lang.invoke.LambdaFormEditor.newSpeciesData(LambdaFormEditor.java:363) at java.lang.invoke.LambdaFormEditor.makeArgumentCombinationForm(LambdaFormEditor.java:631) at java.lang.invoke.LambdaFormEditor.filterArgumentForm(LambdaFormEditor.java:612) at java.lang.invoke.MethodHandles.filterArgument(MethodHandles.java:2667) at java.lang.invoke.MethodHandles.filterArguments(MethodHandles.java:2654) at TestMethods$4.getMH(TestMethods.java:180) at TestMethods.getTestCaseMH(TestMethods.java:548) at LFMultiThreadCachingTest.lambda$doTest$0(LFMultiThreadCachingTest.java:80) at LFMultiThreadCachingTest$$Lambda$5/21979926.run(Unknown Source) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.NoSuchMethodException: no such method: java.lang.invoke.MethodHandle.linkToStatic(Object,Object,int,Object,Object,Object,Object,Object,Object,Object,MemberName)Object/invokeStatic at java.lang.invoke.MemberName.makeAccessException(MemberName.java:873) at java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:990) at java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:212) ... 25 more Caused by: java.lang.NoSuchMethodError: java.lang.invoke.MethodHandle.linkToStatic(Ljava/lang/Object;Ljava/lang/Object;ILjava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object; at java.lang.invoke.MethodHandleNatives.resolve(Native Method) at java.lang.invoke.MemberName$Factory.resolve(MemberName.java:962) at java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:987) ... 26 more Caused by: java.lang.VirtualMachineError: out of space in CodeCache for method handle intrinsic ... 29 more java.lang.LinkageError: loader (instance of <bootloader>): attempted duplicate class definition for name: "java/lang/invoke/BoundMethodHandle$Species_IL7" at sun.misc.Unsafe.defineClass(Native Method) at java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:715) at java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) at java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:388) at java.lang.invoke.LambdaFormEditor.newSpeciesData(LambdaFormEditor.java:363) at java.lang.invoke.LambdaFormEditor.makeArgumentCombinationForm(LambdaFormEditor.java:631) at java.lang.invoke.LambdaFormEditor.filterArgumentForm(LambdaFormEditor.java:612) at java.lang.invoke.MethodHandles.filterArgument(MethodHandles.java:2667) at java.lang.invoke.MethodHandles.filterArguments(MethodHandles.java:2654) at TestMethods$4.getMH(TestMethods.java:180) at TestMethods.getTestCaseMH(TestMethods.java:548) at LFMultiThreadCachingTest.lambda$doTest$0(LFMultiThreadCachingTest.java:80) at LFMultiThreadCachingTest$$Lambda$5/21979926.run(Unknown Source) at java.lang.Thread.run(Thread.java:745) java.lang.LinkageError: loader (instance of <bootloader>): attempted duplicate class definition for name: "java/lang/invoke/BoundMethodHandle$Species_IL7" at sun.misc.Unsafe.defineClass(Native Method) at java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:715) at java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) at java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:388) at java.lang.invoke.LambdaFormEditor.newSpeciesData(LambdaFormEditor.java:363) at java.lang.invoke.LambdaFormEditor.makeArgumentCombinationForm(LambdaFormEditor.java:631) at java.lang.invoke.LambdaFormEditor.filterArgumentForm(LambdaFormEditor.java:612) at java.lang.invoke.MethodHandles.filterArgument(MethodHandles.java:2667) at java.lang.invoke.MethodHandles.filterArguments(MethodHandles.java:2654) at TestMethods$4.getMH(TestMethods.java:180) at TestMethods.getTestCaseMH(TestMethods.java:548) at LFMultiThreadCachingTest.lambda$doTest$0(LFMultiThreadCachingTest.java:80) at LFMultiThreadCachingTest$$Lambda$5/21979926.run(Unknown Source) at java.lang.Thread.run(Thread.java:745) STATUS:Failed.STATUS:Failed.STATUS:Failed.`main' threw exception: java.lang.LinkageError: loader (instance of <bootloader>): attempted duplicate class definition for name: "java/lang/invoke/BoundMethodHandle$Species_IL7" `main' threw exception: java.lang.LinkageError: loader (instance of <bootloader>): attempted duplicate class definition for name: "java/lang/invoke/BoundMethodHandle$Species_IL7" `main' threw exception: java.lang.InternalError: java.lang.NoSuchMethodException: no such method: java.lang.invoke.MethodHandle.linkToStatic(Object,Object,int,Object,Object,Object,Object,Object,Object,Object,MemberName)Object/invokeStatic java.lang.LinkageError: loader (instance of <bootloader>): attempted duplicate class definition for name: "java/lang/invoke/BoundMethodHandle$Species_IL7" at sun.misc.Unsafe.defineClass(Native Method) at java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:715) at java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) ----- -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment From vladimir.x.ivanov at oracle.com Wed Oct 28 12:02:06 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 28 Oct 2015 15:02:06 +0300 Subject: RFR(S): 8131129: Attempt to define a duplicate BMH$Species class In-Reply-To: <A60BF64A-8C53-4D51-A630-79E58D1A4AD8@oracle.com> References: <A60BF64A-8C53-4D51-A630-79E58D1A4AD8@oracle.com> Message-ID: <5630B93E.6020307@oracle.com> Michael, Peter, Thanks for detailed analysis! It was a hard one to track down :-) Unfortunately, I don't see how the proposed change fixes the problem. The failure occurs during SpeciesData instantiation (BMH$SpeciesData.<init>). It means updateCache has not yet been called from getForClass: static SpeciesData getForClass(String types, Class<? extends BoundMethodHandle> clazz) { return updateCache(types, new SpeciesData(types, clazz)); } With your changes, updateCache is called only after successful loading of a class. So, the cache isn't updated if there was an error during previous attempt. The real problem is more severe IMO. The loaded class is useless when its initialization finishes abruptly, so there's no way to instantiate it or reload. Right now it is manifested as a duplicate class definition attempt, but if you avoid repeated class loading it will just fail slightly later - the system is already broken and there's no way to recover. I see the following ways to proceed: (1) delay class initialization (fill in Species_*.SPECIES_DATA field afterwards) and attempt to finish initialization on subsequent requests, but skipping class loading step; (2) use VM anonymous classes (see JDK-8078602 [1]) and just retry Species creation; (3) give up on that particular Species shape and throw an error whenever it is requested (how it works right now, but with more meaningful error message). I remember I experimented with (2), but even after JDK-8078629 [2] there was still measurable peak performance regression on Octane/Nashorn. (1) looks more favorable and robust, but right now there shouldn't be much difference - there's no support in VM to unload MH.linkTo* adapters, so the failure will repeatedly occur once the code cache is full. My conclusion is that it is mostly a test problem, but java.lang.invoke framework should clearly communicate the reason why it fails. Since the test is aware about code cache overflow problems, it looks preferable to go with (1) or (3) for now. VM should throw VirtualMachineError on repeated attempts to instantiate SPECIES_DATA and the test already filters them out. Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8078602 [2] https://bugs.openjdk.java.net/browse/JDK-8078629 On 10/28/15 12:19 PM, Michael Haupt wrote: > Dear all, > > please review this change. > Bug: https://bugs.openjdk.java.net/browse/JDK-8131129 > Webrev: http://cr.openjdk.java.net/~mhaupt/8131129/webrev.00/ > > Thanks to Peter Levart, who has contributed the actual code to fix the issue. > > The background of this is as follows. Bug 8131129 is an intermittent failure in a multi-threaded test for LambdaForm caching. The failure was not reproducible but used to occur on various platforms every now and then. I was able to dig up some stack traces that reveal the real cause in internal test logs. These traces finally confirmed a suspicion that both Peter and I had had but could, for lack of complete failure information, not pin down as the cause of the issue. (Most traces from failures of the test were only partial, as the test harness is selective about traces it logs.) > > At the heart of the problem is an overflowing code cache for adapters in the VM. The test, dynamically generating considerable amounts of LambdaForm and BoundMethodHandle species classes, would eventually trigger this overflow. The place at which the problem would surface is this, in BoundMethodHandle.Factory.generateConcreteBMHClass(): > > Class<? extends BoundMethodHandle> bmhClass = > //UNSAFE.defineAnonymousClass(BoundMethodHandle.class, classFile, null).asSubclass(BoundMethodHandle.class); > UNSAFE.defineClass(className, classFile, 0, classFile.length, > BoundMethodHandle.class.getClassLoader(), null) > .asSubclass(BoundMethodHandle.class); > UNSAFE.ensureClassInitialized(bmhClass); > > The test would generate a BMH species with a given type signature via defineClass and immediately thereafter force initialisation of that class, in the course of which a SpeciesData instance is supposed to be created and entered in the BMH species cache. In case the VM's adapter code cache overflowed during this operation, the BMH species' class initialiser would not finish its execution properly, leading to a stale placeholder entry left behind in the cache. The presence of this very placeholder would trick the next request for a BMH species with the same type signature into believing the class needed to be defined, leading to the observed failure. > > An exemplary stack trace is appended below. > > Both Peter and I had come up with solutions, but I think Peter's is better as it gets rid of the somewhat intricate and semi-hidden cache registration call made from generated code. With Peter's fix, it's all visible in library code now. > > Thanks, > > Michael > > > > ----- > java.lang.InternalError: java.lang.NoSuchMethodException: no such method: java.lang.invoke.MethodHandle.linkToStatic(Object,Object,int,Object,Object,Object,Object,Object,Object,Object,MemberName)Object/invokeStatic > at java.lang.invoke.MethodHandleStatics.newInternalError(MethodHandleStatics.java:120) > at java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:214) > at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:188) > at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:177) > at java.lang.invoke.DirectMethodHandle.make(DirectMethodHandle.java:84) > at java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:1655) > at java.lang.invoke.MethodHandles$Lookup.getDirectMethod(MethodHandles.java:1600) > at java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:777) > at java.lang.invoke.BoundMethodHandle$Factory.makeCbmhCtor(BoundMethodHandle.java:817) > at java.lang.invoke.BoundMethodHandle$Factory.makeCtors(BoundMethodHandle.java:772) > at java.lang.invoke.BoundMethodHandle$SpeciesData.<init>(BoundMethodHandle.java:347) > at java.lang.invoke.BoundMethodHandle$SpeciesData.getForClass(BoundMethodHandle.java:411) > at java.lang.invoke.BoundMethodHandle$Species_IL7.<clinit>(Species_IL7) > at sun.misc.Unsafe.ensureClassInitialized(Native Method) > at java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:718) > at java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) > at java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:388) > at java.lang.invoke.LambdaFormEditor.newSpeciesData(LambdaFormEditor.java:363) > at java.lang.invoke.LambdaFormEditor.makeArgumentCombinationForm(LambdaFormEditor.java:631) > at java.lang.invoke.LambdaFormEditor.filterArgumentForm(LambdaFormEditor.java:612) > at java.lang.invoke.MethodHandles.filterArgument(MethodHandles.java:2667) > at java.lang.invoke.MethodHandles.filterArguments(MethodHandles.java:2654) > at TestMethods$4.getMH(TestMethods.java:180) > at TestMethods.getTestCaseMH(TestMethods.java:548) > at LFMultiThreadCachingTest.lambda$doTest$0(LFMultiThreadCachingTest.java:80) > at LFMultiThreadCachingTest$$Lambda$5/21979926.run(Unknown Source) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NoSuchMethodException: no such method: java.lang.invoke.MethodHandle.linkToStatic(Object,Object,int,Object,Object,Object,Object,Object,Object,Object,MemberName)Object/invokeStatic > at java.lang.invoke.MemberName.makeAccessException(MemberName.java:873) > at java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:990) > at java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:212) > ... 25 more > Caused by: java.lang.NoSuchMethodError: java.lang.invoke.MethodHandle.linkToStatic(Ljava/lang/Object;Ljava/lang/Object;ILjava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object; > at java.lang.invoke.MethodHandleNatives.resolve(Native Method) > at java.lang.invoke.MemberName$Factory.resolve(MemberName.java:962) > at java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:987) > ... 26 more > Caused by: java.lang.VirtualMachineError: out of space in CodeCache for method handle intrinsic > ... 29 more > java.lang.LinkageError: loader (instance of <bootloader>): attempted duplicate class definition for name: "java/lang/invoke/BoundMethodHandle$Species_IL7" > at sun.misc.Unsafe.defineClass(Native Method) > at java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:715) > at java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) > at java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:388) > at java.lang.invoke.LambdaFormEditor.newSpeciesData(LambdaFormEditor.java:363) > at java.lang.invoke.LambdaFormEditor.makeArgumentCombinationForm(LambdaFormEditor.java:631) > at java.lang.invoke.LambdaFormEditor.filterArgumentForm(LambdaFormEditor.java:612) > at java.lang.invoke.MethodHandles.filterArgument(MethodHandles.java:2667) > at java.lang.invoke.MethodHandles.filterArguments(MethodHandles.java:2654) > at TestMethods$4.getMH(TestMethods.java:180) > at TestMethods.getTestCaseMH(TestMethods.java:548) > at LFMultiThreadCachingTest.lambda$doTest$0(LFMultiThreadCachingTest.java:80) > at LFMultiThreadCachingTest$$Lambda$5/21979926.run(Unknown Source) > at java.lang.Thread.run(Thread.java:745) > java.lang.LinkageError: loader (instance of <bootloader>): attempted duplicate class definition for name: "java/lang/invoke/BoundMethodHandle$Species_IL7" > at sun.misc.Unsafe.defineClass(Native Method) > at java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:715) > at java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) > at java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:388) > at java.lang.invoke.LambdaFormEditor.newSpeciesData(LambdaFormEditor.java:363) > at java.lang.invoke.LambdaFormEditor.makeArgumentCombinationForm(LambdaFormEditor.java:631) > at java.lang.invoke.LambdaFormEditor.filterArgumentForm(LambdaFormEditor.java:612) > at java.lang.invoke.MethodHandles.filterArgument(MethodHandles.java:2667) > at java.lang.invoke.MethodHandles.filterArguments(MethodHandles.java:2654) > at TestMethods$4.getMH(TestMethods.java:180) > at TestMethods.getTestCaseMH(TestMethods.java:548) > at LFMultiThreadCachingTest.lambda$doTest$0(LFMultiThreadCachingTest.java:80) > at LFMultiThreadCachingTest$$Lambda$5/21979926.run(Unknown Source) > at java.lang.Thread.run(Thread.java:745) > STATUS:Failed.STATUS:Failed.STATUS:Failed.`main' threw exception: java.lang.LinkageError: loader (instance of <bootloader>): attempted duplicate class definition for name: "java/lang/invoke/BoundMethodHandle$Species_IL7" > `main' threw exception: java.lang.LinkageError: loader (instance of <bootloader>): attempted duplicate class definition for name: "java/lang/invoke/BoundMethodHandle$Species_IL7" > `main' threw exception: java.lang.InternalError: java.lang.NoSuchMethodException: no such method: java.lang.invoke.MethodHandle.linkToStatic(Object,Object,int,Object,Object,Object,Object,Object,Object,Object,MemberName)Object/invokeStatic > java.lang.LinkageError: loader (instance of <bootloader>): attempted duplicate class definition for name: "java/lang/invoke/BoundMethodHandle$Species_IL7" > at sun.misc.Unsafe.defineClass(Native Method) > at java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:715) > at java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) > ----- > > > From michael.haupt at oracle.com Wed Oct 28 14:06:54 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 28 Oct 2015 15:06:54 +0100 Subject: RFR(S): 8131129: Attempt to define a duplicate BMH$Species class In-Reply-To: <5630B93E.6020307@oracle.com> References: <A60BF64A-8C53-4D51-A630-79E58D1A4AD8@oracle.com> <5630B93E.6020307@oracle.com> Message-ID: <44E1AA20-0D3E-43BD-91F4-5A280A82C655@oracle.com> Hi Vladimir, thank you. Of course you're right: I'll dub this issue "Hydra" - one head chopped off, at least one missed, new ones growing. At least the understanding improves in each iteration ... ;-) The proposal as it now is indeed has the risk of leaving a stale cache entry (placeholder) if species loading or initialisation break. The other solution that was proposed would have wrapped the class loading and initialisation step in a try/catch block and rolled back the cache entry for the types string at hand in case anything went wrong. This, too, could lead to the duplicate definition error if the same species is requested again. At the foundation of the problem, there's a code cache that overflows. This is inside the VM, and, as you notice, not easily addressed. In fact, if the application creates so many adapters that the VM cache overflows, it suggests a problem with the application. It's like forcing an OOME by just going mad on allocations. Thus, I don't see how (1) would help. I agree that this is a test problem that has never occurred "in the wild". I also agree that, in case it would, the error message should be clearer. Proposal - this is a derivative of (3): * Keep the fix as it is, because it certainly clarifies the cache initialisation logic. * Additionally, harden the class loading / initialisation step: - Wrap it in a try/catch block. - In case something goes wrong, mark the species as failure in the cache and raise an appropriate error. * Also, check for failed species upon retrieval and raise an appropriate error. * Finally, harden the test itself against such errors, much like it deals with code cache overflows. How about it? Best, Michael > Am 28.10.2015 um 13:02 schrieb Vladimir Ivanov <vladimir.x.ivanov at oracle.com>: > > Michael, Peter, > > Thanks for detailed analysis! It was a hard one to track down :-) > > Unfortunately, I don't see how the proposed change fixes the problem. > > The failure occurs during SpeciesData instantiation (BMH$SpeciesData.<init>). It means updateCache has not yet been called from getForClass: > > static SpeciesData getForClass(String types, Class<? extends BoundMethodHandle> clazz) { > return updateCache(types, new SpeciesData(types, clazz)); > } > > With your changes, updateCache is called only after successful loading of a class. So, the cache isn't updated if there was an error during previous attempt. > > The real problem is more severe IMO. The loaded class is useless when its initialization finishes abruptly, so there's no way to instantiate it or reload. Right now it is manifested as a duplicate class definition attempt, but if you avoid repeated class loading it will just fail slightly later - the system is already broken and there's no way to recover. > > I see the following ways to proceed: > (1) delay class initialization (fill in Species_*.SPECIES_DATA field afterwards) and attempt to finish initialization on subsequent requests, but skipping class loading step; > > (2) use VM anonymous classes (see JDK-8078602 [1]) and just retry Species creation; > > (3) give up on that particular Species shape and throw an error whenever it is requested (how it works right now, but with more meaningful error message). > > I remember I experimented with (2), but even after JDK-8078629 [2] there was still measurable peak performance regression on Octane/Nashorn. > > (1) looks more favorable and robust, but right now there shouldn't be much difference - there's no support in VM to unload MH.linkTo* adapters, so the failure will repeatedly occur once the code cache is full. > > My conclusion is that it is mostly a test problem, but java.lang.invoke framework should clearly communicate the reason why it fails. Since the test is aware about code cache overflow problems, it looks preferable to go with (1) or (3) for now. VM should throw VirtualMachineError on repeated attempts to instantiate SPECIES_DATA and the test already filters them out. > > Best regards, > Vladimir Ivanov > > [1] https://bugs.openjdk.java.net/browse/JDK-8078602 > [2] https://bugs.openjdk.java.net/browse/JDK-8078629 > > On 10/28/15 12:19 PM, Michael Haupt wrote: >> Dear all, >> >> please review this change. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8131129 >> Webrev: http://cr.openjdk.java.net/~mhaupt/8131129/webrev.00/ >> >> Thanks to Peter Levart, who has contributed the actual code to fix the issue. >> >> The background of this is as follows. Bug 8131129 is an intermittent failure in a multi-threaded test for LambdaForm caching. The failure was not reproducible but used to occur on various platforms every now and then. I was able to dig up some stack traces that reveal the real cause in internal test logs. These traces finally confirmed a suspicion that both Peter and I had had but could, for lack of complete failure information, not pin down as the cause of the issue. (Most traces from failures of the test were only partial, as the test harness is selective about traces it logs.) >> >> At the heart of the problem is an overflowing code cache for adapters in the VM. The test, dynamically generating considerable amounts of LambdaForm and BoundMethodHandle species classes, would eventually trigger this overflow. The place at which the problem would surface is this, in BoundMethodHandle.Factory.generateConcreteBMHClass(): >> >> Class<? extends BoundMethodHandle> bmhClass = >> //UNSAFE.defineAnonymousClass(BoundMethodHandle.class, classFile, null).asSubclass(BoundMethodHandle.class); >> UNSAFE.defineClass(className, classFile, 0, classFile.length, >> BoundMethodHandle.class.getClassLoader(), null) >> .asSubclass(BoundMethodHandle.class); >> UNSAFE.ensureClassInitialized(bmhClass); >> >> The test would generate a BMH species with a given type signature via defineClass and immediately thereafter force initialisation of that class, in the course of which a SpeciesData instance is supposed to be created and entered in the BMH species cache. In case the VM's adapter code cache overflowed during this operation, the BMH species' class initialiser would not finish its execution properly, leading to a stale placeholder entry left behind in the cache. The presence of this very placeholder would trick the next request for a BMH species with the same type signature into believing the class needed to be defined, leading to the observed failure. >> >> An exemplary stack trace is appended below. >> >> Both Peter and I had come up with solutions, but I think Peter's is better as it gets rid of the somewhat intricate and semi-hidden cache registration call made from generated code. With Peter's fix, it's all visible in library code now. >> >> Thanks, >> >> Michael >> >> >> >> ----- >> java.lang.InternalError: java.lang.NoSuchMethodException: no such method: java.lang.invoke.MethodHandle.linkToStatic(Object,Object,int,Object,Object,Object,Object,Object,Object,Object,MemberName)Object/invokeStatic >> at java.lang.invoke.MethodHandleStatics.newInternalError(MethodHandleStatics.java:120) >> at java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:214) >> at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:188) >> at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:177) >> at java.lang.invoke.DirectMethodHandle.make(DirectMethodHandle.java:84) >> at java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:1655) >> at java.lang.invoke.MethodHandles$Lookup.getDirectMethod(MethodHandles.java:1600) >> at java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:777) >> at java.lang.invoke.BoundMethodHandle$Factory.makeCbmhCtor(BoundMethodHandle.java:817) >> at java.lang.invoke.BoundMethodHandle$Factory.makeCtors(BoundMethodHandle.java:772) >> at java.lang.invoke.BoundMethodHandle$SpeciesData.<init>(BoundMethodHandle.java:347) >> at java.lang.invoke.BoundMethodHandle$SpeciesData.getForClass(BoundMethodHandle.java:411) >> at java.lang.invoke.BoundMethodHandle$Species_IL7.<clinit>(Species_IL7) >> at sun.misc.Unsafe.ensureClassInitialized(Native Method) >> at java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:718) >> at java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) >> at java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:388) >> at java.lang.invoke.LambdaFormEditor.newSpeciesData(LambdaFormEditor.java:363) >> at java.lang.invoke.LambdaFormEditor.makeArgumentCombinationForm(LambdaFormEditor.java:631) >> at java.lang.invoke.LambdaFormEditor.filterArgumentForm(LambdaFormEditor.java:612) >> at java.lang.invoke.MethodHandles.filterArgument(MethodHandles.java:2667) >> at java.lang.invoke.MethodHandles.filterArguments(MethodHandles.java:2654) >> at TestMethods$4.getMH(TestMethods.java:180) >> at TestMethods.getTestCaseMH(TestMethods.java:548) >> at LFMultiThreadCachingTest.lambda$doTest$0(LFMultiThreadCachingTest.java:80) >> at LFMultiThreadCachingTest$$Lambda$5/21979926.run(Unknown Source) >> at java.lang.Thread.run(Thread.java:745) >> Caused by: java.lang.NoSuchMethodException: no such method: java.lang.invoke.MethodHandle.linkToStatic(Object,Object,int,Object,Object,Object,Object,Object,Object,Object,MemberName)Object/invokeStatic >> at java.lang.invoke.MemberName.makeAccessException(MemberName.java:873) >> at java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:990) >> at java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:212) >> ... 25 more >> Caused by: java.lang.NoSuchMethodError: java.lang.invoke.MethodHandle.linkToStatic(Ljava/lang/Object;Ljava/lang/Object;ILjava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object; >> at java.lang.invoke.MethodHandleNatives.resolve(Native Method) >> at java.lang.invoke.MemberName$Factory.resolve(MemberName.java:962) >> at java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:987) >> ... 26 more >> Caused by: java.lang.VirtualMachineError: out of space in CodeCache for method handle intrinsic >> ... 29 more >> java.lang.LinkageError: loader (instance of <bootloader>): attempted duplicate class definition for name: "java/lang/invoke/BoundMethodHandle$Species_IL7" >> at sun.misc.Unsafe.defineClass(Native Method) >> at java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:715) >> at java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) >> at java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:388) >> at java.lang.invoke.LambdaFormEditor.newSpeciesData(LambdaFormEditor.java:363) >> at java.lang.invoke.LambdaFormEditor.makeArgumentCombinationForm(LambdaFormEditor.java:631) >> at java.lang.invoke.LambdaFormEditor.filterArgumentForm(LambdaFormEditor.java:612) >> at java.lang.invoke.MethodHandles.filterArgument(MethodHandles.java:2667) >> at java.lang.invoke.MethodHandles.filterArguments(MethodHandles.java:2654) >> at TestMethods$4.getMH(TestMethods.java:180) >> at TestMethods.getTestCaseMH(TestMethods.java:548) >> at LFMultiThreadCachingTest.lambda$doTest$0(LFMultiThreadCachingTest.java:80) >> at LFMultiThreadCachingTest$$Lambda$5/21979926.run(Unknown Source) >> at java.lang.Thread.run(Thread.java:745) >> java.lang.LinkageError: loader (instance of <bootloader>): attempted duplicate class definition for name: "java/lang/invoke/BoundMethodHandle$Species_IL7" >> at sun.misc.Unsafe.defineClass(Native Method) >> at java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:715) >> at java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) >> at java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:388) >> at java.lang.invoke.LambdaFormEditor.newSpeciesData(LambdaFormEditor.java:363) >> at java.lang.invoke.LambdaFormEditor.makeArgumentCombinationForm(LambdaFormEditor.java:631) >> at java.lang.invoke.LambdaFormEditor.filterArgumentForm(LambdaFormEditor.java:612) >> at java.lang.invoke.MethodHandles.filterArgument(MethodHandles.java:2667) >> at java.lang.invoke.MethodHandles.filterArguments(MethodHandles.java:2654) >> at TestMethods$4.getMH(TestMethods.java:180) >> at TestMethods.getTestCaseMH(TestMethods.java:548) >> at LFMultiThreadCachingTest.lambda$doTest$0(LFMultiThreadCachingTest.java:80) >> at LFMultiThreadCachingTest$$Lambda$5/21979926.run(Unknown Source) >> at java.lang.Thread.run(Thread.java:745) >> STATUS:Failed.STATUS:Failed.STATUS:Failed.`main' threw exception: java.lang.LinkageError: loader (instance of <bootloader>): attempted duplicate class definition for name: "java/lang/invoke/BoundMethodHandle$Species_IL7" >> `main' threw exception: java.lang.LinkageError: loader (instance of <bootloader>): attempted duplicate class definition for name: "java/lang/invoke/BoundMethodHandle$Species_IL7" >> `main' threw exception: java.lang.InternalError: java.lang.NoSuchMethodException: no such method: java.lang.invoke.MethodHandle.linkToStatic(Object,Object,int,Object,Object,Object,Object,Object,Object,Object,MemberName)Object/invokeStatic >> java.lang.LinkageError: loader (instance of <bootloader>): attempted duplicate class definition for name: "java/lang/invoke/BoundMethodHandle$Species_IL7" >> at sun.misc.Unsafe.defineClass(Native Method) >> at java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:715) >> at java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) >> ----- >> >> >> -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment From vladimir.x.ivanov at oracle.com Wed Oct 28 14:51:56 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 28 Oct 2015 17:51:56 +0300 Subject: RFR(S): 8131129: Attempt to define a duplicate BMH$Species class In-Reply-To: <44E1AA20-0D3E-43BD-91F4-5A280A82C655@oracle.com> References: <A60BF64A-8C53-4D51-A630-79E58D1A4AD8@oracle.com> <5630B93E.6020307@oracle.com> <44E1AA20-0D3E-43BD-91F4-5A280A82C655@oracle.com> Message-ID: <5630E10C.3070707@oracle.com> Michael, > thank you. Of course you're right: I'll dub this issue "Hydra" - one head chopped off, at least one missed, new ones growing. At least the understanding improves in each iteration ... ;-) > > The proposal as it now is indeed has the risk of leaving a stale cache entry (placeholder) if species loading or initialisation break. The other solution that was proposed would have wrapped the class loading and initialisation step in a try/catch block and rolled back the cache entry for the types string at hand in case anything went wrong. This, too, could lead to the duplicate definition error if the same species is requested again. > > At the foundation of the problem, there's a code cache that overflows. This is inside the VM, and, as you notice, not easily addressed. In fact, if the application creates so many adapters that the VM cache overflows, it suggests a problem with the application. It's like forcing an OOME by just going mad on allocations. Thus, I don't see how (1) would help. (1) has a nice property of throwing the same error again (VirtualMachineError: "out of space in CodeCache for method handle intrinsic") on repeated attempts. But it also complicates the implementation, so I'm in favor of your proposal. > I agree that this is a test problem that has never occurred "in the wild". I also agree that, in case it would, the error message should be clearer. > > Proposal - this is a derivative of (3): > * Keep the fix as it is, because it certainly clarifies the cache initialisation logic. Agree. The cleanup changes are good. > * Additionally, harden the class loading / initialisation step: > - Wrap it in a try/catch block. > - In case something goes wrong, mark the species as failure in the cache and raise an appropriate error. > * Also, check for failed species upon retrieval and raise an appropriate error. Sounds good. > * Finally, harden the test itself against such errors, much like it deals with code cache overflows. I'd like to avoid introducing another expected failing mode and would prefer the implementation to throw the same type of error - VirtualMachineError. In that case there should be no need to adjust the test. Best regards, Vladimir Ivanov > > How about it? > > Best, > > Michael > >> Am 28.10.2015 um 13:02 schrieb Vladimir Ivanov <vladimir.x.ivanov at oracle.com>: >> >> Michael, Peter, >> >> Thanks for detailed analysis! It was a hard one to track down :-) >> >> Unfortunately, I don't see how the proposed change fixes the problem. >> >> The failure occurs during SpeciesData instantiation (BMH$SpeciesData.<init>). It means updateCache has not yet been called from getForClass: >> >> static SpeciesData getForClass(String types, Class<? extends BoundMethodHandle> clazz) { >> return updateCache(types, new SpeciesData(types, clazz)); >> } >> >> With your changes, updateCache is called only after successful loading of a class. So, the cache isn't updated if there was an error during previous attempt. >> >> The real problem is more severe IMO. The loaded class is useless when its initialization finishes abruptly, so there's no way to instantiate it or reload. Right now it is manifested as a duplicate class definition attempt, but if you avoid repeated class loading it will just fail slightly later - the system is already broken and there's no way to recover. >> >> I see the following ways to proceed: >> (1) delay class initialization (fill in Species_*.SPECIES_DATA field afterwards) and attempt to finish initialization on subsequent requests, but skipping class loading step; >> >> (2) use VM anonymous classes (see JDK-8078602 [1]) and just retry Species creation; >> >> (3) give up on that particular Species shape and throw an error whenever it is requested (how it works right now, but with more meaningful error message). >> >> I remember I experimented with (2), but even after JDK-8078629 [2] there was still measurable peak performance regression on Octane/Nashorn. >> >> (1) looks more favorable and robust, but right now there shouldn't be much difference - there's no support in VM to unload MH.linkTo* adapters, so the failure will repeatedly occur once the code cache is full. >> >> My conclusion is that it is mostly a test problem, but java.lang.invoke framework should clearly communicate the reason why it fails. Since the test is aware about code cache overflow problems, it looks preferable to go with (1) or (3) for now. VM should throw VirtualMachineError on repeated attempts to instantiate SPECIES_DATA and the test already filters them out. >> >> Best regards, >> Vladimir Ivanov >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8078602 >> [2] https://bugs.openjdk.java.net/browse/JDK-8078629 >> >> On 10/28/15 12:19 PM, Michael Haupt wrote: >>> Dear all, >>> >>> please review this change. >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8131129 >>> Webrev: http://cr.openjdk.java.net/~mhaupt/8131129/webrev.00/ >>> >>> Thanks to Peter Levart, who has contributed the actual code to fix the issue. >>> >>> The background of this is as follows. Bug 8131129 is an intermittent failure in a multi-threaded test for LambdaForm caching. The failure was not reproducible but used to occur on various platforms every now and then. I was able to dig up some stack traces that reveal the real cause in internal test logs. These traces finally confirmed a suspicion that both Peter and I had had but could, for lack of complete failure information, not pin down as the cause of the issue. (Most traces from failures of the test were only partial, as the test harness is selective about traces it logs.) >>> >>> At the heart of the problem is an overflowing code cache for adapters in the VM. The test, dynamically generating considerable amounts of LambdaForm and BoundMethodHandle species classes, would eventually trigger this overflow. The place at which the problem would surface is this, in BoundMethodHandle.Factory.generateConcreteBMHClass(): >>> >>> Class<? extends BoundMethodHandle> bmhClass = >>> //UNSAFE.defineAnonymousClass(BoundMethodHandle.class, classFile, null).asSubclass(BoundMethodHandle.class); >>> UNSAFE.defineClass(className, classFile, 0, classFile.length, >>> BoundMethodHandle.class.getClassLoader(), null) >>> .asSubclass(BoundMethodHandle.class); >>> UNSAFE.ensureClassInitialized(bmhClass); >>> >>> The test would generate a BMH species with a given type signature via defineClass and immediately thereafter force initialisation of that class, in the course of which a SpeciesData instance is supposed to be created and entered in the BMH species cache. In case the VM's adapter code cache overflowed during this operation, the BMH species' class initialiser would not finish its execution properly, leading to a stale placeholder entry left behind in the cache. The presence of this very placeholder would trick the next request for a BMH species with the same type signature into believing the class needed to be defined, leading to the observed failure. >>> >>> An exemplary stack trace is appended below. >>> >>> Both Peter and I had come up with solutions, but I think Peter's is better as it gets rid of the somewhat intricate and semi-hidden cache registration call made from generated code. With Peter's fix, it's all visible in library code now. >>> >>> Thanks, >>> >>> Michael >>> >>> >>> >>> ----- >>> java.lang.InternalError: java.lang.NoSuchMethodException: no such method: java.lang.invoke.MethodHandle.linkToStatic(Object,Object,int,Object,Object,Object,Object,Object,Object,Object,MemberName)Object/invokeStatic >>> at java.lang.invoke.MethodHandleStatics.newInternalError(MethodHandleStatics.java:120) >>> at java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:214) >>> at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:188) >>> at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:177) >>> at java.lang.invoke.DirectMethodHandle.make(DirectMethodHandle.java:84) >>> at java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:1655) >>> at java.lang.invoke.MethodHandles$Lookup.getDirectMethod(MethodHandles.java:1600) >>> at java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:777) >>> at java.lang.invoke.BoundMethodHandle$Factory.makeCbmhCtor(BoundMethodHandle.java:817) >>> at java.lang.invoke.BoundMethodHandle$Factory.makeCtors(BoundMethodHandle.java:772) >>> at java.lang.invoke.BoundMethodHandle$SpeciesData.<init>(BoundMethodHandle.java:347) >>> at java.lang.invoke.BoundMethodHandle$SpeciesData.getForClass(BoundMethodHandle.java:411) >>> at java.lang.invoke.BoundMethodHandle$Species_IL7.<clinit>(Species_IL7) >>> at sun.misc.Unsafe.ensureClassInitialized(Native Method) >>> at java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:718) >>> at java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) >>> at java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:388) >>> at java.lang.invoke.LambdaFormEditor.newSpeciesData(LambdaFormEditor.java:363) >>> at java.lang.invoke.LambdaFormEditor.makeArgumentCombinationForm(LambdaFormEditor.java:631) >>> at java.lang.invoke.LambdaFormEditor.filterArgumentForm(LambdaFormEditor.java:612) >>> at java.lang.invoke.MethodHandles.filterArgument(MethodHandles.java:2667) >>> at java.lang.invoke.MethodHandles.filterArguments(MethodHandles.java:2654) >>> at TestMethods$4.getMH(TestMethods.java:180) >>> at TestMethods.getTestCaseMH(TestMethods.java:548) >>> at LFMultiThreadCachingTest.lambda$doTest$0(LFMultiThreadCachingTest.java:80) >>> at LFMultiThreadCachingTest$$Lambda$5/21979926.run(Unknown Source) >>> at java.lang.Thread.run(Thread.java:745) >>> Caused by: java.lang.NoSuchMethodException: no such method: java.lang.invoke.MethodHandle.linkToStatic(Object,Object,int,Object,Object,Object,Object,Object,Object,Object,MemberName)Object/invokeStatic >>> at java.lang.invoke.MemberName.makeAccessException(MemberName.java:873) >>> at java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:990) >>> at java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:212) >>> ... 25 more >>> Caused by: java.lang.NoSuchMethodError: java.lang.invoke.MethodHandle.linkToStatic(Ljava/lang/Object;Ljava/lang/Object;ILjava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object; >>> at java.lang.invoke.MethodHandleNatives.resolve(Native Method) >>> at java.lang.invoke.MemberName$Factory.resolve(MemberName.java:962) >>> at java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:987) >>> ... 26 more >>> Caused by: java.lang.VirtualMachineError: out of space in CodeCache for method handle intrinsic >>> ... 29 more >>> java.lang.LinkageError: loader (instance of <bootloader>): attempted duplicate class definition for name: "java/lang/invoke/BoundMethodHandle$Species_IL7" >>> at sun.misc.Unsafe.defineClass(Native Method) >>> at java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:715) >>> at java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) >>> at java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:388) >>> at java.lang.invoke.LambdaFormEditor.newSpeciesData(LambdaFormEditor.java:363) >>> at java.lang.invoke.LambdaFormEditor.makeArgumentCombinationForm(LambdaFormEditor.java:631) >>> at java.lang.invoke.LambdaFormEditor.filterArgumentForm(LambdaFormEditor.java:612) >>> at java.lang.invoke.MethodHandles.filterArgument(MethodHandles.java:2667) >>> at java.lang.invoke.MethodHandles.filterArguments(MethodHandles.java:2654) >>> at TestMethods$4.getMH(TestMethods.java:180) >>> at TestMethods.getTestCaseMH(TestMethods.java:548) >>> at LFMultiThreadCachingTest.lambda$doTest$0(LFMultiThreadCachingTest.java:80) >>> at LFMultiThreadCachingTest$$Lambda$5/21979926.run(Unknown Source) >>> at java.lang.Thread.run(Thread.java:745) >>> java.lang.LinkageError: loader (instance of <bootloader>): attempted duplicate class definition for name: "java/lang/invoke/BoundMethodHandle$Species_IL7" >>> at sun.misc.Unsafe.defineClass(Native Method) >>> at java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:715) >>> at java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) >>> at java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:388) >>> at java.lang.invoke.LambdaFormEditor.newSpeciesData(LambdaFormEditor.java:363) >>> at java.lang.invoke.LambdaFormEditor.makeArgumentCombinationForm(LambdaFormEditor.java:631) >>> at java.lang.invoke.LambdaFormEditor.filterArgumentForm(LambdaFormEditor.java:612) >>> at java.lang.invoke.MethodHandles.filterArgument(MethodHandles.java:2667) >>> at java.lang.invoke.MethodHandles.filterArguments(MethodHandles.java:2654) >>> at TestMethods$4.getMH(TestMethods.java:180) >>> at TestMethods.getTestCaseMH(TestMethods.java:548) >>> at LFMultiThreadCachingTest.lambda$doTest$0(LFMultiThreadCachingTest.java:80) >>> at LFMultiThreadCachingTest$$Lambda$5/21979926.run(Unknown Source) >>> at java.lang.Thread.run(Thread.java:745) >>> STATUS:Failed.STATUS:Failed.STATUS:Failed.`main' threw exception: java.lang.LinkageError: loader (instance of <bootloader>): attempted duplicate class definition for name: "java/lang/invoke/BoundMethodHandle$Species_IL7" >>> `main' threw exception: java.lang.LinkageError: loader (instance of <bootloader>): attempted duplicate class definition for name: "java/lang/invoke/BoundMethodHandle$Species_IL7" >>> `main' threw exception: java.lang.InternalError: java.lang.NoSuchMethodException: no such method: java.lang.invoke.MethodHandle.linkToStatic(Object,Object,int,Object,Object,Object,Object,Object,Object,Object,MemberName)Object/invokeStatic >>> java.lang.LinkageError: loader (instance of <bootloader>): attempted duplicate class definition for name: "java/lang/invoke/BoundMethodHandle$Species_IL7" >>> at sun.misc.Unsafe.defineClass(Native Method) >>> at java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:715) >>> at java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) >>> ----- >>> >>> >>> > From peter.levart at gmail.com Wed Oct 28 15:21:09 2015 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 28 Oct 2015 08:21:09 -0700 Subject: RFR(S): 8131129: Attempt to define a duplicate BMH$Species class In-Reply-To: <5630B93E.6020307@oracle.com> References: <A60BF64A-8C53-4D51-A630-79E58D1A4AD8@oracle.com> <5630B93E.6020307@oracle.com> Message-ID: <CAJUsCJBdh-R2fpRy9q1uycUY5a-mSR7Ovnj7avTspnwpunhbEQ@mail.gmail.com> Hi Vladimir, I think you are right. The proposed fix alone even increases the chance of duplicate class definition attempts as it delays registration in cache to after whole clinit successfully finishes. I would still keep this initialization rearrangement as it fixes the possible publication race too. If the source of 1st exception is from clinit method execution, then it would be best to skip forced class initialization and delay it to its 1st use. Eager initialization does not serve any purpose if the registration into cache is performed out of clinit method as proposed in the fix. To summarise: the proposed initialization fix would have to be accompanied with removal of forced class initialization to achieve the effect of your option (1) below. Am I right? Regards, Peter Michael, Peter, Thanks for detailed analysis! It was a hard one to track down :-) Unfortunately, I don't see how the proposed change fixes the problem. The failure occurs during SpeciesData instantiation (BMH$SpeciesData.<init>). It means updateCache has not yet been called from getForClass: static SpeciesData getForClass(String types, Class<? extends BoundMethodHandle> clazz) { return updateCache(types, new SpeciesData(types, clazz)); } With your changes, updateCache is called only after successful loading of a class. So, the cache isn't updated if there was an error during previous attempt. The real problem is more severe IMO. The loaded class is useless when its initialization finishes abruptly, so there's no way to instantiate it or reload. Right now it is manifested as a duplicate class definition attempt, but if you avoid repeated class loading it will just fail slightly later - the system is already broken and there's no way to recover. I see the following ways to proceed: (1) delay class initialization (fill in Species_*.SPECIES_DATA field afterwards) and attempt to finish initialization on subsequent requests, but skipping class loading step; (2) use VM anonymous classes (see JDK-8078602 [1]) and just retry Species creation; (3) give up on that particular Species shape and throw an error whenever it is requested (how it works right now, but with more meaningful error message). I remember I experimented with (2), but even after JDK-8078629 [2] there was still measurable peak performance regression on Octane/Nashorn. (1) looks more favorable and robust, but right now there shouldn't be much difference - there's no support in VM to unload MH.linkTo* adapters, so the failure will repeatedly occur once the code cache is full. My conclusion is that it is mostly a test problem, but java.lang.invoke framework should clearly communicate the reason why it fails. Since the test is aware about code cache overflow problems, it looks preferable to go with (1) or (3) for now. VM should throw VirtualMachineError on repeated attempts to instantiate SPECIES_DATA and the test already filters them out. Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8078602 [2] https://bugs.openjdk.java.net/browse/JDK-8078629 On 10/28/15 12:19 PM, Michael Haupt wrote: > Dear all, > > please review this change. > Bug: https://bugs.openjdk.java.net/browse/JDK-8131129 > Webrev: http://cr.openjdk.java.net/~mhaupt/8131129/webrev.00/ > > Thanks to Peter Levart, who has contributed the actual code to fix the > issue. > > The background of this is as follows. Bug 8131129 is an intermittent > failure in a multi-threaded test for LambdaForm caching. The failure was > not reproducible but used to occur on various platforms every now and then. > I was able to dig up some stack traces that reveal the real cause in > internal test logs. These traces finally confirmed a suspicion that both > Peter and I had had but could, for lack of complete failure information, > not pin down as the cause of the issue. (Most traces from failures of the > test were only partial, as the test harness is selective about traces it > logs.) > > At the heart of the problem is an overflowing code cache for adapters in > the VM. The test, dynamically generating considerable amounts of LambdaForm > and BoundMethodHandle species classes, would eventually trigger this > overflow. The place at which the problem would surface is this, in > BoundMethodHandle.Factory.generateConcreteBMHClass(): > > Class<? extends BoundMethodHandle> bmhClass = > //UNSAFE.defineAnonymousClass(BoundMethodHandle.class, classFile, > null).asSubclass(BoundMethodHandle.class); > UNSAFE.defineClass(className, classFile, 0, classFile.length, > BoundMethodHandle.class.getClassLoader(), null) > .asSubclass(BoundMethodHandle.class); > UNSAFE.ensureClassInitialized(bmhClass); > > The test would generate a BMH species with a given type signature via > defineClass and immediately thereafter force initialisation of that class, > in the course of which a SpeciesData instance is supposed to be created and > entered in the BMH species cache. In case the VM's adapter code cache > overflowed during this operation, the BMH species' class initialiser would > not finish its execution properly, leading to a stale placeholder entry > left behind in the cache. The presence of this very placeholder would trick > the next request for a BMH species with the same type signature into > believing the class needed to be defined, leading to the observed failure. > > An exemplary stack trace is appended below. > > Both Peter and I had come up with solutions, but I think Peter's is better > as it gets rid of the somewhat intricate and semi-hidden cache registration > call made from generated code. With Peter's fix, it's all visible in > library code now. > > Thanks, > > Michael > > > > ----- > java.lang.InternalError: java.lang.NoSuchMethodException: no such method: > java.lang.invoke.MethodHandle.linkToStatic(Object,Object,int,Object,Object,Object,Object,Object,Object,Object,MemberName)Object/invokeStatic > at > java.lang.invoke.MethodHandleStatics.newInternalError(MethodHandleStatics.java:120) > at > java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:214) > at > java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:188) > at > java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:177) > at > java.lang.invoke.DirectMethodHandle.make(DirectMethodHandle.java:84) > at > java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:1655) > at > java.lang.invoke.MethodHandles$Lookup.getDirectMethod(MethodHandles.java:1600) > at > java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:777) > at > java.lang.invoke.BoundMethodHandle$Factory.makeCbmhCtor(BoundMethodHandle.java:817) > at > java.lang.invoke.BoundMethodHandle$Factory.makeCtors(BoundMethodHandle.java:772) > at > java.lang.invoke.BoundMethodHandle$SpeciesData.<init>(BoundMethodHandle.java:347) > at > java.lang.invoke.BoundMethodHandle$SpeciesData.getForClass(BoundMethodHandle.java:411) > at > java.lang.invoke.BoundMethodHandle$Species_IL7.<clinit>(Species_IL7) > at sun.misc.Unsafe.ensureClassInitialized(Native Method) > at > java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:718) > at > java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) > at > java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:388) > at > java.lang.invoke.LambdaFormEditor.newSpeciesData(LambdaFormEditor.java:363) > at > java.lang.invoke.LambdaFormEditor.makeArgumentCombinationForm(LambdaFormEditor.java:631) > at > java.lang.invoke.LambdaFormEditor.filterArgumentForm(LambdaFormEditor.java:612) > at > java.lang.invoke.MethodHandles.filterArgument(MethodHandles.java:2667) > at > java.lang.invoke.MethodHandles.filterArguments(MethodHandles.java:2654) > at TestMethods$4.getMH(TestMethods.java:180) > at TestMethods.getTestCaseMH(TestMethods.java:548) > at > LFMultiThreadCachingTest.lambda$doTest$0(LFMultiThreadCachingTest.java:80) > at LFMultiThreadCachingTest$$Lambda$5/21979926.run(Unknown Source) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NoSuchMethodException: no such method: > java.lang.invoke.MethodHandle.linkToStatic(Object,Object,int,Object,Object,Object,Object,Object,Object,Object,MemberName)Object/invokeStatic > at > java.lang.invoke.MemberName.makeAccessException(MemberName.java:873) > at > java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:990) > at > java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:212) > ... 25 more > Caused by: java.lang.NoSuchMethodError: > java.lang.invoke.MethodHandle.linkToStatic(Ljava/lang/Object;Ljava/lang/Object;ILjava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object; > at java.lang.invoke.MethodHandleNatives.resolve(Native Method) > at java.lang.invoke.MemberName$Factory.resolve(MemberName.java:962) > at > java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:987) > ... 26 more > Caused by: java.lang.VirtualMachineError: out of space in CodeCache for > method handle intrinsic > ... 29 more > java.lang.LinkageError: loader (instance of <bootloader>): attempted > duplicate class definition for name: > "java/lang/invoke/BoundMethodHandle$Species_IL7" > at sun.misc.Unsafe.defineClass(Native Method) > at > java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:715) > at > java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) > at > java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:388) > at > java.lang.invoke.LambdaFormEditor.newSpeciesData(LambdaFormEditor.java:363) > at > java.lang.invoke.LambdaFormEditor.makeArgumentCombinationForm(LambdaFormEditor.java:631) > at > java.lang.invoke.LambdaFormEditor.filterArgumentForm(LambdaFormEditor.java:612) > at > java.lang.invoke.MethodHandles.filterArgument(MethodHandles.java:2667) > at > java.lang.invoke.MethodHandles.filterArguments(MethodHandles.java:2654) > at TestMethods$4.getMH(TestMethods.java:180) > at TestMethods.getTestCaseMH(TestMethods.java:548) > at > LFMultiThreadCachingTest.lambda$doTest$0(LFMultiThreadCachingTest.java:80) > at LFMultiThreadCachingTest$$Lambda$5/21979926.run(Unknown Source) > at java.lang.Thread.run(Thread.java:745) > java.lang.LinkageError: loader (instance of <bootloader>): attempted > duplicate class definition for name: > "java/lang/invoke/BoundMethodHandle$Species_IL7" > at sun.misc.Unsafe.defineClass(Native Method) > at > java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:715) > at > java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) > at > java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:388) > at > java.lang.invoke.LambdaFormEditor.newSpeciesData(LambdaFormEditor.java:363) > at > java.lang.invoke.LambdaFormEditor.makeArgumentCombinationForm(LambdaFormEditor.java:631) > at > java.lang.invoke.LambdaFormEditor.filterArgumentForm(LambdaFormEditor.java:612) > at > java.lang.invoke.MethodHandles.filterArgument(MethodHandles.java:2667) > at > java.lang.invoke.MethodHandles.filterArguments(MethodHandles.java:2654) > at TestMethods$4.getMH(TestMethods.java:180) > at TestMethods.getTestCaseMH(TestMethods.java:548) > at > LFMultiThreadCachingTest.lambda$doTest$0(LFMultiThreadCachingTest.java:80) > at LFMultiThreadCachingTest$$Lambda$5/21979926.run(Unknown Source) > at java.lang.Thread.run(Thread.java:745) > STATUS:Failed.STATUS:Failed.STATUS:Failed.`main' threw exception: > java.lang.LinkageError: loader (instance of <bootloader>): attempted > duplicate class definition for name: > "java/lang/invoke/BoundMethodHandle$Species_IL7" > `main' threw exception: java.lang.LinkageError: loader (instance of > <bootloader>): attempted duplicate class definition for name: > "java/lang/invoke/BoundMethodHandle$Species_IL7" > `main' threw exception: java.lang.InternalError: > java.lang.NoSuchMethodException: no such method: > java.lang.invoke.MethodHandle.linkToStatic(Object,Object,int,Object,Object,Object,Object,Object,Object,Object,MemberName)Object/invokeStatic > java.lang.LinkageError: loader (instance of <bootloader>): attempted > duplicate class definition for name: > "java/lang/invoke/BoundMethodHandle$Species_IL7" > at sun.misc.Unsafe.defineClass(Native Method) > at > java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:715) > at > java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) > ----- > > > > From vladimir.x.ivanov at oracle.com Wed Oct 28 16:37:03 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 28 Oct 2015 19:37:03 +0300 Subject: RFR(S): 8131129: Attempt to define a duplicate BMH$Species class In-Reply-To: <CAJUsCJBdh-R2fpRy9q1uycUY5a-mSR7Ovnj7avTspnwpunhbEQ@mail.gmail.com> References: <A60BF64A-8C53-4D51-A630-79E58D1A4AD8@oracle.com> <5630B93E.6020307@oracle.com> <CAJUsCJBdh-R2fpRy9q1uycUY5a-mSR7Ovnj7avTspnwpunhbEQ@mail.gmail.com> Message-ID: <5630F9AF.5040608@oracle.com> Peter, > Hi Vladimir, I think you are right. The proposed fix alone even > increases the chance of duplicate class definition attempts as it delays > registration in cache to after whole clinit successfully finishes. I > would still keep this initialization rearrangement as it fixes the > possible publication race too. If the source of 1st exception is from > clinit method execution, then it would be best to skip forced class > initialization and delay it to its 1st use. Eager initialization does > not serve any purpose if the registration into cache is performed out of > clinit method as proposed in the fix. > > To summarise: the proposed initialization fix would have to be > accompanied with removal of forced class initialization to achieve the > effect of your option (1) below. There's no benefit from skipping eager initialization - if class initialization fails, the class becomes unusable anyway. The idea was to split class init and SPECIES_DATA field init. It would allow to retry Species_* class init later once the initial attempt failed. But there's not much value is that right now, since VM doesn't unload generated adapters. So, once code cache is exhausted there's not much JVM can do about it. Also, publishing not fully initialized Species_* class requires all users to check whether the initialization is completed, which can be too much from performance perspective. So, I'm in favor of modified (3) Michael proposed. Best regards, Vladimir Ivanov > Regards, Peter > > Michael, Peter, > > Thanks for detailed analysis! It was a hard one to track down :-) > > Unfortunately, I don't see how the proposed change fixes the problem. > > The failure occurs during SpeciesData instantiation > (BMH$SpeciesData.<init>). It means updateCache has not yet been called > from getForClass: > > static SpeciesData getForClass(String types, Class<? extends > BoundMethodHandle> clazz) { > return updateCache(types, new SpeciesData(types, clazz)); > } > > With your changes, updateCache is called only after successful loading > of a class. So, the cache isn't updated if there was an error during > previous attempt. > > The real problem is more severe IMO. The loaded class is useless when > its initialization finishes abruptly, so there's no way to instantiate > it or reload. Right now it is manifested as a duplicate class definition > attempt, but if you avoid repeated class loading it will just fail > slightly later - the system is already broken and there's no way to recover. > > I see the following ways to proceed: > (1) delay class initialization (fill in Species_*.SPECIES_DATA field > afterwards) and attempt to finish initialization on subsequent requests, > but skipping class loading step; > > (2) use VM anonymous classes (see JDK-8078602 [1]) and just retry > Species creation; > > (3) give up on that particular Species shape and throw an error > whenever it is requested (how it works right now, but with more > meaningful error message). > > I remember I experimented with (2), but even after JDK-8078629 [2] there > was still measurable peak performance regression on Octane/Nashorn. > > (1) looks more favorable and robust, but right now there shouldn't be > much difference - there's no support in VM to unload MH.linkTo* > adapters, so the failure will repeatedly occur once the code cache is full. > > My conclusion is that it is mostly a test problem, but java.lang.invoke > framework should clearly communicate the reason why it fails. Since the > test is aware about code cache overflow problems, it looks preferable to > go with (1) or (3) for now. VM should throw VirtualMachineError on > repeated attempts to instantiate SPECIES_DATA and the test already > filters them out. > > Best regards, > Vladimir Ivanov > > [1] https://bugs.openjdk.java.net/browse/JDK-8078602 > [2] https://bugs.openjdk.java.net/browse/JDK-8078629 > > On 10/28/15 12:19 PM, Michael Haupt wrote: > > Dear all, > > please review this change. > Bug: https://bugs.openjdk.java.net/browse/JDK-8131129 > Webrev: http://cr.openjdk.java.net/~mhaupt/8131129/webrev.00/ > > Thanks to Peter Levart, who has contributed the actual code to fix > the issue. > > The background of this is as follows. Bug 8131129 is an intermittent > failure in a multi-threaded test for LambdaForm caching. The failure > was not reproducible but used to occur on various platforms every > now and then. I was able to dig up some stack traces that reveal the > real cause in internal test logs. These traces finally confirmed a > suspicion that both Peter and I had had but could, for lack of > complete failure information, not pin down as the cause of the > issue. (Most traces from failures of the test were only partial, as > the test harness is selective about traces it logs.) > > At the heart of the problem is an overflowing code cache for > adapters in the VM. The test, dynamically generating considerable > amounts of LambdaForm and BoundMethodHandle species classes, would > eventually trigger this overflow. The place at which the problem > would surface is this, in > BoundMethodHandle.Factory.generateConcreteBMHClass(): > > Class<? extends BoundMethodHandle> bmhClass = > //UNSAFE.defineAnonymousClass(BoundMethodHandle.class, > classFile, null).asSubclass(BoundMethodHandle.class); > UNSAFE.defineClass(className, classFile, 0, classFile.length, > BoundMethodHandle.class.getClassLoader(), null) > .asSubclass(BoundMethodHandle.class); > UNSAFE.ensureClassInitialized(bmhClass); > > The test would generate a BMH species with a given type signature > via defineClass and immediately thereafter force initialisation of > that class, in the course of which a SpeciesData instance is > supposed to be created and entered in the BMH species cache. In case > the VM's adapter code cache overflowed during this operation, the > BMH species' class initialiser would not finish its execution > properly, leading to a stale placeholder entry left behind in the > cache. The presence of this very placeholder would trick the next > request for a BMH species with the same type signature into > believing the class needed to be defined, leading to the observed > failure. > > An exemplary stack trace is appended below. > > Both Peter and I had come up with solutions, but I think Peter's is > better as it gets rid of the somewhat intricate and semi-hidden > cache registration call made from generated code. With Peter's fix, > it's all visible in library code now. > > Thanks, > > Michael > > > > ----- > java.lang.InternalError: java.lang.NoSuchMethodException: no such > method: > java.lang.invoke.MethodHandle.linkToStatic(Object,Object,int,Object,Object,Object,Object,Object,Object,Object,MemberName)Object/invokeStatic > at > java.lang.invoke.MethodHandleStatics.newInternalError(MethodHandleStatics.java:120) > at > java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:214) > at > java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:188) > at > java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:177) > at > java.lang.invoke.DirectMethodHandle.make(DirectMethodHandle.java:84) > at > java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:1655) > at > java.lang.invoke.MethodHandles$Lookup.getDirectMethod(MethodHandles.java:1600) > at > java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:777) > at > java.lang.invoke.BoundMethodHandle$Factory.makeCbmhCtor(BoundMethodHandle.java:817) > at > java.lang.invoke.BoundMethodHandle$Factory.makeCtors(BoundMethodHandle.java:772) > at > java.lang.invoke.BoundMethodHandle$SpeciesData.<init>(BoundMethodHandle.java:347) > at > java.lang.invoke.BoundMethodHandle$SpeciesData.getForClass(BoundMethodHandle.java:411) > at > java.lang.invoke.BoundMethodHandle$Species_IL7.<clinit>(Species_IL7) > at sun.misc.Unsafe.ensureClassInitialized(Native Method) > at > java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:718) > at > java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) > at > java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:388) > at > java.lang.invoke.LambdaFormEditor.newSpeciesData(LambdaFormEditor.java:363) > at > java.lang.invoke.LambdaFormEditor.makeArgumentCombinationForm(LambdaFormEditor.java:631) > at > java.lang.invoke.LambdaFormEditor.filterArgumentForm(LambdaFormEditor.java:612) > at > java.lang.invoke.MethodHandles.filterArgument(MethodHandles.java:2667) > at > java.lang.invoke.MethodHandles.filterArguments(MethodHandles.java:2654) > at TestMethods$4.getMH(TestMethods.java:180) > at TestMethods.getTestCaseMH(TestMethods.java:548) > at > LFMultiThreadCachingTest.lambda$doTest$0(LFMultiThreadCachingTest.java:80) > at LFMultiThreadCachingTest$$Lambda$5/21979926.run(Unknown > Source) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NoSuchMethodException: no such method: > java.lang.invoke.MethodHandle.linkToStatic(Object,Object,int,Object,Object,Object,Object,Object,Object,Object,MemberName)Object/invokeStatic > at > java.lang.invoke.MemberName.makeAccessException(MemberName.java:873) > at > java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:990) > at > java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:212) > ... 25 more > Caused by: java.lang.NoSuchMethodError: > java.lang.invoke.MethodHandle.linkToStatic(Ljava/lang/Object;Ljava/lang/Object;ILjava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object; > at java.lang.invoke.MethodHandleNatives.resolve(Native Method) > at > java.lang.invoke.MemberName$Factory.resolve(MemberName.java:962) > at > java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:987) > ... 26 more > Caused by: java.lang.VirtualMachineError: out of space in CodeCache > for method handle intrinsic > ... 29 more > java.lang.LinkageError: loader (instance of <bootloader>): > attempted duplicate class definition for name: > "java/lang/invoke/BoundMethodHandle$Species_IL7" > at sun.misc.Unsafe.defineClass(Native Method) > at > java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:715) > at > java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) > at > java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:388) > at > java.lang.invoke.LambdaFormEditor.newSpeciesData(LambdaFormEditor.java:363) > at > java.lang.invoke.LambdaFormEditor.makeArgumentCombinationForm(LambdaFormEditor.java:631) > at > java.lang.invoke.LambdaFormEditor.filterArgumentForm(LambdaFormEditor.java:612) > at > java.lang.invoke.MethodHandles.filterArgument(MethodHandles.java:2667) > at > java.lang.invoke.MethodHandles.filterArguments(MethodHandles.java:2654) > at TestMethods$4.getMH(TestMethods.java:180) > at TestMethods.getTestCaseMH(TestMethods.java:548) > at > LFMultiThreadCachingTest.lambda$doTest$0(LFMultiThreadCachingTest.java:80) > at LFMultiThreadCachingTest$$Lambda$5/21979926.run(Unknown > Source) > at java.lang.Thread.run(Thread.java:745) > java.lang.LinkageError: loader (instance of <bootloader>): > attempted duplicate class definition for name: > "java/lang/invoke/BoundMethodHandle$Species_IL7" > at sun.misc.Unsafe.defineClass(Native Method) > at > java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:715) > at > java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) > at > java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:388) > at > java.lang.invoke.LambdaFormEditor.newSpeciesData(LambdaFormEditor.java:363) > at > java.lang.invoke.LambdaFormEditor.makeArgumentCombinationForm(LambdaFormEditor.java:631) > at > java.lang.invoke.LambdaFormEditor.filterArgumentForm(LambdaFormEditor.java:612) > at > java.lang.invoke.MethodHandles.filterArgument(MethodHandles.java:2667) > at > java.lang.invoke.MethodHandles.filterArguments(MethodHandles.java:2654) > at TestMethods$4.getMH(TestMethods.java:180) > at TestMethods.getTestCaseMH(TestMethods.java:548) > at > LFMultiThreadCachingTest.lambda$doTest$0(LFMultiThreadCachingTest.java:80) > at LFMultiThreadCachingTest$$Lambda$5/21979926.run(Unknown > Source) > at java.lang.Thread.run(Thread.java:745) > STATUS:Failed.STATUS:Failed.STATUS:Failed.`main' threw exception: > java.lang.LinkageError: loader (instance of <bootloader>): attempted > duplicate class definition for name: > "java/lang/invoke/BoundMethodHandle$Species_IL7" > `main' threw exception: java.lang.LinkageError: loader (instance of > <bootloader>): attempted duplicate class definition for name: > "java/lang/invoke/BoundMethodHandle$Species_IL7" > `main' threw exception: java.lang.InternalError: > java.lang.NoSuchMethodException: no such method: > java.lang.invoke.MethodHandle.linkToStatic(Object,Object,int,Object,Object,Object,Object,Object,Object,Object,MemberName)Object/invokeStatic > java.lang.LinkageError: loader (instance of <bootloader>): > attempted duplicate class definition for name: > "java/lang/invoke/BoundMethodHandle$Species_IL7" > at sun.misc.Unsafe.defineClass(Native Method) > at > java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:715) > at > java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) > ----- > > > From chris.hegarty at oracle.com Wed Oct 28 19:55:41 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 28 Oct 2015 19:55:41 +0000 Subject: RFR [9] 8140606: Update library code to use internal Unsafe Message-ID: <EC502489-56E1-480E-9FA7-93FC4BB263FB@oracle.com> Following on from 8139891 "Prepare Unsafe for true encapsulation? [1], the JDK library code should use the internal Unsafe class, and not sun.misc.Unsafe. http://cr.openjdk.java.net/~chegar/8140606/00/ This will be pushed to jdk9/dev once 8139891 makes its way from hs-rt. -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8139891 From claes.redestad at oracle.com Wed Oct 28 20:01:33 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 28 Oct 2015 21:01:33 +0100 Subject: RFR (XS): 8140683: Deduplicate Strings in UnixFileSystem canonical caches Message-ID: <5631299D.2050602@oracle.com> Hi, while investigating startup and footprint for jigsaw, I found this unrelated oddity where java.io.UnixFileSystem is missing an opportunity to deduplicate file paths determined to be equal when putting them into its internal cache. Also avoid some recalculation of paths determined to be canonical for no good reason and we're golden: webrev: http://cr.openjdk.java.net/~redestad/8140683/webrev.01 bug: https://bugs.openjdk.java.net/browse/JDK-8140683 /Claes From martinrb at google.com Wed Oct 28 21:42:50 2015 From: martinrb at google.com (Martin Buchholz) Date: Wed, 28 Oct 2015 14:42:50 -0700 Subject: RFR [9] 8140606: Update library code to use internal Unsafe In-Reply-To: <EC502489-56E1-480E-9FA7-93FC4BB263FB@oracle.com> References: <EC502489-56E1-480E-9FA7-93FC4BB263FB@oracle.com> Message-ID: <CA+kOe0_M8pZrFPG1+4MuUBsN=z97REPsmA3GazHCzNT32na9Dg@mail.gmail.com> This will cause jsr166 CVS code to no longer be able to run on jdk8, as it does today. We will probably need to fork soon anyways due to Paul's VarHandle code, but we had not expected it to be necessary before then. Is there any easy way for jsr166 CVS src/main to remain "portable" for a while longer? Alternatively, what can we do to continue using "good old sun.misc.Unsafe" in jsr166 CVS? On Wed, Oct 28, 2015 at 12:55 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote: > Following on from 8139891 "Prepare Unsafe for true encapsulation? [1], > the JDK library code should use the internal Unsafe class, and not > sun.misc.Unsafe. > > http://cr.openjdk.java.net/~chegar/8140606/00/ > > This will be pushed to jdk9/dev once 8139891 makes its way from > hs-rt. > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8139891 From claes.redestad at oracle.com Wed Oct 28 22:00:32 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 28 Oct 2015 23:00:32 +0100 Subject: RFR: 8066644: Fix deprecation warnings in jdk.zipfs module In-Reply-To: <562F9A39.70200@oracle.com> References: <562BF00F.6050804@oracle.com> <562F7ED5.1020600@oracle.com> <562F857F.6070307@oracle.com> <562F9A39.70200@oracle.com> Message-ID: <56314580.9030908@oracle.com> On 2015-10-27 16:37, Claes Redestad wrote: > On 2015-10-27 15:09, Claes Redestad wrote: >> >> >> On 2015-10-27 14:40, Aleksey Shipilev wrote: >>> On 10/24/2015 11:54 PM, Claes Redestad wrote: >>>> webrev: <redacted> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8066644 >>> Looks good. >>> >>> Is there really no way to use the new DateTime API, and ditch the >>> multiplication by 1000L here? >>> >>> 116 return ldt.toEpochSecond( >>> 117 ZoneId.systemDefault().getRules().getOffset(ldt)) * 1000L; >> >> I guess using java.util.concurrent.TimeUnit might suffice: >> >> return TimeUnit.MILLISECONDS.convert(ldt.toEpochSecond(...), >> TimeUnit.SECONDS); >> >> The idiomatic DateTime way I guess would be to do: >> >> return Duration.ofSeconds(ldt.toEpochSecond(), 0).toMillis(); >> >> I'll take these for a spin; properly inlined either variant might be >> performance neutral. > > It seems any difference between the second-to-millisecond conversion > approaches is negligible under repeated testing[1], thus I think the > preferred approach is to use be Duration.ofSeconds(..).toMillis(): > > http://cr.openjdk.java.net/~redestad/8066644/webrev.03 > Or we go with TimeUnit, since that's already used in the same utilities for straightforward conversions: http://cr.openjdk.java.net/~redestad/8066644/webrev.04 Cheers! /Claes From xueming.shen at oracle.com Wed Oct 28 22:17:29 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 28 Oct 2015 15:17:29 -0700 Subject: RFR: 8066644: Fix deprecation warnings in jdk.zipfs module In-Reply-To: <56314580.9030908@oracle.com> References: <562BF00F.6050804@oracle.com> <562F7ED5.1020600@oracle.com> <562F857F.6070307@oracle.com> <562F9A39.70200@oracle.com> <56314580.9030908@oracle.com> Message-ID: <56314979.7040205@oracle.com> On 10/28/2015 03:00 PM, Claes Redestad wrote: > > On 2015-10-27 16:37, Claes Redestad wrote: >> On 2015-10-27 15:09, Claes Redestad wrote: >>> >>> >>> On 2015-10-27 14:40, Aleksey Shipilev wrote: >>>> On 10/24/2015 11:54 PM, Claes Redestad wrote: >>>>> webrev: <redacted> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8066644 >>>> Looks good. >>>> >>>> Is there really no way to use the new DateTime API, and ditch the >>>> multiplication by 1000L here? >>>> >>>> 116 return ldt.toEpochSecond( >>>> 117 ZoneId.systemDefault().getRules().getOffset(ldt)) * 1000L; >>> >>> I guess using java.util.concurrent.TimeUnit might suffice: >>> >>> return TimeUnit.MILLISECONDS.convert(ldt.toEpochSecond(...), TimeUnit.SECONDS); >>> >>> The idiomatic DateTime way I guess would be to do: >>> >>> return Duration.ofSeconds(ldt.toEpochSecond(), 0).toMillis(); >>> >>> I'll take these for a spin; properly inlined either variant might be performance neutral. >> >> It seems any difference between the second-to-millisecond conversion approaches is negligible under repeated testing[1], thus I think the preferred approach is to use be Duration.ofSeconds(..).toMillis(): >> >> http://cr.openjdk.java.net/~redestad/8066644/webrev.03 >> > > Or we go with TimeUnit, since that's already used in the same utilities for straightforward conversions: > > http://cr.openjdk.java.net/~redestad/8066644/webrev.04 > Thanks Claes! It looks good to me. I will push it for you. -Sherman From Alan.Bateman at oracle.com Wed Oct 28 22:14:16 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 28 Oct 2015 22:14:16 +0000 Subject: RFR [9] 8140606: Update library code to use internal Unsafe In-Reply-To: <EC502489-56E1-480E-9FA7-93FC4BB263FB@oracle.com> References: <EC502489-56E1-480E-9FA7-93FC4BB263FB@oracle.com> Message-ID: <563148B8.4090105@oracle.com> On 28/10/2015 19:55, Chris Hegarty wrote: > Following on from 8139891 "Prepare Unsafe for true encapsulation? [1], > the JDK library code should use the internal Unsafe class, and not > sun.misc.Unsafe. > > http://cr.openjdk.java.net/~chegar/8140606/00/ > > This will be pushed to jdk9/dev once 8139891 makes its way from > hs-rt. With the interim CORBA removed then can the corba repo copy of ManagedLocalsThread go away instead of switching it to the internal Unsafe? Otherwise looks good to me. -Alan From pavel.rappo at oracle.com Wed Oct 28 23:35:33 2015 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 28 Oct 2015 23:35:33 +0000 Subject: CharSequence.subSequence optimizations Message-ID: <15474975-3460-41BA-8582-112A5E5FDE57@oracle.com> Hi, While working with an API that extensively uses java.lang.CharSequence, I've noticed most JDK implementations of CharSequence do not optimize for corner cases in CharSequence.subSequence(int start, int end). Namely, 1. start == end (an empty subsequence) 2. start == 0 && end == CharSequence.this.length() (the same sequence) It seems to be a valid solution to return a shared empty sequence object and the same (this) sequence in the first and the second case respectively. I wonder if it's worth investigating pros and cons of introducing these optimizations. Thanks. P.S. If it's a known issue, I would appreciate if somebody provided a link to a relevant discussion. -Pavel From john.r.rose at oracle.com Wed Oct 28 23:44:34 2015 From: john.r.rose at oracle.com (John Rose) Date: Wed, 28 Oct 2015 16:44:34 -0700 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <5617E141.7000503@Oracle.com> References: <5613D01F.3000107@Oracle.com> <5613FEE6.2010907@oracle.com> <1391860289.1215500.1444171338590.JavaMail.zimbra@u-pem.fr> <56159B9A.4040404@Oracle.com> <1319440457.2004194.1444294182369.JavaMail.zimbra@u-pem.fr> <56168166.5030903@Oracle.com> <1200530124.2619128.1444329461357.JavaMail.zimbra@u-pem.fr> <5616BF66.3010607@Oracle.com> <278013257.2631892.1444332861717.JavaMail.zimbra@u-pem.fr> <33D01469-37DE-4502-8112-0E4865733AFF@oracle.com> <5616E345.9090609@Oracle.com> <A4D5091B-C41A-4EA4-B811-F4C3658B8AB0@oracle.com> <CACzrW9BPnBNKaXzLfZeJdD+5n_mZV-OM3TH+yD=suGB2mYR2CQ@mail.gmail.com> <91F25DF8-BC0F-44EB-A57D-A49FF7876DB9@oracle.com> <5617B184.7060803@oracle.com> <5617E141.7000503@Oracle.com> Message-ID: <50EAA3DD-46F5-4BF2-B010-333CEE7187A9@oracle.com> On Oct 9, 2015, at 8:46 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote: > > The primary purpose of the existing 'requireNonNull' methods is to check for null > and throw an exception. It is used for explicit testing and producing a cogent exception. > Returning the value was a secondary benefit that allowed it to be used in fluent expressions. As I noted before, the stated purpose of "requireNonNull" can be slightly widened to check for null, and either throw an exception or return an alternative non-null value. This is a compatible change. Meanwhile, I just realized (after working on code in an IDE) that we already have this API point: boolean nonNull(Object x) { return x != null; } The new proposed name "nonNullElse" would seem on first glance to be a variation on that API point, but it's very different, since it returns T instead of boolean. It seems to me that the prefix "nonNull" is already taken, and we have added an incompatible method to that family. The new API point "nonNullElse" is much closer in meaning to "requireNonNull", as noted before: T nonNullElse(Object x, Object y) { return x != null ? x : y; } T requireNonNull(Object x) { return x != null ? x : throw ? } Having different overloadings of the same name confuse T and a primitive type (boolean) is a known anti-pattern. (Cf. List.remove(int|T).) In this case, the names differ but "nonNull" and "nonNullElse" are going to be viewed together often as a group. They are presented together in an IDE completer. When I complete a name, I usually have in mind what I want it to return. Therefore, the completion of "Objects.notN*" will show me a boolean-valued and a T-valued result, one of which is not what I want. Meanwhile, if I were to complete "Objects.req*" I would get a choicer of T-valued operators, but not one particular one that I might want ("notNullElse"). As I said to you verbally, I'm not going to "die on this hill", but I do think the name chosen has some disadvantages that could have been avoided with a very slight mental shift about require. I.e., "requireNonNull*" requires its *return value* to be not-null, so if its *argument* is null, then an adjustment is made (throw, select alternate value, get-from-supplier). ? John From john.r.rose at oracle.com Wed Oct 28 23:50:07 2015 From: john.r.rose at oracle.com (John Rose) Date: Wed, 28 Oct 2015 16:50:07 -0700 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <50EAA3DD-46F5-4BF2-B010-333CEE7187A9@oracle.com> References: <5613D01F.3000107@Oracle.com> <5613FEE6.2010907@oracle.com> <1391860289.1215500.1444171338590.JavaMail.zimbra@u-pem.fr> <56159B9A.4040404@Oracle.com> <1319440457.2004194.1444294182369.JavaMail.zimbra@u-pem.fr> <56168166.5030903@Oracle.com> <1200530124.2619128.1444329461357.JavaMail.zimbra@u-pem.fr> <5616BF66.3010607@Oracle.com> <278013257.2631892.1444332861717.JavaMail.zimbra@u-pem.fr> <33D01469-37DE-4502-8112-0E4865733AFF@oracle.com> <5616E345.9090609@Oracle.com> <A4D5091B-C41A-4EA4-B811-F4C3658B8AB0@oracle.com> <CACzrW9BPnBNKaXzLfZeJdD+5n_mZV-OM3TH+yD=suGB2mYR2CQ@mail.gmail.com> <91F25DF8-BC0F-44EB-A57D-A49FF7876DB9@oracle.com> <5617B184.7060803@oracle.com> <5617E141.7000503@Oracle.com> <50EAA3DD-46F5-4BF2-B010-333CEE7187A9@oracle.com> Message-ID: <0AE52C49-C11C-473D-8B2E-90C23D55B278@oracle.com> On Oct 28, 2015, at 4:44 PM, John Rose <john.r.rose at oracle.com> wrote: > > As I said to you verbally, I'm not going to "die on this hill", but I do think the name chosen has some disadvantages that could have been avoided with a very slight mental shift about require. I.e., "requireNonNull*" requires its *return value* to be not-null, so if its *argument* is null, then an adjustment is made (throw, select alternate value, get-from-supplier). P.S. Should have finished with this: When adding new API points, let's be sensitive to regularity within families of methods that share a prefix, since IDEs present them together. From aleksey.shipilev at oracle.com Thu Oct 29 00:48:54 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 29 Oct 2015 03:48:54 +0300 Subject: CharSequence.subSequence optimizations In-Reply-To: <15474975-3460-41BA-8582-112A5E5FDE57@oracle.com> References: <15474975-3460-41BA-8582-112A5E5FDE57@oracle.com> Message-ID: <56316CF6.5050506@oracle.com> On 10/29/2015 02:35 AM, Pavel Rappo wrote: > While working with an API that extensively uses java.lang.CharSequence, I've > noticed most JDK implementations of CharSequence do not optimize for corner > cases in CharSequence.subSequence(int start, int end). Namely, > > 1. start == end (an empty subsequence) Yeah, returning a canonical "empty" sequence in this case is probably okay. But, I have doubts about it, because you'd want to match the exact implementation type, to keep the type profiles happy. > 2. start == 0 && end == CharSequence.this.length() (the same sequence) Nope. Doesn't that break when CharSequence implementation is mutable? E.g. with StringBuilder, you cannot return "this" when "end == StringBuilder.length()" at the time of .subSequence() call. Thanks, -Aleksey From mandy.chung at oracle.com Thu Oct 29 00:49:29 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 28 Oct 2015 17:49:29 -0700 Subject: RFR [9] 8140606: Update library code to use internal Unsafe In-Reply-To: <EC502489-56E1-480E-9FA7-93FC4BB263FB@oracle.com> References: <EC502489-56E1-480E-9FA7-93FC4BB263FB@oracle.com> Message-ID: <75F6494F-6F32-4ECD-BB5D-BA18C193B20F@oracle.com> > On Oct 28, 2015, at 12:55 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote: > > Following on from 8139891 "Prepare Unsafe for true encapsulation? [1], > the JDK library code should use the internal Unsafe class, and not > sun.misc.Unsafe. > > http://cr.openjdk.java.net/~chegar/8140606/00/ This change looks fine to me. Mandy From gil at azul.com Thu Oct 29 07:52:46 2015 From: gil at azul.com (Gil Tene) Date: Thu, 29 Oct 2015 07:52:46 +0000 Subject: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal In-Reply-To: <562BC968.70603@cs.oswego.edu> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56164C3C.4050800@cs.oswego.edu> <561E6F04.9030708@cs.oswego.edu> <54AE479E-9891-48FB-AD47-ECED8147DABE@azul.com> <561FC6F9.1080701@cs.oswego.edu> <25B8ED3D-4B35-48F4-BF24-32D48E85343E@azul.com> <562BC968.70603@cs.oswego.edu> Message-ID: <8917A25C-4A16-4291-B145-FA7180E09F78@azul.com> [Sorry for the 4 day delay in response. JavaOne sort of got in the way] I think we are looking at two separate and almost opposite motivations, each of which is potentially independently valid. Each can be characterized by answering the question: "How does adding this to an empty while(!ready) {} spin loop change things?". Putting name selection aside, one motivation can be characterized with "if I add this to a spinning loop, keep spinning hard and don't relinquish resources any more than the empty loop would, but try to leave the spin as fast as possible. And it would be nice if power was conserved as a side effect.". The other motivation can be characterized with "If I add this to a spin loop, I am indicating that I can't make useful progress unless stuff happens or some internal time limit is reached, and that it is ok to try and make better use of resources (including my CPU), relinquishing them more aggressively than the empty loop would. And it would be nice if reaction time was faster most of the time too". The two motivations are diametrically opposed in their expected effect when compared to the behavior of an empty spin loop that does not contain them. Both can be validly implemented as a nop, but they "hint" in opposite directions. The former is what I have been calling a spin loop hint (in the "keep spinning and don't let go" sense), and the latter is a "spin/yield" (in the "ok to let go" sense). They have different uses. > On Oct 24, 2015, at 11:09 AM, Doug Lea <dl at cs.oswego.edu> wrote: > > > Here's one more attempt to explain why it would be a good idea > to place, name, and specify this method in a way that is more > general than "call this method only if you want a PAUSE instruction > on a dedicated multicore x86": I agree with the goal of not aiming at a processor specific behavior, and focusing on documenting intent and expectation. But I think that the intent suggested in the spinLoopHint() JavaDoc does that. As noted later in this e-mail, there are other things that the JVM can choose to do to work in the hint's intended direction. > > On 10/15/2015 01:23 PM, Gil Tene wrote: > ... >> >> As noted in my proposed JavaDoc, I see the primary indication of the hint to >> be that the reaction time to events that would cause the loop to exit (e.g. >> in nanosecond units) is more important to the caller than the speed at which >> the loop is executing (e.g. in "number of loop iterations per second" units). > > Sure. This can also be stated: > > class Thread { ... > /** > * A hint to the platform that the current thread is momentarily > * unable to progress until the occurrence of one or more actions of > * one or more other threads (or that its containing loop is > * otherwise terminated). The method is mainly applicable in > * spin-then-block constructions entailing a bounded number of > * re-checks of a condition, separated by spinYield(), followed if > * necessary with use of a blocking synchronization mechanism. A > * spin-loop that invokes this method on each iteration is likely to > * be more responsive than it would otherwise be. > */ > public static void spinYield(); > } I like the "more responsive than it would otherwise be" part. That certainly describes how this is different than an empty loop. But the choice of "mainly applicable" in spinYield() is exactly opposite from the main use case spinLoopHint() is intended for (which is somewhere between "indefinite spinning" and "I don't care what kind of spinning"). This JavaDoc looks like a good description of spinYield() and it's intended main use cases, but this stated intent and expectations (when compared to just doing an empty spin loop) works in the opposite direction of what spinLoopHint's intent and expectations need to be for it's common use cases. > >> Anyone running indefinite spin loops on a uniprocessor deserves whatever they >> get. Yielding in order to help them out is not mercy. Let Darwin take care of >> them instead. >> >> But indefinite user-mode spinning on many-core systems is a valid and common >> use case (see the disruptor link in my previous e-mail). > >> In such situations the spinning loop should just be calling yield(), or >> looping for a very short count (like your magic 64) and then yielding. A >> "magically choose for me whether reaction time or throughput or being nice to >> others is more important" call is not a useful hint IMO. >> >> Like in my uniprocessor comment above, any program spinning indefinitely (or >> for a non-trivial amount of time) with load > # cpus deserves what it gets. > > The main problem here is that there are no APIs reporting whether > load > # cpus, and no good prospects for them either, especially > considering the use of hypervisors (that may intentionally mis-report) > and tightly packed cloud nodes where the number of cpus currently > available to a program may depend on random transient effects of > co-placement with other services running on that node. Since a simple empty spinning loop ( while(!ready){} ) is valid, even if/when stupid, on any such setup, I don't see how a hint needs to carry a higher burden of being able to know these things. Such empty loops are already being used in both indefinite and backing-off spinning situations, along with the risks, responsibilities, and sensitivities that performing such spinning carry. It is hard to argue against the obvious and very real benefits that indefinite spinning loops provide on well provisioned many-core systems, in terms of latency behavior and reaction time when compared with back-off variants. Yes, they come with extra risks of performance degradation when control is lacking, but they are so useful that their existence proof probably trumps the "people shouldn't do this" argument. So lets look at what each call would do compared to just having an empty loop: The starting point of a pure empty loop obviously does not imply or hint that the JVM should take extra steps to yield resources in the loop. The JVM/OS/Hypervisor certainly MAY do that, but there is no declaration of this intent, and probably no expectation that such yielding would be more likely in the loop than anywhere else in the code. In the case where a spin hint is added: while(!ready){ spinLoopHint(); }; The *only* intent declared [in my suggested JavaDoc for the hint] (above the empty loop implementation) is the wish improve the speed of reacting to "ready" becoming true, and the willingness to sacrifice the "speed" of iteration (number of times/sec around the loop) in service of that wish. This would be the common case in indefinite spinning situations that are prevalent in many-core latency sensitive stacks today. [e.g. I would expect https://github.com/LMAX-Exchange/disruptor/blob/f29b3148c2eef3aa2dc5d5f570d7dde92b2f98ba/src/main/java/com/lmax/disruptor/BusySpinWaitStrategy.java#L28 to elect to use the spinLoopHint() ]. It does not harm, and can only help the cause. [Note that there is currently no way to achieve this hint in Javadom, leaving such busy spinning strategies written in Java at a disadvantage when compared to their C cousins executing on identical platforms. That's the gap that this proposed spinLoopHint() JEP is intended to close.] In contrast: while(!ready){ spinYield(); }; Would declare (per the JavaDoc suggested for spinYield()) a very different intent: I.e. an intent to spin but eventually back off, and a wish to relinquish resources (including the cpu itself) more aggressively than the empty loop would. While I can certainly envision new implementations that may want to use such a call, it would be useful to try and find actual places where this call would be made in current use cases. Since most of the the desired effect can be achieved in current Java, there are already multiple implementations of non-indefinite spinning out there, and looking at them in this context may be useful. Having done a cursory scan of a few such loops, I suspect that many current spin-then-backoff implementations are likely to avoid using such a fuzzy implementation because they would normally desire more control over the backoff logic. E.g. various "non-busy" WaitStrategy variants (see implementations of WaitStrategy found here: https://github.com/LMAX-Exchange/disruptor/tree/f29b3148c2eef3aa2dc5d5f570d7dde92b2f98ba/src/main/java/com/lmax/disruptor ) make specific choices about how to not busily-spin. Specific and current non-busy-spinning implementation variants include yielding, blocking, sleeping, blocking with a timeout, "lite" blocking, and a phased backoff strategy. I would expect that none of those would make use of the suggested spinYield() because each is making a different choice about backoff behavior. However, several of them (e.g. YieldingWaitStrategy and PhasedBackoffWaitStrategy ] would probably make use of spinLoopHint() [in the spinning parts that have not yet decided to back off], even though they don't spin indefinitely. [here too, spinLoopHint does no harm, and can only help their cause]. It does feel like letting the JVM (and underlying platform) implement spinning logic may be more desirable and portable for some things than specific strategy implementations written in Java, but evolving the proper API for such spins-with-backoff will probably entail studying the various things that may be expected of them (the richness of the Disruptor's not-entirely-busy strategies alone suggests that there is a need to indicate intent more clearly and richly than a single no-args call can do). I would submit that developing this API is orthogonal to the intend and purpose of the proposed spinLoopHint() JEP, and that we should work on it separately. > And given that programmers cannot portably comply, the method must > allow implementations that take the best course of action known to the JVM. I agree, but in the sense of "best course of action for achieving the implied intent compared to an empty spin loop with no hint". We agree that a nop implementation is valid. Things that "do more than a nop" should strive to move the behavior in the indicated direction compared to that. Agreeing on what that direction is for each call is key. There is a lot more than PAUSE that can be done in a spinLoopHint(), BTW. E.g. since a spinLoopHint() (in my suggested JavaDoc intent) indicates higher responsiveness as a priority, it would be valid and useful (but in no way required) for the JVM to work to *reduce* the likelihood of yielding the CPU in a loop that contained the hint. E.g. if there was some way for the JVM to communicate this preference to the underlying scheduling levels (OS, hypervisor, and even BIOS and HW power management), that would work to improve the behavior in the desired direction. I can envision interesting choices around isolcpus, tasksets, and weight decisions in cpu load balancing decisions, or even priorities. But I really have no desire to implement any of those at this time? > Despite all of the above, I agree that an OK initial hotspot implementation > is just to emit PAUSE if on x86 else no-op. It might be worth then > experimenting with randomized branching etc on other platforms, and > someday further exploring some cheap form of load detection, perhaps > kicking in only upon repeated invocation. > > -Doug > From pavel.rappo at oracle.com Thu Oct 29 10:36:48 2015 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 29 Oct 2015 10:36:48 +0000 Subject: CharSequence.subSequence optimizations In-Reply-To: <56316CF6.5050506@oracle.com> References: <15474975-3460-41BA-8582-112A5E5FDE57@oracle.com> <56316CF6.5050506@oracle.com> Message-ID: <7116593A-3EFA-47DC-8253-FDFC7BA3406C@oracle.com> > On 29 Oct 2015, at 00:48, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote: > > Doesn't that break when CharSequence implementation is mutable? > E.g. with StringBuilder, you cannot return "this" when "end == > StringBuilder.length()" at the time of .subSequence() call. True. This trick cannot be used in cases where CharSequence is able to change its length. (As far as I understand, possible changes in contents are ok.) Thanks. From michael.haupt at oracle.com Thu Oct 29 10:58:15 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 29 Oct 2015 11:58:15 +0100 Subject: RFR(XS): 8139863: [TESTBUG] Need to port tests for JDK-8134903 to 8u-dev Message-ID: <2E8BB4F7-4208-4038-B207-63BE2CADBCDA@oracle.com> Dear all, cross-posted to jdk8u-dev and core-libs-dev. Please review this change. Issue: https://bugs.openjdk.java.net/browse/JDK-8139863 Webrev: http://cr.openjdk.java.net/~mhaupt/8139863/webrev.00 This adds a missing test to 8u-dev that was not pushed along with the feature backport it belongs to. The backport was approved; see http://mail.openjdk.java.net/pipermail/jdk8u-dev/2015-September/004185.html. Thanks, Michael -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment From staffan.larsen at oracle.com Thu Oct 29 12:54:23 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 29 Oct 2015 13:54:23 +0100 Subject: [RFR] (S) 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests In-Reply-To: <5630605C.6070708@oracle.com> References: <5629CBA7.9070007@oracle.com> <E547095E-4726-4F35-B3B5-AB636BF9373A@oracle.com> <562E9780.3090309@oracle.com> <562EA70D.3090806@oracle.com> <5630605C.6070708@oracle.com> Message-ID: <E3284CB0-9A7D-43A2-9719-8FAE74F7DA19@oracle.com> Looks good (still)! Thanks, /Staffan > On 28 okt. 2015, at 06:42, Chris Plummer <chris.plummer at oracle.com> wrote: > > Hello, > > I've fixed the new jvmci tests. New webrevs found here: > > http://cr.openjdk.java.net/~cjplummer/8140189/webrev.01/webrev.hotspot > http://cr.openjdk.java.net/~cjplummer/8140189/webrev.01/webrev.jdk > > Only the hotspot/test/compiler/jvmci files have changed since the previous webrev. If you just want to look at a patch of those changes, they can be found here: > > http://cr.openjdk.java.net/~cjplummer/8140189/webrev.01/jvmci.patch > > The changes were straight forward. In all cases for the jvmci tests the diff is: > > - * @library / /testlibrary /../../test/lib > + * @library / /testlibrary /test/lib > > thanks, > > Chris > > On 10/26/15 3:19 PM, Ioi Lam wrote: >> Hi Chris, >> >> Your changes look good to me. I think it's better to fix the jvmci tests as well in a single push. >> >> Thanks >> - Ioi >> >> On 10/26/15 2:13 PM, Chris Plummer wrote: >>> I just pulled the latest hs-rt, and got about 30 new jvmci tests that are using "/../../test/lib". I can fix them with this push, or file a separate bug or send out a fix after I do this push. If I fix with this push, do you want another review? I'll test with jprt and run the jvmci tests locally. >>> >>> thanks, >>> >>> Chris >>> >>> >>> On 10/23/15 7:50 AM, Staffan Larsen wrote: >>>> Looks good! Thanks for doing this. >>>> >>>> /Staffan >>>> >>>>> On 23 okt. 2015, at 07:54, Chris Plummer <chris.plummer at oracle.com> wrote: >>>>> >>>>> Hello, >>>>> >>>>> Please review the following fix for 8140189: >>>>> >>>>> http://cr.openjdk.java.net/~cjplummer/8140189/webrev.00/webrev.hotspot >>>>> http://cr.openjdk.java.net/~cjplummer/8140189/webrev.00/webrev.jdk >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8140189 >>>>> >>>>> Please also see the following CR, which has much more extensive discussion of the problem: >>>>> >>>>> jtreg produces class files outside the JTwork directory >>>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901527 >>>>> >>>>> All the diffs for the tests simply replace "/../../test/lib" with "/test/lib". The changes in TEST.ROOT are what allow this. It is probably much easier to look at the patch than to look at each file in the webrev. All the test diffs look pretty much like the following: >>>>> >>>>> - * @library /testlibrary /../../test/lib >>>>> + * @library /testlibrary /test/lib >>>>> >>>>> or >>>>> >>>>> - * @library /../../test/lib/share/classes >>>>> + * @library /test/lib/share/classes >>>>> >>>>> Tested with jprt. Also ran the following jtreg tests on a linux/x64 host with a fastdebug build: >>>>> >>>>> -Ran all hotspot jtreg tests. >>>>> -Ran all modified jdk jtreg tests. >>>>> -Ran jdk tier1 and tier2 jtreg tests. >>>>> >>>>> There were some failures and errors, but they were replicated when testing with a clean repo also and are unrelated to my changes. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>> >> > From chris.hegarty at oracle.com Thu Oct 29 14:12:14 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 29 Oct 2015 14:12:14 +0000 Subject: RFR [9] 8140606: Update library code to use internal Unsafe In-Reply-To: <563148B8.4090105@oracle.com> References: <EC502489-56E1-480E-9FA7-93FC4BB263FB@oracle.com> <563148B8.4090105@oracle.com> Message-ID: <77E0A2DB-B650-4EAE-B951-21530A59CED8@oracle.com> On 28 Oct 2015, at 22:14, Alan Bateman <Alan.Bateman at oracle.com> wrote: > On 28/10/2015 19:55, Chris Hegarty wrote: >> Following on from 8139891 "Prepare Unsafe for true encapsulation? [1], >> the JDK library code should use the internal Unsafe class, and not >> sun.misc.Unsafe. >> >> http://cr.openjdk.java.net/~chegar/8140606/00/ >> >> This will be pushed to jdk9/dev once 8139891 makes its way from >> hs-rt. > With the interim CORBA removed then can the corba repo copy of ManagedLocalsThread go away instead of switching it to the internal Unsafe? Otherwise looks good to me. Yes, good point. I updated just the corba webrev. http://cr.openjdk.java.net/~chegar/8140606/01/corba/ I?ll be tackling ManageLocalsThread separately in the near future so have done just the minimum in corba for now. -Chris. From chris.hegarty at oracle.com Thu Oct 29 14:12:10 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 29 Oct 2015 14:12:10 +0000 Subject: RFR [9] 8140606: Update library code to use internal Unsafe In-Reply-To: <CA+kOe0_M8pZrFPG1+4MuUBsN=z97REPsmA3GazHCzNT32na9Dg@mail.gmail.com> References: <EC502489-56E1-480E-9FA7-93FC4BB263FB@oracle.com> <CA+kOe0_M8pZrFPG1+4MuUBsN=z97REPsmA3GazHCzNT32na9Dg@mail.gmail.com> Message-ID: <3002FA82-AB16-4C72-A3F4-397969517C38@oracle.com> On 28 Oct 2015, at 21:42, Martin Buchholz <martinrb at google.com> wrote: > This will cause jsr166 CVS code to no longer be able to run on jdk8, as it does today. We will probably need to fork soon anyways due to Paul's VarHandle code, but we had not expected it to be necessary before then. Is there any easy way for jsr166 CVS src/main to remain "portable" for a while longer? Alternatively, what can we do to continue using "good old sun.misc.Unsafe" in jsr166 CVS? Right, for now I think you can continue to use sun.misc.Unsafe, until VarHandles arrive. Since the major 166 sync is done, the amount of change in this area should be small. I can help out with incoming changes also, until you fork. -Chris. > On Wed, Oct 28, 2015 at 12:55 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote: > Following on from 8139891 "Prepare Unsafe for true encapsulation? [1], > the JDK library code should use the internal Unsafe class, and not > sun.misc.Unsafe. > > http://cr.openjdk.java.net/~chegar/8140606/00/ > > This will be pushed to jdk9/dev once 8139891 makes its way from > hs-rt. > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8139891 > From Alan.Bateman at oracle.com Thu Oct 29 15:10:20 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 29 Oct 2015 15:10:20 +0000 Subject: RFR [9] 8140606: Update library code to use internal Unsafe In-Reply-To: <77E0A2DB-B650-4EAE-B951-21530A59CED8@oracle.com> References: <EC502489-56E1-480E-9FA7-93FC4BB263FB@oracle.com> <563148B8.4090105@oracle.com> <77E0A2DB-B650-4EAE-B951-21530A59CED8@oracle.com> Message-ID: <563236DC.7050106@oracle.com> On 29/10/2015 14:12, Chris Hegarty wrote: > : > Yes, good point. I updated just the corba webrev. > > http://cr.openjdk.java.net/~chegar/8140606/01/corba/ > > I?ll be tackling ManageLocalsThread separately in the near > future so have done just the minimum in corba for now. > This looks good to me. -Alan. From michael.haupt at oracle.com Thu Oct 29 15:20:27 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 29 Oct 2015 16:20:27 +0100 Subject: RFR(S): 8131129: Attempt to define a duplicate BMH$Species class In-Reply-To: <5630F9AF.5040608@oracle.com> References: <A60BF64A-8C53-4D51-A630-79E58D1A4AD8@oracle.com> <5630B93E.6020307@oracle.com> <CAJUsCJBdh-R2fpRy9q1uycUY5a-mSR7Ovnj7avTspnwpunhbEQ@mail.gmail.com> <5630F9AF.5040608@oracle.com> Message-ID: <225CAFC1-34B0-4132-B7D8-C76CDEB6C9D8@oracle.com> Hi Vladimir, Peter, once more, thanks for all your comments. The revised webrev is at http://cr.openjdk.java.net/~mhaupt/8131129/webrev.01/. Best, Michael > Am 28.10.2015 um 17:37 schrieb Vladimir Ivanov <vladimir.x.ivanov at oracle.com>: > > Peter, > >> Hi Vladimir, I think you are right. The proposed fix alone even >> increases the chance of duplicate class definition attempts as it delays >> registration in cache to after whole clinit successfully finishes. I >> would still keep this initialization rearrangement as it fixes the >> possible publication race too. If the source of 1st exception is from >> clinit method execution, then it would be best to skip forced class >> initialization and delay it to its 1st use. Eager initialization does >> not serve any purpose if the registration into cache is performed out of >> clinit method as proposed in the fix. >> >> To summarise: the proposed initialization fix would have to be >> accompanied with removal of forced class initialization to achieve the >> effect of your option (1) below. > There's no benefit from skipping eager initialization - if class initialization fails, the class becomes unusable anyway. > > The idea was to split class init and SPECIES_DATA field init. It would allow to retry Species_* class init later once the initial attempt failed. But there's not much value is that right now, since VM doesn't unload generated adapters. So, once code cache is exhausted there's not much JVM can do about it. > > Also, publishing not fully initialized Species_* class requires all users to check whether the initialization is completed, which can be too much from performance perspective. > > So, I'm in favor of modified (3) Michael proposed. > > Best regards, > Vladimir Ivanov > >> Regards, Peter >> >> Michael, Peter, >> >> Thanks for detailed analysis! It was a hard one to track down :-) >> >> Unfortunately, I don't see how the proposed change fixes the problem. >> >> The failure occurs during SpeciesData instantiation >> (BMH$SpeciesData.<init>). It means updateCache has not yet been called >> from getForClass: >> >> static SpeciesData getForClass(String types, Class<? extends >> BoundMethodHandle> clazz) { >> return updateCache(types, new SpeciesData(types, clazz)); >> } >> >> With your changes, updateCache is called only after successful loading >> of a class. So, the cache isn't updated if there was an error during >> previous attempt. >> >> The real problem is more severe IMO. The loaded class is useless when >> its initialization finishes abruptly, so there's no way to instantiate >> it or reload. Right now it is manifested as a duplicate class definition >> attempt, but if you avoid repeated class loading it will just fail >> slightly later - the system is already broken and there's no way to recover. >> >> I see the following ways to proceed: >> (1) delay class initialization (fill in Species_*.SPECIES_DATA field >> afterwards) and attempt to finish initialization on subsequent requests, >> but skipping class loading step; >> >> (2) use VM anonymous classes (see JDK-8078602 [1]) and just retry >> Species creation; >> >> (3) give up on that particular Species shape and throw an error >> whenever it is requested (how it works right now, but with more >> meaningful error message). >> >> I remember I experimented with (2), but even after JDK-8078629 [2] there >> was still measurable peak performance regression on Octane/Nashorn. >> >> (1) looks more favorable and robust, but right now there shouldn't be >> much difference - there's no support in VM to unload MH.linkTo* >> adapters, so the failure will repeatedly occur once the code cache is full. >> >> My conclusion is that it is mostly a test problem, but java.lang.invoke >> framework should clearly communicate the reason why it fails. Since the >> test is aware about code cache overflow problems, it looks preferable to >> go with (1) or (3) for now. VM should throw VirtualMachineError on >> repeated attempts to instantiate SPECIES_DATA and the test already >> filters them out. >> >> Best regards, >> Vladimir Ivanov >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8078602 >> [2] https://bugs.openjdk.java.net/browse/JDK-8078629 >> >> On 10/28/15 12:19 PM, Michael Haupt wrote: >> >> Dear all, >> >> please review this change. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8131129 >> Webrev: http://cr.openjdk.java.net/~mhaupt/8131129/webrev.00/ >> >> Thanks to Peter Levart, who has contributed the actual code to fix >> the issue. >> >> The background of this is as follows. Bug 8131129 is an intermittent >> failure in a multi-threaded test for LambdaForm caching. The failure >> was not reproducible but used to occur on various platforms every >> now and then. I was able to dig up some stack traces that reveal the >> real cause in internal test logs. These traces finally confirmed a >> suspicion that both Peter and I had had but could, for lack of >> complete failure information, not pin down as the cause of the >> issue. (Most traces from failures of the test were only partial, as >> the test harness is selective about traces it logs.) >> >> At the heart of the problem is an overflowing code cache for >> adapters in the VM. The test, dynamically generating considerable >> amounts of LambdaForm and BoundMethodHandle species classes, would >> eventually trigger this overflow. The place at which the problem >> would surface is this, in >> BoundMethodHandle.Factory.generateConcreteBMHClass(): >> >> Class<? extends BoundMethodHandle> bmhClass = >> //UNSAFE.defineAnonymousClass(BoundMethodHandle.class, >> classFile, null).asSubclass(BoundMethodHandle.class); >> UNSAFE.defineClass(className, classFile, 0, classFile.length, >> BoundMethodHandle.class.getClassLoader(), null) >> .asSubclass(BoundMethodHandle.class); >> UNSAFE.ensureClassInitialized(bmhClass); >> >> The test would generate a BMH species with a given type signature >> via defineClass and immediately thereafter force initialisation of >> that class, in the course of which a SpeciesData instance is >> supposed to be created and entered in the BMH species cache. In case >> the VM's adapter code cache overflowed during this operation, the >> BMH species' class initialiser would not finish its execution >> properly, leading to a stale placeholder entry left behind in the >> cache. The presence of this very placeholder would trick the next >> request for a BMH species with the same type signature into >> believing the class needed to be defined, leading to the observed >> failure. >> >> An exemplary stack trace is appended below. >> >> Both Peter and I had come up with solutions, but I think Peter's is >> better as it gets rid of the somewhat intricate and semi-hidden >> cache registration call made from generated code. With Peter's fix, >> it's all visible in library code now. >> >> Thanks, >> >> Michael >> >> >> >> ----- >> java.lang.InternalError: java.lang.NoSuchMethodException: no such >> method: >> java.lang.invoke.MethodHandle.linkToStatic(Object,Object,int,Object,Object,Object,Object,Object,Object,Object,MemberName)Object/invokeStatic >> at >> java.lang.invoke.MethodHandleStatics.newInternalError(MethodHandleStatics.java:120) >> at >> java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:214) >> at >> java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:188) >> at >> java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:177) >> at >> java.lang.invoke.DirectMethodHandle.make(DirectMethodHandle.java:84) >> at >> java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:1655) >> at >> java.lang.invoke.MethodHandles$Lookup.getDirectMethod(MethodHandles.java:1600) >> at >> java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:777) >> at >> java.lang.invoke.BoundMethodHandle$Factory.makeCbmhCtor(BoundMethodHandle.java:817) >> at >> java.lang.invoke.BoundMethodHandle$Factory.makeCtors(BoundMethodHandle.java:772) >> at >> java.lang.invoke.BoundMethodHandle$SpeciesData.<init>(BoundMethodHandle.java:347) >> at >> java.lang.invoke.BoundMethodHandle$SpeciesData.getForClass(BoundMethodHandle.java:411) >> at >> java.lang.invoke.BoundMethodHandle$Species_IL7.<clinit>(Species_IL7) >> at sun.misc.Unsafe.ensureClassInitialized(Native Method) >> at >> java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:718) >> at >> java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) >> at >> java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:388) >> at >> java.lang.invoke.LambdaFormEditor.newSpeciesData(LambdaFormEditor.java:363) >> at >> java.lang.invoke.LambdaFormEditor.makeArgumentCombinationForm(LambdaFormEditor.java:631) >> at >> java.lang.invoke.LambdaFormEditor.filterArgumentForm(LambdaFormEditor.java:612) >> at >> java.lang.invoke.MethodHandles.filterArgument(MethodHandles.java:2667) >> at >> java.lang.invoke.MethodHandles.filterArguments(MethodHandles.java:2654) >> at TestMethods$4.getMH(TestMethods.java:180) >> at TestMethods.getTestCaseMH(TestMethods.java:548) >> at >> LFMultiThreadCachingTest.lambda$doTest$0(LFMultiThreadCachingTest.java:80) >> at LFMultiThreadCachingTest$$Lambda$5/21979926.run(Unknown >> Source) >> at java.lang.Thread.run(Thread.java:745) >> Caused by: java.lang.NoSuchMethodException: no such method: >> java.lang.invoke.MethodHandle.linkToStatic(Object,Object,int,Object,Object,Object,Object,Object,Object,Object,MemberName)Object/invokeStatic >> at >> java.lang.invoke.MemberName.makeAccessException(MemberName.java:873) >> at >> java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:990) >> at >> java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:212) >> ... 25 more >> Caused by: java.lang.NoSuchMethodError: >> java.lang.invoke.MethodHandle.linkToStatic(Ljava/lang/Object;Ljava/lang/Object;ILjava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object; >> at java.lang.invoke.MethodHandleNatives.resolve(Native Method) >> at >> java.lang.invoke.MemberName$Factory.resolve(MemberName.java:962) >> at >> java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:987) >> ... 26 more >> Caused by: java.lang.VirtualMachineError: out of space in CodeCache >> for method handle intrinsic >> ... 29 more >> java.lang.LinkageError: loader (instance of <bootloader>): >> attempted duplicate class definition for name: >> "java/lang/invoke/BoundMethodHandle$Species_IL7" >> at sun.misc.Unsafe.defineClass(Native Method) >> at >> java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:715) >> at >> java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) >> at >> java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:388) >> at >> java.lang.invoke.LambdaFormEditor.newSpeciesData(LambdaFormEditor.java:363) >> at >> java.lang.invoke.LambdaFormEditor.makeArgumentCombinationForm(LambdaFormEditor.java:631) >> at >> java.lang.invoke.LambdaFormEditor.filterArgumentForm(LambdaFormEditor.java:612) >> at >> java.lang.invoke.MethodHandles.filterArgument(MethodHandles.java:2667) >> at >> java.lang.invoke.MethodHandles.filterArguments(MethodHandles.java:2654) >> at TestMethods$4.getMH(TestMethods.java:180) >> at TestMethods.getTestCaseMH(TestMethods.java:548) >> at >> LFMultiThreadCachingTest.lambda$doTest$0(LFMultiThreadCachingTest.java:80) >> at LFMultiThreadCachingTest$$Lambda$5/21979926.run(Unknown >> Source) >> at java.lang.Thread.run(Thread.java:745) >> java.lang.LinkageError: loader (instance of <bootloader>): >> attempted duplicate class definition for name: >> "java/lang/invoke/BoundMethodHandle$Species_IL7" >> at sun.misc.Unsafe.defineClass(Native Method) >> at >> java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:715) >> at >> java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) >> at >> java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:388) >> at >> java.lang.invoke.LambdaFormEditor.newSpeciesData(LambdaFormEditor.java:363) >> at >> java.lang.invoke.LambdaFormEditor.makeArgumentCombinationForm(LambdaFormEditor.java:631) >> at >> java.lang.invoke.LambdaFormEditor.filterArgumentForm(LambdaFormEditor.java:612) >> at >> java.lang.invoke.MethodHandles.filterArgument(MethodHandles.java:2667) >> at >> java.lang.invoke.MethodHandles.filterArguments(MethodHandles.java:2654) >> at TestMethods$4.getMH(TestMethods.java:180) >> at TestMethods.getTestCaseMH(TestMethods.java:548) >> at >> LFMultiThreadCachingTest.lambda$doTest$0(LFMultiThreadCachingTest.java:80) >> at LFMultiThreadCachingTest$$Lambda$5/21979926.run(Unknown >> Source) >> at java.lang.Thread.run(Thread.java:745) >> STATUS:Failed.STATUS:Failed.STATUS:Failed.`main' threw exception: >> java.lang.LinkageError: loader (instance of <bootloader>): attempted >> duplicate class definition for name: >> "java/lang/invoke/BoundMethodHandle$Species_IL7" >> `main' threw exception: java.lang.LinkageError: loader (instance of >> <bootloader>): attempted duplicate class definition for name: >> "java/lang/invoke/BoundMethodHandle$Species_IL7" >> `main' threw exception: java.lang.InternalError: >> java.lang.NoSuchMethodException: no such method: >> java.lang.invoke.MethodHandle.linkToStatic(Object,Object,int,Object,Object,Object,Object,Object,Object,Object,MemberName)Object/invokeStatic >> java.lang.LinkageError: loader (instance of <bootloader>): >> attempted duplicate class definition for name: >> "java/lang/invoke/BoundMethodHandle$Species_IL7" >> at sun.misc.Unsafe.defineClass(Native Method) >> at >> java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:715) >> at >> java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) >> ----- >> >> >> -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment From martinrb at google.com Thu Oct 29 16:13:06 2015 From: martinrb at google.com (Martin Buchholz) Date: Thu, 29 Oct 2015 09:13:06 -0700 Subject: RFR [9] 8140606: Update library code to use internal Unsafe In-Reply-To: <3002FA82-AB16-4C72-A3F4-397969517C38@oracle.com> References: <EC502489-56E1-480E-9FA7-93FC4BB263FB@oracle.com> <CA+kOe0_M8pZrFPG1+4MuUBsN=z97REPsmA3GazHCzNT32na9Dg@mail.gmail.com> <3002FA82-AB16-4C72-A3F4-397969517C38@oracle.com> Message-ID: <CA+kOe0_H-DOhm-ApT=k=SKGc8H4=yMfdkph0eXMU=8A+X7Nuyw@mail.gmail.com> Here's the plan: - There will be an upcoming "round two" of jsr166 integration, focusing on jtreg tests. - We already need to massage jsr166 sources for integration, and adjusting sun.misc.Unsafe to the new blessed name is relatively trivial. - (There will be confusion and resistance to locking down Unsafe. I wouldn't be surprised if future users built their own jdk just to expose Unsafe functionality.) On Thu, Oct 29, 2015 at 7:12 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote: > > On 28 Oct 2015, at 21:42, Martin Buchholz <martinrb at google.com> wrote: > > > This will cause jsr166 CVS code to no longer be able to run on jdk8, as > it does today. We will probably need to fork soon anyways due to Paul's > VarHandle code, but we had not expected it to be necessary before then. Is > there any easy way for jsr166 CVS src/main to remain "portable" for a while > longer? Alternatively, what can we do to continue using "good old > sun.misc.Unsafe" in jsr166 CVS? > > Right, for now I think you can continue to use sun.misc.Unsafe, > until VarHandles arrive. Since the major 166 sync is done, the > amount of change in this area should be small. I can help out > with incoming changes also, until you fork. > > -Chris. > > > On Wed, Oct 28, 2015 at 12:55 PM, Chris Hegarty < > chris.hegarty at oracle.com> wrote: > > Following on from 8139891 "Prepare Unsafe for true encapsulation? [1], > > the JDK library code should use the internal Unsafe class, and not > > sun.misc.Unsafe. > > > > http://cr.openjdk.java.net/~chegar/8140606/00/ > > > > This will be pushed to jdk9/dev once 8139891 makes its way from > > hs-rt. > > > > -Chris. > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8139891 > > > > From aleksey.shipilev at oracle.com Thu Oct 29 17:46:39 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 29 Oct 2015 20:46:39 +0300 Subject: CharSequence.subSequence optimizations In-Reply-To: <7116593A-3EFA-47DC-8253-FDFC7BA3406C@oracle.com> References: <15474975-3460-41BA-8582-112A5E5FDE57@oracle.com> <56316CF6.5050506@oracle.com> <7116593A-3EFA-47DC-8253-FDFC7BA3406C@oracle.com> Message-ID: <56325B7F.70009@oracle.com> On 10/29/2015 01:36 PM, Pavel Rappo wrote: >> On 29 Oct 2015, at 00:48, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote: >> Doesn't that break when CharSequence implementation is mutable? >> E.g. with StringBuilder, you cannot return "this" when "end == >> StringBuilder.length()" at the time of .subSequence() call. > > True. This trick cannot be used in cases where CharSequence is able to change > its length. (As far as I understand, possible changes in contents are ok.) While Javadoc appears silent on this front, the expectation seems to be that .subSequence returns the "detached" subsequence. See spec change here: https://bugs.openjdk.java.net/browse/JDK-8028757 So, I think this trick works only for the completely immutable CharSequences, which apparently includes only Strings. And, AFAIU from the code, String already returns "this" in cases like these? Thanks, -Aleksey P.S. I think it would be evil to turn subSequence into the forwarding view. These were considered before: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-July/027838.html From lance.andersen at oracle.com Thu Oct 29 18:06:45 2015 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 29 Oct 2015 14:06:45 -0400 Subject: RFR (JAXP) : 8081248: Implement JEP 268: XML Catalog API In-Reply-To: <561F5B2E.7060107@oracle.com> References: <561F5B2E.7060107@oracle.com> Message-ID: <DA305F25-CDB1-416F-AA8C-10F651FF7596@oracle.com> Hi Joe, The current spediff, webrev seems OK to me. Thank you for your diligence on this Best Lance On Oct 15, 2015, at 3:52 AM, huizhe wang <huizhe.wang at oracle.com> wrote: > Hi all, > > Please help review JEP 268 implementation: > https://bugs.openjdk.java.net/browse/JDK-8081248 > > Catalog specification: > https://www.oasis-open.org/committees/download.php/14809/xml-catalogs.html > > webrevs: > http://cr.openjdk.java.net/~joehw/jdk9/8081248/webrev/ > > > A Catalog is basically an ordered list of entries that map external references to local resources using string identifiers called systemId/publicId. The main function of the Catalog API therefore is 1) parse a catalog; 2) use it to find a matching entry and resolve the resource referenced in an XML document. > > For common use cases, an application would simply acquire a CatalogResolver and set it on a parser to be used for resource resolution, refer to the test for an example. > > The unit test contains test cases for the simple entries. Since SQE test development has been in parallel with the dev work, this unit test didn't have to cover all of the functions. What it does is to test and demonstrate the use in a real environment, using a CatalogResolver to actually resolves resources in XML documents, while the SQE tests focus on having a full coverage by matching literal strings without involving XML documents. The SQE test suite has gone through internal reviews and will start public review following this review. > > Thanks, > Joe > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From bradford.wetmore at oracle.com Thu Oct 29 21:12:49 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 29 Oct 2015 14:12:49 -0700 Subject: RFR(XXS): 8140514: [TESTBUG] enable sun/security/pkcs11 tests on Linux/ppc64 In-Reply-To: <CA+3eh13Bdd2R0NnV=ZYkee-Gd3jmpYwb5g3xc7hQUY9c4NiiTg@mail.gmail.com> References: <CA+3eh138XaCped1JCKmnDC8wgurWn=ZJFqO8=y5x3adr1ov+Lw@mail.gmail.com> <CA+3eh13Bdd2R0NnV=ZYkee-Gd3jmpYwb5g3xc7hQUY9c4NiiTg@mail.gmail.com> Message-ID: <56328BD1.5030502@oracle.com> Most of us have been at JavaOne this week. Looks ok to me. Brad On 10/27/2015 11:02 AM, Volker Simonis wrote: > Resend to core-libs-dev to attract a broader audience :) > > On Mon, Oct 26, 2015 at 3:32 PM, Volker Simonis > <volker.simonis at gmail.com> wrote: >> Hi, >> >> can somebody please review the following trivial fix to enable the >> pkcs11 tests for linux/ppc64: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2015/8140514/ >> https://bugs.openjdk.java.net/browse/JDK-8140514 >> >> The pkcs11 tests need to load the native library libnss3.so the >> location of which is system dependent. Until now, the test didn't >> consider Linux/ppc64 systems. >> >> The fix is simple: just add a corresponding map entry which maps the >> platform to the correct library path. All the systems I've checked >> (various Fedora, OpenSUSE, SLES and RHEL distros) have libnss3.so >> under /usr/lib64. >> >> Thank you and best regards, >> Volker From michael.haupt at oracle.com Fri Oct 30 07:12:50 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Fri, 30 Oct 2015 08:12:50 +0100 Subject: [8u-dev] RFR(XS): 8139863: [TESTBUG] Need to port tests for JDK-8134903 to 8u-dev In-Reply-To: <2E8BB4F7-4208-4038-B207-63BE2CADBCDA@oracle.com> References: <2E8BB4F7-4208-4038-B207-63BE2CADBCDA@oracle.com> Message-ID: <7DA08B0B-7532-4695-B89B-B4FC75CC057E@oracle.com> (reposted with corrected subject line) > Am 29.10.2015 um 11:58 schrieb Michael Haupt <michael.haupt at oracle.com>: > > Dear all, > > cross-posted to jdk8u-dev and core-libs-dev. > > Please review this change. > Issue: https://bugs.openjdk.java.net/browse/JDK-8139863 > Webrev: http://cr.openjdk.java.net/~mhaupt/8139863/webrev.00 > > This adds a missing test to 8u-dev that was not pushed along with the feature backport it belongs to. The backport was approved; see http://mail.openjdk.java.net/pipermail/jdk8u-dev/2015-September/004185.html. > > Thanks, > > Michael > -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment From nikolay at azulsystems.com Wed Oct 21 15:39:36 2015 From: nikolay at azulsystems.com (Nikolay Gorshkov) Date: Wed, 21 Oct 2015 18:39:36 +0300 Subject: RFR [7] 8133206: "java.lang.OutOfMemoryError: unable to create new native thread" caused by upgrade to zlib 1.2.8 In-Reply-To: <561E7C96.9010207@azulsystems.com> References: <561E7C96.9010207@azulsystems.com> Message-ID: <5627B1B8.6080307@azulsystems.com> Hi Sherman, Thank you for your reply! My answers are inlined. > Can you be more specific about the "class loading cases" above? Sounds > more like we have a memory leaking here (the real root cause)? for example > the inflateEnd() never gets called? I agree, the real root cause is probably the following issue that exists since the end of 2002: https://bugs.openjdk.java.net/browse/JDK-4797189 "Finalizers not called promptly enough" And it is "the absence of a general solution to the non-heap resource exhaustion problem". zlib's inflateEnd() function is called by void java.util.zip.Inflater.end(long addr) native method only, and this method, in turn, is called only by void java.util.zip.Inflater.end() and void java.util.zip.Inflater.finalize() methods. According to the experiments, the typical stack trace for instantiating java.util.zip.Inflater is: java.util.zip.Inflater.<init>(Inflater.java:116) java.util.zip.ZipFile.getInflater(ZipFile.java:450) java.util.zip.ZipFile.getInputStream(ZipFile.java:369) java.util.jar.JarFile.getInputStream(JarFile.java:412) org.jboss.virtual.plugins.context.zip.ZipFileWrapper.openStream(ZipFileWrapper.java:222) <more jboss frames> org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:592) java.security.AccessController.doPrivileged(Native Method) org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:591) <more jboss frames> org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:447) java.lang.ClassLoader.loadClass(ClassLoader.java:358) java.lang.Class.forName0(Native Method) java.lang.Class.forName(Class.java:278) org.jboss.deployers.plugins.annotations.WeakClassLoaderHolder.loadClass(WeakClassLoaderHolder.java:72) <more jboss and other frames> It's quite hard to understand who is responsible for not calling Inflater.end() method explicitly; probably, it is the jboss/application's code. Unfortunately, we were in "it worked before and is broken now" customer situation here, so needed to fix it anyway. > From the doc/impl in inflate() it appears the proposed change should be > fine, though it's a little hacky, as you never know if it starts to return > Z_OK from some future release(s). Since the "current" implementation > never returns Z_OK, it might be worth considering to keep the Z_OK logic > asis in Inflater.c, together with the Z_BUF_ERROR, just in case? OK, I added handling of Z_OK code back. > I would be desired to add some words in Inflater.c to remind the > future maintainer why we switched from partial to finish and why to > check z_buf_error. I agree, added a comment. The updated webrev is available here: http://cr.openjdk.java.net/~nikgor/8133206/jdk7u-dev/webrev.01/ Thanks, Nikolay From oleksandr.otenko at gmail.com Mon Oct 26 17:12:35 2015 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Mon, 26 Oct 2015 10:12:35 -0700 Subject: [concurrency-interest] Is Reference.reachabilityFence() needed in Reference constructor? In-Reply-To: <5627C696.1070806@oracle.com> References: <56278653.9080501@gmail.com> <5627B2E4.205@oracle.com> <5627B502.2010007@redhat.com> <5627C696.1070806@oracle.com> Message-ID: <B2771568-0B1B-4CD6-849F-4D4B48BCD81B@gmail.com> Wouldn?t it be possible to add a test that will always be false? eg Reference(T referent, ReferenceQueue<? super T> queue) { this.referent = referent; // - safepoint with GC happens, 'referent' is found weakly-reachable, 'this' Reference is hooked on the pending chain // - ReferenceHandler thread unhooks 'this' from pending chain and tries to enqueue it, but this.queue is still null // - BANG! NPE in Referencehandler thread which terminates it! this.queue = (queue == null) ? ReferenceQueue.NULL : queue; if (get() != referent) { // do a get() == referent test instead for Phantom ref System.out.println(referent + ? expected but ? + get() + ? found"); } } The point being that referent would need to stay alive due to Java semantics to align with get() and queue assignment. Alex > On 21 Oct 2015, at 10:08, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote: > > On 10/21/2015 06:53 PM, Andrew Haley wrote: >> On 10/21/2015 04:44 PM, Aleksey Shipilev wrote: >>> Of course, this does not tell another (scary) part of the story, what if >>> the Reference itself is not discovered as strong ref by GC, e.g. when it >>> isn't published on heap, or scalarized by compiler, etc. >>> reachabilityFence, as currently implemented, extends the "liveness" >>> scope of the local variable, but does not convey anything special to the >>> GC/runtime otherwise. >> >> If the Reference itself is not reachable from a strong root then the >> Reference is dead so we don't care what happens to it. But if the >> Reference is put on a reachable ReferenceQueue, then it's fine. > > Yes, if runtime stripes that instance before it is exposed anywhere > (e.g. scalarizes the weakref), or those references are dead (e.g. the > weakref is buried somewhere deep in garbage subgraph, and purged on > sweep), then everything goes awry. > > But the thing is, a WeakReference is put on ReferenceQueue by the GC > itself. In the object graph, ReferenceQueue does not normally reference > weakrefs back. Before enqueueing the reference GC has to first discover > that WeakReference -- but from where? In other words, "registering" on a > reachable RefQueue does not make weakref to be reachable. > > Case in point: > > public class WhereIsWaldo { > > public static void main(String... args) throws Exception { > for (int c = 0; true; c++) { > new WhereIsWaldo().work(c); > } > } > > final ReferenceQueue<Object> rq = new ReferenceQueue<>(); > > void work(int id) throws Exception { > hideWaldo(id); > findWaldo(id); > } > > WeakReference<Object> gwr; > > void hideWaldo(int id) { > // Does not work, d'uh > new WeakReference<>(new Object(), rq); > > // Does not work either :( > WeakReference<Object> wr = > new WeakReference<>(new Object(), rq); > > // This also does not help... once you leave the method, > // the weakref is gone. > Reference.reachabilityFence(wr); > > // This one helps, makes Waldo reachable > // gwr = wr; > } > > void findWaldo(int id) throws Exception { > while (Thread.currentThread().isAlive()) { > System.gc(); > Reference ref = rq.remove(1000); > if (ref != null) { > return; > } else { > System.out.println("Where's Waldo #" + id + "?"); > } > } > } > } > > > Thanks, > -Aleksey > > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest at cs.oswego.edu > http://cs.oswego.edu/mailman/listinfo/concurrency-interest From jsampson at guidewire.com Mon Oct 26 18:56:03 2015 From: jsampson at guidewire.com (Justin Sampson) Date: Mon, 26 Oct 2015 18:56:03 +0000 Subject: [concurrency-interest] Is Reference.reachabilityFence() needed in Reference constructor? In-Reply-To: <B2771568-0B1B-4CD6-849F-4D4B48BCD81B@gmail.com> References: <56278653.9080501@gmail.com> <5627B2E4.205@oracle.com> <5627B502.2010007@redhat.com> <5627C696.1070806@oracle.com> <B2771568-0B1B-4CD6-849F-4D4B48BCD81B@gmail.com> Message-ID: <DM2PR0501MB8758F01BC38A742903D7C79D1230@DM2PR0501MB875.namprd05.prod.outlook.com> Alex Otenko wrote: > Wouldn't it be possible to add a test that will always be false? > > eg > [...] > if (get() != referent) { > [...] > > The point being that referent would need to stay alive due to > Java semantics to align with get() and queue assignment. Couldn't the compiler just inline get() as this.referent, see that this.referent was just set to referent, and simplify this.referent != referent to false? Cheers, Justin From oleksandr.otenko at gmail.com Mon Oct 26 18:58:48 2015 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Mon, 26 Oct 2015 11:58:48 -0700 Subject: [concurrency-interest] Is Reference.reachabilityFence() needed in Reference constructor? In-Reply-To: <DM2PR0501MB8758F01BC38A742903D7C79D1230@DM2PR0501MB875.namprd05.prod.outlook.com> References: <56278653.9080501@gmail.com> <5627B2E4.205@oracle.com> <5627B502.2010007@redhat.com> <5627C696.1070806@oracle.com> <B2771568-0B1B-4CD6-849F-4D4B48BCD81B@gmail.com> <DM2PR0501MB8758F01BC38A742903D7C79D1230@DM2PR0501MB875.namprd05.prod.outlook.com> Message-ID: <225489E6-7DF9-4B26-96A8-C67B85F310EF@gmail.com> That would be the case, if it can assume access is single-threaded. Alex > On 26 Oct 2015, at 11:56, Justin Sampson <jsampson at guidewire.com> wrote: > > Alex Otenko wrote: > >> Wouldn't it be possible to add a test that will always be false? >> >> eg >> [...] >> if (get() != referent) { >> [...] >> >> The point being that referent would need to stay alive due to >> Java semantics to align with get() and queue assignment. > > Couldn't the compiler just inline get() as this.referent, see that > this.referent was just set to referent, and simplify this.referent > != referent to false? > > Cheers, > Justin From ioi.lam at oracle.com Fri Oct 30 17:00:58 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 30 Oct 2015 10:00:58 -0700 Subject: RFR (M) 8140802 - Clean up and refactor of class loading code for CDS Message-ID: <5633A24A.9070800@oracle.com> Please review the following fix: http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/ Bug: Clean up and refactor of class loading code for CDS https://bugs.openjdk.java.net/browse/JDK-8140802 Summary of fix: We need to clean up and refactor the class loading code in order to support CDS in JDK9 [1] Remove code that has been made obsolete by the module changes (such as supporting code used for meta-index file) [2] Add new whitebox API to be used by CDS-related tests. [3] Refactor the parsing of classlist files for future enhancements. [4] Add new APIs in the class loading code to support Oracle CDS enhancements. Tests: JPRT RBT - with same set of tests as hs-rt nightly Thanks - Ioi From roger.riggs at oracle.com Fri Oct 30 18:13:47 2015 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 30 Oct 2015 12:13:47 -0600 Subject: 8139803...Fix for 8132985 breaks OpenJDK build on windows In-Reply-To: <562F8FB1.5070000@oracle.com> References: <562F8EAC.1090401@oracle.com> <562F8FB1.5070000@oracle.com> Message-ID: <5633B35B.6040003@oracle.com> It would be most appreciated to get the fix into the jdk9-dev repo soonest. It is causing build failures on Windows. (It should have been pushed to jdk9-dev directly, since client integrates infrequently). Thanks, Roger [1] http://mail.openjdk.java.net/pipermail/2d-dev/2015-October/005785.html From mandy.chung at oracle.com Fri Oct 30 19:04:33 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 30 Oct 2015 12:04:33 -0700 Subject: Proposed API for JEP 259: Stack-Walking API Message-ID: <B405DF00-00FD-419A-9D99-82F079497841@oracle.com> JEP 259: http://openjdk.java.net/jeps/259 Javadoc for the proposed StackWalker API: http://cr.openjdk.java.net/~mchung/jdk9/jep259/api/java/lang/StackWalker.html A simple way to walk the stack: StackWalker walker = new StackWalker(StackWalker.Option.CLASS_REFERENCE); walker.walk((s) -> s.filter(f -> interestingClasses.contains(f.getDeclaringClass())).findFirst()); The current usage of sun.reflect.Reflection.getCallerClass(int depth) can be replaced with this StackWalker API. Any feedback on the proposed API is appreciated. Mandy P.S. webrev of the current implementation: http://cr.openjdk.java.net/~mchung/jdk9/jep259/webrev.00/ From roger.riggs at oracle.com Fri Oct 30 19:07:33 2015 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 30 Oct 2015 13:07:33 -0600 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <50EAA3DD-46F5-4BF2-B010-333CEE7187A9@oracle.com> References: <5613D01F.3000107@Oracle.com> <5613FEE6.2010907@oracle.com> <1391860289.1215500.1444171338590.JavaMail.zimbra@u-pem.fr> <56159B9A.4040404@Oracle.com> <1319440457.2004194.1444294182369.JavaMail.zimbra@u-pem.fr> <56168166.5030903@Oracle.com> <1200530124.2619128.1444329461357.JavaMail.zimbra@u-pem.fr> <5616BF66.3010607@Oracle.com> <278013257.2631892.1444332861717.JavaMail.zimbra@u-pem.fr> <33D01469-37DE-4502-8112-0E4865733AFF@oracle.com> <5616E345.9090609@Oracle.com> <A4D5091B-C41A-4EA4-B811-F4C3658B8AB0@oracle.com> <CACzrW9BPnBNKaXzLfZeJdD+5n_mZV-OM3TH+yD=suGB2mYR2CQ@mail.gmail.com> <91F25DF8-BC0F-44EB-A57D-A49FF7876DB9@oracle.com> <5617B184.7060803@oracle.com> <5617E141.7000503@Oracle.com> <50EAA3DD-46F5-4BF2-B010-333CEE7187A9@oracle.com> Message-ID: <5633BFF5.9090609@oracle.com> Hi John, Thanks for the followup. It is a subtle issue and seems to hinge on the relative priority of consistency in naming and the degree that historical artifacts ('mistakes') constrain contemporary patterns. If we were re-writing history: boolean nonNull(obj) could/should have been named 'isNonNull'. T nonNull(T, String) could/should have been T nonNullThrows(T, Supplier<Exception>) The notion that the prefix "nonNull" is already taken and the anti-pattern, seem a lower priority. The prefix can be understood to introduce a family of similar not necessarily identical semantics. Most method names try to describe the action taken, not the pre- or post-conditions. I prefer shorter names and was ready to capitulate until I ran into this: T requireNonNull(T) T requireNonNull(T, String) T requireNonNull(T, T) -- now is ambiguous with the pre-existing method So just add another word to disambiguate: T requireNonNullElse(T, T) -- now 23 characters counting required punctuation without room for the return value or arguments. T requireNonNullElseGet(T, Supplier<T>) The shorter names were intended to be easier to read and save the space on the line for the arguments which are the important parts of the expression. The longer names disambiguate adequately but add to the bulk of the code. I see maturing systems end up being weighed down by the seemingly necessary qualification. So in face of the tradeoffs, what were you proposing again? Roger On 10/28/15 5:44 PM, John Rose wrote: > On Oct 9, 2015, at 8:46 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote: >> >> The primary purpose of the existing 'requireNonNull' methods is to >> check for null >> and throw an exception. It is used for explicit testing and producing >> a cogent exception. >> Returning the value was a secondary benefit that allowed it to be >> used in fluent expressions. > > As I noted before, the stated purpose of "requireNonNull" can be > slightly widened to check for null, and either throw an exception or > return an alternative non-null value. This is a compatible change. > > Meanwhile, I just realized (after working on code in an IDE) that we > already have this API point: > > boolean nonNull(Object x) { return x != null; } > > The new proposed name "nonNullElse" would seem on first glance to be a > variation on that API point, but it's very different, since it returns > T instead of boolean. It seems to me that the prefix "nonNull" is > already taken, and we have added an incompatible method to that family. > The new API point "nonNullElse" is much closer in meaning to > "requireNonNull", as noted before: > > T nonNullElse(Object x, Object y) { return x != null ? x : y; } > > T requireNonNull(Object x) { return x != null ? x : throw ? } > > Having different overloadings of the same name confuse T and a > primitive type (boolean) is a known anti-pattern. (Cf. > List.remove(int|T).) In this case, the names differ but "nonNull" and > "nonNullElse" are going to be viewed together often as a group. They > are presented together in an IDE completer. When I complete a name, I > usually have in mind what I want it to return. Therefore, the > completion of "Objects.notN*" will show me a boolean-valued and a > T-valued result, one of which is not what I want. Meanwhile, if I > were to complete "Objects.req*" I would get a choicer of T-valued > operators, but not one particular one that I might want ("notNullElse"). > > As I said to you verbally, I'm not going to "die on this hill", but I > do think the name chosen has some disadvantages that could have been > avoided with a very slight mental shift about require. I.e., > "requireNonNull*" requires its *return value* to be not-null, so if > its *argument* is null, then an adjustment is made (throw, select > alternate value, get-from-supplier). > > ? John From brian.burkhalter at oracle.com Fri Oct 30 19:29:08 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 30 Oct 2015 12:29:08 -0700 Subject: [9] RFR 8141082: Add java/nio/Buffer/Basic.java to ProblemList.txt for 64-bit Linux Message-ID: <885137EA-CAD8-43F4-B398-6BEF70491694@oracle.com> Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8141082 Patch: Summary: Put the test temporarily on the problem list for 64-bit Linux. --- a/test/ProblemList.txt Thu Oct 29 12:39:08 2015 -0700 +++ b/test/ProblemList.txt Fri Oct 30 12:27:49 2015 -0700 @@ -184,6 +184,9 @@ # jdk_nio +# 8141082, Linux 64-bit +java/nio/Buffer/Basic.java linux-amd64,linux-x64 + Thanks, Brian From joe.darcy at oracle.com Fri Oct 30 19:39:04 2015 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 30 Oct 2015 12:39:04 -0700 Subject: [9] RFR 8141082: Add java/nio/Buffer/Basic.java to ProblemList.txt for 64-bit Linux In-Reply-To: <885137EA-CAD8-43F4-B398-6BEF70491694@oracle.com> References: <885137EA-CAD8-43F4-B398-6BEF70491694@oracle.com> Message-ID: <5633C758.8020408@oracle.com> Hi Brian, Looks fine. (I don't see existing uses of the exact clauses "linux-amd64" and "linux-x64" in the problem list, but if you've verified those clauses work as expected I think is is good to go back.) Thank, -Joe On 10/30/2015 12:29 PM, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8141082 > Patch: > > Summary: Put the test temporarily on the problem list for 64-bit Linux. > > --- a/test/ProblemList.txt Thu Oct 29 12:39:08 2015 -0700 > +++ b/test/ProblemList.txt Fri Oct 30 12:27:49 2015 -0700 > @@ -184,6 +184,9 @@ > > # jdk_nio > > +# 8141082, Linux 64-bit > +java/nio/Buffer/Basic.java linux-amd64,linux-x64 > + > > Thanks, > > Brian From coleen.phillimore at oracle.com Fri Oct 30 19:44:30 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 30 Oct 2015 15:44:30 -0400 Subject: RFR (M) 8140802 - Clean up and refactor of class loading code for CDS In-Reply-To: <5633A24A.9070800@oracle.com> References: <5633A24A.9070800@oracle.com> Message-ID: <5633C89E.5050503@oracle.com> Hi Ioi, This is a manageable code change. http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/classListParser.hpp.html You forward declare Klass* but don't use it in this header file. Also can you add a comment to #endif to say what it's endifing. ie. // SHARE_VM_MEMORY_CLASSLISTPARSER_HPP http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/classLoaderExt.cpp.html 33 TempNewSymbol class_name_symbol = SymbolTable::new_permanent_symbol(parser->current_class_name(), THREAD); This doesn't make sense. If you want a permanent symbol, it doesn't need to get un-reference counted with the TempNewSymbol destructor. http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/systemDictionary.cpp.udiff.html + // Make sure we have an entry in the SystemDictionary on success This assert code is a copy of some code elsewhere. Can you make it a function that they boh can call? Can you also comment the raw #endif's to what they're endifing? Otherwise, this looks okay. Coleen On 10/30/15 1:00 PM, Ioi Lam wrote: > Please review the following fix: > > http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/ > > Bug: Clean up and refactor of class loading code for CDS > > https://bugs.openjdk.java.net/browse/JDK-8140802 > > Summary of fix: > > We need to clean up and refactor the class loading code in order > to support CDS in JDK9 > > [1] Remove code that has been made obsolete by the module changes > (such as supporting code used for meta-index file) > [2] Add new whitebox API to be used by CDS-related tests. > [3] Refactor the parsing of classlist files for future enhancements. > [4] Add new APIs in the class loading code to support Oracle CDS > enhancements. > > Tests: > > JPRT > RBT - with same set of tests as hs-rt nightly > > Thanks > - Ioi From david.lloyd at redhat.com Fri Oct 30 19:59:26 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 30 Oct 2015 14:59:26 -0500 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <B405DF00-00FD-419A-9D99-82F079497841@oracle.com> References: <B405DF00-00FD-419A-9D99-82F079497841@oracle.com> Message-ID: <5633CC1E.1030603@redhat.com> On 10/30/2015 02:04 PM, Mandy Chung wrote: > JEP 259: http://openjdk.java.net/jeps/259 > > Javadoc for the proposed StackWalker API: > http://cr.openjdk.java.net/~mchung/jdk9/jep259/api/java/lang/StackWalker.html > > A simple way to walk the stack: > > StackWalker walker = new StackWalker(StackWalker.Option.CLASS_REFERENCE); > walker.walk((s) -> s.filter(f -> interestingClasses.contains(f.getDeclaringClass())).findFirst()); > > The current usage of sun.reflect.Reflection.getCallerClass(int depth) can be replaced with this StackWalker API. > > Any feedback on the proposed API is appreciated. > > Mandy > > P.S. webrev of the current implementation: > http://cr.openjdk.java.net/~mchung/jdk9/jep259/webrev.00/ Clever/interesting way to prevent the stream from being used outside of the stack frame it is active in. I was trying to think of a way it could be subverted but I haven't come up with one yet. Since this is very likely to be a one-implementation API, is there a reason to have a separate WalkerOption interface and Option enum? Seems like you could just skip the interface. The batchSizeMapper should probably be something better than a Function<Integer,Integer>, no? All that boxing seems unnecessary... the next best candidate I can see though is IntToLongFunction. I wonder why we didn't do an IntToIntFunction in JSR 335. Or maybe the stream itself should be somehow made aware of the optimum batch size. What's the use case for changing the batch size as you iterate? Is the traversal *that* expensive? Otherwise - looks nifty! I like the StackWalker#getCallerClass() shortcut method. -- - DML From karen.kinnear at oracle.com Fri Oct 30 20:18:38 2015 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 30 Oct 2015 16:18:38 -0400 Subject: RFR (M) 8140802 - Clean up and refactor of class loading code for CDS In-Reply-To: <5633C89E.5050503@oracle.com> References: <5633A24A.9070800@oracle.com> <5633C89E.5050503@oracle.com> Message-ID: <AEAE2E8A-CD7F-4523-A221-D3640A9FBE98@oracle.com> Coleen, Question for you below please ... > On Oct 30, 2015, at 3:44 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote: > > > Hi Ioi, > This is a manageable code change. > > http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/classListParser.hpp.html > > You forward declare Klass* but don't use it in this header file. > Also can you add a comment to #endif to say what it's endifing. ie. // SHARE_VM_MEMORY_CLASSLISTPARSER_HPP > > http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/classLoaderExt.cpp.html > > 33 TempNewSymbol class_name_symbol = SymbolTable::new_permanent_symbol(parser->current_class_name(), THREAD); > > This doesn't make sense. If you want a permanent symbol, it doesn't need to get un-reference counted with the TempNewSymbol destructor. Thank you for chiming in on this one - I wanted your opinion here. (this code used to be in MetaspaceShared:: preload_and_dump and I think was wrong there as well). My understanding is that it is a TempNewSymbol that he wants, so he should call SymbolTable::new_symbol. The code creates a (temporary) symbol for the name, and then calls SystemDictionary::resolve_or_null, which if it succeeds will walk through the classFileParser which will create a permanent symbol for the class name, via the symbol_alloc_batch handling. That would be consistent with the TempNewSymbol call in SystemDictionary::resolve_or_null as well as in parse_stream - all places dealing with the class name before doing classfile parsing. Does that make sense? thanks, Karen > > http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/systemDictionary.cpp.udiff.html > > + // Make sure we have an entry in the SystemDictionary on success > > > This assert code is a copy of some code elsewhere. Can you make it a function that they boh can call? > Can you also comment the raw #endif's to what they're endifing? > > Otherwise, this looks okay. > > Coleen > > > On 10/30/15 1:00 PM, Ioi Lam wrote: >> Please review the following fix: >> >> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/ >> >> Bug: Clean up and refactor of class loading code for CDS >> >> https://bugs.openjdk.java.net/browse/JDK-8140802 >> >> Summary of fix: >> >> We need to clean up and refactor the class loading code in order >> to support CDS in JDK9 >> >> [1] Remove code that has been made obsolete by the module changes >> (such as supporting code used for meta-index file) >> [2] Add new whitebox API to be used by CDS-related tests. >> [3] Refactor the parsing of classlist files for future enhancements. >> [4] Add new APIs in the class loading code to support Oracle CDS enhancements. >> >> Tests: >> >> JPRT >> RBT - with same set of tests as hs-rt nightly >> >> Thanks >> - Ioi > From jiangli.zhou at oracle.com Fri Oct 30 20:23:53 2015 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 30 Oct 2015 13:23:53 -0700 Subject: RFR (M) 8140802 - Clean up and refactor of class loading code for CDS In-Reply-To: <5633A24A.9070800@oracle.com> References: <5633A24A.9070800@oracle.com> Message-ID: <2DAFD29D-4F30-441E-934F-610F6D0A2C2E@oracle.com> Hi Ioi, The change looks pretty clean. The new src/share/vm/classfile/systemDictionary_ext.hpp and src/share/vm/classfile/vmSymbols_ext.hpp do not have copyright header. Please add the copyright headers. Please also fix the copyright year for the modified files prior to pushing. In src/share/vm/classfile/sharedPathsMiscInfo.hpp, is the new ?#include ?classify/classLoader.hpp? necessary? I agree with the comments from Colleen and Karen regarding the usage of new_permanent_symbol() and TempNewSymbol in classLoaderExt.cpp. It doesn?t seem to be consistent. Thanks, Jiangli > On Oct 30, 2015, at 10:00 AM, Ioi Lam <ioi.lam at oracle.com> wrote: > > Please review the following fix: > > http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/ > > Bug: Clean up and refactor of class loading code for CDS > > https://bugs.openjdk.java.net/browse/JDK-8140802 > > Summary of fix: > > We need to clean up and refactor the class loading code in order > to support CDS in JDK9 > > [1] Remove code that has been made obsolete by the module changes > (such as supporting code used for meta-index file) > [2] Add new whitebox API to be used by CDS-related tests. > [3] Refactor the parsing of classlist files for future enhancements. > [4] Add new APIs in the class loading code to support Oracle CDS enhancements. > > Tests: > > JPRT > RBT - with same set of tests as hs-rt nightly > > Thanks > - Ioi From forax at univ-mlv.fr Fri Oct 30 20:26:50 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 30 Oct 2015 21:26:50 +0100 (CET) Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <5633CC1E.1030603@redhat.com> References: <B405DF00-00FD-419A-9D99-82F079497841@oracle.com> <5633CC1E.1030603@redhat.com> Message-ID: <990258669.2446021.1446236810570.JavaMail.zimbra@u-pem.fr> Hi Mandy, hi David, hi all, the API look gorgeous :) There are some missing wildcards in walk, <T> T walk(Function<? super Stream<StackWalker.StackFrame>, ? extends T> function, IntUnaryOperator batchSizeMapper) In StackWalker.Option, i think that CLASS_REFERENCE can be renamed to KEEP_CLASS_REFERENCE, maybe ? In StackWalker.StackTrace, i think that asStackTraceElement() should be called toStackTraceElement(), like Path.toFile, it's a convenient method to convert a StackFrame instance to the legacy class StackTraceElement. The documentation of getDeclaringClass() is not clear that it throws UOE if the walker is not configured with CLASS_REFERENCE. ----- Mail original ----- > De: "David M. Lloyd" <david.lloyd at redhat.com> > ?: core-libs-dev at openjdk.java.net > Envoy?: Vendredi 30 Octobre 2015 20:59:26 > Objet: Re: Proposed API for JEP 259: Stack-Walking API > > On 10/30/2015 02:04 PM, Mandy Chung wrote: > > JEP 259: http://openjdk.java.net/jeps/259 > > > > Javadoc for the proposed StackWalker API: > > http://cr.openjdk.java.net/~mchung/jdk9/jep259/api/java/lang/StackWalker.html > > > > A simple way to walk the stack: > > > > StackWalker walker = new > > StackWalker(StackWalker.Option.CLASS_REFERENCE); > > walker.walk((s) -> s.filter(f -> > > interestingClasses.contains(f.getDeclaringClass())).findFirst()); > > > > The current usage of sun.reflect.Reflection.getCallerClass(int depth) can > > be replaced with this StackWalker API. > > > > Any feedback on the proposed API is appreciated. > > > > Mandy > > > > P.S. webrev of the current implementation: > > http://cr.openjdk.java.net/~mchung/jdk9/jep259/webrev.00/ > > Clever/interesting way to prevent the stream from being used outside of > the stack frame it is active in. I was trying to think of a way it > could be subverted but I haven't come up with one yet. store the stream in an instance or a static variable ? > > Since this is very likely to be a one-implementation API, is there a > reason to have a separate WalkerOption interface and Option enum? Seems > like you could just skip the interface. > I agree with David, having another implementation is unlikely. > The batchSizeMapper should probably be something better than a > Function<Integer,Integer>, no? All that boxing seems unnecessary... the > next best candidate I can see though is IntToLongFunction. I wonder why > we didn't do an IntToIntFunction in JSR 335. Or maybe the stream itself > should be somehow made aware of the optimum batch size. What's the use > case for changing the batch size as you iterate? Is the traversal > *that* expensive? IntToIntFunction => IntUnaryOperator. > > Otherwise - looks nifty! I like the StackWalker#getCallerClass() > shortcut method. > > -- > - DML > regards, R?mi From coleen.phillimore at oracle.com Fri Oct 30 20:31:30 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 30 Oct 2015 16:31:30 -0400 Subject: RFR (M) 8140802 - Clean up and refactor of class loading code for CDS In-Reply-To: <AEAE2E8A-CD7F-4523-A221-D3640A9FBE98@oracle.com> References: <5633A24A.9070800@oracle.com> <5633C89E.5050503@oracle.com> <AEAE2E8A-CD7F-4523-A221-D3640A9FBE98@oracle.com> Message-ID: <5633D3A2.6050809@oracle.com> On 10/30/15 4:18 PM, Karen Kinnear wrote: > Coleen, > > Question for you below please ... >> On Oct 30, 2015, at 3:44 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote: >> >> >> Hi Ioi, >> This is a manageable code change. >> >> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/classListParser.hpp.html >> >> You forward declare Klass* but don't use it in this header file. >> Also can you add a comment to #endif to say what it's endifing. ie. // SHARE_VM_MEMORY_CLASSLISTPARSER_HPP >> >> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/classLoaderExt.cpp.html >> >> 33 TempNewSymbol class_name_symbol = SymbolTable::new_permanent_symbol(parser->current_class_name(), THREAD); >> >> This doesn't make sense. If you want a permanent symbol, it doesn't need to get un-reference counted with the TempNewSymbol destructor. > Thank you for chiming in on this one - I wanted your opinion here. (this code used to be in MetaspaceShared:: > preload_and_dump and I think was wrong there as well). > My understanding is that it is a TempNewSymbol that he wants, so he should call SymbolTable::new_symbol. > The code creates a (temporary) symbol for the name, and then calls SystemDictionary::resolve_or_null, which if it > succeeds will walk through the classFileParser which will create a permanent symbol for the class name, > via the symbol_alloc_batch handling. That would be consistent with the TempNewSymbol call in > SystemDictionary::resolve_or_null as well as in parse_stream - all places dealing with the class name > before doing classfile parsing. > > Does that make sense? Yes, this makes sense. The symbol shouldn't be permanent. Ioi can test this by putting a strange long name in the classlist file and make sure it doesn't make it out to the shared archive, since I think -Xshare:dump cleans out the SymbolTable before dumping. Coleen > > thanks, > Karen > >> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/systemDictionary.cpp.udiff.html >> >> + // Make sure we have an entry in the SystemDictionary on success >> >> >> This assert code is a copy of some code elsewhere. Can you make it a function that they boh can call? >> Can you also comment the raw #endif's to what they're endifing? >> >> Otherwise, this looks okay. >> >> Coleen >> >> >> On 10/30/15 1:00 PM, Ioi Lam wrote: >>> Please review the following fix: >>> >>> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/ >>> >>> Bug: Clean up and refactor of class loading code for CDS >>> >>> https://bugs.openjdk.java.net/browse/JDK-8140802 >>> >>> Summary of fix: >>> >>> We need to clean up and refactor the class loading code in order >>> to support CDS in JDK9 >>> >>> [1] Remove code that has been made obsolete by the module changes >>> (such as supporting code used for meta-index file) >>> [2] Add new whitebox API to be used by CDS-related tests. >>> [3] Refactor the parsing of classlist files for future enhancements. >>> [4] Add new APIs in the class loading code to support Oracle CDS enhancements. >>> >>> Tests: >>> >>> JPRT >>> RBT - with same set of tests as hs-rt nightly >>> >>> Thanks >>> - Ioi From mandy.chung at oracle.com Fri Oct 30 20:39:38 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 30 Oct 2015 13:39:38 -0700 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <5633CC1E.1030603@redhat.com> References: <B405DF00-00FD-419A-9D99-82F079497841@oracle.com> <5633CC1E.1030603@redhat.com> Message-ID: <3E3E56F1-6402-4CFF-84E1-9CEE9CC0D34C@oracle.com> > On Oct 30, 2015, at 12:59 PM, David M. Lloyd <david.lloyd at redhat.com> wrote: > > Clever/interesting way to prevent the stream from being used outside of the stack frame it is active in. I was trying to think of a way it could be subverted but I haven't come up with one yet. That?s John?s suggestion (John always has great ideas). > > Since this is very likely to be a one-implementation API, is there a reason to have a separate WalkerOption interface and Option enum? Seems like you could just skip the interface. Locals and operands is one experimental feature in mind that is not target for JDK 9. But it would be an interesting feature for e.g. Fibers to experiment. This will also allow JDK-specific capability to be implemented in the future. Another alternative is to have StackWalker subclass but making the @CS instance methods final (that may be a better way). I can?t think of any other options to support extension. Any suggestion is welcome. > > The batchSizeMapper should probably be something better than a Function<Integer,Integer>, no? This batchSizeMapper function is exactly the API ?m looking for feedback. I consider IntSupplier. IntToLongFunction is another option. Comment below. > All that boxing seems unnecessary... the next best candidate I can see though is IntToLongFunction. I wonder why we didn't do an IntToIntFunction in JSR 335. Or maybe the stream itself should be somehow made aware of the optimum batch size. What's the use case for changing the batch size as you iterate? > Is the traversal *that* expensive? > Altering the first batch size would be useful for Log4J and Groovy use cases that filter implementation classes and finds the caller. Altering subsequent batch size is more as a flexible option. One can simple have the function to return the same batch size. I do think IntSupplier is probably a better choice that won?t restrict to supply only the initial batch size. The last batch size parameter is solely for information. > Otherwise - looks nifty! I like the StackWalker#getCallerClass() shortcut method. Thanks Mandy From mandy.chung at oracle.com Fri Oct 30 20:51:01 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 30 Oct 2015 13:51:01 -0700 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <990258669.2446021.1446236810570.JavaMail.zimbra@u-pem.fr> References: <B405DF00-00FD-419A-9D99-82F079497841@oracle.com> <5633CC1E.1030603@redhat.com> <990258669.2446021.1446236810570.JavaMail.zimbra@u-pem.fr> Message-ID: <3A000034-744D-49EF-AD3C-C08603C23C65@oracle.com> > On Oct 30, 2015, at 1:26 PM, Remi Forax <forax at univ-mlv.fr> wrote: > > Hi Mandy, hi David, hi all, > the API look gorgeous :) > Thank you. > There are some missing wildcards in walk, > <T> T walk(Function<? super Stream<StackWalker.StackFrame>, ? extends T> function, IntUnaryOperator batchSizeMapper) > > In StackWalker.Option, > i think that CLASS_REFERENCE can be renamed to KEEP_CLASS_REFERENCE, maybe ? > That?s a good alternative. > In StackWalker.StackTrace, > i think that asStackTraceElement() should be called toStackTraceElement(), like Path.toFile, it's a convenient method to convert a StackFrame instance to the legacy class StackTraceElement. StackFrame has all the information StackTraceElement has. It doesn?t seem that this method is necessary. I?m tempted to remove this default method. Any thought? > The documentation of getDeclaringClass() is not clear that it throws UOE if the walker is not configured with CLASS_REFERENCE. > I?ll fix that. > ----- Mail original ----- >> >> >> >> Clever/interesting way to prevent the stream from being used outside of >> the stack frame it is active in. I was trying to think of a way it >> could be subverted but I haven't come up with one yet. > > store the stream in an instance or a static variable ? > I have a test for all these cases. >> >> Since this is very likely to be a one-implementation API, is there a >> reason to have a separate WalkerOption interface and Option enum? Seems >> like you could just skip the interface. >> > > I agree with David, having another implementation is unlikely. That?s for an experimental capability (see my other reply). > >> The batchSizeMapper should probably be something better than a >> Function<Integer,Integer>, no? All that boxing seems unnecessary... the >> next best candidate I can see though is IntToLongFunction. I wonder why >> we didn't do an IntToIntFunction in JSR 335. Or maybe the stream itself >> should be somehow made aware of the optimum batch size. What's the use >> case for changing the batch size as you iterate? Is the traversal >> *that* expensive? > > IntToIntFunction => IntUnaryOperator. > Thanks. Mandy From david.lloyd at redhat.com Fri Oct 30 21:02:46 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 30 Oct 2015 16:02:46 -0500 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <990258669.2446021.1446236810570.JavaMail.zimbra@u-pem.fr> References: <B405DF00-00FD-419A-9D99-82F079497841@oracle.com> <5633CC1E.1030603@redhat.com> <990258669.2446021.1446236810570.JavaMail.zimbra@u-pem.fr> Message-ID: <5633DAF6.7070708@redhat.com> On 10/30/2015 03:26 PM, Remi Forax wrote: >> The batchSizeMapper should probably be something better than a >> Function<Integer,Integer>, no? All that boxing seems unnecessary... the >> next best candidate I can see though is IntToLongFunction. I wonder why >> we didn't do an IntToIntFunction in JSR 335. Or maybe the stream itself >> should be somehow made aware of the optimum batch size. What's the use >> case for changing the batch size as you iterate? Is the traversal >> *that* expensive? > > IntToIntFunction => IntUnaryOperator. Ah that's the one! You know I think that this is more than once that I looked for, and didn't find, that interface. Some kind of mental blind spot I guess. :-) -- - DML From xueming.shen at oracle.com Fri Oct 30 21:30:23 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 30 Oct 2015 14:30:23 -0700 Subject: RFR: String Density/Compact String JEP 254 (update) In-Reply-To: <56129786.1090402@oracle.com> References: <56129786.1090402@oracle.com> Message-ID: <5633E16F.8090904@oracle.com> Hi, Thanks for the comments/suggestions. Here are the updated webrevs with minor changes here and there based on the feedback. http://cr.openjdk.java.net/~sherman/8054307/jdk/ http://cr.openjdk.java.net/~thartmann/compact_strings/webrev/hotspot/ [closed, Oracle internal only] http://javaweb.us.oracle.com/~tohartma/compact_strings/hotspot/ http://javaweb.us.oracle.com/~tohartma/compact_strings/hotspot_test_closed/ The code is ready for integration. The current plan is to integrate via the hotspot repo in coming week if it passes the PIT. Thanks -Sherman On 10/5/15 8:30 AM, Xueming Shen wrote: > (resent to hotspot-dev at openjdk.java.net) > > Hi, > > Please review the change for JEP 254/Compact String project. > > JPE 254: http://openjdk.java.net/jeps/254 > Issue: https://bugs.openjdk.java.net/browse/JDK-8054307 > Webrevs: http://cr.openjdk.java.net/~sherman/8054307/jdk/ > http://cr.openjdk.java.net/~thartmann/compact_strings/webrev/hotspot > > Description: > > String Density project is to change the internal representation of the > String class from a UTF-16 char array to a byte array plus an encoding > flag field. The new String class stores characters encoded either as > ISO-8859-1/Latin-1 (one byte per character), or as UTF-16 (two bytes > per character), based upon the contents of the string. The encoding > flag indicates which encoding is used. It offers reduced memory > footprint > while maintaining throughput performance. See JEP 254 for more > additional > information > > Implementation repo/try out: > http://hg.openjdk.java.net/jdk9/sandbox/ branch: JDK-8054307-branch > > $ hg clone http://hg.openjdk.java.net/jdk9/sandbox/ > $ cd sandbox > $ sh ./get_source.sh > $ sh ./common/bin/hgforest.sh up -r JDK-8054307-branch > $ make configure > $ make images > > Implementation Notes: > > - To change the internal representation of the String and the String > builder classes (AbstractStringBuilder, StringBuilder and > StringBuffer) > from a UTF-16 char array to a byte array plus an encoding flag field. > > The new representation stores the String characters in a single byte > format using the lower 8-bit of character's 16-bit UTF16 value, and > sets the encoding flag as LATIN1, if all characters of the String > object are Unicode Latin1 characters (with its UTF16 value < \u0100) > > It stores the String characters in 2-byte format with their UTF-16 > value > and sets the flag as UTF16, if any of the character inside the String > object is NOT Unicode latin1 character. > > - To change the method implementation of the String class and its > builders > to function on the new internal character storage, mainly to > delegate to > two implementation classes StringUTF16 and StringLatin1 > > - To update the StringCoding class to decoding/encoding the String > between > String.byte[]/coder(LATIN1/UTF16) <-> byte[](native encoding) instead > of the original String.char[] <-> byte[] (native encoding) > > - To update the hotSpot compiler (new and updated instrinsics), GC > (String > Deduplication mods) and Runtime to work with the new internal > "byte[] + > coder flag" representation. > > See Tobias's note for details of the hotspot changes: > http://cr.openjdk.java.net/~thartmann/compact_strings/hotspot-impl-note > > - To add a vm option "CompactStrings" (default is true) to provide a > switch-off mechanism to always store the String characters in UTF16 > encoding (always 2 bytes, but still in a byte[], instead of the > original char[]). > > > Supporting performance artifacts: > > - Report(s) on memory footprint impact > > http://cr.openjdk.java.net/~shade/density/string-density-report.pdf > > Latest SPECjbb2005 footprint reduction and throughput numbers for both > Intel (Linux) and SPARC, in which it shows the Compact String binaries > use less memory and have higher throughput. > > latest:http://cr.openjdk.java.net/~sherman/8054307/specjbb2005 > old: > http://cr.openjdk.java.net/~huntch/string-density/reports/String-Density-SPARC-jbb2005-Report.pdf > > - Throughput performance impact via String API micro-benchmarks > > http://cr.openjdk.java.net/~thartmann/compact_strings/microbenchmarks/Haswell_090915.pdf > > http://cr.openjdk.java.net/~thartmann/compact_strings/microbenchmarks/IvyBridge_090915.pdf > > http://cr.openjdk.java.net/~thartmann/compact_strings/microbenchmarks/Sparc_090915.pdf > > http://cr.openjdk.java.net/~sherman/8054307/string-coding.txt > > Thanks, > Sherman From mandy.chung at oracle.com Fri Oct 30 22:35:02 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 30 Oct 2015 15:35:02 -0700 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <990258669.2446021.1446236810570.JavaMail.zimbra@u-pem.fr> References: <B405DF00-00FD-419A-9D99-82F079497841@oracle.com> <5633CC1E.1030603@redhat.com> <990258669.2446021.1446236810570.JavaMail.zimbra@u-pem.fr> Message-ID: <B9A3F0C0-E5FB-4EB2-9907-B6BF21D23605@oracle.com> > On Oct 30, 2015, at 1:26 PM, Remi Forax <forax at univ-mlv.fr> wrote: > > In StackWalker.Option, > i think that CLASS_REFERENCE can be renamed to KEEP_CLASS_REFERENCE, maybe ? What about RETAIN_CLASS_REFERENCE? I have updated the javadoc in place: http://cr.openjdk.java.net/~mchung/jdk9/jep259/api/java/lang/StackWalker.html Changes include: - CLASS_REFERENCE renamed to RETAIN_CLASS_REFERENCE - remove StackWalker.WalkerOption interface - the batchSizeMapper argument is of IntUnaryOperator type. Thanks for the feedback, Remi and David. Mandy From david.lloyd at redhat.com Fri Oct 30 22:38:03 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 30 Oct 2015 17:38:03 -0500 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <3E3E56F1-6402-4CFF-84E1-9CEE9CC0D34C@oracle.com> References: <B405DF00-00FD-419A-9D99-82F079497841@oracle.com> <5633CC1E.1030603@redhat.com> <3E3E56F1-6402-4CFF-84E1-9CEE9CC0D34C@oracle.com> Message-ID: <5633F14B.4080503@redhat.com> On 10/30/2015 03:39 PM, Mandy Chung wrote: >> On Oct 30, 2015, at 12:59 PM, David M. Lloyd <david.lloyd at redhat.com> wrote: >> Since this is very likely to be a one-implementation API, is there a reason to have a separate WalkerOption interface and Option enum? Seems like you could just skip the interface. > > Locals and operands is one experimental feature in mind that is not target for JDK 9. But it would be an interesting feature for e.g. Fibers to experiment. This will also allow JDK-specific capability to be implemented in the future. Ah, that makes sense, I forgot about cases where the JDK itself might have non-spec extensions. It should probably be specified in the docs that unrecognized options are either ignored or rejected though. >> All that boxing seems unnecessary... the next best candidate I can see though is IntToLongFunction. I wonder why we didn't do an IntToIntFunction in JSR 335. Or maybe the stream itself should be somehow made aware of the optimum batch size. What's the use case for changing the batch size as you iterate? >> Is the traversal *that* expensive? > > Altering the first batch size would be useful for Log4J and Groovy use cases that filter implementation classes and finds the caller. Altering subsequent batch size is more as a flexible option. One can simple have the function to return the same batch size. Maybe an overload of walk() which accepts an int (initial batch size) in addition to the function for the simple case? > I do think IntSupplier is probably a better choice that won?t restrict to supply only the initial batch size. The last batch size parameter is solely for information. UnaryOperator is a good option too (that's what I was looking for before), or maybe even ToIntFunction<X> where X is something that might inform the next batch size based on the work that has already been done - maybe even a Stream<StackFrame> that consists only of the current batch? Or another idea: <T> T walk(BiFunction<Stream<StackWalker.StackFrame>, IntConsumer, T> function); where the IntConsumer can be called at any time to update a minimum number of remaining frames needed, which in turn can (with the knowledge of how many elements have been consumed by the stream) inform the next batch size. -- - DML From roger.riggs at oracle.com Fri Oct 30 23:41:10 2015 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 30 Oct 2015 17:41:10 -0600 Subject: RFR 9: 8138566: (Process) java.lang.Process.allChildren specification clarification Message-ID: <56340016.80701@oracle.com> Please review and comment on 3 clarifications to ProcessHandle and Process. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-process-clarify-8138566/ 8138566: (Process) java.lang.Process.allChildren specification clarification - Rename the allChildren() method to descendants() - it is more descriptive and less easily confused with the children method. - The risk of renaming is method is minimal since it has been only available for a short time. 8140213: Process/ProcessHandle.onExit() spec need to be improved - The timing of the completion of the CompletableFuture was too tightly specified. With the isAlive method, it is possible to observe that the process has terminated before the CF is completed. The CF is completed sometime after the process terminates. 8140250: (process) Process.info description is inaccurate - The specification of the Process/ProcessHandle.info() method did not match the implementation. On an OS (Windows) some information is available about the process after it is no longer alive. Thanks, Roger From mandy.chung at oracle.com Sat Oct 31 04:24:10 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 30 Oct 2015 21:24:10 -0700 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <5633F14B.4080503@redhat.com> References: <B405DF00-00FD-419A-9D99-82F079497841@oracle.com> <5633CC1E.1030603@redhat.com> <3E3E56F1-6402-4CFF-84E1-9CEE9CC0D34C@oracle.com> <5633F14B.4080503@redhat.com> Message-ID: <5779E088-D59B-427F-83E9-3EB160386CD7@oracle.com> > On Oct 30, 2015, at 3:38 PM, David M. Lloyd <david.lloyd at redhat.com> wrote: > > On 10/30/2015 03:39 PM, Mandy Chung wrote: >>> On Oct 30, 2015, at 12:59 PM, David M. Lloyd <david.lloyd at redhat.com> wrote: >>> Since this is very likely to be a one-implementation API, is there a reason to have a separate WalkerOption interface and Option enum? Seems like you could just skip the interface. >> >> Locals and operands is one experimental feature in mind that is not target for JDK 9. But it would be an interesting feature for e.g. Fibers to experiment. This will also allow JDK-specific capability to be implemented in the future. > > Ah, that makes sense, I forgot about cases where the JDK itself might have non-spec extensions. It should probably be specified in the docs that unrecognized options are either ignored or rejected though. I decide to take out WalkerOption interface, as I didn?t like that as much for supporting one single known extension at the moment. I found another way doing it (by a factory method to return a StackWalker instance with extended capability). > >>> All that boxing seems unnecessary... the next best candidate I can see though is IntToLongFunction. I wonder why we didn't do an IntToIntFunction in JSR 335. Or maybe the stream itself should be somehow made aware of the optimum batch size. What's the use case for changing the batch size as you iterate? >>> Is the traversal *that* expensive? >> >> Altering the first batch size would be useful for Log4J and Groovy use cases that filter implementation classes and finds the caller. Altering subsequent batch size is more as a flexible option. One can simple have the function to return the same batch size. > > Maybe an overload of walk() which accepts an int (initial batch size) in addition to the function for the simple case? > Maybe. It?d be good to get further feedback and use cases to decide adding another variant. >> I do think IntSupplier is probably a better choice that won?t restrict to supply only the initial batch size. The last batch size parameter is solely for information. > > UnaryOperator is a good option too Yup. I have updated the API to use that. > (that's what I was looking for before), or maybe even ToIntFunction<X> where X is something that might inform the next batch size based on the work that has already been done - maybe even a Stream<StackFrame> that consists only of the current batch? > > Or another idea: > <T> T walk(BiFunction<Stream<StackWalker.StackFrame>, IntConsumer, T> function); > > where the IntConsumer can be called at any time to update a minimum number of remaining frames needed, which in turn can (with the knowledge of how many elements have been consumed by the stream) inform the next batch size. The stack walker won?t get the next batch until all frames of the current batch are consumed. I think the current walk methods would cover what this one does. There are other ideas to add other variants of the walk methods and short-cut for performance. I keep these ideas in mind and consider them once more feedback is collected. thanks Mandy From john.r.rose at oracle.com Sat Oct 31 07:01:03 2015 From: john.r.rose at oracle.com (John Rose) Date: Sat, 31 Oct 2015 00:01:03 -0700 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <5633BFF5.9090609@oracle.com> References: <5613D01F.3000107@Oracle.com> <5613FEE6.2010907@oracle.com> <1391860289.1215500.1444171338590.JavaMail.zimbra@u-pem.fr> <56159B9A.4040404@Oracle.com> <1319440457.2004194.1444294182369.JavaMail.zimbra@u-pem.fr> <56168166.5030903@Oracle.com> <1200530124.2619128.1444329461357.JavaMail.zimbra@u-pem.fr> <5616BF66.3010607@Oracle.com> <278013257.2631892.1444332861717.JavaMail.zimbra@u-pem.fr> <33D01469-37DE-4502-8112-0E4865733AFF@oracle.com> <5616E345.9090609@Oracle.com> <A4D5091B-C41A-4EA4-B811-F4C3658B8AB0@oracle.com> <CACzrW9BPnBNKaXzLfZeJdD+5n_mZV-OM3TH+yD=suGB2mYR2CQ@mail.gmail.com> <91F25DF8-BC0F-44EB-A57D-A49FF7876DB9@oracle.com> <5617B184.7060803@oracle.com> <5617E141.7000503@Oracle.com> <50EAA3DD-46F5-4BF2-B010-333CEE7187A9@oracle.com> <5633BFF5.9090609@oracle.com> Message-ID: <5FDA255B-E3D7-4485-8C7C-6D98071D0A1F@oracle.com> On Oct 30, 2015, at 12:07 PM, Roger Riggs <roger.riggs at oracle.com> wrote: > > The longer names disambiguate adequately but add to the bulk of the code. > I see maturing systems end up being weighed down by the seemingly necessary > qualification. I agree with your statement of the problem, but (personally) am less repulsed by long names. The name length is unusual (up to "requireNonNullElseGet", if that's the new API spelling). It would be inconvenient to write manually but (IMO) that isn't a deal-killer. Coders cope with long names (check class name lengths in java.lang). It's a matter of taste, and (particularly) of how much the coder relies on name-completion commands. Given the pre-existing methods in the "nonNull" family and the "requireNonNull" family, it is tricky to fit in the new API points with either prefix. The "nonNull" family is short and sweet, but was adopted (one might say "stolen") for use as a predicate (sans "is"-prefix). The "requireNonNull" family was long-winded, even before we thought about adding "ElseGet". (How did we settle on "require", anyway?) > So in face of the tradeoffs, what were you proposing again? Despite the length of the names involved, I'm going to clutch at my IDE and my Control-Space key, maintaining my preference for the consistency of requireNonNull* over the brevity (but inconsistency) of notNull*. As I said, I noticed the problem with "notNullElse" while using an IDE. Non-IDE users would look at my preference and say, "please, not so many keystrokes!" In the IDE, I would prefer to pretend "notNull" never happened, and type "require" and Control-Space, and then select one of the old or new API points to refine my null-checking logic. ? John P.S. Going for a third way and starting a new family of methods ("notNull*", "stopNull", etc.) would make me sad too, since we already have null-stopping API points. I'd secretly welcome Objects.or(a, b, c), etc. (coupled with "require*" to throw NPEs), but only because "OR" is a sort of logical in-joke for ex-Lispers. From forax at univ-mlv.fr Sat Oct 31 11:17:18 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 31 Oct 2015 12:17:18 +0100 (CET) Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <5FDA255B-E3D7-4485-8C7C-6D98071D0A1F@oracle.com> References: <5613D01F.3000107@Oracle.com> <CACzrW9BPnBNKaXzLfZeJdD+5n_mZV-OM3TH+yD=suGB2mYR2CQ@mail.gmail.com> <91F25DF8-BC0F-44EB-A57D-A49FF7876DB9@oracle.com> <5617B184.7060803@oracle.com> <5617E141.7000503@Oracle.com> <50EAA3DD-46F5-4BF2-B010-333CEE7187A9@oracle.com> <5633BFF5.9090609@oracle.com> <5FDA255B-E3D7-4485-8C7C-6D98071D0A1F@oracle.com> Message-ID: <1317738244.2516893.1446290238651.JavaMail.zimbra@u-pem.fr> Hi John, I think there is a good reason to not reuse/enhance the requireNonNull prefix, requireNonNull here is used to check a precondition or an invariant (a contract), hence a name that starts with 'require' like in Eiffel. (BTW re-reading this thread, Brian already said that) requireNonNullElseGet is not something that checks a contract and as you said, nonNull is not a good prefix too, so we should starts a new family. what about: <T> T coalesceNull(T, T) <T> T coalesceNullGet(T, Supplier<? extends T>) cheers, R?mi PS: COALESCE is already use as an operator in SQL with the same semantics. ----- Mail original ----- > De: "John Rose" <john.r.rose at oracle.com> > ?: "Roger Riggs" <roger.riggs at oracle.com> > Cc: core-libs-dev at openjdk.java.net > Envoy?: Samedi 31 Octobre 2015 08:01:03 > Objet: Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null > > On Oct 30, 2015, at 12:07 PM, Roger Riggs <roger.riggs at oracle.com> wrote: > > > > The longer names disambiguate adequately but add to the bulk of the code. > > I see maturing systems end up being weighed down by the seemingly necessary > > qualification. > > I agree with your statement of the problem, but (personally) am less repulsed > by long names. > > The name length is unusual (up to "requireNonNullElseGet", if that's the new > API spelling). It would be inconvenient to write manually but (IMO) that > isn't a deal-killer. Coders cope with long names (check class name lengths > in java.lang). It's a matter of taste, and (particularly) of how much the > coder relies on name-completion commands. > > Given the pre-existing methods in the "nonNull" family and the > "requireNonNull" family, it is tricky to fit in the new API points with > either prefix. The "nonNull" family is short and sweet, but was adopted > (one might say "stolen") for use as a predicate (sans "is"-prefix). The > "requireNonNull" family was long-winded, even before we thought about adding > "ElseGet". (How did we settle on "require", anyway?) > > > So in face of the tradeoffs, what were you proposing again? > > > Despite the length of the names involved, I'm going to clutch at my IDE and > my Control-Space key, maintaining my preference for the consistency of > requireNonNull* over the brevity (but inconsistency) of notNull*. As I > said, I noticed the problem with "notNullElse" while using an IDE. Non-IDE > users would look at my preference and say, "please, not so many keystrokes!" > In the IDE, I would prefer to pretend "notNull" never happened, and type > "require" and Control-Space, and then select one of the old or new API > points to refine my null-checking logic. > > ? John > > P.S. Going for a third way and starting a new family of methods ("notNull*", > "stopNull", etc.) would make me sad too, since we already have null-stopping > API points. I'd secretly welcome Objects.or(a, b, c), etc. (coupled with > "require*" to throw NPEs), but only because "OR" is a sort of logical > in-joke for ex-Lispers. From forax at univ-mlv.fr Sat Oct 31 18:06:11 2015 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 31 Oct 2015 19:06:11 +0100 (CET) Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <B9A3F0C0-E5FB-4EB2-9907-B6BF21D23605@oracle.com> References: <B405DF00-00FD-419A-9D99-82F079497841@oracle.com> <5633CC1E.1030603@redhat.com> <990258669.2446021.1446236810570.JavaMail.zimbra@u-pem.fr> <B9A3F0C0-E5FB-4EB2-9907-B6BF21D23605@oracle.com> Message-ID: <1440520184.2546899.1446314771503.JavaMail.zimbra@u-pem.fr> Hi Mandy, ----- Mail original ----- > De: "Mandy Chung" <mandy.chung at oracle.com> > ?: "Remi Forax" <forax at univ-mlv.fr>, "David M. Lloyd" <david.lloyd at redhat.com> > Cc: core-libs-dev at openjdk.java.net > Envoy?: Vendredi 30 Octobre 2015 23:35:02 > Objet: Re: Proposed API for JEP 259: Stack-Walking API > > > > On Oct 30, 2015, at 1:26 PM, Remi Forax <forax at univ-mlv.fr> wrote: > > > > In StackWalker.Option, > > i think that CLASS_REFERENCE can be renamed to KEEP_CLASS_REFERENCE, maybe > > ? > > What about RETAIN_CLASS_REFERENCE? yes, it's a better name. > > I have updated the javadoc in place: > http://cr.openjdk.java.net/~mchung/jdk9/jep259/api/java/lang/StackWalker.html > > Changes include: > - CLASS_REFERENCE renamed to RETAIN_CLASS_REFERENCE > - remove StackWalker.WalkerOption interface > - the batchSizeMapper argument is of IntUnaryOperator type. > > Thanks for the feedback, Remi and David. > Mandy R?mi From forax at univ-mlv.fr Sat Oct 31 18:11:51 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 31 Oct 2015 19:11:51 +0100 (CET) Subject: Optional.or() doesn't use a wildcard in its signature In-Reply-To: <1770652221.2547024.1446314919390.JavaMail.zimbra@u-pem.fr> Message-ID: <1960076570.2547169.1446315111675.JavaMail.zimbra@u-pem.fr> Hi all, hi Paul, I've just seen that Optional.or is declared as public Optional<T> or(Supplier<Optional<T>> supplier) { instead of public Optional<T> or(Supplier<? extends Optional<T>> supplier) { regards, R?mi From spliterator at gmail.com Sat Oct 31 18:21:22 2015 From: spliterator at gmail.com (Stefan Zobel) Date: Sat, 31 Oct 2015 19:21:22 +0100 Subject: Optional.or() doesn't use a wildcard in its signature In-Reply-To: <1960076570.2547169.1446315111675.JavaMail.zimbra@u-pem.fr> References: <1770652221.2547024.1446314919390.JavaMail.zimbra@u-pem.fr> <1960076570.2547169.1446315111675.JavaMail.zimbra@u-pem.fr> Message-ID: <CAPkkuScRO1=jBgzNbU+nUs610AkYK+_nDb8h=gbm60Q3DpyYuw@mail.gmail.com> 2015-10-31 19:11 GMT+01:00 Remi Forax <forax at univ-mlv.fr>: > Hi all, hi Paul, > > I've just seen that Optional.or is declared as > public Optional<T> or(Supplier<Optional<T>> supplier) { > instead of > public Optional<T> or(Supplier<? extends Optional<T>> supplier) { > > regards, > R?mi > I don't get it. Optional is final anyway. Can you explain? Thanks, Stefan From forax at univ-mlv.fr Sat Oct 31 18:29:40 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 31 Oct 2015 19:29:40 +0100 (CET) Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <1440520184.2546899.1446314771503.JavaMail.zimbra@u-pem.fr> References: <B405DF00-00FD-419A-9D99-82F079497841@oracle.com> <5633CC1E.1030603@redhat.com> <990258669.2446021.1446236810570.JavaMail.zimbra@u-pem.fr> <B9A3F0C0-E5FB-4EB2-9907-B6BF21D23605@oracle.com> <1440520184.2546899.1446314771503.JavaMail.zimbra@u-pem.fr> Message-ID: <1856609155.2548586.1446316180239.JavaMail.zimbra@u-pem.fr> Hi Mandy, I've crawled the code and the documentation again. In the doc and in the code, a lambda with one parameter doesn't require parenthesis around the parameter, (s) -> s.doSomething() should be s -> s.doSomething(). In the doc of StackWalker, in the first example, the local variable 'frame' should be named 'callerClass' In the doc of getCallerClass(), the first example do a skip(2) which i believe is not necessary anymore, also instead of Optional.orElse, orElseGet is better because it avoids to evaluate Thread.currentThread().getClass() if not necessary. So the example should be: walk(s -> s.map(StackFrame::getDeclaringClass) .findFirst()).orElseGet(() -> Thread.currentThread().getClass()); In the second example, the field walker should be declared 'final'. And as i said earlier, the signature of walk() is: <T> T walk(Function<? super Stream<StackWalker.StackFrame>, ? extends T> function, IntUnaryOperator batchSizeMapper) cheers, R?mi ----- Mail original ----- > De: forax at univ-mlv.fr > ?: "Mandy Chung" <mandy.chung at oracle.com> > Cc: core-libs-dev at openjdk.java.net > Envoy?: Samedi 31 Octobre 2015 19:06:11 > Objet: Re: Proposed API for JEP 259: Stack-Walking API > > Hi Mandy, > > ----- Mail original ----- > > De: "Mandy Chung" <mandy.chung at oracle.com> > > ?: "Remi Forax" <forax at univ-mlv.fr>, "David M. Lloyd" > > <david.lloyd at redhat.com> > > Cc: core-libs-dev at openjdk.java.net > > Envoy?: Vendredi 30 Octobre 2015 23:35:02 > > Objet: Re: Proposed API for JEP 259: Stack-Walking API > > > > > > > On Oct 30, 2015, at 1:26 PM, Remi Forax <forax at univ-mlv.fr> wrote: > > > > > > In StackWalker.Option, > > > i think that CLASS_REFERENCE can be renamed to KEEP_CLASS_REFERENCE, > > > maybe > > > ? > > > > What about RETAIN_CLASS_REFERENCE? > > yes, it's a better name. > > > > > I have updated the javadoc in place: > > http://cr.openjdk.java.net/~mchung/jdk9/jep259/api/java/lang/StackWalker.html > > > > Changes include: > > - CLASS_REFERENCE renamed to RETAIN_CLASS_REFERENCE > > - remove StackWalker.WalkerOption interface > > - the batchSizeMapper argument is of IntUnaryOperator type. > > > > Thanks for the feedback, Remi and David. > > Mandy > > R?mi > From misterm at gmail.com Sat Oct 31 18:48:34 2015 From: misterm at gmail.com (Michael Nascimento) Date: Sat, 31 Oct 2015 11:48:34 -0700 Subject: Optional.or() doesn't use a wildcard in its signature In-Reply-To: <CAPkkuScRO1=jBgzNbU+nUs610AkYK+_nDb8h=gbm60Q3DpyYuw@mail.gmail.com> References: <1770652221.2547024.1446314919390.JavaMail.zimbra@u-pem.fr> <1960076570.2547169.1446315111675.JavaMail.zimbra@u-pem.fr> <CAPkkuScRO1=jBgzNbU+nUs610AkYK+_nDb8h=gbm60Q3DpyYuw@mail.gmail.com> Message-ID: <CAAWA2oV9ZqE=RZodnyzqEk2077d=TebzK1ByLRq4GbP+GE7dcg@mail.gmail.com> If this instance is an Optional<CharSequence> , passing an Optional<StringBuilder> will fail to compile. Regards, Michael On 31 Oct 2015 11:21, "Stefan Zobel" <spliterator at gmail.com> wrote: > 2015-10-31 19:11 GMT+01:00 Remi Forax <forax at univ-mlv.fr>: > > > Hi all, hi Paul, > > > > I've just seen that Optional.or is declared as > > public Optional<T> or(Supplier<Optional<T>> supplier) { > > instead of > > public Optional<T> or(Supplier<? extends Optional<T>> supplier) { > > > > regards, > > R?mi > > > > > I don't get it. Optional is final anyway. Can you explain? > > Thanks, > Stefan > From forax at univ-mlv.fr Sat Oct 31 18:50:43 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 31 Oct 2015 19:50:43 +0100 (CET) Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <3E3E56F1-6402-4CFF-84E1-9CEE9CC0D34C@oracle.com> References: <B405DF00-00FD-419A-9D99-82F079497841@oracle.com> <5633CC1E.1030603@redhat.com> <3E3E56F1-6402-4CFF-84E1-9CEE9CC0D34C@oracle.com> Message-ID: <675709662.2550110.1446317443208.JavaMail.zimbra@u-pem.fr> Hi Mandy, hi all, ----- Mail original ----- > De: "Mandy Chung" <mandy.chung at oracle.com> > ?: "David M. Lloyd" <david.lloyd at redhat.com> > Cc: core-libs-dev at openjdk.java.net > Envoy?: Vendredi 30 Octobre 2015 21:39:38 > Objet: Re: Proposed API for JEP 259: Stack-Walking API > > > > On Oct 30, 2015, at 12:59 PM, David M. Lloyd <david.lloyd at redhat.com> > > wrote: > > > > Clever/interesting way to prevent the stream from being used outside of the > > stack frame it is active in. I was trying to think of a way it could be > > subverted but I haven't come up with one yet. > > That?s John?s suggestion (John always has great ideas). > > > > > Since this is very likely to be a one-implementation API, is there a reason > > to have a separate WalkerOption interface and Option enum? Seems like you > > could just skip the interface. > > Locals and operands is one experimental feature in mind that is not target > for JDK 9. But it would be an interesting feature for e.g. Fibers to > experiment. This will also allow JDK-specific capability to be implemented > in the future. I think most of the runtime language developers, myself included will kill to have this feature included into the JDK. There are several features of dynamic languages that are currently hard to implement like type specialization, stack reification, as you said fibers, and more generally de-optimization that will be far easier to implement with that capability (currently only Nashorn can afford to implement some of these optimizations). [...] > > Thanks > Mandy > > R?mi From forax at univ-mlv.fr Sat Oct 31 18:57:41 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 31 Oct 2015 19:57:41 +0100 (CET) Subject: Optional.or() doesn't use a wildcard in its signature In-Reply-To: <CAPkkuScRO1=jBgzNbU+nUs610AkYK+_nDb8h=gbm60Q3DpyYuw@mail.gmail.com> References: <1770652221.2547024.1446314919390.JavaMail.zimbra@u-pem.fr> <1960076570.2547169.1446315111675.JavaMail.zimbra@u-pem.fr> <CAPkkuScRO1=jBgzNbU+nUs610AkYK+_nDb8h=gbm60Q3DpyYuw@mail.gmail.com> Message-ID: <1583523049.2550277.1446317861070.JavaMail.zimbra@u-pem.fr> Hum, it's quite embarrassing, you're right :) In fact, it's more than that because i now remember that Paul already answer that to me :( Thanks, Stefan. (I like your email address BTW) ----- Mail original ----- > De: "Stefan Zobel" <spliterator at gmail.com> > ?: "core-libs-dev at openjdk.java.net Libs" <core-libs-dev at openjdk.java.net> > Envoy?: Samedi 31 Octobre 2015 19:21:22 > Objet: Re: Optional.or() doesn't use a wildcard in its signature > > 2015-10-31 19:11 GMT+01:00 Remi Forax <forax at univ-mlv.fr>: > > > Hi all, hi Paul, > > > > I've just seen that Optional.or is declared as > > public Optional<T> or(Supplier<Optional<T>> supplier) { > > instead of > > public Optional<T> or(Supplier<? extends Optional<T>> supplier) { > > > > regards, > > R?mi > > > > > I don't get it. Optional is final anyway. Can you explain? > > Thanks, > Stefan > From vitalyd at gmail.com Sat Oct 31 18:59:00 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Sat, 31 Oct 2015 14:59:00 -0400 Subject: Optional.or() doesn't use a wildcard in its signature In-Reply-To: <CAAWA2oV9ZqE=RZodnyzqEk2077d=TebzK1ByLRq4GbP+GE7dcg@mail.gmail.com> References: <1770652221.2547024.1446314919390.JavaMail.zimbra@u-pem.fr> <1960076570.2547169.1446315111675.JavaMail.zimbra@u-pem.fr> <CAPkkuScRO1=jBgzNbU+nUs610AkYK+_nDb8h=gbm60Q3DpyYuw@mail.gmail.com> <CAAWA2oV9ZqE=RZodnyzqEk2077d=TebzK1ByLRq4GbP+GE7dcg@mail.gmail.com> Message-ID: <CAHjP37EG_b8fF7wdiysS8QHxMeAzCrH6mULkLVeoQWVjLetPVg@mail.gmail.com> This would require Supplier<Optional<? extends T>>, not Supplier<? extends Optional<T>>. sent from my phone On Oct 31, 2015 2:49 PM, "Michael Nascimento" <misterm at gmail.com> wrote: > If this instance is an Optional<CharSequence> , passing an > Optional<StringBuilder> will fail to compile. > > Regards, > Michael > On 31 Oct 2015 11:21, "Stefan Zobel" <spliterator at gmail.com> wrote: > > > 2015-10-31 19:11 GMT+01:00 Remi Forax <forax at univ-mlv.fr>: > > > > > Hi all, hi Paul, > > > > > > I've just seen that Optional.or is declared as > > > public Optional<T> or(Supplier<Optional<T>> supplier) { > > > instead of > > > public Optional<T> or(Supplier<? extends Optional<T>> supplier) { > > > > > > regards, > > > R?mi > > > > > > > > > I don't get it. Optional is final anyway. Can you explain? > > > > Thanks, > > Stefan > > > From peter.levart at gmail.com Sat Oct 31 19:23:14 2015 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 31 Oct 2015 20:23:14 +0100 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <1856609155.2548586.1446316180239.JavaMail.zimbra@u-pem.fr> References: <B405DF00-00FD-419A-9D99-82F079497841@oracle.com> <5633CC1E.1030603@redhat.com> <990258669.2446021.1446236810570.JavaMail.zimbra@u-pem.fr> <B9A3F0C0-E5FB-4EB2-9907-B6BF21D23605@oracle.com> <1440520184.2546899.1446314771503.JavaMail.zimbra@u-pem.fr> <1856609155.2548586.1446316180239.JavaMail.zimbra@u-pem.fr> Message-ID: <56351522.5010400@gmail.com> On 10/31/2015 07:29 PM, Remi Forax wrote: > also instead of Optional.orElse, orElseGet is better because it avoids to evaluate > Thread.currentThread().getClass() if not necessary. > > So the example should be: > walk(s -> s.map(StackFrame::getDeclaringClass) > .findFirst()).orElseGet(() -> Thread.currentThread().getClass()); It might be hard to believe, but the evaluation of constant lambda expression is approx. equally expensive as the expression it encapsulates in this example, so it really is an overkill here: Benchmark Mode Cnt Score Error Units LambdaVsCurrentThreadBench.getCurrentThreadClass avgt 10 2.202 ? 0.058 ns/op LambdaVsCurrentThreadBench.getCurrentThreadClassSupplier avgt 10 2.196 ? 0.159 ns/op @BenchmarkMode(Mode.AverageTime) @Fork(1) @Warmup(iterations = 5) @Measurement(iterations = 10) @OutputTimeUnit(TimeUnit.NANOSECONDS) public class LambdaVsCurrentThreadBench { @Benchmark public Class<?> getCurrentThreadClass() { return Thread.currentThread().getClass(); } @Benchmark public Supplier<Class<?>> getCurrentThreadClassSupplier() { return () -> Thread.currentThread().getClass(); } } Regards, Peter From forax at univ-mlv.fr Sat Oct 31 19:37:09 2015 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 31 Oct 2015 20:37:09 +0100 (CET) Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <56351522.5010400@gmail.com> References: <B405DF00-00FD-419A-9D99-82F079497841@oracle.com> <5633CC1E.1030603@redhat.com> <990258669.2446021.1446236810570.JavaMail.zimbra@u-pem.fr> <B9A3F0C0-E5FB-4EB2-9907-B6BF21D23605@oracle.com> <1440520184.2546899.1446314771503.JavaMail.zimbra@u-pem.fr> <1856609155.2548586.1446316180239.JavaMail.zimbra@u-pem.fr> <56351522.5010400@gmail.com> Message-ID: <572259565.2552990.1446320229415.JavaMail.zimbra@u-pem.fr> You're right, the JVM never stops to amaze me ! It's not that hard to believe, Thread.currentThread and Object.getClass() are both intrinsics and the current thread pointer is stored at the bottom (top) of the stack and getClass is just an indirection. thanks, R?mi ----- Mail original ----- > De: "Peter Levart" <peter.levart at gmail.com> > ?: "Remi Forax" <forax at univ-mlv.fr>, "Mandy Chung" <mandy.chung at oracle.com> > Cc: core-libs-dev at openjdk.java.net > Envoy?: Samedi 31 Octobre 2015 20:23:14 > Objet: Re: Proposed API for JEP 259: Stack-Walking API > On 10/31/2015 07:29 PM, Remi Forax wrote: > > also instead of Optional.orElse, orElseGet is better because it avoids to > > evaluate > > > Thread.currentThread().getClass() if not necessary. > > > So the example should be: > > > walk(s -> s.map(StackFrame::getDeclaringClass) > > > .findFirst()).orElseGet(() -> Thread.currentThread().getClass()); > > It might be hard to believe, but the evaluation of constant lambda expression > is approx. equally expensive as the expression it encapsulates in this > example, so it really is an overkill here: > Benchmark Mode Cnt Score Error Units > LambdaVsCurrentThreadBench.getCurrentThreadClass avgt 10 2.202 ? 0.058 ns/op > LambdaVsCurrentThreadBench.getCurrentThreadClassSupplier avgt 10 2.196 ? > 0.159 ns/op > @BenchmarkMode(Mode.AverageTime) > @Fork(1) > @Warmup(iterations = 5) > @Measurement(iterations = 10) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > public class LambdaVsCurrentThreadBench { > @Benchmark > public Class<?> getCurrentThreadClass() { > return Thread.currentThread().getClass(); > } > @Benchmark > public Supplier<Class<?>> getCurrentThreadClassSupplier() { > return () -> Thread.currentThread().getClass(); > } > } > Regards, Peter From john.r.rose at oracle.com Sat Oct 31 19:44:31 2015 From: john.r.rose at oracle.com (John Rose) Date: Sat, 31 Oct 2015 12:44:31 -0700 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <1317738244.2516893.1446290238651.JavaMail.zimbra@u-pem.fr> References: <5613D01F.3000107@Oracle.com> <CACzrW9BPnBNKaXzLfZeJdD+5n_mZV-OM3TH+yD=suGB2mYR2CQ@mail.gmail.com> <91F25DF8-BC0F-44EB-A57D-A49FF7876DB9@oracle.com> <5617B184.7060803@oracle.com> <5617E141.7000503@Oracle.com> <50EAA3DD-46F5-4BF2-B010-333CEE7187A9@oracle.com> <5633BFF5.9090609@oracle.com> <5FDA255B-E3D7-4485-8C7C-6D98071D0A1F@oracle.com> <1317738244.2516893.1446290238651.JavaMail.zimbra@u-pem.fr> Message-ID: <1C154586-2033-4154-B75C-9125993D0AB9@oracle.com> On Oct 31, 2015, at 4:17 AM, Remi Forax <forax at univ-mlv.fr> wrote: > > Hi John, > I think there is a good reason to not reuse/enhance the requireNonNull prefix, > requireNonNull here is used to check a precondition or an invariant (a contract), hence a name that starts with 'require' like in Eiffel. > (BTW re-reading this thread, Brian already said that) Ah, of course?that's where require came from, from contract terms. Thanks. > requireNonNullElseGet is not something that checks a contract and as you said, nonNull is not a good prefix too, so we should starts a new family. It seems to me that, even so, "require*" makes excellent logical sense for the proposed use case. As I said, it requires a slight adjustment (really, an *expansion*) of the contract viewpoint. I think we should be happy to think of the new "require*" logic as an "extended contract" or "contract with fallback/repair". Why shouldn't contract checks (at least in our system) offer repairs? Why must "require", as imported from Eiffel (or some such place) dictate the meaning of a family of Java methods? If I am working on new Java code, and I want to enforce a dynamically checked condition P on some value X, I *first* think, "X must be (is required to be) P", and then as a *secondary* thought I think, "what event E should happen if that fails?" In this case, X is a reference value and P is "must not be null". E can often be: - throw NullPointerException - throw IllegalArgumentException - throw AssertionError (use assert syntax) - replace X with an ad hoc fallback value - replace X with the result of some ad hoc computation (Supplier.get) - execute some ad hoc logic inline (control flow) I understand that contract systems (per se) allow a single contract to be injected across a range of sites, and so the use of ad hoc local values is impossible in those use cases, but (again) we are not designing a contract system here. ? John P.S. If we did add a contract system, perhaps we would end up with double-requires, as: class Box<T> { private T value; static require<in value> { Objects.requireNonNull(value); } // value null-checked before every storage ... } This suggests there is only a weak linkage between some hypothetical contract system and the present API. P.P.S. > what about: > <T> T coalesceNull(T, T) > <T> T coalesceNullGet(T, Supplier<? extends T>) (Sorry, not for my bikeshed.) From john.r.rose at oracle.com Sat Oct 31 19:51:12 2015 From: john.r.rose at oracle.com (John Rose) Date: Sat, 31 Oct 2015 12:51:12 -0700 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <675709662.2550110.1446317443208.JavaMail.zimbra@u-pem.fr> References: <B405DF00-00FD-419A-9D99-82F079497841@oracle.com> <5633CC1E.1030603@redhat.com> <3E3E56F1-6402-4CFF-84E1-9CEE9CC0D34C@oracle.com> <675709662.2550110.1446317443208.JavaMail.zimbra@u-pem.fr> Message-ID: <5D28F4B9-B88E-4D52-A1D3-665F0516D575@oracle.com> On Oct 31, 2015, at 11:50 AM, Remi Forax <forax at univ-mlv.fr> wrote: > > I think most of the runtime language developers, myself included will kill to have this feature included into the JDK. > There are several features of dynamic languages that are currently hard to implement like type specialization, stack reification, as you said fibers, and more generally de-optimization that will be far easier to implement with that capability (currently only Nashorn can afford to implement some of these optimizations). Oh, yes, we've been thinking about it, eagerly, even though other things (modules, true polymorphism, value types, native interconnect) keep pushing to the top of the list. Most recently, at the JavaOne "Ask the Architects", we were asked "what big-ticket item would you add to Java that is not already on the map?" Mark immediately said, "coroutines". ? John P.S. ...Which relieved me of the duty to say "coroutines", allowing me to talk about a group of overlapping DSL-like features like object construction expressions, complex constants, builders and complex array selection expressions. Those things all fit together, you know. From vitalyd at gmail.com Sat Oct 31 19:51:44 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Sat, 31 Oct 2015 15:51:44 -0400 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <1C154586-2033-4154-B75C-9125993D0AB9@oracle.com> References: <5613D01F.3000107@Oracle.com> <CACzrW9BPnBNKaXzLfZeJdD+5n_mZV-OM3TH+yD=suGB2mYR2CQ@mail.gmail.com> <91F25DF8-BC0F-44EB-A57D-A49FF7876DB9@oracle.com> <5617B184.7060803@oracle.com> <5617E141.7000503@Oracle.com> <50EAA3DD-46F5-4BF2-B010-333CEE7187A9@oracle.com> <5633BFF5.9090609@oracle.com> <5FDA255B-E3D7-4485-8C7C-6D98071D0A1F@oracle.com> <1317738244.2516893.1446290238651.JavaMail.zimbra@u-pem.fr> <1C154586-2033-4154-B75C-9125993D0AB9@oracle.com> Message-ID: <CAHjP37HO3Mb3WDZDq4s1hdD0rLwY_Swim=1+sVb1vv0fqKGUig@mail.gmail.com> How about Objects.ifNull? Short and sweet. I don't like requireXXX for this semantic either. sent from my phone On Oct 31, 2015 3:45 PM, "John Rose" <john.r.rose at oracle.com> wrote: > On Oct 31, 2015, at 4:17 AM, Remi Forax <forax at univ-mlv.fr> wrote: > > > > Hi John, > > I think there is a good reason to not reuse/enhance the requireNonNull > prefix, > > requireNonNull here is used to check a precondition or an invariant (a > contract), hence a name that starts with 'require' like in Eiffel. > > (BTW re-reading this thread, Brian already said that) > > Ah, of course?that's where require came from, from contract terms. Thanks. > > > requireNonNullElseGet is not something that checks a contract and as you > said, nonNull is not a good prefix too, so we should starts a new family. > > It seems to me that, even so, "require*" makes excellent logical sense for > the proposed use case. As I said, it requires a slight adjustment (really, > an *expansion*) of the contract viewpoint. I think we should be happy to > think of the new "require*" logic as an "extended contract" or "contract > with fallback/repair". > > Why shouldn't contract checks (at least in our system) offer repairs? Why > must "require", as imported from Eiffel (or some such place) dictate the > meaning of a family of Java methods? If I am working on new Java code, and > I want to enforce a dynamically checked condition P on some value X, I > *first* think, "X must be (is required to be) P", and then as a *secondary* > thought I think, "what event E should happen if that fails?" In this case, > X is a reference value and P is "must not be null". E can often be: > > - throw NullPointerException > - throw IllegalArgumentException > - throw AssertionError (use assert syntax) > - replace X with an ad hoc fallback value > - replace X with the result of some ad hoc computation (Supplier.get) > - execute some ad hoc logic inline (control flow) > > I understand that contract systems (per se) allow a single contract to be > injected across a range of sites, and so the use of ad hoc local values is > impossible in those use cases, but (again) we are not designing a contract > system here. > > ? John > > P.S. If we did add a contract system, perhaps we would end up with > double-requires, as: > > class Box<T> { > private T value; > static require<in value> { Objects.requireNonNull(value); } > // value null-checked before every storage > ... > } > > This suggests there is only a weak linkage between some hypothetical > contract system and the present API. > > P.P.S. > > what about: > > <T> T coalesceNull(T, T) > > <T> T coalesceNullGet(T, Supplier<? extends T>) > > (Sorry, not for my bikeshed.) From john.r.rose at oracle.com Sat Oct 31 19:56:13 2015 From: john.r.rose at oracle.com (John Rose) Date: Sat, 31 Oct 2015 12:56:13 -0700 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <5D28F4B9-B88E-4D52-A1D3-665F0516D575@oracle.com> References: <B405DF00-00FD-419A-9D99-82F079497841@oracle.com> <5633CC1E.1030603@redhat.com> <3E3E56F1-6402-4CFF-84E1-9CEE9CC0D34C@oracle.com> <675709662.2550110.1446317443208.JavaMail.zimbra@u-pem.fr> <5D28F4B9-B88E-4D52-A1D3-665F0516D575@oracle.com> Message-ID: <02CB415C-E0C7-4ED2-9225-8980230DC8E1@oracle.com> On Oct 31, 2015, at 12:51 PM, John Rose <john.r.rose at oracle.com> wrote: > > modules, true polymorphism, value types, native interconnect P.S. Project refs: Jigsaw, Valhalla (List<any T>), Valhalla, Panama. From john.r.rose at oracle.com Sat Oct 31 20:06:37 2015 From: john.r.rose at oracle.com (John Rose) Date: Sat, 31 Oct 2015 13:06:37 -0700 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <1C154586-2033-4154-B75C-9125993D0AB9@oracle.com> References: <5613D01F.3000107@Oracle.com> <CACzrW9BPnBNKaXzLfZeJdD+5n_mZV-OM3TH+yD=suGB2mYR2CQ@mail.gmail.com> <91F25DF8-BC0F-44EB-A57D-A49FF7876DB9@oracle.com> <5617B184.7060803@oracle.com> <5617E141.7000503@Oracle.com> <50EAA3DD-46F5-4BF2-B010-333CEE7187A9@oracle.com> <5633BFF5.9090609@oracle.com> <5FDA255B-E3D7-4485-8C7C-6D98071D0A1F@oracle.com> <1317738244.2516893.1446290238651.JavaMail.zimbra@u-pem.fr> <1C154586-2033-4154-B75C-9125993D0AB9@oracle.com> Message-ID: <F9E13899-5F6C-421C-A540-EC163E297879@oracle.com> OK, it's Halloween, so a certain amount of bikeshed vandalism might be allowable. I will to select my spray-paint color from the following paint-store aisle: http://www.thesaurus.com/browse/deter <http://www.thesaurus.com/browse/deter> There's something in there to charm everyone. Personally, I would fall for: > <T> T checkNull(T, T) > <T> TcheckNullElseGet(T, Supplier<? extends T>) The trick is to remember that "check" can be a synonym for "deter" as in hockey. The treat is that "checkNull" reminds every Java programmer of "null check". Plus it's not taken yet. (Gonna have to shower after this is over.) ? John On Oct 31, 2015, at 12:51 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote: > How about Objects.ifNull? Short and sweet. I don't like requireXXX for this semantic either. On Oct 31, 2015, at 4:17 AM, Remi Forax <forax at univ-mlv.fr> wrote: > > what about: > <T> T coalesceNull(T, T) > <T> T coalesceNullGet(T, Supplier<? extends T>) On Oct 31, 2015, at 12:01 AM, John Rose <john.r.rose at oracle.com> wrote: > P.S. Going for a third way and starting a new family of methods ("notNull*", "stopNull", etc.) would make me sad too, since we already have null-stopping API points. I'd secretly welcome Objects.or(a, b, c), etc. (coupled with "require*" to throw NPEs), but only because "OR" is a sort of logical in-joke for ex-Lispers. From vitalyd at gmail.com Sat Oct 31 20:15:08 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Sat, 31 Oct 2015 16:15:08 -0400 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <F9E13899-5F6C-421C-A540-EC163E297879@oracle.com> References: <5613D01F.3000107@Oracle.com> <CACzrW9BPnBNKaXzLfZeJdD+5n_mZV-OM3TH+yD=suGB2mYR2CQ@mail.gmail.com> <91F25DF8-BC0F-44EB-A57D-A49FF7876DB9@oracle.com> <5617B184.7060803@oracle.com> <5617E141.7000503@Oracle.com> <50EAA3DD-46F5-4BF2-B010-333CEE7187A9@oracle.com> <5633BFF5.9090609@oracle.com> <5FDA255B-E3D7-4485-8C7C-6D98071D0A1F@oracle.com> <1317738244.2516893.1446290238651.JavaMail.zimbra@u-pem.fr> <1C154586-2033-4154-B75C-9125993D0AB9@oracle.com> <F9E13899-5F6C-421C-A540-EC163E297879@oracle.com> Message-ID: <CAHjP37FMsErVYKcRZc9knx6JQmrZ3_-HerZGTo7jz=9OA9fxyg@mail.gmail.com> It's hard to escape bikeshedding, everyone's subconsciously favorite pastime. :) To me, checkNull still means there's an error path somewhere there (I've seen plenty of internal validation/util APIs where check methods throw if arg is null). To me, we're saying "here's a method that returns default if arg is null", which is an if statement on null. So ifNull, ifNullThen, defaultIfNull, etc seem to convey slightly more of the intent. sent from my phone On Oct 31, 2015 4:06 PM, "John Rose" <john.r.rose at oracle.com> wrote: > OK, it's Halloween, so a certain amount of bikeshed vandalism might be > allowable. > > I will to select my spray-paint color from the following paint-store aisle: > http://www.thesaurus.com/browse/deter < > http://www.thesaurus.com/browse/deter> > > There's something in there to charm everyone. Personally, I would fall > for: > > > <T> T checkNull(T, T) > > <T> TcheckNullElseGet(T, Supplier<? extends T>) > > The trick is to remember that "check" can be a synonym for "deter" as in > hockey. > The treat is that "checkNull" reminds every Java programmer of "null > check". Plus it's not taken yet. > (Gonna have to shower after this is over.) > > ? John > > On Oct 31, 2015, at 12:51 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote: > > How about Objects.ifNull? Short and sweet. I don't like requireXXX for > this semantic either. > > On Oct 31, 2015, at 4:17 AM, Remi Forax <forax at univ-mlv.fr> wrote: > > > > what about: > > <T> T coalesceNull(T, T) > > <T> T coalesceNullGet(T, Supplier<? extends T>) > > On Oct 31, 2015, at 12:01 AM, John Rose <john.r.rose at oracle.com> wrote: > > > P.S. Going for a third way and starting a new family of methods > ("notNull*", "stopNull", etc.) would make me sad too, since we already have > null-stopping API points. I'd secretly welcome Objects.or(a, b, c), etc. > (coupled with "require*" to throw NPEs), but only because "OR" is a sort of > logical in-joke for ex-Lispers. > > From roger.riggs at oracle.com Sat Oct 31 20:29:16 2015 From: roger.riggs at oracle.com (Roger Riggs) Date: Sat, 31 Oct 2015 14:29:16 -0600 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <F9E13899-5F6C-421C-A540-EC163E297879@oracle.com> References: <5613D01F.3000107@Oracle.com> <CACzrW9BPnBNKaXzLfZeJdD+5n_mZV-OM3TH+yD=suGB2mYR2CQ@mail.gmail.com> <91F25DF8-BC0F-44EB-A57D-A49FF7876DB9@oracle.com> <5617B184.7060803@oracle.com> <5617E141.7000503@Oracle.com> <50EAA3DD-46F5-4BF2-B010-333CEE7187A9@oracle.com> <5633BFF5.9090609@oracle.com> <5FDA255B-E3D7-4485-8C7C-6D98071D0A1F@oracle.com> <1317738244.2516893.1446290238651.JavaMail.zimbra@u-pem.fr> <1C154586-2033-4154-B75C-9125993D0AB9@oracle.com> <F9E13899-5F6C-421C-A540-EC163E297879@oracle.com> Message-ID: <5635249C.3050108@oracle.com> Hi, And, going back nearly to the beginning of the thread, some folks are familiar with T firstNonNull(T, T) proposed from Guava. But since the exercise was turned into simplify: (x != null) ? x : requireNonNull(y); My favorite at this point is to identify the thread as a failed attempt and remove it. ?: is going to be easier to type; and might even get some help from the IDE. Roger p.s. I occasionally work with an IDE but never exclusively when developing across 4 OS's and sometime remotely. xemacs and vi are the most portable and reliable. On 10/31/15 2:06 PM, John Rose wrote: > OK, it's Halloween, so a certain amount of bikeshed vandalism might be allowable. > > I will to select my spray-paint color from the following paint-store aisle: > http://www.thesaurus.com/browse/deter <http://www.thesaurus.com/browse/deter> > > There's something in there to charm everyone. Personally, I would fall for: > >> <T> T checkNull(T, T) >> <T> TcheckNullElseGet(T, Supplier<? extends T>) > The trick is to remember that "check" can be a synonym for "deter" as in hockey. > The treat is that "checkNull" reminds every Java programmer of "null check". Plus it's not taken yet. > (Gonna have to shower after this is over.) > > ? John > > On Oct 31, 2015, at 12:51 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote: >> How about Objects.ifNull? Short and sweet. I don't like requireXXX for this semantic either. > On Oct 31, 2015, at 4:17 AM, Remi Forax <forax at univ-mlv.fr> wrote: >> what about: >> <T> T coalesceNull(T, T) >> <T> T coalesceNullGet(T, Supplier<? extends T>) > On Oct 31, 2015, at 12:01 AM, John Rose <john.r.rose at oracle.com> wrote: > >> P.S. Going for a third way and starting a new family of methods ("notNull*", "stopNull", etc.) would make me sad too, since we already have null-stopping API points. I'd secretly welcome Objects.or(a, b, c), etc. (coupled with "require*" to throw NPEs), but only because "OR" is a sort of logical in-joke for ex-Lispers. From mandy.chung at oracle.com Sat Oct 31 22:59:01 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 31 Oct 2015 15:59:01 -0700 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <1856609155.2548586.1446316180239.JavaMail.zimbra@u-pem.fr> References: <B405DF00-00FD-419A-9D99-82F079497841@oracle.com> <5633CC1E.1030603@redhat.com> <990258669.2446021.1446236810570.JavaMail.zimbra@u-pem.fr> <B9A3F0C0-E5FB-4EB2-9907-B6BF21D23605@oracle.com> <1440520184.2546899.1446314771503.JavaMail.zimbra@u-pem.fr> <1856609155.2548586.1446316180239.JavaMail.zimbra@u-pem.fr> Message-ID: <6F54C4AF-2B92-429B-B452-8FF3C372B6D9@oracle.com> > On Oct 31, 2015, at 11:29 AM, Remi Forax <forax at univ-mlv.fr> wrote: > > Hi Mandy, > I've crawled the code and the documentation again. > > In the doc and in the code, a lambda with one parameter doesn't require parenthesis around the parameter, > (s) -> s.doSomething() > should be > s -> s.doSomething(). > Oh right. (It didn?t look right to me but didn?t pay attention to it). > > In the doc of StackWalker, > in the first example, the local variable 'frame' should be named ?callerClass' > Fixed > > In the doc of getCallerClass(), > the first example do a skip(2) which i believe is not necessary anymore, It has to skip two frames. Use the second example, the stack looks like this: StackWalk::getCallerClass Util::getResourceBundle Foo::init : : > also instead of Optional.orElse, orElseGet is better because it avoids to evaluate > Thread.currentThread().getClass() if not necessary. > > So the example should be: > walk(s -> s.map(StackFrame::getDeclaringClass) > .findFirst()).orElseGet(() -> Thread.currentThread().getClass()); > This would return Util.class instead of Foo.class > In the second example, the field walker should be declared 'final?. Sure. Fixed. > > And as i said earlier, the signature of walk() is: > <T> T walk(Function<? super Stream<StackWalker.StackFrame>, ? extends T> function, IntUnaryOperator batchSizeMapper) > I was pondering it and that?s why not changed in the last update. I agree with the upper bounded wildcard "? extends T? for the return type of the function. But for the function?s input argument, can you help me understand why it should take "? super Stream<StackWalker.StackFrame>?? Is it useful to have function accepting supertype of Stream<StackFrame> rather than Stream<StackFrame>? VM should be the only source producing this StackFrame stream. On the other hand, I wonder if the stream argument should be Stream<? extends StackFrame> that may allow future implementation change. <T> T walk(Function<Stream<? extends StackWalker.StackFrame>, ? extends T> function, ?) Mandy From forax at univ-mlv.fr Sat Oct 31 23:23:17 2015 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sun, 1 Nov 2015 00:23:17 +0100 (CET) Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <6F54C4AF-2B92-429B-B452-8FF3C372B6D9@oracle.com> References: <B405DF00-00FD-419A-9D99-82F079497841@oracle.com> <5633CC1E.1030603@redhat.com> <990258669.2446021.1446236810570.JavaMail.zimbra@u-pem.fr> <B9A3F0C0-E5FB-4EB2-9907-B6BF21D23605@oracle.com> <1440520184.2546899.1446314771503.JavaMail.zimbra@u-pem.fr> <1856609155.2548586.1446316180239.JavaMail.zimbra@u-pem.fr> <6F54C4AF-2B92-429B-B452-8FF3C372B6D9@oracle.com> Message-ID: <237221617.2567778.1446333797116.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Mandy Chung" <mandy.chung at oracle.com> > ?: "Remi Forax" <forax at univ-mlv.fr> > Cc: core-libs-dev at openjdk.java.net > Envoy?: Samedi 31 Octobre 2015 23:59:01 > Objet: Re: Proposed API for JEP 259: Stack-Walking API > > > > On Oct 31, 2015, at 11:29 AM, Remi Forax <forax at univ-mlv.fr> wrote: > > > > Hi Mandy, > > I've crawled the code and the documentation again. > > > > In the doc and in the code, a lambda with one parameter doesn't require > > parenthesis around the parameter, > > (s) -> s.doSomething() > > should be > > s -> s.doSomething(). > > > > Oh right. (It didn?t look right to me but didn?t pay attention to it). > > > > > In the doc of StackWalker, > > in the first example, the local variable 'frame' should be named > > ?callerClass' > > > > Fixed > > > > In the doc of getCallerClass(), > > the first example do a skip(2) which i believe is not necessary anymore, > > It has to skip two frames. Use the second example, the stack looks like > this: > > StackWalk::getCallerClass > Util::getResourceBundle > Foo::init > : > : Ok, get it ! > > > also instead of Optional.orElse, orElseGet is better because it avoids to > > evaluate > > Thread.currentThread().getClass() if not necessary. > > > > So the example should be: > > walk(s -> s.map(StackFrame::getDeclaringClass) > > .findFirst()).orElseGet(() -> > > Thread.currentThread().getClass()); > > > > This would return Util.class instead of Foo.class > > > In the second example, the field walker should be declared 'final?. > > Sure. Fixed. > > > > > And as i said earlier, the signature of walk() is: > > <T> T walk(Function<? super Stream<StackWalker.StackFrame>, ? extends T> > > function, IntUnaryOperator batchSizeMapper) > > > > I was pondering it and that?s why not changed in the last update. I agree > with the upper bounded wildcard "? extends T? for the return type of the > function. > > But for the function?s input argument, can you help me understand why it > should take "? super Stream<StackWalker.StackFrame>?? Is it useful to have > function accepting supertype of Stream<StackFrame> rather than > Stream<StackFrame>? VM should be the only source producing this StackFrame > stream. currently this code doesn't compile, and should IMO, Function<BaseStream<StackWalker.StackFrame>, Void> fun = null; stackWalker.walk(fun); > > On the other hand, I wonder if the stream argument should be Stream<? extends > StackFrame> that may allow future implementation change. > > <T> T walk(Function<Stream<? extends StackWalker.StackFrame>, ? extends T> > function, ?) A stream of ? extends StackFrame means that you can not call any methods of Stream<T> that takes a T as parameter because the compiler can not enforce that the type is correct, so you can not call neither reduce(BinaryOperator<T> ) nor reduce(T, BinaryOperator<T>). If you want to be able to send subtypes of StackFrame and know that at compile time, it's better to parameterized the StackWalker class by the type of StackFrame. > > Mandy R?mi From brian.goetz at oracle.com Sat Oct 31 23:37:31 2015 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 31 Oct 2015 19:37:31 -0400 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <5633DAF6.7070708@redhat.com> References: <B405DF00-00FD-419A-9D99-82F079497841@oracle.com> <5633CC1E.1030603@redhat.com> <990258669.2446021.1446236810570.JavaMail.zimbra@u-pem.fr> <5633DAF6.7070708@redhat.com> Message-ID: <563550BB.1060009@oracle.com> >> IntToIntFunction => IntUnaryOperator. > > Ah that's the one! You know I think that this is more than once that > I looked for, and didn't find, that interface. Some kind of mental > blind spot I guess. :-) > We all look forward to when Valhalla will relegate all of these hand-specialized interfaces to the scrap heap, and we can just use Function<int,int>...