April 2020 - core-libs-dev

RFR (S): 8241947: Minor comment fixes for system property handling
by Langer, Christoph 01 Apr '20

01 Apr '20

Hi, please review a small fix that updates two comments. The first one, in make/autoconf/spec.gmk.in, is probably quite old. It talks about handling of a property "vm.vendor" in VersionProps.java.template. However, there is no property "vm.vendor", it must rather be "java.vendor". I stumbled over that when looking at the change of JDK-4947890 (Minimize JNI upcalls in system-properties initialization). The second one is the code comment attached to "private static Properties props;" in java.lang.System. After JDK-8197927 (Allow the system property `java.vendor.version` to be undefined), "java.vendor.version" can be undefined, so this should be reflected in the comment. I also took the liberty to remove an unneeded import statement. Bug: https://bugs.openjdk.java.net/browse/JDK-8241947 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8241947.0/ Thanks Christoph

5 10

Re: RFR: 8238665: Add JFR event for direct memory statistics
by Denghui Dong 01 Apr '20

01 Apr '20

Hi Erik, Updated. Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.01/ Thanks Denghui Dong ------------------------------------------------------------------ From:Erik Gahlin <erik.gahlin(a)oracle.com> Send Time:2020年3月5日(星期四) 06:33 To:董登辉(卓昂) <denghui.ddh(a)alibaba-inc.com> Cc:hotspot-jfr-dev <hotspot-jfr-dev(a)openjdk.java.net> Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics Hi Denghui, Looking through you patch again. Could you add copyright headers, and change “5000 ms” to “5 s” in the .jfc files. When you reply with the updated patch, could you please include core-libs-dev(a)openjdk.java.net in the reply since you are modifying exports in java.base. Thanks Erik On 4 Mar 2020, at 20:35, Erik Gahlin <erik.gahlin(a)oracle.com> wrote: Hi Denghui, I have tested your fix and it seems to work. TestDefaultConfiguration takes into account the event is periodic, so it doesn't complain as I expected. Looks good. I can sponsor this. Thanks Erik On 3 Mar 2020, at 07:14, Denghui Dong <denghui.ddh(a)alibaba-inc.com> wrote: Hi Erik, I agree with you that the default interval should be changed to 5s, the webrev (http://cr.openjdk.java.net/~ddong/8238665/webrev.01/) has been updated. No need to modify TestDefaultConfigurations.java, it is passed. Testing (Linux release/slow debug build): jdk/jfr, all passed except TestNativeLibrariesEvent and TestNetworkUtilizationEvent(unstable). And these two test failures were not caused by this patch. And there were some test errors in slow debug build, I have checked the error test list and confirm they are also error in slow debug build without this patch, such as TestRecordedFrame. There are two new files in this patch, should I add copyright header to them? Thanks Denghui Dong ------------------------------------------------------------------ From:Erik Gahlin <erik.gahlin(a)oracle.com> Send Time:2020年3月3日(星期二) 04:08 To:董登辉(卓昂) <denghui.ddh(a)alibaba-inc.com> Cc:hotspot-jfr-dev <hotspot-jfr-dev(a)openjdk.java.net> Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics Hi Denghui, Thanks for the explanation. I think the default interval could be increased to once every 5 seconds. Have you run the all the tests in test/jdk/jdk/jfr? I would expect TestDefaultConfigurations to have failed unless modified. Thanks Erik On 2020-02-26 14:40, 董登辉(卓昂) wrote: PING: Could you review it? Bug: https://bugs.openjdk.java.net/browse/JDK-8238665 Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.01/ ------------------------------------------------------------------ From:董登辉(卓昂) <denghui.ddh(a)alibaba-inc.com> Send Time:2020年2月11日(星期二) 16:13 To:Erik Gahlin <erik.gahlin(a)oracle.com> Cc:hotspot-jfr-dev <hotspot-jfr-dev(a)openjdk.java.net> Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics Hi Erik, Thanks for the review. See answers embedded. New webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.01/ On Feb 11, 2020, at 1:52 AM, Erik Gahlin <erik.gahlin(a)oracle.com> wrote: Hi Denghiu, Can you explain when this event can be useful, i.e. when troubleshooting x etc.? This makes it easier to determine if the event should be on by default, if it is worth the increased startup cost that the instrumentation creates and what a reasonable period for the event should be. Many Java middleware(e.g. Netty) and applications use direct memory for achieving higher performance, if java process use too much direct memory, some exceptions will occur, such as oom-killer. Hence, it’s necessary to monitor it, and we use JMX to monitor it in our production environment currently. src/jdk.jfr/share/classes/jdk/jfr/events/DirectMemoryStatisticsEvent.java: @Label("TotalCapacity") -> @Label("Total Capacity") @Label("MemoryUsed") -> @Label("Memory Used”) Updated What is meant by 'limit'? Could we have a better field name and/or description that explains what this fields contains, because it is not obvious from that name. Fields that contains bytes, should have the DataAmount; annotation. What is the value if -XX:MaxDirectMemorySize has not been set? limit -> maxCapacity if -XX:MaxDirectMemorySize has not been set, the value of Runtime.getRuntime().maxMemory() will be used. Can you make the event class final. Updated @StackTrace(false) should not be needed. Removed test/jdk/jdk/jfr/event/runtime/TestDirectMemoryStatisticsEvent.java: Use try-with-resources on the Recording object. Updated Thanks Denghui Dong Thanks Erik On 2020-02-07 06:24, Denghui Dong wrote: Hi, Could I have a review of a change that adds JFR event for direct memory statistics Bug: https://bugs.openjdk.java.net/browse/JDK-8238665 Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.00/ Test: test/jdk/jdk/jfr/event/runtime/TestDirectMemoryStatisticsEvent.java Thanks Denghui Dong

