Re: RFR: 8260592: jpackage tests fail when Desktop is not supported [v2]
On Fri, 29 Jan 2021 01:13:30 GMT, Alexander Matveev wrote: >> Duplicated messages are not much help in understanding control flow. I'd >> change the new message or merge conditions. Whatever you prefer. > > It is fine with me to have two separate messages for display and desktop, but > it is better to move this check to top of function after if > (GraphicsEnvironment.isHeadless()). No point to execute other code. Okay, I moved the check upwards. The trace message is left intact. Note it says "desktop", there, so it is not a duplicate message. - PR: https://git.openjdk.java.net/jdk/pull/2291
Re: RFR: 8260592: jpackage tests fail when Desktop is not supported [v2]
> If you run x86 configuration (cross-compiled on x86_64), then many tests > would fail with: > > $ CONF=linux-x86-server-fastdebug make images run-test TEST=tools/jpackage > ... > can not load libgnomevfs-2.so > Exception in thread "main" java.lang.ExceptionInInitializerError > Caused by: java.lang.UnsupportedOperationException: Desktop API is not > supported on the current platform > at java.desktop/java.awt.Desktop.getDesktop(Unknown Source) > at com.that/com.that.main.Florence.createInstance(Unknown Source) > at com.that/com.that.main.Florence.(Unknown Source) > Failed to launch JVM > java.lang.AssertionError: Expected [0]. Actual [1]: Check command > [/home/shade/trunks/jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_jdk_tools_jpackage/scratch/10/./testMainLauncherIsModular.ed4f638d/output/MainLauncherIsModularAddLauncherTest/bin/ModularAppLauncher](1) > exited with 0 code > > The tests probably need to check `Desktop.isDesktopSupported()`, similarly > how they check `GraphicsEnvironment.isHeadless()`. > > Additional testing: > - [x] Linux x86_32 `tools/jpackage` (now pass) > - [x] Linux x86_64 `tools/jpackage` (still pass) Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: - Reinstate trace message - Move check higher - Changes: - all: https://git.openjdk.java.net/jdk/pull/2291/files - new: https://git.openjdk.java.net/jdk/pull/2291/files/c0975ae3..ddf28110 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2291=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2291=00-01 Stats: 12 lines in 1 file changed: 6 ins; 6 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2291.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2291/head:pull/2291 PR: https://git.openjdk.java.net/jdk/pull/2291
Re: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap dump [v13]
On Fri, 29 Jan 2021 05:33:19 GMT, Serguei Spitsyn wrote:
> You are right.
> So, in my suggestion just replace this block:
>
> ```
> if (gzlevel <= 0 || gzlevel > 9) {
> err.println("Invalid "gz=" option: " + option);
> usage();
> return;
> }
> ```
>
> with:
>
> ```
> if (gzlevel == 0) {
> usage();
> return;
> }
> ```
Thanks, just found there can be two prints of same error for option like gz=abc,
I will change back:)
-
PR: https://git.openjdk.java.net/jdk/pull/1712
Re: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap dump [v13]
On Fri, 29 Jan 2021 05:14:31 GMT, Lin Zang wrote:
>> Hi Lin,
>>
>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java
>>
>> Thank you for the update.
>>
>> The list of possible commands must include one more variant with no
>> arguments:
>> + * Possible command:
>> + * dumpheap gz=1 file;
>> + * dumpheap gz=1;
>> + * dumpheap file;
>> + * dumpheap
>>
>> The argument processing is still not right.
>> Why are there no checks for gzlevel < 0 and gzlevel > 9 ?
>>
>> I'd suggest the following refactoring below:
>>
>>/*
>> * Possible commands:
>> * dumpheap gz=1 file
>> * dumpheap gz=1
>> * dumpheap file
>> * dumpheap
>> *
>> * Use default filename if cntTokens == 0.
>> * Handle cases with cntTokens == 1 or 2.
>> */
>>
>> if (cntTokens > 2) {
>> err.println("Too big number of options: " +
>> cntTokens);
>> usage();
>> return;
>> }
>> if (cntTokens >= 1) { // parse first argument which is
>> "gz=" option
>> String option = t.nextToken();
>> gzlevel = parseHeapDumpCompressionLevel(option);
>> if (gzlevel <= 0 || gzlevel > 9) {
>> err.println("Invalid "gz=" option: " + option);
>> usage();
>> return;
>> }
>> filename = "heap.bin.gz";
>> }
>> if (cntTokens == 2) { // parse second argument which is
>> filename
>> filename = t.nextToken();
>> if (filename.startsWith("gz=")) {
>> err.println("Filename should not start with
>> "gz=": " + filename);
>> usage();
>> return;
>> }
>> }
>
> Hi @sspitsyn,
> Thanks for your suggestion, the parseHeapDumpCompresslevel() inside tested
> the gzlevel, but I think your code is much reasonable. I will make it in next
> update.
> BRs,
> Lin
You are right.
So, in my suggestion just replace this block:
if (gzlevel <= 0 || gzlevel > 9) {
err.println("Invalid "gz=" option: " + option);
usage();
return;
}
with:
if (gzlevel == 0) {
usage();
return;
}
-
PR: https://git.openjdk.java.net/jdk/pull/1712
Re: RFR: JDK-8257086: Clarify differences between {Float, Double}.equals and ==
Hi Stuart, On 1/28/2021 7:19 PM, Stuart Marks wrote: On Thu, 28 Jan 2021 07:15:05 GMT, Joe Darcy wrote: Great, let me know if you'd like me to provide some text for any particular topics in this area. Great, let me know if you'd like me to provide some text for any particular topics in this area. Before sending out another iteration in code, there the draft javadoc text of a discussion at the end of the class-level discussion of java.lang.Double: [snip] Comments? Thanks, I took the liberty of making an editing pass over the proposed text. Along with a few editorial and markup adjustments, the key changes are as follows: 1) I moved discussion of interaction with Set and Map to the end, after all the issues have been set up. 2) I added the concept of substitution alongside the equivalence relation. AFAIK substitution (or substitutability) is not part of an equivalence relation, but it seems that in many systems, equivalence implies substitutability. Of course, the point is that it _doesn't_ apply for -0.0 and +0.0. Yes; substitutability was an implicit concept in the earlier write-up; it is an improvement to call it out my name. I'll work on integrating this version into an update of the PR with references from the equals and compareTo methods, etc. Thanks, -Joe - PR: https://git.openjdk.java.net/jdk/pull/1699
Re: RFR: JDK-8257086: Clarify differences between {Float, Double}.equals and ==
On Thu, 28 Jan 2021 07:15:05 GMT, Joe Darcy wrote:
>> Great, let me know if you'd like me to provide some text for any particular
>> topics in this area.
>
>>
>>
>> Great, let me know if you'd like me to provide some text for any particular
>> topics in this area.
>
> Before sending out another iteration in code, there the draft javadoc text of
> a discussion at the end of the class-level discussion of java.lang.Double:
>
> * Floating-point Equality, Equivalence,
> * and Comparison
> *
> * IEEE 754 floating-point values include finite nonzero values,
> * signed zeros ({@code +0.0} and {@code -0.0}), signed infinities
> * {@linkplain Double#POSITIVE_INFINITY positive infinity} and
> * {@linkplain Double#NEGATIVE_INFINITY negative infinity}), and
> * {@linkplain Double#NaN NaN} (not-a-number).
> *
> * An equivalence relation on a set of values is a boolean
> * relation on pairs of values that is reflexive, symmetric, and
> * transitive. A set can have multiple equivalence relations defined
> * for it. For example, {@link java.util.HashMap HashMap} compares
> * keys in the set of objects using the equivalence relation of {@link
> * Object#equals Object.equals} while {@link java.util.IdentityHashMap
> * IdentityHashMap} compares keys in the set of objects using the
> * equivalence relation of reference equality.
> *
> * For floating-point values to be used in data structures like
> * sets and maps, the {@linkplain Double#equals equals} or {@linkplain
> * Double#compareTo comparison} method must satisfy the usual
> * requirements of being an equivalence relation or analogous
> * requirement for comparison methods. However, surprisingly, the
> * built-in {@code ==} operation on floating-point values does
> * not implement an equivalence relation. Despite not
> * defining an equivalence relation, the semantics of the IEEE 754
> * {@code ==} operator were deliberately designed to meet other needs
> * of numerical computation. There are two exceptions where the
> * properties of an equivalence relations are not satisfied by {@code
> * ==} on floating-point values:
> *
> *
> *
> * If {@code v1} and {@code v2} are both NaN, then {@code v1
> * == v2} has the value {@code false}. Therefore, for two NaN
> * arguments the reflexive property of an equivalence
> * relation is not satisfied by the {@code ==} operator.
> *
> * If {@code v1} represents {@code +0.0} while {@code v2}
> * represents {@code -0.0}, or vice versa, then {@code v1 == v2} has
> * the value {@code true} even though {@code +0.0} and {@code -0.0}
> * are distinguishable under various floating-point operations. For
> * example, {@code 1.0/+0.0} evaluates to positive infinity while
> * {@code 1.0/-0.0} evaluates to negative infinity and
> * positive infinity and negative infinity are neither equal to each
> * other nor equivalent to each other.
> *
> *
> *
> * For ordered comparisons using the built-in comparison operator
> * ({@code <}, {@code <=}, etc.), NaN values have another anomalous
> * situation: a NaN is neither less than, greater than, nor equal to
> * any value, including itself. This means the trichotomy of
> * comparison does not hold.
> *
> * To provide the appropriate semantics for {@code equals} and {@code
> * compareTo} methods, those methods cannot simply to wrappers around
> * {@code ==} or ordered comparison operations. Instead, {@link
> * Double#equals equals} defines NaN arguments to be equal to each
> * other and defines {@code +0.0} to not be equal to {@code
> * -0.0}, restoring reflexivity. For comparisons, {@link
> * Double#compareTo compareTo} defines a total order where {@code
> * -0.0} is less than {@code +0.0} and where a NaN is equal to itself
> * and considered greater than positive infinity.
> *
> * The operational semantics of {@code equals} and {@code
> * compareTo} are expressed in terms of {@linkplain doubleToLongBigs
> * bit-wise converting} the floating-point values to integral values
> *
> * The natural ordering implemented by {@link compareTo
> * compareTo} is {@linkplain Comparable consistent with equals}; that
> * is values are only reported as equal by {@code equals} if {@code
> * compareTo} on those objects returns zero.
> *
> * @jls 4.2.3 Floating-Point Types, Formats, and Values
> * @jls 4.2.4. Floating-Point Operations
> * @jls 15.21.1 Numerical Equality Operators == and !=
>
> Comments?
>
> Thanks,
I took the liberty of making an editing pass over the proposed text. Along with
a few editorial and markup adjustments, the key changes are as follows:
1) I moved discussion of interaction with Set and Map to the end, after all the
issues have been set up.
2) I added the concept of substitution alongside the equivalence relation.
AFAIK substitution (or substitutability) is not part of an equivalence
relation, but it seems that in many systems, equivalence implies
substitutability. Of course, the point is that it
Re: RFR: 8260592: jpackage tests fail when Desktop is not supported
On Thu, 28 Jan 2021 23:41:44 GMT, Alexey Semenyuk wrote: >> I would prefer to have separate messages for "headless" and "desktop >> capable". I can merge these, if you insist. > > Duplicated messages are not much help in understanding control flow. I'd > change the new message or merge conditions. Whatever you prefer. It is fine with me to have two separate messages for display and desktop, but it is better to move this check to top of function after if (GraphicsEnvironment.isHeadless()). No point to execute other code. - PR: https://git.openjdk.java.net/jdk/pull/2291
Re: RFR: JDK-8260335: [macos] Running app using relative path causes problems
On Wed, 27 Jan 2021 12:43:40 GMT, Andy Herrick wrote: > Fixing FileUtils.dirname() to skip over "/.". Marked as reviewed by almatvee (Committer). - PR: https://git.openjdk.java.net/jdk/pull/2260
Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v14]
On Mon, 18 Jan 2021 16:45:00 GMT, Jim Laskey wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>>
>> javadoc can be found at
>> http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
>>
>> old PR: https://github.com/openjdk/jdk/pull/1273
>
> Jim Laskey has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update package info to credit LMX algorithm
src/java.base/share/classes/java/util/random/RandomGenerator.java line 110:
> 108: /**
> 109: * Returns an instance of {@link RandomGenerator} that utilizes the
> 110: * {@code name} algorithm.
Shouldn't this method, and related methods, mention the fact that
`RandomGenerator` instances are located as services? I see no mention of of
that fact anywhere, unless I missed it, but I do see the `uses` and `provides`
declarations in the module declaration. A paragraph explaining how services are
used here, perhaps in the package specification, would be ideal.
-
PR: https://git.openjdk.java.net/jdk/pull/1292
Re: RFR: 8249867: xml declaration is not followed by a newline [v3]
> Please review a patch to add an explicit control over whether a newline > should be added after the XML header. This is done by adding a DOM > LSSerializer property "jdk-is-standalone" and System property > "jdk.xml.isStandalone". > > This change addresses an incompatibility introduced during 7u4 as an update > to Xalan 2.7.1. Joe Wang has updated the pull request incrementally with one additional commit since the last revision: Updated the patch based on review comments. Refer to the previous reviews. - Changes: - all: https://git.openjdk.java.net/jdk/pull/2041/files - new: https://git.openjdk.java.net/jdk/pull/2041/files/a3591aa7..0ed62318 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2041=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2041=01-02 Stats: 57 lines in 3 files changed: 14 ins; 8 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/2041.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2041/head:pull/2041 PR: https://git.openjdk.java.net/jdk/pull/2041
Re: RFR: 8260592: jpackage tests fail when Desktop is not supported
On Thu, 28 Jan 2021 22:05:17 GMT, Aleksey Shipilev wrote:
>> test/jdk/tools/jpackage/apps/image/Hello.java line 166:
>>
>>> 164: }
>>> 165:
>>> 166: if (!Desktop.isDesktopSupported()) {
>>
>> Would it make more sense to replace
>> `if (GraphicsEnvironment.isHeadless())`
>> with
>> `if (GraphicsEnvironment.isHeadless() || !Desktop.isDesktopSupported())`
>> without need to add another `trace()` call?
>
> I would prefer to have separate messages for "headless" and "desktop
> capable". I can merge these, if you insist.
Duplicated messages are not much help in understanding control flow. I'd change
the new message or merge conditions. Whatever you prefer.
-
PR: https://git.openjdk.java.net/jdk/pull/2291
Re: RFR: 8260592: jpackage tests fail when Desktop is not supported
On Thu, 28 Jan 2021 20:13:23 GMT, Alexey Semenyuk wrote:
>> If you run x86 configuration (cross-compiled on x86_64), then many tests
>> would fail with:
>>
>> $ CONF=linux-x86-server-fastdebug make images run-test TEST=tools/jpackage
>> ...
>> can not load libgnomevfs-2.so
>> Exception in thread "main" java.lang.ExceptionInInitializerError
>> Caused by: java.lang.UnsupportedOperationException: Desktop API is not
>> supported on the current platform
>> at java.desktop/java.awt.Desktop.getDesktop(Unknown Source)
>> at com.that/com.that.main.Florence.createInstance(Unknown Source)
>> at com.that/com.that.main.Florence.(Unknown Source)
>> Failed to launch JVM
>> java.lang.AssertionError: Expected [0]. Actual [1]: Check command
>> [/home/shade/trunks/jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_jdk_tools_jpackage/scratch/10/./testMainLauncherIsModular.ed4f638d/output/MainLauncherIsModularAddLauncherTest/bin/ModularAppLauncher](1)
>> exited with 0 code
>>
>> The tests probably need to check `Desktop.isDesktopSupported()`, similarly
>> how they check `GraphicsEnvironment.isHeadless()`.
>>
>> Additional testing:
>> - [x] Linux x86_32 `tools/jpackage` (now pass)
>> - [x] Linux x86_64 `tools/jpackage` (still pass)
>
> test/jdk/tools/jpackage/apps/image/Hello.java line 166:
>
>> 164: }
>> 165:
>> 166: if (!Desktop.isDesktopSupported()) {
>
> Would it make more sense to replace
> `if (GraphicsEnvironment.isHeadless())`
> with
> `if (GraphicsEnvironment.isHeadless() || !Desktop.isDesktopSupported())`
> without need to add another `trace()` call?
I would prefer to have separate messages for "headless" and "desktop capable".
I can merge these, if you insist.
-
PR: https://git.openjdk.java.net/jdk/pull/2291
Re: RFR: 8260592: jpackage tests fail when Desktop is not supported
On Thu, 28 Jan 2021 14:33:35 GMT, Aleksey Shipilev wrote: > If you run x86 configuration (cross-compiled on x86_64), then many tests > would fail with: > > $ CONF=linux-x86-server-fastdebug make images run-test TEST=tools/jpackage > ... > can not load libgnomevfs-2.so > Exception in thread "main" java.lang.ExceptionInInitializerError > Caused by: java.lang.UnsupportedOperationException: Desktop API is not > supported on the current platform > at java.desktop/java.awt.Desktop.getDesktop(Unknown Source) > at com.that/com.that.main.Florence.createInstance(Unknown Source) > at com.that/com.that.main.Florence.(Unknown Source) > Failed to launch JVM > java.lang.AssertionError: Expected [0]. Actual [1]: Check command > [/home/shade/trunks/jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_jdk_tools_jpackage/scratch/10/./testMainLauncherIsModular.ed4f638d/output/MainLauncherIsModularAddLauncherTest/bin/ModularAppLauncher](1) > exited with 0 code > > The tests probably need to check `Desktop.isDesktopSupported()`, similarly > how they check `GraphicsEnvironment.isHeadless()`. > > Additional testing: > - [x] Linux x86_32 `tools/jpackage` (now pass) > - [x] Linux x86_64 `tools/jpackage` (still pass) Marked as reviewed by herrick (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2291
Re: RFR: 8260592: jpackage tests fail when Desktop is not supported
On Thu, 28 Jan 2021 14:33:35 GMT, Aleksey Shipilev wrote:
> If you run x86 configuration (cross-compiled on x86_64), then many tests
> would fail with:
>
> $ CONF=linux-x86-server-fastdebug make images run-test TEST=tools/jpackage
> ...
> can not load libgnomevfs-2.so
> Exception in thread "main" java.lang.ExceptionInInitializerError
> Caused by: java.lang.UnsupportedOperationException: Desktop API is not
> supported on the current platform
> at java.desktop/java.awt.Desktop.getDesktop(Unknown Source)
> at com.that/com.that.main.Florence.createInstance(Unknown Source)
> at com.that/com.that.main.Florence.(Unknown Source)
> Failed to launch JVM
> java.lang.AssertionError: Expected [0]. Actual [1]: Check command
> [/home/shade/trunks/jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_jdk_tools_jpackage/scratch/10/./testMainLauncherIsModular.ed4f638d/output/MainLauncherIsModularAddLauncherTest/bin/ModularAppLauncher](1)
> exited with 0 code
>
> The tests probably need to check `Desktop.isDesktopSupported()`, similarly
> how they check `GraphicsEnvironment.isHeadless()`.
>
> Additional testing:
> - [x] Linux x86_32 `tools/jpackage` (now pass)
> - [x] Linux x86_64 `tools/jpackage` (still pass)
Changes requested by asemenyuk (Committer).
test/jdk/tools/jpackage/apps/image/Hello.java line 166:
> 164: }
> 165:
> 166: if (!Desktop.isDesktopSupported()) {
Would it make more sense to replace
`if (GraphicsEnvironment.isHeadless())`
with
`if (GraphicsEnvironment.isHeadless() || !Desktop.isDesktopSupported())`
without need to add another `trace()` call?
-
PR: https://git.openjdk.java.net/jdk/pull/2291
Re: RFR: 8260605: Various java.lang.invoke cleanups [v2]
> - Remove unused code > - Inline and simplify the bootstrap method invocation code (remove pointless > reboxing checks etc) > - Apply pattern matching to make some code more readable Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Missing outstanding changes - Changes: - all: https://git.openjdk.java.net/jdk/pull/2300/files - new: https://git.openjdk.java.net/jdk/pull/2300/files/dc8b586d..68d3475a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2300=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2300=00-01 Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2300.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2300/head:pull/2300 PR: https://git.openjdk.java.net/jdk/pull/2300
RFR: 8260605: Various java.lang.invoke cleanups
- Remove unused code - Inline and simplify the bootstrap method invocation code (remove pointless reboxing checks etc) - Apply pattern matching to make some code more readable - Commit messages: - Avoid unnecessary reboxing checks, inline and simplify class/mt invokes - j.l.invoke cleanups Changes: https://git.openjdk.java.net/jdk/pull/2300/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2300=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260605 Stats: 269 lines in 14 files changed: 11 ins; 161 del; 97 mod Patch: https://git.openjdk.java.net/jdk/pull/2300.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2300/head:pull/2300 PR: https://git.openjdk.java.net/jdk/pull/2300
Re: RFR: JDK-8257086: Clarify differences between {Float, Double}.equals and ==
I like the text it’s good to mix object and value identities. I would only miss
unequal behavior of NaN in the description.
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: core-libs-dev im Auftrag von Joe
Darcy
Gesendet: Thursday, January 28, 2021 8:17:39 AM
An: core-libs-dev@openjdk.java.net
Betreff: Re: RFR: JDK-8257086: Clarify differences between {Float,
Double}.equals and ==
On Thu, 10 Dec 2020 01:32:24 GMT, Stuart Marks wrote:
>
>
> Great, let me know if you'd like me to provide some text for any particular
> topics in this area.
Before sending out another iteration in code, there the draft javadoc text of a
discussion at the end of the class-level discussion of java.lang.Double:
* Floating-point Equality, Equivalence,
* and Comparison
*
* IEEE 754 floating-point values include finite nonzero values,
* signed zeros ({@code +0.0} and {@code -0.0}), signed infinities
* {@linkplain Double#POSITIVE_INFINITY positive infinity} and
* {@linkplain Double#NEGATIVE_INFINITY negative infinity}), and
* {@linkplain Double#NaN NaN} (not-a-number).
*
* An equivalence relation on a set of values is a boolean
* relation on pairs of values that is reflexive, symmetric, and
* transitive. A set can have multiple equivalence relations defined
* for it. For example, {@link java.util.HashMap HashMap} compares
* keys in the set of objects using the equivalence relation of {@link
* Object#equals Object.equals} while {@link java.util.IdentityHashMap
* IdentityHashMap} compares keys in the set of objects using the
* equivalence relation of reference equality.
*
* For floating-point values to be used in data structures like
* sets and maps, the {@linkplain Double#equals equals} or {@linkplain
* Double#compareTo comparison} method must satisfy the usual
* requirements of being an equivalence relation or analogous
* requirement for comparison methods. However, surprisingly, the
* built-in {@code ==} operation on floating-point values does
* not implement an equivalence relation. Despite not
* defining an equivalence relation, the semantics of the IEEE 754
* {@code ==} operator were deliberately designed to meet other needs
* of numerical computation. There are two exceptions where the
* properties of an equivalence relations are not satisfied by {@code
* ==} on floating-point values:
*
*
*
* If {@code v1} and {@code v2} are both NaN, then {@code v1
* == v2} has the value {@code false}. Therefore, for two NaN
* arguments the reflexive property of an equivalence
* relation is not satisfied by the {@code ==} operator.
*
* If {@code v1} represents {@code +0.0} while {@code v2}
* represents {@code -0.0}, or vice versa, then {@code v1 == v2} has
* the value {@code true} even though {@code +0.0} and {@code -0.0}
* are distinguishable under various floating-point operations. For
* example, {@code 1.0/+0.0} evaluates to positive infinity while
* {@code 1.0/-0.0} evaluates to negative infinity and
* positive infinity and negative infinity are neither equal to each
* other nor equivalent to each other.
*
*
*
* For ordered comparisons using the built-in comparison operator
* ({@code <}, {@code <=}, etc.), NaN values have another anomalous
* situation: a NaN is neither less than, greater than, nor equal to
* any value, including itself. This means the trichotomy of
* comparison does not hold.
*
* To provide the appropriate semantics for {@code equals} and {@code
* compareTo} methods, those methods cannot simply to wrappers around
* {@code ==} or ordered comparison operations. Instead, {@link
* Double#equals equals} defines NaN arguments to be equal to each
* other and defines {@code +0.0} to not be equal to {@code
* -0.0}, restoring reflexivity. For comparisons, {@link
* Double#compareTo compareTo} defines a total order where {@code
* -0.0} is less than {@code +0.0} and where a NaN is equal to itself
* and considered greater than positive infinity.
*
* The operational semantics of {@code equals} and {@code
* compareTo} are expressed in terms of {@linkplain doubleToLongBigs
* bit-wise converting} the floating-point values to integral values
*
* The natural ordering implemented by {@link compareTo
* compareTo} is {@linkplain Comparable consistent with equals}; that
* is values are only reported as equal by {@code equals} if {@code
* compareTo} on those objects returns zero.
*
* @jls 4.2.3 Floating-Point Types, Formats, and Values
* @jls 4.2.4. Floating-Point Operations
* @jls 15.21.1 Numerical Equality Operators == and !=
Comments?
Thanks,
-
PR: https://git.openjdk.java.net/jdk/pull/1699
Integrated: 8260461: Modernize jsr166 tck tests
On Tue, 26 Jan 2021 21:23:25 GMT, Martin Buchholz wrote: > 8260461: Modernize jsr166 tck tests This pull request has now been integrated. Changeset: 81e9e6a7 Author:Martin Buchholz URL: https://git.openjdk.java.net/jdk/commit/81e9e6a7 Stats: 7616 lines in 71 files changed: 318 ins; 187 del; 7111 mod 8260461: Modernize jsr166 tck tests Reviewed-by: dl - PR: https://git.openjdk.java.net/jdk/pull/2245
Re: RFR: 8257746: Regression introduced with JDK-8250984 - memory might be null in some machines
On Thu, 28 Jan 2021 17:19:53 GMT, Poonam Bajaj wrote:
> > > I'm curious: What config is this to actually trigger the NPE? How does
> > > `/proc/self/mountinfo`, `/proc/self/cgroup` and `/proc/cgroups` look like?
> >
> >
> > > > I'm curious: What config is this to actually trigger the NPE? How does
> > > > `/proc/self/mountinfo`, `/proc/self/cgroup` and `/proc/cgroups` look
> > > > like?
> > >
> > >
> > > I don't have access to the config. The issue was reported by a customer.
> >
> >
> > This isn't very satisfying, though. How can we be sure this issue isn't
> > also present in the cgroup v2 code? Has this been tested? Surely, there was
> > some stack trace reported by the customer or some sort of reproducer got
> > provided. What was the reasoning that established this issue is present in
> > JDK head and **only** in cgroups v1 code? My guess is that the issue got
> > triggered via the OperatingSystemMXBean, but nothing to that effect has
> > been noted here or in the bug.
> > If I were to propose such a point fix, clearly, I'd have to provide some
> > details what the actual problem is and explain why the fix is sufficient
> > and covers all branches. All that got provided is: "But memory could be
> > Null on some machines that have cgroup entries for CPU but not for memory."
>
> I can check with the customer if they could share their config.
That would be helpful. A stack trace of the NPE would be good too.
> The cgroups v2 code was thoroughly examined and this problem does not exist
> in that code. cgroups v2 does not have a separate MemorySubSystemController
> as we have for c1 cgroups.
>
> An instance of the CgroupV1MemorySubSystemController is stored as a member in
> CgroupV1Subsystem.
>
> ```
> private CgroupV1MemorySubSystemController memory;
>
> private void setMemorySubSystem(CgroupV1MemorySubSystemController memory) {
> this.memory = memory;
> }
> ```
>
> This memory instance variable could stay null if "memory" entry is not found
> while creating sub-system objects in createSubSystemController().
>
> ```
>case "memory":
> subsystem.setMemorySubSystem(new
> CgroupV1MemorySubSystemController(mountentry[3], mountentry[4]));
> break;
> ```
>
> This fix ensure that the memory instance is not null before invoking any
> method on it.
>
> Such problem does not exist in cgroups v2 code.
Right, but is this reasoning sound? Without knowing the code path triggering
the problem **and** knowing something about the config can we really say?
Depending on the config it might fail in some very different way on cgroups v2!
On the other hand, knowing the config, might allow us to conclude it's an
impossible config on cgroups v2 and we are done.
-
PR: https://git.openjdk.java.net/jdk/pull/2269
Integrated: 8260596: Comment cleanup in BigInteger
On Thu, 28 Jan 2021 16:19:41 GMT, Weijun Wang wrote: > Fix some small errors. This pull request has now been integrated. Changeset: 2b166d81 Author:Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/2b166d81 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod 8260596: Comment cleanup in BigInteger Reviewed-by: bpb - PR: https://git.openjdk.java.net/jdk/pull/2292
Re: RFR: 8257746: Regression introduced with JDK-8250984 - memory might be null in some machines
On Thu, 28 Jan 2021 16:00:36 GMT, Severin Gehwolf wrote:
> > I'm curious: What config is this to actually trigger the NPE? How does
> > `/proc/self/mountinfo`, `/proc/self/cgroup` and `/proc/cgroups` look like?
>
> > > I'm curious: What config is this to actually trigger the NPE? How does
> > > `/proc/self/mountinfo`, `/proc/self/cgroup` and `/proc/cgroups` look like?
> >
> >
> > I don't have access to the config. The issue was reported by a customer.
>
> This isn't very satisfying, though. How can we be sure this issue isn't also
> present in the cgroup v2 code? Has this been tested? Surely, there was some
> stack trace reported by the customer or some sort of reproducer got provided.
> What was the reasoning that established this issue is present in JDK head and
> **only** in cgroups v1 code? My guess is that the issue got triggered via the
> OperatingSystemMXBean, but nothing to that effect has been noted here or in
> the bug.
>
> If I were to propose such a point fix, clearly, I'd have to provide some
> details what the actual problem is and explain why the fix is sufficient and
> covers all branches. All that got provided is: "But memory could be Null on
> some machines that have cgroup entries for CPU but not for memory."
I can check with the customer if they could share their config.
The cgroups v2 code was thoroughly examined and this problem does not exist in
that code. cgroups v2 does not have a separate MemorySubSystemController as we
have for c1 cgroups.
An instance of the CgroupV1MemorySubSystemController is stored as a member in
CgroupV1Subsystem.
private CgroupV1MemorySubSystemController memory;
private void setMemorySubSystem(CgroupV1MemorySubSystemController memory) {
this.memory = memory;
}
This memory instance variable could stay null if "memory" entry is not found
while creating sub-system objects in createSubSystemController().
case "memory":
subsystem.setMemorySubSystem(new
CgroupV1MemorySubSystemController(mountentry[3], mountentry[4]));
break;
This fix ensure that the memory instance is not null before invoking any method
on it.
Such problem does not exist in cgroups v2 code.
-
PR: https://git.openjdk.java.net/jdk/pull/2269
Re: RFR: 8260596: Comment cleanup in BigInteger
On Thu, 28 Jan 2021 16:19:41 GMT, Weijun Wang wrote: > Fix some small errors. Marked as reviewed by bpb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2292
RFR: 8260596: Comment cleanup in BigInteger
Fix some small errors. - Commit messages: - 8260596: Comment cleanup in BigInteger Changes: https://git.openjdk.java.net/jdk/pull/2292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2292=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260596 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2292/head:pull/2292 PR: https://git.openjdk.java.net/jdk/pull/2292
Re: RFR: 8257746: Regression introduced with JDK-8250984 - memory might be null in some machines
On Thu, 28 Jan 2021 15:01:11 GMT, Poonam Bajaj wrote: >> I'm curious: What config is this to actually trigger the NPE? How does >> `/proc/self/mountinfo`, `/proc/self/cgroup` and `/proc/cgroups` look like? > >> I'm curious: What config is this to actually trigger the NPE? How does >> `/proc/self/mountinfo`, `/proc/self/cgroup` and `/proc/cgroups` look like? > > I don't have access to the config. The issue was reported by a customer. > I'm curious: What config is this to actually trigger the NPE? How does > `/proc/self/mountinfo`, `/proc/self/cgroup` and `/proc/cgroups` look like? > > I'm curious: What config is this to actually trigger the NPE? How does > > `/proc/self/mountinfo`, `/proc/self/cgroup` and `/proc/cgroups` look like? > > I don't have access to the config. The issue was reported by a customer. This isn't very satisfying, though. How can we be sure this issue isn't also present in the cgroup v2 code? Has this been tested? Surely, there was some stack trace reported by the customer or some sort of reproducer got provided. What was the reasoning that established this issue is present in JDK head and **only** in cgroups v1 code? My guess is that the issue got triggered via the OperatingSystemMXBean, but nothing to that effect has been noted here or in the bug. If I were to propose such a point fix, clearly, I'd have to provide some details what the actual problem is and explain why the fix is sufficient and covers all branches. All that got provided is: "But memory could be Null on some machines that have cgroup entries for CPU but not for memory." - PR: https://git.openjdk.java.net/jdk/pull/2269
Integrated: 8257746: Regression introduced with JDK-8250984 - memory might be null in some machines
On Wed, 27 Jan 2021 21:10:16 GMT, Poonam Bajaj wrote:
> Please review this simple change that adds null checks for memory in
> CgroupV1Subsystem.java.
>
> Problem: After the backport of JDK-8250984, there are places where
> memory.isSwapEnabled() is called. For example:
>
> public long getMemoryAndSwapFailCount() {
> if (!memory.isSwapEnabled()) {
> return getMemoryFailCount();
> }
> return SubSystem.getLongValue(memory, "memory.memsw.failcnt");
> }
>
> But memory could be Null on some machines that have cgroup entries for CPU
> but not for memory. This would cause a NullPointerException when memory is
> accessed.
>
> Fix: Add null checks for memory.
This pull request has now been integrated.
Changeset: abc4300d
Author:Poonam Bajaj
URL: https://git.openjdk.java.net/jdk/commit/abc4300d
Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
8257746: Regression introduced with JDK-8250984 - memory might be null in some
machines
Reviewed-by: hseigel
-
PR: https://git.openjdk.java.net/jdk/pull/2269
Re: RFR: 8257746: Regression introduced with JDK-8250984 - memory might be null in some machines
On Thu, 28 Jan 2021 14:36:36 GMT, Severin Gehwolf wrote: > I'm curious: What config is this to actually trigger the NPE? How does > `/proc/self/mountinfo`, `/proc/self/cgroup` and `/proc/cgroups` look like? I don't have access to the config. The issue was reported by a customer. - PR: https://git.openjdk.java.net/jdk/pull/2269
Re: RFR: 8257746: Regression introduced with JDK-8250984 - memory might be null in some machines
On Wed, 27 Jan 2021 21:10:16 GMT, Poonam Bajaj wrote:
> Please review this simple change that adds null checks for memory in
> CgroupV1Subsystem.java.
>
> Problem: After the backport of JDK-8250984, there are places where
> memory.isSwapEnabled() is called. For example:
>
> public long getMemoryAndSwapFailCount() {
> if (!memory.isSwapEnabled()) {
> return getMemoryFailCount();
> }
> return SubSystem.getLongValue(memory, "memory.memsw.failcnt");
> }
>
> But memory could be Null on some machines that have cgroup entries for CPU
> but not for memory. This would cause a NullPointerException when memory is
> accessed.
>
> Fix: Add null checks for memory.
Changes look good! Thanks for doing this.
Harold
-
Marked as reviewed by hseigel (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/2269
RFR: 8260592: jpackage tests fail when Desktop is not supported
If you run x86 configuration (cross-compiled on x86_64), then many tests would fail with: $ CONF=linux-x86-server-fastdebug make images run-test TEST=tools/jpackage ... can not load libgnomevfs-2.so Exception in thread "main" java.lang.ExceptionInInitializerError Caused by: java.lang.UnsupportedOperationException: Desktop API is not supported on the current platform at java.desktop/java.awt.Desktop.getDesktop(Unknown Source) at com.that/com.that.main.Florence.createInstance(Unknown Source) at com.that/com.that.main.Florence.(Unknown Source) Failed to launch JVM java.lang.AssertionError: Expected [0]. Actual [1]: Check command [/home/shade/trunks/jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_jdk_tools_jpackage/scratch/10/./testMainLauncherIsModular.ed4f638d/output/MainLauncherIsModularAddLauncherTest/bin/ModularAppLauncher](1) exited with 0 code The tests probably need to check `Desktop.isDesktopSupported()`, similarly how they check `GraphicsEnvironment.isHeadless()`. Additional testing: - [x] Linux x86_32 `tools/jpackage` (now pass) - [x] Linux x86_64 `tools/jpackage` (still pass) - Commit messages: - 8260592: jpackage tests fail when Desktop is not supported Changes: https://git.openjdk.java.net/jdk/pull/2291/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2291=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260592 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2291.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2291/head:pull/2291 PR: https://git.openjdk.java.net/jdk/pull/2291
Re: RFR: 8257746: Regression introduced with JDK-8250984 - memory might be null in some machines
On Wed, 27 Jan 2021 21:10:16 GMT, Poonam Bajaj wrote:
> Please review this simple change that adds null checks for memory in
> CgroupV1Subsystem.java.
>
> Problem: After the backport of JDK-8250984, there are places where
> memory.isSwapEnabled() is called. For example:
>
> public long getMemoryAndSwapFailCount() {
> if (!memory.isSwapEnabled()) {
> return getMemoryFailCount();
> }
> return SubSystem.getLongValue(memory, "memory.memsw.failcnt");
> }
>
> But memory could be Null on some machines that have cgroup entries for CPU
> but not for memory. This would cause a NullPointerException when memory is
> accessed.
>
> Fix: Add null checks for memory.
I'm curious: What config is this to actually trigger the NPE? How does
`/proc/self/mountinfo`, `/proc/self/cgroup` and `/proc/cgroups` look like?
-
PR: https://git.openjdk.java.net/jdk/pull/2269
RFR: JDK-8260335: [macos] Running app using relative path causes problems
Fixing FileUtils.dirname() to skip over "/.". - Commit messages: - JDK-8260335: [macos] Running app using relative path causes problems on MacOS Changes: https://git.openjdk.java.net/jdk/pull/2260/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2260=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260335 Stats: 10 lines in 1 file changed: 8 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2260.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2260/head:pull/2260 PR: https://git.openjdk.java.net/jdk/pull/2260
Re: RFR: 8258917: NativeMemoryTracking is handled by launcher inconsistenly [v3]
On Wed, 20 Jan 2021 01:47:54 GMT, Alex Menkov wrote: >> The fix adds NMT handling for non-java launchers > > Alex Menkov has updated the pull request incrementally with one additional > commit since the last revision: > > Updated comment Sorry, I overlooked some of details. Final change looks fine to me. - PR: https://git.openjdk.java.net/jdk/pull/2106
Re: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection
On Tue, 12 Jan 2021 14:29:28 GMT, Severin Gehwolf wrote: >> Ping? Anyone? > > Anybody willing to review this? PING? - PR: https://git.openjdk.java.net/jdk/pull/1393
Integrated: 8255531: MethodHandles::permuteArguments throws NPE when duplicating dropped arguments
On Tue, 12 Jan 2021 16:58:45 GMT, Jorn Vernee wrote: > Hi, > > This small patch fixes the NPE in the following case: > > MethodHandle mh = MethodHandles.empty(MethodType.methodType(void.class, > int.class, int.class)); > MethodHandles.permuteArguments(mh, MethodType.methodType(void.class, > int.class), 0, 0); > > If a parameter name was changed by a lambda form edit, `LambdaForm::endEdit` > will try to sort the names that fall into the old range of parameter names > (starting from `firstChanged` and up to `arity` in the code) to make sure > that non-parameter names (`exprs`) properly appear after parameter names. > But, if a parameter was dropped, and there are no non-paramter names, a > `null` will fall into the range that is being sorted, and the call to > `name.isParam()` in the sorting algorithm will result in an NPE. > > We can just add a `name != null` check there, since `null` is definitely not > a parameter. However, we still need to do the loop in order to get an > accurate `exprp` value, which is later used to adjust the `arity` after > sorting (there are other ways to get there that don't involve copying the > extra `null`, but they are more convoluted, so I elected to go for this > solution). > > Thanks, > Jorn > > Testing: tier1-tier2 This pull request has now been integrated. Changeset: d07af2b8 Author:Jorn Vernee URL: https://git.openjdk.java.net/jdk/commit/d07af2b8 Stats: 9 lines in 2 files changed: 8 ins; 0 del; 1 mod 8255531: MethodHandles::permuteArguments throws NPE when duplicating dropped arguments Reviewed-by: redestad - PR: https://git.openjdk.java.net/jdk/pull/2054
Integrated: 8260506: VersionHelper cleanup
On Wed, 27 Jan 2021 12:15:43 GMT, Claes Redestad wrote: > Some small modernizations and cleanups that ultimately help startup of apps > using JNDI/InitialContext This pull request has now been integrated. Changeset: ecde52ec Author:Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/ecde52ec Stats: 30 lines in 1 file changed: 2 ins; 16 del; 12 mod 8260506: VersionHelper cleanup Reviewed-by: alanb, dfuchs, aefimov - PR: https://git.openjdk.java.net/jdk/pull/2259
Re: RFR: 8260506: VersionHelper cleanup
On Wed, 27 Jan 2021 15:32:58 GMT, Alan Bateman wrote: >> Some small modernizations and cleanups that ultimately help startup of apps >> using JNDI/InitialContext > > Marked as reviewed by alanb (Reviewer). @AlanBateman @dfuch @AlekseiEfimov - thanks for reviewing! - PR: https://git.openjdk.java.net/jdk/pull/2259
