Re: RFR: 8257450: Start of release updates for JDK 17 [v7]
> Start of JDK 17 updates. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: - Merge branch 'master' into JDK-8257450 - Merge branch 'master' into JDK-8257450 - Merge branch 'master' into JDK-8257450 - Get in JEP 390 changes. - Merge branch 'master' into JDK-8257450 - Merge branch 'master' into JDK-8257450 - Update symbol files for JDK 16b27. - Merge branch 'master' into JDK-8257450 - Merge branch 'master' into JDK-8257450 - Merge branch 'master' into JDK-8257450 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/bbfda542...766c2c01 - Changes: - all: https://git.openjdk.java.net/jdk/pull/1531/files - new: https://git.openjdk.java.net/jdk/pull/1531/files/57ba7b64..766c2c01 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=1531=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1531=05-06 Stats: 4920 lines in 147 files changed: 3195 ins; 1060 del; 665 mod Patch: https://git.openjdk.java.net/jdk/pull/1531.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1531/head:pull/1531 PR: https://git.openjdk.java.net/jdk/pull/1531
Re: RFR: 8257733: Move module-specific data from make to respective module [v2]
On Mon, 7 Dec 2020 14:27:45 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. >> For instance, the publicsuffixlist is used by java.base, and fontconfig by >> java.desktop. (A few directories, like mainmanifest, is *actually* used by >> make for the whole build.) >> >> These data files should move to the module they belong to. The are, after >> all, "source code" for that module that is "compiler" into resulting >> deliverables, for that module. (But the "source code" language is not Java >> or C, but typically a highly domain specific language or data format, and >> the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. >> When such data is changed, most of the time build-dev (or the new build >> label) is involved, even though this has nothing to do with the build. While >> this is annoying, a worse problem is if the actual team that needs to review >> the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [ ] java.base >> - [ ] java.desktop >> - [x] jdk.compiler >> - [ ] java.se > > Magnus Ihse Bursie has updated the pull request incrementally with one > additional commit since the last revision: > > Move to share/data, and move jdwp.spec to java.se The security-related part (cacerts, blacklisted.certs, publicsuffxlist) looks fine to me. - Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1611
Re: RFR: 8257602: Introduce JFR Event Throttling and new jdk.ObjectAllocationSample event (enabled by default)
On Mon, 7 Dec 2020 22:37:20 GMT, Mukilesh Sethu
wrote:
>> Greetings,
>>
>> please help review this enhancement to let JFR sample object allocations by
>> default.
>>
>> A description is provided in the JIRA issue.
>>
>> Thanks
>> Markus
>
> This is great! It would be awesome to have this capability.
>
> One query on the way you are throttling the events (please correct me if I'm
> wrong here as I am new to this codebase),
>
> If I understood correctly, you are throttling the events at the time of
> committing, specifically part of `should_write` or `should_commit` in
> `jfrEvent.hpp`. If so, how would we be able to add throttling to events which
> might require it early on like `ObjectCountAfterGC` or `ObjectCount` events ?
>
> I think it makes perfect sense to have it part of commit for allocation
> events because most of the time consuming tasks like stack walking or storing
> stack trace in global table is done part of event commit and we will be able
> to throttle it. However, for events like `ObjectCountAfterGC` the time
> consuming task is iterating the heap which is unavoidable if we add
> throttling part of commit. So, I am just curious how can we extend this
> solution to such events ?
Hi, @myBloodTop, thanks for your comment.
For more special events (for example periodic events), it will be possible,
although not yet supported, to use the throttling mechanism directly. For
example:
TRACE_REQUEST_FUNC(ObjectCount) {
if (JfrEventThrottler::accept(JfrObjectCountEvent)) {
VM_GC_SendObjectCountEvent op;
VMThread::execute();
}
}
Evaluating the throttle predicate as part of commit or should_commit() is an
optimization to avoid having to take the clock twice, but for cases such as the
above, if you don't pass a timestamp, a timestamp will be taken for you as part
of the evaluation.
Now, ObjectCount and ObjectCountAfterGC are also special in another respect, in
that they are UNTIMED, meaning the events are timestamped outside of JFR. For
other, non-UNTIMED events, it would be sufficient to only use the
should_commit() tester, since the throttler evaluation is incorporated (post
enable and threshold checks evaluations). For example:
MyEvent event;
...
if (event.should_commit()) { <<-- throttle evaluation
event.set_field(...);
event.commit();
}
Thanks
Markus
-
PR: https://git.openjdk.java.net/jdk/pull/1624
Re: RFR: 8257602: Introduce JFR Event Throttling and new jdk.ObjectAllocationSample event (enabled by default) [v4]
On Tue, 8 Dec 2020 16:31:37 GMT, Erik Gahlin wrote:
>> Markus Grönlund has updated the pull request incrementally with 12
>> additional commits since the last revision:
>>
>> - initialization check
>> - thread locals and detach and reattach
>> - Tighter ThrottleUnit
>> - JFC control elements
>> - TLAB include
>> - ThrottleUnit enum
>> - remote tests
>> - jfc control attributes
>> - Sampling frequency adjustment for large objects
>> - Treat large objects as tlabs for sampling purposes
>> - ... and 2 more:
>> https://git.openjdk.java.net/jdk/compare/6918f0c8...4e986552
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/EventControl.java line 79:
>
>> 77: private final PlatformEventType type;
>> 78: private final String idName;
>> 79:
>
> Why move Enabled to later?
Configuring the throttler implementation in native is a bit involved. With the
existing order, with enabled first, events are enabled before subsequent
conditions are set up. For the throttler, it means as soon as the enabled
setting is flipped, the throttler gets traffic, but its not yet configured to
accept it. It has a default, which is off, meaning it accepts all events until
the subsequent call to configure the throttler which can take some time,
because the setup is non-trivial. It was found that rates are not respected
because of the throttler not having been setup yet when its starts to get
traffic.
> src/jdk.jfr/share/classes/jdk/jfr/internal/Utils.java line 229:
>
>> 227: // Expected input format is "x/y" or "x\y" where x is a
>> non-negative long
>> 228: // and y is a time unit. Split the string at the delimiter.
>> 229: private static String parseThrottleString(String s, boolean value) {
>
> I think we should only support one type of slash "/".
Fixed.
> src/jdk.jfr/share/classes/jdk/jfr/internal/Utils.java line 249:
>
>> 247: }
>> 248:
>> 249: private static TimeUnit timeUnit(String unit) {
>
> This could be done with an enum with a constructor.
Fixed.
> src/jdk.jfr/share/classes/jdk/jfr/internal/settings/ThrottleSetting.java line
> 65:
>
>> 63: @Override
>> 64: public String combine(Set values) {
>> 65: double max = OFF;
>
> Probably better to use a long (nanos) than floating number
Fixed.
> src/jdk.jfr/share/classes/jdk/jfr/internal/settings/ThrottleSetting.java line
> 88:
>
>> 86: @Override
>> 87: public void setValue(String s) {
>> 88: this.value = s;
>
> If parsing fails, I think things should be kept as is. At least that is what
> the SettingControl interface say.s
>
> I looked at other setting control and the implementation seems wrong there as
> well.
Fixed.
> src/jdk.jfr/share/conf/jfr/default.jfc line 618:
>
>> 616:
>> 617:
>> 618: true
>
> I think enabled should have the "memory-profiling" control.
Fixed.
> src/jdk.jfr/share/conf/jfr/profile.jfc line 608:
>
>> 606:
>> 607:
>> 608: > control="memory-profiling-enabled-medium">false
>
> Need to sync this with .
>
> Perhaps a new choice are needed "Object Allocation"
New control elements and attributes introduced.
-
PR: https://git.openjdk.java.net/jdk/pull/1624
Re: RFR: 8257602: Introduce JFR Event Throttling and new jdk.ObjectAllocationSample event (enabled by default) [v4]
On Wed, 9 Dec 2020 20:58:48 GMT, Markus Grönlund wrote:
>> Greetings,
>>
>> please help review this enhancement to let JFR sample object allocations by
>> default.
>>
>> A description is provided in the JIRA issue.
>>
>> Thanks
>> Markus
>
> Markus Grönlund has updated the pull request incrementally with 12 additional
> commits since the last revision:
>
> - initialization check
> - thread locals and detach and reattach
> - Tighter ThrottleUnit
> - JFC control elements
> - TLAB include
> - ThrottleUnit enum
> - remote tests
> - jfc control attributes
> - Sampling frequency adjustment for large objects
> - Treat large objects as tlabs for sampling purposes
> - ... and 2 more:
> https://git.openjdk.java.net/jdk/compare/6918f0c8...4e986552
src/jdk.jfr/share/classes/jdk/jfr/internal/EventControl.java line 79:
> 77: private final PlatformEventType type;
> 78: private final String idName;
> 79:
Why move Enabled to later?
src/jdk.jfr/share/classes/jdk/jfr/internal/Utils.java line 229:
> 227: // Expected input format is "x/y" or "x\y" where x is a non-negative
> long
> 228: // and y is a time unit. Split the string at the delimiter.
> 229: private static String parseThrottleString(String s, boolean value) {
I think we should only support one type of slash "/".
src/jdk.jfr/share/classes/jdk/jfr/internal/Utils.java line 249:
> 247: }
> 248:
> 249: private static TimeUnit timeUnit(String unit) {
This could be done with an enum with a constructor.
src/jdk.jfr/share/classes/jdk/jfr/internal/settings/ThrottleSetting.java line
65:
> 63: @Override
> 64: public String combine(Set values) {
> 65: double max = OFF;
Probably better to use a long (nanos) than floating number
src/jdk.jfr/share/classes/jdk/jfr/internal/settings/ThrottleSetting.java line
88:
> 86: @Override
> 87: public void setValue(String s) {
> 88: this.value = s;
If parsing fails, I think things should be kept as is. At least that is what
the SettingControl interface say.s
I looked at other setting control and the implementation seems wrong there as
well.
src/jdk.jfr/share/conf/jfr/default.jfc line 618:
> 616:
> 617:
> 618: true
I think enabled should have the "memory-profiling" control.
src/jdk.jfr/share/conf/jfr/profile.jfc line 608:
> 606:
> 607:
> 608:control="memory-profiling-enabled-medium">false
Need to sync this with .
Perhaps a new choice are needed "Object Allocation"
-
PR: https://git.openjdk.java.net/jdk/pull/1624
Re: RFR: 8257602: Introduce JFR Event Throttling and new jdk.ObjectAllocationSample event (enabled by default) [v4]
> Greetings, > > please help review this enhancement to let JFR sample object allocations by > default. > > A description is provided in the JIRA issue. > > Thanks > Markus Markus Grönlund has updated the pull request incrementally with 12 additional commits since the last revision: - initialization check - thread locals and detach and reattach - Tighter ThrottleUnit - JFC control elements - TLAB include - ThrottleUnit enum - remote tests - jfc control attributes - Sampling frequency adjustment for large objects - Treat large objects as tlabs for sampling purposes - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6918f0c8...4e986552 - Changes: - all: https://git.openjdk.java.net/jdk/pull/1624/files - new: https://git.openjdk.java.net/jdk/pull/1624/files/6918f0c8..4e986552 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=1624=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1624=02-03 Stats: 530 lines in 13 files changed: 174 ins; 285 del; 71 mod Patch: https://git.openjdk.java.net/jdk/pull/1624.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1624/head:pull/1624 PR: https://git.openjdk.java.net/jdk/pull/1624
Re: RFR: 8257602: Introduce JFR Event Throttling and new jdk.ObjectAllocationSample event (enabled by default)
On Fri, 4 Dec 2020 15:25:23 GMT, Markus Grönlund wrote: > Greetings, > > please help review this enhancement to let JFR sample object allocations by > default. > > A description is provided in the JIRA issue. > > Thanks > Markus This is great! It would be awesome to have this capability. One query on the way you are throttling the events (please correct me if I'm wrong here as I am new to this codebase), If I understood correctly, you are throttling the events at the time of committing, specifically part of `should_write` or `should_commit` in `jfrEvent.hpp`. If so, how would we be able to add throttling to events which might require it early on like `ObjectCountAfterGC` or `ObjectCount` events ? I think it makes perfect sense to have it part of commit for allocation events because most of the time consuming tasks like stack walking or storing stack trace in global table is done part of event commit and we will be able to throttle it. However, for events like `ObjectCountAfterGC` the time consuming task is iterating the heap which is unavoidable if we add throttling part of commit. So, I am just curious how can we extend this solution to such events ? - PR: https://git.openjdk.java.net/jdk/pull/1624
Re: RFR: 8251854: [macosx] Java forces the use of discrete GPU
On Tue, 17 Nov 2020 18:55:51 GMT, Sergey Bylokhov wrote: >> 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. > >> > @kevinrushforth @prrace could you please review? >> >> As we discussed yesterday, it is reviewed but not ready to be approved. >> We are waiting for a reply from Apple. > > @prrace > We are waiting for it for three months already. If it is possible then not > sure why other applications did not found any possible ways to force one > specific GPU. What we are wating for? @mrserb @prrace what is a back up plan in case we will not have a reply from Apple? (as we do not have it for 4! months). Definitely we need a plan B - PR: https://git.openjdk.java.net/jdk/pull/1139
Integrated: 8257973: UTIL_LOOKUP_PROGS should only find executable files
On Wed, 9 Dec 2020 14:08:32 GMT, Magnus Ihse Bursie wrote: > It turns out that UTIL_LOOKUP_PROGS does not verify that when it find a file > in the PATH that matches the given tool name, it accept it straight away. > Even if the file is a directory, or is not executable. This pull request has now been integrated. Changeset: 6c69eca3 Author:Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/6c69eca3 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8257973: UTIL_LOOKUP_PROGS should only find executable files Reviewed-by: erikj - PR: https://git.openjdk.java.net/jdk/pull/1715
Integrated: JDK-8256950: Add record attribute support to symbol generator CreateSymbols
On Fri, 27 Nov 2020 13:21:15 GMT, Jan Lahoda wrote: > Adding support for record classes in the historical data for ct.sym. This > includes a few changes not strictly needed for the change: > -updating and moving tests into test/langtools, so that it is easier to run > them. > -fixing Record attribute reading in javac's ClassReader (used for tests, but > seems like the proper thing to do anyway). > -fixing the -Xprint annotation processor to print record component > annotations. > > Changes to jdk.jdeps' classfile library are needed so that the ct.sym > creation works. This pull request has now been integrated. Changeset: 6eff9315 Author:Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/6eff9315 Stats: 1961 lines in 12 files changed: 1198 ins; 745 del; 18 mod 8256950: Add record attribute support to symbol generator CreateSymbols Reviewed-by: jjg, chegar - PR: https://git.openjdk.java.net/jdk/pull/1480
Re: RFR: JDK-8256950: Add record attribute support to symbol generator CreateSymbols [v6]
> Adding support for record classes in the historical data for ct.sym. This > includes a few changes not strictly needed for the change: > -updating and moving tests into test/langtools, so that it is easier to run > them. > -fixing Record attribute reading in javac's ClassReader (used for tests, but > seems like the proper thing to do anyway). > -fixing the -Xprint annotation processor to print record component > annotations. > > Changes to jdk.jdeps' classfile library are needed so that the ct.sym > creation works. Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision: - Need to open a few packages for the test. - Merge branch 'master' into JDK-8256950 - Blank lines do not count for the text block indentation, removing them. - Reflecting review comments. - Fixing tests on Windows - normalizing line endings. - Merge branch 'JDK-8256950' of https://github.com/lahodaj/jdk into JDK-8256950 - Update CreateSymbolsTest.java - CreateSymbols should support records with no components. - Cleaning TODO. - Cleaning TODO. - ... and 3 more: https://git.openjdk.java.net/jdk/compare/51dfede0...08d7a106 - Changes: - all: https://git.openjdk.java.net/jdk/pull/1480/files - new: https://git.openjdk.java.net/jdk/pull/1480/files/3aaaf28c..08d7a106 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=1480=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1480=04-05 Stats: 41234 lines in 1081 files changed: 28666 ins; 7705 del; 4863 mod Patch: https://git.openjdk.java.net/jdk/pull/1480.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1480/head:pull/1480 PR: https://git.openjdk.java.net/jdk/pull/1480
Re: RFR: 8257973: UTIL_LOOKUP_PROGS should only find executable files
On Wed, 9 Dec 2020 14:08:32 GMT, Magnus Ihse Bursie wrote: > It turns out that UTIL_LOOKUP_PROGS does not verify that when it find a file > in the PATH that matches the given tool name, it accept it straight away. > Even if the file is a directory, or is not executable. Marked as reviewed by erikj (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1715
Re: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version
On Wed, 2 Dec 2020 17:34:00 GMT, Anton Kozlov wrote: > Please review a small change that replaces use of objc_msgSend_stret in macOS > platform code with pure ObjC code. It's also a prerequisite for macOS/AArch64 > support, where objc_msgSend_stret is not available. Looks ok to me. But it would be good if @prrace can have a look. - Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1569
RFR: 8257973: UTIL_LOOKUP_PROGS should only find executable files
It turns out that UTIL_LOOKUP_PROGS does not verify that when it find a file in the PATH that matches the given tool name, it accept it straight away. Even if the file is a directory, or is not executable. - Commit messages: - 8257973: UTIL_LOOKUP_PROGS should only find executable files Changes: https://git.openjdk.java.net/jdk/pull/1715/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1715=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257973 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1715.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1715/head:pull/1715 PR: https://git.openjdk.java.net/jdk/pull/1715
Re: RFR: 8257450: Start of release updates for JDK 17 [v6]
On Tue, 8 Dec 2020 23:23:55 GMT, Joe Darcy wrote: >> Start of JDK 17 updates. > > Joe Darcy has updated the pull request with a new target base due to a merge > or a rebase. The incremental webrev excludes the unrelated changes brought in > by the merge/rebase. The pull request contains 14 additional commits since > the last revision: > > - Get in JEP 390 changes. > - Merge branch 'master' into JDK-8257450 > - Merge branch 'master' into JDK-8257450 > - Update symbol files for JDK 16b27. > - Merge branch 'master' into JDK-8257450 > - Merge branch 'master' into JDK-8257450 > - Merge branch 'master' into JDK-8257450 > - Update tests. > - Merge branch 'master' into JDK-8257450 > - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into > JDK-8257450 > - ... and 4 more: > https://git.openjdk.java.net/jdk/compare/5c27251d...57ba7b64 Build changes (or should I say "change"?) looks good! - Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1531
Re: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v12]
On Tue, 8 Dec 2020 19:35:03 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 with a new target base due to a merge > or a rebase. The pull request now contains 55 commits: > > - Merging recent master changes into JDK-8250768 > - Fixing navigator for the PREVIEW page. > - Fixing typo. > - Removing obsolette @PreviewFeature. > - Merging master into JDK-8250768 > - Removing unnecessary property keys. > - Cleanup - removing unnecessary code. > - Merging master into JDK-8250768-dev4 > - Reflecting review comments. > - Removing trailing whitespace. > - ... and 45 more: > https://git.openjdk.java.net/jdk/compare/044616bd...0c1c4d57 Build changes still good. - Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/703
Re: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version
On Wed, 2 Dec 2020 17:34:00 GMT, Anton Kozlov wrote: > Please review a small change that replaces use of objc_msgSend_stret in macOS > platform code with pure ObjC code. It's also a prerequisite for macOS/AArch64 > support, where objc_msgSend_stret is not available. >From a build PoV this sounds like a reasonable fix, but you need a review from >someone in core-libs as well. - PR: https://git.openjdk.java.net/jdk/pull/1569
Integrated: 8256657: Add cross-compiled build for Windows+Arm64 to submit workflow
On Mon, 23 Nov 2020 09:35:40 GMT, Bernhard Urban-Forster wrote: > This adds the cross-compiled build only, as no Windows+Arm64 machines are > available on GitHub Action that we could use to run the tests. > > Due to cross-compilation a build JDK is required. Initially I added EA builds > to be downloaded from https://jdk.java.net/16/ and used for that, but then I > saw how @shipiliv attempted it for the linux cross-compilation builds in > https://github.com/openjdk/jdk/pull/1147. That is using the JDK image > produced by the x64 variant. This however add more stress to the "critical > path", as now two more jobs depend on the x64 build first. > > Let's see how it works out in the long-run. A Windows+AArch64 build takes > 40-50min. This pull request has now been integrated. Changeset: d3dddb6a Author:Bernhard Urban-Forster Committer: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/d3dddb6a Stats: 92 lines in 1 file changed: 91 ins; 0 del; 1 mod 8256657: Add cross-compiled build for Windows+Arm64 to submit workflow Reviewed-by: shade, ihse - PR: https://git.openjdk.java.net/jdk/pull/1379
Re: RFR: 8256657: Add cross-compiled build for Windows+Arm64 to submit workflow [v5]
On Wed, 9 Dec 2020 07:22:51 GMT, Bernhard Urban-Forster wrote: >> This adds the cross-compiled build only, as no Windows+Arm64 machines are >> available on GitHub Action that we could use to run the tests. >> >> Due to cross-compilation a build JDK is required. Initially I added EA >> builds to be downloaded from https://jdk.java.net/16/ and used for that, but >> then I saw how @shipiliv attempted it for the linux cross-compilation builds >> in https://github.com/openjdk/jdk/pull/1147. That is using the JDK image >> produced by the x64 variant. This however add more stress to the "critical >> path", as now two more jobs depend on the x64 build first. >> >> Let's see how it works out in the long-run. A Windows+AArch64 build takes >> 40-50min. > > Bernhard Urban-Forster has updated the pull request with a new target base > due to a merge or a rebase. The pull request now contains 12 commits: > > - remove gtest and jtreg > - Merge remote-tracking branch 'upstream/master' into > 8256657-win-arm64-gh-submit-workflow > - merge mistakes > - change default target to hotspot and align with updated x64 bits > - remove devkit usage on win-aarch64 > - Merge remote-tracking branch 'upstream/master' into > 8256657-win-arm64-gh-submit-workflow > - todo note for caching devkit > - remove release build > - move windows_aarch64_build next to other builds > - Merge remote-tracking branch 'upstream/master' into > 8256657-win-arm64-gh-submit-workflow > - ... and 2 more: > https://git.openjdk.java.net/jdk/compare/9ce3d806...c07f5d72 Marked as reviewed by ihse (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1379