3 24

JDK 15 RF(pre)R of JDK-8241374: add Math.absExact
by Joe Darcy 01 Apr '20

01 Apr '20

Hello, Please review the initial proposed wording of the spec for JDK-8241374: add Math.absExact The eventual wording needs to be replicated four times (Math.absExact(int), Math.absExact(long), StrictMath.absExact(int), StrictMath.absExact(long)) so I want to get the wording agreed to before presenting it in quadruplicate. The other "exact" methods mention overflow so I wanted the spec to absExact to include both "exact" and "overflow" in its description. Tests will follow in subsequent review iterations. Thanks, -Joe diff -r c5d90e8d4a46 src/java.base/share/classes/java/lang/Math.java --- a/src/java.base/share/classes/java/lang/Math.java Sat Mar 28 11:00:09 2020 -0400 +++ b/src/java.base/share/classes/java/lang/Math.java Sat Mar 28 10:17:39 2020 -0700 @@ -1369,6 +1369,32 @@ } /** + * Returns the mathematical absolute value of an {@code int} value + * if it is exactly representable as an {@code int}, throwing + * {@code ArithmeticException} if the result overflows the + * positive {@code int} range. + * + * <p>Since the range of two's complement integers is asymmetric + * with one additional negative value, the mathematical absolute + * value of {@link Integer#MIN_VALUE} overflows the positive + * {@code int} range and an exception is thrown for that argument. + * + * @param a the argument whose absolute value is to be determined + * @return the absolute value of the argument absent overflow + * @throws ArithmeticException if the argument is {@link Integer#MIN_VALUE} + * @see Math#abs(int) + * @since 15 + */ + public static int absExact(int a) { + if (a == Integer.MIN_VALUE) + throw new ArithmeticException("Cannot represent " + + "absolute value of " + + "Integer.MIN_VALUE"); + else + return abs(a); + } + + /** * Returns the absolute value of a {@code long} value. * If the argument is not negative, the argument is returned. * If the argument is negative, the negation of the argument is returned.

6 11

[15] RFR: 8214694: cleanup rawtypes warnings in open jndi tests
by Chris Yin 01 Apr '20

01 Apr '20

Hello Please review following simple changes to cleanup raw types warning for open jndi tests (under test/jdk/com/sun/jndi and test/jdk/javax/naming), thanks Bug: https://bugs.openjdk.java.net/browse/JDK-8214694 Webrev: http://cr.openjdk.java.net/~xyin/8214694/webrev.00/ The changes should be straightforward, only fix raw types warnings, no test logic change, no code optimization or cleanup. Minor change to each test file, just a little surprised about the affected tests count, hope this covers all. Run related jndi tests on 4 platforms for total 200 times, all passed. Thanks, Chris

3 8