Re: JDK14 cross-compile to arm64 fails to locate c++ header new
Hi Adrian, Thanks for the quick reply. Yes, I do have build-essential installed on the host system. I have cross-compiled jdk14 from a 32-bit x86 system to target aarch32-linux-gnueabihf before, with the same version gcc and g++. Could this still be the issue though? Thanks again, Jiwon On Tue, Aug 25, 2020 at 4:27 PM John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > Hi Jiwon! > > On 8/25/20 10:06 PM, Choe, Jiwon wrote: > > === Output from failing command(s) repeated here === > > * For target > > hotspot_variant-server_libjvm_gtest_objs_precompiled_precompiled.hpp.gch: > > In file included from > > > /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/classfile/classLoaderData.hpp:28:0, > > from > > > /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/precompiled/precompiled.hpp:34: > > > /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/memory/allocation.hpp:31:15: > > fatal error: new: No such file or directory > > #include > > Do you have "build-essential" installed on the host system, assuming it's > Debian-based? > > > Tools summary: > > * Boot JDK: openjdk version "13.0.2" 2020-01-14 OpenJDK Runtime > > Environment (build 13.0.2+8) OpenJDK 64-Bit Server VM (build 13.0.2+8, > > mixed mode, sharing) (at /usr/lib/jvm/jdk-13.0.2) > > * Toolchain: gcc (GNU Compiler Collection) > > * C Compiler: Version 4.8.4 (at /usr/bin/aarch64-linux-gnu-gcc) > > * C++ Compiler: Version 4.8.4 (at /usr/bin/aarch64-linux-gnu-g++) > > That version of GCC looks a bit old. I'm not sure whether it's recent > enough for > OpenJDK 14. > > FWIW, I'm using a different approach for cross-building OpenJDK which > works particularly > easy on Debian and Ubuntu due to Multi-Arch support which allows > co-installing library > packages for different architectures on one system. > > I have documented it here: > https://wiki.debian.org/PortsDocs/BootstrappingOpenJDK > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >
Re: RFR: JDK-8252145: Unify Info.plist files with correct version strings
Looks fine. On 25.08.2020 07:27, Erik Joelsson wrote: On 2020-08-24 19:18, Sergey Bylokhov wrote: Hi, Erik. I would like to highlight one thing affected by this fix. The text in the default about dialog in the Swing application will be changed. For my local build: - Current text: "Java Version 1.0 (16)" - After the fix: "Java Version 16 (0)" I am not sure why the build version and as a result the CFBundleVersion is zero? The CFBundleVersion is supposed to have a version number representing the build number. In a developer build, the "VERSION_BUILD" variable is default 0. In a promoted build, that number is set to the promoted build number. In Oracle promoted builds, we will also have a CI build number, so if this change was in effect, the latest JDK 16 promoted build would have 12.477 in CFBundleVersion. /Erik On 24.08.2020 08:19, Erik Joelsson wrote: When fixing JDK-8246094, I concluded that our Info.plist files are in a bit of a mess. This patch tries to address this on a more fundamental level. 1. All Info.plist files and templates are moved to the same location in the source tree. 2. The CFBundleIdentifier is changed to no longer contain the version number. Instead it gets the $VERSION_PRE string if present. 3. The CFBundleShortVersionString is changed to the numeric version part of our version string. 4. The CFBundleVersion is changed to the build number (or a custom number if supplied through a new configure argument). For Oracle builds, this will take the form of .. For more details on why this particular scheme, see bug description, but in short, this is what I think best reflects what the Apple documentation says the fields are for. Bug: https://bugs.openjdk.java.net/browse/JDK-8252145 Webrev: http://cr.openjdk.java.net/~erikj/8252145/webrev.01 /Erik -- Best regards, Sergey.
Re: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU
On 25.08.2020 16:25, Philip Race wrote: On 8/25/20, 4:01 PM, Sergey Bylokhov wrote: It is applied if the "automatic graphics switching" is enabled, if the user disables this feature for the "power adapter" mode, then the discrete graphics will be always used. That's a bit misleading If I disable automatic graphics switching it is disabled for BOTH batter and power and vice versa. In other words there is no way to express that battery power should fall back to integrated and that you only want discrete when running on the adapter. It is possible to do it manually, in the "power adapter" mode the user can disable "automatic graphics switching", and enable it in the "battery" mode. What do you mean by "manually" ? Open the preferences and enable/disable the switching then needed. -- Best regards, Sergey.
Re: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU
On 8/25/20, 4:01 PM, Sergey Bylokhov wrote: It is applied if the "automatic graphics switching" is enabled, if the user disables this feature for the "power adapter" mode, then the discrete graphics will be always used. That's a bit misleading If I disable automatic graphics switching it is disabled for BOTH batter and power and vice versa. In other words there is no way to express that battery power should fall back to integrated and that you only want discrete when running on the adapter. It is possible to do it manually, in the "power adapter" mode the user can disable "automatic graphics switching", and enable it in the "battery" mode. What do you mean by "manually" ? -phil.
Re: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU
On 8/25/2020 4:17 PM, Sergey Bylokhov wrote: On 25.08.2020 16:08, Kevin Rushforth wrote: I haven't tested an FX app yet, but since this changes the plist properties, I want to see whether or not FX apps are impacted. It should be affected because the first variation of the fix was pushed to the FX(if nothing changed since then): https://bugs.openjdk.java.net/browse/JDK-8132775 Since FX does not have the launcher it depends on the "bin/java" or the packed application. Yes, this is what I remember as well back when we were testing the bug. My recollection is that we only wanted to avoid using the discrete CPU when running on battery, although it's been a while since we first looked at this. -- Kevin -- Kevin On 8/25/2020 4:01 PM, Sergey Bylokhov wrote: On 25.08.2020 15:40, Philip Race wrote: On 8/25/20, 12:27 PM, Sergey Bylokhov wrote: On 25.08.2020 05:43, Kevin Rushforth wrote: Does this only apply when the MacBook is running on battery, or will this affect performance even when the laptop is plugged in? If the latter, I wonder what Apple's rationale is for including a discrete graphics card that isn't used most of the time. Based on the numbers, I wonder if we should make this change ? This is how other applications work, some numbers are now aligned to the metal pipeline. Also results are similar to other macbooks without discrete graphics. It is applied if the "automatic graphics switching" is enabled, if the user disables this feature for the "power adapter" mode, then the discrete graphics will be always used. That's a bit misleading If I disable automatic graphics switching it is disabled for BOTH batter and power and vice versa. In other words there is no way to express that battery power should fall back to integrated and that you only want discrete when running on the adapter. It is possible to do it manually, in the "power adapter" mode the user can disable "automatic graphics switching", and enable it in the "battery" mode. BTW I have never did it myself.
Re: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU
On 25.08.2020 16:08, Kevin Rushforth wrote: I haven't tested an FX app yet, but since this changes the plist properties, I want to see whether or not FX apps are impacted. It should be affected because the first variation of the fix was pushed to the FX(if nothing changed since then): https://bugs.openjdk.java.net/browse/JDK-8132775 Since FX does not have the launcher it depends on the "bin/java" or the packed application. -- Kevin On 8/25/2020 4:01 PM, Sergey Bylokhov wrote: On 25.08.2020 15:40, Philip Race wrote: On 8/25/20, 12:27 PM, Sergey Bylokhov wrote: On 25.08.2020 05:43, Kevin Rushforth wrote: Does this only apply when the MacBook is running on battery, or will this affect performance even when the laptop is plugged in? If the latter, I wonder what Apple's rationale is for including a discrete graphics card that isn't used most of the time. Based on the numbers, I wonder if we should make this change ? This is how other applications work, some numbers are now aligned to the metal pipeline. Also results are similar to other macbooks without discrete graphics. It is applied if the "automatic graphics switching" is enabled, if the user disables this feature for the "power adapter" mode, then the discrete graphics will be always used. That's a bit misleading If I disable automatic graphics switching it is disabled for BOTH batter and power and vice versa. In other words there is no way to express that battery power should fall back to integrated and that you only want discrete when running on the adapter. It is possible to do it manually, in the "power adapter" mode the user can disable "automatic graphics switching", and enable it in the "battery" mode. BTW I have never did it myself. -- Best regards, Sergey.
Re: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU
This is how other applications work... Also results are similar to other macbooks without discrete graphics. That's sort of what I was getting at with my earlier question: why have a discrete graphics card that never / seldom gets used? This may be more of a question for Apple, but it seems quite strange to me. If it switched automatically based on whether or not you were on battery, or some user setting that favored lower power usages over increased performance, then it would make sense. As it is, I'm having a hard time understanding the motivation. I haven't tested an FX app yet, but since this changes the plist properties, I want to see whether or not FX apps are impacted. -- Kevin On 8/25/2020 4:01 PM, Sergey Bylokhov wrote: On 25.08.2020 15:40, Philip Race wrote: On 8/25/20, 12:27 PM, Sergey Bylokhov wrote: On 25.08.2020 05:43, Kevin Rushforth wrote: Does this only apply when the MacBook is running on battery, or will this affect performance even when the laptop is plugged in? If the latter, I wonder what Apple's rationale is for including a discrete graphics card that isn't used most of the time. Based on the numbers, I wonder if we should make this change ? This is how other applications work, some numbers are now aligned to the metal pipeline. Also results are similar to other macbooks without discrete graphics. It is applied if the "automatic graphics switching" is enabled, if the user disables this feature for the "power adapter" mode, then the discrete graphics will be always used. That's a bit misleading If I disable automatic graphics switching it is disabled for BOTH batter and power and vice versa. In other words there is no way to express that battery power should fall back to integrated and that you only want discrete when running on the adapter. It is possible to do it manually, in the "power adapter" mode the user can disable "automatic graphics switching", and enable it in the "battery" mode. BTW I have never did it myself.
Re: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU
On 25.08.2020 15:40, Philip Race wrote: On 8/25/20, 12:27 PM, Sergey Bylokhov wrote: On 25.08.2020 05:43, Kevin Rushforth wrote: Does this only apply when the MacBook is running on battery, or will this affect performance even when the laptop is plugged in? If the latter, I wonder what Apple's rationale is for including a discrete graphics card that isn't used most of the time. Based on the numbers, I wonder if we should make this change ? This is how other applications work, some numbers are now aligned to the metal pipeline. Also results are similar to other macbooks without discrete graphics. It is applied if the "automatic graphics switching" is enabled, if the user disables this feature for the "power adapter" mode, then the discrete graphics will be always used. That's a bit misleading If I disable automatic graphics switching it is disabled for BOTH batter and power and vice versa. In other words there is no way to express that battery power should fall back to integrated and that you only want discrete when running on the adapter. It is possible to do it manually, in the "power adapter" mode the user can disable "automatic graphics switching", and enable it in the "battery" mode. BTW I have never did it myself. -- Best regards, Sergey.
Re: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU
On 8/25/20, 12:27 PM, Sergey Bylokhov wrote: On 25.08.2020 05:43, Kevin Rushforth wrote: Does this only apply when the MacBook is running on battery, or will this affect performance even when the laptop is plugged in? If the latter, I wonder what Apple's rationale is for including a discrete graphics card that isn't used most of the time. Based on the numbers, I wonder if we should make this change ? It is applied if the "automatic graphics switching" is enabled, if the user disables this feature for the "power adapter" mode, then the discrete graphics will be always used. That's a bit misleading If I disable automatic graphics switching it is disabled for BOTH batter and power and vice versa. In other words there is no way to express that battery power should fall back to integrated and that you only want discrete when running on the adapter. -phil I guess by default they try to "maximize battery life": https://support.apple.com/en-us/HT202043 -- Kevin On 8/24/2020 11:27 PM, Sergey Bylokhov wrote: On 24.08.2020 13:35, Philip Race wrote: Is there any performance cost to doing this ? I'd expect so. Any estimate ? Yes, performance is affected for sure: - SwingMark: OGL_Base: 14000 OGL_Fix: 24000 Metal: 18000 - Here is a j2dbench for the common draw operations(new/old/metal): http://cr.openjdk.java.net/~serb/8251854/perf/results.txt Summary: OGL_base: Number of tests: 24 Overall average: 4.556306150323041E8 Best spread: 0.16% variance Worst spread: 4.68% variance (Basis for results comparison) OGL_fix: Number of tests: 24 Overall average: 1.0086929824044746E8 Best spread: 0.04% variance Worst spread: 7.89% variance Comparison to basis: Best result: 83.41% of basis Worst result: 15.73% of basis Number of wins: 0 Number of ties: 0 Number of losses: 24 metal: Number of tests: 24 Overall average: 8.841681616575797E7 Best spread: 0.08% variance Worst spread: 5.64% variance Comparison to basis: Best result: 248.11% of basis Worst result: 19.1% of basis Number of wins: 8 Number of ties: 2 Number of losses: 14 == - Here is a j2dbench for the common draw operations(newOGL vs metal only): http://cr.openjdk.java.net/~serb/8251854/perf/newOGL_vs_Metal.txt Summary: OGL_fix: Number of tests: 24 Overall average: 2.5871177969681844E7 Best spread: 0.04% variance Worst spread: 7.01% variance (Basis for results comparison) metal: Number of tests: 24 Overall average: 2.1896134898150157E7 Best spread: 0.04% variance Worst spread: 1.98% variance Comparison to basis: Best result: 488.31% of basis Worst result: 30.77% of basis Number of wins: 14 Number of ties: 0 Number of losses: 10 And there's then no way to explicitly request the discrete card on a 15/16" MBP. I have checked that the discrete card is enabled by the macOS: - if the full screen window is set - if the second monitor is connected Do not know any other ways to enable it. Should we release note this ? Yes, I think so. Note that it does not affect the bundled applications only apps running via java launcher. But some(most?) bundled java applications use this flag already.
Re: RFR [16/java.xml] 8251561: Fix doclint warnings in the java.xml package
Ah, I was looking for that kind of information in the bug report, but couldn't find any. /Erik On 2020-08-25 13:20, Joe Wang wrote: Hi Erik, We're acting on a report Jon generated separately. The warnings checks are currently disabled (see line 106 JAVADOC_DISABLED_DOCLINT := accessibility html missing syntax reference). -Joe On 8/25/20 12:39 PM, Erik Joelsson wrote: On 2020-08-25 12:21, Roger Riggs wrote: Hi Erik, org.w3c is in third party code that is not being updated. There is a balance between ignoring the warnings and doing a bunch of editing that would overwritten by a future update. Yes, I get that part, but why are those warnings not triggered today? I don't see any change enabling more warnings from the build. /Erik $.02, Roger On 8/25/20 2:58 PM, Erik Joelsson wrote: Build change looks ok, but why is it needed? You are fixing a bunch of warnings in one part of the source and disabling them in another part. Is there some other change incoming that will enable more warning categories by default? /Erik On 2020-08-25 11:47, Joe Wang wrote: Cc-ing build-dev@openjdk.java.net (makefile change: make/Docs.gmk) Updated webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ Thanks Roger! Please see inline comments. On 8/25/20 8:09 AM, Roger Riggs wrote: Hi Joe, Eliminating the checking for warnings in org.w3c is fine. Please be more specific in the comment. "Ignore the doclint warnings in the W3C DOM package" Updated. org/xml/...: If we're suppressing the warnings for org/xml/... then the files changes are unnecessary? Did you mean org/w3c? We're only suppressing the warnings for org/w3c where the DOM package is in, but not org/xml where SAX is in. Remove the addition of -Xmaxwarns, it should stay the default. Done. Since its a makefile change, please copy build-dev@openjdk.java.net. Cc-ed The first line comments should terminate with a period ".". javax/xml/stream/FactoryConfigurationError.java:40 javax/xml/stream/XMLStreamException.java:41 javax/xml/xpath/XPathException.java:44 And capitable "Serializable". javax/xml/stream/events/Attribute.java: 50; add "normalized" to the @return line so it is the same as the first line. For simple get methods, the @return mimics the first line. javax/xml/stream/events/NotationDeclaration.java:43 add "notation" Updated webrev including all of the above: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ Thanks, Roger p.s. There is lots of other cleanup of the javadoc, using @code around true, false, missing periods at the end of first sentences, etc. But that's a different task. Created a bug to keep track of this: https://bugs.openjdk.java.net/browse/JDK-8252328 Thanks, Joe On 8/24/20 5:44 PM, Joe Wang wrote: Hi all, adding Roger's comment for the make file to webrev_02 (the only change to webrev_01 is Docs.gmk): http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_02/ Thanks, Joe On 8/21/20 12:49 PM, naoto.s...@oracle.com wrote: +1 Naoto On 8/21/20 12:24 PM, Lance Andersen wrote: Hi Joe, This looks OK. On Aug 21, 2020, at 2:23 PM, Joe Wang wrote: Pelase review a patch to add the missing @return, @throws, @param statements in the java.xml package (excluding the DOM component). JBS: https://bugs.openjdk.java.net/browse/JDK-8251561 CSR: https://bugs.openjdk.java.net/browse/JDK-8251995 webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_01/ Thanks, Joe Best Lance -- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: JDK14 cross-compile to arm64 fails to locate c++ header new
Hi Jiwon! On 8/25/20 10:06 PM, Choe, Jiwon wrote: > === Output from failing command(s) repeated here === > * For target > hotspot_variant-server_libjvm_gtest_objs_precompiled_precompiled.hpp.gch: > In file included from > /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/classfile/classLoaderData.hpp:28:0, > from > /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/precompiled/precompiled.hpp:34: > /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/memory/allocation.hpp:31:15: > fatal error: new: No such file or directory > #include Do you have "build-essential" installed on the host system, assuming it's Debian-based? > Tools summary: > * Boot JDK: openjdk version "13.0.2" 2020-01-14 OpenJDK Runtime > Environment (build 13.0.2+8) OpenJDK 64-Bit Server VM (build 13.0.2+8, > mixed mode, sharing) (at /usr/lib/jvm/jdk-13.0.2) > * Toolchain: gcc (GNU Compiler Collection) > * C Compiler: Version 4.8.4 (at /usr/bin/aarch64-linux-gnu-gcc) > * C++ Compiler: Version 4.8.4 (at /usr/bin/aarch64-linux-gnu-g++) That version of GCC looks a bit old. I'm not sure whether it's recent enough for OpenJDK 14. FWIW, I'm using a different approach for cross-building OpenJDK which works particularly easy on Debian and Ubuntu due to Multi-Arch support which allows co-installing library packages for different architectures on one system. I have documented it here: https://wiki.debian.org/PortsDocs/BootstrappingOpenJDK Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: RFR [16/java.xml] 8251561: Fix doclint warnings in the java.xml package
Hi Erik, We're acting on a report Jon generated separately. The warnings checks are currently disabled (see line 106 JAVADOC_DISABLED_DOCLINT := accessibility html missing syntax reference). -Joe On 8/25/20 12:39 PM, Erik Joelsson wrote: On 2020-08-25 12:21, Roger Riggs wrote: Hi Erik, org.w3c is in third party code that is not being updated. There is a balance between ignoring the warnings and doing a bunch of editing that would overwritten by a future update. Yes, I get that part, but why are those warnings not triggered today? I don't see any change enabling more warnings from the build. /Erik $.02, Roger On 8/25/20 2:58 PM, Erik Joelsson wrote: Build change looks ok, but why is it needed? You are fixing a bunch of warnings in one part of the source and disabling them in another part. Is there some other change incoming that will enable more warning categories by default? /Erik On 2020-08-25 11:47, Joe Wang wrote: Cc-ing build-dev@openjdk.java.net (makefile change: make/Docs.gmk) Updated webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ Thanks Roger! Please see inline comments. On 8/25/20 8:09 AM, Roger Riggs wrote: Hi Joe, Eliminating the checking for warnings in org.w3c is fine. Please be more specific in the comment. "Ignore the doclint warnings in the W3C DOM package" Updated. org/xml/...: If we're suppressing the warnings for org/xml/... then the files changes are unnecessary? Did you mean org/w3c? We're only suppressing the warnings for org/w3c where the DOM package is in, but not org/xml where SAX is in. Remove the addition of -Xmaxwarns, it should stay the default. Done. Since its a makefile change, please copy build-dev@openjdk.java.net. Cc-ed The first line comments should terminate with a period ".". javax/xml/stream/FactoryConfigurationError.java:40 javax/xml/stream/XMLStreamException.java:41 javax/xml/xpath/XPathException.java:44 And capitable "Serializable". javax/xml/stream/events/Attribute.java: 50; add "normalized" to the @return line so it is the same as the first line. For simple get methods, the @return mimics the first line. javax/xml/stream/events/NotationDeclaration.java:43 add "notation" Updated webrev including all of the above: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ Thanks, Roger p.s. There is lots of other cleanup of the javadoc, using @code around true, false, missing periods at the end of first sentences, etc. But that's a different task. Created a bug to keep track of this: https://bugs.openjdk.java.net/browse/JDK-8252328 Thanks, Joe On 8/24/20 5:44 PM, Joe Wang wrote: Hi all, adding Roger's comment for the make file to webrev_02 (the only change to webrev_01 is Docs.gmk): http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_02/ Thanks, Joe On 8/21/20 12:49 PM, naoto.s...@oracle.com wrote: +1 Naoto On 8/21/20 12:24 PM, Lance Andersen wrote: Hi Joe, This looks OK. On Aug 21, 2020, at 2:23 PM, Joe Wang wrote: Pelase review a patch to add the missing @return, @throws, @param statements in the java.xml package (excluding the DOM component). JBS: https://bugs.openjdk.java.net/browse/JDK-8251561 CSR: https://bugs.openjdk.java.net/browse/JDK-8251995 webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_01/ Thanks, Joe Best Lance -- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: RFR [16/java.xml] 8251561: Fix doclint warnings in the java.xml package
Hi Erik, We're in a cleanup phase of the source before re-enabling disabled warnings. The warnings for "missing" comments are disabled: Docs.gmk: 106: JAVADOC_DISABLED_DOCLINT := accessibility html missing syntax reference Roger On 8/25/20 3:39 PM, Erik Joelsson wrote: On 2020-08-25 12:21, Roger Riggs wrote: Hi Erik, org.w3c is in third party code that is not being updated. There is a balance between ignoring the warnings and doing a bunch of editing that would overwritten by a future update. Yes, I get that part, but why are those warnings not triggered today? I don't see any change enabling more warnings from the build. /Erik $.02, Roger On 8/25/20 2:58 PM, Erik Joelsson wrote: Build change looks ok, but why is it needed? You are fixing a bunch of warnings in one part of the source and disabling them in another part. Is there some other change incoming that will enable more warning categories by default? /Erik On 2020-08-25 11:47, Joe Wang wrote: Cc-ing build-dev@openjdk.java.net (makefile change: make/Docs.gmk) Updated webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ Thanks Roger! Please see inline comments. On 8/25/20 8:09 AM, Roger Riggs wrote: Hi Joe, Eliminating the checking for warnings in org.w3c is fine. Please be more specific in the comment. "Ignore the doclint warnings in the W3C DOM package" Updated. org/xml/...: If we're suppressing the warnings for org/xml/... then the files changes are unnecessary? Did you mean org/w3c? We're only suppressing the warnings for org/w3c where the DOM package is in, but not org/xml where SAX is in. Remove the addition of -Xmaxwarns, it should stay the default. Done. Since its a makefile change, please copy build-dev@openjdk.java.net. Cc-ed The first line comments should terminate with a period ".". javax/xml/stream/FactoryConfigurationError.java:40 javax/xml/stream/XMLStreamException.java:41 javax/xml/xpath/XPathException.java:44 And capitable "Serializable". javax/xml/stream/events/Attribute.java: 50; add "normalized" to the @return line so it is the same as the first line. For simple get methods, the @return mimics the first line. javax/xml/stream/events/NotationDeclaration.java:43 add "notation" Updated webrev including all of the above: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ Thanks, Roger p.s. There is lots of other cleanup of the javadoc, using @code around true, false, missing periods at the end of first sentences, etc. But that's a different task. Created a bug to keep track of this: https://bugs.openjdk.java.net/browse/JDK-8252328 Thanks, Joe On 8/24/20 5:44 PM, Joe Wang wrote: Hi all, adding Roger's comment for the make file to webrev_02 (the only change to webrev_01 is Docs.gmk): http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_02/ Thanks, Joe On 8/21/20 12:49 PM, naoto.s...@oracle.com wrote: +1 Naoto On 8/21/20 12:24 PM, Lance Andersen wrote: Hi Joe, This looks OK. On Aug 21, 2020, at 2:23 PM, Joe Wang wrote: Pelase review a patch to add the missing @return, @throws, @param statements in the java.xml package (excluding the DOM component). JBS: https://bugs.openjdk.java.net/browse/JDK-8251561 CSR: https://bugs.openjdk.java.net/browse/JDK-8251995 webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_01/ Thanks, Joe Best Lance -- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
JDK14 cross-compile to arm64 fails to locate c++ header new
Hello all, I'm trying to cross-compile JDK 14 to target aarch64-linux-gnu, from a 64-bit x86 Linux machine. I followed the steps described in the documentation ( https://hg.openjdk.java.net/jdk/jdk14/raw-file/tip/doc/building.html#creating-and-using-sysroots-with-qemu-deboostrap), but when I try to make the target image, I get the following error: === Output from failing command(s) repeated here === * For target hotspot_variant-server_libjvm_gtest_objs_precompiled_precompiled.hpp.gch: In file included from /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/classfile/classLoaderData.hpp:28:0, from /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/precompiled/precompiled.hpp:34: /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/memory/allocation.hpp:31:15: fatal error: new: No such file or directory #include ^ compilation terminated. * For target hotspot_variant-server_libjvm_objs_precompiled_precompiled.hpp.gch: In file included from /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/classfile/classLoaderData.hpp:28:0, from /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/precompiled/precompiled.hpp:34: /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/memory/allocation.hpp:31:15: fatal error: new: No such file or directory #include ^ compilation terminated. Could anyone help me figure out how to fix this? This is how I configured the build, and the output I got from configure: $ sudo qemu-debootstrap --arch=arm64 --verbose --include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev --resolve-deps trusty /opt/sysroot/ $ CC=aarch64-linux-gnu-gcc CXX=aarch64-linux-gnu-g++ bash configure --openjdk-target=aarch64-linux-gnu --with-build-jdk=build/linux-x86_64-server-release/images/jdk --with-sysroot=/opt/sysroot --with-toolchain-path=/opt/sysroot configure: Configuration created at Tue Aug 25 15:55:28 EDT 2020. checking for basename... /usr/bin/basename checking for bash... /bin/bash checking for cat... /bin/cat checking for chmod... /bin/chmod checking for cmp... /usr/bin/cmp checking for comm... /usr/bin/comm checking for cp... /bin/cp checking for cut... /usr/bin/cut checking for date... /bin/date checking for gdiff... no checking for diff... /usr/bin/diff checking for dirname... /usr/bin/dirname checking for echo... /bin/echo checking for expr... /usr/bin/expr checking for file... /usr/bin/file checking for find... /usr/bin/find checking for head... /usr/bin/head checking for gunzip... /bin/gunzip checking for pigz... no checking for gzip... /bin/gzip checking for ln... /bin/ln checking for ls... /bin/ls checking for gmkdir... no checking for mkdir... /bin/mkdir checking for mktemp... /bin/mktemp checking for mv... /bin/mv checking for nawk... /usr/bin/nawk checking for printf... /usr/bin/printf checking for greadlink... no checking for readlink... /bin/readlink checking for rm... /bin/rm checking for rmdir... /bin/rmdir checking for sh... /bin/sh checking for sort... /usr/bin/sort checking for tail... /usr/bin/tail checking for gtar... no checking for tar... /bin/tar checking for tee... /usr/bin/tee checking for touch... /usr/bin/touch checking for tr... /usr/bin/tr checking for uname... /bin/uname checking for uniq... /usr/bin/uniq checking for wc... /usr/bin/wc checking for which... /usr/bin/which checking for xargs... /usr/bin/xargs checking for gawk... gawk checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for fgrep... /bin/grep -F checking for a sed that does not truncate output... /bin/sed checking for cygpath... no checking for wslpath... no checking for df... /bin/df checking for cpio... /bin/cpio checking for nice... /usr/bin/nice checking for lsb_release... /usr/bin/lsb_release checking for cmd.exe... no checking for /mnt/c/Windows/System32/cmd.exe... no checking build system type... x86_64-unknown-linux-gnu checking host system type... aarch64-unknown-linux-gnu checking target system type... aarch64-unknown-linux-gnu checking openjdk-build os-cpu... linux-x86_64 checking openjdk-target os-cpu... linux-aarch64 checking compilation type... cross checking for top-level directory... /home/jiwon/jdk-related/jdk14/jdk14 checking if custom source is suppressed (openjdk-only)... no checking which debug level to use... release checking which variants of the JVM to build... server checking for sysroot... /opt/sysroot checking for toolchain path... /opt/sysroot checking for extra path... checking where to store configuration... in default location checking what configuration name to use... linux-aarch64-server-release checking for zypper... no checking for apt-get... apt-get checking for pandoc... no checking for gmake... no checking for make... /usr/bin/make configure: Testing potential make at /usr/bin/make, found using make in
Re: RFR [16/java.xml] 8251561: Fix doclint warnings in the java.xml package
+1 Naoto On 8/25/20 11:47 AM, Joe Wang wrote: Cc-ing build-dev@openjdk.java.net (makefile change: make/Docs.gmk) Updated webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ Thanks Roger! Please see inline comments. On 8/25/20 8:09 AM, Roger Riggs wrote: Hi Joe, Eliminating the checking for warnings in org.w3c is fine. Please be more specific in the comment. "Ignore the doclint warnings in the W3C DOM package" Updated. org/xml/...: If we're suppressing the warnings for org/xml/... then the files changes are unnecessary? Did you mean org/w3c? We're only suppressing the warnings for org/w3c where the DOM package is in, but not org/xml where SAX is in. Remove the addition of -Xmaxwarns, it should stay the default. Done. Since its a makefile change, please copy build-dev@openjdk.java.net. Cc-ed The first line comments should terminate with a period ".". javax/xml/stream/FactoryConfigurationError.java:40 javax/xml/stream/XMLStreamException.java:41 javax/xml/xpath/XPathException.java:44 And capitable "Serializable". javax/xml/stream/events/Attribute.java: 50; add "normalized" to the @return line so it is the same as the first line. For simple get methods, the @return mimics the first line. javax/xml/stream/events/NotationDeclaration.java:43 add "notation" Updated webrev including all of the above: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ Thanks, Roger p.s. There is lots of other cleanup of the javadoc, using @code around true, false, missing periods at the end of first sentences, etc. But that's a different task. Created a bug to keep track of this: https://bugs.openjdk.java.net/browse/JDK-8252328 Thanks, Joe On 8/24/20 5:44 PM, Joe Wang wrote: Hi all, adding Roger's comment for the make file to webrev_02 (the only change to webrev_01 is Docs.gmk): http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_02/ Thanks, Joe On 8/21/20 12:49 PM, naoto.s...@oracle.com wrote: +1 Naoto On 8/21/20 12:24 PM, Lance Andersen wrote: Hi Joe, This looks OK. On Aug 21, 2020, at 2:23 PM, Joe Wang wrote: Pelase review a patch to add the missing @return, @throws, @param statements in the java.xml package (excluding the DOM component). JBS: https://bugs.openjdk.java.net/browse/JDK-8251561 CSR: https://bugs.openjdk.java.net/browse/JDK-8251995 webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_01/ Thanks, Joe Best Lance -- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: RFR [16/java.xml] 8251561: Fix doclint warnings in the java.xml package
On 2020-08-25 12:21, Roger Riggs wrote: Hi Erik, org.w3c is in third party code that is not being updated. There is a balance between ignoring the warnings and doing a bunch of editing that would overwritten by a future update. Yes, I get that part, but why are those warnings not triggered today? I don't see any change enabling more warnings from the build. /Erik $.02, Roger On 8/25/20 2:58 PM, Erik Joelsson wrote: Build change looks ok, but why is it needed? You are fixing a bunch of warnings in one part of the source and disabling them in another part. Is there some other change incoming that will enable more warning categories by default? /Erik On 2020-08-25 11:47, Joe Wang wrote: Cc-ing build-dev@openjdk.java.net (makefile change: make/Docs.gmk) Updated webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ Thanks Roger! Please see inline comments. On 8/25/20 8:09 AM, Roger Riggs wrote: Hi Joe, Eliminating the checking for warnings in org.w3c is fine. Please be more specific in the comment. "Ignore the doclint warnings in the W3C DOM package" Updated. org/xml/...: If we're suppressing the warnings for org/xml/... then the files changes are unnecessary? Did you mean org/w3c? We're only suppressing the warnings for org/w3c where the DOM package is in, but not org/xml where SAX is in. Remove the addition of -Xmaxwarns, it should stay the default. Done. Since its a makefile change, please copy build-dev@openjdk.java.net. Cc-ed The first line comments should terminate with a period ".". javax/xml/stream/FactoryConfigurationError.java:40 javax/xml/stream/XMLStreamException.java:41 javax/xml/xpath/XPathException.java:44 And capitable "Serializable". javax/xml/stream/events/Attribute.java: 50; add "normalized" to the @return line so it is the same as the first line. For simple get methods, the @return mimics the first line. javax/xml/stream/events/NotationDeclaration.java:43 add "notation" Updated webrev including all of the above: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ Thanks, Roger p.s. There is lots of other cleanup of the javadoc, using @code around true, false, missing periods at the end of first sentences, etc. But that's a different task. Created a bug to keep track of this: https://bugs.openjdk.java.net/browse/JDK-8252328 Thanks, Joe On 8/24/20 5:44 PM, Joe Wang wrote: Hi all, adding Roger's comment for the make file to webrev_02 (the only change to webrev_01 is Docs.gmk): http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_02/ Thanks, Joe On 8/21/20 12:49 PM, naoto.s...@oracle.com wrote: +1 Naoto On 8/21/20 12:24 PM, Lance Andersen wrote: Hi Joe, This looks OK. On Aug 21, 2020, at 2:23 PM, Joe Wang wrote: Pelase review a patch to add the missing @return, @throws, @param statements in the java.xml package (excluding the DOM component). JBS: https://bugs.openjdk.java.net/browse/JDK-8251561 CSR: https://bugs.openjdk.java.net/browse/JDK-8251995 webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_01/ Thanks, Joe Best Lance -- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: RFR [16/java.xml] 8251561: Fix doclint warnings in the java.xml package
Hi Joe, The updates to those files are fine, I mixed up the two packages. Roger On 8/25/20 2:47 PM, Joe Wang wrote: org/xml/...: If we're suppressing the warnings for org/xml/... then the files changes are unnecessary? Did you mean org/w3c? We're only suppressing the warnings for org/w3c where the DOM package is in, but not org/xml where SAX is in.
Re: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU
On 25.08.2020 05:43, Kevin Rushforth wrote: Does this only apply when the MacBook is running on battery, or will this affect performance even when the laptop is plugged in? If the latter, I wonder what Apple's rationale is for including a discrete graphics card that isn't used most of the time. It is applied if the "automatic graphics switching" is enabled, if the user disables this feature for the "power adapter" mode, then the discrete graphics will be always used. I guess by default they try to "maximize battery life": https://support.apple.com/en-us/HT202043 -- Kevin On 8/24/2020 11:27 PM, Sergey Bylokhov wrote: On 24.08.2020 13:35, Philip Race wrote: Is there any performance cost to doing this ? I'd expect so. Any estimate ? Yes, performance is affected for sure: - SwingMark: OGL_Base: 14000 OGL_Fix: 24000 Metal: 18000 - Here is a j2dbench for the common draw operations(new/old/metal): http://cr.openjdk.java.net/~serb/8251854/perf/results.txt Summary: OGL_base: Number of tests: 24 Overall average: 4.556306150323041E8 Best spread: 0.16% variance Worst spread: 4.68% variance (Basis for results comparison) OGL_fix: Number of tests: 24 Overall average: 1.0086929824044746E8 Best spread: 0.04% variance Worst spread: 7.89% variance Comparison to basis: Best result: 83.41% of basis Worst result: 15.73% of basis Number of wins: 0 Number of ties: 0 Number of losses: 24 metal: Number of tests: 24 Overall average: 8.841681616575797E7 Best spread: 0.08% variance Worst spread: 5.64% variance Comparison to basis: Best result: 248.11% of basis Worst result: 19.1% of basis Number of wins: 8 Number of ties: 2 Number of losses: 14 == - Here is a j2dbench for the common draw operations(newOGL vs metal only): http://cr.openjdk.java.net/~serb/8251854/perf/newOGL_vs_Metal.txt Summary: OGL_fix: Number of tests: 24 Overall average: 2.5871177969681844E7 Best spread: 0.04% variance Worst spread: 7.01% variance (Basis for results comparison) metal: Number of tests: 24 Overall average: 2.1896134898150157E7 Best spread: 0.04% variance Worst spread: 1.98% variance Comparison to basis: Best result: 488.31% of basis Worst result: 30.77% of basis Number of wins: 14 Number of ties: 0 Number of losses: 10 And there's then no way to explicitly request the discrete card on a 15/16" MBP. I have checked that the discrete card is enabled by the macOS: - if the full screen window is set - if the second monitor is connected Do not know any other ways to enable it. Should we release note this ? Yes, I think so. Note that it does not affect the bundled applications only apps running via java launcher. But some(most?) bundled java applications use this flag already. -- Best regards, Sergey.
Re: RFR [16/java.xml] 8251561: Fix doclint warnings in the java.xml package
Hi Erik, org.w3c is in third party code that is not being updated. There is a balance between ignoring the warnings and doing a bunch of editing that would overwritten by a future update. $.02, Roger On 8/25/20 2:58 PM, Erik Joelsson wrote: Build change looks ok, but why is it needed? You are fixing a bunch of warnings in one part of the source and disabling them in another part. Is there some other change incoming that will enable more warning categories by default? /Erik On 2020-08-25 11:47, Joe Wang wrote: Cc-ing build-dev@openjdk.java.net (makefile change: make/Docs.gmk) Updated webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ Thanks Roger! Please see inline comments. On 8/25/20 8:09 AM, Roger Riggs wrote: Hi Joe, Eliminating the checking for warnings in org.w3c is fine. Please be more specific in the comment. "Ignore the doclint warnings in the W3C DOM package" Updated. org/xml/...: If we're suppressing the warnings for org/xml/... then the files changes are unnecessary? Did you mean org/w3c? We're only suppressing the warnings for org/w3c where the DOM package is in, but not org/xml where SAX is in. Remove the addition of -Xmaxwarns, it should stay the default. Done. Since its a makefile change, please copy build-dev@openjdk.java.net. Cc-ed The first line comments should terminate with a period ".". javax/xml/stream/FactoryConfigurationError.java:40 javax/xml/stream/XMLStreamException.java:41 javax/xml/xpath/XPathException.java:44 And capitable "Serializable". javax/xml/stream/events/Attribute.java: 50; add "normalized" to the @return line so it is the same as the first line. For simple get methods, the @return mimics the first line. javax/xml/stream/events/NotationDeclaration.java:43 add "notation" Updated webrev including all of the above: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ Thanks, Roger p.s. There is lots of other cleanup of the javadoc, using @code around true, false, missing periods at the end of first sentences, etc. But that's a different task. Created a bug to keep track of this: https://bugs.openjdk.java.net/browse/JDK-8252328 Thanks, Joe On 8/24/20 5:44 PM, Joe Wang wrote: Hi all, adding Roger's comment for the make file to webrev_02 (the only change to webrev_01 is Docs.gmk): http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_02/ Thanks, Joe On 8/21/20 12:49 PM, naoto.s...@oracle.com wrote: +1 Naoto On 8/21/20 12:24 PM, Lance Andersen wrote: Hi Joe, This looks OK. On Aug 21, 2020, at 2:23 PM, Joe Wang wrote: Pelase review a patch to add the missing @return, @throws, @param statements in the java.xml package (excluding the DOM component). JBS: https://bugs.openjdk.java.net/browse/JDK-8251561 CSR: https://bugs.openjdk.java.net/browse/JDK-8251995 webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_01/ Thanks, Joe Best Lance -- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: RFR [16/java.xml] 8251561: Fix doclint warnings in the java.xml package
Build change looks ok, but why is it needed? You are fixing a bunch of warnings in one part of the source and disabling them in another part. Is there some other change incoming that will enable more warning categories by default? /Erik On 2020-08-25 11:47, Joe Wang wrote: Cc-ing build-dev@openjdk.java.net (makefile change: make/Docs.gmk) Updated webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ Thanks Roger! Please see inline comments. On 8/25/20 8:09 AM, Roger Riggs wrote: Hi Joe, Eliminating the checking for warnings in org.w3c is fine. Please be more specific in the comment. "Ignore the doclint warnings in the W3C DOM package" Updated. org/xml/...: If we're suppressing the warnings for org/xml/... then the files changes are unnecessary? Did you mean org/w3c? We're only suppressing the warnings for org/w3c where the DOM package is in, but not org/xml where SAX is in. Remove the addition of -Xmaxwarns, it should stay the default. Done. Since its a makefile change, please copy build-dev@openjdk.java.net. Cc-ed The first line comments should terminate with a period ".". javax/xml/stream/FactoryConfigurationError.java:40 javax/xml/stream/XMLStreamException.java:41 javax/xml/xpath/XPathException.java:44 And capitable "Serializable". javax/xml/stream/events/Attribute.java: 50; add "normalized" to the @return line so it is the same as the first line. For simple get methods, the @return mimics the first line. javax/xml/stream/events/NotationDeclaration.java:43 add "notation" Updated webrev including all of the above: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ Thanks, Roger p.s. There is lots of other cleanup of the javadoc, using @code around true, false, missing periods at the end of first sentences, etc. But that's a different task. Created a bug to keep track of this: https://bugs.openjdk.java.net/browse/JDK-8252328 Thanks, Joe On 8/24/20 5:44 PM, Joe Wang wrote: Hi all, adding Roger's comment for the make file to webrev_02 (the only change to webrev_01 is Docs.gmk): http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_02/ Thanks, Joe On 8/21/20 12:49 PM, naoto.s...@oracle.com wrote: +1 Naoto On 8/21/20 12:24 PM, Lance Andersen wrote: Hi Joe, This looks OK. On Aug 21, 2020, at 2:23 PM, Joe Wang wrote: Pelase review a patch to add the missing @return, @throws, @param statements in the java.xml package (excluding the DOM component). JBS: https://bugs.openjdk.java.net/browse/JDK-8251561 CSR: https://bugs.openjdk.java.net/browse/JDK-8251995 webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_01/ Thanks, Joe Best Lance -- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: RFR [16/java.xml] 8251561: Fix doclint warnings in the java.xml package
Cc-ing build-dev@openjdk.java.net (makefile change: make/Docs.gmk) Updated webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ Thanks Roger! Please see inline comments. On 8/25/20 8:09 AM, Roger Riggs wrote: Hi Joe, Eliminating the checking for warnings in org.w3c is fine. Please be more specific in the comment. "Ignore the doclint warnings in the W3C DOM package" Updated. org/xml/...: If we're suppressing the warnings for org/xml/... then the files changes are unnecessary? Did you mean org/w3c? We're only suppressing the warnings for org/w3c where the DOM package is in, but not org/xml where SAX is in. Remove the addition of -Xmaxwarns, it should stay the default. Done. Since its a makefile change, please copy build-dev@openjdk.java.net. Cc-ed The first line comments should terminate with a period ".". javax/xml/stream/FactoryConfigurationError.java:40 javax/xml/stream/XMLStreamException.java:41 javax/xml/xpath/XPathException.java:44 And capitable "Serializable". javax/xml/stream/events/Attribute.java: 50; add "normalized" to the @return line so it is the same as the first line. For simple get methods, the @return mimics the first line. javax/xml/stream/events/NotationDeclaration.java:43 add "notation" Updated webrev including all of the above: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ Thanks, Roger p.s. There is lots of other cleanup of the javadoc, using @code around true, false, missing periods at the end of first sentences, etc. But that's a different task. Created a bug to keep track of this: https://bugs.openjdk.java.net/browse/JDK-8252328 Thanks, Joe On 8/24/20 5:44 PM, Joe Wang wrote: Hi all, adding Roger's comment for the make file to webrev_02 (the only change to webrev_01 is Docs.gmk): http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_02/ Thanks, Joe On 8/21/20 12:49 PM, naoto.s...@oracle.com wrote: +1 Naoto On 8/21/20 12:24 PM, Lance Andersen wrote: Hi Joe, This looks OK. On Aug 21, 2020, at 2:23 PM, Joe Wang wrote: Pelase review a patch to add the missing @return, @throws, @param statements in the java.xml package (excluding the DOM component). JBS: https://bugs.openjdk.java.net/browse/JDK-8251561 CSR: https://bugs.openjdk.java.net/browse/JDK-8251995 webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_01/ Thanks, Joe Best Lance -- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: RFR: JDK-8252145: Unify Info.plist files with correct version strings
On 2020-08-24 19:18, Sergey Bylokhov wrote: Hi, Erik. I would like to highlight one thing affected by this fix. The text in the default about dialog in the Swing application will be changed. For my local build: - Current text: "Java Version 1.0 (16)" - After the fix: "Java Version 16 (0)" I am not sure why the build version and as a result the CFBundleVersion is zero? The CFBundleVersion is supposed to have a version number representing the build number. In a developer build, the "VERSION_BUILD" variable is default 0. In a promoted build, that number is set to the promoted build number. In Oracle promoted builds, we will also have a CI build number, so if this change was in effect, the latest JDK 16 promoted build would have 12.477 in CFBundleVersion. /Erik On 24.08.2020 08:19, Erik Joelsson wrote: When fixing JDK-8246094, I concluded that our Info.plist files are in a bit of a mess. This patch tries to address this on a more fundamental level. 1. All Info.plist files and templates are moved to the same location in the source tree. 2. The CFBundleIdentifier is changed to no longer contain the version number. Instead it gets the $VERSION_PRE string if present. 3. The CFBundleShortVersionString is changed to the numeric version part of our version string. 4. The CFBundleVersion is changed to the build number (or a custom number if supplied through a new configure argument). For Oracle builds, this will take the form of .. For more details on why this particular scheme, see bug description, but in short, this is what I think best reflects what the Apple documentation says the fields are for. Bug: https://bugs.openjdk.java.net/browse/JDK-8252145 Webrev: http://cr.openjdk.java.net/~erikj/8252145/webrev.01 /Erik
Re: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU
Does this only apply when the MacBook is running on battery, or will this affect performance even when the laptop is plugged in? If the latter, I wonder what Apple's rationale is for including a discrete graphics card that isn't used most of the time. -- Kevin On 8/24/2020 11:27 PM, Sergey Bylokhov wrote: On 24.08.2020 13:35, Philip Race wrote: Is there any performance cost to doing this ? I'd expect so. Any estimate ? Yes, performance is affected for sure: - SwingMark: OGL_Base: 14000 OGL_Fix: 24000 Metal: 18000 - Here is a j2dbench for the common draw operations(new/old/metal): http://cr.openjdk.java.net/~serb/8251854/perf/results.txt Summary: OGL_base: Number of tests: 24 Overall average: 4.556306150323041E8 Best spread: 0.16% variance Worst spread: 4.68% variance (Basis for results comparison) OGL_fix: Number of tests: 24 Overall average: 1.0086929824044746E8 Best spread: 0.04% variance Worst spread: 7.89% variance Comparison to basis: Best result: 83.41% of basis Worst result: 15.73% of basis Number of wins: 0 Number of ties: 0 Number of losses: 24 metal: Number of tests: 24 Overall average: 8.841681616575797E7 Best spread: 0.08% variance Worst spread: 5.64% variance Comparison to basis: Best result: 248.11% of basis Worst result: 19.1% of basis Number of wins: 8 Number of ties: 2 Number of losses: 14 == - Here is a j2dbench for the common draw operations(newOGL vs metal only): http://cr.openjdk.java.net/~serb/8251854/perf/newOGL_vs_Metal.txt Summary: OGL_fix: Number of tests: 24 Overall average: 2.5871177969681844E7 Best spread: 0.04% variance Worst spread: 7.01% variance (Basis for results comparison) metal: Number of tests: 24 Overall average: 2.1896134898150157E7 Best spread: 0.04% variance Worst spread: 1.98% variance Comparison to basis: Best result: 488.31% of basis Worst result: 30.77% of basis Number of wins: 14 Number of ties: 0 Number of losses: 10 And there's then no way to explicitly request the discrete card on a 15/16" MBP. I have checked that the discrete card is enabled by the macOS: - if the full screen window is set - if the second monitor is connected Do not know any other ways to enable it. Should we release note this ? Yes, I think so. Note that it does not affect the bundled applications only apps running via java launcher. But some(most?) bundled java applications use this flag already.
Re: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support
Hi Erik, On 8/24/20 11:26 PM, Erik Österlund wrote: Hi Ningsheng, On 2020-08-24 11:59, Ningsheng Jian wrote: Hi Erik, Thanks for the review! On 8/22/20 12:21 AM, Erik Österlund wrote: Hi, Have you tried this with ZGC on AArch64? It has custom code for saving live registers in the load barrier slow path. I can't see any code changes there, so assuming this will just crash instead. The relevant code is in ZBarrierSetAssembler on aarch64. Maybe I missed something? I didn't add ZGC option while running tests. I think I need to update push_fp() which is called by ZSaveLiveRegisters. But do we need to get size info (float/neon/sve) instead of saving the whole vector register? Currently, it just simply saves the whole NEON register. What we found on x86_64 was that there was a significant cost in saving vector registers in load barriers. That is why we perform some analysis so that only the exact registers that are affected, and only the parts of the registers that are affected, get spilled. It actually mattered. It will of course work either way, but that was our observation on x86_64. But I am okay with that being deferred to a separate RFE. I just wanted to make sure that it at the very least works with the new code, for a start, so it doesn't start crashing. OK, I will make it to save the whole reg in this patch and have a separate RFE to optimize as what x86 does. And in ZBarrierSetAssembler::load_at(), before calling to runtime code, we call push_call_clobbered_registers_except(), which just saves floating point registers instead of the whole NEON vector registers. Similar behavior in x86 implementation. Is that correct (not saving vectors)? Yes. The call contexts are: 1) Interpreter. Does not use vector registers. 2) Method handle intrinsic. Uses only floats that are part of the Java calling convention, rest is garbage. No vectors here. 3) Checkcast arraycopy. Does not use vectors. Thanks for sharing this. Thanks, Ningsheng
Re: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU
On 24.08.2020 13:35, Philip Race wrote: Is there any performance cost to doing this ? I'd expect so. Any estimate ? Yes, performance is affected for sure: - SwingMark: OGL_Base: 14000 OGL_Fix: 24000 Metal: 18000 - Here is a j2dbench for the common draw operations(new/old/metal): http://cr.openjdk.java.net/~serb/8251854/perf/results.txt Summary: OGL_base: Number of tests: 24 Overall average: 4.556306150323041E8 Best spread: 0.16% variance Worst spread: 4.68% variance (Basis for results comparison) OGL_fix: Number of tests: 24 Overall average: 1.0086929824044746E8 Best spread: 0.04% variance Worst spread: 7.89% variance Comparison to basis: Best result: 83.41% of basis Worst result: 15.73% of basis Number of wins: 0 Number of ties: 0 Number of losses: 24 metal: Number of tests: 24 Overall average: 8.841681616575797E7 Best spread: 0.08% variance Worst spread: 5.64% variance Comparison to basis: Best result: 248.11% of basis Worst result: 19.1% of basis Number of wins: 8 Number of ties: 2 Number of losses: 14 == - Here is a j2dbench for the common draw operations(newOGL vs metal only): http://cr.openjdk.java.net/~serb/8251854/perf/newOGL_vs_Metal.txt Summary: OGL_fix: Number of tests: 24 Overall average: 2.5871177969681844E7 Best spread: 0.04% variance Worst spread: 7.01% variance (Basis for results comparison) metal: Number of tests: 24 Overall average: 2.1896134898150157E7 Best spread: 0.04% variance Worst spread: 1.98% variance Comparison to basis: Best result: 488.31% of basis Worst result: 30.77% of basis Number of wins: 14 Number of ties: 0 Number of losses: 10 And there's then no way to explicitly request the discrete card on a 15/16" MBP. I have checked that the discrete card is enabled by the macOS: - if the full screen window is set - if the second monitor is connected Do not know any other ways to enable it. Should we release note this ? Yes, I think so. Note that it does not affect the bundled applications only apps running via java launcher. But some(most?) bundled java applications use this flag already. -- Best regards, Sergey.
