Re: RFR: 8260401: StackOverflowError on open WindowsPreferences
On Fri, 12 Feb 2021 23:40:51 GMT, Brian Burkhalter wrote: >> Can I please get a review for this change which proposes to fix the issue >> reported in https://bugs.openjdk.java.net/browse/JDK-8260401? >> >> As noted in that issue, when the constructor of >> `java.util.prefs.WindowsPreferences` runs into an error while dealing with >> the Windows registry, it logs a warning message. The message construction >> calls `rootNativeHandle()` (on the same instance of `WindowsPreferences` >> that's being constructed) which then ultimately ends up calling the >> constructor of `WindowsPreferences` which then again runs into the Windows >> registry error and attempts to log a message and this whole cycle repeats >> indefinitely leading to that `StackOverFlowError`. >> >> Based on my limited knowledge of the code in that constructor and analyzing >> that code a bit, it's my understanding (and also the input provided by the >> reporter of the bug) that the log message should actually be using the >> `rootNativeHandle` parameter that is passed to this constructor instead of >> invoking the `rootNativeHandle()` method. The commit in this PR does this >> change to use the passed `rootNativeHandle` in the log message. >> >> Furthermore, there's another constructor in this class which does a similar >> thing and potentially can run into the same error as this one. I've changed >> that constructor too, to avoid the call to `rootNativeHandle()` method in >> that log message. Reading the log message that's being generated there, it's >> my understanding that this change shouldn't cause any inaccuracy in what's >> being logged and in fact, I think it's now more precise about which handle >> returned the error code. >> >> Finally, this log message creation, in both the constructors, also calls >> `windowsAbsolutePath()` and `byteArrayToString()` methods. The >> `byteArrayToString()` is a static method and a call to it doesn't lead back >> to the constructor again. The `windowsAbsolutePath()` is a instance method >> and although it does use a instance variable `absolutePath`, that instance >> variable is already initialized appropriately by the time this >> `windowsAbsolutePath()` gets called in the log message. Also, the >> `windowsAbsolutePath()` call doesn't lead back to the constructor of the >> `WindowsPreferences` so it doesn't pose the same issue as a call to >> `rootNativeHandle()`. >> >> Given the nature of this issue, I haven't added any jtreg test for this >> change. > > I think you can go ahead and integrate this now. Thank you Brian for the review and help in testing the change. - PR: https://git.openjdk.java.net/jdk/pull/2326
Integrated: 8260401: StackOverflowError on open WindowsPreferences
On Sat, 30 Jan 2021 14:35:50 GMT, Jaikiran Pai wrote: > Can I please get a review for this change which proposes to fix the issue > reported in https://bugs.openjdk.java.net/browse/JDK-8260401? > > As noted in that issue, when the constructor of > `java.util.prefs.WindowsPreferences` runs into an error while dealing with > the Windows registry, it logs a warning message. The message construction > calls `rootNativeHandle()` (on the same instance of `WindowsPreferences` > that's being constructed) which then ultimately ends up calling the > constructor of `WindowsPreferences` which then again runs into the Windows > registry error and attempts to log a message and this whole cycle repeats > indefinitely leading to that `StackOverFlowError`. > > Based on my limited knowledge of the code in that constructor and analyzing > that code a bit, it's my understanding (and also the input provided by the > reporter of the bug) that the log message should actually be using the > `rootNativeHandle` parameter that is passed to this constructor instead of > invoking the `rootNativeHandle()` method. The commit in this PR does this > change to use the passed `rootNativeHandle` in the log message. > > Furthermore, there's another constructor in this class which does a similar > thing and potentially can run into the same error as this one. I've changed > that constructor too, to avoid the call to `rootNativeHandle()` method in > that log message. Reading the log message that's being generated there, it's > my understanding that this change shouldn't cause any inaccuracy in what's > being logged and in fact, I think it's now more precise about which handle > returned the error code. > > Finally, this log message creation, in both the constructors, also calls > `windowsAbsolutePath()` and `byteArrayToString()` methods. The > `byteArrayToString()` is a static method and a call to it doesn't lead back > to the constructor again. The `windowsAbsolutePath()` is a instance method > and although it does use a instance variable `absolutePath`, that instance > variable is already initialized appropriately by the time this > `windowsAbsolutePath()` gets called in the log message. Also, the > `windowsAbsolutePath()` call doesn't lead back to the constructor of the > `WindowsPreferences` so it doesn't pose the same issue as a call to > `rootNativeHandle()`. > > Given the nature of this issue, I haven't added any jtreg test for this > change. This pull request has now been integrated. Changeset: 849390a1 Author:Jaikiran Pai URL: https://git.openjdk.java.net/jdk/commit/849390a1 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8260401: StackOverflowError on open WindowsPreferences Reviewed-by: bpb - PR: https://git.openjdk.java.net/jdk/pull/2326
RFR: JDK-8260858: Implementation specific property xsltcIsStandalone for XSLTC Serializer
Adds a property similar to 'isStandalone' in JDK-8249867. Please note that the test received an auto-format. The material changes were the two tests marked with bug id 8260858 and related data and methods. - Commit messages: - JDK-8260858: Implementation specific property xsltcIsStandalone for XSLTC Serializer Changes: https://git.openjdk.java.net/jdk/pull/2559/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2559=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260858 Stats: 243 lines in 7 files changed: 167 ins; 4 del; 72 mod Patch: https://git.openjdk.java.net/jdk/pull/2559.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2559/head:pull/2559 PR: https://git.openjdk.java.net/jdk/pull/2559
Re: RFR: JDK-8261422: Adjust problematic String.format calls in jdk/internal/util/Preconditions.java outOfBoundsMessage
On Tue, 9 Feb 2021 16:04:02 GMT, stefan-zobel wrote: >> I haven't written the class Preconditions.java, this question should >> probably go to the authors . >> I found the String.format syntax a bit unusual, should this be rewritten ? > > AFAIK, Preconditions was introduced in > https://bugs.openjdk.java.net/browse/JDK-8155794 It looks like java/util/Objects/CheckIndex should adequately cover this change. - PR: https://git.openjdk.java.net/jdk/pull/2483
Re: RFR: 8260401: StackOverflowError on open WindowsPreferences
On Fri, 12 Feb 2021 03:34:54 GMT, Jaikiran Pai wrote: >> Did you run this through the usual CI tests in all tiers? > >> Did you run this through the usual CI tests in all tiers? > > Hello Brian, > > Do you mean other than the ones that have been automatically run and passed > in the GitHub actions against this PR? I don't have a Windows box, but if > there's some specific tests you want me to run locally, please do let me know > and I'll run them. > On Feb 11, 2021, at 7:35 PM, Jaikiran wrote: > > Did you run this through the usual CI tests in all tiers? > > Hello Brian, > > Do you mean other than the ones that have been automatically run and passed > in the GitHub actions against this PR? I don't have a Windows box, but if > there's some specific tests you want me to run locally, please do let me know > and I'll run them. > I ran this through our internal CI tests and saw no problems. - PR: https://git.openjdk.java.net/jdk/pull/2326
Re: RFR: 8260401: StackOverflowError on open WindowsPreferences
On Sat, 30 Jan 2021 14:35:50 GMT, Jaikiran Pai wrote: > Can I please get a review for this change which proposes to fix the issue > reported in https://bugs.openjdk.java.net/browse/JDK-8260401? > > As noted in that issue, when the constructor of > `java.util.prefs.WindowsPreferences` runs into an error while dealing with > the Windows registry, it logs a warning message. The message construction > calls `rootNativeHandle()` (on the same instance of `WindowsPreferences` > that's being constructed) which then ultimately ends up calling the > constructor of `WindowsPreferences` which then again runs into the Windows > registry error and attempts to log a message and this whole cycle repeats > indefinitely leading to that `StackOverFlowError`. > > Based on my limited knowledge of the code in that constructor and analyzing > that code a bit, it's my understanding (and also the input provided by the > reporter of the bug) that the log message should actually be using the > `rootNativeHandle` parameter that is passed to this constructor instead of > invoking the `rootNativeHandle()` method. The commit in this PR does this > change to use the passed `rootNativeHandle` in the log message. > > Furthermore, there's another constructor in this class which does a similar > thing and potentially can run into the same error as this one. I've changed > that constructor too, to avoid the call to `rootNativeHandle()` method in > that log message. Reading the log message that's being generated there, it's > my understanding that this change shouldn't cause any inaccuracy in what's > being logged and in fact, I think it's now more precise about which handle > returned the error code. > > Finally, this log message creation, in both the constructors, also calls > `windowsAbsolutePath()` and `byteArrayToString()` methods. The > `byteArrayToString()` is a static method and a call to it doesn't lead back > to the constructor again. The `windowsAbsolutePath()` is a instance method > and although it does use a instance variable `absolutePath`, that instance > variable is already initialized appropriately by the time this > `windowsAbsolutePath()` gets called in the log message. Also, the > `windowsAbsolutePath()` call doesn't lead back to the constructor of the > `WindowsPreferences` so it doesn't pose the same issue as a call to > `rootNativeHandle()`. > > Given the nature of this issue, I haven't added any jtreg test for this > change. I think you can go ahead and integrate this now. - Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2326
Re: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v6]
On Fri, 12 Feb 2021 22:52:06 GMT, Joe Darcy wrote:
>> A follow-up of sorts to JDK-8257086, this change aims to improve the
>> discussion of the relationship between Object.equals and compareTo and
>> compare methods. The not-consistent-with-equals natural ordering of
>> BigDecimal get more explication too. While updating Object, I added some
>> uses of apiNote and implSpec, as appropriate. While a signum method did not
>> exist when Comparable was added, it has existed for many years so I removed
>> obsolete text that defined a "sgn" function to compute signum.
>>
>> Once the changes are agreed to, I'll reflow paragraphs and update the
>> copyright years.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Fix typo.
Marked as reviewed by smarks (Reviewer).
src/java.base/share/classes/java/math/BigDecimal.java line 99:
> 97: * hold. The results of methods like {@link scale} and {@link
> 98: * unscaledValue} will differ for numerically equal values with
> 99: * different representations.
While this text is correct and reasonable, it doesn't really explain _why_
equals() considers the representation. One might assume incorrectly that the
representation is internal only and doesn't affect computations. Of course it
does affect computations, which is why I suggested the example. Maybe the
example doesn't belong right here, in which case it's reasonable for this
change to proceed. I think it would be good to put an example _somewhere_ of
non-substitutability of numerical values with different representations. Maybe
we could handle that separately.
-
PR: https://git.openjdk.java.net/jdk/pull/2471
Re: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v3]
On Fri, 12 Feb 2021 22:12:30 GMT, Joe Darcy wrote:
>> src/java.base/share/classes/java/lang/Comparable.java line 90:
>>
>>> 88: * of the {@code equals} method and the equivalence classes defined by
>>> 89: * the quotient of the {@code compareTo} method are the same.
>>> 90: *
>>
>> I think in both cases it should be "the equivalence class defined by"
>> That is, "equivalence class" should be singular. But there are two of them,
>> so the sentence still properly concludes "... are the same."
>
> An equivalence relation defines a *set* of equivalence classes which
> partition the objects the relation operates on. For example, the "same signum
> value" equivalence relation on integers has three equivalence classes :
> 1) negative nonzero numbers (corresponding to signum == -1)
> 2) zero (corresponding to signum = 0)
> 3) positive nonzero numbers (corresponding to signum ==1)
OK, got it.
-
PR: https://git.openjdk.java.net/jdk/pull/2471
Re: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v3]
On Fri, 12 Feb 2021 22:39:55 GMT, Roger Riggs wrote: >> Added "The string output is not necessary stable over time." The particulars >> of the toString contract of a given class will depend on the class of course. > > Perhaps "necessary" -> "necessarily" Good catch Roger; will change to "The string output is not necessarily stable over time or across JVM invocations." The latter clause will more explicitly handle cases like "myEnumConstant.toString() gave different answers when I ran the program multiple times," a bug that has been submitted as closed as not-a-bug repeated. - PR: https://git.openjdk.java.net/jdk/pull/2471
Re: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v6]
> A follow-up of sorts to JDK-8257086, this change aims to improve the > discussion of the relationship between Object.equals and compareTo and > compare methods. The not-consistent-with-equals natural ordering of > BigDecimal get more explication too. While updating Object, I added some uses > of apiNote and implSpec, as appropriate. While a signum method did not exist > when Comparable was added, it has existed for many years so I removed > obsolete text that defined a "sgn" function to compute signum. > > Once the changes are agreed to, I'll reflow paragraphs and update the > copyright years. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Fix typo. - Changes: - all: https://git.openjdk.java.net/jdk/pull/2471/files - new: https://git.openjdk.java.net/jdk/pull/2471/files/41102f52..03f01e65 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2471=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2471=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2471.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2471/head:pull/2471 PR: https://git.openjdk.java.net/jdk/pull/2471
Re: RFR: 8261031: Move some ClassLoader name checking to native/VM [v3]
On Fri, 12 Feb 2021 02:10:02 GMT, Coleen Phillimore wrote: >> Claes Redestad has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Consolidate verifyClassname and verifyFixClassname > > This more limited cleanup looks good. This patch changes `JVM_FindLoadedClass` interface to only accept a binary name. It used to accept both a binary name and internal form. Most, if not all, JVM entry points take the name of internal name. So this change makes this JVM entry point inconsistent with others. Looking closer each API that involves `fixClassName` or `verifyXXXClassName`, the JVM entry points called expects the internal form except `JVM_FindLoadedClass` (see details below). I think a better change is to change the native `JVM_FindLoadedClass` to accept the internal form only and have `findLoadedClass0` method to detect if the name contains '/' or '['. ClassLoader API does not allow loading of an array type whereas `Class::forName` allows to find an array type. Perhaps `verifyFixClassName` should be renamed like `binaryNameToInternalForm`. I think we don't need `fixClassname`? ClassLoader::defineClass - `preDefineClass` checks the name and throws if it contains '/' or '[' - no name check in `JVM_DefineClassWithSource` and `JVM_LookupDefineClass` which expects the name is of internal form native Class::forName0 - converts the binary name to internal form (i.e. replace '.' with '/') - throw if the name contains '/' - no explicit name check in `JVM_FindClassFromCaller` ClassLoader::loadClass - calls native `findLoadedClass0` that calls `JVM_FindLoadedClass` which accepts binary form and converts '.' to '/' but the current implementation accepts both binary name and internal form - calls `native findBootstrapClass` which converts '.' to '/' and pass the internal form to `JVM_FindBootstrapClass`. It'd be helpful to document the internal APIs and JVM entry points clearly what it expects for example binary name vs internal form and where it does the validation e.g. Class::forName0 allows array type and native library methods do the name validation. - PR: https://git.openjdk.java.net/jdk/pull/2378
Re: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v5]
> A follow-up of sorts to JDK-8257086, this change aims to improve the > discussion of the relationship between Object.equals and compareTo and > compare methods. The not-consistent-with-equals natural ordering of > BigDecimal get more explication too. While updating Object, I added some uses > of apiNote and implSpec, as appropriate. While a signum method did not exist > when Comparable was added, it has existed for many years so I removed > obsolete text that defined a "sgn" function to compute signum. > > Once the changes are agreed to, I'll reflow paragraphs and update the > copyright years. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to more review feedback. - Changes: - all: https://git.openjdk.java.net/jdk/pull/2471/files - new: https://git.openjdk.java.net/jdk/pull/2471/files/a7f1b28b..41102f52 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2471=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2471=03-04 Stats: 12 lines in 3 files changed: 6 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2471.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2471/head:pull/2471 PR: https://git.openjdk.java.net/jdk/pull/2471
Re: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v3]
On Fri, 12 Feb 2021 22:28:33 GMT, Joe Darcy wrote: >> src/java.base/share/classes/java/lang/Object.java line 236: >> >>> 234: * be a concise but informative representation that is easy for a >>> 235: * person to read. >>> 236: * It is recommended that all subclasses override this method. >> >> Do we want to have a general note here or somewhere that the exact format of >> the result of `toString()` is generally not stable, and that it is subject >> to change without notice? > > Added "The string output is not necessary stable over time." The particulars > of the toString contract of a given class will depend on the class of course. Perhaps "necessary" -> "necessarily" - PR: https://git.openjdk.java.net/jdk/pull/2471
Re: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v3]
On Thu, 11 Feb 2021 04:44:08 GMT, Stuart Marks wrote:
>> src/java.base/share/classes/java/math/BigDecimal.java line 97:
>>
>>> 95: * contrast, the {@link equals equals} method requires both the
>>> 96: * numerical value and representation to be the same for equality to
>>> 97: * hold.
>>
>> Note, discussing "representation" is ok here since the context is discussing
>> the representation of BigDecimal (in contrast to the text in Comparable).
>
> It might be reasonable to add a bit of rationale here and give an example. I
> think the reason that members of the same cohort might not be considered
> `equals()` to one another is that they are not substitutable. For example,
> consider 2.0 and 2.00. They are members of the same cohort, because
>
> new BigDecimal("2.0").compareTo(new BigDecimal("2.00")) == 0
>
> is true. However,
>
> new BigDecimal("2.0").equals(new BigDecimal("2.00"))
>
> is false. They aren't considered `equals()` because they aren't
> substitutable, since using them in an arithmetic expression can give
> different results. For example:
>
> new BigDecimal("2.0").divide(new BigDecimal(3), RoundingMode.HALF_UP)
> ==> 0.7
>
> new BigDecimal("2.00").divide(new BigDecimal(3), RoundingMode.HALF_UP)
> ==> 0.67
>
> I think that's the right rationale, and a reasonable example to illustrate
> it. Edit to taste. I think it would be good to have material like this,
> though, because people's immediate reaction to BD being inconsistent with
> equals is "well that's wrong." Well, no, it's right, and I think this is the
> reason.
Added example using scale and unscaledValue.
-
PR: https://git.openjdk.java.net/jdk/pull/2471
Re: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v3]
On Thu, 11 Feb 2021 04:22:18 GMT, Stuart Marks wrote: >> Joe Darcy has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix typos in javadoc tags found during review. > > src/java.base/share/classes/java/lang/Object.java line 236: > >> 234: * be a concise but informative representation that is easy for a >> 235: * person to read. >> 236: * It is recommended that all subclasses override this method. > > Do we want to have a general note here or somewhere that the exact format of > the result of `toString()` is generally not stable, and that it is subject to > change without notice? Added "The string output is not necessary stable over time." The particulars of the toString contract of a given class will depend on the class of course. - PR: https://git.openjdk.java.net/jdk/pull/2471
Re: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v3]
On Thu, 11 Feb 2021 04:17:48 GMT, Stuart Marks wrote: >> Joe Darcy has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix typos in javadoc tags found during review. > > src/java.base/share/classes/java/lang/Object.java line 135: > >> 133: * into equivalence classes; all the members of an >> 134: * equivalence class are equal to each other. The equal objects >> 135: * are substitutable for each other, at least for some purposes. > > Since the preceding sentence mentions the members of an equivalence class, it > might read better to say "Members are substitutable..." or possibly "Members > of an equivalence class are substitutable" Phrasing updated to: "Members of an equivalence class are substitutable for each other, at least for some purposes." - PR: https://git.openjdk.java.net/jdk/pull/2471
Re: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8]
On Fri, 12 Feb 2021 21:53:13 GMT, Andrey Turbanov
wrote:
>> ## java/nio/file/Files/CopyAndMove.java
>>
>> make test TEST="jtreg:java/nio/file/Files/CopyAndMove.java"
>>
>> STDOUT:
>> Seed from RandomFactory = 704532001916725417L
>> STDERR:
>> dir1:
>> f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_nio_file_Files_CopyAndMove_java\tmp\name9678927043623070601
>> (NTFS)
>> dir2: .\name1900089232270637553 (NTFS)
>> java.lang.RuntimeException: AtomicMoveNotSupportedException expected
>> at CopyAndMove.testMove(CopyAndMove.java:369)
>> at CopyAndMove.main(CopyAndMove.java:74)
>> at
>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
>> Method)
>> at
>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>> at
>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>> at
>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> at java.base/java.lang.Thread.run(Thread.java:831)
>>
>> JavaTest Message: Test threw exception: java.lang.RuntimeException:
>> AtomicMoveNotSupportedException expected
>> JavaTest Message: shutting down test
>>
>> STATUS:Failed.`main' threw exception: java.lang.RuntimeException:
>> AtomicMoveNotSupportedException expected
>>
>> Checked in debugger:
>>
>> Files.getFileStore(dir1) = {WindowsFileStore@1211} "ssd (f:)"
>> Files.getFileStore(dir2) = {WindowsFileStore@1213} "ssd (F:)"
>> sameDevice = false
>>
>> https://bugs.openjdk.java.net/browse/JDK-8219644 looks like there is already
>> known bug this test.
>
> ## java/security/AccessController/DoPrivAccompliceTest.java
>
> make test
> TEST="jtreg:java/security/AccessController/DoPrivAccompliceTest.java"
>
> STDOUT:
> Adding DoPrivAccomplice.class to
> F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar
>
> Created jar file
> F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar
> Adding DoPrivTest.class to
> F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar
>
> Created jar file
> F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar
> Created policy for
> F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar
> Command line:
> [f:\projects\official_openjdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
> -cp
> F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\java\security\AccessController\DoPrivAccompliceTest.d;F:\Projects\official_openjdk\test\jdk\java\security\AccessController;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\test\lib;F:\Projects\official_openjdk\test\lib;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\javatest.jar;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\jtreg.jar
> -Xmx512m -XX:MaxRAMPercentage=6
> -Djava.io.tmpdir=f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\tmp
> -ea -esa -Djava.security.manager
> -Djava.security.policy=F:\Projects\official_openjdk\build\w
indows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\java.policy
-classpath
F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar
DoPrivTest ]
> [2021-02-12T21:42:29.297091800Z] Gathering output for process 12712
> [2021-02-12T21:42:29.544092Z] Waiting for completion for process 12712
> [2021-02-12T21:42:29.544092Z] Waiting for completion finished for process
> 12712
> Output and diagnostic info for process 12712 was saved into
>
Re: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v3]
On Thu, 11 Feb 2021 04:12:06 GMT, Stuart Marks wrote:
>> Joe Darcy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix typos in javadoc tags found during review.
>
> src/java.base/share/classes/java/lang/Comparable.java line 90:
>
>> 88: * of the {@code equals} method and the equivalence classes defined by
>> 89: * the quotient of the {@code compareTo} method are the same.
>> 90: *
>
> I think in both cases it should be "the equivalence class defined by"
> That is, "equivalence class" should be singular. But there are two of them,
> so the sentence still properly concludes "... are the same."
An equivalence relation defines a *set* of equivalence classes which partition
the objects the relation operates on. For example, the "same signum value"
equivalence relation on integers has three equivalence classes :
1) negative nonzero numbers (corresponding to signum == -1)
2) zero (corresponding to signum = 0)
3) positive nonzero numbers (corresponding to signum ==1)
-
PR: https://git.openjdk.java.net/jdk/pull/2471
Re: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v3]
On Thu, 11 Feb 2021 04:09:16 GMT, Stuart Marks wrote:
>> Joe Darcy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix typos in javadoc tags found during review.
>
> src/java.base/share/classes/java/lang/Comparable.java line 68:
>
>> 66: * orderings that are consistent with equals. One exception is
>> 67: * {@link java.math.BigDecimal}, whose {@linkplain
>> java.math.BigDecimal#compareTo natural ordering} equates
>> 68: * {@code BigDecimal} objects with equal numerical values and different
>> representations
>
> Nothing here talks about the representation of BigDecimal. I think it would
> be preferable to say that in BigDecimal, the `equals()` method considers 4.0
> and 4.00 unequal because they have different precisions; however,
> `compareTo()` considers them equal because it considers only their numerical
> values.
In BigDecimal, I'll add a sentence:
" The results of methods like {@link scale} and {@link unscaledValue} will
differ for numerically equal values with different representations."
Talking about "precision" and BigDecimal is more appropriate for pre-JSR 13
BigDecimal since values like zero can have the same precision (1 digit) but
many different scales.
-
PR: https://git.openjdk.java.net/jdk/pull/2471
Re: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8]
On Fri, 12 Feb 2021 21:32:04 GMT, Andrey Turbanov
wrote:
>> ## java/net/MulticastSocket/SetLoopbackMode.java
>>
>> make test
>> TEST="jtreg:test/jdk/java/net/MulticastSocket/SetLoopbackMode.java"
>>
>>
>> STDOUT:
>> IPv6 can be used
>> Default network interface: null
>>
>> Test will use multicast group: /ff01:0:0:0:0:0:0:1
>> NetworkInterface.getByInetAddress(grp): null
>> STDERR:
>> java.net.NoRouteToHostException: No route to host: no further information
>> at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method)
>> at java.base/sun.nio.ch.Net.join6(Net.java:734)
>> at
>> java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515)
>> at
>> java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551)
>> at
>> java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532)
>> at
>> java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479)
>> at
>> java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318)
>> at SetLoopbackMode.main(SetLoopbackMode.java:132)
>> at
>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
>> Method)
>> at
>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>> at
>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>> at
>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> at java.base/java.lang.Thread.run(Thread.java:831)
>>
>> JavaTest Message: Test threw exception: java.net.NoRouteToHostException:
>> No route to host: no further information
>> JavaTest Message: shutting down test
>>
>> STATUS:Failed.`main' threw exception: java.net.NoRouteToHostException:
>> No route to host: no further information
>>
>> Cause looks similar to `MulticastAddresses`: virtualbox network interface:
>> Test: /ff01:0:0:0:0:0:0:1 ni: name:eth10 (VirtualBox Host-Only Ethernet
>> Adapter)
>> joinGroup(InetAddress) Failed: No route to host: no further information
>> Will investigate futher.
>
> ## java/nio/file/Files/CopyAndMove.java
>
> make test TEST="jtreg:java/nio/file/Files/CopyAndMove.java"
>
> STDOUT:
> Seed from RandomFactory = 704532001916725417L
> STDERR:
> dir1:
> f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_nio_file_Files_CopyAndMove_java\tmp\name9678927043623070601
> (NTFS)
> dir2: .\name1900089232270637553 (NTFS)
> java.lang.RuntimeException: AtomicMoveNotSupportedException expected
> at CopyAndMove.testMove(CopyAndMove.java:369)
> at CopyAndMove.main(CopyAndMove.java:74)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> at java.base/java.lang.Thread.run(Thread.java:831)
>
> JavaTest Message: Test threw exception: java.lang.RuntimeException:
> AtomicMoveNotSupportedException expected
> JavaTest Message: shutting down test
>
> STATUS:Failed.`main' threw exception: java.lang.RuntimeException:
> AtomicMoveNotSupportedException expected
>
> Checked in debugger:
>
> Files.getFileStore(dir1) = {WindowsFileStore@1211} "ssd (f:)"
> Files.getFileStore(dir2) = {WindowsFileStore@1213} "ssd (F:)"
> sameDevice = false
>
> https://bugs.openjdk.java.net/browse/JDK-8219644 looks like there is already
> known bug this test.
## java/security/AccessController/DoPrivAccompliceTest.java
make test
TEST="jtreg:java/security/AccessController/DoPrivAccompliceTest.java"
STDOUT:
Adding DoPrivAccomplice.class to
F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar
Created jar file
F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar
Adding DoPrivTest.class to
F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar
Created jar file
Re: RFR: 8261621: Delegate Unicode history from JLS to j.l.Character [v2]
On Fri, 12 Feb 2021 20:29:28 GMT, Joe Darcy wrote: >> This was requested by Alex, and I thought it sounded reasonable and >> informative. I think if an MR upgrades the supported Unicode version, it >> should be listed here. > > Should some acknowledgement be made to the changes in Unicode support done by > the Java SE 8 and Java SE 11 MRs with respect to extensions of the base > Unicode version? I thought about that but decided not to include them here because the changes made in those MRs were not Unicode version upgrades (i.e., version stayed the same). Let me know if you think otherwise. - PR: https://git.openjdk.java.net/jdk/pull/2538
Re: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8]
On Fri, 12 Feb 2021 21:12:14 GMT, Andrey Turbanov wrote: >> ## java/net/MulticastSocket/MulticastAddresses.java >> >> make test >> TEST="jtreg:test/jdk/java/net/MulticastSocket/MulticastAddresses.java" >> >> STDOUT: >> Test: /224.80.80.80 ni: name:eth1 (PANGP Virtual Ethernet Adapter) >> joinGroup(InetAddress) Passed. >> joinGroup(InetAddress,NetworkInterface) Passed. >> Test: /129.1.1.1 >> joinGroup(InetAddress) >> Passed: Not a multicast address >> Test: /ff01:0:0:0:0:0:0:1 ni: name:eth10 (VirtualBox Host-Only Ethernet >> Adapter) >> joinGroup(InetAddress) Failed: No route to host: no further >> information >> Test: /ff02:0:0:0:0:0:0:1234 ni: name:eth10 (VirtualBox Host-Only >> Ethernet Adapter) >> joinGroup(InetAddress) Passed. >> joinGroup(InetAddress,NetworkInterface) Passed. >> Test: /ff05:0:0:0:0:0:0:a ni: name:eth10 (VirtualBox Host-Only Ethernet >> Adapter) >> joinGroup(InetAddress) Passed. >> joinGroup(InetAddress,NetworkInterface) Passed. >> Test: /ff0e:0:0:0:0:0:1234:a ni: name:eth10 (VirtualBox Host-Only >> Ethernet Adapter) >> joinGroup(InetAddress) Passed. >> joinGroup(InetAddress,NetworkInterface) Passed. >> Test: /0:0:0:0:0:0:0:1 >> joinGroup(InetAddress) >> Passed: Not a multicast address >> Test: /0:0:0:0:0:0:8101:101 >> joinGroup(InetAddress) >> Passed: Not a multicast address >> Test: /fe80:0:0:0:a00:20ff:fee5:bc02 >> joinGroup(InetAddress) >> Passed: Not a multicast address >> STDERR: >> java.lang.Exception: 1 test(s) failed - see log file. >> at MulticastAddresses.runTest(MulticastAddresses.java:93) >> at MulticastAddresses.main(MulticastAddresses.java:138) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> at >> com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) >> at java.base/java.lang.Thread.run(Thread.java:831) >> >> JavaTest Message: Test threw exception: java.lang.Exception >> JavaTest Message: shutting down test >> >> >> TEST RESULT: Failed. Execution failed: `main' threw exception: >> java.lang.Exception: 1 test(s) failed - see log file. >> >> >> I connected debbuger and got this stack trace: >> >> java.net.NoRouteToHostException: No route to host: no further information >> at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method) >> at java.base/sun.nio.ch.Net.join6(Net.java:734) >> at >> java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515) >> at >> java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551) >> at >> java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532) >> at >> java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479) >> at >> java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318) >> at MulticastAddresses.runTest(MulticastAddresses.java:56) >> at MulticastAddresses.main(MulticastAddresses.java:138) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> at >> com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) >> at java.base/java.lang.Thread.run(Thread.java:831) >> >> Not sure what actual cause. Will investigate further. > > ## java/net/MulticastSocket/SetLoopbackMode.java > > make test > TEST="jtreg:test/jdk/java/net/MulticastSocket/SetLoopbackMode.java" > > > STDOUT: > IPv6 can be used > Default network interface: null > > Test will use multicast group: /ff01:0:0:0:0:0:0:1 > NetworkInterface.getByInetAddress(grp): null > STDERR: > java.net.NoRouteToHostException: No route to host: no further information > at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method) > at java.base/sun.nio.ch.Net.join6(Net.java:734) > at > java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515) > at >
Re: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8]
On Fri, 12 Feb 2021 21:06:24 GMT, Andrey Turbanov wrote: >> Then I tried to run tests separately: >> ## java/io/File/GetXSpace.java >> >> >> make test TEST="jtreg:test/jdk/java/io/File/GetXSpace.java" >> >> STDERR: >> java.nio.file.InvalidPathException: Illegal char <:> at index 0: : >> at >> java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) >> at >> java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) >> at >> java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) >> at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92) >> at >> java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:230) >> at java.base/java.io.File.toPath(File.java:2316) >> at GetXSpace.compare(GetXSpace.java:219) >> at GetXSpace.testDF(GetXSpace.java:394) >> at GetXSpace.main(GetXSpace.java:428) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> at >> com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) >> at java.base/java.lang.Thread.run(Thread.java:831) >> >> JavaTest Message: Test threw exception: >> java.nio.file.InvalidPathException >> JavaTest Message: shutting down test >> >> STDOUT: >> --- Testing df >> C:/Programs/cygwin64 350809332 172573816 178235516 50% / >> D:3702215676 2812548988 88988 76% >> /cygdrive/d >> E:3906885628 3544182676 362702952 91% >> /cygdrive/e >> F: 250057724 240917056 9140668 97% >> /cygdrive/f >> >> >> SecurityManager = null >> C:/Programs/cygwin64: >> df total= 359228755968 free =0 usable = 182513168384 >> getX total= 359228755968 free = 182513168384 usable = 182513168384 >> :: >> df total= 3791068852224 free =0 usable = 911018688512 >> getX total=0 free =0 usable =0 >> >> TEST RESULT: Failed. Execution failed: `main' threw exception: >> java.nio.file.InvalidPathException: Illegal char <:> at index 0: : >> -- >> >> >> https://bugs.openjdk.java.net/browse/JDK-8251466 looks like there is already >> known bug for similar cygwin output. > > ## java/net/MulticastSocket/MulticastAddresses.java > > make test > TEST="jtreg:test/jdk/java/net/MulticastSocket/MulticastAddresses.java" > > STDOUT: > Test: /224.80.80.80 ni: name:eth1 (PANGP Virtual Ethernet Adapter) > joinGroup(InetAddress) Passed. > joinGroup(InetAddress,NetworkInterface) Passed. > Test: /129.1.1.1 > joinGroup(InetAddress) > Passed: Not a multicast address > Test: /ff01:0:0:0:0:0:0:1 ni: name:eth10 (VirtualBox Host-Only Ethernet > Adapter) > joinGroup(InetAddress) Failed: No route to host: no further > information > Test: /ff02:0:0:0:0:0:0:1234 ni: name:eth10 (VirtualBox Host-Only > Ethernet Adapter) > joinGroup(InetAddress) Passed. > joinGroup(InetAddress,NetworkInterface) Passed. > Test: /ff05:0:0:0:0:0:0:a ni: name:eth10 (VirtualBox Host-Only Ethernet > Adapter) > joinGroup(InetAddress) Passed. > joinGroup(InetAddress,NetworkInterface) Passed. > Test: /ff0e:0:0:0:0:0:1234:a ni: name:eth10 (VirtualBox Host-Only > Ethernet Adapter) > joinGroup(InetAddress) Passed. > joinGroup(InetAddress,NetworkInterface) Passed. > Test: /0:0:0:0:0:0:0:1 > joinGroup(InetAddress) > Passed: Not a multicast address > Test: /0:0:0:0:0:0:8101:101 > joinGroup(InetAddress) > Passed: Not a multicast address > Test: /fe80:0:0:0:a00:20ff:fee5:bc02 > joinGroup(InetAddress) > Passed: Not a multicast address > STDERR: > java.lang.Exception: 1 test(s) failed - see log file. > at MulticastAddresses.runTest(MulticastAddresses.java:93) > at MulticastAddresses.main(MulticastAddresses.java:138) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at
Re: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8]
On Mon, 8 Feb 2021 16:39:55 GMT, Julia Boes wrote: >> The other security-related code changes look good to me. > > I've updated the issue summary to better reflect the changes, the PR summary > should be renamed accordingly. > As mentioned earlier, have you run the tests for the affected areas? Here's > some information on how to do that: > http://openjdk.java.net/guide/#testing-the-jdk I rebased my changes onto master. (commit 837bd8930d0a010110f1318b947c036609d3aa33) and checked tier2 and tier3. What I got: == Test summary == TEST TOTAL PASS FAIL ERROR >> jtreg:test/jdk:tier2 3698 3690 6 2 << >> jtreg:test/langtools:tier2 1211 1 0 << jtreg:test/jaxp:tier2 450 450 0 0 == TEST FAILURE == Test summary == TEST TOTAL PASS FAIL ERROR >> jtreg:test/jdk:tier3 1190 1188 2 0 << jtreg:test/langtools:tier30 0 0 0 jtreg:test/jaxp:tier3 0 0 0 0 == TEST FAILURE Failed tests: tier2: java/io/File/GetXSpace.java Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: : java/net/MulticastSocket/MulticastAddresses.java Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file. java/net/MulticastSocket/SetLoopbackMode.java Failed. Execution failed: `main' threw exception: java.net.NoRouteToHostException: No route to host: no further information java/nio/file/Files/CopyAndMove.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected java/security/AccessController/DoPrivAccompliceTest.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: 'user' found in stderr tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java Failed. Execution failed: `main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS sun/security/tools/jarsigner/TimestampCheck.java Error. Agent error: java.lang.Exception: Agent 72 timed out with a timeout of 2400 seconds; check console log for any additional details sun/security/tools/keytool/DefaultOptions.java Error. Agent error: java.lang.Exception: Agent 77 timed out with a timeout of 480 seconds; check console log for any additional details jdk/jshell/ToolBasicTest.java Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1 tier3: sanity/client/SwingSet/src/SwingSet2DemoTest.java Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1 sanity/client/SwingSet/src/ColorChooserDemoTest.java Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1 - PR: https://git.openjdk.java.net/jdk/pull/1853
Re: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8]
On Fri, 12 Feb 2021 21:04:54 GMT, Andrey Turbanov wrote: >> I rebased my changes onto master. (commit >> 837bd8930d0a010110f1318b947c036609d3aa33) >> and checked tier2 and tier3. >> What I got: >> >> == >> Test summary >> == >>TEST TOTAL PASS FAIL >> ERROR >> >> jtreg:test/jdk:tier2 3698 3690 6 >> 2 << >> >> jtreg:test/langtools:tier2 1211 1 >> 0 << >>jtreg:test/jaxp:tier2 450 450 0 >> 0 >> == >> TEST FAILURE >> >> >> >> >> == >> Test summary >> == >>TEST TOTAL PASS FAIL >> ERROR >> >> jtreg:test/jdk:tier3 1190 1188 2 >> 0 << >>jtreg:test/langtools:tier30 0 0 >> 0 >>jtreg:test/jaxp:tier3 0 0 0 >> 0 >> == >> TEST FAILURE >> >> >> Failed tests: >> >> tier2: >> java/io/File/GetXSpace.java >> Failed. Execution failed: `main' threw >> exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: : >> java/net/MulticastSocket/MulticastAddresses.java >> Failed. Execution failed: `main' threw >> exception: java.lang.Exception: 1 test(s) failed - see log file. >> java/net/MulticastSocket/SetLoopbackMode.java >> Failed. Execution failed: `main' threw >> exception: java.net.NoRouteToHostException: No route to host: no further >> information >> java/nio/file/Files/CopyAndMove.java >> Failed. Execution failed: `main' threw >> exception: java.lang.RuntimeException: AtomicMoveNotSupportedException >> expected >> java/security/AccessController/DoPrivAccompliceTest.java >> Failed. Execution failed: `main' threw >> exception: java.lang.RuntimeException: 'user' found in stderr >> tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java >> Failed. Execution failed: `main' threw >> exception: jdk.jpackage.test.Functional$ExceptionBox: >> java.lang.RuntimeException: 2 FAILED TESTS >> >> sun/security/tools/jarsigner/TimestampCheck.java >> Error. Agent error: java.lang.Exception: Agent >> 72 timed out with a timeout of 2400 seconds; check console log for any >> additional details >> sun/security/tools/keytool/DefaultOptions.java >> Error. Agent error: java.lang.Exception: Agent >> 77 timed out with a timeout of 480 seconds; check console log for any >> additional details >> >> jdk/jshell/ToolBasicTest.java Failed. >> Execution failed: `main' threw exception: java.lang.Exception: failures: 1 >> >> tier3: >> sanity/client/SwingSet/src/SwingSet2DemoTest.java >>Failed. Execution failed: `main' >> threw exception: java.lang.Exception: failures: 1 >> sanity/client/SwingSet/src/ColorChooserDemoTest.java >>Failed. Execution failed: `main' >> threw exception: java.lang.Exception: failures: 1 > > Then I tried to run tests separately: > ## java/io/File/GetXSpace.java > > > make test TEST="jtreg:test/jdk/java/io/File/GetXSpace.java" > > STDERR: > java.nio.file.InvalidPathException: Illegal char <:> at index 0: : > at > java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) > at > java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) > at > java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) > at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92) > at > java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:230) > at java.base/java.io.File.toPath(File.java:2316) > at GetXSpace.compare(GetXSpace.java:219) > at GetXSpace.testDF(GetXSpace.java:394) > at GetXSpace.main(GetXSpace.java:428) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at >
Re: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8]
On Fri, 12 Feb 2021 21:03:04 GMT, Andrey Turbanov wrote: >> I've updated the issue summary to better reflect the changes, the PR summary >> should be renamed accordingly. >> As mentioned earlier, have you run the tests for the affected areas? Here's >> some information on how to do that: >> http://openjdk.java.net/guide/#testing-the-jdk > > I rebased my changes onto master. (commit > 837bd8930d0a010110f1318b947c036609d3aa33) > and checked tier2 and tier3. > What I got: > > == > Test summary > == >TEST TOTAL PASS FAIL > ERROR > >> jtreg:test/jdk:tier2 3698 3690 6 > 2 << > >> jtreg:test/langtools:tier2 1211 1 > 0 << >jtreg:test/jaxp:tier2 450 450 0 > 0 > == > TEST FAILURE > > > > > == > Test summary > == >TEST TOTAL PASS FAIL > ERROR > >> jtreg:test/jdk:tier3 1190 1188 2 > 0 << >jtreg:test/langtools:tier30 0 0 > 0 >jtreg:test/jaxp:tier3 0 0 0 > 0 > == > TEST FAILURE > > > Failed tests: > > tier2: > java/io/File/GetXSpace.java >Failed. Execution failed: `main' threw exception: > java.nio.file.InvalidPathException: Illegal char <:> at index 0: : > java/net/MulticastSocket/MulticastAddresses.java >Failed. Execution failed: `main' threw exception: > java.lang.Exception: 1 test(s) failed - see log file. > java/net/MulticastSocket/SetLoopbackMode.java >Failed. Execution failed: `main' threw exception: > java.net.NoRouteToHostException: No route to host: no further information > java/nio/file/Files/CopyAndMove.java >Failed. Execution failed: `main' threw exception: > java.lang.RuntimeException: AtomicMoveNotSupportedException expected > java/security/AccessController/DoPrivAccompliceTest.java >Failed. Execution failed: `main' threw exception: > java.lang.RuntimeException: 'user' found in stderr > tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java >Failed. Execution failed: `main' threw exception: > jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 > FAILED TESTS > > sun/security/tools/jarsigner/TimestampCheck.java >Error. Agent error: java.lang.Exception: Agent 72 > timed out with a timeout of 2400 seconds; check console log for any > additional details > sun/security/tools/keytool/DefaultOptions.java >Error. Agent error: java.lang.Exception: Agent 77 > timed out with a timeout of 480 seconds; check console log for any additional > details > > jdk/jshell/ToolBasicTest.java Failed. > Execution failed: `main' threw exception: java.lang.Exception: failures: 1 > > tier3: > sanity/client/SwingSet/src/SwingSet2DemoTest.java > Failed. Execution failed: `main' > threw exception: java.lang.Exception: failures: 1 > sanity/client/SwingSet/src/ColorChooserDemoTest.java > Failed. Execution failed: `main' > threw exception: java.lang.Exception: failures: 1 Then I tried to run tests separately: ## java/io/File/GetXSpace.java make test TEST="jtreg:test/jdk/java/io/File/GetXSpace.java" STDERR: java.nio.file.InvalidPathException: Illegal char <:> at index 0: : at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92) at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:230) at java.base/java.io.File.toPath(File.java:2316) at GetXSpace.compare(GetXSpace.java:219) at GetXSpace.testDF(GetXSpace.java:394) at GetXSpace.main(GetXSpace.java:428) at
Re: RFR: 8261621: Delegate Unicode history from JLS to j.l.Character [v2]
On Fri, 12 Feb 2021 17:03:57 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/lang/Character.java line 86: >> >>> 84: * Unicode 10.0 >>> 85: * Java SE 9 >>> 86: * Unicode 8.0 >> >> Do we really need the history in the API docs? Will will update this table >> if there is a MR of the JSR for Java 8 that moves to a new Unicode release? > > This was requested by Alex, and I thought it sounded reasonable and > informative. I think if an MR upgrades the supported Unicode version, it > should be listed here. Should some acknowledgement be made to the changes in Unicode support done by the Java SE 8 and Java SE 11 MRs with respect to extensions of the base Unicode version? - PR: https://git.openjdk.java.net/jdk/pull/2538
Re: RFR: 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview [v7]
> Hi, > > Could someone please review my changeset for JDK-8252399: 'Update mapMulti > documentation to use type test pattern instead of instanceof once JEP 375 > exits preview' ? > > This change updates the example code displayed in the API documentation for > mapMulti to use the type test pattern introduced in > [JEP375](https://openjdk.java.net/jeps/375). > > Kind regards, > Patrick Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: 8252399: Converted JavadocExamples to test - Changes: - all: https://git.openjdk.java.net/jdk/pull/2544/files - new: https://git.openjdk.java.net/jdk/pull/2544/files/2429e4f7..47dd74df Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2544=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2544=05-06 Stats: 33 lines in 2 files changed: 15 ins; 6 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/2544.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2544/head:pull/2544 PR: https://git.openjdk.java.net/jdk/pull/2544
Re: RFR: 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview [v6]
> Hi, > > Could someone please review my changeset for JDK-8252399: 'Update mapMulti > documentation to use type test pattern instead of instanceof once JEP 375 > exits preview' ? > > This change updates the example code displayed in the API documentation for > mapMulti to use the type test pattern introduced in > [JEP375](https://openjdk.java.net/jeps/375). > > Kind regards, > Patrick Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8252399 - 825399: Added wildcard to Iterable - Merge remote-tracking branch 'origin/master' into JDK-8252399 - 8252399: Added more appropriate test stream for Expand Iterable example - 8252399: Corrected Expand Iterable Example - 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview - Changes: - all: https://git.openjdk.java.net/jdk/pull/2544/files - new: https://git.openjdk.java.net/jdk/pull/2544/files/80056650..2429e4f7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2544=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2544=04-05 Stats: 736 lines in 25 files changed: 669 ins; 31 del; 36 mod Patch: https://git.openjdk.java.net/jdk/pull/2544.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2544/head:pull/2544 PR: https://git.openjdk.java.net/jdk/pull/2544
Re: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached
On Wed, 10 Feb 2021 14:08:22 GMT, PROgrm_JARvis wrote: >>> Hi Claes, >>> Would flattening the state of MD5 bring any further improvements? >>> [plevart@92bf48f](https://github.com/plevart/jdk/commit/92bf48ff58f0ce9648e49466dbf1befebbf49083) >> >> I think it might, marginally, but it seemed to me that the implCompress0 MD5 >> intrinsic is using `state` so I've not tried that yet since rewriting and >> checking the intrinsic code is a lot of work. (I've blogged about my >> experiments in this area and mentioned this issue in passing: >> https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html#accidental-constraints) > >> >> >> @JarvisCraft This pull request has been inactive for more than 4 weeks and >> will be automatically closed if another 4 weeks passes without any activity. >> To avoid this, simply add a new comment to the pull request. Feel free to >> ask for assistance if you need help with progressing this pull request >> towards integration! @JarvisCraft Can you re-run your benchmarks in light of the changes that @cl4es pointed out in the previous comment? We think this PR can be closed. - PR: https://git.openjdk.java.net/jdk/pull/1821
Re: RFR: 6594730: UUID.getVersion() is only meaningful for Leach-Salz variant
On Fri, 15 Jan 2021 07:14:49 GMT, Richard Fussenegger wrote: >> Often an enhancement is created when there's an idea of an improvement but >> no resources to do the research and develop a justification. That work has >> to be done when someone has time. Usually ideas are discussed on one of the >> many OpenJDK email aliases to validate the idea and the approach before >> developing the code. See the list of OpenJDK Mail lists for details. >> https://mail.openjdk.java.net/mailman/listinfo >> As for moving to GitHub, it was in part to make it easier to collaborate on >> the development but also to move from Mercurial to Git. >> But GitHub does not replace the need for discussion on the Email Lists. > > Active Active - PR: https://git.openjdk.java.net/jdk/pull/1467
Re: RFR: 8247918: Clarify Reader.skip behavior for end of stream [v2]
I would be all right with that. > On Feb 12, 2021, at 9:45 AM, liach > wrote: > > On Fri, 12 Feb 2021 16:11:58 GMT, Roger Riggs wrote: > >>> Brian Burkhalter has updated the pull request incrementally with one >>> additional commit since the last revision: >>> >>> 8247918: Change'ns' to 'n' in the skip doc >> >> The use of @ inheritdoc causes some unexpected changes in the javadoc, >> dropping the skip method from several classes. > > I personally suggest moving this clarification into a separate paragraph as > opposed to appending it to the first sentence. > > - > > PR: https://git.openjdk.java.net/jdk/pull/2274
Re: RFR: 8247918: Clarify Reader.skip behavior for end of stream [v2]
On Fri, 12 Feb 2021 16:11:58 GMT, Roger Riggs wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8247918: Change'ns' to 'n' in the skip doc > > The use of @ inheritdoc causes some unexpected changes in the javadoc, > dropping the skip method from several classes. I personally suggest moving this clarification into a separate paragraph as opposed to appending it to the first sentence. - PR: https://git.openjdk.java.net/jdk/pull/2274
Integrated: 8261160: Add a deserialization JFR event
On Tue, 9 Feb 2021 12:35:27 GMT, Chris Hegarty wrote: > This issue adds a new event to improve diagnostic information of Java > deserialization. The event captures the details of deserialization activity > from ObjectInputStream. The event details are similar to that of the serial > filter, but is agnostic of whether a filter is installed or not. The event > also captures the filter status, if there is one. This pull request has now been integrated. Changeset: 3dc6f52a Author:Chris Hegarty URL: https://git.openjdk.java.net/jdk/commit/3dc6f52a Stats: 620 lines in 12 files changed: 598 ins; 5 del; 17 mod 8261160: Add a deserialization JFR event Co-authored-by: Sean Coffey Co-authored-by: Chris Hegarty Reviewed-by: coffeys, rriggs, dfuchs, egahlin - PR: https://git.openjdk.java.net/jdk/pull/2479
Re: RFR: 8247918: Clarify Reader.skip behavior for end of stream [v3]
> Please review this clarification of the specification of the method > `skip(long)` in `java.io.Reader` and its subclasses. Specifically, the > behavior of the method is made clear for the case when the `Reader` is > already at the end of its stream when the method is invoked. A corresponding > CSR will be filed. Also, the change includes an update to an existing test in > order to verify that the specification change reflects actual behavior. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8247918: Remove verbiage describing impossible behavior in CharArrayReader and StringReader - Changes: - all: https://git.openjdk.java.net/jdk/pull/2274/files - new: https://git.openjdk.java.net/jdk/pull/2274/files/2a2ceb41..a33245d3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2274=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2274=01-02 Stats: 17 lines in 2 files changed: 15 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2274.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2274/head:pull/2274 PR: https://git.openjdk.java.net/jdk/pull/2274
Re: RFR: 8261621: Delegate Unicode history from JLS to j.l.Character [v2]
On Fri, 12 Feb 2021 16:13:04 GMT, Alan Bateman wrote: >> Naoto Sato has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Removed empty tag > > src/java.base/share/classes/java/lang/Character.java line 86: > >> 84: * Unicode 10.0 >> 85: * Java SE 9 >> 86: * Unicode 8.0 > > Do we really need the history in the API docs? Will will update this table if > there is a MR of the JSR for Java 8 that moves to a new Unicode release? This was requested by Alex, and I thought it sounded reasonable and informative. I think if an MR upgrades the supported Unicode version, it should be listed here. - PR: https://git.openjdk.java.net/jdk/pull/2538
Re: RFR: 8261160: Add a deserialization JFR event [v5]
On Fri, 12 Feb 2021 16:26:09 GMT, Chris Hegarty wrote: >> This issue adds a new event to improve diagnostic information of Java >> deserialization. The event captures the details of deserialization activity >> from ObjectInputStream. The event details are similar to that of the serial >> filter, but is agnostic of whether a filter is installed or not. The event >> also captures the filter status, if there is one. > > Chris Hegarty has updated the pull request incrementally with one additional > commit since the last revision: > > Split exception into type and message Marked as reviewed by egahlin (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2479
Re: RFR: 8261160: Add a deserialization JFR event [v5]
On Fri, 12 Feb 2021 16:26:09 GMT, Chris Hegarty wrote: >> This issue adds a new event to improve diagnostic information of Java >> deserialization. The event captures the details of deserialization activity >> from ObjectInputStream. The event details are similar to that of the serial >> filter, but is agnostic of whether a filter is installed or not. The event >> also captures the filter status, if there is one. > > Chris Hegarty has updated the pull request incrementally with one additional > commit since the last revision: > > Split exception into type and message Marked as reviewed by dfuchs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2479
Re: RFR: 8261160: Add a deserialization JFR event [v5]
On Fri, 12 Feb 2021 16:26:09 GMT, Chris Hegarty wrote: >> This issue adds a new event to improve diagnostic information of Java >> deserialization. The event captures the details of deserialization activity >> from ObjectInputStream. The event details are similar to that of the serial >> filter, but is agnostic of whether a filter is installed or not. The event >> also captures the filter status, if there is one. > > Chris Hegarty has updated the pull request incrementally with one additional > commit since the last revision: > > Split exception into type and message Marked as reviewed by coffeys (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2479
Integrated: 8253702: BigSur version number reported as 10.16, should be 11.nn
On Thu, 11 Feb 2021 17:14:35 GMT, Roger Riggs wrote: > On Mac Os X, the OSVersionTest detected a difference in the version number > reported in the os.version property > and the version number provided by `sw_vers -productVersion`. > > When the java runtime is built with XCode 11.3, the os.version is reported as > 10.16 > though the current version numbering is 11.nnn. > > The workaround is to derive the os.version number from the > ProductBuildVersion. > When the toolchain is updated to XCode 12.nnn it can be removed. > The workaround is enabled only when the environment variable > SYSTEM_VERSION_COMPAT is unset. > When the SYSTEM_VERSION_COMPAT is set in the environment the version number > is reported as reported by Mac OS X. This pull request has now been integrated. Changeset: 66757750 Author:Roger Riggs URL: https://git.openjdk.java.net/jdk/commit/66757750 Stats: 30 lines in 1 file changed: 22 ins; 2 del; 6 mod 8253702: BigSur version number reported as 10.16, should be 11.nn Reviewed-by: bpb, kcr - PR: https://git.openjdk.java.net/jdk/pull/2530
Re: RFR: 8247918: Clarify Reader.skip behavior for end of stream [v2]
On Fri, 12 Feb 2021 16:03:09 GMT, Roger Riggs wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8247918: Change'ns' to 'n' in the skip doc
>
> src/java.base/share/classes/java/io/LineNumberReader.java line 270:
>
>> 268:
>> 269: /**
>> 270: * {@inheritDoc}
>
> This appears to make the skip method disappear from the LineNumberReader
> javadoc
> and only show up as a method declared in Reader.
Right. This is intended and expected.
> src/java.base/share/classes/java/io/CharArrayReader.java line 149:
>
>> 147:
>> 148: /**
>> 149: * {@inheritDoc}
>
> Using inheritDoc for the exceptions adds several new and irrelevant
> impossible causes to the javadoc.
> " This method will block until some characters are available", etc.
> It also drops the existing "If the stream is closed" condition on @ throws
> IOException.
As above for `StringReader`.
> src/java.base/share/classes/java/io/PushbackReader.java line 257:
>
>> 255:
>> 256: /**
>> 257: * {@inheritDoc}
>
> This appears to make the skip method disappear from the PushbackReader javadoc
> and only show up as a method declared in FilterReader.
This is intended and expected.
> src/java.base/share/classes/java/io/BufferedReader.java line 400:
>
>> 398:
>> 399: /**
>> 400: * {@inheritDoc}
>
> This appears to make the skip method disappear from the BufferedReader javadoc
> and only show up as a method declared in Reader.
This is intended and expected.
-
PR: https://git.openjdk.java.net/jdk/pull/2274
Re: RFR: 8261160: Add a deserialization JFR event [v5]
On Fri, 12 Feb 2021 16:26:09 GMT, Chris Hegarty wrote: >> This issue adds a new event to improve diagnostic information of Java >> deserialization. The event captures the details of deserialization activity >> from ObjectInputStream. The event details are similar to that of the serial >> filter, but is agnostic of whether a filter is installed or not. The event >> also captures the filter status, if there is one. > > Chris Hegarty has updated the pull request incrementally with one additional > commit since the last revision: > > Split exception into type and message Marked as reviewed by rriggs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2479
Re: RFR: 8247918: Clarify Reader.skip behavior for end of stream [v2]
On Fri, 12 Feb 2021 15:51:59 GMT, Roger Riggs wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8247918: Change'ns' to 'n' in the skip doc
>
> src/java.base/share/classes/java/io/StringReader.java line 108:
>
>> 106:
>> 107: /**
>> 108: * {@inheritDoc}
>
> Using inheritDoc for the exceptions adds several new and irrelevant
> impossible causes to the javadoc.
> " This method will block until some characters are available", etc.
Good catch; will fix.
-
PR: https://git.openjdk.java.net/jdk/pull/2274
Re: RFR: 8261160: Add a deserialization JFR event [v4]
On Thu, 11 Feb 2021 16:02:09 GMT, Roger Riggs wrote: >> Chris Hegarty has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Filter **C**onfigured > > Marked as reviewed by rriggs (Reviewer). Speaking to Erik offline, he suggested to split the `exceptionMessage` into `exceptionType` and `exceptionMessage` ( since the code was somewhat overloading the existing Sting field by using toString to force the exception class name and message into a single sting ). While the exceptionXXX field should rarely be non-null, they add very little overhead. - PR: https://git.openjdk.java.net/jdk/pull/2479
Re: RFR: 8261160: Add a deserialization JFR event [v5]
> This issue adds a new event to improve diagnostic information of Java > deserialization. The event captures the details of deserialization activity > from ObjectInputStream. The event details are similar to that of the serial > filter, but is agnostic of whether a filter is installed or not. The event > also captures the filter status, if there is one. Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: Split exception into type and message - Changes: - all: https://git.openjdk.java.net/jdk/pull/2479/files - new: https://git.openjdk.java.net/jdk/pull/2479/files/d764f75f..8cb8f75e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2479=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2479=03-04 Stats: 48 lines in 4 files changed: 34 ins; 6 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/2479.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2479/head:pull/2479 PR: https://git.openjdk.java.net/jdk/pull/2479
Re: RFR: 8261621: Delegate Unicode history from JLS to j.l.Character [v2]
On Fri, 12 Feb 2021 04:06:55 GMT, Naoto Sato wrote: >> Please review this doc fix to j.l.Character, which now includes the table of >> the history of supported Unicode versions. A corresponding CSR will be filed >> accordingly. > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Removed empty tag src/java.base/share/classes/java/lang/Character.java line 86: > 84: * Unicode 10.0 > 85: * Java SE 9 > 86: * Unicode 8.0 Do we really need the history in the API docs? Will will update this table if there is a MR of the JSR for Java 8 that moves to a new Unicode release? - PR: https://git.openjdk.java.net/jdk/pull/2538
Re: RFR: 8247918: Clarify Reader.skip behavior for end of stream [v2]
On Fri, 12 Feb 2021 01:18:53 GMT, Brian Burkhalter wrote:
>> Please review this clarification of the specification of the method
>> `skip(long)` in `java.io.Reader` and its subclasses. Specifically, the
>> behavior of the method is made clear for the case when the `Reader` is
>> already at the end of its stream when the method is invoked. A corresponding
>> CSR will be filed. Also, the change includes an update to an existing test
>> in order to verify that the specification change reflects actual behavior.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8247918: Change'ns' to 'n' in the skip doc
The use of @ inheritdoc causes some unexpected changes in the javadoc, dropping
the skip method from several classes.
src/java.base/share/classes/java/io/StringReader.java line 108:
> 106:
> 107: /**
> 108: * {@inheritDoc}
Using inheritDoc for the exceptions adds several new and irrelevant impossible
causes to the javadoc.
" This method will block until some characters are available", etc.
src/java.base/share/classes/java/io/PushbackReader.java line 257:
> 255:
> 256: /**
> 257: * {@inheritDoc}
This appears to make the skip method disappear from the PushbackReader javadoc
and only show up as a method declared in FilterReader.
src/java.base/share/classes/java/io/LineNumberReader.java line 270:
> 268:
> 269: /**
> 270: * {@inheritDoc}
This appears to make the skip method disappear from the LineNumberReader javadoc
and only show up as a method declared in Reader.
src/java.base/share/classes/java/io/CharArrayReader.java line 149:
> 147:
> 148: /**
> 149: * {@inheritDoc}
Using inheritDoc for the exceptions adds several new and irrelevant impossible
causes to the javadoc.
" This method will block until some characters are available", etc.
It also drops the existing "If the stream is closed" condition on @ throws
IOException.
src/java.base/share/classes/java/io/BufferedReader.java line 400:
> 398:
> 399: /**
> 400: * {@inheritDoc}
This appears to make the skip method disappear from the BufferedReader javadoc
and only show up as a method declared in Reader.
-
PR: https://git.openjdk.java.net/jdk/pull/2274
Integrated: 8260221: java.util.Formatter throws wrong exception for mismatched flags in %% conversion
On Wed, 3 Feb 2021 22:42:00 GMT, Ian Graves wrote: > Updating the specification to reflect well-established behavior in Formatter > when incorrect flags used for `%`. This pull request has now been integrated. Changeset: 350303d4 Author:Ian Graves Committer: Stuart Marks URL: https://git.openjdk.java.net/jdk/commit/350303d4 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8260221: java.util.Formatter throws wrong exception for mismatched flags in %% conversion Reviewed-by: smarks - PR: https://git.openjdk.java.net/jdk/pull/2389
Re: RFR: 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview
On Fri, 12 Feb 2021 11:46:09 GMT, Patrick Concannon
wrote:
> Hi,
>
> Could someone please review my changeset for JDK-8252399: 'Update mapMulti
> documentation to use type test pattern instead of instanceof once JEP 375
> exits preview' ?
>
> This change updates the example code displayed in the API documentation for
> mapMulti to use the type test pattern introduced in
> [JEP375](https://openjdk.java.net/jeps/375).
>
> Kind regards,
> Patrick
> _Mailing list message from [Remi Forax](mailto:fo...@univ-mlv.fr) on
> [core-libs-dev](mailto:core-libs-dev@openjdk.java.net):_
>
> Hi Patrick,
>
> "Iterable" is Ok as runtime type of the classical instanceof but not in a
> type pattern where it is a raw type,
> so
> if (e instanceof Iterable elements) {
> should be
> if (e instanceof Iterable elements) {
>
> regards,
> R?mi
>
> - Mail original -
>
> > De: "Patrick Concannon"
> > ?: "core-libs-dev"
> > Envoy?: Vendredi 12 F?vrier 2021 13:16:00
> > Objet: Re: RFR: 8252399: Update mapMulti documentation to use type test
> > pattern instead of instanceof once JEP 375 exits
> > preview [v3]
Hi Remi,
Well spotted. I've updated that now ... you can view the change here: 8005665
-
PR: https://git.openjdk.java.net/jdk/pull/2544
Re: RFR: 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview [v5]
> Hi, > > Could someone please review my changeset for JDK-8252399: 'Update mapMulti > documentation to use type test pattern instead of instanceof once JEP 375 > exits preview' ? > > This change updates the example code displayed in the API documentation for > mapMulti to use the type test pattern introduced in > [JEP375](https://openjdk.java.net/jeps/375). > > Kind regards, > Patrick Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: 825399: Added wildcard to Iterable - Changes: - all: https://git.openjdk.java.net/jdk/pull/2544/files - new: https://git.openjdk.java.net/jdk/pull/2544/files/f7003778..80056650 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2544=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2544=03-04 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2544.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2544/head:pull/2544 PR: https://git.openjdk.java.net/jdk/pull/2544
Re: RFR: 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview [v4]
> Hi, > > Could someone please review my changeset for JDK-8252399: 'Update mapMulti > documentation to use type test pattern instead of instanceof once JEP 375 > exits preview' ? > > This change updates the example code displayed in the API documentation for > mapMulti to use the type test pattern introduced in > [JEP375](https://openjdk.java.net/jeps/375). > > Kind regards, > Patrick Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8252399 - 8252399: Added more appropriate test stream for Expand Iterable example - 8252399: Corrected Expand Iterable Example - 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview - Changes: - all: https://git.openjdk.java.net/jdk/pull/2544/files - new: https://git.openjdk.java.net/jdk/pull/2544/files/8f8dfe5c..f7003778 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2544=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2544=02-03 Stats: 717 lines in 21 files changed: 651 ins; 20 del; 46 mod Patch: https://git.openjdk.java.net/jdk/pull/2544.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2544/head:pull/2544 PR: https://git.openjdk.java.net/jdk/pull/2544
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
On Thu, 4 Feb 2021 22:49:23 GMT, Gerard Ziemski wrote:
>> Anton Kozlov has updated the pull request incrementally with six additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>> - Add comments to WX transitions
>>
>>+ minor change of placements
>> - Use macro conditionals instead of empty functions
>> - Add W^X to tests
>> - Do not require known W^X state
>> - Revert w^x in gtests
>
> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 297:
>
>> 295: stub = SharedRuntime::handle_unsafe_access(thread, next_pc);
>> 296: }
>> 297: } else if (sig == SIGILL && nativeInstruction_at(pc)->is_stop()) {
>
> Can we add a comment here describing what this case means?
this arm64 specific part came as is from linux_aarch64 and I can't add any
meaning comments here.
> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 302:
>
>> 300: const uint64_t *detail_msg_ptr
>> 301: = (uint64_t*)(pc + NativeInstruction::instruction_size);
>> 302: const char *detail_msg = (const char *)*detail_msg_ptr;
>
> Where is `detail_msg` used?
Came from linux_arm64. was used in os_linux_aarch64.cpp on line 246 in
report_and_die
But became unused on bsd_arm64. I agree this needs to be removed
> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 403:
>
>> 401: }
>> 402:
>> 403: return false; // Mute compiler
>
> Is this comment needed?
this part came as is from linux_aarch64 as well and was supposed to mean
something there.
-
PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR: 8261621: Delegate Unicode history from JLS to j.l.Character [v2]
On Fri, 12 Feb 2021 04:06:55 GMT, Naoto Sato wrote: >> Please review this doc fix to j.l.Character, which now includes the table of >> the history of supported Unicode versions. A corresponding CSR will be filed >> accordingly. > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Removed empty tag The table is informative and should not be construed as specification. The wording "has supported" should be sufficient. - Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2538
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Tue, 2 Feb 2021 22:08:14 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional >> commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 221: > >> 219: assert(sig == info->si_signo, "bad siginfo"); >> 220: } >> 221: */ > > Should this code be deleted? From here and from where it was copied > from if it is also commented out there... Thanks, will fix in bsd_aarch64 soon, as for bsd_x86 I've filled new bug and pr - https://github.com/openjdk/jdk/pull/2547 - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Wed, 3 Feb 2021 09:11:50 GMT, Andrew Haley wrote: >> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 323: >> >>> 321: str(zr, Address(rthread, JavaThread::last_Java_pc_offset())); >>> 322: >>> 323: str(zr, Address(rthread, >>> JavaFrameAnchor::saved_fp_address_offset())); >> >> I don't think this switch from `JavaThread::saved_fp_address_offset()` >> to `JavaFrameAnchor::saved_fp_address_offset()` is correct since >> `rthread` is still used and is a JavaThread*. The new code will give you: >> >> `rthread` + offset of the `saved_fp_address` field in a JavaFrameAnchor >> >> The old code gave you: >> >> `rthread` + offset of the `saved_fp_address` field in the >> JavaFrameAnchor field in the JavaThread >> >> Those are not the same things. > > I agree, I don't understand why this change was made. Wow, this is scary. I don't understand how I've merged JDK-8257882 like this. I've reviewed cpu/aarch64 changes again, there is nothing suspicious besides this. Thank you very much for catching, fixed. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v13]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: JDK-8257882: oops, fixed 7fe50a996b6f436932452d220b351c73153ed945 - Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/0d0e9baf..ad4e4c65 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2200=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2200=11-12 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Tue, 2 Feb 2021 22:14:42 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional >> commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 486: > >> 484: } >> 485: } >> 486: } > > This appears to be a mix for Mavericks (10.9) and 10.12 > work arounds. Is this code needed by this project? I wasn't able to replicate JDK-8020753 and JDK-8186286. So will remove these workaround Gerard, 8020753 was originally your fix, do you know if it still needed on intel-mac ? - PR: https://git.openjdk.java.net/jdk/pull/2200
Integrated: 8252971: WindowsFileAttributes does not know about Unix domain sockets
On Fri, 5 Feb 2021 09:52:11 GMT, Michael McMahon wrote: > Could I get the following change reviewed please? It fixes a problem (in > JEP380) on Windows where some file operations on Unix domain sockets were not > working and led to the feature being disabled on Windows 2019 Server in JDK > 16. So, the fix re-enables the feature on all versions of Windows that > support it. > > The test checks all the file APIs that were affected by the problem. The > change touches the code that handles symbolic links in Windows (since they > are implemented as NTFS reparse points, like Unix sockets), but I didn't add > any specific testing in this area, as I assume the existing unit tests for > NIO symbolic links should cover that. If I should add more tests here, then I > can do that. > > Thanks, > Michael This pull request has now been integrated. Changeset: 9ffabf30 Author:Michael McMahon URL: https://git.openjdk.java.net/jdk/commit/9ffabf30 Stats: 245 lines in 10 files changed: 228 ins; 10 del; 7 mod 8252971: WindowsFileAttributes does not know about Unix domain sockets Reviewed-by: alanb - PR: https://git.openjdk.java.net/jdk/pull/2424
Re: RFR: 8252971: WindowsFileAttributes does not know about Unix domain sockets [v9]
On Thu, 11 Feb 2021 09:19:05 GMT, Michael McMahon wrote: >> Could I get the following change reviewed please? It fixes a problem (in >> JEP380) on Windows where some file operations on Unix domain sockets were >> not working and led to the feature being disabled on Windows 2019 Server in >> JDK 16. So, the fix re-enables the feature on all versions of Windows that >> support it. >> >> The test checks all the file APIs that were affected by the problem. The >> change touches the code that handles symbolic links in Windows (since they >> are implemented as NTFS reparse points, like Unix sockets), but I didn't add >> any specific testing in this area, as I assume the existing unit tests for >> NIO symbolic links should cover that. If I should add more tests here, then >> I can do that. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains 17 additional > commits since the last revision: > > - Merge branch 'master' into 8252971-socket-attributes > - Rearrange test in WindowsPath. Change to Security.java test to explicitly > delete socket files > - Merge branch 'master' into 8252971-socket-attributes > - update > - fix mistake in last push > - update > - Merge branch 'master' into 8252971-socket-attributes > - add specific check for unix domain socket > - Merge branch 'master' into 8252971-socket-attributes > - update > - ... and 7 more: > https://git.openjdk.java.net/jdk/compare/c6c9f6f9...11ae5e72 Thanks for the updates, I think you've got this to a good place now. - Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2424
Re: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection [v4]
On Fri, 12 Feb 2021 10:19:03 GMT, Severin Gehwolf wrote: >> Hi Severin, >> Thanks for doing this! Sorry for taking so long to review this change. The >> change looks good. Before pushing it, could you add a comment explaining >> what the code in lines 185-194 of CgroupSubsystemFactory.java is doing? >> Also, please don't overwrite the fix for JDK-8257746. >> Thanks again! Harold > > Setting reviewers to 2 since I want @gnu-andrew to be OK with it too. Hi Harold, > Thanks for doing this! Sorry for taking so long to review this change. The > change looks good. Thanks for the review! > Before pushing it, could you add a comment explaining what the code in lines > 185-194 of CgroupSubsystemFactory.java is doing? Done. > Also, please don't overwrite the fix for JDK-8257746. AFAIK this patch doesn't touch this code. So this should not happen (overwrite of the fix). FWIW, once this is in I intend to propose a patch which adds a regression test for JDK-8257746. It would depend on this change. Thanks, Severin - PR: https://git.openjdk.java.net/jdk/pull/1393
Re: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection [v5]
> This is an enhancement which solves two issues: > > 1. Multiple reads of relevant cgroup interface files. Now interface files are > only read once per file (just like Hotspot). > 2. Proxies creation of the impl specific subsystem via `determineType()` as > before, but now reads all relevant interface files: `/proc/cgroups`, > `/proc/self/mountinfo` and `/proc/self/cgroup`. Once read it passes the > parsed information to the impl specific subsystem classes for instantiation. > This allows for more flexibility of testing as interface files can be mocked > and, thus, more cases can be tested that way without having access to these > specific systems. For example, proper regression tests for JDK-8217766 and > JDK-8253435 have been added now with this in place. > > * [x] Tested on Linux x86_64 on cgroups v1 and cgroups v2. Container tests > pass. Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Add comment to parsing logic of /proc/self/cgroup - Changes: - all: https://git.openjdk.java.net/jdk/pull/1393/files - new: https://git.openjdk.java.net/jdk/pull/1393/files/9a2d6a20..078e16db Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=1393=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1393=03-04 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1393.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1393/head:pull/1393 PR: https://git.openjdk.java.net/jdk/pull/1393
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Fri, 12 Feb 2021 12:22:44 GMT, Vladimir Kempik wrote: >> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 435: >> >>> 433: //||\ Java thread created by VM does not >>> have glibc >>> 434: //|glibc guard page| - guard, attached Java thread usually >>> has >>> 435: //||/ 1 glibc guard page. >> >> Is this code going to be built by GCC (with glibc) or will only >> macOS compilers and libraries be used? > > only macos comiplers The comment is also wrong for glibc: The AArch64 ABI requires a 64 KiB guard region independently of page size, otherwise `-fstack-clash-protection` is not reliable. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR: 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview [v3]
Hi Patrick,
"Iterable" is Ok as runtime type of the classical instanceof but not in a type
pattern where it is a raw type,
so
if (e instanceof Iterable elements) {
should be
if (e instanceof Iterable elements) {
regards,
Rémi
- Mail original -
> De: "Patrick Concannon"
> À: "core-libs-dev"
> Envoyé: Vendredi 12 Février 2021 13:16:00
> Objet: Re: RFR: 8252399: Update mapMulti documentation to use type test
> pattern instead of instanceof once JEP 375 exits
> preview [v3]
>> Hi,
>>
>> Could someone please review my changeset for JDK-8252399: 'Update mapMulti
>> documentation to use type test pattern instead of instanceof once JEP 375
>> exits
>> preview' ?
>>
>> This change updates the example code displayed in the API documentation for
>> mapMulti to use the type test pattern introduced in
>> [JEP375](https://openjdk.java.net/jeps/375).
>>
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one
> additional
> commit since the last revision:
>
> 8252399: Added more appropriate test stream for Expand Iterable example
>
> -
>
> Changes:
> - all: https://git.openjdk.java.net/jdk/pull/2544/files
> - new: https://git.openjdk.java.net/jdk/pull/2544/files/1b8ca544..8f8dfe5c
>
> Webrevs:
> - full: https://webrevs.openjdk.java.net/?repo=jdk=2544=02
> - incr: https://webrevs.openjdk.java.net/?repo=jdk=2544=01-02
>
> Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
> Patch: https://git.openjdk.java.net/jdk/pull/2544.diff
> Fetch: git fetch https://git.openjdk.java.net/jdk pull/2544/head:pull/2544
>
> PR: https://git.openjdk.java.net/jdk/pull/2544
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Thu, 4 Feb 2021 22:54:42 GMT, Gerard Ziemski wrote:
>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 363:
>>
>>> 361: address pc = os::Posix::ucontext_get_pc(uc);
>>> 362:
>>> 363: if (pc != addr && uc->context_esr == 0x924F) { //TODO: figure
>>> out what this value means
>>
>> Is this TODO going to be resolved by this port?
>
> Where did this come from - some snippet/example/tech note code? Maybe other
> people can help figure it out if we provide more info.
This is the version of w^x on-demand switch implemented by microsoft guys. This
is enabled only for debug builds.
@lewurm could you comment here please
-
PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Tue, 2 Feb 2021 22:12:07 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional >> commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 435: > >> 433: //||\ Java thread created by VM does not >> have glibc >> 434: //|glibc guard page| - guard, attached Java thread usually >> has >> 435: //||/ 1 glibc guard page. > > Is this code going to be built by GCC (with glibc) or will only > macOS compilers and libraries be used? only macos comiplers - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR: 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview [v3]
> Hi, > > Could someone please review my changeset for JDK-8252399: 'Update mapMulti > documentation to use type test pattern instead of instanceof once JEP 375 > exits preview' ? > > This change updates the example code displayed in the API documentation for > mapMulti to use the type test pattern introduced in > [JEP375](https://openjdk.java.net/jeps/375). > > Kind regards, > Patrick Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: 8252399: Added more appropriate test stream for Expand Iterable example - Changes: - all: https://git.openjdk.java.net/jdk/pull/2544/files - new: https://git.openjdk.java.net/jdk/pull/2544/files/1b8ca544..8f8dfe5c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2544=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2544=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2544.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2544/head:pull/2544 PR: https://git.openjdk.java.net/jdk/pull/2544
Re: RFR: 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview [v2]
> Hi, > > Could someone please review my changeset for JDK-8252399: 'Update mapMulti > documentation to use type test pattern instead of instanceof once JEP 375 > exits preview' ? > > This change updates the example code displayed in the API documentation for > mapMulti to use the type test pattern introduced in > [JEP375](https://openjdk.java.net/jeps/375). > > Kind regards, > Patrick Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: 8252399: Corrected Expand Iterable Example - Changes: - all: https://git.openjdk.java.net/jdk/pull/2544/files - new: https://git.openjdk.java.net/jdk/pull/2544/files/39261213..1b8ca544 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2544=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2544=00-01 Stats: 12 lines in 1 file changed: 4 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/2544.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2544/head:pull/2544 PR: https://git.openjdk.java.net/jdk/pull/2544
Re: RFR: 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview [v2]
On Fri, 12 Feb 2021 11:54:30 GMT, Daniel Fuchs wrote:
>> Patrick Concannon has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8252399: Corrected Expand Iterable Example
>
> test/jdk/java/util/stream/examples/JavadocExamples.java line 59:
>
>> 57: }
>> 58: }
>> 59: private void expandIterable(Object o, Consumer c) { }
>
> It would be better to keep the second example in its original form: with
> class C ... etc.
Corrected this now. See 1b8ca54
-
PR: https://git.openjdk.java.net/jdk/pull/2544
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Tue, 2 Feb 2021 22:07:15 GMT, Daniel D. Daugherty wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> support macos_aarch64 in hsdis
>
> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 195:
>
>> 193: frame os::get_sender_for_C_frame(frame* fr) {
>> 194: return frame(fr->link(), fr->link(), fr->sender_pc());
>> 195: }
>
> Is this file going to be built by GCC or just macOS compilers?
there is no support for compiling java with gcc on macos since about jdk11,
only clang.
considering this and the absence of gcc for macos_m1, the answer is - just
macOS compilers.
-
PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR: 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview
On Fri, 12 Feb 2021 11:46:09 GMT, Patrick Concannon
wrote:
> Hi,
>
> Could someone please review my changeset for JDK-8252399: 'Update mapMulti
> documentation to use type test pattern instead of instanceof once JEP 375
> exits preview' ?
>
> This change updates the example code displayed in the API documentation for
> mapMulti to use the type test pattern introduced in
> [JEP375](https://openjdk.java.net/jeps/375).
>
> Kind regards,
> Patrick
test/jdk/java/util/stream/examples/JavadocExamples.java line 59:
> 57: }
> 58: }
> 59: private void expandIterable(Object o, Consumer c) { }
It would be better to keep the second example in its original form: with class
C ... etc.
-
PR: https://git.openjdk.java.net/jdk/pull/2544
RFR: 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview
Hi, Could someone please review my changeset for JDK-8252399: 'Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview' ? This change updates the example code displayed in the API documentation for mapMulti to use the type test pattern introduced in [JEP375](https://openjdk.java.net/jeps/375). Kind regards, Patrick - Commit messages: - 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview Changes: https://git.openjdk.java.net/jdk/pull/2544/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2544=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252399 Stats: 68 lines in 2 files changed: 64 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2544.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2544/head:pull/2544 PR: https://git.openjdk.java.net/jdk/pull/2544
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
On Thu, 4 Feb 2021 21:59:02 GMT, Gerard Ziemski wrote:
>> Anton Kozlov has updated the pull request incrementally with six additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>> - Add comments to WX transitions
>>
>>+ minor change of placements
>> - Use macro conditionals instead of empty functions
>> - Add W^X to tests
>> - Do not require known W^X state
>> - Revert w^x in gtests
>
> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 194:
>
>> 192: // may get turned off by -fomit-frame-pointer.
>> 193: frame os::get_sender_for_C_frame(frame* fr) {
>> 194: return frame(fr->link(), fr->link(), fr->sender_pc());
>
> Why is it
>
> return frame(fr->link(), fr->link(), fr->sender_pc());
>
> and not
>
> return frame(fr->sender_sp(), fr->link(), fr->sender_pc());
>
> like in the bsd-x86 counter part?
bsd_aarcb64 was based on linux_aarch64, with addition of bsd-specific things
from bsd_x86
You think the bsd-x86 is better here ?
-
PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR: JDK-8261422: Adjust problematic String.format calls in jdk/internal/util/Preconditions.java outOfBoundsMessage
On Tue, 9 Feb 2021 14:33:22 GMT, Matthias Baesken wrote: > JDK-8261422: Adjust problematic String.format calls in > jdk/internal/util/Preconditions.java outOfBoundsMessage As we're potentially formatting any "Number" type here, theoretically floats could be passed which would result in an Exception. In fact, only decimal types are passed by the callers so this should not happen. Unfortunately there's no super type specifying decimal numbers. And as we're not doing some fancy formatting but just %d, I think replacing this with %s should be ok. - Marked as reviewed by clanger (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2483
Re: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection [v4]
On Thu, 11 Feb 2021 19:51:43 GMT, Harold Seigel wrote: >> Severin Gehwolf has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains seven additional >> commits since the last revision: >> >> - Fix jcheck >> - Add documentation and reduce code running in the critical section >> - Add some documentation >> - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics >> - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics >> - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics >> - 8254001: [Metrics] Enhance parsing of cgroup interface files for version >> detection > > Hi Severin, > Thanks for doing this! Sorry for taking so long to review this change. The > change looks good. Before pushing it, could you add a comment explaining > what the code in lines 185-194 of CgroupSubsystemFactory.java is doing? > Also, please don't overwrite the fix for JDK-8257746. > Thanks again! Harold Setting reviewers to 2 since I want @gnu-andrew to be OK with it too. - PR: https://git.openjdk.java.net/jdk/pull/1393
Re: RFR: 4926314: Optimize Reader.read(CharBuffer) [v3]
On Wed, 10 Feb 2021 21:58:02 GMT, Brian Burkhalter wrote: >> That would be possible. It would help in cases where a large Reader is read >> into one or several relatively small off-heap CharBuffers, requiring >> multiple #read calls. This can only be done when the caller is able to work >> with only a partial input. I don't know how common this case is. >> >> We could re-purpose #skipBuffer, it has the same maximum size (8192) but >> determined by a different constant (#maxSkipBufferSize instead of >> #TRANSFER_BUFFER_SIZE). That would likely require it to be renamed and maybe >> we should even remove #maxSkipBufferSize. We could also do the reallocation >> and growing similar as is currently done in #skip. > > Perhaps a static final `WORK_BUFFER_SIZE` could be added with value 8192 and > `maxSkipBufferSize` and `TRANSFER_BUFFER_SIZE` replaced with that? Then > `skipBuffer` could be renamed to `workBuffer` and used in both > `read(CharBuffer)` and `skip(long)`. That shouldn't be a problem as both uses > are in synchronized blocks. Also I suggest putting the declaration of > `workBuffer` just below that of `lock` instead of lower down the file where > `skipBuffer` is. > > Lastly you mentioned C-style array declarations like `char buf[]`. As there > are only four of these in the file it might be good to just go ahead and > change them, I don't think that adds much noise or risk. Done. I left #transferTo(Writer) untouched for now. Firstly it is not already behind a synchronized. Secondly it writes so there is no need for repeated calls. - PR: https://git.openjdk.java.net/jdk/pull/1915
Re: RFR: 4926314: Optimize Reader.read(CharBuffer) [v7]
> Implement three optimiztations for Reader.read(CharBuffer) > > * Add a code path for heap buffers in Reader#read to use the backing array > instead of allocating a new one. > * Change the code path for direct buffers in Reader#read to limit the > intermediate allocation to `TRANSFER_BUFFER_SIZE`. > * Implement `InputStreamReader#read(CharBuffer)` and delegate to > `StreamDecoder`. > * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation. Philippe Marschall has updated the pull request incrementally with two additional commits since the last revision: - Replace c-style array declarations - Share work buffer between #skip and #read - Changes: - all: https://git.openjdk.java.net/jdk/pull/1915/files - new: https://git.openjdk.java.net/jdk/pull/1915/files/08948f93..fc29f3e6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=1915=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1915=05-06 Stats: 28 lines in 1 file changed: 8 ins; 6 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/1915.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1915/head:pull/1915 PR: https://git.openjdk.java.net/jdk/pull/1915
