Re: RFR: JDK-8306441: Two-stage Segmented Heap Dump [v10]
> ### Motivation and proposal > Hi, heap dump brings about pauses for application's execution(STW), this is a > well-known pain. JDK-8252842 have added parallel support to heapdump in an > attempt to alleviate this issue. However, all concurrent threads > competitively write heap data to the same file, and more memory is required > to maintain the concurrent buffer queue. In experiments, we did not feel a > significant performance improvement from that. > > The minor-pause solution, which is presented in this PR, is a two-stage > segmented heap dump: > > 1. Stage One(STW): Concurrent threads directly write data to multiple heap > files. > 2. Stage Two(Non-STW): Merge multiple heap files into one complete heap dump > file. > > Now concurrent worker threads are not required to maintain a buffer queue, > which would result in more memory overhead, nor do they need to compete for > locks. The changes in the overall design are as follows: > >  > Fig1. Before > >  > Fig1. After this patch > > ### Performance evaluation > | memory | numOfThread | STW | Total | Compression | > | --- | - | -- | | | > | 8g | 1 thread | 15.612 secs | 15.612 secs | N | > | 8g | 32 thread | 2.5617250 secs | 14.498 secs | N | > | 8g | 32 thread | 2.3084878 secs | 3.198 secs | Compress1 | > | 8g | 32 thread | 10.9355128 secs | 21.882 secs | Compress2 | > | 8g | 96 thread | 2.6790452 secs | 14.012 secs | N | > | 8g | 96 thread | 2.3044796 secs | 3.589 secs | Compress1 | > | 8g | 96 thread | 9.7585151 secs | 20.219 secs| Compress2 | > | 16g | 1 thread | 26.278 secs | 26.278 secs | N | > | 16g | 32 thread | 5.2313740 secs | 26.417 secs | N | > | 16g | 32 thread | 5.6946983 secs | 6.538 secs | Compress1 | > | 16g | 32 thread | 21.8211105 secs | 41.133 secs | Compress2 | > | 16g | 96 thread | 6.2445556 secs | 27.141 secs | N | > | 16g | 96 thread | 4.6007096 secs | 6.259 secs | Compress1 | > | 16g | 96 thread | 19.2965783 secs | 39.007 secs | Compress2 | > | 32g | 1 thread | 48.149 secs | 48.149 secs | N | > | 32g | 32 thread | 10.7734677 secs | 61.643 secs | N | > | 32g | 32 thread | 10.1642097 secs | 10.903 secs | Compress1 | > | 32g | 32 thread | 43.8407607 secs | 88.152 secs | Compress2 | > | 32g | 96 thread | 13.1522042 secs | 61.432 secs | N | > | 32g | 96 thread | 9.0954641 secs | 9.885 secs | C... Yi Yang has updated the pull request incrementally with one additional commit since the last revision: whitespace - Changes: - all: https://git.openjdk.org/jdk/pull/13667/files - new: https://git.openjdk.org/jdk/pull/13667/files/04f54d9a..2280159a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13667&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13667&range=08-09 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13667.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13667/head:pull/13667 PR: https://git.openjdk.org/jdk/pull/13667
Re: RFR: JDK-8306441: Two-stage Segmented Heap Dump [v9]
> ### Motivation and proposal > Hi, heap dump brings about pauses for application's execution(STW), this is a > well-known pain. JDK-8252842 have added parallel support to heapdump in an > attempt to alleviate this issue. However, all concurrent threads > competitively write heap data to the same file, and more memory is required > to maintain the concurrent buffer queue. In experiments, we did not feel a > significant performance improvement from that. > > The minor-pause solution, which is presented in this PR, is a two-stage > segmented heap dump: > > 1. Stage One(STW): Concurrent threads directly write data to multiple heap > files. > 2. Stage Two(Non-STW): Merge multiple heap files into one complete heap dump > file. > > Now concurrent worker threads are not required to maintain a buffer queue, > which would result in more memory overhead, nor do they need to compete for > locks. The changes in the overall design are as follows: > >  > Fig1. Before > >  > Fig1. After this patch > > ### Performance evaluation > | memory | numOfThread | STW | Total | Compression | > | --- | - | -- | | | > | 8g | 1 thread | 15.612 secs | 15.612 secs | N | > | 8g | 32 thread | 2.5617250 secs | 14.498 secs | N | > | 8g | 32 thread | 2.3084878 secs | 3.198 secs | Compress1 | > | 8g | 32 thread | 10.9355128 secs | 21.882 secs | Compress2 | > | 8g | 96 thread | 2.6790452 secs | 14.012 secs | N | > | 8g | 96 thread | 2.3044796 secs | 3.589 secs | Compress1 | > | 8g | 96 thread | 9.7585151 secs | 20.219 secs| Compress2 | > | 16g | 1 thread | 26.278 secs | 26.278 secs | N | > | 16g | 32 thread | 5.2313740 secs | 26.417 secs | N | > | 16g | 32 thread | 5.6946983 secs | 6.538 secs | Compress1 | > | 16g | 32 thread | 21.8211105 secs | 41.133 secs | Compress2 | > | 16g | 96 thread | 6.2445556 secs | 27.141 secs | N | > | 16g | 96 thread | 4.6007096 secs | 6.259 secs | Compress1 | > | 16g | 96 thread | 19.2965783 secs | 39.007 secs | Compress2 | > | 32g | 1 thread | 48.149 secs | 48.149 secs | N | > | 32g | 32 thread | 10.7734677 secs | 61.643 secs | N | > | 32g | 32 thread | 10.1642097 secs | 10.903 secs | Compress1 | > | 32g | 32 thread | 43.8407607 secs | 88.152 secs | Compress2 | > | 32g | 96 thread | 13.1522042 secs | 61.432 secs | N | > | 32g | 96 thread | 9.0954641 secs | 9.885 secs | C... Yi Yang has updated the pull request incrementally with one additional commit since the last revision: review from Alex - Changes: - all: https://git.openjdk.org/jdk/pull/13667/files - new: https://git.openjdk.org/jdk/pull/13667/files/c8e80e9e..04f54d9a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13667&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13667&range=07-08 Stats: 152 lines in 1 file changed: 78 ins; 70 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13667.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13667/head:pull/13667 PR: https://git.openjdk.org/jdk/pull/13667
Re: RFR: 8304478: Initial nroff manpage generation for JDK 22
On Wed, 14 Jun 2023 06:08:59 GMT, Alan Bateman wrote: >> Updated the version to 22-ea and year to 2024. >> >> The following unpublished changes will also be included in this update: >> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool >> manpage contains a special character >> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update >> jarsigner man page after >> [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410) >> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) >> Deprecate jdeps -profile option >> >> The following changes, to `javac.1`, were never applied to the closed >> sources and are "lost" by this update. These changes will need to be >> re-applied directly in JDK 21 and JDK 22: >> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): >> java.lang.NoClassDefFoundError exception on running fully legitimate code >> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check >> for calling overridable methods from a constructor >> >> Thanks. > > Looks fine. Thanks @AlanBateman ! - PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1590531861
Re: RFR: 8304478: Initial nroff manpage generation for JDK 22
On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes wrote: > Updated the version to 22-ea and year to 2024. > > The following unpublished changes will also be included in this update: > - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage > contains a special character > - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update > jarsigner man page after > [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410) > - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) > Deprecate jdeps -profile option > > The following changes, to `javac.1`, were never applied to the closed sources > and are "lost" by this update. These changes will need to be re-applied > directly in JDK 21 and JDK 22: > - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): > java.lang.NoClassDefFoundError exception on running fully legitimate code > - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check > for calling overridable methods from a constructor > > Thanks. Looks fine. - Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14462#pullrequestreview-1478549017
RFR: 8304478: Initial nroff manpage generation for JDK 22
Updated the version to 22-ea and year to 2024. The following unpublished changes will also be included in this update: - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410) - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option The following changes were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22: - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor Thanks. - Commit messages: - 8304478: Initial nroff manpage generation for JDK 22 Changes: https://git.openjdk.org/jdk/pull/14462/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14462&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304478 Stats: 140 lines in 28 files changed: 1 ins; 105 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/14462.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14462/head:pull/14462 PR: https://git.openjdk.org/jdk/pull/14462
Re: RFR: 8309663: test fails "assert(check_alignment(result)) failed: address not aligned: 0x00000008baadbabe"
On Wed, 14 Jun 2023 01:02:09 GMT, Alex Menkov wrote: > If virtual thread has frames in stackChunks, need to apply load barriers > before processing nmethods (javaVFrame::locals() and > javaVFrame::expressions() do it internally) > > Testing: tier1-tier5 (still in progress); > 400 runs of VThreadStackRefTest.java test on linux-x64 and linux-x64-debug > with "-XX:+UseZGC -Xcomp -XX:-TieredCompilation" added serviceability as it was not added automatically - PR Comment: https://git.openjdk.org/jdk/pull/14460#issuecomment-1590288091
Integrated: 8309878: Reduce inclusion of resolvedIndyEntry.hpp
On Mon, 12 Jun 2023 19:52:36 GMT, Ioi Lam wrote: > resolvedIndyEntry.hpp was added in > [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995) and is included in > the popular cpCache.hpp. As a result, resolvedIndyEntry.hpp is included in > 807 out of about 1160 hotspot .o files. > > The contents of resolvedIndyEntry.hpp is infrequently used. Its inclusion > should be moved from cpCache.hpp to cpCache.inline.hpp. This improves hotspot > build time. > > After this PR, resolvedIndyEntry.hpp is included in only 30 hotspot .o files. This pull request has now been integrated. Changeset: 5d193193 Author:Ioi Lam URL: https://git.openjdk.org/jdk/commit/5d193193a3a4c519e7b3d77b27e6b2bf1b11c7f9 Stats: 86 lines in 35 files changed: 61 ins; 13 del; 12 mod 8309878: Reduce inclusion of resolvedIndyEntry.hpp Reviewed-by: coleenp, sspitsyn, matsaave - PR: https://git.openjdk.org/jdk/pull/14427
Re: RFR: 8309878: Reduce inclusion of resolvedIndyEntry.hpp
On Mon, 12 Jun 2023 22:24:26 GMT, Serguei Spitsyn wrote: >> resolvedIndyEntry.hpp was added in >> [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995) and is included >> in the popular cpCache.hpp. As a result, resolvedIndyEntry.hpp is included >> in 807 out of about 1160 hotspot .o files. >> >> The contents of resolvedIndyEntry.hpp is infrequently used. Its inclusion >> should be moved from cpCache.hpp to cpCache.inline.hpp. This improves >> hotspot build time. >> >> After this PR, resolvedIndyEntry.hpp is included in only 30 hotspot .o files. > > Looks good. > Thanks, > Serguei Thanks @sspitsyn @coleenp @matias9927 for the review. - PR Comment: https://git.openjdk.org/jdk/pull/14427#issuecomment-1590238854
Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v4]
On Tue, 13 Jun 2023 22:09:40 GMT, Justin Lu wrote: >> Please review this PR which updates the JDK's localized resources since the >> previous L10n translation drop (1/26). >> >> To help with reviewing the changes, @jonathan-gibbons created a tool which >> displays the localized changes next to the original file's changes in UTF-8 >> native. Those files can be viewed >> [here](https://cr.openjdk.org/~jlu/output/) >> >> For example, >> >> > src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3";> >> >> >> Please note that the HTML files only apply to .properties, and not .java >> resources. > > Justin Lu has updated the pull request incrementally with three additional > commits since the last revision: > > - Review: correct previous commit, remove 标 as well > - Review: Remove 本机 from 'javac.opt.Xlint.desc.output-file-clash' for zh_CN > - Review: Use old 'err.crash' zh_CN value Looks good, Justin - Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14430#pullrequestreview-1478236336
Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
On Tue, 13 Jun 2023 20:56:31 GMT, Weijun Wang wrote: >> Justin Lu has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Revert 'main.help.opt.any.file' value for _de > > Some comments: > > - `src/java.base/share/classes/sun/launcher/resources/launcher` > > `非 private`. "private" should be translated, just like the "static" in the > 2nd box. > > - `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler` > > `compiler.err.annotation.unrecognized.attribute.name`: Here "annotation" is > translated to "注释"? How do you translate "comment"? > > `compiler.err.enum.label.must.be.enum.constant`: "constant" should be > translated. > > `compiler.warn.possible.this.escape`, > `compiler.warn.possible.this.escape.location`: "escape" might not mean "转义". > It's more like its original meaning "run away" or "referenced". > > > - `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac`: > > `javac.opt.Xlint.desc.output-file-clash`: "native header files" is translated > into "本机标头文件". The "本机" is strange, I'd rather just say "头文件" as there is no > non-native header file. > > - `src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap` > > I don't think the new translation is better than the old one. Thank you for the review @wangweij, I have addressed these recommendations > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac`: > > > `javac.opt.Xlint.desc.output-file-clash`: "native header files" is translated > into "本机标头文件". The "本机" is strange, I'd rather just say "头文件" as there is no > non-native header file. > > * `src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap` > > > I don't think the new translation is better than the old one. For the other comments, I will bring them to the language specialist for updated translations. Ideally we can get those in for this translation drop, but if not, they can go in during the second translation drop during RDP2. I am also hesitant to make too many manual changes, as they will just get overwritten by the tool in the future, so it's best to get it fixed in the tool first. - PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1590087839
Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v4]
> Please review this PR which updates the JDK's localized resources since the > previous L10n translation drop (1/26). > > To help with reviewing the changes, @jonathan-gibbons created a tool which > displays the localized changes next to the original file's changes in UTF-8 > native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) > > For example, > > src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3";> > > > Please note that the HTML files only apply to .properties, and not .java > resources. Justin Lu has updated the pull request incrementally with three additional commits since the last revision: - Review: correct previous commit, remove 标 as well - Review: Remove 本机 from 'javac.opt.Xlint.desc.output-file-clash' for zh_CN - Review: Use old 'err.crash' zh_CN value - Changes: - all: https://git.openjdk.org/jdk/pull/14430/files - new: https://git.openjdk.org/jdk/pull/14430/files/7801eefb..f7c06512 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14430.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14430/head:pull/14430 PR: https://git.openjdk.org/jdk/pull/14430
Re: RFR: JDK-8306441: Two-stage Segmented Heap Dump [v8]
On Tue, 6 Jun 2023 02:35:30 GMT, Yi Yang wrote:
>> ### Motivation and proposal
>> Hi, heap dump brings about pauses for application's execution(STW), this is
>> a well-known pain. JDK-8252842 have added parallel support to heapdump in an
>> attempt to alleviate this issue. However, all concurrent threads
>> competitively write heap data to the same file, and more memory is required
>> to maintain the concurrent buffer queue. In experiments, we did not feel a
>> significant performance improvement from that.
>>
>> The minor-pause solution, which is presented in this PR, is a two-stage
>> segmented heap dump:
>>
>> 1. Stage One(STW): Concurrent threads directly write data to multiple heap
>> files.
>> 2. Stage Two(Non-STW): Merge multiple heap files into one complete heap dump
>> file.
>>
>> Now concurrent worker threads are not required to maintain a buffer queue,
>> which would result in more memory overhead, nor do they need to compete for
>> locks.
>>
>> ### Performance evaluation
>> | memory | numOfThread | STW | Total | Compression |
>> | --- | - | -- | | |
>> | 8g | 1 thread | 15.612 secs | 15.612 secs | N |
>> | 8g | 32 thread | 2.5617250 secs | 14.498 secs | N |
>> | 8g | 32 thread | 2.3084878 secs | 3.198 secs | Compress1 |
>> | 8g | 32 thread | 10.9355128 secs | 21.882 secs | Compress2 |
>> | 8g | 96 thread | 2.6790452 secs | 14.012 secs | N |
>> | 8g | 96 thread | 2.3044796 secs | 3.589 secs | Compress1 |
>> | 8g | 96 thread | 9.7585151 secs | 20.219 secs| Compress2 |
>> | 16g | 1 thread | 26.278 secs | 26.278 secs | N |
>> | 16g | 32 thread | 5.2313740 secs | 26.417 secs | N |
>> | 16g | 32 thread | 5.6946983 secs | 6.538 secs | Compress1 |
>> | 16g | 32 thread | 21.8211105 secs | 41.133 secs | Compress2 |
>> | 16g | 96 thread | 6.2445556 secs | 27.141 secs | N |
>> | 16g | 96 thread | 4.6007096 secs | 6.259 secs | Compress1 |
>> | 16g | 96 thread | 19.2965783 secs | 39.007 secs | Compress2 |
>> | 32g | 1 thread | 48.149 secs | 48.149 secs | N |
>> | 32g | 32 thread | 10.7734677 secs | 61.643 secs | N |
>> | 32g | 32 thread | 10.1642097 secs | 10.903 secs | Compress1 |
>> | 32g | 32 thread | 43.8407607 secs | 88.152 secs | Compress2 |
>> | 32g | 96 thread | 13.1522042 secs | 61.432 secs | N |
>> | 32g | 96 thread | 9.0954641 secs | 9.885 secs | Compress1 |
>> | 32g | 96 thread | 38.9900931 secs | 80.574 secs | Compress2 |
>> | 64g | 1 thread | 100.583 secs | 100.583 secs | N |
>> | 64g | 32 thread | 20.9233744 secs | 134.701 secs | N |
>> | 64g | 32 thread | 18.5023784 secs | 19.358 secs | Compre...
>
> Yi Yang has updated the pull request incrementally with one additional commit
> since the last revision:
>
> undo refactor -- done
It looks good in general. I added some change requests.
src/hotspot/share/services/heapDumper.cpp line 577:
> 575: _in_dump_segment = true;
> 576: _is_huge_sub_record = len > buffer_size() - dump_segment_header_size;
> 577: ResourceMark rm;
Looks like redundant leftover from development
src/hotspot/share/services/heapDumper.cpp line 1892:
> 1890: }
> 1891:
> 1892: static int volatile dump_seq = 0;
Could you please convert this global variable to field of VM_HeapDumper.
The value can be passed to VM_HeapDumpMerge as ctor argument
src/hotspot/share/services/heapDumper.cpp line 1894:
> 1892: static int volatile dump_seq = 0;
> 1893:
> 1894: void VM_HeapDumpMerge::merge_done() {
Implementation of VM_HeapDumpMerge methods is in the middle of VM_HeapDumper
methods.
Please put them after VM_HeapDumpMerge declaration (as we have for all other
classes)
-
PR Review: https://git.openjdk.org/jdk/pull/13667#pullrequestreview-1478097941
PR Review Comment: https://git.openjdk.org/jdk/pull/13667#discussion_r1228735182
PR Review Comment: https://git.openjdk.org/jdk/pull/13667#discussion_r1228728069
PR Review Comment: https://git.openjdk.org/jdk/pull/13667#discussion_r1228731666
Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
On Tue, 13 Jun 2023 19:59:28 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Revert 'main.help.opt.any.file' value for _de > > src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_ja.properties > line 63: > >> 61: >> FileChooser.newFolderExistsError.textAndMnemonic=\u305D\u306E\u540D\u524D\u306F\u3059\u3067\u306B\u4F7F\u7528\u3055\u308C\u3066\u3044\u307E\u3059 >> 62: FileChooser.chooseButton.textAndMnemonic=\u9078\u629E >> 63: >> FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629E\u3057\u305F\u30D5\u30A1\u30A4\u30EB\u3092\u8FFD\u52A0\u3057\u307E\u3059 > > Suggestion: > > FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629e\u3055\u308c\u3066\u3044\u308b\u30d5\u30a1\u30a4\u30eb\u3092\u9078\u629e\u3057\u307e\u3059 Thank you Naoto, all your recommended translations have been updated. The HTML diffs have also been updated as well. - PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228692234
Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v3]
> Please review this PR which updates the JDK's localized resources since the > previous L10n translation drop (1/26). > > To help with reviewing the changes, @jonathan-gibbons created a tool which > displays the localized changes next to the original file's changes in UTF-8 > native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) > > For example, > > src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3";> > > > Please note that the HTML files only apply to .properties, and not .java > resources. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Review: use Naoto's recommended ja values - Changes: - all: https://git.openjdk.org/jdk/pull/14430/files - new: https://git.openjdk.org/jdk/pull/14430/files/8ee7bf88..7801eefb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=01-02 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/14430.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14430/head:pull/14430 PR: https://git.openjdk.org/jdk/pull/14430
Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
On Mon, 12 Jun 2023 22:32:14 GMT, Justin Lu wrote: >> Please review this PR which updates the JDK's localized resources since the >> previous L10n translation drop (1/26). >> >> To help with reviewing the changes, @jonathan-gibbons created a tool which >> displays the localized changes next to the original file's changes in UTF-8 >> native. Those files can be viewed >> [here](https://cr.openjdk.org/~jlu/output/) >> >> For example, >> >> > src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3";> >> >> >> Please note that the HTML files only apply to .properties, and not .java >> resources. > > Justin Lu has updated the pull request incrementally with one additional > commit since the last revision: > > Revert 'main.help.opt.any.file' value for _de Some comments: - `src/java.base/share/classes/sun/launcher/resources/launcher` `非 private`. "private" should be translated, just like the "static" in the 2nd box. - `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler` `compiler.err.annotation.unrecognized.attribute.name`: Here "annotation" is translated to "注释"? How do you translate "comment"? `compiler.err.enum.label.must.be.enum.constant`: "constant" should be translated. `compiler.warn.possible.this.escape`, `compiler.warn.possible.this.escape.location`: "escape" might not mean "转义". It's more like its original meaning "run away" or "referenced". - `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac`: `javac.opt.Xlint.desc.output-file-clash`: "native header files" is translated into "本机标头文件". The "本机" is strange, I'd rather just say "头文件" as there is no non-native header file. - `src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap` I don't think the new translation is better than the old one. - PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1590013825
Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
On Mon, 12 Jun 2023 22:32:14 GMT, Justin Lu wrote:
>> Please review this PR which updates the JDK's localized resources since the
>> previous L10n translation drop (1/26).
>>
>> To help with reviewing the changes, @jonathan-gibbons created a tool which
>> displays the localized changes next to the original file's changes in UTF-8
>> native. Those files can be viewed
>> [here](https://cr.openjdk.org/~jlu/output/)
>>
>> For example,
>>
>> > src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3";>
>>
>>
>> Please note that the HTML files only apply to .properties, and not .java
>> resources.
>
> Justin Lu has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Revert 'main.help.opt.any.file' value for _de
Left some suggestions. Should be looked at by translators later.
src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_ja.properties line
63:
> 61:
> FileChooser.newFolderExistsError.textAndMnemonic=\u305D\u306E\u540D\u524D\u306F\u3059\u3067\u306B\u4F7F\u7528\u3055\u308C\u3066\u3044\u307E\u3059
> 62: FileChooser.chooseButton.textAndMnemonic=\u9078\u629E
> 63:
> FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629E\u3057\u305F\u30D5\u30A1\u30A4\u30EB\u3092\u8FFD\u52A0\u3057\u307E\u3059
Suggestion:
FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629e\u3055\u308c\u3066\u3044\u308b\u30d5\u30a1\u30a4\u30eb\u3092\u9078\u629e\u3057\u307e\u3059
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties
line 502:
> 500:
> compiler.warn.forward.ref=\u521D\u671F\u5316\u3055\u308C\u308B\u524D\u306E\u5909\u6570''{0}''\u3092\u53C2\u7167\u3057\u3088\u3046\u3068\u3057\u307E\u3057\u305F
> 501:
> 502:
> compiler.warn.possible.this.escape=\u30B5\u30D6\u30AF\u30E9\u30B9\u524D\u306B\u6307\u5B9A\u53EF\u80FD\u306A''this''\u30A8\u30B9\u30B1\u30FC\u30D7\u306F\u5B8C\u5168\u306B\u521D\u671F\u5316\u3055\u308C\u307E\u3059
Suggestion:
compiler.warn.possible.this.escape=\u30b5\u30d6\u30af\u30e9\u30b9\u304c\u521d\u671f\u5316\u3055\u308c\u308b\u524d\u306e''this''\u30a8\u30b9\u30b1\u30fc\u30d7\u306e\u53ef\u80fd\u6027\u304c\u3042\u308a\u307e\u3059
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties
line 504:
> 502:
> compiler.warn.possible.this.escape=\u30B5\u30D6\u30AF\u30E9\u30B9\u524D\u306B\u6307\u5B9A\u53EF\u80FD\u306A''this''\u30A8\u30B9\u30B1\u30FC\u30D7\u306F\u5B8C\u5168\u306B\u521D\u671F\u5316\u3055\u308C\u307E\u3059
> 503:
> 504:
> compiler.warn.possible.this.escape.location=\u4E8B\u524D\u306B\u6307\u5B9A\u53EF\u80FD\u306A''this''\u30A8\u30B9\u30B1\u30FC\u30D7\u306F\u547C\u51FA\u3057\u3092\u4ECB\u3057\u3066\u3053\u3053\u306B\u51FA\u73FE\u3057\u307E\u3059
Suggestion:
compiler.warn.possible.this.escape.location=\u4e8b\u524d\u306e''this''\u30a8\u30b9\u30b1\u30fc\u30d7\u306f\u3053\u306e\u547c\u3073\u51fa\u3057\u3067\u51fa\u73fe\u3057\u307e\u3059
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties
line 956:
> 954:
> compiler.err.unclosed.text.block=\u9589\u3058\u3089\u308C\u3066\u3044\u306A\u3044\u30C6\u30AD\u30B9\u30C8\u30FB\u30D6\u30ED\u30C3\u30AF
> 955:
> 956:
> compiler.err.string.template.is.not.well.formed=\u6587\u5B57\u5217\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093
Suggestion:
compiler.err.string.template.is.not.well.formed=\u6587\u5b57\u5217\u30c6\u30f3\u30d7\u30ec\u30fc\u30c8\u304c\u9069\u683c\u3067\u306f\u3042\u308a\u307e\u305b\u3093
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties
line 958:
> 956:
> compiler.err.string.template.is.not.well.formed=\u6587\u5B57\u5217\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093
> 957:
> 958:
> compiler.err.text.block.template.is.not.well.formed=\u30C6\u30AD\u30B9\u30C8\u30FB\u30D6\u30ED\u30C3\u30AF\u30FB\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093
Suggestion:
compiler.err.text.block.template.is.not.well.formed=\u30c6\u30ad\u30b9\u30c8\u30fb\u30d6\u30ed\u30c3\u30af\u30fb\u30c6\u30f3\u30d7\u30ec\u30fc\u30c8\u304c\u9069\u683c\u3067\u306f\u3042\u308a\u307e\u305b\u3093
-
Changes requested by naoto (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/14430#pullrequestreview-1477963618
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228635514
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228648714
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228651272
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228653057
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228654384
Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
On Tue, 13 Jun 2023 18:13:12 GMT, Naoto Sato wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Revert 'main.help.opt.any.file' value for _de
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties
> line 140:
>
>> 138:
>> 139: # 0: type, 1: name
>> 140: compiler.err.annotation.unrecognized.attribute.name=Annotation @{0}
>> weist das unbekannte Attribut "{1}" auf
>
> Is it intentional to replace single quotes with double quotes? It is done in
> several locations in this file, but other languages keep using single quotes
> as in the source English resource file.
I will consult the language specialist on this. I remember in previous
discussions that certain languages would format punctuation differently, but
let ask about this specific instance.
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties
> line 959:
>
>> 957:
>> 958:
>> compiler.err.text.block.template.is.not.well.formed=\u30C6\u30AD\u30B9\u30C8\u30FB\u30D6\u30ED\u30C3\u30AF\u30FB\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093
>> 959:
>
> The translation of "well-formed" is incorrect. It is not 整数式
For translations that are incorrect, I can file a bug against the tool. Such a
fix would probably not happen soon, can you suggest an alternative for now?
-
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228567669
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228570665
Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
On Mon, 12 Jun 2023 22:32:14 GMT, Justin Lu wrote:
>> Please review this PR which updates the JDK's localized resources since the
>> previous L10n translation drop (1/26).
>>
>> To help with reviewing the changes, @jonathan-gibbons created a tool which
>> displays the localized changes next to the original file's changes in UTF-8
>> native. Those files can be viewed
>> [here](https://cr.openjdk.org/~jlu/output/)
>>
>> For example,
>>
>> > src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3";>
>>
>>
>> Please note that the HTML files only apply to .properties, and not .java
>> resources.
>
> Justin Lu has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Revert 'main.help.opt.any.file' value for _de
Left some comments on the translations mainly in Japanese. It is now very easy
to look at the l10n changes in the generated HTML. One small comment to the
tool is that it would be nice if the order in HTML (alphabetically sorted
currently) aligns with the order in the actual resource file. It is a great
improvement anyways.
src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_ja.properties line
63:
> 61:
> FileChooser.newFolderExistsError.textAndMnemonic=\u305D\u306E\u540D\u524D\u306F\u3059\u3067\u306B\u4F7F\u7528\u3055\u308C\u3066\u3044\u307E\u3059
> 62: FileChooser.chooseButton.textAndMnemonic=\u9078\u629E
> 63:
> FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629E\u3057\u305F\u30D5\u30A1\u30A4\u30EB\u3092\u8FFD\u52A0\u3057\u307E\u3059
The translation seems wrong. It means to *add* the selected file, which is not
the same meaning as in English file
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties
line 140:
> 138:
> 139: # 0: type, 1: name
> 140: compiler.err.annotation.unrecognized.attribute.name=Annotation @{0}
> weist das unbekannte Attribut "{1}" auf
Is it intentional to replace single quotes with double quotes? It is done in
several locations in this file, but other languages keep using single quotes as
in the source English resource file.
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties
line 505:
> 503:
> 504:
> compiler.warn.possible.this.escape.location=\u4E8B\u524D\u306B\u6307\u5B9A\u53EF\u80FD\u306A''this''\u30A8\u30B9\u30B1\u30FC\u30D7\u306F\u547C\u51FA\u3057\u3092\u4ECB\u3057\u3066\u3053\u3053\u306B\u51FA\u73FE\u3057\u307E\u3059
> 505:
These translations are very cryptic. Cannot understand it at first hand.
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties
line 959:
> 957:
> 958:
> compiler.err.text.block.template.is.not.well.formed=\u30C6\u30AD\u30B9\u30C8\u30FB\u30D6\u30ED\u30C3\u30AF\u30FB\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093
> 959:
The translation of "well-formed" is incorrect. It is not 整数式
-
PR Review: https://git.openjdk.org/jdk/pull/14430#pullrequestreview-1477795175
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228530280
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228521409
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228538758
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228529769
Re: RFR: 8309757: com/sun/jdi/ReferrersTest.java fails with virtual test thread factory
On Fri, 9 Jun 2023 23:58:39 GMT, Chris Plummer wrote:
> This test launches a debuggee, which creates 11 instances of its main class,
> stores them in a static array of the main class, and then the debugger side
> iterates over all referrers to the main class instaces. Usually this is a
> pretty quick process and doesn't produce much in the way of output while
> walking the reference tree of referrers. However, with virtual threads the
> tree walking and output get unwieldy, and eventually it fails with:
>
>
> IOException reading output of child java interpreter:Stream closed
> java.lang.IllegalThreadStateException
> at
> jdk.jdi/com.sun.tools.jdi.JDWPException.toJDIException(JDWPException.java:76)
> at
> jdk.jdi/com.sun.tools.jdi.ThreadReferenceImpl.name(ThreadReferenceImpl.java:197)
> at
> jdk.jdi/com.sun.tools.jdi.ThreadReferenceImpl.toString(ThreadReferenceImpl.java:637)
> at java.base/java.lang.String.valueOf(String.java:4461)
> at ReferrersTest.showReferrers(ReferrersTest.java:438)
> at ReferrersTest.showReferrers(ReferrersTest.java:466)
>
>
> And ReferrersTest.showReferrers() has recursed about 200 levels deep. I'm not
> sure the order of these errors can be relied on. It looks like while walking
> the referrers tree, the test eventually stumbled upon a thread that had
> exited (but its Thread object was still alive), and this resulted in the test
> aborting. If I catch these exceptions, eventually the test times out while
> still working on referrers.
>
> Judging by some of the output, it appears that introducing the TestScaffold
> class as a referrer to the main debuggee class is the root cause of all these
> extra referrers.
>
> The test has a provision to cut off the recursion:
>
>
> // We have to stop going up a referrer chain in some cases
> Type rt = objRef.type();
> if (rt instanceof ClassType) {
> ClassType ct = (ClassType)rt;
> String name = ct.name();
> if (name.equals("sun.awt.SoftCache$ValueCell")) {
> return;
> }
> if (name.equals("java.lang.ref.Finalizer")) {
> return;
> }
> if (name.equals("java.lang.ref.SoftReference")) {
> return;
> }
> // oh oh, should really check for a subclass of ClassLoader :-)
> if (name.indexOf("ClassLoader") >= 0) {
> return;
> }
> // No doubt there are other reasons to stop ...
> }
>
>
> Adding TestScaffold to the list makes it so the referrer tree walking output
> is almost identical to what it is when not using virtual threads. ...
Thanks for the reviews Serguei and Kevin
-
PR Comment: https://git.openjdk.org/jdk/pull/14405#issuecomment-1589795544
Integrated: 8309757: com/sun/jdi/ReferrersTest.java fails with virtual test thread factory
On Fri, 9 Jun 2023 23:58:39 GMT, Chris Plummer wrote:
> This test launches a debuggee, which creates 11 instances of its main class,
> stores them in a static array of the main class, and then the debugger side
> iterates over all referrers to the main class instaces. Usually this is a
> pretty quick process and doesn't produce much in the way of output while
> walking the reference tree of referrers. However, with virtual threads the
> tree walking and output get unwieldy, and eventually it fails with:
>
>
> IOException reading output of child java interpreter:Stream closed
> java.lang.IllegalThreadStateException
> at
> jdk.jdi/com.sun.tools.jdi.JDWPException.toJDIException(JDWPException.java:76)
> at
> jdk.jdi/com.sun.tools.jdi.ThreadReferenceImpl.name(ThreadReferenceImpl.java:197)
> at
> jdk.jdi/com.sun.tools.jdi.ThreadReferenceImpl.toString(ThreadReferenceImpl.java:637)
> at java.base/java.lang.String.valueOf(String.java:4461)
> at ReferrersTest.showReferrers(ReferrersTest.java:438)
> at ReferrersTest.showReferrers(ReferrersTest.java:466)
>
>
> And ReferrersTest.showReferrers() has recursed about 200 levels deep. I'm not
> sure the order of these errors can be relied on. It looks like while walking
> the referrers tree, the test eventually stumbled upon a thread that had
> exited (but its Thread object was still alive), and this resulted in the test
> aborting. If I catch these exceptions, eventually the test times out while
> still working on referrers.
>
> Judging by some of the output, it appears that introducing the TestScaffold
> class as a referrer to the main debuggee class is the root cause of all these
> extra referrers.
>
> The test has a provision to cut off the recursion:
>
>
> // We have to stop going up a referrer chain in some cases
> Type rt = objRef.type();
> if (rt instanceof ClassType) {
> ClassType ct = (ClassType)rt;
> String name = ct.name();
> if (name.equals("sun.awt.SoftCache$ValueCell")) {
> return;
> }
> if (name.equals("java.lang.ref.Finalizer")) {
> return;
> }
> if (name.equals("java.lang.ref.SoftReference")) {
> return;
> }
> // oh oh, should really check for a subclass of ClassLoader :-)
> if (name.indexOf("ClassLoader") >= 0) {
> return;
> }
> // No doubt there are other reasons to stop ...
> }
>
>
> Adding TestScaffold to the list makes it so the referrer tree walking output
> is almost identical to what it is when not using virtual threads. ...
This pull request has now been integrated.
Changeset: d7251c17
Author:Chris Plummer
URL:
https://git.openjdk.org/jdk/commit/d7251c1755779f8c4fdeac16ccb797ed45b1dfd4
Stats: 5 lines in 2 files changed: 3 ins; 1 del; 1 mod
8309757: com/sun/jdi/ReferrersTest.java fails with virtual test thread factory
Reviewed-by: sspitsyn, kevinw
-
PR: https://git.openjdk.org/jdk/pull/14405
Re: RFR: 8309757: com/sun/jdi/ReferrersTest.java fails with virtual test thread factory [v2]
> This test launches a debuggee, which creates 11 instances of its main class,
> stores them in a static array of the main class, and then the debugger side
> iterates over all referrers to the main class instaces. Usually this is a
> pretty quick process and doesn't produce much in the way of output while
> walking the reference tree of referrers. However, with virtual threads the
> tree walking and output get unwieldy, and eventually it fails with:
>
>
> IOException reading output of child java interpreter:Stream closed
> java.lang.IllegalThreadStateException
> at
> jdk.jdi/com.sun.tools.jdi.JDWPException.toJDIException(JDWPException.java:76)
> at
> jdk.jdi/com.sun.tools.jdi.ThreadReferenceImpl.name(ThreadReferenceImpl.java:197)
> at
> jdk.jdi/com.sun.tools.jdi.ThreadReferenceImpl.toString(ThreadReferenceImpl.java:637)
> at java.base/java.lang.String.valueOf(String.java:4461)
> at ReferrersTest.showReferrers(ReferrersTest.java:438)
> at ReferrersTest.showReferrers(ReferrersTest.java:466)
>
>
> And ReferrersTest.showReferrers() has recursed about 200 levels deep. I'm not
> sure the order of these errors can be relied on. It looks like while walking
> the referrers tree, the test eventually stumbled upon a thread that had
> exited (but its Thread object was still alive), and this resulted in the test
> aborting. If I catch these exceptions, eventually the test times out while
> still working on referrers.
>
> Judging by some of the output, it appears that introducing the TestScaffold
> class as a referrer to the main debuggee class is the root cause of all these
> extra referrers.
>
> The test has a provision to cut off the recursion:
>
>
> // We have to stop going up a referrer chain in some cases
> Type rt = objRef.type();
> if (rt instanceof ClassType) {
> ClassType ct = (ClassType)rt;
> String name = ct.name();
> if (name.equals("sun.awt.SoftCache$ValueCell")) {
> return;
> }
> if (name.equals("java.lang.ref.Finalizer")) {
> return;
> }
> if (name.equals("java.lang.ref.SoftReference")) {
> return;
> }
> // oh oh, should really check for a subclass of ClassLoader :-)
> if (name.indexOf("ClassLoader") >= 0) {
> return;
> }
> // No doubt there are other reasons to stop ...
> }
>
>
> Adding TestScaffold to the list makes it so the referrer tree walking output
> is almost identical to what it is when not using virtual threads. ...
Chris Plummer has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains two commits:
- Merge
- Do some additional pruning needed when run with a virtual thread
-
Changes: https://git.openjdk.org/jdk/pull/14405/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14405&range=01
Stats: 5 lines in 2 files changed: 3 ins; 1 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/14405.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/14405/head:pull/14405
PR: https://git.openjdk.org/jdk/pull/14405
Re: RFR: 8309878: Reduce inclusion of resolvedIndyEntry.hpp
On Mon, 12 Jun 2023 19:52:36 GMT, Ioi Lam wrote: > resolvedIndyEntry.hpp was added in > [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995) and is included in > the popular cpCache.hpp. As a result, resolvedIndyEntry.hpp is included in > 807 out of about 1160 hotspot .o files. > > The contents of resolvedIndyEntry.hpp is infrequently used. Its inclusion > should be moved from cpCache.hpp to cpCache.inline.hpp. This improves hotspot > build time. > > After this PR, resolvedIndyEntry.hpp is included in only 30 hotspot .o files. Looks good, thanks for this! - Marked as reviewed by matsaave (Committer). PR Review: https://git.openjdk.org/jdk/pull/14427#pullrequestreview-1477437064
Integrated: 8309468: Remove jvmti Allocate locker test case
On Mon, 12 Jun 2023 16:39:12 GMT, Leo Korinth wrote: > There is a bunch of tests that are used to test critical section/gc locker. > One of the test is named jvmti locker. In that test, JNI code is doing a loop > of ` jvmti->Allocate()` followed `sleep()` followed by a > `jvmti->Deallocate()`. There is no JVM lock implementation to be tested on > jvmti Allocate/Deallocate, they are implemented using malloc/free. Let us > save test time, code complexity and confusion by removing this test. > > This removal is very similar to https://bugs.openjdk.org/browse/JDK-8309048 > > (Oracle) hs-tier5 testing passed on x86-64. This pull request has now been integrated. Changeset: c884862a Author:Leo Korinth URL: https://git.openjdk.org/jdk/commit/c884862ad2189654596df27a76ab685dcd7399f6 Stats: 260 lines in 9 files changed: 0 ins; 257 del; 3 mod 8309468: Remove jvmti Allocate locker test case Reviewed-by: dholmes, lmesnik, sspitsyn - PR: https://git.openjdk.org/jdk/pull/14421
Re: RFR: 8309468: Remove jvmti Allocate locker test case
On Mon, 12 Jun 2023 16:39:12 GMT, Leo Korinth wrote: > There is a bunch of tests that are used to test critical section/gc locker. > One of the test is named jvmti locker. In that test, JNI code is doing a loop > of ` jvmti->Allocate()` followed `sleep()` followed by a > `jvmti->Deallocate()`. There is no JVM lock implementation to be tested on > jvmti Allocate/Deallocate, they are implemented using malloc/free. Let us > save test time, code complexity and confusion by removing this test. > > This removal is very similar to https://bugs.openjdk.org/browse/JDK-8309048 > > (Oracle) hs-tier5 testing passed on x86-64. Thanks David, Leonid and Serguei! - PR Comment: https://git.openjdk.org/jdk/pull/14421#issuecomment-1589211147
Re: RFR: 8309757: com/sun/jdi/ReferrersTest.java fails with virtual test thread factory
On Fri, 9 Jun 2023 23:58:39 GMT, Chris Plummer wrote:
> This test launches a debuggee, which creates 11 instances of its main class,
> stores them in a static array of the main class, and then the debugger side
> iterates over all referrers to the main class instaces. Usually this is a
> pretty quick process and doesn't produce much in the way of output while
> walking the reference tree of referrers. However, with virtual threads the
> tree walking and output get unwieldy, and eventually it fails with:
>
>
> IOException reading output of child java interpreter:Stream closed
> java.lang.IllegalThreadStateException
> at
> jdk.jdi/com.sun.tools.jdi.JDWPException.toJDIException(JDWPException.java:76)
> at
> jdk.jdi/com.sun.tools.jdi.ThreadReferenceImpl.name(ThreadReferenceImpl.java:197)
> at
> jdk.jdi/com.sun.tools.jdi.ThreadReferenceImpl.toString(ThreadReferenceImpl.java:637)
> at java.base/java.lang.String.valueOf(String.java:4461)
> at ReferrersTest.showReferrers(ReferrersTest.java:438)
> at ReferrersTest.showReferrers(ReferrersTest.java:466)
>
>
> And ReferrersTest.showReferrers() has recursed about 200 levels deep. I'm not
> sure the order of these errors can be relied on. It looks like while walking
> the referrers tree, the test eventually stumbled upon a thread that had
> exited (but its Thread object was still alive), and this resulted in the test
> aborting. If I catch these exceptions, eventually the test times out while
> still working on referrers.
>
> Judging by some of the output, it appears that introducing the TestScaffold
> class as a referrer to the main debuggee class is the root cause of all these
> extra referrers.
>
> The test has a provision to cut off the recursion:
>
>
> // We have to stop going up a referrer chain in some cases
> Type rt = objRef.type();
> if (rt instanceof ClassType) {
> ClassType ct = (ClassType)rt;
> String name = ct.name();
> if (name.equals("sun.awt.SoftCache$ValueCell")) {
> return;
> }
> if (name.equals("java.lang.ref.Finalizer")) {
> return;
> }
> if (name.equals("java.lang.ref.SoftReference")) {
> return;
> }
> // oh oh, should really check for a subclass of ClassLoader :-)
> if (name.indexOf("ClassLoader") >= 0) {
> return;
> }
> // No doubt there are other reasons to stop ...
> }
>
>
> Adding TestScaffold to the list makes it so the referrer tree walking output
> is almost identical to what it is when not using virtual threads. ...
Looks good.
This test test/jdk/com/sun/jdi/ReferrersTest.java, and also
AnyDebuggeeTest.java and InstancesTest.java have comments referring to running
them with "runregresS". Maybe this is some old test harness or launcher that
no longer exists, probably wants to be deleted or reworded, in a separate
update.
-
Marked as reviewed by kevinw (Committer).
PR Review: https://git.openjdk.org/jdk/pull/14405#pullrequestreview-1476899872
PR Comment: https://git.openjdk.org/jdk/pull/14405#issuecomment-1589093501
Integrated: 8309671: Avoid using jvmci.Compiler property to determine if Graal is enabled
On Thu, 8 Jun 2023 17:14:39 GMT, Yudi Zheng wrote:
> HeapMonitor checks if System.getProperty("jvmci.Compiler") is graal and will
> not enforce checking line number derived from uncommon trap debug info.
> However, Graal does not set this property explicitly.
This pull request has now been integrated.
Changeset: 4f23fc1f
Author:Yudi Zheng
Committer: Doug Simon
URL:
https://git.openjdk.org/jdk/commit/4f23fc1f273ea30f49c5412a2f25c07f8982d5b5
Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod
8309671: Avoid using jvmci.Compiler property to determine if Graal is enabled
Reviewed-by: dnsimon, sspitsyn
-
PR: https://git.openjdk.org/jdk/pull/14381
Re: RFR: 8309671: Avoid using jvmci.Compiler property to determine if Graal is enabled
On Thu, 8 Jun 2023 17:14:39 GMT, Yudi Zheng wrote:
> HeapMonitor checks if System.getProperty("jvmci.Compiler") is graal and will
> not enforce checking line number derived from uncommon trap debug info.
> However, Graal does not set this property explicitly.
Thanks for the review!
-
PR Comment: https://git.openjdk.org/jdk/pull/14381#issuecomment-1588815689
Integrated: 8309462: [AIX] vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/TestDescription.java crashing due to empty while loop
On Mon, 12 Jun 2023 14:36:56 GMT, Martin Doerr wrote: > Test fix for test failing on AIX because of undefined behavior in current > implementation. This pull request has now been integrated. Changeset: 08eff92b Author:Martin Doerr URL: https://git.openjdk.org/jdk21/commit/08eff92b5e1e42cf299c1da8d5fa88d92b840505 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8309462: [AIX] vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/TestDescription.java crashing due to empty while loop Reviewed-by: mbaesken Backport-of: cf9e6353cc6fe9e57a7a9883813d09892e7e7621 - PR: https://git.openjdk.org/jdk21/pull/9
