[OpenJDK 2D-Dev] Withdrawn: 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 This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk/pull/1139
Re: [OpenJDK 2D-Dev] RFR: 8196301: java/awt/print/PrinterJob/Margins.java times out
On Wed, 17 Feb 2021 18:50:11 GMT, Phil Race wrote: > That should be irrelevant. jtreg should only be invoking tests which do NOT > have the printer keyword since the test job has this : keywords=headful & > !printer which are handed directly to jtreg. In other words it is not > filtering on whether there is actually a printer, but on whether the keyword > is present. > > So if this test is being invoked on tests which specify that then there's > something badly wrong with jtreg or the harness is mangling it. I have to change script to have keywords=headful & printer as it was not running this test in mach5 without it. - PR: https://git.openjdk.java.net/jdk/pull/2598
Re: [OpenJDK 2D-Dev] RFR: 8196301: java/awt/print/PrinterJob/Margins.java times out
On Wed, 17 Feb 2021 18:50:11 GMT, Phil Race wrote: >> Maybe @key printer is not being taken seriously during system setup which is >> why no real printer is being used. > >> Maybe @key printer is not being taken seriously during system setup which is >> why no real printer is being used. > > That should be irrelevant. jtreg should only be invoking tests which do NOT > have the printer keyword since the test job has this : keywords=headful & > !printer which are handed directly to jtreg. In other words it is not > filtering on whether there is actually a printer, but on whether the keyword > is present. > > So if this test is being invoked on tests which specify that then there's > something badly wrong with jtreg or the harness is mangling it. > > But I think this bug was filed back when this test was MISSING that keyword - > it was added here > http://hg.openjdk.java.net/jdk/client/rev/f13dba72a5ea > > So likely you should be focused on the timing issue and not the file printers As I told, I already fixed the timing issue too by moving thread start to pass ENTER keypress closer to actual pagedialog invocation and the mach5 job where all the tests passed is there in JBS. - PR: https://git.openjdk.java.net/jdk/pull/2598
Re: [OpenJDK 2D-Dev] RFR: 8196301: java/awt/print/PrinterJob/Margins.java times out
On Wed, 17 Feb 2021 18:07:27 GMT, Prasanta Sadhukhan wrote: > Maybe @key printer is not being taken seriously during system setup which is > why no real printer is being used. That should be irrelevant. jtreg should only be invoking tests which do NOT have the printer keyword since the test job has this : keywords=headful & !printer which are handed directly to jtreg. In other words it is not filtering on whether there is actually a printer, but on whether the keyword is present. So if this test is being invoked on tests which specify that then there's something badly wrong with jtreg or the harness is mangling it. But I think this bug was filed back when this test was MISSING that keyword - it was added here http://hg.openjdk.java.net/jdk/client/rev/f13dba72a5ea So likely you should be focused on the timing issue and not the file printers - PR: https://git.openjdk.java.net/jdk/pull/2598
Re: [OpenJDK 2D-Dev] RFR: 8196301: java/awt/print/PrinterJob/Margins.java times out
On Wed, 17 Feb 2021 18:02:49 GMT, Phil Race wrote: >> This test was timing out in windows in mach5 nightly testing. Investigation >> reveals that 70% of the time, it is failing due to printer being chosen was >> Microsoft Print to PDF which opens up a File Save Dialog when "OK" was >> clicked in printer pagedialog. Since no user intervention is done to dismiss >> the modal filedialog, so subsequent pagedialog was not dismissed resulting >> in timeout. >> Other times, it was found that "One Note" software printer was used as >> default printerservice which again, opens up a OneNote app which again gets >> focus and obscure pagedialog so PageDialog did not get dismissed. >> Updated test to ignore "Print To PDF", "OneNote" and "XPS Document >> Writer"(which again opens filedialog like PDF printer) and run it for >> several iteration in mach5 platforms which is ok. Link in JBS. > > The problem I have with this is that it does not scale. > It is a maintenance nightmare every possible "file printer" on Windows to > every test. > and back porting it too ? > removing or disabling one note and the rest s supposed to be part of the set > up of the test systems. > > And when you say "70%" what is the other 30 % ? other 30% is mixture of OneNote, XPS being used as printer service and timing issue which is why I moved the Thread start closer to actual pagedialog invocation. - PR: https://git.openjdk.java.net/jdk/pull/2598
Re: [OpenJDK 2D-Dev] RFR: 8196301: java/awt/print/PrinterJob/Margins.java times out
On Wed, 17 Feb 2021 18:05:41 GMT, Prasanta Sadhukhan wrote: >> The problem I have with this is that it does not scale. >> It is a maintenance nightmare every possible "file printer" on Windows to >> every test. >> and back porting it too ? >> removing or disabling one note and the rest s supposed to be part of the set >> up of the test systems. >> >> And when you say "70%" what is the other 30 % ? > > other 30% is mixture of OneNote, XPS being used as printer service and timing > issue which is why I moved the Thread start closer to actual pagedialog > invocation. Maybe @key printer is not being taken seriously during system setup which is why no real printer is being used. - PR: https://git.openjdk.java.net/jdk/pull/2598
Re: [OpenJDK 2D-Dev] RFR: 8196301: java/awt/print/PrinterJob/Margins.java times out
On Wed, 17 Feb 2021 03:21:03 GMT, Prasanta Sadhukhan wrote: > This test was timing out in windows in mach5 nightly testing. Investigation > reveals that 70% of the time, it is failing due to printer being chosen was > Microsoft Print to PDF which opens up a File Save Dialog when "OK" was > clicked in printer pagedialog. Since no user intervention is done to dismiss > the modal filedialog, so subsequent pagedialog was not dismissed resulting in > timeout. > Other times, it was found that "One Note" software printer was used as > default printerservice which again, opens up a OneNote app which again gets > focus and obscure pagedialog so PageDialog did not get dismissed. > Updated test to ignore "Print To PDF", "OneNote" and "XPS Document > Writer"(which again opens filedialog like PDF printer) and run it for several > iteration in mach5 platforms which is ok. Link in JBS. The problem I have with this is that it does not scale. It is a maintenance nightmare every possible "file printer" on Windows to every test. and back porting it too ? removing or disabling one note and the rest s supposed to be part of the set up of the test systems. And when you say "70%" what is the other 30 % ? - PR: https://git.openjdk.java.net/jdk/pull/2598
Re: [OpenJDK 2D-Dev] RFR: 8196301: java/awt/print/PrinterJob/Margins.java times out
On Wed, 17 Feb 2021 17:34:22 GMT, Alexander Zuev wrote: >> This test was timing out in windows in mach5 nightly testing. Investigation >> reveals that 70% of the time, it is failing due to printer being chosen was >> Microsoft Print to PDF which opens up a File Save Dialog when "OK" was >> clicked in printer pagedialog. Since no user intervention is done to dismiss >> the modal filedialog, so subsequent pagedialog was not dismissed resulting >> in timeout. >> Other times, it was found that "One Note" software printer was used as >> default printerservice which again, opens up a OneNote app which again gets >> focus and obscure pagedialog so PageDialog did not get dismissed. >> Updated test to ignore "Print To PDF", "OneNote" and "XPS Document >> Writer"(which again opens filedialog like PDF printer) and run it for >> several iteration in mach5 platforms which is ok. Link in JBS. > > Shouldn't you update copyright years in the header of the test? No, it's not mandatory to update the copyright year as there is script that should update it at end of release. - PR: https://git.openjdk.java.net/jdk/pull/2598
Re: [OpenJDK 2D-Dev] RFR: 8196301: java/awt/print/PrinterJob/Margins.java times out
On Wed, 17 Feb 2021 03:21:03 GMT, Prasanta Sadhukhan wrote: > This test was timing out in windows in mach5 nightly testing. Investigation > reveals that 70% of the time, it is failing due to printer being chosen was > Microsoft Print to PDF which opens up a File Save Dialog when "OK" was > clicked in printer pagedialog. Since no user intervention is done to dismiss > the modal filedialog, so subsequent pagedialog was not dismissed resulting in > timeout. > Other times, it was found that "One Note" software printer was used as > default printerservice which again, opens up a OneNote app which again gets > focus and obscure pagedialog so PageDialog did not get dismissed. > Updated test to ignore "Print To PDF", "OneNote" and "XPS Document > Writer"(which again opens filedialog like PDF printer) and run it for several > iteration in mach5 platforms which is ok. Link in JBS. Shouldn't you update copyright years in the header of the test? - PR: https://git.openjdk.java.net/jdk/pull/2598
Re: [OpenJDK 2D-Dev] RFR: 6206189: Graphics2D.clip specifies incorrectly that a 'null' is a valid value for this method [v10]
On Wed, 17 Feb 2021 15:55:04 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one >> additional commit since the last revision: >> >> javadoc change > > Marked as reviewed by aivanov (Reviewer). Thanks @aivanov-jdk . Would you mind adding yourself as a reviewer to the CSR? - PR: https://git.openjdk.java.net/jdk/pull/2476
Re: [OpenJDK 2D-Dev] RFR: 6206189: Graphics2D.clip specifies incorrectly that a 'null' is a valid value for this method [v10]
On Wed, 17 Feb 2021 15:54:22 GMT, Prasanta Sadhukhan wrote: >> The API doc for Graphics2D.clip(shape s) claims that passing a null argument >> would actually clear the existing clipping area, which is incorrect. >> This statement is applicable only to G2D.setClip() and not for the clip() >> method. G2D.clip() would throw a NullPointerException when it encounters a >> null argument. >> Updated spec to rectify this. > > Prasanta Sadhukhan has updated the pull request incrementally with one > additional commit since the last revision: > > javadoc change Marked as reviewed by aivanov (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2476
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v8]
On Tue, 16 Feb 2021 06:24:05 GMT, Vladimir Kempik wrote: >> This is when passing a float, yes? In the case where we have more float >> arguments than n_float_register_parameters_c. >> I don't understand why you think it's acceptable to bail in this case. Can >> you explain, please? > > it's for everything that uses less than 8 bytes on a stack( ints ( 4), > shorts(2), bytes(1), floats(4)). > currently native wrapper generation does not support such cases at all, it > needs refactoring before this can be implemented. > So when a method has more argument than can be placed in registers, we may > have issues. > > So we just bailing out to interpreter in case when a smaller (<=4 b) type is > going to be passed thru the stack. > > There was attempt to implement handling such cases but currently it requires > some hacks (like using some vectors for non-specific task) - > https://github.com/openjdk/aarch64-port/pull/3 OK. I checked and the Panama preview doesn't support direct native calls for stack arguments, so we're good for now. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v18]
On Mon, 15 Feb 2021 17:45:32 GMT, Anton Kozlov wrote: >> I'm not sure it can wait. This change turns already-messy code into >> something significantly messier, to the extent that it's not really good >> enough to go into mainline. > > The latest merge with JDK-8261071 should resolve the issue. Please take a > look. Looks much better, thanks. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 6206189: Graphics2D.clip specifies incorrectly that a 'null' is a valid value for this method [v9]
On Wed, 17 Feb 2021 15:48:12 GMT, Prasanta Sadhukhan
wrote:
>> The API doc for Graphics2D.clip(shape s) claims that passing a null argument
>> would actually clear the existing clipping area, which is incorrect.
>> This statement is applicable only to G2D.setClip() and not for the clip()
>> method. G2D.clip() would throw a NullPointerException when it encounters a
>> null argument.
>> Updated spec to rectify this.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one
> additional commit since the last revision:
>
> javadoc change
src/java.desktop/share/classes/java/awt/Graphics2D.java line 1207:
> 1205: * with the current clip, it will throw {@code NullPointerException}
> 1206: * for a null shape unless the user clip is also {@code null}.
> 1207: * So calling this method with a {@code null} argument is not
> recommended.
I wonder why not “{@code null} shape” at line 1206?
-
PR: https://git.openjdk.java.net/jdk/pull/2476
Re: [OpenJDK 2D-Dev] RFR: 6206189: Graphics2D.clip specifies incorrectly that a 'null' is a valid value for this method [v10]
> The API doc for Graphics2D.clip(shape s) claims that passing a null argument > would actually clear the existing clipping area, which is incorrect. > This statement is applicable only to G2D.setClip() and not for the clip() > method. G2D.clip() would throw a NullPointerException when it encounters a > null argument. > Updated spec to rectify this. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: javadoc change - Changes: - all: https://git.openjdk.java.net/jdk/pull/2476/files - new: https://git.openjdk.java.net/jdk/pull/2476/files/a9bc437b..e447b562 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2476=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2476=08-09 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2476.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2476/head:pull/2476 PR: https://git.openjdk.java.net/jdk/pull/2476
Re: [OpenJDK 2D-Dev] RFR: 6206189: Graphics2D.clip specifies incorrectly that a 'null' is a valid value for this method [v8]
On Wed, 17 Feb 2021 15:38:10 GMT, Prasanta Sadhukhan
wrote:
>> The API doc for Graphics2D.clip(shape s) claims that passing a null argument
>> would actually clear the existing clipping area, which is incorrect.
>> This statement is applicable only to G2D.setClip() and not for the clip()
>> method. G2D.clip() would throw a NullPointerException when it encounters a
>> null argument.
>> Updated spec to rectify this.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one
> additional commit since the last revision:
>
> javadoc change
src/java.desktop/share/classes/java/awt/Graphics2D.java line 1207:
> 1205: * with the current clip, it will throw {@code NullPointerException}
> 1206: * for a null shape unless the user clip is also {@code null}.
> 1207: * So calling this method with a null argument is not recommended.
This suggestion still applies too.
Suggestion:
* for a {@code null} shape unless the user clip is also {@code null}.
* So calling this method with a {@code null} argument is not recommended.
-
PR: https://git.openjdk.java.net/jdk/pull/2476
Re: [OpenJDK 2D-Dev] RFR: 6206189: Graphics2D.clip specifies incorrectly that a 'null' is a valid value for this method [v9]
> The API doc for Graphics2D.clip(shape s) claims that passing a null argument > would actually clear the existing clipping area, which is incorrect. > This statement is applicable only to G2D.setClip() and not for the clip() > method. G2D.clip() would throw a NullPointerException when it encounters a > null argument. > Updated spec to rectify this. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: javadoc change - Changes: - all: https://git.openjdk.java.net/jdk/pull/2476/files - new: https://git.openjdk.java.net/jdk/pull/2476/files/3a1faf33..a9bc437b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2476=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2476=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2476.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2476/head:pull/2476 PR: https://git.openjdk.java.net/jdk/pull/2476
Re: [OpenJDK 2D-Dev] RFR: 6206189: Graphics2D.clip specifies incorrectly that a 'null' is a valid value for this method [v7]
On Wed, 17 Feb 2021 15:25:35 GMT, Alexey Ivanov wrote:
>> Prasanta Sadhukhan has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> javadoc change
>
> src/java.desktop/share/classes/java/awt/Graphics2D.java line 1206:
>
>> 1204: * with the current clip, it will throw {@code
>> NullPointerException}
>> 1205: * for a null shape unless the user clip is also {@code null}.
>> 1206: * So calling this method with a null argument is not recommended.
>
> Since you're editing the javadoc for this method, wouldn't adding a couple
> `` break up the description to make it clearer?
>
> 1198 * The user clip modified by this method is independent of
> the
> 1203 * user clip.
> * Since this method intersects the specified shape
> The rendered javadoc will have clear separation between different paragraphs
> and will facilitate scanning the method description.
>
> Does it make any sense?
ok. sure...
-
PR: https://git.openjdk.java.net/jdk/pull/2476
Re: [OpenJDK 2D-Dev] RFR: 6206189: Graphics2D.clip specifies incorrectly that a 'null' is a valid value for this method [v8]
> The API doc for Graphics2D.clip(shape s) claims that passing a null argument > would actually clear the existing clipping area, which is incorrect. > This statement is applicable only to G2D.setClip() and not for the clip() > method. G2D.clip() would throw a NullPointerException when it encounters a > null argument. > Updated spec to rectify this. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: javadoc change - Changes: - all: https://git.openjdk.java.net/jdk/pull/2476/files - new: https://git.openjdk.java.net/jdk/pull/2476/files/530cad4d..3a1faf33 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2476=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2476=06-07 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2476.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2476/head:pull/2476 PR: https://git.openjdk.java.net/jdk/pull/2476
Re: [OpenJDK 2D-Dev] RFR: 6206189: Graphics2D.clip specifies incorrectly that a 'null' is a valid value for this method [v7]
On Wed, 17 Feb 2021 15:08:58 GMT, Prasanta Sadhukhan
wrote:
>> The API doc for Graphics2D.clip(shape s) claims that passing a null argument
>> would actually clear the existing clipping area, which is incorrect.
>> This statement is applicable only to G2D.setClip() and not for the clip()
>> method. G2D.clip() would throw a NullPointerException when it encounters a
>> null argument.
>> Updated spec to rectify this.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one
> additional commit since the last revision:
>
> javadoc change
src/java.desktop/share/classes/java/awt/Graphics2D.java line 1206:
> 1204: * with the current clip, it will throw {@code NullPointerException}
> 1205: * for a null shape unless the user clip is also {@code null}.
> 1206: * So calling this method with a null argument is not recommended.
Suggestion:
* for a {@code null} shape unless the user clip is also {@code null}.
* So calling this method with a {@code null} argument is not recommended.
src/java.desktop/share/classes/java/awt/Graphics2D.java line 1206:
> 1204: * with the current clip, it will throw {@code NullPointerException}
> 1205: * for a null shape unless the user clip is also {@code null}.
> 1206: * So calling this method with a null argument is not recommended.
Since you're editing the javadoc for this method, wouldn't adding a couple
`` break up the description to make it clearer?
1198 * The user clip modified by this method is independent of the
1203 * user clip.
* Since this method intersects the specified shape
The rendered javadoc will have clear separation between different paragraphs
and will facilitate scanning the method description.
Does it make any sense?
-
PR: https://git.openjdk.java.net/jdk/pull/2476
Re: [OpenJDK 2D-Dev] RFR: 6206189: Graphics2D.clip specifies incorrectly that a 'null' is a valid value for this method [v6]
On Wed, 17 Feb 2021 14:20:47 GMT, Alexey Ivanov wrote:
>> Prasanta Sadhukhan has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> javdoc tag for NPE
>
> src/java.desktop/share/classes/java/awt/Graphics2D.java line 1205:
>
>> 1203: * user clip. Since this method intersects the specified shape
>> 1204: * with the current clip, it will throw {@code
>> NullPointerException} for a null shape
>> 1205: * unless the user clip is also null.
>
> Shall the text be re-wrapped?
>
> I'm not sure if null should always be {@code null}, it's not used
> consistently. At the same time, two lines above it's “…with a {@code null}
> argument…”; it makes sense to make Javadoc consistent in this regard at least
> for one method.
ok .fair enough...done..
-
PR: https://git.openjdk.java.net/jdk/pull/2476
Re: [OpenJDK 2D-Dev] RFR: 6206189: Graphics2D.clip specifies incorrectly that a 'null' is a valid value for this method [v7]
> The API doc for Graphics2D.clip(shape s) claims that passing a null argument > would actually clear the existing clipping area, which is incorrect. > This statement is applicable only to G2D.setClip() and not for the clip() > method. G2D.clip() would throw a NullPointerException when it encounters a > null argument. > Updated spec to rectify this. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: javadoc change - Changes: - all: https://git.openjdk.java.net/jdk/pull/2476/files - new: https://git.openjdk.java.net/jdk/pull/2476/files/0951a478..530cad4d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2476=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2476=05-06 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2476.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2476/head:pull/2476 PR: https://git.openjdk.java.net/jdk/pull/2476
Re: [OpenJDK 2D-Dev] RFR: 6206189: Graphics2D.clip specifies incorrectly that a 'null' is a valid value for this method [v6]
On Mon, 15 Feb 2021 12:48:01 GMT, Prasanta Sadhukhan
wrote:
>> The API doc for Graphics2D.clip(shape s) claims that passing a null argument
>> would actually clear the existing clipping area, which is incorrect.
>> This statement is applicable only to G2D.setClip() and not for the clip()
>> method. G2D.clip() would throw a NullPointerException when it encounters a
>> null argument.
>> Updated spec to rectify this.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one
> additional commit since the last revision:
>
> javdoc tag for NPE
src/java.desktop/share/classes/java/awt/Graphics2D.java line 1205:
> 1203: * user clip. Since this method intersects the specified shape
> 1204: * with the current clip, it will throw {@code
> NullPointerException} for a null shape
> 1205: * unless the user clip is also null.
Shall the text be re-wrapped?
I'm not sure if null should always be {@code null}, it's not used consistently.
At the same time, two lines above it's “…with a {@code null} argument…”; it
makes sense to make Javadoc consistent in this regard at least for one method.
-
PR: https://git.openjdk.java.net/jdk/pull/2476
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Tue, 2 Feb 2021 22:42:22 GMT, Daniel D. Daugherty wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> support macos_aarch64 in hsdis
>
> src/hotspot/share/logging/logStream.hpp line 35:
>
>> 33: class LogStream : public outputStream {
>> 34: // see test/hotspot/gtest/logging/test_logStream.cpp
>> 35: friend class LogStreamTest;
>
> It's not clear why this change is made for this port.
This was done for previous implementation of W^X, for gtests be able to access
this test. This not required anymore, this hunk was reverted.
-
PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Mon, 15 Feb 2021 16:21:53 GMT, Bernhard Urban-Forster wrote: >> This is the version of w^x on-demand switch implemented by microsoft guys. >> This is enabled only for debug builds. >> @lewurm could you comment here please > > Those values can be observed in the debugger, but aren't documented or > defined in header files. > > This mode was useful for the initial bootstrap of the platform (it helped > with missing W^X transitions), but shouldn't be required anymore today. I'm > fine with removing it altogether. OK, I'm going to remove this block. So we'll be able to revert changes in globals.hpp https://github.com/openjdk/jdk/pull/2200/files#r568986339 - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Tue, 2 Feb 2021 21:51:56 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional >> commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 31: > >> 29: #include "asm/assembler.inline.hpp" >> 30: #include "oops/compressedOops.hpp" >> 31: #include "runtime/vm_version.hpp" > > It's not clear why this include needed to be added. Line 448 calls `VM_Version::features()`. It seems the declaration is included indirectly somehow on the rest of the platforms, through OS specific headers. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v18]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 88 commits: - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos - Re-do safefetch.hpp - Merge remote-tracking branch 'origin/jdk/8261075-stubroutines-inline' into jdk-macos - stubRoutines.inline.hpp -> safefetch.hpp - Update copyrights - Merge remote-tracking branch 'upstream/jdk/master' into 8261075-stubroutines-inline - Merge remote-tracking branch 'upstream/jdk/master' into 8261075-stubroutines-inline - Extract SafeFetch32/N to stubRoutines.inline.hpp - Revert "Extract SafeFetch32/N to stubRoutines.inline.hpp" This reverts commit b873c25f31dd21349d140b790713cc9ccb5f2dc0. - Merge pull request #9 from VladimirKempik/pull/2200 Removed unused variables - ... and 78 more: https://git.openjdk.java.net/jdk/compare/b955f85e...ab72613c - Changes: https://git.openjdk.java.net/jdk/pull/2200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2200=17 Stats: 2946 lines in 74 files changed: 2861 ins; 27 del; 58 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
