Re: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v11]
On Fri, 6 Nov 2020 18:41:15 GMT, Jan Lahoda wrote: >> This is an update to javac and javadoc, to introduce support for Preview >> APIs, and generally improve javac and javadoc behavior to more closely >> adhere to JEP 12. >> >> The notable changes are: >> >> * adding support for Preview APIs (javac until now supported primarily only >> preview language features, and APIs associated with preview language >> features). This includes: >> * the @PreviewFeature annotation has boolean attribute "reflective", >> which should be true for reflective Preview APIs, false otherwise. This >> replaces the existing "essentialAPI" attribute with roughly inverted meaning. >> * the preview warnings for preview APIs are auto-suppressed as >> described in the JEP 12. E.g. the module that declares the preview API is >> free to use it without warnings >> * improving error/warning messages. Please see [1] for a list of >> cases/examples. >> * class files are only marked as preview if they are using a preview >> feature. [1] also shows if a class file is marked as preview or not. >> * the PreviewFeature annotation has been moved to jdk.internal.javac >> package (originally was in the jdk.internal package). >> * Preview API in JDK's javadoc no longer needs to specify @preview tag in >> the source files. javadoc will auto-generate a note for @PreviewFeature >> elements, see e.g. [2] and [3] (non-reflective and reflective API, >> respectively). A summary of preview elements is also provided [4]. Existing >> uses of @preview have been updated/removed. >> * non-JDK javadoc is also enhanced to auto-generate preview notes for uses >> of Preview elements, and for declaring elements using preview language >> features [5]. >> >> Please also see the CSR [6] for more information. >> >> [1] >> http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html >> [2] >> http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html >> [3] >> http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html >> [4] >> http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html >> [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ >> [6] https://bugs.openjdk.java.net/browse/JDK-8250769 > > Jan Lahoda has updated the pull request incrementally with one additional > commit since the last revision: > > Fixing navigator for the PREVIEW page. I have a mild queasiness about this new overloaded use of the word "Summary", since "summary tables" are normally the summary of the contents of a declaration, like fields and methods of a class. That being said, the usage is primarily internal, and I have no overwhelmingly wonderful alternative, and (overloading aside) the term is accurate. So, OK for now. We can change it later if we want to. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2949: > 2947: > 2948: /** > 2949: * Return the set of preview language features used to declare the > given element. "Returns" - Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/703
Re: RFR: 8255822: Zero: improve build-time JVMTI handling [v3]
On Tue, 10 Nov 2020 12:33:34 GMT, David Holmes wrote: >> Aleksey Shipilev has updated the pull request with a new target base due to >> a merge or a rebase. The pull request now contains six commits: >> >> - Simplify a few JVMTI_ENABLED blocks >> - Merge branch 'master' into JDK-8255822-zero-jvmti-rework >> - Fix build error >> - Merge branch 'master' into JDK-8255822-zero-jvmti-rework >> - Revert one dubious change >> - 8255822: Zero: improve build-time JVMTI handling >>Summary: use C++ templates instead of XSLT transforms > > Still good. Thanks! - PR: https://git.openjdk.java.net/jdk/pull/1061
Integrated: 8255822: Zero: improve build-time JVMTI handling
On Wed, 4 Nov 2020 16:29:27 GMT, Aleksey Shipilev wrote: > Current Zero interpreter has the optimization for JVMTI support. It > recognizes that JVMTI is disabled most of the time, and that JVMTI checks in > the interpreter code slows it down considerably. (I measured it myself when > working on this patch: removing this optimization yields about 20% hit in > build times). > > Current optimization works as follows. At build time, an XSLT transform is > performed on `bytecodeInterpreter.cpp`, yielding > `bytecodeInterpreterWithChecks.cpp`. In that new compilation unit, `VM_JVMTI` > macro is defined, and a new entry point -- `BytecodeInterpreter::withChecks` > -- is defined. Then, both compilation units are compiled. In one of them, > `JVMTI` hooks are stripped out. In another, they persist. Then, callers have > to choose which entry point to use. > > I believe this can be rewritten to use C++ templates instead of XLST and > defines dance. This also allows to clean up JVMTI checks a bit. > > Additional testing: > - [x] Linux x86_64 Zero fastdebug build with `-jvmti` > - [x] Linux x86_64 Zero fastdebug/release build times are not regressing This pull request has now been integrated. Changeset: 643969a1 Author:Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/643969a1 Stats: 188 lines in 6 files changed: 5 ins; 128 del; 55 mod 8255822: Zero: improve build-time JVMTI handling Reviewed-by: dholmes, ihse - PR: https://git.openjdk.java.net/jdk/pull/1061
Re: RFR: 8251854: [macosx] Java forces the use of discrete GPU
On Tue, 10 Nov 2020 16:38:25 GMT, Kevin Rushforth wrote: >> Change looks ok from a build point of view, but I can't comment on the >> validity and implications of using this key. > > I ran a 3D lighting test that is designed to be a GPU stress test. It's a > worst case, to be sure, but it take 10 times as long to render with the > integrated GPU as it does with the discrete GPU: > > **attenuation.LightingSample: 500 large quads** > discrete GPU: 23.5 fps > integrated GPU: 2.34 fps > > In a more realistic example of drawing a large number of 2D vectors, it runs > 35% slower with the integrated GPU: > > **Vector charting test, oval clip** > discrete GPU: 41.1 fps > integrated GPU: 26.6 fps > > I see similar results in the performance numbers you listed above. > > An application developer who packages up their JDK, for example, using > jpackage, can make the decision for themselves. Application developers who > rely on the JDK as delivered will get whatever we choose as the default. So > we need to be sure that the benefit of doing this justifies the performance > hit. The difference between the two is that, if the integrated card is default then it is possible to force the discrete card if needed, but it is not possible to force the integrated card if discrete is the default. In the end, it is a laptop, it will work longer on an integrated card. - PR: https://git.openjdk.java.net/jdk/pull/1139
Re: RFR: 8251854: [macosx] Java forces the use of discrete GPU
On Tue, 10 Nov 2020 13:24:21 GMT, Erik Joelsson wrote: >> This is a review request for the bug particularly fixed some time ago: >> https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html >> >> In that review request it was found that the old fix does not work well in >> all cases, see: >> https://mail.openjdk.java.net/pipermail/2d-dev/2015-August/005611.html >> >> The current fix updates an embedded plist.info, so the java will not require >> discrete graphics by default, same as for any other applications. >> >> The discrete card will be used: >> 1. If macOS decided to enable it for some reason >> 2. If the java app sets/uses a full-screen window >> 3. If the user disable "automatic graphics switching" in the system >> preferences >> 4. If an external monitor is connected to the laptop >> >> In other cases, the integrated graphics will be used, which should be fine >> in most cases since this graphic is used/tested in the mbp 13/etc. This is >> not only about rendering performance but also about startup performance, on >> my current new laptop mbp 16 + Cataline 10.15.7 the switching >> discrete/integrated causes unexpected delays up to 10 seconds. >> >> >> Note that the new "metal" pipeline also does not require discrete graphics. >> >> The documentation for NSSupportsAutomaticGraphicsSwitching: >> https://developer.apple.com/documentation/bundleresources/information_property_list/nssupportsautomaticgraphicsswitching >> >> I'll create a release note after approval. >> >> Performance numbers: >> https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010979.html >> Old review request: >> https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010973.html > > Change looks ok from a build point of view, but I can't comment on the > validity and implications of using this key. I ran a 3D lighting test that is designed to be a GPU stress test. It's a worst case, to be sure, but it take 10 times as long to render with the integrated GPU as it does with the discrete GPU: **attenuation.LightingSample: 500 large quads** discrete GPU: 23.5 fps integrated GPU: 2.34 fps In a more realistic example of drawing a large number of 2D vectors, it runs 35% slower with the integrated GPU: **Vector charting test, oval clip** discrete GPU: 41.1 fps integrated GPU: 26.6 fps I see similar results in the performance numbers you listed above. An application developer who packages up their JDK, for example, using jpackage, can make the decision for themselves. Application developers who rely on the JDK as delivered will get whatever we choose as the default. So we need to be sure that the benefit of doing this justifies the performance hit. - PR: https://git.openjdk.java.net/jdk/pull/1139
Re: RFR: 8251854: [macosx] Java forces the use of discrete GPU
On Tue, 10 Nov 2020 08:19:13 GMT, Sergey Bylokhov wrote: > This is a review request for the bug particularly fixed some time ago: > https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html > > In that review request it was found that the old fix does not work well in > all cases, see: > https://mail.openjdk.java.net/pipermail/2d-dev/2015-August/005611.html > > The current fix updates an embedded plist.info, so the java will not require > discrete graphics by default, same as for any other applications. > > The discrete card will be used: > 1. If macOS decided to enable it for some reason > 2. If the java app sets/uses a full-screen window > 3. If the user disable "automatic graphics switching" in the system > preferences > 4. If an external monitor is connected to the laptop > > In other cases, the integrated graphics will be used, which should be fine in > most cases since this graphic is used/tested in the mbp 13/etc. This is not > only about rendering performance but also about startup performance, on my > current new laptop mbp 16 + Cataline 10.15.7 the switching > discrete/integrated causes unexpected delays up to 10 seconds. > > > Note that the new "metal" pipeline also does not require discrete graphics. > > The documentation for NSSupportsAutomaticGraphicsSwitching: > https://developer.apple.com/documentation/bundleresources/information_property_list/nssupportsautomaticgraphicsswitching > > I'll create a release note after approval. > > Performance numbers: > https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010979.html > Old review request: > https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010973.html Change looks ok from a build point of view, but I can't comment on the validity and implications of using this key. - Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1139
Re: RFR: 8251854: [macosx] Java forces the use of discrete GPU
On Tue, 10 Nov 2020 08:19:13 GMT, Sergey Bylokhov wrote: > This is a review request for the bug particularly fixed some time ago: > https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html > > In that review request it was found that the old fix does not work well in > all cases, see: > https://mail.openjdk.java.net/pipermail/2d-dev/2015-August/005611.html > > The current fix updates an embedded plist.info, so the java will not require > discrete graphics by default, same as for any other applications. > > The discrete card will be used: > 1. If macOS decided to enable it for some reason > 2. If the java app sets/uses a full-screen window > 3. If the user disable "automatic graphics switching" in the system > preferences > 4. If an external monitor is connected to the laptop > > In other cases, the integrated graphics will be used, which should be fine in > most cases since this graphic is used/tested in the mbp 13/etc. This is not > only about rendering performance but also about startup performance, on my > current new laptop mbp 16 + Cataline 10.15.7 the switching > discrete/integrated causes unexpected delays up to 10 seconds. > > > Note that the new "metal" pipeline also does not require discrete graphics. > > The documentation for NSSupportsAutomaticGraphicsSwitching: > https://developer.apple.com/documentation/bundleresources/information_property_list/nssupportsautomaticgraphicsswitching > > I'll create a release note after approval. > > Performance numbers: > https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010979.html > Old review request: > https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010973.html I'm still somewhat unsure whether we want to do this in all cases. As mentioned offline, the discrete GPU will be unused (might as well not be there) for almost all Java applications when using a single screen. When the MacBook Pro is running on battery, this seems like a good thing, but when it is plugged in, it seems like we wasting the discrete GPU. It's too bad Apple doesn't provide a way for an application to hint whether they would like to use the discrete GPU if available. I want to run some performance tests with JavaFX, since it will likely impact JavaFX applications. - PR: https://git.openjdk.java.net/jdk/pull/1139
Re: RFR: 8255822: Zero: improve build-time JVMTI handling [v3]
On Tue, 10 Nov 2020 07:22:07 GMT, Aleksey Shipilev wrote: >> Current Zero interpreter has the optimization for JVMTI support. It >> recognizes that JVMTI is disabled most of the time, and that JVMTI checks in >> the interpreter code slows it down considerably. (I measured it myself when >> working on this patch: removing this optimization yields about 20% hit in >> build times). >> >> Current optimization works as follows. At build time, an XSLT transform is >> performed on `bytecodeInterpreter.cpp`, yielding >> `bytecodeInterpreterWithChecks.cpp`. In that new compilation unit, >> `VM_JVMTI` macro is defined, and a new entry point -- >> `BytecodeInterpreter::withChecks` -- is defined. Then, both compilation >> units are compiled. In one of them, `JVMTI` hooks are stripped out. In >> another, they persist. Then, callers have to choose which entry point to use. >> >> I believe this can be rewritten to use C++ templates instead of XLST and >> defines dance. This also allows to clean up JVMTI checks a bit. >> >> Additional testing: >> - [x] Linux x86_64 Zero fastdebug build with `-jvmti` >> - [x] Linux x86_64 Zero fastdebug/release build times are not regressing > > Aleksey Shipilev has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains six commits: > > - Simplify a few JVMTI_ENABLED blocks > - Merge branch 'master' into JDK-8255822-zero-jvmti-rework > - Fix build error > - Merge branch 'master' into JDK-8255822-zero-jvmti-rework > - Revert one dubious change > - 8255822: Zero: improve build-time JVMTI handling >Summary: use C++ templates instead of XSLT transforms Still good. - Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1061
Integrated: 8256048: Incomplete gitignore setting for netbeans project
On Mon, 9 Nov 2020 12:07:37 GMT, Jie Fu wrote: > Hi all, > > The gitignore setting for netbeans project seems to be incomplete. > Only nbproject/private/ [1] is ignored. > > But there are also other files under nbproject/, which should be ignored too. > > $ tree -L 1 nbproject/ > nbproject/ > ├── configurations.xml > ├── private > └── project.xml > > > It would be better to fix it. > > Thanks. > Best regards, > Jie > > > [1] https://github.com/openjdk/jdk/blob/master/.gitignore#L5 This pull request has now been integrated. Changeset: 52805f52 Author:Jie Fu URL: https://git.openjdk.java.net/jdk/commit/52805f52 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8256048: Incomplete gitignore setting for netbeans project Reviewed-by: erikj - PR: https://git.openjdk.java.net/jdk/pull/1122
Re: Preliminary review for new WINENV support
Hi Bernhard, Thank you for you efforts in keeping this patch viable and getting it closer to integration! I have no intention of letting this bitrot. The patch is, still, blocked by major simplifications I made: * There is no support for the javac server * There is no support for building without absolute pathnames This functionality is a must-have. The good news is that there is a relative clear way forward for me to achieve both of these, which in both cases involves fixing the code base: to simplify how we pass arguments to the javac server and how we build without absolute pathnames on Windows. And in both cases these will be good additions in their own right. After that, all irregularities must be fixed, so there is no regression in terms of building functionality or major performance regressions on already supported platforms. Expanding to support new compilation combinations is certainly a nice addition, but not one that's required for an initial checkin. I apologize for the slow progress on this patch. Due to personal and family issues, I am unfortunately unable to work on the OpenJDK build as much as I'd like, and the time I can spend is somewhat unpredictable. But I can assure you that this patch is important for me as well, and I'm trying to prioritize it as much as I can. /Magnus On 2020-11-10 11:01, Bernhard Urban-Forster wrote: Hello Magnus, Sorry for the late reply! This is awesome work and I don't want to see that to bit rot :-) I rebased your changes on top of current master: https://github.com/openjdk/jdk/compare/master...lewurm:winenv-testing This branch is by no means ready to be reviewed, it's just whatever I've used to do my experiments. Also note that it was a bit painful to merge the changes in toolchain_windows.m4 due to the renaming. While I agree that toolchain_microsoft.m4 is the better name, I suggest to defer that change to a later point. I've tested the following scenarios: 1. cygwin on x86_64 to build x86_64 2. cygwin on x86_64 to build arm64 3. WSL1 on x86_64 to build x86_64 4. WSL1 on x86_64 to build arm64 5. WSL2 on x86_64 to build x86_64 6. WSL1 on arm64 to build arm64 Some context: Microsoft doesn't ship native Arm64 binaries for the VS toolchain (yet). Instead one can run x86 binaries via xtajit (a binary translator), but as one can imagine this comes with some performance penalty. Cygwin is also not available on Arm64. Cygwin already being slow, it made sense to avoid running Cygwin x86 on Arm64, and instead go the cross-compilation route in the OpenJDK build for Windows+Arm64. Previously the OpenJDK build did not support cross-compiling on Windows. Even today, on openjdk/jdk:master a dirty workaround for fixpath.exe is needed to build Windows+Arm64 ( https://github.com/openjdk/jdk/pull/212#issuecomment-695024586 ). So we have been very excited to see this WINENV patch :-) Here are comments for each scenario. == ## 1. cygwin on x86_64 to build x86_64 == ``` $ bash configure --with-devkit=/cygdrive/c/work/VS2019-16.6.1-devkit --with-build-devkit=/cygdrive/c/work/VS2019-16.6.1-devkit --with-boot-jdk=/cygdrive/c/work/jdk-16+22 --openjdk-target=aarch64-unknown-cygwin configure: Configuration created at Mon Nov 9 21:33:42 CET 2020. checking for basename... /usr/bin/basename checking for dirname... /usr/bin/dirname checking for file... /usr/bin/file checking for ldd... /usr/bin/ldd checking for bash... /usr/bin/bash checking for cat... /usr/bin/cat checking for chmod... /usr/bin/chmod checking for cp... /usr/bin/cp checking for cut... /usr/bin/cut checking for date... /usr/bin/date checking for gdiff... /cygdrive/c/work/winenv-cygwin/build/.configure-support/generated-configure.sh: line 10043: test: too many arguments /cygdrive/c/work/winenv-cygwin/build/.configure-support/generated-configure.sh: line 10047: test: too many arguments /cygdrive/c/work/winenv-cygwin/build/.configure-support/generated-configure.sh: line 10043: test: too many arguments /cygdrive/c/work/winenv-cygwin/build/.configure-support/generated-configure.sh: line 10047: test: too many arguments /cygdrive/c/work/winenv-cygwin/build/.configure-support/generated-configure.sh: line 10043: test: too many arguments /cygdrive/c/work/winenv-cygwin/build/.configure-support/generated-configure.sh: line 10047: test: too many arguments /cygdrive/c/work/winenv-cygwin/build/.configure-support/generated-configure.sh: line 10043: test: /cygdrive/c/Program: binary operator expected /cygdrive/c/work/winenv-cygwin/build/.configure-support/generated-configure.sh: line 10047: test: /cygdrive/c/Program: binary operator expected /cygdrive/c/work/winenv-cygwin/build/.configure-support/generated-configure.sh: line 10043: test: too many arguments /cygdrive/c/work/winenv-cygwin/build/.configure-support/generated-configure.sh: line 10047: test: too many arguments [not found] [...] ``` I didn
Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator) [v26]
On Mon, 9 Nov 2020 16:07:13 GMT, Maurizio Cimadamore wrote: >> This patch contains the changes associated with the third incubation round >> of the foreign memory access API incubation (see JEP 393 [1]). This >> iteration focus on improving the usability of the API in 3 main ways: >> >> * first, by providing a way to obtain truly *shared* segments, which can be >> accessed and closed concurrently from multiple threads >> * second, by providing a way to register a memory segment against a >> `Cleaner`, so as to have some (optional) guarantee that the memory will be >> deallocated, eventually >> * third, by not requiring users to dive deep into var handles when they >> first pick up the API; a new `MemoryAccess` class has been added, which >> defines several useful dereference routines; these are really just thin >> wrappers around memory access var handles, but they make the barrier of >> entry for using this API somewhat lower. >> >> A big conceptual shift that comes with this API refresh is that the role of >> `MemorySegment` and `MemoryAddress` is not the same as it used to be; it >> used to be the case that a memory address could (sometimes, not always) have >> a back link to the memory segment which originated it; additionally, memory >> access var handles used `MemoryAddress` as a basic unit of dereference. >> >> This has all changed as per this API refresh; now a `MemoryAddress` is just >> a dumb carrier which wraps a pair of object/long addressing coordinates; >> `MemorySegment` has become the star of the show, as far as dereferencing >> memory is concerned. You cannot dereference memory if you don't have a >> segment. This improves usability in a number of ways - first, it is a lot >> easier to wrap native addresses (`long`, essentially) into a >> `MemoryAddress`; secondly, it is crystal clear what a client has to do in >> order to dereference memory: if a client has a segment, it can use that; >> otherwise, if the client only has an address, it will have to create a >> segment *unsafely* (this can be done by calling >> `MemoryAddress::asSegmentRestricted`). >> >> A list of the API, implementation and test changes is provided below. If >> you have any questions, or need more detailed explanations, I (and the rest >> of the Panama team) will be happy to point at existing discussions, and/or >> to provide the feedback required. >> >> A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without >> whom the work on shared memory segment would not have been possible; also >> I'd like to thank Paul Sandoz, whose insights on API design have been very >> helpful in this journey. >> >> Thanks >> Maurizio >> >> Javadoc: >> >> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html >> >> Specdiff: >> >> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html >> >> CSR: >> >> https://bugs.openjdk.java.net/browse/JDK-8254163 >> >> >> >> ### API Changes >> >> * `MemorySegment` >> * drop factory for restricted segment (this has been moved to >> `MemoryAddress`, see below) >> * added a no-arg factory for a native restricted segment representing >> entire native heap >> * rename `withOwnerThread` to `handoff` >> * add new `share` method, to create shared segments >> * add new `registerCleaner` method, to register a segment against a cleaner >> * add more helpers to create arrays from a segment e.g. `toIntArray` >> * add some `asSlice` overloads (to make up for the fact that now segments >> are more frequently used as cursors) >> * rename `baseAddress` to `address` (so that `MemorySegment` can implement >> `Addressable`) >> * `MemoryAddress` >> * drop `segment` accessor >> * drop `rebase` method and replace it with `segmentOffset` which returns >> the offset (a `long`) of this address relative to a given segment >> * `MemoryAccess` >> * New class supporting several static dereference helpers; the helpers are >> organized by carrier and access mode, where a carrier is one of the usual >> suspect (a Java primitive, minus `boolean`); the access mode can be simple >> (e.g. access base address of given segment), or indexed, in which case the >> accessor takes a segment and either a low-level byte offset,or a high level >> logical index. The classification is reflected in the naming scheme (e.g. >> `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`). >> * `MemoryHandles` >> * drop `withOffset` combinator >> * drop `withStride` combinator >> * the basic memory access handle factory now returns a var handle which >> takes a `MemorySegment` and a `long` - from which it is easy to derive all >> the other handles using plain var handle combinators. >> * `Addressable` >> * This is a new interface which is attached to entities which can be >> projected to a `MemoryAddress`. For now, both `MemoryAddress` and >> `MemorySegme
Re: Preliminary review for new WINENV support
Hello Magnus, Sorry for the late reply! This is awesome work and I don't want to see that to bit rot :-) I rebased your changes on top of current master: https://github.com/openjdk/jdk/compare/master...lewurm:winenv-testing This branch is by no means ready to be reviewed, it's just whatever I've used to do my experiments. Also note that it was a bit painful to merge the changes in toolchain_windows.m4 due to the renaming. While I agree that toolchain_microsoft.m4 is the better name, I suggest to defer that change to a later point. I've tested the following scenarios: 1. cygwin on x86_64 to build x86_64 2. cygwin on x86_64 to build arm64 3. WSL1 on x86_64 to build x86_64 4. WSL1 on x86_64 to build arm64 5. WSL2 on x86_64 to build x86_64 6. WSL1 on arm64 to build arm64 Some context: Microsoft doesn't ship native Arm64 binaries for the VS toolchain (yet). Instead one can run x86 binaries via xtajit (a binary translator), but as one can imagine this comes with some performance penalty. Cygwin is also not available on Arm64. Cygwin already being slow, it made sense to avoid running Cygwin x86 on Arm64, and instead go the cross-compilation route in the OpenJDK build for Windows+Arm64. Previously the OpenJDK build did not support cross-compiling on Windows. Even today, on openjdk/jdk:master a dirty workaround for fixpath.exe is needed to build Windows+Arm64 ( https://github.com/openjdk/jdk/pull/212#issuecomment-695024586 ). So we have been very excited to see this WINENV patch :-) Here are comments for each scenario. == ## 1. cygwin on x86_64 to build x86_64 == ``` $ bash configure --with-devkit=/cygdrive/c/work/VS2019-16.6.1-devkit --with-build-devkit=/cygdrive/c/work/VS2019-16.6.1-devkit --with-boot-jdk=/cygdrive/c/work/jdk-16+22 --openjdk-target=aarch64-unknown-cygwin configure: Configuration created at Mon Nov 9 21:33:42 CET 2020. checking for basename... /usr/bin/basename checking for dirname... /usr/bin/dirname checking for file... /usr/bin/file checking for ldd... /usr/bin/ldd checking for bash... /usr/bin/bash checking for cat... /usr/bin/cat checking for chmod... /usr/bin/chmod checking for cp... /usr/bin/cp checking for cut... /usr/bin/cut checking for date... /usr/bin/date checking for gdiff... /cygdrive/c/work/winenv-cygwin/build/.configure-support/generated-configure.sh: line 10043: test: too many arguments /cygdrive/c/work/winenv-cygwin/build/.configure-support/generated-configure.sh: line 10047: test: too many arguments /cygdrive/c/work/winenv-cygwin/build/.configure-support/generated-configure.sh: line 10043: test: too many arguments /cygdrive/c/work/winenv-cygwin/build/.configure-support/generated-configure.sh: line 10047: test: too many arguments /cygdrive/c/work/winenv-cygwin/build/.configure-support/generated-configure.sh: line 10043: test: too many arguments /cygdrive/c/work/winenv-cygwin/build/.configure-support/generated-configure.sh: line 10047: test: too many arguments /cygdrive/c/work/winenv-cygwin/build/.configure-support/generated-configure.sh: line 10043: test: /cygdrive/c/Program: binary operator expected /cygdrive/c/work/winenv-cygwin/build/.configure-support/generated-configure.sh: line 10047: test: /cygdrive/c/Program: binary operator expected /cygdrive/c/work/winenv-cygwin/build/.configure-support/generated-configure.sh: line 10043: test: too many arguments /cygdrive/c/work/winenv-cygwin/build/.configure-support/generated-configure.sh: line 10047: test: too many arguments [not found] [...] ``` I didn't investigate it any further, as this has already been reported on the mailing list. = ## 2. cygwin on x86_64 to build arm64 = ``` $ bash configure --with-devkit=/cygdrive/c/work/VS2019-16.6.1-devkit --with-build-devkit=/cygdrive/c/work/VS2019-16.6.1-devkit --with-boot-jdk=/cygdrive/c/work/jdk-16+22 --openjdk-target=aarch64-unknown-cygwin ``` Same as scenario 1) ## 3. WSL1 on x86_64 to build x86_64 I do get some weird permission errors, so I run everything with sudo (chmod -R $user doesn't help): ``` $ sudo bash configure --with-build-devkit="/mnt/c/work/VS2019-16.6.1-devkit" --with-devkit="/mnt/c/work/VS2019-16.6.1-devkit" --with-boot-jdk="/mnt/c/work/jdk-16+22" [...] Configuration summary: * Debug level:release * HS debug level: product * JVM variants: server * JVM features: server: 'aot cds compiler1 compiler2 epsilongc g1gc graal jfr jni-check jvmci jvmti management nmt parallelgc serialgc services shenandoahgc vm-structs zgc' * OpenJDK target: OS: windows, CPU architecture: x86, address length: 64 * Version string: 16-internal+0-adhoc.root.winenv-wsl1 (16-internal) Tools summary: * Environment:wsl1 version 4.4.0-19041-Microsoft, #488-Microsoft Mon Sep 01 13:43:00 PST 2020 (Ubuntu 20.04.1 LTS); window
RFR: 8251854: [macosx] Java forces the use of discrete GPU
This is a review request for the bug particularly fixed some time ago: https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html In that review request it was found that the old fix does not work well in all cases, see: https://mail.openjdk.java.net/pipermail/2d-dev/2015-August/005611.html The current fix updates an embedded plist.info, so the java will not require discrete graphics by default, same as for any other applications. The discrete card will be used: 1. If macOS decided to enable it for some reason 2. If the java app sets/uses a full-screen window 3. If the user disable "automatic graphics switching" in the system preferences 4. If an external monitor is connected to the laptop In other cases, the integrated graphics will be used, which should be fine in most cases since this graphic is used/tested in the mbp 13/etc. This is not only about rendering performance but also about startup performance, on my current new laptop mbp 16 + Cataline 10.15.7 the switching discrete/integrated causes unexpected delays up to 10 seconds. Note that the new "metal" pipeline also does not require discrete graphics. The documentation for NSSupportsAutomaticGraphicsSwitching: https://developer.apple.com/documentation/bundleresources/information_property_list/nssupportsautomaticgraphicsswitching I'll create a release note after approval. Performance numbers: https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010979.html Old review request: https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010973.html - Commit messages: - Initial fix Changes: https://git.openjdk.java.net/jdk/pull/1139/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1139&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251854 Stats: 6 lines in 3 files changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1139.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1139/head:pull/1139 PR: https://git.openjdk.java.net/jdk/pull/1139
