From alanb at openjdk.java.net  Mon May  2 06:24:21 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 2 May 2022 06:24:21 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v9]
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <LXp0tyaigLgDbl9mb2IudAI3T6CKbp5FsHbuaEhus64=.8320aa51-38bb-430d-983c-56b9036827a5@github.com>

> This is the implementation of JEP 425: Virtual Threads (Preview).
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
 - Merge with jdk-19+20
 - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
 - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
 - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1
 - Merge with jdk-19+19
 - Refresh
 - Refresh
 - Refresh
 - Refresh
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/16a8ebbf...51bc652d

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8166/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=08
  Stats: 103888 lines in 1143 files changed: 93996 ins; 4227 del; 5665 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8166.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Mon May  2 06:33:22 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 2 May 2022 06:33:22 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <5w1-RAMPJ1845QC0VJ2YRwifky-U04KUmBp6kQGoOF8=.8486acaa-beda-4706-b394-962f2e8954c0@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <zi26K5BcvOD4orgtEdUoZJ3YtSkQq2LG9bsqo73bAsc=.a437c818-7bb5-4e43-835c-49fa6c4ec510@github.com>
 <5w1-RAMPJ1845QC0VJ2YRwifky-U04KUmBp6kQGoOF8=.8486acaa-beda-4706-b394-962f2e8954c0@github.com>
Message-ID: <Hy7L4hTspFwCHXS0TokPH_lBEMMBcZjTAC6D7MJW3uM=.09fb5f13-c986-4ca5-a20b-a289d78d4edb@github.com>

On Fri, 29 Apr 2022 20:57:01 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> test/jdk/jdk/jfr/api/consumer/TestManyRecordings.java line 57:
>> 
>>> 55:         int classLoaderCount = Integer.parseInt(args[0]);
>>> 56:         int classCount = Integer.parseInt(args[1]);
>>> 57:         for (int i = 0; i <classCount; i++) {
>> 
>> Did you mean classLoaderCount here instead of classCount? Also, please make sure there is a space between < and classLoaderCount.
>
> The JFR "tests" look strange. I would expect a test called TestManyRecording to start recordings, not create a lot of classes, similar to TestManyClasses. How is this related to Loom?  Could this be a merge gone bad?
> 
> Also, in TestActiveSettingEvent.java
> 
> +settingValues.put(EventNames.VirtualThreadPinned + "#threshold", "20 ms");
> 
> The reason to exclude a setting (threshold or stackTrace) from a .jfc file is if it doesn't make sense to configure. For example, if the event is always instantaneous (so duration is always 0) or periodic (so the stack trace only show JFR internals) then "threshold" and "stackTrace" can be removed from the configuration file, but needs to be added to test to avoid false positive.
> 
> The value "20 ms" seems like something a user might want to configure. If the event is instant, then the value should be "0 ms".

It seems that test/jdk/jdk/jfr/api/consumer/TestManyClasses.java, TestManyRecordings.java, and TestParse.java were added for another JFR event (nothing to do with VirtualThreadPinned). @egahlin has contributed some cleanup and these files are removed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Mon May  2 06:33:23 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 2 May 2022 06:33:23 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <ycstoIkpgIuaPPuUzJJl0WbTB9d2fgNzsmMGAkaLg5g=.b596ebbd-0f27-4911-a1f4-f0e6c98dcbe9@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <ycstoIkpgIuaPPuUzJJl0WbTB9d2fgNzsmMGAkaLg5g=.b596ebbd-0f27-4911-a1f4-f0e6c98dcbe9@github.com>
Message-ID: <Ihkc2WEFbT66Mp-11wmQKxr7tb2FAnCWUX-AEOFKogg=.5f0069b9-6bff-44e4-b78e-dc261b7719b2@github.com>

On Fri, 29 Apr 2022 23:14:45 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
> test/lib/jdk/test/lib/thread/VThreadRunner.java line 61:
> 
>> 59:     /**
>> 60:      * Run a task in a virtual thread and wait for it to terminate.
>> 61:      * If the task completse with an exception then it is thrown by this method.
> 
> typo: completse --> completes

Thanks, it seems this typo was repeated several times in the test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From mseledtsov at openjdk.java.net  Mon May  2 16:05:19 2022
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Mon, 2 May 2022 16:05:19 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v9]
In-Reply-To: <LXp0tyaigLgDbl9mb2IudAI3T6CKbp5FsHbuaEhus64=.8320aa51-38bb-430d-983c-56b9036827a5@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <LXp0tyaigLgDbl9mb2IudAI3T6CKbp5FsHbuaEhus64=.8320aa51-38bb-430d-983c-56b9036827a5@github.com>
Message-ID: <q-gQnc_5PSoqmpwJzQeU3OBmPHuB_6VvOPe6DgZ7NMo=.686d086e-933b-4b1a-967d-b08193d998ca@github.com>

On Mon, 2 May 2022 06:24:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview).
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
>  - Merge with jdk-19+20
>  - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>  - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
>  - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1
>  - Merge with jdk-19+19
>  - Refresh
>  - Refresh
>  - Refresh
>  - Refresh
>  - ... and 3 more: https://git.openjdk.java.net/jdk/compare/16a8ebbf...51bc652d

Thank you for addressing my review feedback. HotSpot/Runtime, test library, common test and JFR test changes look good to me.

-------------

Marked as reviewed by mseledtsov (Committer).

PR: https://git.openjdk.java.net/jdk/pull/8166

From lmesnik at openjdk.java.net  Mon May  2 17:24:13 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Mon, 2 May 2022 17:24:13 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <ToZrjWwHwDBwSBGMmN4GhwGvTEhcPFSVF40moxWLKwQ=.f6d14c2c-02f5-4655-808e-431bca9b386e@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <ToZrjWwHwDBwSBGMmN4GhwGvTEhcPFSVF40moxWLKwQ=.f6d14c2c-02f5-4655-808e-431bca9b386e@github.com>
Message-ID: <ojMUwaa-wbzazU8JX6_xaqDrJ9ASDlPApVC1iux2ncA=.19af44cd-1114-417e-b08e-c5e5a97e12e3@github.com>

On Fri, 29 Apr 2022 05:48:19 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
> test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp line 66:
> 
>> 64:   for (i = 0; i < METH_NUM; i++)
>> 65:     bpEvents[i] = 0;
>> 66: }
> 
> Leonid, thank you for converting these tests from nsk.jvmti to provide test coverage for virtual threads!
> As I understand all new tests are C++ based.
> So, I'd suggest to always use C++ style of loops:
>   for (int i = 0; i < METH_NUM; i++)
> 
> This suggestion applies to all new tests in the serviceability/jvmti folder.
> One reason to keep old style would be to keep these tests comparable with the matching nsk.jvmti tests.
> However, I tried to compare and found out that the difference is already pretty big.
> You can consider this clean up after integration though.

fixed in all ported tests were applicable

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From lmesnik at openjdk.java.net  Mon May  2 17:33:45 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Mon, 2 May 2022 17:33:45 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <ZIbvg5mqBKnDkPqj_VXglNgLvfgXGoXXQeKkCdXEpog=.222d1b6a-ba31-4b24-8087-8939d91f6b40@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <ZIbvg5mqBKnDkPqj_VXglNgLvfgXGoXXQeKkCdXEpog=.222d1b6a-ba31-4b24-8087-8939d91f6b40@github.com>
Message-ID: <htZ8N0SehZt8GFsN3GD8d0lvFbFlfjHdLv-PonqMYBI=.79c09d37-e6db-4746-b608-702eeca04539@github.com>

On Fri, 29 Apr 2022 06:09:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
> test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp line 139:
> 
>> 137:            thr_info.name,        (jni->IsVirtualThread(thread) == JNI_TRUE) ? "virtual" : "kernel",
>> 138:         (thr_info.is_daemon == JNI_TRUE) ? "deamon" : "user");
>> 139:   }
> 
> I'd suggest to add locals (their names are up to you):
>    const char* thr_virtual_tag = jni->IsVirtualThread(thread) == JNI_TRUE ? "virtual" : "kernel";
>    const char* thr_daemon_tag == JNI_TRUE) ? "deamon" : "user";
> 
> It is better to place togeter lines: 129+130.
> Line 137 is not aligned, and there are many unneeded spaces.
> The '()' around conditions are not needed. At least, I do not see them increasing readability.

fixed

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From lmesnik at openjdk.java.net  Mon May  2 20:04:59 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Mon, 2 May 2022 20:04:59 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TcJvhtqkkhHL32dEDwwEwxpShTFQTt39RsQo4wyHfJo=.4c9533a1-0540-4545-8293-74aa6168d085@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <TcJvhtqkkhHL32dEDwwEwxpShTFQTt39RsQo4wyHfJo=.4c9533a1-0540-4545-8293-74aa6168d085@github.com>
Message-ID: <WkOg5zdfmYpJZrFNKGUgfrtEA2OTK1NZZMvPV3wSpBI=.063bc28c-2147-4173-892e-87287939ac7c@github.com>

On Fri, 29 Apr 2022 06:43:02 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
> test/hotspot/jtreg/serviceability/jvmti/events/Exception/exception01/libexception01.cpp line 287:
> 
>> 285:   }
>> 286: 
>> 287:   eventsCount = 0;
> 
> Counters are not protected with locks.
> I'm not sure it is a real problem here but would be better to double-check.

The variable eventsCount seems to be used in the sinlge thread only. I looked on the several tests with same variable and similar logic.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From lmesnik at openjdk.java.net  Mon May  2 20:16:01 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Mon, 2 May 2022 20:16:01 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <YzgjmX7Q5pE2ckM4tdOY0tfh-TepCovgtzJKqxylvlo=.132db6f6-864d-4230-bdf9-7098512f0984@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <YzgjmX7Q5pE2ckM4tdOY0tfh-TepCovgtzJKqxylvlo=.132db6f6-864d-4230-bdf9-7098512f0984@github.com>
Message-ID: <7mvqatvgF_tC9fZB1rci31SVIh7q0JVtwGPXlWfiH9Y=.b58e30aa-101c-48d4-bed2-bcb7bf20a160@github.com>

On Fri, 29 Apr 2022 06:33:42 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
> test/hotspot/jtreg/serviceability/jvmti/events/ClassPrepare/classprep01/libclassprep01.cpp line 59:
> 
>> 57: static jvmtiEventCallbacks callbacks;
>> 58: static jint result = PASSED;
>> 59: static volatile size_t eventsCount = 0; // TODO these 2 vars mofified from different threads in getReady/check. What to DO???
> 
> I'd suggest to use RawMonitorLocker with event_lock or counter_lock to protect updates of these counters.
> You can remove this comment then.

The variable eventsCount seems to be used in the sinlge thread only. I looked on the several tests with same variable and similar logic.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From egahlin at openjdk.java.net  Mon May  2 22:36:45 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Mon, 2 May 2022 22:36:45 GMT
Subject: RFR: 8285872: JFR: Remove finalize() methods
Message-ID: <xxFTrGHrJQwMiBupk8MgWLoVaDXWNMeLyWBSrCpxSpw=.a5bde366-a9a8-4392-bd14-ddf9a321f2d3@github.com>

Hi,

Could I have review of a fix that removes the finalize() methods in the jdk.jfr module.

Chunks a reference counted so finalizers are not needed. To verify this, I added checks to the finalize() methods to make sure resources were not released when the finalizer was run. 

Testing: jdk/jdk/jfr multiple times

Thanks
Erik

-------------

Commit messages:
 - Initial

Changes: https://git.openjdk.java.net/jdk/pull/8510/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8510&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285872
  Stats: 28 lines in 3 files changed: 0 ins; 28 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8510.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8510/head:pull/8510

PR: https://git.openjdk.java.net/jdk/pull/8510

From alanb at openjdk.java.net  Tue May  3 08:11:45 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 3 May 2022 08:11:45 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v10]
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <C12QFWDYSwfwhM2JV6cdT5duNy-3F7mmYy9eTCItmtM=.ccd6fb59-f1ee-4cd2-b24f-7d439d636b09@github.com>

> This is the implementation of JEP 425: Virtual Threads (Preview).
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
 - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
 - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
 - Merge with jdk-19+20
 - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
 - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
 - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1
 - Merge with jdk-19+19
 - Refresh
 - Refresh
 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/cfcba1fc...f41b3131

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8166/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=09
  Stats: 102769 lines in 1140 files changed: 92907 ins; 4216 del; 5646 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8166.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Tue May  3 08:11:47 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 3 May 2022 08:11:47 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <htZ8N0SehZt8GFsN3GD8d0lvFbFlfjHdLv-PonqMYBI=.79c09d37-e6db-4746-b608-702eeca04539@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <ZIbvg5mqBKnDkPqj_VXglNgLvfgXGoXXQeKkCdXEpog=.222d1b6a-ba31-4b24-8087-8939d91f6b40@github.com>
 <htZ8N0SehZt8GFsN3GD8d0lvFbFlfjHdLv-PonqMYBI=.79c09d37-e6db-4746-b608-702eeca04539@github.com>
Message-ID: <fkmUI64vg-G_ILxioCOP_NqlP2O5LvNK1v9_vj1xvt8=.1e5cef3c-d532-4050-8860-4425d5acd5c2@github.com>

On Mon, 2 May 2022 17:29:02 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp line 139:
>> 
>>> 137:            thr_info.name,        (jni->IsVirtualThread(thread) == JNI_TRUE) ? "virtual" : "kernel",
>>> 138:         (thr_info.is_daemon == JNI_TRUE) ? "deamon" : "user");
>>> 139:   }
>> 
>> I'd suggest to add locals (their names are up to you):
>>    const char* thr_virtual_tag = jni->IsVirtualThread(thread) == JNI_TRUE ? "virtual" : "kernel";
>>    const char* thr_daemon_tag == JNI_TRUE) ? "deamon" : "user";
>> 
>> It is better to place togeter lines: 129+130.
>> Line 137 is not aligned, and there are many unneeded spaces.
>> The '()' around conditions are not needed. At least, I do not see them increasing readability.
>
> fixed

Thanks, I'll mark all the comments related to the JVMTI event tests as resolved.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Wed May  4 12:12:48 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 4 May 2022 12:12:48 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v11]
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <TGoQByO-TEVhk2tPwEEhXYSPBghWEV23Bqni4AKT1ME=.f94dc6e0-15e4-44ad-8e8e-3fcc57b63de2@github.com>

> This is the implementation of JEP 425: Virtual Threads (Preview).
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05
 - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89
 - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
 - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
 - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
 - Merge with jdk-19+20
 - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
 - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
 - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1
 - Merge with jdk-19+19
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/4b2c8220...f06aff75

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8166/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=10
  Stats: 102779 lines in 1140 files changed: 92909 ins; 4219 del; 5651 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8166.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166

PR: https://git.openjdk.java.net/jdk/pull/8166

From shade at openjdk.java.net  Wed May  4 16:05:06 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 4 May 2022 16:05:06 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v11]
In-Reply-To: <TGoQByO-TEVhk2tPwEEhXYSPBghWEV23Bqni4AKT1ME=.f94dc6e0-15e4-44ad-8e8e-3fcc57b63de2@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TGoQByO-TEVhk2tPwEEhXYSPBghWEV23Bqni4AKT1ME=.f94dc6e0-15e4-44ad-8e8e-3fcc57b63de2@github.com>
Message-ID: <Q3DstnYGNVgBXkn57bQirgdwlubtfPhnhkirhbjZMjk=.ad2e9a0f-b49c-47ad-b7c3-88037905f3ad@github.com>

On Wed, 4 May 2022 12:12:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview).
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05
>  - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89
>  - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
>  - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
>  - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
>  - Merge with jdk-19+20
>  - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>  - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
>  - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1
>  - Merge with jdk-19+19
>  - ... and 7 more: https://git.openjdk.java.net/jdk/compare/4b2c8220...f06aff75

> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.

So, does this PR pass current GHA checks? I see they are not enabled for this PR. It would be unfortunate for this large integration to break builds/tests for smaller PRs that would follow it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From egahlin at openjdk.java.net  Wed May  4 21:02:31 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 4 May 2022 21:02:31 GMT
Subject: RFR: 8282420: JFR: Remove event handlers
Message-ID: <KjE68jWImpVDbfN2S7Yv1XPKYC8LvFHcY25B9qQ8Lkg=.529b39a0-74e8-4157-8cb7-9ed9e6109169@github.com>

Hi,

Could I have a review of a fix that removes event handler classes for JFR. Bytecode for event instrumentation is now only added to the event class. Benefits are:

- No class memory leak in the boot class loader.
- Reduce overhead from class loading during startup, which is important with additional JDK events that are coming (VirtualThreadStart etc.)
- One less frame to traverse when recording a Java stack trace.

Future benefits are:

- Simplify creating instrumentation at build step. See https://bugs.openjdk.java.net/browse/JDK-8279354
- Simplify implementation of Event Metrics. See https://bugs.openjdk.java.net/browse/JDK-8224749

When the Security Manager is removed, much of the code being added for security reasons can be deleted.

There are few JFR hooks when code is being linked. Plan is to also use these for other events later. 

Testing: tier 1-4, jdk/jdk/jfr

Thanks
Erik

-------------

Commit messages:
 - Test cleanup
 - Test fixes
 - Fix whitespaces
 - Use EventWriterFactory
 - Initial

Changes: https://git.openjdk.java.net/jdk/pull/8383/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8383&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282420
  Stats: 4016 lines in 79 files changed: 2412 ins; 1010 del; 594 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8383.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8383/head:pull/8383

PR: https://git.openjdk.java.net/jdk/pull/8383

From sspitsyn at openjdk.java.net  Thu May  5 02:25:12 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 5 May 2022 02:25:12 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v11]
In-Reply-To: <TGoQByO-TEVhk2tPwEEhXYSPBghWEV23Bqni4AKT1ME=.f94dc6e0-15e4-44ad-8e8e-3fcc57b63de2@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TGoQByO-TEVhk2tPwEEhXYSPBghWEV23Bqni4AKT1ME=.f94dc6e0-15e4-44ad-8e8e-3fcc57b63de2@github.com>
Message-ID: <obecW-tlrdGOcntvR3ze475nlAw-kj12CKCVF-b_JlI=.3e70ef85-3112-416a-8cf5-978ced099032@github.com>

On Wed, 4 May 2022 12:12:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview).
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05
>  - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89
>  - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
>  - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
>  - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
>  - Merge with jdk-19+20
>  - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>  - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
>  - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1
>  - Merge with jdk-19+19
>  - ... and 7 more: https://git.openjdk.java.net/jdk/compare/4b2c8220...f06aff75

I've completed review of new vthread-related tests in the folder serviceability/jvmti.
It includes sub-folders:
 serviceability/jvmti/events
 serviceability/jvmti/negative
 serviceability/jvmti/thread
Thank you, Leonid, for resolving my comments!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From duke at openjdk.java.net  Thu May  5 08:50:20 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Thu, 5 May 2022 08:50:20 GMT
Subject: RFR: 8284686: Interval of < 1 ms disables ExecutionSample events
 [v5]
In-Reply-To: <25dQBbVY_H8dsIfWgyjc3FGhkPe_NlxZXOy8U-r1Zzw=.7b717a2b-efc4-496d-b97d-01cb25017ddc@github.com>
References: <aGIOW_F7ba5mho6Pb3qbg6jRmTGeScxxNoFZlqQ9J9E=.766676cc-9c96-4b6d-8f21-7a923f9f1b30@github.com>
 <25dQBbVY_H8dsIfWgyjc3FGhkPe_NlxZXOy8U-r1Zzw=.7b717a2b-efc4-496d-b97d-01cb25017ddc@github.com>
Message-ID: <_DLuz5cCshNcOvccAE1a1kEutawoS8qOChEuooJPIyw=.7c1cd830-dd45-414e-b2c1-27e484fbb748@github.com>

On Fri, 29 Apr 2022 11:16:27 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> Fixes the issue by rounding the period interval to the next full millisecond larger than zero.
>> 
>> The following from the bug report works now:
>> 
>> java -XX:StartFlightRecording=filename=flight.jfr,jdk.ExecutionSample#period=999us CLASS_FILE; jfr print --events jdk.ExecutionSample flight.jfr
>> 
>> It considers the period to be `1ms`, producing the recording as expected.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Remove Thread from make_walkable signature"
>   
>   This reverts commit fe7d7116611a26abc229e7fb8f846bb3cf1e26ab.

I'm currently struggling with writing the tests as there are problems, even with durations > 1ms and on the stock JVM.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8183

From alanb at openjdk.java.net  Thu May  5 09:35:42 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 5 May 2022 09:35:42 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v12]
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com>

> This is the implementation of JEP 425: Virtual Threads (Preview).
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - Refresh 12aa09ce7efd48425cc080d0b8761aca0f3e215f
 - Merge with 1bb4de2e2868a539846ec48dd43fd623c2ba69a5
 - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05
 - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89
 - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
 - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
 - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
 - Merge with jdk-19+20
 - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
 - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
 - ... and 9 more: https://git.openjdk.java.net/jdk/compare/1bb4de2e...86bea8ec

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8166/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=11
  Stats: 99452 lines in 1130 files changed: 91184 ins; 3598 del; 4670 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8166.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Thu May  5 09:47:38 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 5 May 2022 09:47:38 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v11]
In-Reply-To: <Q3DstnYGNVgBXkn57bQirgdwlubtfPhnhkirhbjZMjk=.ad2e9a0f-b49c-47ad-b7c3-88037905f3ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TGoQByO-TEVhk2tPwEEhXYSPBghWEV23Bqni4AKT1ME=.f94dc6e0-15e4-44ad-8e8e-3fcc57b63de2@github.com>
 <Q3DstnYGNVgBXkn57bQirgdwlubtfPhnhkirhbjZMjk=.ad2e9a0f-b49c-47ad-b7c3-88037905f3ad@github.com>
Message-ID: <gGcWBFyWAFSVEUgLsrurXb3OlGSwQT-jj0rOiQbcbUI=.406d3188-fa19-46a1-86cc-31d97c9812ce@github.com>

On Wed, 4 May 2022 16:02:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> So, does this PR pass current GHA checks? I see they are not enabled for this PR. It would be unfortunate for this large integration to break builds/tests for smaller PRs that would follow it.

I've enabled it on my fork and we'll see if it kicks in.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From jbachorik at openjdk.java.net  Thu May  5 09:52:37 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Thu, 5 May 2022 09:52:37 GMT
Subject: RFR: 8282420: JFR: Remove event handlers
In-Reply-To: <KjE68jWImpVDbfN2S7Yv1XPKYC8LvFHcY25B9qQ8Lkg=.529b39a0-74e8-4157-8cb7-9ed9e6109169@github.com>
References: <KjE68jWImpVDbfN2S7Yv1XPKYC8LvFHcY25B9qQ8Lkg=.529b39a0-74e8-4157-8cb7-9ed9e6109169@github.com>
Message-ID: <_5I-X5S5yMBx0VCDRirEt6UlBqqgWFU9VcF-jDDIejM=.f250a9e7-ce30-4a8a-b641-8978a2df7735@github.com>

On Mon, 25 Apr 2022 16:49:42 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Hi,
> 
> Could I have a review of a fix that removes event handler classes for JFR. Bytecode for event instrumentation is now only added to the event class. Benefits are:
> 
> - No class memory leak in the boot class loader.
> - Reduce overhead from class loading during startup, which is important with additional JDK events that are coming (VirtualThreadStart etc.)
> - One less frame to traverse when recording a Java stack trace.
> 
> Future benefits are:
> 
> - Simplify creating instrumentation at build step. See https://bugs.openjdk.java.net/browse/JDK-8279354
> - Simplify implementation of Event Metrics. See https://bugs.openjdk.java.net/browse/JDK-8224749
> 
> When the Security Manager is removed, much of the code being added for security reasons can be deleted.
> 
> There are few JFR hooks when code is being linked. Plan is to also use these for other events later. 
> 
> Testing: tier 1-4, jdk/jdk/jfr
> 
> Thanks
> Erik

src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp line 1451:

> 1449: 
> 1450: // If for a subklass, on initial class load, an implementation exist for any of the final methods declared in Event,
> 1451: // then constaints are considered breached.

Suggestion:

// then constraints are considered breached.

src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp line 1468:

> 1466:   if (invalid_preconditions_for_subklass_on_initial_load(ik)) {
> 1467:     // Remove the tag denoting this as a jdk.jfr.Event subklass. No instrumentation, hence no events can be written.
> 1468:     // The class is allow to load as-is, but it is classified as outside of the jfr system.

Suggestion:

    // The class is allowed to load as-is, but it is classified as outside of the jfr system.

src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp line 1560:

> 1558:     (JvmtiCachedClassFileData*)NEW_C_HEAP_ARRAY_RETURN_NULL(u1, offset_of(JvmtiCachedClassFileData, data) + stream_len, mtInternal);
> 1559:   if (p == NULL) {
> 1560:     log_error(jfr, system)("Allocation using C_HEAP_ARRAY for " SIZE_FORMAT " bytes failed in JfrEventClassTransformer::on_klass_creation",

Is the log text referencing a wrong method?

Suggestion:

    log_error(jfr, system)("Allocation using C_HEAP_ARRAY for " SIZE_FORMAT " bytes failed in JfrEventClassTransformer::cache_class_file_data",

src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.cpp line 190:

> 188:   /* Set callbacks */
> 189:   memset(&callbacks, 0, sizeof(callbacks));
> 190:   // callbacks.ClassFileLoadHook = jfr_on_class_file_load_hook;

Perhaps you want to remove this commented out code

src/hotspot/share/jfr/instrumentation/jfrResolution.hpp line 41:

> 39:   static void on_resolution(const CallInfo & info, TRAPS);
> 40:   static void on_resolution(const Parse * parse, const ciKlass * holder, const ciMethod * target);
> 41:   static void on_resolution(const GraphBuilder * builder, const ciKlass * holder, const ciMethod * target);

Could you add brief comments as when will each callback be called?
Eg. the second form is called from C1 and the third form is called from C2 (assuming based on what I see in the cpp file)?

src/jdk.jfr/share/classes/jdk/jfr/internal/EventClassBuilder.java line 112:

> 110:         methodVisitor.visitMethodInsn(Opcodes.INVOKESPECIAL, className, m.getName(), m.getDescriptor(), false);
> 111:     }
> 112: 

I wonder if it makes sense to extract this method - it is virtually replacing one method call by another.

src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 92:

> 90: 
> 91:         public boolean isString() {
> 92:             return ASMToolkit.TYPE_STRING.getDescriptor().equals(fieldDescriptor);

If this is to be called often it might be beneficial to cache the descriptor instead of recreating it each time.

src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 139:

> 137:         this.settingInfos = buildSettingInfos(superClass, classNode);
> 138:         this.fieldInfos = buildFieldInfos(superClass, classNode);
> 139:         String n = annotationValue(classNode, ANNOTATION_TYPE_NAME.getDescriptor(), String.class);

As well - the descriptor could be cached to avoid calling substring operations repeatedly.

src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformEventType.java line 109:

> 107:             }
> 108:         }
> 109:         return 3;

Why is the default stack trace offset changed?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8383

From duke at openjdk.java.net  Thu May  5 11:02:09 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Thu, 5 May 2022 11:02:09 GMT
Subject: RFR: 8284686: Interval of < 1 ms disables ExecutionSample events
 [v6]
In-Reply-To: <aGIOW_F7ba5mho6Pb3qbg6jRmTGeScxxNoFZlqQ9J9E=.766676cc-9c96-4b6d-8f21-7a923f9f1b30@github.com>
References: <aGIOW_F7ba5mho6Pb3qbg6jRmTGeScxxNoFZlqQ9J9E=.766676cc-9c96-4b6d-8f21-7a923f9f1b30@github.com>
Message-ID: <86v_lI0kWTXQv5hJaMZ1-XKOtVRYo2BoJbvl45sDD1g=.8b870c70-9db6-45ba-9fab-77bf25d55e8e@github.com>

> Fixes the issue by rounding the period interval to the next full millisecond larger than zero.
> 
> The following from the bug report works now:
> 
> java -XX:StartFlightRecording=filename=flight.jfr,jdk.ExecutionSample#period=999us CLASS_FILE; jfr print --events jdk.ExecutionSample flight.jfr
> 
> It considers the period to be `1ms`, producing the recording as expected.

Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:

 - Add TestShortPeriod
 - Remove TestPeriodSetting

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8183/files
  - new: https://git.openjdk.java.net/jdk/pull/8183/files/a9aebe04..e5b7f55c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8183&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8183&range=04-05

  Stats: 146 lines in 2 files changed: 95 ins; 51 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8183.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8183/head:pull/8183

PR: https://git.openjdk.java.net/jdk/pull/8183

From jbachorik at openjdk.java.net  Thu May  5 13:07:38 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Thu, 5 May 2022 13:07:38 GMT
Subject: RFR: 8284686: Interval of < 1 ms disables ExecutionSample events
 [v6]
In-Reply-To: <86v_lI0kWTXQv5hJaMZ1-XKOtVRYo2BoJbvl45sDD1g=.8b870c70-9db6-45ba-9fab-77bf25d55e8e@github.com>
References: <aGIOW_F7ba5mho6Pb3qbg6jRmTGeScxxNoFZlqQ9J9E=.766676cc-9c96-4b6d-8f21-7a923f9f1b30@github.com>
 <86v_lI0kWTXQv5hJaMZ1-XKOtVRYo2BoJbvl45sDD1g=.8b870c70-9db6-45ba-9fab-77bf25d55e8e@github.com>
Message-ID: <jJb7U14M7il8fK2xZORD5xjYGNrzF-Q9Pzm-3Vaj12k=.ff1ea29a-be4d-45b2-91c6-0b017e169cdb@github.com>

On Thu, 5 May 2022 11:02:09 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> Fixes the issue by rounding the period interval to the next full millisecond larger than zero.
>> 
>> The following from the bug report works now:
>> 
>> java -XX:StartFlightRecording=filename=flight.jfr,jdk.ExecutionSample#period=999us CLASS_FILE; jfr print --events jdk.ExecutionSample flight.jfr
>> 
>> It considers the period to be `1ms`, producing the recording as expected.
>
> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add TestShortPeriod
>  - Remove TestPeriodSetting

test/jdk/jdk/jfr/api/recording/event/TestShortPeriod.java line 63:

> 61:         try (var r = new RecordingStream()) {
> 62:             r.enable(EventNames.JVMInformation).withPeriod(Duration.ofNanos(1));
> 63:             r.onEvent(e -> r.close());

What happens when the event is, in fact, disabled?
The test will run forever, right?

Could you rather use something like `CountDownLatch` which will get decremented in `onEvent()` handler and the test method would wait for that latch for at most N milliseconds - failing when the wait times out?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8183

From duke at openjdk.java.net  Thu May  5 13:11:19 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Thu, 5 May 2022 13:11:19 GMT
Subject: RFR: 8284686: Interval of < 1 ms disables ExecutionSample events
 [v6]
In-Reply-To: <jJb7U14M7il8fK2xZORD5xjYGNrzF-Q9Pzm-3Vaj12k=.ff1ea29a-be4d-45b2-91c6-0b017e169cdb@github.com>
References: <aGIOW_F7ba5mho6Pb3qbg6jRmTGeScxxNoFZlqQ9J9E=.766676cc-9c96-4b6d-8f21-7a923f9f1b30@github.com>
 <86v_lI0kWTXQv5hJaMZ1-XKOtVRYo2BoJbvl45sDD1g=.8b870c70-9db6-45ba-9fab-77bf25d55e8e@github.com>
 <jJb7U14M7il8fK2xZORD5xjYGNrzF-Q9Pzm-3Vaj12k=.ff1ea29a-be4d-45b2-91c6-0b017e169cdb@github.com>
Message-ID: <D7Fvz_BSEs3HSritnp1Q-9ZQTDQ7ShTJhZVqkzpGt1g=.8bdbc0b1-6db0-4db4-a52e-b6fad95350b9@github.com>

On Thu, 5 May 2022 13:04:04 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add TestShortPeriod
>>  - Remove TestPeriodSetting
>
> test/jdk/jdk/jfr/api/recording/event/TestShortPeriod.java line 63:
> 
>> 61:         try (var r = new RecordingStream()) {
>> 62:             r.enable(EventNames.JVMInformation).withPeriod(Duration.ofNanos(1));
>> 63:             r.onEvent(e -> r.close());
> 
> What happens when the event is, in fact, disabled?
> The test will run forever, right?
> 
> Could you rather use something like `CountDownLatch` which will get decremented in `onEvent()` handler and the test method would wait for that latch for at most N milliseconds - failing when the wait times out?

I could, but lets ask @egahlin for his opinion. He proposed it in the first place.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8183

From egahlin at openjdk.java.net  Thu May  5 14:08:18 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Thu, 5 May 2022 14:08:18 GMT
Subject: RFR: 8284686: Interval of < 1 ms disables ExecutionSample events
 [v6]
In-Reply-To: <D7Fvz_BSEs3HSritnp1Q-9ZQTDQ7ShTJhZVqkzpGt1g=.8bdbc0b1-6db0-4db4-a52e-b6fad95350b9@github.com>
References: <aGIOW_F7ba5mho6Pb3qbg6jRmTGeScxxNoFZlqQ9J9E=.766676cc-9c96-4b6d-8f21-7a923f9f1b30@github.com>
 <86v_lI0kWTXQv5hJaMZ1-XKOtVRYo2BoJbvl45sDD1g=.8b870c70-9db6-45ba-9fab-77bf25d55e8e@github.com>
 <jJb7U14M7il8fK2xZORD5xjYGNrzF-Q9Pzm-3Vaj12k=.ff1ea29a-be4d-45b2-91c6-0b017e169cdb@github.com>
 <D7Fvz_BSEs3HSritnp1Q-9ZQTDQ7ShTJhZVqkzpGt1g=.8bdbc0b1-6db0-4db4-a52e-b6fad95350b9@github.com>
Message-ID: <DMktIzmBGtHPSzZGnNpjbqVRjWipqXYFEsi_Y_7MZAU=.7a1eef68-7bdd-4ba2-838b-6191ef757758@github.com>

On Thu, 5 May 2022 13:08:04 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> test/jdk/jdk/jfr/api/recording/event/TestShortPeriod.java line 63:
>> 
>>> 61:         try (var r = new RecordingStream()) {
>>> 62:             r.enable(EventNames.JVMInformation).withPeriod(Duration.ofNanos(1));
>>> 63:             r.onEvent(e -> r.close());
>> 
>> What happens when the event is, in fact, disabled?
>> The test will run forever, right?
>> 
>> Could you rather use something like `CountDownLatch` which will get decremented in `onEvent()` handler and the test method would wait for that latch for at most N milliseconds - failing when the wait times out?
>
> I could, but lets ask @egahlin for his opinion. He proposed it in the first place.

I think it's better to use the timeout provided by jtreg than hardwiring in a number in the test.

The test could be run on different hardware or in modes that are very slow.  It's better to allow the framework to provide the timeout. The test should not fail, so it shouldn't be an issue.

I think the code looks fine, but could you remove the update to the documentation / specification. Also, perhaps add a comment in the test that the execution event requires a separate thread because the thread streaming events gets excluded from JFR (to avoid recursion).

I will take it for a spin a few hundred times on different platforms to see if there are any intermittent issues.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8183

From coffeys at openjdk.java.net  Thu May  5 16:08:38 2022
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Thu, 5 May 2022 16:08:38 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v12]
In-Reply-To: <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com>
Message-ID: <7N1fimic2Cdh1UG_lIkjdUZhX_r-zzC1equf9VbNU7U=.f43339fb-7797-4d84-9c87-472e6db02638@github.com>

On Thu, 5 May 2022 09:35:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview).
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - Refresh 12aa09ce7efd48425cc080d0b8761aca0f3e215f
>  - Merge with 1bb4de2e2868a539846ec48dd43fd623c2ba69a5
>  - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05
>  - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89
>  - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
>  - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
>  - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
>  - Merge with jdk-19+20
>  - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>  - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
>  - ... and 9 more: https://git.openjdk.java.net/jdk/compare/1bb4de2e...86bea8ec

Studied the java.io package edits, the new JFR events and the new jcmd dump_to_file functionality. Looks good!

-------------

Marked as reviewed by coffeys (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8166

From darcy at openjdk.java.net  Thu May  5 17:15:49 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 5 May 2022 17:15:49 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v12]
In-Reply-To: <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com>
Message-ID: <0ntcEQFUGJN5jQeKnIZrEqQR9CDgkt9aHi-1mzUcKP0=.959c2be4-16c1-4d21-8276-a273e5945658@github.com>

On Thu, 5 May 2022 09:35:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview).
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - Refresh 12aa09ce7efd48425cc080d0b8761aca0f3e215f
>  - Merge with 1bb4de2e2868a539846ec48dd43fd623c2ba69a5
>  - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05
>  - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89
>  - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
>  - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
>  - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
>  - Merge with jdk-19+20
>  - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>  - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
>  - ... and 9 more: https://git.openjdk.java.net/jdk/compare/1bb4de2e...86bea8ec

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From shade at openjdk.java.net  Thu May  5 17:46:09 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 5 May 2022 17:46:09 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v12]
In-Reply-To: <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com>
Message-ID: <JEybFaDnjzr7ucOpe3QVrZsDGzOYgZaXvEiCfU8-kTs=.089e55ac-7c9d-42db-8cbe-b9f985823387@github.com>

On Thu, 5 May 2022 09:35:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview).
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - Refresh 12aa09ce7efd48425cc080d0b8761aca0f3e215f
>  - Merge with 1bb4de2e2868a539846ec48dd43fd623c2ba69a5
>  - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05
>  - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89
>  - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
>  - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
>  - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
>  - Merge with jdk-19+20
>  - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>  - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
>  - ... and 9 more: https://git.openjdk.java.net/jdk/compare/1bb4de2e...86bea8ec

I am sorry to be a buzzkill here, but this integration would break lots of platforms even when Loom functionality is not enabled/used. For example, running `java -version` on RISC-V runs into many issues: `TemplateInterpreterGenerator::generate_Continuation_doYield_entry` runs into `Unimplemented()`, `UnsafeCopyMemory` asserts about UCM table size, `NativeDeoptInstruction::is_deopt` would run into `Unimplemented()` while being called from signal handler.

This effectively blocks development on those platforms, and it seems to be too much breakage for a preview feature. Are we really breaking these platforms? Do we have plans in place with maintainers of those platforms to fix all this in JDK 19 timeframe? I'd suggest holding off the integration until such a plan and agreement is in place.

-------------

Changes requested by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Thu May  5 19:00:42 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 5 May 2022 19:00:42 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v12]
In-Reply-To: <JEybFaDnjzr7ucOpe3QVrZsDGzOYgZaXvEiCfU8-kTs=.089e55ac-7c9d-42db-8cbe-b9f985823387@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com>
 <JEybFaDnjzr7ucOpe3QVrZsDGzOYgZaXvEiCfU8-kTs=.089e55ac-7c9d-42db-8cbe-b9f985823387@github.com>
Message-ID: <IClQBci8WY_me9QbqEJc1YmrSDb69SSwbs30vvXk0FE=.1952a7e8-af0d-4c56-a6e3-16459a8026bf@github.com>

On Thu, 5 May 2022 17:43:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I am sorry to be a buzzkill here, but this integration would break lots of platforms even when Loom functionality is not enabled/used. For example, running `java -version` on RISC-V runs into many issues: `TemplateInterpreterGenerator::generate_Continuation_doYield_entry` runs into `Unimplemented()`, `UnsafeCopyMemory` asserts about UCM table size, `NativeDeoptInstruction::is_deopt` would run into `Unimplemented()` while being called from signal handler.
> 
> This effectively blocks development on those platforms, and it seems to be too much breakage for a preview feature. Are we really breaking these platforms? Do we have plans in place with maintainers of those platforms to fix all this in JDK 19 timeframe? I'd suggest holding off the integration until such a plan and agreement is in place.

We mailed porters-dev in Sep 2021 to give a heads up that this feature would require porting work so it shouldn't be a surprise. We have been open to including other ports with the initial integration but it was never a goal to have all the ports done in advance of that.

Most of the new code in the VM is only used when running with --enable-preview. You'll see several places that test Continuations::enabled(). It should be possible to get these port running without -enable-preview without much effort. The feature has to be implemented to pass all the tests of course.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Fri May  6 06:48:46 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 6 May 2022 06:48:46 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v13]
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <kw1r-eOnf3xU7xF1-qpb-ddASUTDT60FW0OXSNspvzs=.cd80786d-4dd4-4fbd-bafe-e5786b0d1afd@github.com>

> This is the implementation of JEP 425: Virtual Threads (Preview).
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:

 - Refresh 6ace49bf42e5504c69fa11c564e8e865c0a95fb3
 - Merge with 9425ab2b43b649bd591706bfc820e9c8795a6fdf
 - Refresh 12aa09ce7efd48425cc080d0b8761aca0f3e215f
 - Merge with 1bb4de2e2868a539846ec48dd43fd623c2ba69a5
 - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05
 - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89
 - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
 - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
 - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
 - Merge with jdk-19+20
 - ... and 11 more: https://git.openjdk.java.net/jdk/compare/9425ab2b...6d968671

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8166/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=12
  Stats: 99456 lines in 1130 files changed: 91188 ins; 3598 del; 4670 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8166.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166

PR: https://git.openjdk.java.net/jdk/pull/8166

From shade at openjdk.java.net  Fri May  6 08:32:46 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 6 May 2022 08:32:46 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v12]
In-Reply-To: <IClQBci8WY_me9QbqEJc1YmrSDb69SSwbs30vvXk0FE=.1952a7e8-af0d-4c56-a6e3-16459a8026bf@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com>
 <JEybFaDnjzr7ucOpe3QVrZsDGzOYgZaXvEiCfU8-kTs=.089e55ac-7c9d-42db-8cbe-b9f985823387@github.com>
 <IClQBci8WY_me9QbqEJc1YmrSDb69SSwbs30vvXk0FE=.1952a7e8-af0d-4c56-a6e3-16459a8026bf@github.com>
Message-ID: <h0IQAD8PepuXk5NE_ddzyldmrGQHqYYDKRy_KECVo6E=.2476bbfa-0957-46a3-bd99-e0dee1046f35@github.com>

On Thu, 5 May 2022 18:54:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> We mailed porters-dev in Sep 2021 to give a heads up that this feature would require porting work so it shouldn't be a surprise. We have been open to including other ports with the initial integration but it was never a goal to have all the ports done in advance of that.

It is understandable to ship the preview feature not implemented on all platforms. It is even understandable to ship the final product feature that breaks some platforms in an clearly understandable way, prompting platform maintainers to implement the agreed-upon, final Java feature. What I am seeing, though, is that just running `java -version` (!) after integrating a *preview feature* is broken!

> Most of the new code in the VM is only used when running with --enable-preview. You'll see several places that test Continuations::enabled(). It should be possible to get these port running without -enable-preview without much effort. The feature has to be implemented to pass all the tests of course.

It is not as clear-cut, unfortunately. I see there are substantial changes in deopt machinery with post-call NOPs -- and there maybe more stuff lurking after that one is implemented -- so it is not as simple as changing `Unimplemented()` to guarding with `Continuations::enabled()`. So this looks to me that the core deopt machinery is affected, whether Loom is enabled or not. Is the impact of that deopt machinery change on the VM stability and VM ports discussed, understood, documented somewhere?

I would have honestly expected those core changes to be heavily conditionalized with either `ifdef`-s, or runtime checks, or both, so that both unimplemented platforms had the old behavior *and* the implemented platforms had a fallback to old behavior if preview feature was broken. The current code is fine for experimental Loom repo, but I firmly believe mainline should have much stronger safety/reliability requirements.

My fear is that an integration like this would wreck JDK 19 release. So my question stands: Are we breaking those platforms? Are we sure the unconditional VM changes are problem-free, implementable everywhere, etc? The answer might be "Yes, we are integrating, let the chips fall where they may", but I also believe that should be the call made by responsible platform/VM architects, who should explicitly weigh in and accept the risk of wide JDK 19 breakage.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Fri May  6 09:51:20 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 6 May 2022 09:51:20 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v13]
In-Reply-To: <kw1r-eOnf3xU7xF1-qpb-ddASUTDT60FW0OXSNspvzs=.cd80786d-4dd4-4fbd-bafe-e5786b0d1afd@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <kw1r-eOnf3xU7xF1-qpb-ddASUTDT60FW0OXSNspvzs=.cd80786d-4dd4-4fbd-bafe-e5786b0d1afd@github.com>
Message-ID: <apoi69wlbi5W27w85tRBUvBvU0od_yc6bHjTJRVmfZ0=.06215232-4cbb-43fe-bd43-4a0fc17a73e4@github.com>

On Fri, 6 May 2022 06:48:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview).
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
> 
>  - Refresh 6ace49bf42e5504c69fa11c564e8e865c0a95fb3
>  - Merge with 9425ab2b43b649bd591706bfc820e9c8795a6fdf
>  - Refresh 12aa09ce7efd48425cc080d0b8761aca0f3e215f
>  - Merge with 1bb4de2e2868a539846ec48dd43fd623c2ba69a5
>  - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05
>  - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89
>  - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
>  - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
>  - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
>  - Merge with jdk-19+20
>  - ... and 11 more: https://git.openjdk.java.net/jdk/compare/9425ab2b...6d968671

> It is understandable to ship the preview feature not implemented on all platforms. It is even understandable to ship the final product feature that breaks some platforms in an clearly understandable way, prompting platform maintainers to implement the agreed-upon, final Java feature. What I am seeing, though, is that just running `java -version` (!) after integrating a _preview feature_ is broken!

Preview features need to be implemented by a port before it can be released. For JDK 19 this means that the maintainers of ports will have work to do for both JEP 424 and JEP 425 (ifdef is not an option).

I think the issue that are concerned about is the interim period between the JEP 425 integration and the port/implementation of this feature to other architectures. I think the answer is that it will vary. It may be that some port maintainers decide to do something very short term so they can run without --enable-preview and buy time before they do the port/implementation for JDK 19. Good progress has been reported on at least ppc64le port and maybe that port be ready before others. So yes, some ports may crash until they receive attention, others (like zero) should be able to run tests that don't use --enable-preview. I've no doubt there will be a flurry of changes post integration.

The motivation for Continuations::enabled() was to reduce risk and disable a lot of the new code by default. The motivation wasn't porting but it may be helpful during the interim period. That is probably a topic for loom-dev rather here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From egahlin at openjdk.java.net  Fri May  6 13:00:37 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Fri, 6 May 2022 13:00:37 GMT
Subject: RFR: 8284686: Interval of < 1 ms disables ExecutionSample events
 [v6]
In-Reply-To: <DMktIzmBGtHPSzZGnNpjbqVRjWipqXYFEsi_Y_7MZAU=.7a1eef68-7bdd-4ba2-838b-6191ef757758@github.com>
References: <aGIOW_F7ba5mho6Pb3qbg6jRmTGeScxxNoFZlqQ9J9E=.766676cc-9c96-4b6d-8f21-7a923f9f1b30@github.com>
 <86v_lI0kWTXQv5hJaMZ1-XKOtVRYo2BoJbvl45sDD1g=.8b870c70-9db6-45ba-9fab-77bf25d55e8e@github.com>
 <jJb7U14M7il8fK2xZORD5xjYGNrzF-Q9Pzm-3Vaj12k=.ff1ea29a-be4d-45b2-91c6-0b017e169cdb@github.com>
 <D7Fvz_BSEs3HSritnp1Q-9ZQTDQ7ShTJhZVqkzpGt1g=.8bdbc0b1-6db0-4db4-a52e-b6fad95350b9@github.com>
 <DMktIzmBGtHPSzZGnNpjbqVRjWipqXYFEsi_Y_7MZAU=.7a1eef68-7bdd-4ba2-838b-6191ef757758@github.com>
Message-ID: <2erNuwebxTHUkBSXftAPqKZcsScib95eBfVeP49H9Z0=.be208fb5-0257-4bb2-9df1-0bd0ffaa9960@github.com>

On Thu, 5 May 2022 14:04:15 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> I could, but lets ask @egahlin for his opinion. He proposed it in the first place.
>
> I think it's better to use the timeout provided by jtreg than hardwiring in a number in the test.
> 
> The test could be run on different hardware or in modes that are very slow.  It's better to allow the framework to provide the timeout. The test should not fail, so it shouldn't be an issue.
> 
> I think the code looks fine, but could you remove the update to the documentation / specification. Also, perhaps add a comment in the test that the execution event requires a separate thread because the thread streaming events gets excluded from JFR (to avoid recursion).
> 
> I will take it for a spin a few hundred times on different platforms to see if there are any intermittent issues.

I ran the test about 200 times on Windows, Linux and Mac and it seems fine.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8183

From clanger at openjdk.java.net  Fri May  6 21:53:49 2022
From: clanger at openjdk.java.net (Christoph Langer)
Date: Fri, 6 May 2022 21:53:49 GMT
Subject: RFR: 8284686: Interval of < 1 ms disables ExecutionSample events
 [v6]
In-Reply-To: <86v_lI0kWTXQv5hJaMZ1-XKOtVRYo2BoJbvl45sDD1g=.8b870c70-9db6-45ba-9fab-77bf25d55e8e@github.com>
References: <aGIOW_F7ba5mho6Pb3qbg6jRmTGeScxxNoFZlqQ9J9E=.766676cc-9c96-4b6d-8f21-7a923f9f1b30@github.com>
 <86v_lI0kWTXQv5hJaMZ1-XKOtVRYo2BoJbvl45sDD1g=.8b870c70-9db6-45ba-9fab-77bf25d55e8e@github.com>
Message-ID: <TY7zd5AryCxWk9GkQ2otPeideaQEk3K6g5RS90Ko7k4=.f641a252-fadb-4e65-9f7d-3684fc3f65b9@github.com>

On Thu, 5 May 2022 11:02:09 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> Fixes the issue by rounding the period interval to the next full millisecond larger than zero.
>> 
>> The following from the bug report works now:
>> 
>> java -XX:StartFlightRecording=filename=flight.jfr,jdk.ExecutionSample#period=999us CLASS_FILE; jfr print --events jdk.ExecutionSample flight.jfr
>> 
>> It considers the period to be `1ms`, producing the recording as expected.
>
> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add TestShortPeriod
>  - Remove TestPeriodSetting

test/jdk/jdk/jfr/api/recording/event/TestShortPeriod.java line 2:

> 1: /*
> 2:  * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved.

@parttimenerd Since you wrote the test, it should have SAP copyright.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8183

From egahlin at openjdk.java.net  Sat May  7 02:38:22 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Sat, 7 May 2022 02:38:22 GMT
Subject: RFR: 8282420: JFR: Remove event handlers [v2]
In-Reply-To: <KjE68jWImpVDbfN2S7Yv1XPKYC8LvFHcY25B9qQ8Lkg=.529b39a0-74e8-4157-8cb7-9ed9e6109169@github.com>
References: <KjE68jWImpVDbfN2S7Yv1XPKYC8LvFHcY25B9qQ8Lkg=.529b39a0-74e8-4157-8cb7-9ed9e6109169@github.com>
Message-ID: <e2mVNtsUwsKkfiOlhjJOxHpvtNDGlbccR6XM5DwIxSI=.3ce57077-db90-4051-aa7d-1f9ae5b5d2bb@github.com>

> Hi,
> 
> Could I have a review of a fix that removes event handler classes for JFR. Bytecode for event instrumentation is now only added to the event class. Benefits are:
> 
> - No class memory leak in the boot class loader.
> - Reduce overhead from class loading during startup, which is important with additional JDK events that are coming (VirtualThreadStart etc.)
> - One less frame to traverse when recording a Java stack trace.
> 
> Future benefits are:
> 
> - Simplify creating instrumentation as a build step. See https://bugs.openjdk.java.net/browse/JDK-8279354
> - Simplify implementation of Event Metrics. See https://bugs.openjdk.java.net/browse/JDK-8224749
> 
> When the Security Manager is removed, much of the code being added for security reasons can be deleted.
> 
> There are few JFR hooks when code is being linked. Plan is to also use these for other events later. 
> 
> Testing: tier 1-4, jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Cleanups

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8383/files
  - new: https://git.openjdk.java.net/jdk/pull/8383/files/28de553d..3e4d9068

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8383&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8383&range=00-01

  Stats: 124 lines in 12 files changed: 11 ins; 50 del; 63 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8383.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8383/head:pull/8383

PR: https://git.openjdk.java.net/jdk/pull/8383

From egahlin at openjdk.java.net  Sat May  7 02:38:23 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Sat, 7 May 2022 02:38:23 GMT
Subject: RFR: 8282420: JFR: Remove event handlers [v2]
In-Reply-To: <_5I-X5S5yMBx0VCDRirEt6UlBqqgWFU9VcF-jDDIejM=.f250a9e7-ce30-4a8a-b641-8978a2df7735@github.com>
References: <KjE68jWImpVDbfN2S7Yv1XPKYC8LvFHcY25B9qQ8Lkg=.529b39a0-74e8-4157-8cb7-9ed9e6109169@github.com>
 <_5I-X5S5yMBx0VCDRirEt6UlBqqgWFU9VcF-jDDIejM=.f250a9e7-ce30-4a8a-b641-8978a2df7735@github.com>
Message-ID: <hkmxS9N1YxK73RBCY-TzyA3TtzY1pS0X20av14RTvIU=.7b59e27a-0be6-48ac-8b71-7faceb264a81@github.com>

On Thu, 5 May 2022 07:05:07 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanups
>
> src/hotspot/share/jfr/instrumentation/jfrResolution.hpp line 41:
> 
>> 39:   static void on_resolution(const CallInfo & info, TRAPS);
>> 40:   static void on_resolution(const Parse * parse, const ciKlass * holder, const ciMethod * target);
>> 41:   static void on_resolution(const GraphBuilder * builder, const ciKlass * holder, const ciMethod * target);
> 
> Could you add brief comments as when will each callback be called?
> Eg. the second form is called from C1 and the third form is called from C2 (assuming based on what I see in the cpp file)?

Renamed the methods to on_runtime_resolution, on_c1_resolution and on_c2_resolution to make it clearer. I hope this is sufficient.

> src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 92:
> 
>> 90: 
>> 91:         public boolean isString() {
>> 92:             return ASMToolkit.TYPE_STRING.getDescriptor().equals(fieldDescriptor);
> 
> If this is to be called often it might be beneficial to cache the descriptor instead of recreating it each time.

Turns out this method is not needed, so I removed it. I also changed the classes FieldInfo and SettingInfo into record classes and while at it, I also made EventInstrumentation (shallow) immutable so guardEventConfiguration is now passed in the constructor.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8383

From egahlin at openjdk.java.net  Sat May  7 02:49:41 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Sat, 7 May 2022 02:49:41 GMT
Subject: RFR: 8282420: JFR: Remove event handlers [v2]
In-Reply-To: <_5I-X5S5yMBx0VCDRirEt6UlBqqgWFU9VcF-jDDIejM=.f250a9e7-ce30-4a8a-b641-8978a2df7735@github.com>
References: <KjE68jWImpVDbfN2S7Yv1XPKYC8LvFHcY25B9qQ8Lkg=.529b39a0-74e8-4157-8cb7-9ed9e6109169@github.com>
 <_5I-X5S5yMBx0VCDRirEt6UlBqqgWFU9VcF-jDDIejM=.f250a9e7-ce30-4a8a-b641-8978a2df7735@github.com>
Message-ID: <4bA2dwkR9Pkvu8toW69vI9Z4tEEg1wyDbXwZ5uw57Q8=.cacb7815-d439-48d0-898b-e44fb7cf442c@github.com>

On Thu, 5 May 2022 09:36:27 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanups
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformEventType.java line 109:
> 
>> 107:             }
>> 108:         }
>> 109:         return 3;
> 
> Why is the default stack trace offset changed?

Previously the stack looked like this:

   UserEvent::commit() {
   UserEventHandler::write(startTime, duration ...);
   EventWriter::puStackTrace();
   JVM::getStackTraceId(4);

Now it looks like this:

   UserEvent::commit() {
   EventWriter::puStackTrace();
   JVM::getStackTraceId(3);
   
The branches isUsingConfiguration() and isExceptionEvent() are not affected because they used the EventHandler directly previously.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8383

From egahlin at openjdk.java.net  Sat May  7 03:02:39 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Sat, 7 May 2022 03:02:39 GMT
Subject: RFR: 8282420: JFR: Remove event handlers [v2]
In-Reply-To: <_5I-X5S5yMBx0VCDRirEt6UlBqqgWFU9VcF-jDDIejM=.f250a9e7-ce30-4a8a-b641-8978a2df7735@github.com>
References: <KjE68jWImpVDbfN2S7Yv1XPKYC8LvFHcY25B9qQ8Lkg=.529b39a0-74e8-4157-8cb7-9ed9e6109169@github.com>
 <_5I-X5S5yMBx0VCDRirEt6UlBqqgWFU9VcF-jDDIejM=.f250a9e7-ce30-4a8a-b641-8978a2df7735@github.com>
Message-ID: <OOEyh4yknyw7InxPL3csjGUmcmaAFWgwz94ZeJxigog=.a46db2d2-0e02-423c-980b-6cb7a1d84cf3@github.com>

On Thu, 5 May 2022 09:20:09 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanups
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 139:
> 
>> 137:         this.settingInfos = buildSettingInfos(superClass, classNode);
>> 138:         this.fieldInfos = buildFieldInfos(superClass, classNode);
>> 139:         String n = annotationValue(classNode, ANNOTATION_TYPE_NAME.getDescriptor(), String.class);
> 
> As well - the descriptor could be cached to avoid calling substring operations repeatedly.

Changed from Type to String in some places to reduce allocation. More could be done with the Method descriptor, but I didn't want to go overboard. If needed, I rather handle it separately.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8383

From egahlin at openjdk.java.net  Sat May  7 03:14:06 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Sat, 7 May 2022 03:14:06 GMT
Subject: RFR: 8282420: JFR: Remove event handlers [v3]
In-Reply-To: <KjE68jWImpVDbfN2S7Yv1XPKYC8LvFHcY25B9qQ8Lkg=.529b39a0-74e8-4157-8cb7-9ed9e6109169@github.com>
References: <KjE68jWImpVDbfN2S7Yv1XPKYC8LvFHcY25B9qQ8Lkg=.529b39a0-74e8-4157-8cb7-9ed9e6109169@github.com>
Message-ID: <f6jrsXA4Vp_Z-H-NcImP-VL7BYI7hx4byag2NkBBy2s=.2bf1a19a-2794-437c-a26a-6f93f636f48e@github.com>

> Hi,
> 
> Could I have a review of a fix that removes event handler classes for JFR. Bytecode for event instrumentation is now only added to the event class. Benefits are:
> 
> - No class memory leak in the boot class loader.
> - Reduce overhead from class loading during startup, which is important with additional JDK events that are coming (VirtualThreadStart etc.)
> - One less frame to traverse when recording a Java stack trace.
> 
> Future benefits are:
> 
> - Simplify creating instrumentation as a build step. See https://bugs.openjdk.java.net/browse/JDK-8279354
> - Simplify implementation of Event Metrics. See https://bugs.openjdk.java.net/browse/JDK-8224749
> 
> When the Security Manager is removed, much of the code being added for security reasons can be deleted.
> 
> There are few JFR hooks when code is being linked. Plan is to also use these for other events later. 
> 
> Testing: tier 1-4, jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Typos in cleanups

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8383/files
  - new: https://git.openjdk.java.net/jdk/pull/8383/files/3e4d9068..81989dd6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8383&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8383&range=01-02

  Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8383.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8383/head:pull/8383

PR: https://git.openjdk.java.net/jdk/pull/8383

From alanb at openjdk.java.net  Sat May  7 06:04:51 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 7 May 2022 06:04:51 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v14]
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <3Qd4HYCpL8oQztouBMiY7c_7lMBS16X23WTpP65FIzk=.6e4209ba-ce7f-4049-807b-5b6b6ad459ff@github.com>

> This is the implementation of JEP 425: Virtual Threads (Preview).
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - Refresh 4e99b5185eef9398c4cc4e90544de4a3153d61a9
 - Merge with 5212535a276a92d96ca20bdcfccfbce956febdb1
 - Refresh 6ace49bf42e5504c69fa11c564e8e865c0a95fb3
 - Merge with 9425ab2b43b649bd591706bfc820e9c8795a6fdf
 - Refresh 12aa09ce7efd48425cc080d0b8761aca0f3e215f
 - Merge with 1bb4de2e2868a539846ec48dd43fd623c2ba69a5
 - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05
 - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89
 - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
 - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
 - ... and 13 more: https://git.openjdk.java.net/jdk/compare/5212535a...df43e6fc

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8166/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=13
  Stats: 99468 lines in 1133 files changed: 91198 ins; 3598 del; 4672 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8166.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Sat May  7 08:09:45 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 7 May 2022 08:09:45 GMT
Subject: Integrated: 8284161: Implementation of Virtual Threads (Preview)
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <qTZgwH4SV8Df3Gz9y3-k6b_F275b3pEmB7wGBYQScK4=.29139c98-29de-41e0-9541-2e686005cb31@github.com>

On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is the implementation of JEP 425: Virtual Threads (Preview).
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

This pull request has now been integrated.

Changeset: 9583e365
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9583e3657e43cc1c6f2101a64534564db2a9bd84
Stats:     99468 lines in 1133 files changed: 91198 ins; 3598 del; 4672 mod

8284161: Implementation of Virtual Threads (Preview)

Co-authored-by: Ron Pressler <rpressler at openjdk.org>
Co-authored-by: Alan Bateman <alanb at openjdk.org>
Co-authored-by: Erik ?sterlund <eosterlund at openjdk.org>
Co-authored-by: Andrew Haley <aph at openjdk.org>
Co-authored-by: Rickard B?ckman <rbackman at openjdk.org>
Co-authored-by: Markus Gr?nlund <mgronlun at openjdk.org>
Co-authored-by: Leonid Mesnik <lmesnik at openjdk.org>
Co-authored-by: Serguei Spitsyn <sspitsyn at openjdk.org>
Co-authored-by: Chris Plummer <cjplummer at openjdk.org>
Co-authored-by: Coleen Phillimore <coleenp at openjdk.org>
Co-authored-by: Robbin Ehn <rehn at openjdk.org>
Co-authored-by: Stefan Karlsson <stefank at openjdk.org>
Co-authored-by: Thomas Schatzl <tschatzl at openjdk.org>
Co-authored-by: Sergey Kuksenko <skuksenko at openjdk.org>
Reviewed-by: lancea, eosterlund, rehn, sspitsyn, stefank, tschatzl, dfuchs, lmesnik, dcubed, kevinw, amenkov, dlong, mchung, psandoz, bpb, coleenp, smarks, egahlin, mseledtsov, coffeys, darcy

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From egahlin at openjdk.java.net  Sun May  8 13:02:14 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Sun, 8 May 2022 13:02:14 GMT
Subject: RFR: 8282420: JFR: Remove event handlers [v4]
In-Reply-To: <KjE68jWImpVDbfN2S7Yv1XPKYC8LvFHcY25B9qQ8Lkg=.529b39a0-74e8-4157-8cb7-9ed9e6109169@github.com>
References: <KjE68jWImpVDbfN2S7Yv1XPKYC8LvFHcY25B9qQ8Lkg=.529b39a0-74e8-4157-8cb7-9ed9e6109169@github.com>
Message-ID: <L8iHw-vf2huEakjW3DOtsieq6tC3gp1JKd5Y5Py1MaQ=.f827560a-3161-4a85-b68d-1f343df3d54e@github.com>

> Hi,
> 
> Could I have a review of a fix that removes event handler classes for JFR. Bytecode for event instrumentation is now only added to the event class. Benefits are:
> 
> - No class memory leak in the boot class loader.
> - Reduce overhead from class loading during startup, which is important with additional JDK events that are coming (VirtualThreadStart etc.)
> - One less frame to traverse when recording a Java stack trace.
> 
> Future benefits are:
> 
> - Simplify creating instrumentation as a build step. See https://bugs.openjdk.java.net/browse/JDK-8279354
> - Simplify implementation of Event Metrics. See https://bugs.openjdk.java.net/browse/JDK-8224749
> 
> When the Security Manager is removed, much of the code being added for security reasons can be deleted.
> 
> There are few JFR hooks when code is being linked. Plan is to also use these for other events later. 
> 
> Testing: tier 1-4, jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge
 - Typos in cleanups
 - Cleanups
 - Test cleanup
 - Test fixes
 - Fix whitespaces
 - Use EventWriterFactory
 - Initial

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8383/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8383&range=03
  Stats: 4076 lines in 82 files changed: 2415 ins; 1050 del; 611 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8383.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8383/head:pull/8383

PR: https://git.openjdk.java.net/jdk/pull/8383

From duke at openjdk.java.net  Sun May  8 20:18:45 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Sun, 8 May 2022 20:18:45 GMT
Subject: RFR: 8284686: Interval of < 1 ms disables ExecutionSample events
 [v6]
In-Reply-To: <TY7zd5AryCxWk9GkQ2otPeideaQEk3K6g5RS90Ko7k4=.f641a252-fadb-4e65-9f7d-3684fc3f65b9@github.com>
References: <aGIOW_F7ba5mho6Pb3qbg6jRmTGeScxxNoFZlqQ9J9E=.766676cc-9c96-4b6d-8f21-7a923f9f1b30@github.com>
 <86v_lI0kWTXQv5hJaMZ1-XKOtVRYo2BoJbvl45sDD1g=.8b870c70-9db6-45ba-9fab-77bf25d55e8e@github.com>
 <TY7zd5AryCxWk9GkQ2otPeideaQEk3K6g5RS90Ko7k4=.f641a252-fadb-4e65-9f7d-3684fc3f65b9@github.com>
Message-ID: <DxBnwlNl8VCMdsnS6c6j24J1oTBEA6z3lXm65_9CvQA=.b53fd025-366a-44b0-9896-1ce1ba8db63a@github.com>

On Fri, 6 May 2022 21:50:22 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add TestShortPeriod
>>  - Remove TestPeriodSetting
>
> test/jdk/jdk/jfr/api/recording/event/TestShortPeriod.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved.
> 
> @parttimenerd Since you wrote the test, it should have SAP copyright.

"Oracle" -> "SAP"?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8183

From clanger at openjdk.java.net  Mon May  9 06:35:50 2022
From: clanger at openjdk.java.net (Christoph Langer)
Date: Mon, 9 May 2022 06:35:50 GMT
Subject: RFR: 8284686: Interval of < 1 ms disables ExecutionSample events
 [v6]
In-Reply-To: <DxBnwlNl8VCMdsnS6c6j24J1oTBEA6z3lXm65_9CvQA=.b53fd025-366a-44b0-9896-1ce1ba8db63a@github.com>
References: <aGIOW_F7ba5mho6Pb3qbg6jRmTGeScxxNoFZlqQ9J9E=.766676cc-9c96-4b6d-8f21-7a923f9f1b30@github.com>
 <86v_lI0kWTXQv5hJaMZ1-XKOtVRYo2BoJbvl45sDD1g=.8b870c70-9db6-45ba-9fab-77bf25d55e8e@github.com>
 <TY7zd5AryCxWk9GkQ2otPeideaQEk3K6g5RS90Ko7k4=.f641a252-fadb-4e65-9f7d-3684fc3f65b9@github.com>
 <DxBnwlNl8VCMdsnS6c6j24J1oTBEA6z3lXm65_9CvQA=.b53fd025-366a-44b0-9896-1ce1ba8db63a@github.com>
Message-ID: <w5BZMczoq-KZ_zBPtObM3JFLXzuH9DLtfpSeQZSBAmI=.1220f8f6-1f17-470f-9b69-60505ae86e6d@github.com>

On Sun, 8 May 2022 20:14:58 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> test/jdk/jdk/jfr/api/recording/event/TestShortPeriod.java line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved.
>> 
>> @parttimenerd Since you wrote the test, it should have SAP copyright.
>
> "Oracle" -> "SAP"?

Yes, should look like here: https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/nio/zipfs/TestPosix.java

Although for SAP we usually don't use a comma before SAP... so it should probably be:
`Copyright (c) 2022 SAP SE. All rights reserved.`

-------------

PR: https://git.openjdk.java.net/jdk/pull/8183

From duke at openjdk.java.net  Mon May  9 07:44:39 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Mon, 9 May 2022 07:44:39 GMT
Subject: RFR: 8284686: Interval of < 1 ms disables ExecutionSample events
 [v7]
In-Reply-To: <aGIOW_F7ba5mho6Pb3qbg6jRmTGeScxxNoFZlqQ9J9E=.766676cc-9c96-4b6d-8f21-7a923f9f1b30@github.com>
References: <aGIOW_F7ba5mho6Pb3qbg6jRmTGeScxxNoFZlqQ9J9E=.766676cc-9c96-4b6d-8f21-7a923f9f1b30@github.com>
Message-ID: <nv4kp0Dc7FYYcir5CzSdIU9VQRdyx-nODZqHi1MYw-4=.af846b14-3ebd-4535-aec2-ce68fd84ca06@github.com>

> Fixes the issue by rounding the period interval to the next full millisecond larger than zero.
> 
> The following from the bug report works now:
> 
> java -XX:StartFlightRecording=filename=flight.jfr,jdk.ExecutionSample#period=999us CLASS_FILE; jfr print --events jdk.ExecutionSample flight.jfr
> 
> It considers the period to be `1ms`, producing the recording as expected.

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Update documentation

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8183/files
  - new: https://git.openjdk.java.net/jdk/pull/8183/files/e5b7f55c..eda59421

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8183&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8183&range=05-06

  Stats: 5 lines in 2 files changed: 2 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8183.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8183/head:pull/8183

PR: https://git.openjdk.java.net/jdk/pull/8183

From asotona at openjdk.java.net  Mon May  9 16:05:46 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Mon, 9 May 2022 16:05:46 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound
 assignments
Message-ID: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>

Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.

The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.

The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 

Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.

Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.

Thanks for your review,
Adam

-------------

Commit messages:
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
 - 8244681: Add a warning for possibly lossy conversion in compound assignments

Changes: https://git.openjdk.java.net/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244681
  Stats: 449 lines in 26 files changed: 444 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From erikj at openjdk.java.net  Mon May  9 16:33:56 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 9 May 2022 16:33:56 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <QMW2y8ihFHz3GPVQLMACiUV5aGbvwcreUKbGfVwaWGg=.2b5fe22c-6331-4ac2-a05d-44a1b65e85c0@github.com>

On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Build changes look good.

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8599

From prr at openjdk.java.net  Mon May  9 17:55:55 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 9 May 2022 17:55:55 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <cih52bus7vW_1tDS7D7szxNTdayfjQxSeHRJhL99DSc=.f5a417b9-844a-4a34-b0b4-8591ac4e28cb@github.com>

On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Marked as reviewed by prr (Reviewer).

test/langtools/tools/javac/lint/LossyConversions.java line 131:

> 129:     @SuppressWarnings("lossy-conversions")
> 130:     public void supressedLossyConversions() {
> 131:         byte a = 0;

you might want to spell suppressed correctly.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8599

From egahlin at openjdk.java.net  Mon May  9 18:24:48 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Mon, 9 May 2022 18:24:48 GMT
Subject: RFR: 8284686: Interval of < 1 ms disables ExecutionSample events
 [v7]
In-Reply-To: <nv4kp0Dc7FYYcir5CzSdIU9VQRdyx-nODZqHi1MYw-4=.af846b14-3ebd-4535-aec2-ce68fd84ca06@github.com>
References: <aGIOW_F7ba5mho6Pb3qbg6jRmTGeScxxNoFZlqQ9J9E=.766676cc-9c96-4b6d-8f21-7a923f9f1b30@github.com>
 <nv4kp0Dc7FYYcir5CzSdIU9VQRdyx-nODZqHi1MYw-4=.af846b14-3ebd-4535-aec2-ce68fd84ca06@github.com>
Message-ID: <x1AvA7s0ykFkYktw0vSd3S5Qgc6opD56y5uI24ejpiw=.03cdc603-eee4-4892-80c4-c4641c89b20b@github.com>

On Mon, 9 May 2022 07:44:39 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> Fixes the issue by rounding the period interval to the next full millisecond larger than zero.
>> 
>> The following from the bug report works now:
>> 
>> java -XX:StartFlightRecording=filename=flight.jfr,jdk.ExecutionSample#period=999us CLASS_FILE; jfr print --events jdk.ExecutionSample flight.jfr
>> 
>> It considers the period to be `1ms`, producing the recording as expected.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update documentation

Marked as reviewed by egahlin (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8183

From prr at openjdk.java.net  Mon May  9 18:36:59 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 9 May 2022 18:36:59 GMT
Subject: RFR: 8280035: Use Class.isInstance instead of
 Class.isAssignableFrom where applicable [v2]
In-Reply-To: <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
References: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
 <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
Message-ID: <TNi7tutFJLMg6yutpu2AsFme3MkCanqOVXcfb4iSX0A=.431d79e6-1f09-4370-8057-3784d9a6864e@github.com>

On Thu, 31 Mar 2022 08:03:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Method `Class.isAssignableFrom` is often used in form of:
>> 
>>     if (clazz.isAssignableFrom(obj.getClass())) {
>> Such condition could be simplified to more shorter and performarnt code
>> 
>>     if (clazz.isInstance(obj)) {
>>     
>> Replacement is equivalent if it's known that `obj != null`.
>> In JDK codebase there are many such places.
>> 
>> I tried to measure performance via JMH
>> 
>>     Class<?> integerClass = Integer.class;
>>     Class<?> numberClass = Number.class;
>> 
>>     Object integerObject = 45666;
>>     Object doubleObject = 8777d;
>> 
>>     @Benchmark
>>     public boolean integerInteger_isInstance() {
>>         return integerClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerInteger_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isInstance() {
>>         return integerClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isInstance() {
>>         return numberClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isInstance() {
>>         return numberClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public void numberIntegerDouble_isInstance(Blackhole bh) {
>>         bh.consume(numberClass.isInstance(integerObject));
>>         bh.consume(numberClass.isInstance(doubleObject));
>>     }
>> 
>>     @Benchmark
>>     public void integerIntegerDouble_isAssignableFrom(Blackhole bh) {
>>         bh.consume(integerClass.isAssignableFrom(integerObject.getClass()));
>>         bh.consume(integerClass.isAssignableFrom(doubleObject.getClass()));
>>     }
>> 
>> `isInstance` is a bit faster than `isAssignableFrom`
>> 
>> Benchmark                              Mode  Cnt  Score   Error  Units
>> integerDouble_isAssignableFrom         avgt    5  1,173 ? 0,026  ns/op
>> integerDouble_isInstance               avgt    5  0,939 ? 0,038  ns/op
>> integerIntegerDouble_isAssignableFrom  avgt    5  2,106 ? 0,068  ns/op
>> numberIntegerDouble_isInstance         avgt    5  1,516 ? 0,046  ns/op
>> integerInteger_isAssignableFrom        avgt    5  1,175 ? 0,029  ns/op
>> integerInteger_isInstance              avgt    5  0,886 ? 0,017  ns/op
>> numberDouble_isAssignableFrom          avgt    5  1,172 ? 0,007  ns/op
>> numberDouble_isInstance                avgt    5  0,891 ? 0,030  ns/op
>> numberInteger_isAssignableFrom         avgt    5  1,169 ? 0,014  ns/op
>> numberInteger_isInstance               avgt    5  0,887 ? 0,016  ns/op
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable
>   apply suggestion to avoid second Method.invoke call

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7061

From duke at openjdk.java.net  Mon May  9 19:31:52 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Mon, 9 May 2022 19:31:52 GMT
Subject: Integrated: 8284686: Interval of < 1 ms disables ExecutionSample
 events
In-Reply-To: <aGIOW_F7ba5mho6Pb3qbg6jRmTGeScxxNoFZlqQ9J9E=.766676cc-9c96-4b6d-8f21-7a923f9f1b30@github.com>
References: <aGIOW_F7ba5mho6Pb3qbg6jRmTGeScxxNoFZlqQ9J9E=.766676cc-9c96-4b6d-8f21-7a923f9f1b30@github.com>
Message-ID: <4jckh630_8AdNZdMaDvQf_VvgeHDNfEJ2jLHTtoTMEI=.93cebc0c-6316-4410-a2b3-44bdf053575c@github.com>

On Mon, 11 Apr 2022 16:53:08 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

> Fixes the issue by rounding the period interval to the next full millisecond larger than zero.
> 
> The following from the bug report works now:
> 
> java -XX:StartFlightRecording=filename=flight.jfr,jdk.ExecutionSample#period=999us CLASS_FILE; jfr print --events jdk.ExecutionSample flight.jfr
> 
> It considers the period to be `1ms`, producing the recording as expected.

This pull request has now been integrated.

Changeset: 902b1dd4
Author:    Johannes Bechberger <johannes.bechberger at sap.com>
Committer: Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/902b1dd4550136c520e5ec6cb8c4fe9a81218938
Stats:     100 lines in 2 files changed: 97 ins; 0 del; 3 mod

8284686: Interval of < 1 ms disables ExecutionSample events

Reviewed-by: egahlin

-------------

PR: https://git.openjdk.java.net/jdk/pull/8183

From darcy at openjdk.java.net  Mon May  9 20:26:56 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 9 May 2022 20:26:56 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <8O_QfMi1b_fhddBS7yzm9cwzf-l6nWbfNs6qFJWdtuU=.22f44b80-54e8-4249-8ece-d02be29f4267@github.com>

On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

I see there is already a bug filed to address situations found by the new warning in the JDK's libraries (JDK-8286374). As a matter of policy, I recommend the (potential) warnings be addressed in at least the java.base and java.desktop modules before the new warning is enabled. In other words, a priority should be given to keeping java.base and java.desktop compiling successfully with all warnings enabled.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8599

From asotona at openjdk.java.net  Tue May 10 08:46:45 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Tue, 10 May 2022 08:46:45 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <oWxFgbGHRAk_wFpGtPGtfrAlzLUVXctQCCRZ9pi43Mg=.ee995996-668b-4509-98c0-76337a2f9818@github.com>

On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

I agree with the priority to keep java.base and java.desktop clean from possibly lossy conversions, so the related issues should probably raise from P4 priority level.

However this lint warning as a part of the javac is critical to confirm that the situations have been correctly addressed.
If we want to avoid "blind" patching, we only two possible scenarios:
1. big homogenous patch including hundreds of fixed lines of code across many "moving-target" classes, together with lint warning implemented and enabled 
2. javac lint patch (disabled for affected JDK modules build) goes first, so each case can be resolved, reviewed and validated in individual patch 

>From complexity and cost perspective I prefer the second scenario.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8599

From asotona at openjdk.java.net  Tue May 10 09:07:44 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Tue, 10 May 2022 09:07:44 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v2]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <umZcmzwHYP-3A50ORfu4n9EQ-kqvn7zwJMjn3aTJbLM=.a4c996d0-d373-4233-9b81-259905dcfd7f@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  8244681: Add a warning for possibly lossy conversion in compound assignments
  recommended correction of the warning wording
  fixed typo in test method name

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8599/files
  - new: https://git.openjdk.java.net/jdk/pull/8599/files/47779ba5..6b3942b8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From dfuchs at openjdk.java.net  Tue May 10 11:16:48 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 10 May 2022 11:16:48 GMT
Subject: RFR: 8280035: Use Class.isInstance instead of
 Class.isAssignableFrom where applicable [v2]
In-Reply-To: <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
References: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
 <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
Message-ID: <RYNCwh7eHPTdYusU_PAZuvo0BIPXlrWbs7ppxq-1UjQ=.59650d85-491d-4509-b212-f694ef6afd94@github.com>

On Thu, 31 Mar 2022 08:03:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Method `Class.isAssignableFrom` is often used in form of:
>> 
>>     if (clazz.isAssignableFrom(obj.getClass())) {
>> Such condition could be simplified to more shorter and performarnt code
>> 
>>     if (clazz.isInstance(obj)) {
>>     
>> Replacement is equivalent if it's known that `obj != null`.
>> In JDK codebase there are many such places.
>> 
>> I tried to measure performance via JMH
>> 
>>     Class<?> integerClass = Integer.class;
>>     Class<?> numberClass = Number.class;
>> 
>>     Object integerObject = 45666;
>>     Object doubleObject = 8777d;
>> 
>>     @Benchmark
>>     public boolean integerInteger_isInstance() {
>>         return integerClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerInteger_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isInstance() {
>>         return integerClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isInstance() {
>>         return numberClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isInstance() {
>>         return numberClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public void numberIntegerDouble_isInstance(Blackhole bh) {
>>         bh.consume(numberClass.isInstance(integerObject));
>>         bh.consume(numberClass.isInstance(doubleObject));
>>     }
>> 
>>     @Benchmark
>>     public void integerIntegerDouble_isAssignableFrom(Blackhole bh) {
>>         bh.consume(integerClass.isAssignableFrom(integerObject.getClass()));
>>         bh.consume(integerClass.isAssignableFrom(doubleObject.getClass()));
>>     }
>> 
>> `isInstance` is a bit faster than `isAssignableFrom`
>> 
>> Benchmark                              Mode  Cnt  Score   Error  Units
>> integerDouble_isAssignableFrom         avgt    5  1,173 ? 0,026  ns/op
>> integerDouble_isInstance               avgt    5  0,939 ? 0,038  ns/op
>> integerIntegerDouble_isAssignableFrom  avgt    5  2,106 ? 0,068  ns/op
>> numberIntegerDouble_isInstance         avgt    5  1,516 ? 0,046  ns/op
>> integerInteger_isAssignableFrom        avgt    5  1,175 ? 0,029  ns/op
>> integerInteger_isInstance              avgt    5  0,886 ? 0,017  ns/op
>> numberDouble_isAssignableFrom          avgt    5  1,172 ? 0,007  ns/op
>> numberDouble_isInstance                avgt    5  0,891 ? 0,030  ns/op
>> numberInteger_isAssignableFrom         avgt    5  1,169 ? 0,014  ns/op
>> numberInteger_isInstance               avgt    5  0,887 ? 0,016  ns/op
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable
>   apply suggestion to avoid second Method.invoke call

src/java.desktop/share/classes/javax/imageio/spi/ServiceRegistry.java line 230:

> 228:         List<SubRegistry> l = new ArrayList<>();
> 229:         for (Class<?> c : categoryMap.keySet()) {
> 230:             if (c.isInstance(provider)) {

Can this be reached if `provider` is null? If yes there could be a change of behaviour as the previous code would have thrown NPE.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7061

From aturbanov at openjdk.java.net  Tue May 10 11:35:04 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Tue, 10 May 2022 11:35:04 GMT
Subject: RFR: 8280035: Use Class.isInstance instead of
 Class.isAssignableFrom where applicable [v2]
In-Reply-To: <RYNCwh7eHPTdYusU_PAZuvo0BIPXlrWbs7ppxq-1UjQ=.59650d85-491d-4509-b212-f694ef6afd94@github.com>
References: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
 <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
 <RYNCwh7eHPTdYusU_PAZuvo0BIPXlrWbs7ppxq-1UjQ=.59650d85-491d-4509-b212-f694ef6afd94@github.com>
Message-ID: <iyPHYWiIL0mqxp3iaAaDT3pMp6tFWEpERqLGJ2sgiao=.1f3e0af5-0d64-4769-9282-c120201fe5e0@github.com>

On Tue, 10 May 2022 11:10:50 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable
>>   apply suggestion to avoid second Method.invoke call
>
> src/java.desktop/share/classes/javax/imageio/spi/ServiceRegistry.java line 230:
> 
>> 228:         List<SubRegistry> l = new ArrayList<>();
>> 229:         for (Class<?> c : categoryMap.keySet()) {
>> 230:             if (c.isInstance(provider)) {
> 
> Can this be reached if `provider` is null? If yes there could be a change of behaviour as the previous code would have thrown NPE.

No. This method is called from 3 places,  and there 3 null checks before the method call.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7061

From dfuchs at openjdk.java.net  Tue May 10 11:43:55 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 10 May 2022 11:43:55 GMT
Subject: RFR: 8280035: Use Class.isInstance instead of
 Class.isAssignableFrom where applicable [v2]
In-Reply-To: <iyPHYWiIL0mqxp3iaAaDT3pMp6tFWEpERqLGJ2sgiao=.1f3e0af5-0d64-4769-9282-c120201fe5e0@github.com>
References: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
 <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
 <RYNCwh7eHPTdYusU_PAZuvo0BIPXlrWbs7ppxq-1UjQ=.59650d85-491d-4509-b212-f694ef6afd94@github.com>
 <iyPHYWiIL0mqxp3iaAaDT3pMp6tFWEpERqLGJ2sgiao=.1f3e0af5-0d64-4769-9282-c120201fe5e0@github.com>
Message-ID: <endEBOSOYQDoktP2AgDxXQDJK6XpeuHGvgATOffZHmo=.9635df10-a2c3-40be-81ea-aa4ffc80bdcb@github.com>

On Tue, 10 May 2022 11:31:16 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/imageio/spi/ServiceRegistry.java line 230:
>> 
>>> 228:         List<SubRegistry> l = new ArrayList<>();
>>> 229:         for (Class<?> c : categoryMap.keySet()) {
>>> 230:             if (c.isInstance(provider)) {
>> 
>> Can this be reached if `provider` is null? If yes there could be a change of behaviour as the previous code would have thrown NPE.
>
> No. This method is called from 3 places,  and there 3 null checks before the method call.

Thanks for double checking! LGTM then.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7061

From egahlin at openjdk.java.net  Tue May 10 12:14:22 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Tue, 10 May 2022 12:14:22 GMT
Subject: RFR: 8286392: Address possibly lossy conversions in jdk.jfr
Message-ID: <A0a810gCFSiCaE3XSP3paGz20nml76ft9RCs5MGLe-c=.3289047f-d1fa-42da-bbf8-d1158e68c260@github.com>

Could I have a fix of this lossy conversion issue.

Testing: jdk/jdk/jfr

Thanks
Erik

-------------

Commit messages:
 - Initial

Changes: https://git.openjdk.java.net/jdk/pull/8600/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8600&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286392
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8600.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8600/head:pull/8600

PR: https://git.openjdk.java.net/jdk/pull/8600

From egahlin at openjdk.java.net  Tue May 10 12:14:35 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Tue, 10 May 2022 12:14:35 GMT
Subject: RFR: 8286396: Address possibly lossy conversions in jdk.management.jfr
Message-ID: <PJgdLEk1_xRYJipkuJv9BuCwKFKbVqTN7VA215dYRng=.7a7527f7-0038-45f0-bca9-d8d5d0c2ca2e@github.com>

Could I have a review of two lossy conversion issues.

The size of an event can't be larger than 2^28, so it shouldn't be an issue in practise, but the type id could potentially be larger than 2^31, but it would require a user to load more than 2 billion classes. 

Testing: jdk/jdk/jfr

Thanks
Erik

-------------

Commit messages:
 - Initial

Changes: https://git.openjdk.java.net/jdk/pull/8603/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8603&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286396
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8603.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8603/head:pull/8603

PR: https://git.openjdk.java.net/jdk/pull/8603

From ihse at openjdk.java.net  Tue May 10 13:29:51 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 10 May 2022 13:29:51 GMT
Subject: RFR: 8286392: Address possibly lossy conversions in jdk.jfr
In-Reply-To: <A0a810gCFSiCaE3XSP3paGz20nml76ft9RCs5MGLe-c=.3289047f-d1fa-42da-bbf8-d1158e68c260@github.com>
References: <A0a810gCFSiCaE3XSP3paGz20nml76ft9RCs5MGLe-c=.3289047f-d1fa-42da-bbf8-d1158e68c260@github.com>
Message-ID: <X-Mfy9ePKprEJ9k720b9Nnqpj9Vq0uPocZ30mXJ5Wq8=.97dbea91-7168-4c95-b7af-0d4902f55c59@github.com>

On Mon, 9 May 2022 17:16:06 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a fix of this lossy conversion issue.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

This (and JDK-8286396) needs to be coordinated with JDK-8244681. Either that PR should not add the `DISABLED_WARNINGS` for the JFR modules, or -- if this PR goes in afterwards -- it needs to remove it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8600

From egahlin at openjdk.java.net  Tue May 10 13:56:42 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Tue, 10 May 2022 13:56:42 GMT
Subject: RFR: 8282420: JFR: Remove event handlers [v5]
In-Reply-To: <KjE68jWImpVDbfN2S7Yv1XPKYC8LvFHcY25B9qQ8Lkg=.529b39a0-74e8-4157-8cb7-9ed9e6109169@github.com>
References: <KjE68jWImpVDbfN2S7Yv1XPKYC8LvFHcY25B9qQ8Lkg=.529b39a0-74e8-4157-8cb7-9ed9e6109169@github.com>
Message-ID: <NMYgXTh4SrCbnbObhk-2kRSJHyqWQV9-xjNF85kf_Nw=.b918ca38-9008-4780-b0ed-b64d52b41808@github.com>

> Hi,
> 
> Could I have a review of a fix that removes event handler classes for JFR. Bytecode for event instrumentation is now only added to the event class. Benefits are:
> 
> - No class memory leak in the boot class loader.
> - Reduce overhead from class loading during startup, which is important with additional JDK events that are coming (VirtualThreadStart etc.)
> - One less frame to traverse when recording a Java stack trace.
> 
> Future benefits are:
> 
> - Simplify creating instrumentation as a build step. See https://bugs.openjdk.java.net/browse/JDK-8279354
> - Simplify implementation of Event Metrics. See https://bugs.openjdk.java.net/browse/JDK-8224749
> 
> When the Security Manager is removed, much of the code being added for security reasons can be deleted.
> 
> There are few JFR hooks when code is being linked. Plan is to also use these for other events later. 
> 
> Testing: tier 1-4, jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Reviewer feedback

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8383/files
  - new: https://git.openjdk.java.net/jdk/pull/8383/files/2bf6ed15..2a9081d1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8383&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8383&range=03-04

  Stats: 25 lines in 10 files changed: 7 ins; 0 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8383.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8383/head:pull/8383

PR: https://git.openjdk.java.net/jdk/pull/8383

From coleenp at openjdk.java.net  Tue May 10 14:21:49 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 10 May 2022 14:21:49 GMT
Subject: RFR: 8286480: Remove the c1 getEventWriter() intrinsic to simplify
 post-Loom integration platform-porting efforts
In-Reply-To: <LQwA8Qaht353IvODBOhNu2dD4IgJDGMXigQ_xuubodQ=.b210c7c5-4a45-4dfc-8aca-eaaeaa7a3a8e@github.com>
References: <LQwA8Qaht353IvODBOhNu2dD4IgJDGMXigQ_xuubodQ=.b210c7c5-4a45-4dfc-8aca-eaaeaa7a3a8e@github.com>
Message-ID: <OYl5nSW8jozcKONywvCkM7XTrcY9HQL5RM6JVvDMS54=.cc5923d9-b147-4486-8700-08f2cf0c6d63@github.com>

On Tue, 10 May 2022 14:01:24 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> The C1 intrinsic for getEventWriter() did not materialize and is currently only bouncing a platform-specific stub to enter the VM, putting an unnecessary burden on post-Loom integration platform-porting efforts.
> 
> The platform-specific stub for C2, jfr_write_checkpoint, is still needed but is only called if a java/lang/VirtualThread is mounted. As such, it could be left unimplemented.
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

This looks good but might want to time it with the x86 32 and ppc loom changes, where they've added stubs for these already.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8631

From shade at openjdk.java.net  Tue May 10 14:35:50 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 10 May 2022 14:35:50 GMT
Subject: RFR: 8286480: Remove the c1 getEventWriter() intrinsic to simplify
 post-Loom integration platform-porting efforts
In-Reply-To: <LQwA8Qaht353IvODBOhNu2dD4IgJDGMXigQ_xuubodQ=.b210c7c5-4a45-4dfc-8aca-eaaeaa7a3a8e@github.com>
References: <LQwA8Qaht353IvODBOhNu2dD4IgJDGMXigQ_xuubodQ=.b210c7c5-4a45-4dfc-8aca-eaaeaa7a3a8e@github.com>
Message-ID: <-JlqRE2WTj_RZffHmw9q_zpeSCNIz2p8pdryV6pctcc=.aa2b38c1-5450-4a6e-afee-f2c1f816e2b1@github.com>

On Tue, 10 May 2022 14:01:24 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> The C1 intrinsic for getEventWriter() did not materialize and is currently only bouncing a platform-specific stub to enter the VM, putting an unnecessary burden on post-Loom integration platform-porting efforts.
> 
> The platform-specific stub for C2, jfr_write_checkpoint, is still needed but is only called if a java/lang/VirtualThread is mounted. As such, it could be left unimplemented.
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

If you can integrate this soon, I can rebase #8630 afterwards.

This would probably break RISC-V that is already in the mainline, though.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8631

From egahlin at openjdk.java.net  Tue May 10 14:42:58 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Tue, 10 May 2022 14:42:58 GMT
Subject: RFR: 8282420: JFR: Remove event handlers [v6]
In-Reply-To: <KjE68jWImpVDbfN2S7Yv1XPKYC8LvFHcY25B9qQ8Lkg=.529b39a0-74e8-4157-8cb7-9ed9e6109169@github.com>
References: <KjE68jWImpVDbfN2S7Yv1XPKYC8LvFHcY25B9qQ8Lkg=.529b39a0-74e8-4157-8cb7-9ed9e6109169@github.com>
Message-ID: <xiaijCW9wjortMwDiFZYoOq5Nt24Fretm3z8kpZtju4=.aa792a85-1822-4536-b44f-c666e2a87233@github.com>

> Hi,
> 
> Could I have a review of a fix that removes event handler classes for JFR. Bytecode for event instrumentation is now only added to the event class. Benefits are:
> 
> - No class memory leak in the boot class loader.
> - Reduce overhead from class loading during startup, which is important with additional JDK events that are coming (VirtualThreadStart etc.)
> - One less frame to traverse when recording a Java stack trace.
> 
> Future benefits are:
> 
> - Simplify creating instrumentation as a build step. See https://bugs.openjdk.java.net/browse/JDK-8279354
> - Simplify implementation of Event Metrics. See https://bugs.openjdk.java.net/browse/JDK-8224749
> 
> When the Security Manager is removed, much of the code being added for security reasons can be deleted.
> 
> There are few JFR hooks when code is being linked. Plan is to also use these for other events later. 
> 
> Testing: tier 1-4, jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Minor fixes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8383/files
  - new: https://git.openjdk.java.net/jdk/pull/8383/files/2a9081d1..193c9d80

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8383&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8383&range=04-05

  Stats: 5 lines in 3 files changed: 0 ins; 2 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8383.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8383/head:pull/8383

PR: https://git.openjdk.java.net/jdk/pull/8383

From mgronlun at openjdk.java.net  Tue May 10 14:43:00 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 10 May 2022 14:43:00 GMT
Subject: RFR: 8282420: JFR: Remove event handlers [v5]
In-Reply-To: <NMYgXTh4SrCbnbObhk-2kRSJHyqWQV9-xjNF85kf_Nw=.b918ca38-9008-4780-b0ed-b64d52b41808@github.com>
References: <KjE68jWImpVDbfN2S7Yv1XPKYC8LvFHcY25B9qQ8Lkg=.529b39a0-74e8-4157-8cb7-9ed9e6109169@github.com>
 <NMYgXTh4SrCbnbObhk-2kRSJHyqWQV9-xjNF85kf_Nw=.b918ca38-9008-4780-b0ed-b64d52b41808@github.com>
Message-ID: <1cp7VMWSN1Vr12vH329tgudVuQrEIpzaYvx-Qjzwl5Y=.5719a33a-ef81-431c-8893-8d6c96ec7886@github.com>

On Tue, 10 May 2022 13:56:42 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Hi,
>> 
>> Could I have a review of a fix that removes event handler classes for JFR. Bytecode for event instrumentation is now only added to the event class. Benefits are:
>> 
>> - No class memory leak in the boot class loader.
>> - Reduce overhead from class loading during startup, which is important with additional JDK events that are coming (VirtualThreadStart etc.)
>> - One less frame to traverse when recording a Java stack trace.
>> 
>> Future benefits are:
>> 
>> - Simplify creating instrumentation as a build step. See https://bugs.openjdk.java.net/browse/JDK-8279354
>> - Simplify implementation of Event Metrics. See https://bugs.openjdk.java.net/browse/JDK-8224749
>> 
>> When the Security Manager is removed, much of the code being added for security reasons can be deleted.
>> 
>> There are few JFR hooks when code is being linked. Plan is to also use these for other events later. 
>> 
>> Testing: tier 1-4, jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reviewer feedback

Marked as reviewed by mgronlun (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8383

From mgronlun at openjdk.java.net  Tue May 10 14:46:07 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 10 May 2022 14:46:07 GMT
Subject: RFR: 8286480: Remove the c1 getEventWriter() intrinsic to simplify
 post-Loom integration platform-porting efforts
In-Reply-To: <-JlqRE2WTj_RZffHmw9q_zpeSCNIz2p8pdryV6pctcc=.aa2b38c1-5450-4a6e-afee-f2c1f816e2b1@github.com>
References: <LQwA8Qaht353IvODBOhNu2dD4IgJDGMXigQ_xuubodQ=.b210c7c5-4a45-4dfc-8aca-eaaeaa7a3a8e@github.com>
 <-JlqRE2WTj_RZffHmw9q_zpeSCNIz2p8pdryV6pctcc=.aa2b38c1-5450-4a6e-afee-f2c1f816e2b1@github.com>
Message-ID: <U1cvmDAFIQdIMekVYseo6BOdowoAlTys5Pb40hOt7uw=.f1b00479-7462-4621-863f-6cef593ab7c9@github.com>

On Tue, 10 May 2022 14:33:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This would probably break RISC-V that is already in the mainline, though.

Good catch, I will update that code as well.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8631

From shade at openjdk.java.net  Tue May 10 14:46:08 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 10 May 2022 14:46:08 GMT
Subject: RFR: 8286480: Remove the c1 getEventWriter() intrinsic to simplify
 post-Loom integration platform-porting efforts
In-Reply-To: <U1cvmDAFIQdIMekVYseo6BOdowoAlTys5Pb40hOt7uw=.f1b00479-7462-4621-863f-6cef593ab7c9@github.com>
References: <LQwA8Qaht353IvODBOhNu2dD4IgJDGMXigQ_xuubodQ=.b210c7c5-4a45-4dfc-8aca-eaaeaa7a3a8e@github.com>
 <-JlqRE2WTj_RZffHmw9q_zpeSCNIz2p8pdryV6pctcc=.aa2b38c1-5450-4a6e-afee-f2c1f816e2b1@github.com>
 <U1cvmDAFIQdIMekVYseo6BOdowoAlTys5Pb40hOt7uw=.f1b00479-7462-4621-863f-6cef593ab7c9@github.com>
Message-ID: <84kjihd6lw1C35L01WoBjrsXmIr42Leh3X8TridI9mA=.74a48d40-bff8-4ffc-a71a-f393ca562854@github.com>

On Tue, 10 May 2022 14:40:41 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> > This would probably break RISC-V that is already in the mainline, though.
> 
> Good catch, I will update that code as well.

Just take this patch, I already tested it on RISC-V box: http://cr.openjdk.java.net/~shade/8286480/risc-v.patch

-------------

PR: https://git.openjdk.java.net/jdk/pull/8631

From mgronlun at openjdk.java.net  Tue May 10 15:02:29 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 10 May 2022 15:02:29 GMT
Subject: RFR: 8286480: Remove the c1 getEventWriter() intrinsic to simplify
 post-Loom integration platform-porting efforts [v2]
In-Reply-To: <LQwA8Qaht353IvODBOhNu2dD4IgJDGMXigQ_xuubodQ=.b210c7c5-4a45-4dfc-8aca-eaaeaa7a3a8e@github.com>
References: <LQwA8Qaht353IvODBOhNu2dD4IgJDGMXigQ_xuubodQ=.b210c7c5-4a45-4dfc-8aca-eaaeaa7a3a8e@github.com>
Message-ID: <ZsGKZADsV1w0MStvc04e9Y7JrWSjt5n8kqdcPBRouag=.e8526216-e947-4800-9c56-99826d3bbffc@github.com>

> Greetings,
> 
> The C1 intrinsic for getEventWriter() did not materialize and is currently only bouncing a platform-specific stub to enter the VM, putting an unnecessary burden on post-Loom integration platform-porting efforts.
> 
> The platform-specific stub for C2, jfr_write_checkpoint, is still needed but is only called if a java/lang/VirtualThread is mounted. As such, it could be left unimplemented.
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision:

 - missing comma
 - riscv

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8631/files
  - new: https://git.openjdk.java.net/jdk/pull/8631/files/4e38c4ba..c21ec34e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8631&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8631&range=00-01

  Stats: 20 lines in 1 file changed: 2 ins; 13 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8631.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8631/head:pull/8631

PR: https://git.openjdk.java.net/jdk/pull/8631

From mgronlun at openjdk.java.net  Tue May 10 15:02:30 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 10 May 2022 15:02:30 GMT
Subject: RFR: 8286480: Remove the c1 getEventWriter() intrinsic to simplify
 post-Loom integration platform-porting efforts [v2]
In-Reply-To: <UPOQG-7dkILRfNwwWnqoNSoEvsRmHUcv3nR7otBJcLc=.205791ad-38ce-4933-ab10-0535c8ea9c02@github.com>
References: <LQwA8Qaht353IvODBOhNu2dD4IgJDGMXigQ_xuubodQ=.b210c7c5-4a45-4dfc-8aca-eaaeaa7a3a8e@github.com>
 <ZsGKZADsV1w0MStvc04e9Y7JrWSjt5n8kqdcPBRouag=.e8526216-e947-4800-9c56-99826d3bbffc@github.com>
 <UPOQG-7dkILRfNwwWnqoNSoEvsRmHUcv3nR7otBJcLc=.205791ad-38ce-4933-ab10-0535c8ea9c02@github.com>
Message-ID: <dirIqkSR6Zo0Cyri1omD-RprOo9EXZY16mvNTw16g6k=.9201801f-5334-426f-9f40-596b87ce3450@github.com>

On Tue, 10 May 2022 14:55:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - missing comma
>>  - riscv
>
> src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 3770:
> 
>> 3768:     address the_pc = __ pc();
>> 3769:     jfr_prologue(the_pc, _masm, xthread);
>> 3770:     __ call_VM_leaf(CAST_FROM_FN_PTR(address, JfrIntrinsicSupport::write_checkpoint) 1);
> 
> Spot the missing comma. ;)

Haha, should have taken your patch :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8631

From shade at openjdk.java.net  Tue May 10 15:02:29 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 10 May 2022 15:02:29 GMT
Subject: RFR: 8286480: Remove the c1 getEventWriter() intrinsic to simplify
 post-Loom integration platform-porting efforts [v2]
In-Reply-To: <ZsGKZADsV1w0MStvc04e9Y7JrWSjt5n8kqdcPBRouag=.e8526216-e947-4800-9c56-99826d3bbffc@github.com>
References: <LQwA8Qaht353IvODBOhNu2dD4IgJDGMXigQ_xuubodQ=.b210c7c5-4a45-4dfc-8aca-eaaeaa7a3a8e@github.com>
 <ZsGKZADsV1w0MStvc04e9Y7JrWSjt5n8kqdcPBRouag=.e8526216-e947-4800-9c56-99826d3bbffc@github.com>
Message-ID: <UPOQG-7dkILRfNwwWnqoNSoEvsRmHUcv3nR7otBJcLc=.205791ad-38ce-4933-ab10-0535c8ea9c02@github.com>

On Tue, 10 May 2022 14:59:38 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> The C1 intrinsic for getEventWriter() did not materialize and is currently only bouncing a platform-specific stub to enter the VM, putting an unnecessary burden on post-Loom integration platform-porting efforts.
>> 
>> The platform-specific stub for C2, jfr_write_checkpoint, is still needed but is only called if a java/lang/VirtualThread is mounted. As such, it could be left unimplemented.
>> 
>> Testing: jdk_jfr
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - missing comma
>  - riscv

Changes requested by shade (Reviewer).

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 3770:

> 3768:     address the_pc = __ pc();
> 3769:     jfr_prologue(the_pc, _masm, xthread);
> 3770:     __ call_VM_leaf(CAST_FROM_FN_PTR(address, JfrIntrinsicSupport::write_checkpoint) 1);

Spot the missing comma. ;)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8631

From shade at openjdk.java.net  Tue May 10 15:08:13 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 10 May 2022 15:08:13 GMT
Subject: RFR: 8286480: Remove the c1 getEventWriter() intrinsic to simplify
 post-Loom integration platform-porting efforts [v2]
In-Reply-To: <ZsGKZADsV1w0MStvc04e9Y7JrWSjt5n8kqdcPBRouag=.e8526216-e947-4800-9c56-99826d3bbffc@github.com>
References: <LQwA8Qaht353IvODBOhNu2dD4IgJDGMXigQ_xuubodQ=.b210c7c5-4a45-4dfc-8aca-eaaeaa7a3a8e@github.com>
 <ZsGKZADsV1w0MStvc04e9Y7JrWSjt5n8kqdcPBRouag=.e8526216-e947-4800-9c56-99826d3bbffc@github.com>
Message-ID: <TdekSfZjMzNsoToVcG4ouOvctOkb6UeKI9Zt5Gtdycs=.52fa4db3-2fdf-4c23-bf54-877e04e96b40@github.com>

On Tue, 10 May 2022 15:02:29 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> The C1 intrinsic for getEventWriter() did not materialize and is currently only bouncing a platform-specific stub to enter the VM, putting an unnecessary burden on post-Loom integration platform-porting efforts.
>> 
>> The platform-specific stub for C2, jfr_write_checkpoint, is still needed but is only called if a java/lang/VirtualThread is mounted. As such, it could be left unimplemented.
>> 
>> Testing: jdk_jfr
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - missing comma
>  - riscv

RISC-V runs more or less fine with this patch.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8631

From mgronlun at openjdk.java.net  Tue May 10 15:13:49 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 10 May 2022 15:13:49 GMT
Subject: RFR: 8286480: Remove the c1 getEventWriter() intrinsic to simplify
 post-Loom integration platform-porting efforts [v2]
In-Reply-To: <ZsGKZADsV1w0MStvc04e9Y7JrWSjt5n8kqdcPBRouag=.e8526216-e947-4800-9c56-99826d3bbffc@github.com>
References: <LQwA8Qaht353IvODBOhNu2dD4IgJDGMXigQ_xuubodQ=.b210c7c5-4a45-4dfc-8aca-eaaeaa7a3a8e@github.com>
 <ZsGKZADsV1w0MStvc04e9Y7JrWSjt5n8kqdcPBRouag=.e8526216-e947-4800-9c56-99826d3bbffc@github.com>
Message-ID: <Q1Yn703f0_z0-Wekr8AdgD1SS0bgcIpTZNDDFLqLaY4=.114bdb53-a821-43a0-b730-26ec246657dc@github.com>

On Tue, 10 May 2022 15:02:29 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> The C1 intrinsic for getEventWriter() did not materialize and is currently only bouncing a platform-specific stub to enter the VM, putting an unnecessary burden on post-Loom integration platform-porting efforts.
>> 
>> The platform-specific stub for C2, jfr_write_checkpoint, is still needed but is only called if a java/lang/VirtualThread is mounted. As such, it could be left unimplemented.
>> 
>> Testing: jdk_jfr
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - missing comma
>  - riscv

Thanks for reviewing! I would propose to integrate this right away to help unblock porting efforts.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8631

From mgronlun at openjdk.java.net  Tue May 10 15:21:58 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 10 May 2022 15:21:58 GMT
Subject: Integrated: 8286480: Remove the c1 getEventWriter() intrinsic to
 simplify post-Loom integration platform-porting efforts
In-Reply-To: <LQwA8Qaht353IvODBOhNu2dD4IgJDGMXigQ_xuubodQ=.b210c7c5-4a45-4dfc-8aca-eaaeaa7a3a8e@github.com>
References: <LQwA8Qaht353IvODBOhNu2dD4IgJDGMXigQ_xuubodQ=.b210c7c5-4a45-4dfc-8aca-eaaeaa7a3a8e@github.com>
Message-ID: <68hgoKnLfKHemcM9kmkQ3ctZIQqo5rSid3tKuKThwAE=.778f223c-ae05-4fac-9041-af647073f3a4@github.com>

On Tue, 10 May 2022 14:01:24 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> The C1 intrinsic for getEventWriter() did not materialize and is currently only bouncing a platform-specific stub to enter the VM, putting an unnecessary burden on post-Loom integration platform-porting efforts.
> 
> The platform-specific stub for C2, jfr_write_checkpoint, is still needed but is only called if a java/lang/VirtualThread is mounted. As such, it could be left unimplemented.
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

This pull request has now been integrated.

Changeset: fa25733d
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fa25733d7603dff214a17c2ce95a564de965b6af
Stats:     103 lines in 10 files changed: 7 ins; 81 del; 15 mod

8286480: Remove the c1 getEventWriter() intrinsic to simplify post-Loom integration platform-porting efforts

Reviewed-by: coleenp, shade

-------------

PR: https://git.openjdk.java.net/jdk/pull/8631

From egahlin at openjdk.java.net  Tue May 10 16:17:44 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Tue, 10 May 2022 16:17:44 GMT
Subject: Integrated: 8282420: JFR: Remove event handlers
In-Reply-To: <KjE68jWImpVDbfN2S7Yv1XPKYC8LvFHcY25B9qQ8Lkg=.529b39a0-74e8-4157-8cb7-9ed9e6109169@github.com>
References: <KjE68jWImpVDbfN2S7Yv1XPKYC8LvFHcY25B9qQ8Lkg=.529b39a0-74e8-4157-8cb7-9ed9e6109169@github.com>
Message-ID: <d5-0zNSeg4Vxoqau0LNmpL02lAkMtroz8zNBUu0C0wk=.244f94ab-73d6-444b-a2e8-4d6870340df2@github.com>

On Mon, 25 Apr 2022 16:49:42 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Hi,
> 
> Could I have a review of a fix that removes event handler classes for JFR. Bytecode for event instrumentation is now only added to the event class. Benefits are:
> 
> - No class memory leak in the boot class loader.
> - Reduce overhead from class loading during startup, which is important with additional JDK events that are coming (VirtualThreadStart etc.)
> - One less frame to traverse when recording a Java stack trace.
> 
> Future benefits are:
> 
> - Simplify creating instrumentation as a build step. See https://bugs.openjdk.java.net/browse/JDK-8279354
> - Simplify implementation of Event Metrics. See https://bugs.openjdk.java.net/browse/JDK-8224749
> 
> When the Security Manager is removed, much of the code being added for security reasons can be deleted.
> 
> There are few JFR hooks when code is being linked. Plan is to also use these for other events later. 
> 
> Testing: tier 1-4, jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 0f377363
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0f3773635d3f20866472b505ac390bac10ed4676
Stats:     4083 lines in 82 files changed: 2420 ins; 1050 del; 613 mod

8282420: JFR: Remove event handlers

Reviewed-by: mgronlun

-------------

PR: https://git.openjdk.java.net/jdk/pull/8383

From egahlin at openjdk.java.net  Tue May 10 18:20:14 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Tue, 10 May 2022 18:20:14 GMT
Subject: RFR: 8286015 JFR: Remove jfr.save.generated.asm
Message-ID: <w9YlPwqWB-V8CwzcGZF8ym3CvooI5y1JFJfnlmOnevo=.9414ad1e-fba4-45dc-9495-a860380c0e33@github.com>

Could I have a review of a fix that removes the jfr.save.generated.asm property.

It was a developer property that could be set to write generated JFR .class files to disk. The mechanism doesn't work due to a bug, but nobody has noticed it for years. For debugging JFR bytecode generation, it's much more convenient to use  -Xlog:jfr+system+bytecode=trace to print ASM to standard output. 

Testing: jdk/jdk/jfr

Thanks
Erik

-------------

Commit messages:
 - Initial

Changes: https://git.openjdk.java.net/jdk/pull/8637/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8637&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286015
  Stats: 32 lines in 3 files changed: 0 ins; 31 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8637.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8637/head:pull/8637

PR: https://git.openjdk.java.net/jdk/pull/8637

From egahlin at openjdk.java.net  Tue May 10 20:55:22 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Tue, 10 May 2022 20:55:22 GMT
Subject: RFR: 8286515: JFR: Remove SimpleStringIdPool class
Message-ID: <miUd_zoJxiMRjN3Nxa-F0CLFqQKL4_ob22s4cHRJTl8=.c6e18791-1cdc-4edb-94da-9e5952045bbf@github.com>

Could I have review of a fix that removes an unnecessary indirection when using the string pool.

Testing: jdk/jdk/jfr

Thanks
Erik

-------------

Commit messages:
 - Move non-final field
 - Initial

Changes: https://git.openjdk.java.net/jdk/pull/8638/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8638&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286515
  Stats: 96 lines in 1 file changed: 24 ins; 39 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8638.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8638/head:pull/8638

PR: https://git.openjdk.java.net/jdk/pull/8638

From mgronlun at openjdk.java.net  Tue May 10 21:12:48 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 10 May 2022 21:12:48 GMT
Subject: RFR: 8286015 JFR: Remove jfr.save.generated.asm
In-Reply-To: <w9YlPwqWB-V8CwzcGZF8ym3CvooI5y1JFJfnlmOnevo=.9414ad1e-fba4-45dc-9495-a860380c0e33@github.com>
References: <w9YlPwqWB-V8CwzcGZF8ym3CvooI5y1JFJfnlmOnevo=.9414ad1e-fba4-45dc-9495-a860380c0e33@github.com>
Message-ID: <oUWVT6sttrwC89asX6pOoHeVk88_f9hC5663_Ham1xM=.58bbafd1-2954-4836-8c94-c9c42810d525@github.com>

On Tue, 10 May 2022 17:59:58 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a fix that removes the jfr.save.generated.asm property.
> 
> It was a developer property that could be set to write generated JFR .class files to disk. The mechanism doesn't work due to a bug, but nobody has noticed it for years. For debugging JFR bytecode generation, it's much more convenient to use  -Xlog:jfr+system+bytecode=trace to print ASM to standard output. 
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Looks good.

-------------

Marked as reviewed by mgronlun (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8637

From mgronlun at openjdk.java.net  Tue May 10 21:13:50 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 10 May 2022 21:13:50 GMT
Subject: RFR: 8286515: JFR: Remove SimpleStringIdPool class
In-Reply-To: <miUd_zoJxiMRjN3Nxa-F0CLFqQKL4_ob22s4cHRJTl8=.c6e18791-1cdc-4edb-94da-9e5952045bbf@github.com>
References: <miUd_zoJxiMRjN3Nxa-F0CLFqQKL4_ob22s4cHRJTl8=.c6e18791-1cdc-4edb-94da-9e5952045bbf@github.com>
Message-ID: <SELrEPCDKC7foN2gZpzxyxcAZvwC6PlcSNZB4AQ_GOk=.075ff683-b976-491a-962b-d857dcac99ec@github.com>

On Tue, 10 May 2022 18:59:48 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of a fix that removes an unnecessary indirection when using the string pool.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Looks good.

-------------

Marked as reviewed by mgronlun (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8638

From egahlin at openjdk.java.net  Wed May 11 00:18:19 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 11 May 2022 00:18:19 GMT
Subject: RFR: 8286541: JFR: RecordingFile.write is missing "since 19"
Message-ID: <DYXDMAKUEsyag6PPS0y-p1nqWwRO86XGw8dG8Wn4NpQ=.949d7450-abe6-44b8-9bef-07faa4d92baa@github.com>

Could I have review of a fix that add "since 19" to the RecordingFile.write(Path, Predicate) methods.

Testing: build and verify javadoc 

Thanks
Erik

-------------

Commit messages:
 - Initial

Changes: https://git.openjdk.java.net/jdk/pull/8643/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8643&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286541
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8643.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8643/head:pull/8643

PR: https://git.openjdk.java.net/jdk/pull/8643

From jrose at openjdk.java.net  Wed May 11 06:28:37 2022
From: jrose at openjdk.java.net (John R Rose)
Date: Wed, 11 May 2022 06:28:37 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v2]
In-Reply-To: <umZcmzwHYP-3A50ORfu4n9EQ-kqvn7zwJMjn3aTJbLM=.a4c996d0-d373-4233-9b81-259905dcfd7f@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <umZcmzwHYP-3A50ORfu4n9EQ-kqvn7zwJMjn3aTJbLM=.a4c996d0-d373-4233-9b81-259905dcfd7f@github.com>
Message-ID: <sISfnxp1FBO9eR2lfA8D57iqvW-Xq2VFduvRezba1ok=.74a7448d-7f76-4be8-9180-d8b479d56c03@github.com>

On Tue, 10 May 2022 09:07:44 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
>> 
>> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
>> 
>> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
>> 
>> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
>> 
>> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
>> 
>> Thanks for your review,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8244681: Add a warning for possibly lossy conversion in compound assignments
>   recommended correction of the warning wording
>   fixed typo in test method name

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties line 210:

> 208: 
> 209: javac.opt.Xlint.desc.lossy-conversions=\
> 210:     Warn about compiler possible lossy conversions.

I like this warning.  But the documentation doesn't even parse as English.

I suggest this, as more grammatical and precise:

> Warn about possible lossy conversions in compound assignments

-------------

PR: https://git.openjdk.java.net/jdk/pull/8599

From asotona at openjdk.java.net  Wed May 11 07:45:39 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 11 May 2022 07:45:39 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  8244681: Add a warning for possibly lossy conversion in compound assignments
  recommended correction of the warning description

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8599/files
  - new: https://git.openjdk.java.net/jdk/pull/8599/files/6b3942b8..f0729396

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From egahlin at openjdk.java.net  Wed May 11 11:24:29 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 11 May 2022 11:24:29 GMT
Subject: RFR: 8286392: Address possibly lossy conversions in jdk.jfr [v2]
In-Reply-To: <A0a810gCFSiCaE3XSP3paGz20nml76ft9RCs5MGLe-c=.3289047f-d1fa-42da-bbf8-d1158e68c260@github.com>
References: <A0a810gCFSiCaE3XSP3paGz20nml76ft9RCs5MGLe-c=.3289047f-d1fa-42da-bbf8-d1158e68c260@github.com>
Message-ID: <opyPR9JVAaafz20Ph7UVWtREFutGU6z45Zl0KI9exhg=.1f1330fc-a2d6-4c65-9495-ba4f0f85f00a@github.com>

> Could I have a fix of this lossy conversion issue.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin 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 two additional commits since the last revision:

 - Merge branch 'openjdk:master' into lossy_jdkjfr
 - Initial

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8600/files
  - new: https://git.openjdk.java.net/jdk/pull/8600/files/ca573327..598aa319

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8600&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8600&range=00-01

  Stats: 7706 lines in 219 files changed: 4221 ins; 2119 del; 1366 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8600.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8600/head:pull/8600

PR: https://git.openjdk.java.net/jdk/pull/8600

From egahlin at openjdk.java.net  Wed May 11 11:29:29 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 11 May 2022 11:29:29 GMT
Subject: RFR: 8286396: Address possibly lossy conversions in
 jdk.management.jfr [v2]
In-Reply-To: <PJgdLEk1_xRYJipkuJv9BuCwKFKbVqTN7VA215dYRng=.7a7527f7-0038-45f0-bca9-d8d5d0c2ca2e@github.com>
References: <PJgdLEk1_xRYJipkuJv9BuCwKFKbVqTN7VA215dYRng=.7a7527f7-0038-45f0-bca9-d8d5d0c2ca2e@github.com>
Message-ID: <MZXNhsjZeKccsxOoeSVdReezkgKDSAmTY0IuQ6D60zs=.2268be2e-ee32-4228-91c6-da902fb560be@github.com>

> Could I have a review of two lossy conversion issues.
> 
> The size of an event can't be larger than 2^28, so it shouldn't be an issue in practise, but the type id could potentially be larger than 2^31, but it would require a user to load more than 2 billion classes. 
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin 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 two additional commits since the last revision:

 - Merge branch 'openjdk:master' into lossy_jdkmanagementjfr
 - Initial

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8603/files
  - new: https://git.openjdk.java.net/jdk/pull/8603/files/47329c10..bb498043

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8603&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8603&range=00-01

  Stats: 7706 lines in 219 files changed: 4221 ins; 2119 del; 1366 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8603.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8603/head:pull/8603

PR: https://git.openjdk.java.net/jdk/pull/8603

From mgronlun at openjdk.java.net  Wed May 11 11:45:37 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 11 May 2022 11:45:37 GMT
Subject: RFR: 8286541: JFR: RecordingFile.write is missing "since 19"
In-Reply-To: <DYXDMAKUEsyag6PPS0y-p1nqWwRO86XGw8dG8Wn4NpQ=.949d7450-abe6-44b8-9bef-07faa4d92baa@github.com>
References: <DYXDMAKUEsyag6PPS0y-p1nqWwRO86XGw8dG8Wn4NpQ=.949d7450-abe6-44b8-9bef-07faa4d92baa@github.com>
Message-ID: <hnnziwhO8pgc97u-_0ZNt0wvNtVKY5L41nPtSTm770A=.ffa27b85-a59f-401f-9f35-5370120169af@github.com>

On Tue, 10 May 2022 21:51:40 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of a fix that add "since 19" to the RecordingFile.write(Path, Predicate) methods.
> 
> Testing: build and verify javadoc 
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8643

From mgronlun at openjdk.java.net  Wed May 11 11:54:45 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 11 May 2022 11:54:45 GMT
Subject: RFR: 8285872: JFR: Remove finalize() methods
In-Reply-To: <xxFTrGHrJQwMiBupk8MgWLoVaDXWNMeLyWBSrCpxSpw=.a5bde366-a9a8-4392-bd14-ddf9a321f2d3@github.com>
References: <xxFTrGHrJQwMiBupk8MgWLoVaDXWNMeLyWBSrCpxSpw=.a5bde366-a9a8-4392-bd14-ddf9a321f2d3@github.com>
Message-ID: <UOtnB1jD4uDkNH_VGCgXv_7mJxeu8oL1J9Ok8YuPmfQ=.21eee048-95e4-4922-a3a0-e88d6dc4185e@github.com>

On Mon, 2 May 2022 22:12:48 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Hi,
> 
> Could I have review of a fix that removes the finalize() methods in the jdk.jfr module.
> 
> Chunks are reference counted so finalizers are not needed. To verify this, I added checks to the finalize() methods to make sure resources were not released when the finalizer was run. 
> 
> Testing: jdk/jdk/jfr multiple times
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8510

From mgronlun at openjdk.java.net  Wed May 11 11:56:55 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 11 May 2022 11:56:55 GMT
Subject: RFR: 8286392: Address possibly lossy conversions in jdk.jfr [v2]
In-Reply-To: <opyPR9JVAaafz20Ph7UVWtREFutGU6z45Zl0KI9exhg=.1f1330fc-a2d6-4c65-9495-ba4f0f85f00a@github.com>
References: <A0a810gCFSiCaE3XSP3paGz20nml76ft9RCs5MGLe-c=.3289047f-d1fa-42da-bbf8-d1158e68c260@github.com>
 <opyPR9JVAaafz20Ph7UVWtREFutGU6z45Zl0KI9exhg=.1f1330fc-a2d6-4c65-9495-ba4f0f85f00a@github.com>
Message-ID: <P0L6olScfyTAhjl4-8WhDfW1n1x4-FLxRLm3WEBzfSE=.3b2132e0-3746-4218-8cfc-1a66e42cf8d9@github.com>

On Wed, 11 May 2022 11:24:29 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have a fix of this lossy conversion issue.
>> 
>> Testing: jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin 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 two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into lossy_jdkjfr
>  - Initial

Marked as reviewed by mgronlun (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8600

From mgronlun at openjdk.java.net  Wed May 11 12:00:59 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 11 May 2022 12:00:59 GMT
Subject: RFR: 8286396: Address possibly lossy conversions in
 jdk.management.jfr [v2]
In-Reply-To: <MZXNhsjZeKccsxOoeSVdReezkgKDSAmTY0IuQ6D60zs=.2268be2e-ee32-4228-91c6-da902fb560be@github.com>
References: <PJgdLEk1_xRYJipkuJv9BuCwKFKbVqTN7VA215dYRng=.7a7527f7-0038-45f0-bca9-d8d5d0c2ca2e@github.com>
 <MZXNhsjZeKccsxOoeSVdReezkgKDSAmTY0IuQ6D60zs=.2268be2e-ee32-4228-91c6-da902fb560be@github.com>
Message-ID: <WUwHAiB_PF8yowUYZfRRWTRgKeR1fn48-gNAqKF55rw=.b02398a2-6821-45bf-b96a-ce3b43bd5c99@github.com>

On Wed, 11 May 2022 11:29:29 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have a review of two lossy conversion issues.
>> 
>> The size of an event can't be larger than 2^28, so it shouldn't be an issue in practise, but the type id could potentially be larger than 2^31, but it would require a user to load more than 2 billion classes. 
>> 
>> Testing: jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin 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 two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into lossy_jdkmanagementjfr
>  - Initial

Marked as reviewed by mgronlun (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8603

From egahlin at openjdk.java.net  Wed May 11 12:06:52 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 11 May 2022 12:06:52 GMT
Subject: Integrated: 8286515: JFR: Remove SimpleStringIdPool class
In-Reply-To: <miUd_zoJxiMRjN3Nxa-F0CLFqQKL4_ob22s4cHRJTl8=.c6e18791-1cdc-4edb-94da-9e5952045bbf@github.com>
References: <miUd_zoJxiMRjN3Nxa-F0CLFqQKL4_ob22s4cHRJTl8=.c6e18791-1cdc-4edb-94da-9e5952045bbf@github.com>
Message-ID: <RzDnuhOYVan8ODI1OelgSVVev9lpdDu3aYj_a3jZsAM=.66fd3e6e-ca5a-4760-a51e-3b55d0f29728@github.com>

On Tue, 10 May 2022 18:59:48 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of a fix that removes an unnecessary indirection when using the string pool.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: faa1aad4
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/faa1aad4343aa7387f93a376963942ad40642c76
Stats:     96 lines in 1 file changed: 24 ins; 39 del; 33 mod

8286515: JFR: Remove SimpleStringIdPool class

Reviewed-by: mgronlun

-------------

PR: https://git.openjdk.java.net/jdk/pull/8638

From egahlin at openjdk.java.net  Wed May 11 12:20:59 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 11 May 2022 12:20:59 GMT
Subject: Integrated: 8285872: JFR: Remove finalize() methods
In-Reply-To: <xxFTrGHrJQwMiBupk8MgWLoVaDXWNMeLyWBSrCpxSpw=.a5bde366-a9a8-4392-bd14-ddf9a321f2d3@github.com>
References: <xxFTrGHrJQwMiBupk8MgWLoVaDXWNMeLyWBSrCpxSpw=.a5bde366-a9a8-4392-bd14-ddf9a321f2d3@github.com>
Message-ID: <4qFwYnjUWRNzQ8X-wRMLZyIhqrbFwoj41i6Bbs4O6xU=.a6876e76-d8bd-4f09-bae4-eb7605521d3c@github.com>

On Mon, 2 May 2022 22:12:48 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Hi,
> 
> Could I have review of a fix that removes the finalize() methods in the jdk.jfr module.
> 
> Chunks are reference counted so finalizers are not needed. To verify this, I added checks to the finalize() methods to make sure resources were not released when the finalizer was run. 
> 
> Testing: jdk/jdk/jfr multiple times
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: f1554fc4
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f1554fc4a8e11a06465f57825fb376ba75019a2f
Stats:     28 lines in 3 files changed: 0 ins; 28 del; 0 mod

8285872: JFR: Remove finalize() methods

Reviewed-by: mgronlun

-------------

PR: https://git.openjdk.java.net/jdk/pull/8510

From egahlin at openjdk.java.net  Wed May 11 12:29:39 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 11 May 2022 12:29:39 GMT
Subject: Integrated: 8286541: JFR: RecordingFile.write is missing "since 19"
In-Reply-To: <DYXDMAKUEsyag6PPS0y-p1nqWwRO86XGw8dG8Wn4NpQ=.949d7450-abe6-44b8-9bef-07faa4d92baa@github.com>
References: <DYXDMAKUEsyag6PPS0y-p1nqWwRO86XGw8dG8Wn4NpQ=.949d7450-abe6-44b8-9bef-07faa4d92baa@github.com>
Message-ID: <J1S1Gvm0--eMyq-nkwXBWeNngcPVnb4kxoN-ZAnuUcs=.f2cdb60b-ee4b-4559-80ed-de032edf87d3@github.com>

On Tue, 10 May 2022 21:51:40 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of a fix that add "since 19" to the RecordingFile.write(Path, Predicate) methods.
> 
> Testing: build and verify javadoc 
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: f6289669
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f628966916b9772700297110e6d550f139735b4f
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8286541: JFR: RecordingFile.write is missing "since 19"

Reviewed-by: mgronlun

-------------

PR: https://git.openjdk.java.net/jdk/pull/8643

From egahlin at openjdk.java.net  Wed May 11 12:51:47 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 11 May 2022 12:51:47 GMT
Subject: Integrated: 8286392: Address possibly lossy conversions in jdk.jfr
In-Reply-To: <A0a810gCFSiCaE3XSP3paGz20nml76ft9RCs5MGLe-c=.3289047f-d1fa-42da-bbf8-d1158e68c260@github.com>
References: <A0a810gCFSiCaE3XSP3paGz20nml76ft9RCs5MGLe-c=.3289047f-d1fa-42da-bbf8-d1158e68c260@github.com>
Message-ID: <FCptOSO-QkcGYS31lY9er2RG4W5bN4aQlULAlcXlrrY=.874cfd9e-d650-4ae8-854e-c25f94a9ef2b@github.com>

On Mon, 9 May 2022 17:16:06 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a fix of this lossy conversion issue.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 9ac52b0c
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9ac52b0c2ebce89dcfd5bf8d5e87c60b9bff4c60
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8286392: Address possibly lossy conversions in jdk.jfr

Reviewed-by: mgronlun

-------------

PR: https://git.openjdk.java.net/jdk/pull/8600

From egahlin at openjdk.java.net  Wed May 11 12:55:45 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 11 May 2022 12:55:45 GMT
Subject: Integrated: 8286396: Address possibly lossy conversions in
 jdk.management.jfr
In-Reply-To: <PJgdLEk1_xRYJipkuJv9BuCwKFKbVqTN7VA215dYRng=.7a7527f7-0038-45f0-bca9-d8d5d0c2ca2e@github.com>
References: <PJgdLEk1_xRYJipkuJv9BuCwKFKbVqTN7VA215dYRng=.7a7527f7-0038-45f0-bca9-d8d5d0c2ca2e@github.com>
Message-ID: <6jRj9o3XSTuVJOoUqkb1yE0RTF3Q_fVh7v5I1Hpvwfw=.fc5d63ef-050d-4c51-b5f5-c89174deb410@github.com>

On Mon, 9 May 2022 18:16:22 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of two lossy conversion issues.
> 
> The size of an event can't be larger than 2^28, so it shouldn't be an issue in practise, but the type id could potentially be larger than 2^31, but it would require a user to load more than 2 billion classes. 
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 7a2bbbbc
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7a2bbbbce5914e2167ce618fabf6116892caaf45
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8286396: Address possibly lossy conversions in jdk.management.jfr

Reviewed-by: mgronlun

-------------

PR: https://git.openjdk.java.net/jdk/pull/8603

From egahlin at openjdk.java.net  Wed May 11 13:05:46 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 11 May 2022 13:05:46 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
Message-ID: <PWtwdccbXVxNM6h8D5nH5AzTqjGk9y5se7lGEE-ToHU=.135fd8e6-f702-41c0-9397-e165c29adb77@github.com>

On Wed, 11 May 2022 07:45:39 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
>> 
>> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
>> 
>> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
>> 
>> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
>> 
>> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
>> 
>> Thanks for your review,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8244681: Add a warning for possibly lossy conversion in compound assignments
>   recommended correction of the warning description

Lossy conversion issues for jdk.jfr and jdk.management.jfr. have been fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8599

From ihse at openjdk.java.net  Wed May 11 13:05:46 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 11 May 2022 13:05:46 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
Message-ID: <KY5Ya0MQB_OK8SgR_rVF7iB-CWPNgWU1A44IjR40bvg=.e333e601-d7da-44d2-b008-2d2d9c26b685@github.com>

On Wed, 11 May 2022 07:45:39 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
>> 
>> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
>> 
>> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
>> 
>> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
>> 
>> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
>> 
>> Thanks for your review,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8244681: Add a warning for possibly lossy conversion in compound assignments
>   recommended correction of the warning description

Check updates on JDK-8286374 subtasks.

make/modules/jdk.jfr/Java.gmk line 26:

> 24: #
> 25: 
> 26: DISABLED_WARNINGS_java += exports lossy-conversions

Note that with the fix of JDK-8286392 (and JDK-8286396) the `lossy-conversions` warning should not be disabled for the JFR code. 

In general, you need to check which of the subtasks of JDK-8286374 that has been fixed, and adjust the makefiles accordingly, before pushing this fix.

(In the future, it might be easier to push the fix which disables the warnings first, and then file follow-up bugs on aa per-component basis, and remind them to remove the disabling in the makefile. That way there won't be a race between individual fixes and a "master" bug like this.)

-------------

Changes requested by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8599

From egahlin at openjdk.java.net  Wed May 11 13:08:49 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 11 May 2022 13:08:49 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <KY5Ya0MQB_OK8SgR_rVF7iB-CWPNgWU1A44IjR40bvg=.e333e601-d7da-44d2-b008-2d2d9c26b685@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
 <KY5Ya0MQB_OK8SgR_rVF7iB-CWPNgWU1A44IjR40bvg=.e333e601-d7da-44d2-b008-2d2d9c26b685@github.com>
Message-ID: <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com>

On Wed, 11 May 2022 12:59:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8244681: Add a warning for possibly lossy conversion in compound assignments
>>   recommended correction of the warning description
>
> make/modules/jdk.jfr/Java.gmk line 26:
> 
>> 24: #
>> 25: 
>> 26: DISABLED_WARNINGS_java += exports lossy-conversions
> 
> Note that with the fix of JDK-8286392 (and JDK-8286396) the `lossy-conversions` warning should not be disabled for the JFR code. 
> 
> In general, you need to check which of the subtasks of JDK-8286374 that has been fixed, and adjust the makefiles accordingly, before pushing this fix.
> 
> (In the future, it might be easier to push the fix which disables the warnings first, and then file follow-up bugs on aa per-component basis, and remind them to remove the disabling in the makefile. That way there won't be a race between individual fixes and a "master" bug like this.)

I agree, but if it doesn't happen, I can follow up with a separate PR where I remove the disablement.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8599

From ihse at openjdk.java.net  Wed May 11 13:13:43 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 11 May 2022 13:13:43 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
 <KY5Ya0MQB_OK8SgR_rVF7iB-CWPNgWU1A44IjR40bvg=.e333e601-d7da-44d2-b008-2d2d9c26b685@github.com>
 <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com>
Message-ID: <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com>

On Wed, 11 May 2022 13:05:45 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> make/modules/jdk.jfr/Java.gmk line 26:
>> 
>>> 24: #
>>> 25: 
>>> 26: DISABLED_WARNINGS_java += exports lossy-conversions
>> 
>> Note that with the fix of JDK-8286392 (and JDK-8286396) the `lossy-conversions` warning should not be disabled for the JFR code. 
>> 
>> In general, you need to check which of the subtasks of JDK-8286374 that has been fixed, and adjust the makefiles accordingly, before pushing this fix.
>> 
>> (In the future, it might be easier to push the fix which disables the warnings first, and then file follow-up bugs on aa per-component basis, and remind them to remove the disabling in the makefile. That way there won't be a race between individual fixes and a "master" bug like this.)
>
> I agree, but if it doesn't happen, I can follow up with a separate PR where I remove the disablement.

That's good to know. I think the tricky part is mostly about keeping track of all these disabled warnings, so they are not kept around longer than necessary. And that needs coordination with all the subtasks of the umbrella issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8599

From asotona at openjdk.java.net  Wed May 11 13:30:43 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 11 May 2022 13:30:43 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
 <KY5Ya0MQB_OK8SgR_rVF7iB-CWPNgWU1A44IjR40bvg=.e333e601-d7da-44d2-b008-2d2d9c26b685@github.com>
 <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com>
 <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com>
Message-ID: <dgY-0m2tjBC_KNqQmiMDb4VJzrS_m5vjamdP4J1J6sk=.3620563b-0170-4e3b-8edc-ed154b5f2927@github.com>

On Wed, 11 May 2022 13:10:10 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I agree, but if it doesn't happen, I can follow up with a separate PR where I remove the disablement.
>
> That's good to know. I think the tricky part is mostly about keeping track of all these disabled warnings, so they are not kept around longer than necessary. And that needs coordination with all the subtasks of the umbrella issue.

Thanks for quick reaction.
I'll keep my eyes on this race of patches and update this pull request accordingly or create a new PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8599

From rriggs at openjdk.java.net  Wed May 11 13:34:49 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 11 May 2022 13:34:49 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <dgY-0m2tjBC_KNqQmiMDb4VJzrS_m5vjamdP4J1J6sk=.3620563b-0170-4e3b-8edc-ed154b5f2927@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
 <KY5Ya0MQB_OK8SgR_rVF7iB-CWPNgWU1A44IjR40bvg=.e333e601-d7da-44d2-b008-2d2d9c26b685@github.com>
 <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com>
 <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com>
 <dgY-0m2tjBC_KNqQmiMDb4VJzrS_m5vjamdP4J1J6sk=.3620563b-0170-4e3b-8edc-ed154b5f2927@github.com>
Message-ID: <eBtTimIKT1ZsRwVd8woMwtHHRvqcWGUzBsMJVI6eACU=.ca2c9d89-1883-44e8-9765-77696c2f7542@github.com>

On Wed, 11 May 2022 13:27:38 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> That's good to know. I think the tricky part is mostly about keeping track of all these disabled warnings, so they are not kept around longer than necessary. And that needs coordination with all the subtasks of the umbrella issue.
>
> Thanks for quick reaction.
> I'll keep my eyes on this race of patches and update this pull request accordingly or create a new PR.

I put out a PR for java.base, but thought I'd wait until the javac fixe were pushed before integrating and would re-enable the warnings at the same time.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8599

From asotona at openjdk.java.net  Wed May 11 13:41:30 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 11 May 2022 13:41:30 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v4]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <3RgMbsaSwgdBXE2qlIwjVI680aN7Ovi6OOfu9eeNtJo=.a76eff60-8652-40ce-ae40-20f9095b1b93@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona 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 six additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning description
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning wording
   fixed typo in test method name
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   jdk.internal.le make patch to disable warnings
 - 8244681: Add a warning for possibly lossy conversion in compound assignments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8599/files
  - new: https://git.openjdk.java.net/jdk/pull/8599/files/f0729396..a59dfa4f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=02-03

  Stats: 9179 lines in 255 files changed: 5253 ins; 2422 del; 1504 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From asotona at openjdk.java.net  Wed May 11 13:41:30 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 11 May 2022 13:41:30 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <eBtTimIKT1ZsRwVd8woMwtHHRvqcWGUzBsMJVI6eACU=.ca2c9d89-1883-44e8-9765-77696c2f7542@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
 <KY5Ya0MQB_OK8SgR_rVF7iB-CWPNgWU1A44IjR40bvg=.e333e601-d7da-44d2-b008-2d2d9c26b685@github.com>
 <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com>
 <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com>
 <dgY-0m2tjBC_KNqQmiMDb4VJzrS_m5vjamdP4J1J6sk=.3620563b-0170-4e3b-8edc-ed154b5f2927@github.com>
 <eBtTimIKT1ZsRwVd8woMwtHHRvqcWGUzBsMJVI6eACU=.ca2c9d89-1883-44e8-9765-77696c2f7542@github.com>
Message-ID: <6EkEbNxPc3RKNGprHlBhqM574oY7iPI9z3PpR91IMok=.9019963f-8085-49a8-951f-f8a2b2137fb0@github.com>

On Wed, 11 May 2022 13:31:16 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Thanks for quick reaction.
>> I'll keep my eyes on this race of patches and update this pull request accordingly or create a new PR.
>
> I put out a PR for java.base, but thought I'd wait until the javac fixe were pushed before integrating and would re-enable the warnings at the same time.

Feel free to go ahead with the java.base PR as this one still needs CSR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8599

From asotona at openjdk.java.net  Wed May 11 14:45:12 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 11 May 2022 14:45:12 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v5]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <cJu_ULWgPS-KxeOlGeUXs0iYI7U7DjdxrITrg0vzoTQ=.057010a4-d66f-4df7-b982-7e0bee3519c4@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8599/files
  - new: https://git.openjdk.java.net/jdk/pull/8599/files/a59dfa4f..32282515

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=03-04

  Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From jiefu at openjdk.java.net  Thu May 12 14:00:26 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 12 May 2022 14:00:26 GMT
Subject: RFR: 8286647: JFR: Build failure when C1 or C2 is disabled after
 JDK-8282420
Message-ID: <PeDJivS_LYe30IDQDM6JfTjc7iyYQBNALAQzqF-cVYE=.7757edbe-4400-4ad7-918e-175757ee0fee@github.com>

Hi all,

JDK fails to build when c1 or c2 is disabled after JDK-8282420.
The reason is that c1/c2 code is used without `#ifdef` guards.
The fix just adds some `#ifdef`.

Testing:
 - build   on Linux/x64
 - jdk/jfr on Linux/x64

Thanks.
Best regards,
Jie

-------------

Commit messages:
 - 8286647: JFR: Build failure when C1 or C2 is disabled after JDK-8282420

Changes: https://git.openjdk.java.net/jdk/pull/8680/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8680&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286647
  Stats: 32 lines in 3 files changed: 28 ins; 4 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8680.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8680/head:pull/8680

PR: https://git.openjdk.java.net/jdk/pull/8680

From mgronlun at openjdk.java.net  Thu May 12 14:15:59 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 12 May 2022 14:15:59 GMT
Subject: RFR: 8286647: JFR: Build failure when C1 or C2 is disabled after
 JDK-8282420
In-Reply-To: <PeDJivS_LYe30IDQDM6JfTjc7iyYQBNALAQzqF-cVYE=.7757edbe-4400-4ad7-918e-175757ee0fee@github.com>
References: <PeDJivS_LYe30IDQDM6JfTjc7iyYQBNALAQzqF-cVYE=.7757edbe-4400-4ad7-918e-175757ee0fee@github.com>
Message-ID: <1cU021yvn7cX_VhLa4OhH2HmUcAMlmORSBaXMtvI9wY=.38ed9c16-10c8-4772-b4b7-735bbdc6c252@github.com>

On Thu, 12 May 2022 13:52:52 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> JDK fails to build when c1 or c2 is disabled after JDK-8282420.
> The reason is that c1/c2 code is used without `#ifdef` guards.
> The fix just adds some `#ifdef`.
> 
> Testing:
>  - build   on Linux/x64
>  - jdk/jfr on Linux/x64
> 
> Thanks.
> Best regards,
> Jie

Is it possible to use the ifdef's for only the include declarations in JfrResolution.cpp to help reduce the amount of conditionalisation? Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8680

From egahlin at openjdk.java.net  Thu May 12 14:22:33 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Thu, 12 May 2022 14:22:33 GMT
Subject: RFR: 8278262: JFR: TestPrintXML can't handle missing timestamps
Message-ID: <AZm9xDeJARg88_25ftiMe4ivCz0_pvwdxjErwXF70sY=.d8523cf6-3697-44a8-972a-412edc968c3b@github.com>

Could I have review of a test fix. The timestamp, i.e. field "until" in the Thread Park event, is converted to an Instant value before comparing it to the XML value. This doesn't work when the value is missing (Long.MIN_VALUE). 

Testing: running jdk/jdk/jfr/tool/TestPrintXML.java 300 times without failure. 

Thanks
Erik

-------------

Commit messages:
 - Initial

Changes: https://git.openjdk.java.net/jdk/pull/8681/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8681&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278262
  Stats: 7 lines in 1 file changed: 4 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8681.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8681/head:pull/8681

PR: https://git.openjdk.java.net/jdk/pull/8681

From jiefu at openjdk.java.net  Thu May 12 14:24:45 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 12 May 2022 14:24:45 GMT
Subject: RFR: 8286647: JFR: Build failure when C1 or C2 is disabled after
 JDK-8282420
In-Reply-To: <1cU021yvn7cX_VhLa4OhH2HmUcAMlmORSBaXMtvI9wY=.38ed9c16-10c8-4772-b4b7-735bbdc6c252@github.com>
References: <PeDJivS_LYe30IDQDM6JfTjc7iyYQBNALAQzqF-cVYE=.7757edbe-4400-4ad7-918e-175757ee0fee@github.com>
 <1cU021yvn7cX_VhLa4OhH2HmUcAMlmORSBaXMtvI9wY=.38ed9c16-10c8-4772-b4b7-735bbdc6c252@github.com>
Message-ID: <_3XLjJqtwLiaY2l9uSCqpSHhzWMOLh6-TcVe-tIepoY=.2ed8d35f-90fe-4dcf-ac4d-1e9b00c56de4@github.com>

On Thu, 12 May 2022 14:12:15 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Is it possible to use the ifdef's for only the include declarations in JfrResolution.cpp to help reduce the amount of conditionalisation? Thanks.

No.
Because the definition of methods would also use classes like `Parse`(C2-only) and `GraphBuilder`(C1-only).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8680

From mgronlun at openjdk.java.net  Thu May 12 14:29:50 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 12 May 2022 14:29:50 GMT
Subject: RFR: 8286647: JFR: Build failure when C1 or C2 is disabled after
 JDK-8282420
In-Reply-To: <PeDJivS_LYe30IDQDM6JfTjc7iyYQBNALAQzqF-cVYE=.7757edbe-4400-4ad7-918e-175757ee0fee@github.com>
References: <PeDJivS_LYe30IDQDM6JfTjc7iyYQBNALAQzqF-cVYE=.7757edbe-4400-4ad7-918e-175757ee0fee@github.com>
Message-ID: <Qib3lQqVAOU_leLbiotWixvvtjVD1CrOldCoLYlz3Wg=.14f3ef19-6cbd-4d46-9ecf-4f353d2c9e4d@github.com>

On Thu, 12 May 2022 13:52:52 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> JDK fails to build when c1 or c2 is disabled after JDK-8282420.
> The reason is that c1/c2 code is used without `#ifdef` guards.
> The fix just adds some `#ifdef`.
> 
> Testing:
>  - build   on Linux/x64
>  - jdk/jfr on Linux/x64
> 
> Thanks.
> Best regards,
> Jie

Ok, the function definitions in the .cpp will also have to be conditionalised. Is the rest necessary? Forward declarations are just symbolic pointers until they reach their definition.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8680

From jiefu at openjdk.java.net  Thu May 12 14:45:55 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 12 May 2022 14:45:55 GMT
Subject: RFR: 8286647: JFR: Build failure when C1 or C2 is disabled after
 JDK-8282420
In-Reply-To: <Qib3lQqVAOU_leLbiotWixvvtjVD1CrOldCoLYlz3Wg=.14f3ef19-6cbd-4d46-9ecf-4f353d2c9e4d@github.com>
References: <PeDJivS_LYe30IDQDM6JfTjc7iyYQBNALAQzqF-cVYE=.7757edbe-4400-4ad7-918e-175757ee0fee@github.com>
 <Qib3lQqVAOU_leLbiotWixvvtjVD1CrOldCoLYlz3Wg=.14f3ef19-6cbd-4d46-9ecf-4f353d2c9e4d@github.com>
Message-ID: <sv3D7xqCN10szvkHmvX3_RVF3SLe1lsiPw2EkNWs0yA=.4f63401b-f4fc-4ed5-86ed-ba24fe498ffc@github.com>

On Thu, 12 May 2022 14:25:53 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Ok, the function definitions in the .cpp will also have to be conditionalised. Is the rest necessary? Forward declarations are just symbolic pointers until they reach their definition.

At the beginning, I didn't guard the forward declarations and the build still passed on my Linux/x64.

#ifdef COMPILER1
class GraphBuilder;
#endif

#ifdef COMPILER2
class Parse;
#endif


However, I'm not sure if all the compilers would pass without the  two `#ifdef` above.
So to make it to be safe enough, I just added them.

Are you sure it's safe to remove them? 
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8680

From mgronlun at openjdk.java.net  Thu May 12 15:06:55 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 12 May 2022 15:06:55 GMT
Subject: RFR: 8286647: JFR: Build failure when C1 or C2 is disabled after
 JDK-8282420
In-Reply-To: <PeDJivS_LYe30IDQDM6JfTjc7iyYQBNALAQzqF-cVYE=.7757edbe-4400-4ad7-918e-175757ee0fee@github.com>
References: <PeDJivS_LYe30IDQDM6JfTjc7iyYQBNALAQzqF-cVYE=.7757edbe-4400-4ad7-918e-175757ee0fee@github.com>
Message-ID: <T44KHcUY4vkw3uxGI3SG8d34n3-fuJfvQTCgOrBTgDE=.de0483fb-b3b7-477d-8d88-23ed71648533@github.com>

On Thu, 12 May 2022 13:52:52 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> JDK fails to build when c1 or c2 is disabled after JDK-8282420.
> The reason is that c1/c2 code is used without `#ifdef` guards.
> The fix just adds some `#ifdef`.
> 
> Testing:
>  - build   on Linux/x64
>  - jdk/jfr on Linux/x64
> 
> Thanks.
> Best regards,
> Jie

In general, we would like to reduce the amount of conditionalization because it makes the code harder to read and follow. Compilers should not require a definition until a definition is actually needed. Perhaps there are compilers out there that don't do this, but I can't think of any right now. If that is the case, we can revisit to add in the conditionals for them.

Please try to only conditionalize in jfrResolution.cpp if you can, thank you.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8680

From mgronlun at openjdk.java.net  Thu May 12 15:07:49 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 12 May 2022 15:07:49 GMT
Subject: RFR: 8278262: JFR: TestPrintXML can't handle missing timestamps
In-Reply-To: <AZm9xDeJARg88_25ftiMe4ivCz0_pvwdxjErwXF70sY=.d8523cf6-3697-44a8-972a-412edc968c3b@github.com>
References: <AZm9xDeJARg88_25ftiMe4ivCz0_pvwdxjErwXF70sY=.d8523cf6-3697-44a8-972a-412edc968c3b@github.com>
Message-ID: <8AlxYKtGbtfaVY7oehvGlxOukUc0g4fo78ECzRxjg0c=.6c3dbb15-6055-468c-a411-8f217dbd5aa5@github.com>

On Thu, 12 May 2022 13:59:09 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of a test fix. The timestamp, i.e. field "until" in the Thread Park event, is converted to an Instant value before comparing it to the XML value. This doesn't work when the value is missing (Long.MIN_VALUE). 
> 
> Testing: running jdk/jdk/jfr/tool/TestPrintXML.java 300 times without failure. 
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8681

From egahlin at openjdk.java.net  Thu May 12 15:21:57 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Thu, 12 May 2022 15:21:57 GMT
Subject: Integrated: 8286015 JFR: Remove jfr.save.generated.asm
In-Reply-To: <w9YlPwqWB-V8CwzcGZF8ym3CvooI5y1JFJfnlmOnevo=.9414ad1e-fba4-45dc-9495-a860380c0e33@github.com>
References: <w9YlPwqWB-V8CwzcGZF8ym3CvooI5y1JFJfnlmOnevo=.9414ad1e-fba4-45dc-9495-a860380c0e33@github.com>
Message-ID: <g26tp4fGUqnU4aJhAdMXiMW9J9FQIg6Sc0Jz8H2n4bA=.e432e144-30eb-4783-b7fc-2035f115b3d9@github.com>

On Tue, 10 May 2022 17:59:58 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a fix that removes the jfr.save.generated.asm property.
> 
> It was a developer property that could be set to write generated JFR .class files to disk. The mechanism doesn't work due to a bug, but nobody has noticed it for years. For debugging JFR bytecode generation, it's much more convenient to use  -Xlog:jfr+system+bytecode=trace to print ASM to standard output. 
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 82aa0455
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/82aa04558434f60f3b308e4da164cf44120efa67
Stats:     32 lines in 3 files changed: 0 ins; 31 del; 1 mod

8286015: JFR: Remove jfr.save.generated.asm

Reviewed-by: mgronlun

-------------

PR: https://git.openjdk.java.net/jdk/pull/8637

From jiefu at openjdk.java.net  Thu May 12 15:28:53 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 12 May 2022 15:28:53 GMT
Subject: RFR: 8286647: JFR: Build failure when C1 or C2 is disabled after
 JDK-8282420 [v2]
In-Reply-To: <PeDJivS_LYe30IDQDM6JfTjc7iyYQBNALAQzqF-cVYE=.7757edbe-4400-4ad7-918e-175757ee0fee@github.com>
References: <PeDJivS_LYe30IDQDM6JfTjc7iyYQBNALAQzqF-cVYE=.7757edbe-4400-4ad7-918e-175757ee0fee@github.com>
Message-ID: <5htVLkZGk2xjogDx4WXqXtfDWpAtT1mYUnICcou8auY=.f84ed87f-ba10-441d-8f7f-d74b94789fb6@github.com>

> Hi all,
> 
> JDK fails to build when c1 or c2 is disabled after JDK-8282420.
> The reason is that c1/c2 code is used without `#ifdef` guards.
> The fix just adds some `#ifdef`.
> 
> Testing:
>  - build   on Linux/x64
>  - jdk/jfr on Linux/x64
> 
> Thanks.
> Best regards,
> Jie

Jie Fu has updated the pull request incrementally with one additional commit since the last revision:

  Revert change in src/hotspot/share/jfr/jfr.hpp

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8680/files
  - new: https://git.openjdk.java.net/jdk/pull/8680/files/99fe830b..50cc937f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8680&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8680&range=00-01

  Stats: 13 lines in 1 file changed: 1 ins; 11 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8680.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8680/head:pull/8680

PR: https://git.openjdk.java.net/jdk/pull/8680

From jiefu at openjdk.java.net  Thu May 12 15:32:48 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 12 May 2022 15:32:48 GMT
Subject: RFR: 8286647: JFR: Build failure when C1 or C2 is disabled after
 JDK-8282420
In-Reply-To: <T44KHcUY4vkw3uxGI3SG8d34n3-fuJfvQTCgOrBTgDE=.de0483fb-b3b7-477d-8d88-23ed71648533@github.com>
References: <PeDJivS_LYe30IDQDM6JfTjc7iyYQBNALAQzqF-cVYE=.7757edbe-4400-4ad7-918e-175757ee0fee@github.com>
 <T44KHcUY4vkw3uxGI3SG8d34n3-fuJfvQTCgOrBTgDE=.de0483fb-b3b7-477d-8d88-23ed71648533@github.com>
Message-ID: <SVihoz85KzBNkrtH1kJolJ4zn5cD676tET1GV4BBZG0=.026ac0c5-dab1-4c58-ba66-4046f5f7c347@github.com>

On Thu, 12 May 2022 15:03:13 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> In general, we would like to reduce the amount of conditionalization because it makes the code harder to read and follow. Compilers should not require a definition until a definition is actually needed. Perhaps there are compilers out there that don't do this, but I can't think of any right now. If that is the case, we can revisit to add in the conditionals for them.
> 
> Please try to only conditionalize in jfrResolution.cpp if you can, thank you.

OK.

I revert changes in the `jfr.hpp`.
Not sure if it's fine for all the compilers.
But as you mentioned that we can add them back if it's really a problem.

The remaining change is necessary on Linux/x64.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8680

From mgronlun at openjdk.java.net  Thu May 12 15:32:50 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 12 May 2022 15:32:50 GMT
Subject: RFR: 8286647: JFR: Build failure when C1 or C2 is disabled after
 JDK-8282420 [v2]
In-Reply-To: <5htVLkZGk2xjogDx4WXqXtfDWpAtT1mYUnICcou8auY=.f84ed87f-ba10-441d-8f7f-d74b94789fb6@github.com>
References: <PeDJivS_LYe30IDQDM6JfTjc7iyYQBNALAQzqF-cVYE=.7757edbe-4400-4ad7-918e-175757ee0fee@github.com>
 <5htVLkZGk2xjogDx4WXqXtfDWpAtT1mYUnICcou8auY=.f84ed87f-ba10-441d-8f7f-d74b94789fb6@github.com>
Message-ID: <RS1OccyK9-RhXuvd1CVjFqGUE_YQsRQ29s2HgaxOyno=.c12df793-9179-4a78-bf4a-f16802d8fdaa@github.com>

On Thu, 12 May 2022 15:28:53 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> JDK fails to build when c1 or c2 is disabled after JDK-8282420.
>> The reason is that c1/c2 code is used without `#ifdef` guards.
>> The fix just adds some `#ifdef`.
>> 
>> Testing:
>>  - build   on Linux/x64
>>  - jdk/jfr on Linux/x64
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert change in src/hotspot/share/jfr/jfr.hpp

Is the ifdef in jfr.cpp needed? There is no type-use, only the forwarding of pointers.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8680

From jiefu at openjdk.java.net  Thu May 12 15:36:49 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 12 May 2022 15:36:49 GMT
Subject: RFR: 8286647: JFR: Build failure when C1 or C2 is disabled after
 JDK-8282420 [v2]
In-Reply-To: <RS1OccyK9-RhXuvd1CVjFqGUE_YQsRQ29s2HgaxOyno=.c12df793-9179-4a78-bf4a-f16802d8fdaa@github.com>
References: <PeDJivS_LYe30IDQDM6JfTjc7iyYQBNALAQzqF-cVYE=.7757edbe-4400-4ad7-918e-175757ee0fee@github.com>
 <5htVLkZGk2xjogDx4WXqXtfDWpAtT1mYUnICcou8auY=.f84ed87f-ba10-441d-8f7f-d74b94789fb6@github.com>
 <RS1OccyK9-RhXuvd1CVjFqGUE_YQsRQ29s2HgaxOyno=.c12df793-9179-4a78-bf4a-f16802d8fdaa@github.com>
Message-ID: <n2ZeCHsBRePUi96om8pX-d3-5wWIqsmrfOgj1OpnY_M=.22170f8a-c337-491f-acb3-eccd4c9bc2b0@github.com>

On Thu, 12 May 2022 15:29:47 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Is the ifdef in jfr.cpp needed? There is no type-use, only the forwarding of pointers.

Yes.
It uses `Parse` and `GraphBuilder`. 
You can just experiment it on Linux/x64.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8680

From mgronlun at openjdk.java.net  Thu May 12 15:42:47 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 12 May 2022 15:42:47 GMT
Subject: RFR: 8286647: JFR: Build failure when C1 or C2 is disabled after
 JDK-8282420 [v2]
In-Reply-To: <5htVLkZGk2xjogDx4WXqXtfDWpAtT1mYUnICcou8auY=.f84ed87f-ba10-441d-8f7f-d74b94789fb6@github.com>
References: <PeDJivS_LYe30IDQDM6JfTjc7iyYQBNALAQzqF-cVYE=.7757edbe-4400-4ad7-918e-175757ee0fee@github.com>
 <5htVLkZGk2xjogDx4WXqXtfDWpAtT1mYUnICcou8auY=.f84ed87f-ba10-441d-8f7f-d74b94789fb6@github.com>
Message-ID: <lgb1oBai8gLK38wk-NCr9rWlzMTHtxZAgSrNxE2gLeQ=.2aadbb6d-e860-42ac-b3f5-f689fa1cf92e@github.com>

On Thu, 12 May 2022 15:28:53 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> JDK fails to build when c1 or c2 is disabled after JDK-8282420.
>> The reason is that c1/c2 code is used without `#ifdef` guards.
>> The fix just adds some `#ifdef`.
>> 
>> Testing:
>>  - build   on Linux/x64
>>  - jdk/jfr on Linux/x64
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert change in src/hotspot/share/jfr/jfr.hpp

Marked as reviewed by mgronlun (Reviewer).

Ok, I'm on Windows, and there a pointer forwarding is not considered a type-use. It may be different on Linux.

Thanks for fixing this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8680

From egahlin at openjdk.java.net  Thu May 12 18:26:54 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Thu, 12 May 2022 18:26:54 GMT
Subject: Integrated: 8278262: JFR: TestPrintXML can't handle missing timestamps
In-Reply-To: <AZm9xDeJARg88_25ftiMe4ivCz0_pvwdxjErwXF70sY=.d8523cf6-3697-44a8-972a-412edc968c3b@github.com>
References: <AZm9xDeJARg88_25ftiMe4ivCz0_pvwdxjErwXF70sY=.d8523cf6-3697-44a8-972a-412edc968c3b@github.com>
Message-ID: <qBeB0pm5upGK6mNMB8pd6OfGMxAbM0Y1F_RIWUuxYMw=.dacd6d08-2807-4e2d-9d0f-2cefea1b21cc@github.com>

On Thu, 12 May 2022 13:59:09 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of a test fix. The timestamp, i.e. field "until" in the Thread Park event, is converted to an Instant value before comparing it to the XML value. This doesn't work when the value is missing (Long.MIN_VALUE). 
> 
> Testing: running jdk/jdk/jfr/tool/TestPrintXML.java 300 times without failure. 
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 71183437
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/711834373790fe6e8df69a3309514500eb230959
Stats:     7 lines in 1 file changed: 4 ins; 0 del; 3 mod

8278262: JFR: TestPrintXML can't handle missing timestamps

Reviewed-by: mgronlun

-------------

PR: https://git.openjdk.java.net/jdk/pull/8681

From jiefu at openjdk.java.net  Thu May 12 22:52:50 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 12 May 2022 22:52:50 GMT
Subject: RFR: 8286647: JFR: Build failure when C1 or C2 is disabled after
 JDK-8282420 [v2]
In-Reply-To: <lgb1oBai8gLK38wk-NCr9rWlzMTHtxZAgSrNxE2gLeQ=.2aadbb6d-e860-42ac-b3f5-f689fa1cf92e@github.com>
References: <PeDJivS_LYe30IDQDM6JfTjc7iyYQBNALAQzqF-cVYE=.7757edbe-4400-4ad7-918e-175757ee0fee@github.com>
 <5htVLkZGk2xjogDx4WXqXtfDWpAtT1mYUnICcou8auY=.f84ed87f-ba10-441d-8f7f-d74b94789fb6@github.com>
 <lgb1oBai8gLK38wk-NCr9rWlzMTHtxZAgSrNxE2gLeQ=.2aadbb6d-e860-42ac-b3f5-f689fa1cf92e@github.com>
Message-ID: <eOwUPGz2R5kQUf18wA_TDKL-VpKxnBLx_mvUp_7NUgk=.7bc6a6c0-0289-4813-baa5-bc0c940b20c2@github.com>

On Thu, 12 May 2022 15:39:06 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert change in src/hotspot/share/jfr/jfr.hpp
>
> Ok, I'm on Windows, and there a pointer forwarding is not considered a type-use. It may be different on Linux.
> 
> Thanks for fixing this.

Thanks @mgronlun for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8680

From jiefu at openjdk.java.net  Thu May 12 22:52:50 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 12 May 2022 22:52:50 GMT
Subject: Integrated: 8286647: JFR: Build failure when C1 or C2 is disabled
 after JDK-8282420
In-Reply-To: <PeDJivS_LYe30IDQDM6JfTjc7iyYQBNALAQzqF-cVYE=.7757edbe-4400-4ad7-918e-175757ee0fee@github.com>
References: <PeDJivS_LYe30IDQDM6JfTjc7iyYQBNALAQzqF-cVYE=.7757edbe-4400-4ad7-918e-175757ee0fee@github.com>
Message-ID: <AZhnxU_bqITGX1oGfBj-zbn1Oh9YsCRk_WgBuYw6fjA=.56b0760f-0111-4ee0-ad5f-0775d01759e5@github.com>

On Thu, 12 May 2022 13:52:52 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> JDK fails to build when c1 or c2 is disabled after JDK-8282420.
> The reason is that c1/c2 code is used without `#ifdef` guards.
> The fix just adds some `#ifdef`.
> 
> Testing:
>  - build   on Linux/x64
>  - jdk/jfr on Linux/x64
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: 617ef541
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/617ef541bba58e45aa660aa30d7eb85c89ddb5b5
Stats:     18 lines in 2 files changed: 16 ins; 2 del; 0 mod

8286647: JFR: Build failure when C1 or C2 is disabled after JDK-8282420

Reviewed-by: mgronlun

-------------

PR: https://git.openjdk.java.net/jdk/pull/8680

From egahlin at openjdk.java.net  Fri May 13 06:23:03 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Fri, 13 May 2022 06:23:03 GMT
Subject: RFR: 8286668: JFR: Cleanup
Message-ID: <tU10Zpl7YnGneWGNqKFozdmnVBqKeCCvtR5NPOej8uM=.08eaad5c-b3e6-4551-bbcc-4681612feb9f@github.com>

Could I have a review of some cleanups (remove unused imports, use record classes, change to switch expressions, remove unnecessary empty lines etc).

Most changes are self-explanatory, but the AbstractEventStream class may need a comment. It's changed so it no longer takes a recording object in the constructor. This means the recording object can be kept in a private field in the subclass EventDirectoryStream, which seems more appropriate as the object is not needed in the base class and its other subclass EventFileStream. A isRecording() method is added to describe if a stream is tied to an ongoing recording or not. The field parserState is made private, but exposed to subclasses using the parserState() method.

Testing: jdk/jdk/jfr

Thanks
Erik

-------------

Commit messages:
 - Initial

Changes: https://git.openjdk.java.net/jdk/pull/8687/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8687&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286668
  Stats: 228 lines in 27 files changed: 21 ins; 103 del; 104 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8687.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8687/head:pull/8687

PR: https://git.openjdk.java.net/jdk/pull/8687

From asotona at openjdk.java.net  Fri May 13 08:32:29 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Fri, 13 May 2022 08:32:29 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v6]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <LWPvsMChniyfkaHPvxdnn1tvOwQkW9MSCwiDoJ_Fm78=.5ca8e192-b796-43d4-a621-0ac58232eae9@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - lossy conversions addressed in java.net.http, jdk.incubator.foreign, Microbenchmarks and most of java.base
   new case appeared in java.base by moving jdk.incubator.foreign code under java.base
 - Merge remote-tracking branch 'upstream/master' into JDK-8244681
   
   # Conflicts:
   #	make/test/BuildMicrobenchmark.gmk
 - enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning description
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning wording
   fixed typo in test method name
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   jdk.internal.le make patch to disable warnings
 - 8244681: Add a warning for possibly lossy conversion in compound assignments

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=05
  Stats: 444 lines in 21 files changed: 441 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From mgronlun at openjdk.java.net  Fri May 13 14:33:48 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 13 May 2022 14:33:48 GMT
Subject: RFR: 8286668: JFR: Cleanup
In-Reply-To: <tU10Zpl7YnGneWGNqKFozdmnVBqKeCCvtR5NPOej8uM=.08eaad5c-b3e6-4551-bbcc-4681612feb9f@github.com>
References: <tU10Zpl7YnGneWGNqKFozdmnVBqKeCCvtR5NPOej8uM=.08eaad5c-b3e6-4551-bbcc-4681612feb9f@github.com>
Message-ID: <ipMkPJt6Jsla-hg3X4LPQDQZMGISWXJz6a6DiT_31tQ=.3fa07fa4-9c67-4ed8-8f9a-4703ca8e5aa1@github.com>

On Thu, 12 May 2022 19:35:43 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of some cleanups (remove unused imports, use record classes, change to switch expressions, remove unnecessary empty lines etc).
> 
> Most changes are self-explanatory, but the AbstractEventStream class may need a comment. It's changed so it no longer takes a recording object in the constructor. This means the recording object can be kept in a private field in the subclass EventDirectoryStream, which seems more appropriate as the object is not needed in the base class and its other subclass EventFileStream. A isRecording() method is added to describe if a stream is tied to an ongoing recording or not. The field parserState is made private, but exposed to subclasses using the parserState() method.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8687

From egahlin at openjdk.java.net  Fri May 13 15:36:49 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Fri, 13 May 2022 15:36:49 GMT
Subject: Integrated: 8286668: JFR: Cleanup
In-Reply-To: <tU10Zpl7YnGneWGNqKFozdmnVBqKeCCvtR5NPOej8uM=.08eaad5c-b3e6-4551-bbcc-4681612feb9f@github.com>
References: <tU10Zpl7YnGneWGNqKFozdmnVBqKeCCvtR5NPOej8uM=.08eaad5c-b3e6-4551-bbcc-4681612feb9f@github.com>
Message-ID: <yK277ltLAGZh0UqPf9vXyubhrBO_5NZ5czvagoJgKMQ=.4a8afd79-8c9a-436b-89ff-ab7a6bda1be2@github.com>

On Thu, 12 May 2022 19:35:43 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of some cleanups (remove unused imports, use record classes, change to switch expressions, remove unnecessary empty lines etc).
> 
> Most changes are self-explanatory, but the AbstractEventStream class may need a comment. It's changed so it no longer takes a recording object in the constructor. This means the recording object can be kept in a private field in the subclass EventDirectoryStream, which seems more appropriate as the object is not needed in the base class and its other subclass EventFileStream. A isRecording() method is added to describe if a stream is tied to an ongoing recording or not. The field parserState is made private, but exposed to subclasses using the parserState() method.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 78ffefb8
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/78ffefb8492eb48a9bd964e7184830d4762e5adb
Stats:     228 lines in 27 files changed: 21 ins; 103 del; 104 mod

8286668: JFR: Cleanup

Reviewed-by: mgronlun

-------------

PR: https://git.openjdk.java.net/jdk/pull/8687

From aturbanov at openjdk.java.net  Sun May 15 10:31:20 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Sun, 15 May 2022 10:31:20 GMT
Subject: RFR: 8285519: Change usages of TimeUnit.convert to TimeUnit.toXXX
 [v2]
In-Reply-To: <FlO4bNdKn-onqZABzBMX1zWW2Gy-mh3xW5TJ1zzghjk=.910c3ad1-4adf-472d-9c3a-63333008a4cd@github.com>
References: <FlO4bNdKn-onqZABzBMX1zWW2Gy-mh3xW5TJ1zzghjk=.910c3ad1-4adf-472d-9c3a-63333008a4cd@github.com>
Message-ID: <-HXGIdvip8kNCtVfJk4nceMYxRjst0UkmuVkvWXEtr8=.9e0636d1-8ade-4052-8f05-a42def897bed@github.com>

> TimeUnit.toMillis/toNanos/toMicros/toSeconds is shorter and a bit faster.
> Compared via JMH benchmark: 150ns -> 125ns/op
> <details>
> <summary>Benchamark adapted from http://cr.openjdk.java.net/~shade/8152083/TimeUnitBench.java</summary>
> 
> 
> @Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
> @Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
> @Fork(1)
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class TimeUnitBench {
> 
>     static final int SIZE = TimeUnit.values().length * 10;
> 
>     @Param({"0", "1", "2", "3", "4", "5", "6", "-1"})
>     int bias;
> 
>     TimeUnit[] mod;
> 
>     @Setup
>     public void setup() {
>         mod = new TimeUnit[SIZE];
> 
>         TimeUnit[] vals = TimeUnit.values();
>         for (int c = 0; c < SIZE; c++) {
>             if (bias == -1) {
>                 // megamorphic
>                 mod[c] = vals[c % vals.length];
>             } else {
>                 mod[c] = vals[bias];
>             }
>         }
> 
>         Random r = new Random();
>         for (int c = 0; c < 10000; c++) {
>             int i = r.nextInt();
>             for (int o = 0; o < vals.length; o++) {
>                 if (vals[o].toNanos(i) != TimeUnit.NANOSECONDS.convert(i, vals[o]))
>                     throw new IllegalStateException("switch " + o);
>             }
>         }
>     }
> 
>     @Benchmark
>     public void const_convert(Blackhole bh) {
>         for (TimeUnit tu : mod) {
>             bh.consume(do_convert(tu));
>         }
>     }
> 
>     @Benchmark
>     public void value_convert(Blackhole bh) {
>         for (TimeUnit tu : mod) {
>             bh.consume(do_convert(tu, 1L));
>         }
>     }
> 
>     @Benchmark
>     public void const_toNanos(Blackhole bh) {
>         for (TimeUnit tu : mod) {
>             bh.consume(do_toNanos(tu));
>         }
>     }
> 
>     @Benchmark
>     public void value_toNanos(Blackhole bh) {
>         for (TimeUnit tu : mod) {
>             bh.consume(do_toNanos(tu, 1L));
>         }
>     }
> 
>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>     private long do_toNanos(TimeUnit tu) {
>         return tu.toNanos(1L);
>     }
> 
>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>     private long do_toNanos(TimeUnit tu, long value) {
>         return tu.toNanos(value);
>     }
> 
>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>     private long do_convert(TimeUnit tu) {
>         return TimeUnit.NANOSECONDS.convert(1L, tu);
>     }
> 
>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>     private long do_convert(TimeUnit tu, long value) {
>         return TimeUnit.NANOSECONDS.convert(value, tu);
>     }
> }
> 
> Results:
> 
> Benchmark                    (bias)  Mode  Cnt    Score    Error  Units
> TimeUnitBench.const_convert       0  avgt    5  151,856 ? 28,595  ns/op
> TimeUnitBench.const_convert       1  avgt    5  150,720 ? 23,863  ns/op
> TimeUnitBench.const_convert       2  avgt    5  151,432 ? 23,184  ns/op
> TimeUnitBench.const_convert       3  avgt    5  150,959 ? 24,726  ns/op
> TimeUnitBench.const_convert       4  avgt    5  150,966 ? 25,280  ns/op
> TimeUnitBench.const_convert       5  avgt    5  150,976 ? 25,542  ns/op
> TimeUnitBench.const_convert       6  avgt    5  151,118 ? 25,254  ns/op
> TimeUnitBench.const_convert      -1  avgt    5  152,673 ? 29,861  ns/op
> TimeUnitBench.const_toNanos       0  avgt    5  121,296 ? 25,236  ns/op
> TimeUnitBench.const_toNanos       1  avgt    5  121,707 ? 25,364  ns/op
> TimeUnitBench.const_toNanos       2  avgt    5  121,736 ? 25,726  ns/op
> TimeUnitBench.const_toNanos       3  avgt    5  121,822 ? 25,491  ns/op
> TimeUnitBench.const_toNanos       4  avgt    5  121,867 ? 26,090  ns/op
> TimeUnitBench.const_toNanos       5  avgt    5  121,927 ? 25,611  ns/op
> TimeUnitBench.const_toNanos       6  avgt    5  121,821 ? 25,843  ns/op
> TimeUnitBench.const_toNanos      -1  avgt    5  121,923 ? 25,206  ns/op
> TimeUnitBench.value_convert       0  avgt    5  150,525 ? 25,439  ns/op
> TimeUnitBench.value_convert       1  avgt    5  151,098 ? 24,024  ns/op
> TimeUnitBench.value_convert       2  avgt    5  151,259 ? 25,381  ns/op
> TimeUnitBench.value_convert       3  avgt    5  151,030 ? 25,548  ns/op
> TimeUnitBench.value_convert       4  avgt    5  151,290 ? 25,998  ns/op
> TimeUnitBench.value_convert       5  avgt    5  151,006 ? 25,448  ns/op
> TimeUnitBench.value_convert       6  avgt    5  150,945 ? 25,314  ns/op
> TimeUnitBench.value_convert      -1  avgt    5  151,186 ? 25,814  ns/op
> TimeUnitBench.value_toNanos       0  avgt    5  121,556 ? 25,745  ns/op
> TimeUnitBench.value_toNanos       1  avgt    5  123,410 ? 22,323  ns/op
> TimeUnitBench.value_toNanos       2  avgt    5  125,452 ? 26,575  ns/op
> TimeUnitBench.value_toNanos       3  avgt    5  125,297 ? 26,204  ns/op
> TimeUnitBench.value_toNanos       4  avgt    5  125,357 ? 26,085  ns/op
> TimeUnitBench.value_toNanos       5  avgt    5  125,165 ? 26,185  ns/op
> TimeUnitBench.value_toNanos       6  avgt    5  125,536 ? 25,487  ns/op
> TimeUnitBench.value_toNanos      -1  avgt    5  125,460 ? 25,063  ns/op
> 
> 
> </details>

Andrey Turbanov 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 remote-tracking branch 'origin/master' into Use_direct_TimeUnit.toSome_instead_of_TimeUnit.convert
   
   # Conflicts:
   #	src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java
   #	src/java.base/unix/classes/sun/nio/ch/PollSelectorImpl.java
 - [PATCH] Simplify TimeUnit.convert calls to TimeUnit.toSomething instead

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8376/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8376&range=01
  Stats: 24 lines in 4 files changed: 2 ins; 0 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8376.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8376/head:pull/8376

PR: https://git.openjdk.java.net/jdk/pull/8376

From dholmes at openjdk.java.net  Mon May 16 11:31:56 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 16 May 2022 11:31:56 GMT
Subject: RFR: 8280844: Epoch shift synchronization point for Compiler
 threads is inadequate
In-Reply-To: <rauLC9rAc53Jp5MPiGRcrhWLHPrfCeJjLVySTtTTunw=.3369a85b-aace-4af7-9d6d-255441ed1070@github.com>
References: <rauLC9rAc53Jp5MPiGRcrhWLHPrfCeJjLVySTtTTunw=.3369a85b-aace-4af7-9d6d-255441ed1070@github.com>
Message-ID: <mA4R5QmlWNdIcYWh8qafvetPQzJSQTbDefYOoTABBb0=.45441313-ee11-4d7a-9d98-804bed335c6d@github.com>

On Mon, 16 May 2022 10:17:42 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> [JDK-8233111](https://bugs.openjdk.java.net/browse/JDK-8233111) attempted to address artefact tagging for Compiler threads, letting threads run _thread_in_native to avoid the transition. Unfortunately, that attempt proved inadequate.
> 
> The epoch race is avoided only by performing the transition to _thread_in_vm.
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

src/hotspot/share/compiler/compilerEvent.cpp line 126:

> 124: static inline void commit(EventType& event) {
> 125:   JavaThread* thread = JavaThread::current();
> 126:   assert(thread->thread_state() == _thread_in_native, "invariant");

You don't need this assert as `ThreadInVMfromNative` already has it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8724

From mgronlun at openjdk.java.net  Mon May 16 11:37:43 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 16 May 2022 11:37:43 GMT
Subject: RFR: 8280844: Epoch shift synchronization point for Compiler
 threads is inadequate [v2]
In-Reply-To: <rauLC9rAc53Jp5MPiGRcrhWLHPrfCeJjLVySTtTTunw=.3369a85b-aace-4af7-9d6d-255441ed1070@github.com>
References: <rauLC9rAc53Jp5MPiGRcrhWLHPrfCeJjLVySTtTTunw=.3369a85b-aace-4af7-9d6d-255441ed1070@github.com>
Message-ID: <1e7AHT4Z2EMgm-mxAOrVO0kLCOkjzFpzvh-yL7KNr-I=.42f520bd-25f8-4a0d-9d89-0c238dce9ef1@github.com>

> Greetings,
> 
> [JDK-8233111](https://bugs.openjdk.java.net/browse/JDK-8233111) attempted to address artefact tagging for Compiler threads, letting threads run _thread_in_native to avoid the transition. Unfortunately, that attempt proved inadequate.
> 
> The epoch race is avoided only by performing the transition to _thread_in_vm.
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  delegate assertion

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8724/files
  - new: https://git.openjdk.java.net/jdk/pull/8724/files/9ce10130..b4e59b72

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8724&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8724&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8724.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8724/head:pull/8724

PR: https://git.openjdk.java.net/jdk/pull/8724

From egahlin at openjdk.java.net  Mon May 16 13:13:29 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Mon, 16 May 2022 13:13:29 GMT
Subject: RFR: 8286740: JFR: Active Setting event emitted incorrectly
Message-ID: <RVxlP7dpUdgIFXSA1OCK4QZIIrrxXNOivA5gDQtWBcw=.babb65f1-c550-4474-926b-089a4089676c@github.com>

Could I have a review of a fix to the Active Setting event.

- The event object is cached which leads to the event having the same timestamp
- The event is sometimes emitted twice when a recording is started
- Due to caching the event gets a duration, i.e. 0,19 ms. It should be 0 s.

-------------

Commit messages:
 - Initial

Changes: https://git.openjdk.java.net/jdk/pull/8709/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8709&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286740
  Stats: 63 lines in 7 files changed: 39 ins; 8 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8709.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8709/head:pull/8709

PR: https://git.openjdk.java.net/jdk/pull/8709

From egahlin at openjdk.java.net  Mon May 16 13:35:58 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Mon, 16 May 2022 13:35:58 GMT
Subject: RFR: 8280844: Epoch shift synchronization point for Compiler
 threads is inadequate [v2]
In-Reply-To: <1e7AHT4Z2EMgm-mxAOrVO0kLCOkjzFpzvh-yL7KNr-I=.42f520bd-25f8-4a0d-9d89-0c238dce9ef1@github.com>
References: <rauLC9rAc53Jp5MPiGRcrhWLHPrfCeJjLVySTtTTunw=.3369a85b-aace-4af7-9d6d-255441ed1070@github.com>
 <1e7AHT4Z2EMgm-mxAOrVO0kLCOkjzFpzvh-yL7KNr-I=.42f520bd-25f8-4a0d-9d89-0c238dce9ef1@github.com>
Message-ID: <tfBQfIQ4xwTWxIxJvKynkwLYIiBS_oSg9SRdZgrpZ_o=.6f8b1ae0-b1c9-4a08-89d6-2666430449df@github.com>

On Mon, 16 May 2022 11:37:43 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> [JDK-8233111](https://bugs.openjdk.java.net/browse/JDK-8233111) attempted to address artefact tagging for Compiler threads, letting threads run _thread_in_native to avoid the transition. Unfortunately, that attempt proved inadequate.
>> 
>> The epoch race is avoided only by performing the transition to _thread_in_vm.
>> 
>> Testing: jdk_jfr
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delegate assertion

Marked as reviewed by egahlin (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8724

From mgronlun at openjdk.java.net  Mon May 16 13:55:11 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 16 May 2022 13:55:11 GMT
Subject: RFR: 8283520: JFR: Memory leak in dcmd_arena
Message-ID: <mR0GZL3vloGuo6avGdF-Jeioa8nRF-edV_xyTR7fZSo=.1bc9a33b-6eab-4d3d-b9fb-1c6508ef676c@github.com>

Greetings,

This changeset will address the memory leak in the dcmd_arena.

Testing: jdk_jfr

Thanks to @shipilev for reporting this issue.

Thanks
Markus

-------------

Commit messages:
 - remove unused thread param
 - 8283520

Changes: https://git.openjdk.java.net/jdk/pull/8727/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8727&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283520
  Stats: 29 lines in 3 files changed: 23 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8727.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8727/head:pull/8727

PR: https://git.openjdk.java.net/jdk/pull/8727

From mgronlun at openjdk.java.net  Mon May 16 14:12:56 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 16 May 2022 14:12:56 GMT
Subject: RFR: 8286740: JFR: Active Setting event emitted incorrectly
In-Reply-To: <RVxlP7dpUdgIFXSA1OCK4QZIIrrxXNOivA5gDQtWBcw=.babb65f1-c550-4474-926b-089a4089676c@github.com>
References: <RVxlP7dpUdgIFXSA1OCK4QZIIrrxXNOivA5gDQtWBcw=.babb65f1-c550-4474-926b-089a4089676c@github.com>
Message-ID: <jlgekDvqGyllPqRpOywBc-9qPqm1gv1oKbvntYnVZLI=.6dfd42ce-a91a-422e-91c2-706c46adbe4d@github.com>

On Fri, 13 May 2022 22:34:03 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a fix to the Active Setting event.
> 
> - The event object is cached which leads to the event having the same timestamp
> - The event is sometimes emitted twice when a recording is started
> - Due to caching the event gets a duration, i.e. 0,19 ms. It should be 0 s.

Marked as reviewed by mgronlun (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8709

From egahlin at openjdk.java.net  Mon May 16 14:17:23 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Mon, 16 May 2022 14:17:23 GMT
Subject: RFR: 8286706: JFR: 'jfr scrub' should overwrite output
Message-ID: <siYj0cIBkSCu8U5bwigkx_mTIjg20DAUelqp87PYMvQ=.576e5093-a0b3-4e39-bc30-765b2cf06d95@github.com>

Could I have a review of a change that makes the 'jfr scrub' overwrite the output file if it already exists.

Testing: /test/jdk/jdk/jfr/tool  (Mac, Linux, Windows)

Thanks
Erik

-------------

Commit messages:
 - Initial

Changes: https://git.openjdk.java.net/jdk/pull/8728/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8728&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286706
  Stats: 35 lines in 2 files changed: 34 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8728.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8728/head:pull/8728

PR: https://git.openjdk.java.net/jdk/pull/8728

From asotona at openjdk.java.net  Mon May 16 14:45:25 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Mon, 16 May 2022 14:45:25 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v7]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <B9n9ovVUUAPav2KdXUFCOizjfBhzhONYzbossdB5IoQ=.dcca8271-3116-4026-a51a-0afa592cb3ad@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge branch 'openjdk:master' into JDK-8244681
 - lossy conversions addressed in java.net.http, jdk.incubator.foreign, Microbenchmarks and most of java.base
   new case appeared in java.base by moving jdk.incubator.foreign code under java.base
 - Merge remote-tracking branch 'upstream/master' into JDK-8244681
   
   # Conflicts:
   #	make/test/BuildMicrobenchmark.gmk
 - enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning description
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning wording
   fixed typo in test method name
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   jdk.internal.le make patch to disable warnings
 - 8244681: Add a warning for possibly lossy conversion in compound assignments

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=06
  Stats: 444 lines in 21 files changed: 441 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From asotona at openjdk.java.net  Mon May 16 14:58:33 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Mon, 16 May 2022 14:58:33 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v8]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <6fMaRe1U4N-Uz4oe8QKOqIwy-bqkQRVR75XJJpLSXgY=.c8072af3-f0e1-430e-9ab2-33db617c5d77@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  8244681: Add a warning for possibly lossy conversion in compound assignments
  re-enabled warnings for java.base, java.rmi and java.smartcardio

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8599/files
  - new: https://git.openjdk.java.net/jdk/pull/8599/files/a72644e9..74f9f4b1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=06-07

  Stats: 3 lines in 3 files changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From egahlin at openjdk.java.net  Mon May 16 19:12:35 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Mon, 16 May 2022 19:12:35 GMT
Subject: Integrated: 8286740: JFR: Active Setting event emitted incorrectly
In-Reply-To: <RVxlP7dpUdgIFXSA1OCK4QZIIrrxXNOivA5gDQtWBcw=.babb65f1-c550-4474-926b-089a4089676c@github.com>
References: <RVxlP7dpUdgIFXSA1OCK4QZIIrrxXNOivA5gDQtWBcw=.babb65f1-c550-4474-926b-089a4089676c@github.com>
Message-ID: <P5c8NyfcnT7tGbgiXSTo8UDRQp1xeRNp9amyEdpyMC0=.e798c672-42d7-4453-8bf2-3eccad24ef0f@github.com>

On Fri, 13 May 2022 22:34:03 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a fix to the Active Setting event.
> 
> - The event object is cached which leads to the event having the same timestamp
> - The event is sometimes emitted twice when a recording is started
> - Due to caching the event gets a duration, i.e. 0,19 ms. It should be 0 s.

This pull request has now been integrated.

Changeset: 24cab0af
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/24cab0af32a1eaa4c594fb2a144386a6b7062981
Stats:     63 lines in 7 files changed: 39 ins; 8 del; 16 mod

8286740: JFR: Active Setting event emitted incorrectly

Reviewed-by: mgronlun

-------------

PR: https://git.openjdk.java.net/jdk/pull/8709

From egahlin at openjdk.java.net  Tue May 17 00:41:06 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Tue, 17 May 2022 00:41:06 GMT
Subject: RFR: 8286688: JFR: Active Setting events should have the same
 timestamp
Message-ID: <vwXBTRQG4JUmjcEZIfqjQPTwpiw1WsBDD0oeGaVVsyU=.d15963be-e0b1-480e-91ee-6a2b80a582c2@github.com>

Could I have a review of a change that ensures that all Active Setting events emitted together get the same timestamp.

Testing: jdk/jdk/jfr + 100 times TestActiveSettingEvent.java

Thanks
Erik

-------------

Commit messages:
 - Initial

Changes: https://git.openjdk.java.net/jdk/pull/8738/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8738&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286688
  Stats: 41 lines in 6 files changed: 30 ins; 2 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8738.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8738/head:pull/8738

PR: https://git.openjdk.java.net/jdk/pull/8738

From mgronlun at openjdk.java.net  Tue May 17 06:00:31 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 17 May 2022 06:00:31 GMT
Subject: RFR: 8283520: JFR: Memory leak in dcmd_arena [v2]
In-Reply-To: <mR0GZL3vloGuo6avGdF-Jeioa8nRF-edV_xyTR7fZSo=.1bc9a33b-6eab-4d3d-b9fb-1c6508ef676c@github.com>
References: <mR0GZL3vloGuo6avGdF-Jeioa8nRF-edV_xyTR7fZSo=.1bc9a33b-6eab-4d3d-b9fb-1c6508ef676c@github.com>
Message-ID: <TMWF3pBVj_pGEf40qIwcp6G-UDrEF-tZdV7_LKNlAl8=.e4d84112-166d-4046-828c-3b8d80b5a234@github.com>

> Greetings,
> 
> This changeset will address the memory leak in the dcmd_arena.
> 
> Testing: jdk_jfr
> 
> Thanks to @shipilev for reporting this issue.
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  hw thread is one-to-many javathreads

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8727/files
  - new: https://git.openjdk.java.net/jdk/pull/8727/files/0b233f39..c7a34d5d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8727&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8727&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8727.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8727/head:pull/8727

PR: https://git.openjdk.java.net/jdk/pull/8727

From aturbanov at openjdk.java.net  Tue May 17 13:21:48 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Tue, 17 May 2022 13:21:48 GMT
Subject: RFR: 8280035: Use Class.isInstance instead of
 Class.isAssignableFrom where applicable [v2]
In-Reply-To: <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
References: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
 <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
Message-ID: <bdyMScRIzJTzmKnpU9Bdu7Qe7gv9r1te5Yw6yVYsk4o=.ab88908e-33aa-4efe-8d80-3ad8cda92483@github.com>

On Thu, 31 Mar 2022 08:03:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Method `Class.isAssignableFrom` is often used in form of:
>> 
>>     if (clazz.isAssignableFrom(obj.getClass())) {
>> Such condition could be simplified to more shorter and performarnt code
>> 
>>     if (clazz.isInstance(obj)) {
>>     
>> Replacement is equivalent if it's known that `obj != null`.
>> In JDK codebase there are many such places.
>> 
>> I tried to measure performance via JMH
>> 
>>     Class<?> integerClass = Integer.class;
>>     Class<?> numberClass = Number.class;
>> 
>>     Object integerObject = 45666;
>>     Object doubleObject = 8777d;
>> 
>>     @Benchmark
>>     public boolean integerInteger_isInstance() {
>>         return integerClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerInteger_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isInstance() {
>>         return integerClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isInstance() {
>>         return numberClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isInstance() {
>>         return numberClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public void numberIntegerDouble_isInstance(Blackhole bh) {
>>         bh.consume(numberClass.isInstance(integerObject));
>>         bh.consume(numberClass.isInstance(doubleObject));
>>     }
>> 
>>     @Benchmark
>>     public void integerIntegerDouble_isAssignableFrom(Blackhole bh) {
>>         bh.consume(integerClass.isAssignableFrom(integerObject.getClass()));
>>         bh.consume(integerClass.isAssignableFrom(doubleObject.getClass()));
>>     }
>> 
>> `isInstance` is a bit faster than `isAssignableFrom`
>> 
>> Benchmark                              Mode  Cnt  Score   Error  Units
>> integerDouble_isAssignableFrom         avgt    5  1,173 ? 0,026  ns/op
>> integerDouble_isInstance               avgt    5  0,939 ? 0,038  ns/op
>> integerIntegerDouble_isAssignableFrom  avgt    5  2,106 ? 0,068  ns/op
>> numberIntegerDouble_isInstance         avgt    5  1,516 ? 0,046  ns/op
>> integerInteger_isAssignableFrom        avgt    5  1,175 ? 0,029  ns/op
>> integerInteger_isInstance              avgt    5  0,886 ? 0,017  ns/op
>> numberDouble_isAssignableFrom          avgt    5  1,172 ? 0,007  ns/op
>> numberDouble_isInstance                avgt    5  0,891 ? 0,030  ns/op
>> numberInteger_isAssignableFrom         avgt    5  1,169 ? 0,014  ns/op
>> numberInteger_isInstance               avgt    5  0,887 ? 0,016  ns/op
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable
>   apply suggestion to avoid second Method.invoke call

Any more reviewers, please?)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7061

From mgronlun at openjdk.java.net  Tue May 17 19:20:48 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 17 May 2022 19:20:48 GMT
Subject: RFR: 8286688: JFR: Active Setting events should have the same
 timestamp
In-Reply-To: <vwXBTRQG4JUmjcEZIfqjQPTwpiw1WsBDD0oeGaVVsyU=.d15963be-e0b1-480e-91ee-6a2b80a582c2@github.com>
References: <vwXBTRQG4JUmjcEZIfqjQPTwpiw1WsBDD0oeGaVVsyU=.d15963be-e0b1-480e-91ee-6a2b80a582c2@github.com>
Message-ID: <qz3erRnHYi8CN-anSTm8FyRNNhNCV3YV_ljfiQn8gEI=.1b893255-e8ff-4982-b7dd-3eeb4c5663bf@github.com>

On Tue, 17 May 2022 00:13:44 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a change that ensures that all Active Setting events emitted together get the same timestamp.
> 
> Testing: jdk/jdk/jfr + 100 times TestActiveSettingEvent.java
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8738

From egahlin at openjdk.java.net  Tue May 17 20:09:56 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Tue, 17 May 2022 20:09:56 GMT
Subject: RFR: 8283520: JFR: Memory leak in dcmd_arena [v2]
In-Reply-To: <TMWF3pBVj_pGEf40qIwcp6G-UDrEF-tZdV7_LKNlAl8=.e4d84112-166d-4046-828c-3b8d80b5a234@github.com>
References: <mR0GZL3vloGuo6avGdF-Jeioa8nRF-edV_xyTR7fZSo=.1bc9a33b-6eab-4d3d-b9fb-1c6508ef676c@github.com>
 <TMWF3pBVj_pGEf40qIwcp6G-UDrEF-tZdV7_LKNlAl8=.e4d84112-166d-4046-828c-3b8d80b5a234@github.com>
Message-ID: <qj5KWEVwdgtMAPsAQoSwNtmbacV3T9VUNYjegf47OnU=.f078e557-384c-471e-b233-3baa02991886@github.com>

On Tue, 17 May 2022 06:00:31 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This changeset will address the memory leak in the dcmd_arena.
>> 
>> Testing: jdk_jfr
>> 
>> Thanks to @shipilev for reporting this issue.
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   hw thread is one-to-many javathreads

Marked as reviewed by egahlin (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8727

From egahlin at openjdk.java.net  Tue May 17 20:27:40 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Tue, 17 May 2022 20:27:40 GMT
Subject: Integrated: 8286688: JFR: Active Setting events should have the same
 timestamp
In-Reply-To: <vwXBTRQG4JUmjcEZIfqjQPTwpiw1WsBDD0oeGaVVsyU=.d15963be-e0b1-480e-91ee-6a2b80a582c2@github.com>
References: <vwXBTRQG4JUmjcEZIfqjQPTwpiw1WsBDD0oeGaVVsyU=.d15963be-e0b1-480e-91ee-6a2b80a582c2@github.com>
Message-ID: <F4QEIdUirZd1hTO5YY6GZD4Z67V0GxUJnzQnNx_OhNY=.7d21910d-8beb-488b-8fce-e55b03be3809@github.com>

On Tue, 17 May 2022 00:13:44 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a change that ensures that all Active Setting events emitted together get the same timestamp.
> 
> Testing: jdk/jdk/jfr + 100 times TestActiveSettingEvent.java
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: a25b9bc8
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a25b9bc89b5899a55db5a2334bc837c021960424
Stats:     41 lines in 6 files changed: 30 ins; 2 del; 9 mod

8286688: JFR: Active Setting events should have the same timestamp

Reviewed-by: mgronlun

-------------

PR: https://git.openjdk.java.net/jdk/pull/8738

From egahlin at openjdk.java.net  Tue May 17 22:20:40 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Tue, 17 May 2022 22:20:40 GMT
Subject: RFR: 8286706: JFR: 'jfr scrub' should overwrite output [v2]
In-Reply-To: <siYj0cIBkSCu8U5bwigkx_mTIjg20DAUelqp87PYMvQ=.576e5093-a0b3-4e39-bc30-765b2cf06d95@github.com>
References: <siYj0cIBkSCu8U5bwigkx_mTIjg20DAUelqp87PYMvQ=.576e5093-a0b3-4e39-bc30-765b2cf06d95@github.com>
Message-ID: <xQ60kxzi1CxlyBPQz9G2XFWfrU51Ua7TPXHq-B3BeFQ=.f0f33989-8ae1-4748-a8ee-66505165d610@github.com>

> Could I have a review of a change that makes the 'jfr scrub' overwrite the output file if it already exists.
> 
> Testing: /test/jdk/jdk/jfr/tool  (Mac, Linux, Windows)
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Rename method

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8728/files
  - new: https://git.openjdk.java.net/jdk/pull/8728/files/2cfef0ff..89a3b975

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8728&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8728&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8728.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8728/head:pull/8728

PR: https://git.openjdk.java.net/jdk/pull/8728

From mgronlun at openjdk.java.net  Tue May 17 22:29:45 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 17 May 2022 22:29:45 GMT
Subject: RFR: 8286706: JFR: 'jfr scrub' should overwrite output [v2]
In-Reply-To: <xQ60kxzi1CxlyBPQz9G2XFWfrU51Ua7TPXHq-B3BeFQ=.f0f33989-8ae1-4748-a8ee-66505165d610@github.com>
References: <siYj0cIBkSCu8U5bwigkx_mTIjg20DAUelqp87PYMvQ=.576e5093-a0b3-4e39-bc30-765b2cf06d95@github.com>
 <xQ60kxzi1CxlyBPQz9G2XFWfrU51Ua7TPXHq-B3BeFQ=.f0f33989-8ae1-4748-a8ee-66505165d610@github.com>
Message-ID: <XpdTomBEw5qK0WCchZwKwOrieCaJLbNh2XwtbtJdlWQ=.d51cb2de-21b7-487a-b213-9580b5707803@github.com>

On Tue, 17 May 2022 22:20:40 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have a review of a change that makes the 'jfr scrub' overwrite the output file if it already exists.
>> 
>> Testing: /test/jdk/jdk/jfr/tool  (Mac, Linux, Windows)
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename method

Marked as reviewed by mgronlun (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8728

From egahlin at openjdk.java.net  Wed May 18 04:47:53 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 18 May 2022 04:47:53 GMT
Subject: Integrated: 8286706: JFR: 'jfr scrub' should overwrite output
In-Reply-To: <siYj0cIBkSCu8U5bwigkx_mTIjg20DAUelqp87PYMvQ=.576e5093-a0b3-4e39-bc30-765b2cf06d95@github.com>
References: <siYj0cIBkSCu8U5bwigkx_mTIjg20DAUelqp87PYMvQ=.576e5093-a0b3-4e39-bc30-765b2cf06d95@github.com>
Message-ID: <LWIWBlvDt0mRb-XjN8T-FtCroqz9JShWwxoi3ZjKFgs=.75620d02-905d-407f-b4d3-ccc40b0bce35@github.com>

On Mon, 16 May 2022 14:04:43 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a change that makes the 'jfr scrub' overwrite the output file if it already exists.
> 
> Testing: /test/jdk/jdk/jfr/tool  (Mac, Linux, Windows)
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: ab144190
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ab144190c9951f2a9a3acf30db4b570484d5f751
Stats:     35 lines in 2 files changed: 34 ins; 0 del; 1 mod

8286706: JFR: 'jfr scrub' should overwrite output

Reviewed-by: mgronlun

-------------

PR: https://git.openjdk.java.net/jdk/pull/8728

From mgronlun at openjdk.java.net  Wed May 18 09:09:52 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 18 May 2022 09:09:52 GMT
Subject: Integrated: 8280844: Epoch shift synchronization point for Compiler
 threads is inadequate
In-Reply-To: <rauLC9rAc53Jp5MPiGRcrhWLHPrfCeJjLVySTtTTunw=.3369a85b-aace-4af7-9d6d-255441ed1070@github.com>
References: <rauLC9rAc53Jp5MPiGRcrhWLHPrfCeJjLVySTtTTunw=.3369a85b-aace-4af7-9d6d-255441ed1070@github.com>
Message-ID: <JJ0bHSeBpifGCKthfyQ4S9oDRE1WGNj_ivviDPa1M-8=.56b828a3-da89-4821-b132-0bdf1e7de9a5@github.com>

On Mon, 16 May 2022 10:17:42 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> [JDK-8233111](https://bugs.openjdk.java.net/browse/JDK-8233111) attempted to address artefact tagging for Compiler threads, letting threads run _thread_in_native to avoid the transition. Unfortunately, that attempt proved inadequate.
> 
> The epoch race is avoided only by performing the transition to _thread_in_vm.
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

This pull request has now been integrated.

Changeset: d936c302
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d936c3024acf428df6d1fb3064a1d8aa5038d277
Stats:     100 lines in 6 files changed: 12 ins; 84 del; 4 mod

8280844: Epoch shift synchronization point for Compiler threads is inadequate

Reviewed-by: egahlin

-------------

PR: https://git.openjdk.java.net/jdk/pull/8724

From mgronlun at openjdk.java.net  Wed May 18 09:11:58 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 18 May 2022 09:11:58 GMT
Subject: Integrated: 8283520: JFR: Memory leak in dcmd_arena
In-Reply-To: <mR0GZL3vloGuo6avGdF-Jeioa8nRF-edV_xyTR7fZSo=.1bc9a33b-6eab-4d3d-b9fb-1c6508ef676c@github.com>
References: <mR0GZL3vloGuo6avGdF-Jeioa8nRF-edV_xyTR7fZSo=.1bc9a33b-6eab-4d3d-b9fb-1c6508ef676c@github.com>
Message-ID: <4QautkV45VjpBJiE27dB2Ezti0zoePMyJZMUtHyQK-U=.f5b89321-3423-43a4-9d43-25487faab677@github.com>

On Mon, 16 May 2022 13:47:53 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> This changeset will address the memory leak in the dcmd_arena.
> 
> Testing: jdk_jfr
> 
> Thanks to @shipilev for reporting this issue.
> 
> Thanks
> Markus

This pull request has now been integrated.

Changeset: 6a8be358
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6a8be358d2af34fab8798077202b998badaa5d54
Stats:     32 lines in 3 files changed: 23 ins; 2 del; 7 mod

8283520: JFR: Memory leak in dcmd_arena

Reviewed-by: egahlin

-------------

PR: https://git.openjdk.java.net/jdk/pull/8727

From egahlin at openjdk.java.net  Wed May 18 12:43:17 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 18 May 2022 12:43:17 GMT
Subject: RFR: 8286925: Move JSON parser used in JFR tests to test library
Message-ID: <MfU2pkOiowBpfdID6jO7Y-dwpJO2AcLnjT0DltIqaNc=.aa69420f-498d-490c-97f3-bc49df65d9eb@github.com>

Could I have a review of a change that moves the JSON parser used in JFR tests to the test library so it can be used by other tests.

Testing: test/jdk/jdk/jfr/tool

Thanks
Erik Gahlin

-------------

Commit messages:
 - Initial

Changes: https://git.openjdk.java.net/jdk/pull/8763/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8763&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286925
  Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8763.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8763/head:pull/8763

PR: https://git.openjdk.java.net/jdk/pull/8763

From mgronlun at openjdk.java.net  Wed May 18 13:01:55 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 18 May 2022 13:01:55 GMT
Subject: RFR: 8286925: Move JSON parser used in JFR tests to test library
In-Reply-To: <MfU2pkOiowBpfdID6jO7Y-dwpJO2AcLnjT0DltIqaNc=.aa69420f-498d-490c-97f3-bc49df65d9eb@github.com>
References: <MfU2pkOiowBpfdID6jO7Y-dwpJO2AcLnjT0DltIqaNc=.aa69420f-498d-490c-97f3-bc49df65d9eb@github.com>
Message-ID: <x_Z_MOuD0JkYmcN4Trc4nKilSgJtmGeAhIdZBYuVnM4=.51774552-8347-496b-9d7d-6bb03e61d312@github.com>

On Wed, 18 May 2022 10:37:10 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a change that moves the JSON parser used in JFR tests to the test library so it can be used by other tests.
> 
> Testing: test/jdk/jdk/jfr/tool
> 
> Thanks
> Erik Gahlin

Marked as reviewed by mgronlun (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8763

From alanb at openjdk.java.net  Wed May 18 13:27:49 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 18 May 2022 13:27:49 GMT
Subject: RFR: 8286925: Move JSON parser used in JFR tests to test library
In-Reply-To: <MfU2pkOiowBpfdID6jO7Y-dwpJO2AcLnjT0DltIqaNc=.aa69420f-498d-490c-97f3-bc49df65d9eb@github.com>
References: <MfU2pkOiowBpfdID6jO7Y-dwpJO2AcLnjT0DltIqaNc=.aa69420f-498d-490c-97f3-bc49df65d9eb@github.com>
Message-ID: <hZzpDW72ooW-1diIizafi1AJKtlGpas3_jlTPz64RYY=.466c83d3-97f2-469f-a7e2-7e9bac22aec1@github.com>

On Wed, 18 May 2022 10:37:10 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a change that moves the JSON parser used in JFR tests to the test library so it can be used by other tests.
> 
> Testing: test/jdk/jdk/jfr/tool
> 
> Thanks
> Erik Gahlin

Thanks for this.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8763

From egahlin at openjdk.java.net  Wed May 18 15:11:57 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 18 May 2022 15:11:57 GMT
Subject: Integrated: 8286925: Move JSON parser used in JFR tests to test
 library
In-Reply-To: <MfU2pkOiowBpfdID6jO7Y-dwpJO2AcLnjT0DltIqaNc=.aa69420f-498d-490c-97f3-bc49df65d9eb@github.com>
References: <MfU2pkOiowBpfdID6jO7Y-dwpJO2AcLnjT0DltIqaNc=.aa69420f-498d-490c-97f3-bc49df65d9eb@github.com>
Message-ID: <Hsffc9a30ZEzDNOxicIvh437tl1Q6rDSJ-twjv0EiK4=.8061ff40-6971-4aee-819c-aa95a9010c3e@github.com>

On Wed, 18 May 2022 10:37:10 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a change that moves the JSON parser used in JFR tests to the test library so it can be used by other tests.
> 
> Testing: test/jdk/jdk/jfr/tool
> 
> Thanks
> Erik Gahlin

This pull request has now been integrated.

Changeset: ac7e0192
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ac7e019232903db38a03f644c3d31c858cbf3967
Stats:     4 lines in 2 files changed: 1 ins; 0 del; 3 mod

8286925: Move JSON parser used in JFR tests to test library

Reviewed-by: mgronlun, alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/8763

From rriggs at openjdk.java.net  Thu May 19 20:59:01 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 19 May 2022 20:59:01 GMT
Subject: RFR: 8280035: Use Class.isInstance instead of
 Class.isAssignableFrom where applicable [v2]
In-Reply-To: <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
References: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
 <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
Message-ID: <jbBaODyPtTd8-tuH-COiI2ThXfoKUWG-KPHV-il4ohQ=.0fc3bc38-0236-4244-8094-1dab9a2ba505@github.com>

On Thu, 31 Mar 2022 08:03:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Method `Class.isAssignableFrom` is often used in form of:
>> 
>>     if (clazz.isAssignableFrom(obj.getClass())) {
>> Such condition could be simplified to more shorter and performarnt code
>> 
>>     if (clazz.isInstance(obj)) {
>>     
>> Replacement is equivalent if it's known that `obj != null`.
>> In JDK codebase there are many such places.
>> 
>> I tried to measure performance via JMH
>> 
>>     Class<?> integerClass = Integer.class;
>>     Class<?> numberClass = Number.class;
>> 
>>     Object integerObject = 45666;
>>     Object doubleObject = 8777d;
>> 
>>     @Benchmark
>>     public boolean integerInteger_isInstance() {
>>         return integerClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerInteger_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isInstance() {
>>         return integerClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isInstance() {
>>         return numberClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isInstance() {
>>         return numberClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public void numberIntegerDouble_isInstance(Blackhole bh) {
>>         bh.consume(numberClass.isInstance(integerObject));
>>         bh.consume(numberClass.isInstance(doubleObject));
>>     }
>> 
>>     @Benchmark
>>     public void integerIntegerDouble_isAssignableFrom(Blackhole bh) {
>>         bh.consume(integerClass.isAssignableFrom(integerObject.getClass()));
>>         bh.consume(integerClass.isAssignableFrom(doubleObject.getClass()));
>>     }
>> 
>> `isInstance` is a bit faster than `isAssignableFrom`
>> 
>> Benchmark                              Mode  Cnt  Score   Error  Units
>> integerDouble_isAssignableFrom         avgt    5  1,173 ? 0,026  ns/op
>> integerDouble_isInstance               avgt    5  0,939 ? 0,038  ns/op
>> integerIntegerDouble_isAssignableFrom  avgt    5  2,106 ? 0,068  ns/op
>> numberIntegerDouble_isInstance         avgt    5  1,516 ? 0,046  ns/op
>> integerInteger_isAssignableFrom        avgt    5  1,175 ? 0,029  ns/op
>> integerInteger_isInstance              avgt    5  0,886 ? 0,017  ns/op
>> numberDouble_isAssignableFrom          avgt    5  1,172 ? 0,007  ns/op
>> numberDouble_isInstance                avgt    5  0,891 ? 0,030  ns/op
>> numberInteger_isAssignableFrom         avgt    5  1,169 ? 0,014  ns/op
>> numberInteger_isInstance               avgt    5  0,887 ? 0,016  ns/op
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable
>   apply suggestion to avoid second Method.invoke call

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7061

From aturbanov at openjdk.java.net  Thu May 19 21:23:45 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Thu, 19 May 2022 21:23:45 GMT
Subject: RFR: 8280035: Use Class.isInstance instead of
 Class.isAssignableFrom where applicable [v2]
In-Reply-To: <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
References: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
 <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
Message-ID: <vSSWEeLopB9OfgPnj3bMmrcDoWqUaXU1Vx4Ob-Sr2e4=.00db113f-cfe6-41a7-b227-fbd8bb96819f@github.com>

On Thu, 31 Mar 2022 08:03:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Method `Class.isAssignableFrom` is often used in form of:
>> 
>>     if (clazz.isAssignableFrom(obj.getClass())) {
>> Such condition could be simplified to more shorter and performarnt code
>> 
>>     if (clazz.isInstance(obj)) {
>>     
>> Replacement is equivalent if it's known that `obj != null`.
>> In JDK codebase there are many such places.
>> 
>> I tried to measure performance via JMH
>> 
>>     Class<?> integerClass = Integer.class;
>>     Class<?> numberClass = Number.class;
>> 
>>     Object integerObject = 45666;
>>     Object doubleObject = 8777d;
>> 
>>     @Benchmark
>>     public boolean integerInteger_isInstance() {
>>         return integerClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerInteger_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isInstance() {
>>         return integerClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isInstance() {
>>         return numberClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isInstance() {
>>         return numberClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public void numberIntegerDouble_isInstance(Blackhole bh) {
>>         bh.consume(numberClass.isInstance(integerObject));
>>         bh.consume(numberClass.isInstance(doubleObject));
>>     }
>> 
>>     @Benchmark
>>     public void integerIntegerDouble_isAssignableFrom(Blackhole bh) {
>>         bh.consume(integerClass.isAssignableFrom(integerObject.getClass()));
>>         bh.consume(integerClass.isAssignableFrom(doubleObject.getClass()));
>>     }
>> 
>> `isInstance` is a bit faster than `isAssignableFrom`
>> 
>> Benchmark                              Mode  Cnt  Score   Error  Units
>> integerDouble_isAssignableFrom         avgt    5  1,173 ? 0,026  ns/op
>> integerDouble_isInstance               avgt    5  0,939 ? 0,038  ns/op
>> integerIntegerDouble_isAssignableFrom  avgt    5  2,106 ? 0,068  ns/op
>> numberIntegerDouble_isInstance         avgt    5  1,516 ? 0,046  ns/op
>> integerInteger_isAssignableFrom        avgt    5  1,175 ? 0,029  ns/op
>> integerInteger_isInstance              avgt    5  0,886 ? 0,017  ns/op
>> numberDouble_isAssignableFrom          avgt    5  1,172 ? 0,007  ns/op
>> numberDouble_isInstance                avgt    5  0,891 ? 0,030  ns/op
>> numberInteger_isAssignableFrom         avgt    5  1,169 ? 0,014  ns/op
>> numberInteger_isInstance               avgt    5  0,887 ? 0,016  ns/op
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable
>   apply suggestion to avoid second Method.invoke call

Thank you for review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7061

From aturbanov at openjdk.java.net  Thu May 19 21:46:09 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Thu, 19 May 2022 21:46:09 GMT
Subject: Integrated: 8280035: Use Class.isInstance instead of
 Class.isAssignableFrom where applicable
In-Reply-To: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
References: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
Message-ID: <m5Mlh_GXpRbgYU6ZFCOd4XxqZaSy9yYVTOz5Mnnr69I=.4c5baad6-401b-41b0-af78-60b6a3e417a8@github.com>

On Thu, 13 Jan 2022 08:25:22 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Method `Class.isAssignableFrom` is often used in form of:
> 
>     if (clazz.isAssignableFrom(obj.getClass())) {
> Such condition could be simplified to more shorter and performarnt code
> 
>     if (clazz.isInstance(obj)) {
>     
> Replacement is equivalent if it's known that `obj != null`.
> In JDK codebase there are many such places.
> 
> I tried to measure performance via JMH
> 
>     Class<?> integerClass = Integer.class;
>     Class<?> numberClass = Number.class;
> 
>     Object integerObject = 45666;
>     Object doubleObject = 8777d;
> 
>     @Benchmark
>     public boolean integerInteger_isInstance() {
>         return integerClass.isInstance(integerObject);
>     }
> 
>     @Benchmark
>     public boolean integerInteger_isAssignableFrom() {
>         return integerClass.isAssignableFrom(integerObject.getClass());
>     }
> 
>     @Benchmark
>     public boolean integerDouble_isInstance() {
>         return integerClass.isInstance(doubleObject);
>     }
> 
>     @Benchmark
>     public boolean integerDouble_isAssignableFrom() {
>         return integerClass.isAssignableFrom(doubleObject.getClass());
>     }
> 
>     @Benchmark
>     public boolean numberDouble_isInstance() {
>         return numberClass.isInstance(doubleObject);
>     }
> 
>     @Benchmark
>     public boolean numberDouble_isAssignableFrom() {
>         return numberClass.isAssignableFrom(doubleObject.getClass());
>     }
> 
>     @Benchmark
>     public boolean numberInteger_isInstance() {
>         return numberClass.isInstance(integerObject);
>     }
> 
>     @Benchmark
>     public boolean numberInteger_isAssignableFrom() {
>         return numberClass.isAssignableFrom(integerObject.getClass());
>     }
> 
>     @Benchmark
>     public void numberIntegerDouble_isInstance(Blackhole bh) {
>         bh.consume(numberClass.isInstance(integerObject));
>         bh.consume(numberClass.isInstance(doubleObject));
>     }
> 
>     @Benchmark
>     public void integerIntegerDouble_isAssignableFrom(Blackhole bh) {
>         bh.consume(integerClass.isAssignableFrom(integerObject.getClass()));
>         bh.consume(integerClass.isAssignableFrom(doubleObject.getClass()));
>     }
> 
> `isInstance` is a bit faster than `isAssignableFrom`
> 
> Benchmark                              Mode  Cnt  Score   Error  Units
> integerDouble_isAssignableFrom         avgt    5  1,173 ? 0,026  ns/op
> integerDouble_isInstance               avgt    5  0,939 ? 0,038  ns/op
> integerIntegerDouble_isAssignableFrom  avgt    5  2,106 ? 0,068  ns/op
> numberIntegerDouble_isInstance         avgt    5  1,516 ? 0,046  ns/op
> integerInteger_isAssignableFrom        avgt    5  1,175 ? 0,029  ns/op
> integerInteger_isInstance              avgt    5  0,886 ? 0,017  ns/op
> numberDouble_isAssignableFrom          avgt    5  1,172 ? 0,007  ns/op
> numberDouble_isInstance                avgt    5  0,891 ? 0,030  ns/op
> numberInteger_isAssignableFrom         avgt    5  1,169 ? 0,014  ns/op
> numberInteger_isInstance               avgt    5  0,887 ? 0,016  ns/op

This pull request has now been integrated.

Changeset: de74e0e2
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/de74e0e25a195084745891419f0c4a8ad286560c
Stats:     25 lines in 10 files changed: 0 ins; 3 del; 22 mod

8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable

Reviewed-by: prr, rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/7061

From egahlin at openjdk.java.net  Fri May 20 14:07:19 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Fri, 20 May 2022 14:07:19 GMT
Subject: RFR: 8285513: JFR: Add more static support for event classes
Message-ID: <Qymhpooepst9M0DMklo8cjjFevGRycsSIjAeHwHXjq8=.b98c3eef-e112-47a3-a98f-083bc1cb8923@github.com>

Could I have a review that allows code in java.base, which can't have a compile-time dependency on jdk.jfr, to check if an event can be committed without using an event object. See issue for details.

Testing: 
- jdk/jdk/jfr
- tier1 + tier2
- Tested to implement ThreadSleep event using a static commit method (not part of this changeset)

-------------

Commit messages:
 - Initial

Changes: https://git.openjdk.java.net/jdk/pull/8810/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8810&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285513
  Stats: 88 lines in 1 file changed: 72 ins; 14 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8810.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8810/head:pull/8810

PR: https://git.openjdk.java.net/jdk/pull/8810

From egahlin at openjdk.java.net  Fri May 20 15:05:02 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Fri, 20 May 2022 15:05:02 GMT
Subject: RFR: 8285513: JFR: Add more static support for event classes [v2]
In-Reply-To: <Qymhpooepst9M0DMklo8cjjFevGRycsSIjAeHwHXjq8=.b98c3eef-e112-47a3-a98f-083bc1cb8923@github.com>
References: <Qymhpooepst9M0DMklo8cjjFevGRycsSIjAeHwHXjq8=.b98c3eef-e112-47a3-a98f-083bc1cb8923@github.com>
Message-ID: <D-14UlehFYwsMRNLLVPQF1RN1OWBi3V_UVMrhyCXE4g=.d8c4b846-04b2-4009-aa71-d5f81bcaaa68@github.com>

> Could I have a review that allows code in java.base, which can't have a compile-time dependency on jdk.jfr, to check if an event can be committed without using an event object. See issue for details.
> 
> Testing: 
> - jdk/jdk/jfr
> - tier1 + tier2
> - Tested to implement ThreadSleep event using a static commit method (not part of this changeset)

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Fix typos, method and field names

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8810/files
  - new: https://git.openjdk.java.net/jdk/pull/8810/files/b853d559..1e2bfeae

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8810&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8810&range=00-01

  Stats: 13 lines in 1 file changed: 0 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8810.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8810/head:pull/8810

PR: https://git.openjdk.java.net/jdk/pull/8810

From mgronlun at openjdk.java.net  Fri May 20 16:04:09 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 20 May 2022 16:04:09 GMT
Subject: RFR: 8285513: JFR: Add more static support for event classes [v2]
In-Reply-To: <D-14UlehFYwsMRNLLVPQF1RN1OWBi3V_UVMrhyCXE4g=.d8c4b846-04b2-4009-aa71-d5f81bcaaa68@github.com>
References: <Qymhpooepst9M0DMklo8cjjFevGRycsSIjAeHwHXjq8=.b98c3eef-e112-47a3-a98f-083bc1cb8923@github.com>
 <D-14UlehFYwsMRNLLVPQF1RN1OWBi3V_UVMrhyCXE4g=.d8c4b846-04b2-4009-aa71-d5f81bcaaa68@github.com>
Message-ID: <e6muUpdr7LWITX2CA4KVayxXx-wh6QUQILN5yt0tiYw=.a19e7da2-c9ed-4203-b48f-7f2e8f9a5629@github.com>

On Fri, 20 May 2022 15:05:02 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have a review that allows code in java.base, which can't have a compile-time dependency on jdk.jfr, to check if an event can be committed without using an event object. See issue for details.
>> 
>> Testing: 
>> - jdk/jdk/jfr
>> - tier1 + tier2
>> - Tested to implement ThreadSleep event using a static commit method (not part of this changeset)
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos, method and field names

Marked as reviewed by mgronlun (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8810

From egahlin at openjdk.java.net  Fri May 20 20:09:58 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Fri, 20 May 2022 20:09:58 GMT
Subject: Integrated: 8285513: JFR: Add more static support for event classes
In-Reply-To: <Qymhpooepst9M0DMklo8cjjFevGRycsSIjAeHwHXjq8=.b98c3eef-e112-47a3-a98f-083bc1cb8923@github.com>
References: <Qymhpooepst9M0DMklo8cjjFevGRycsSIjAeHwHXjq8=.b98c3eef-e112-47a3-a98f-083bc1cb8923@github.com>
Message-ID: <AH8zTEV2eiYxmDKT8JVwWCnWcE9Pyk4vp-bDdE3_Jic=.5efd6720-6b56-4d40-9df8-1800ea39d37e@github.com>

On Fri, 20 May 2022 13:27:14 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review that allows code in java.base, which can't have a compile-time dependency on jdk.jfr, to check if an event can be committed without using an event object. See issue for details.
> 
> Testing: 
> - jdk/jdk/jfr
> - tier1 + tier2
> - Tested to implement ThreadSleep event using a static commit method (not part of this changeset)

This pull request has now been integrated.

Changeset: 7b274feb
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7b274feba5117b6cd80601242a4176f967625cc2
Stats:     90 lines in 1 file changed: 72 ins; 14 del; 4 mod

8285513: JFR: Add more static support for event classes

Reviewed-by: mgronlun

-------------

PR: https://git.openjdk.java.net/jdk/pull/8810

From egahlin at openjdk.java.net  Sat May 21 15:15:15 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Sat, 21 May 2022 15:15:15 GMT
Subject: RFR: 8287113: JFR: Periodic task thread uses period for method
 sampling events
Message-ID: <V4NWtE45ks-Fh_x0wcLaGAEFyFfsNB-HiJbS-vP7nl4=.a36b38c8-f775-48cf-8edb-090e37afeddd@github.com>

Could I have a review that excludes the native method sampling event type from the JFR Periodic Task thread. Sampling is done in native code, not in the periodic task thread. 

The method sampling event (jdk.ExecutionSample) was already excluded, but jdk.NativeMethodSample was missing. This lead to the periodic task thread waking up 50 times per second instead of once (when using the default configuration). Each time the thread waits and an unnecessary JavaMonitorWait event was emitted.

Testing: jdk/jdk/jfr

-------------

Commit messages:
 - Initial

Changes: https://git.openjdk.java.net/jdk/pull/8824/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8824&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287113
  Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8824.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8824/head:pull/8824

PR: https://git.openjdk.java.net/jdk/pull/8824

From jbachorik at openjdk.java.net  Mon May 23 07:08:00 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Mon, 23 May 2022 07:08:00 GMT
Subject: RFR: 8287113: JFR: Periodic task thread uses period for method
 sampling events
In-Reply-To: <V4NWtE45ks-Fh_x0wcLaGAEFyFfsNB-HiJbS-vP7nl4=.a36b38c8-f775-48cf-8edb-090e37afeddd@github.com>
References: <V4NWtE45ks-Fh_x0wcLaGAEFyFfsNB-HiJbS-vP7nl4=.a36b38c8-f775-48cf-8edb-090e37afeddd@github.com>
Message-ID: <uArrKGHOyZsixqb43ptOrP60Lsa4C7-NRLkqoYYT80s=.081be9fb-66e8-43d7-9637-afd316120663@github.com>

On Sat, 21 May 2022 14:22:52 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review that excludes the native method sampling event type from the JFR Periodic Task thread. Sampling is done in native code, not in the periodic task thread. 
> 
> The method sampling event (jdk.ExecutionSample) was already excluded, but jdk.NativeMethodSample was missing. This lead to the periodic task thread waking up 50 times per second instead of once (when using the default configuration). Each time the thread waits an unnecessary JavaMonitorWait event was emitted.
> 
> Testing: jdk/jdk/jfr

Looks good!

-------------

Marked as reviewed by jbachorik (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8824

From asotona at openjdk.java.net  Mon May 23 10:40:40 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Mon, 23 May 2022 10:40:40 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v9]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <W_1U5L9wg5OtyL_Ar1-3297-G3AA7DQKexeRB1qm6D8=.cf6451b5-559d-4d20-b3d6-b294f5b1cf06@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   re-enabled warnings for java.base, java.rmi and java.smartcardio
 - Merge branch 'openjdk:master' into JDK-8244681
 - lossy conversions addressed in java.net.http, jdk.incubator.foreign, Microbenchmarks and most of java.base
   new case appeared in java.base by moving jdk.incubator.foreign code under java.base
 - Merge remote-tracking branch 'upstream/master' into JDK-8244681
   
   # Conflicts:
   #	make/test/BuildMicrobenchmark.gmk
 - enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning description
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning wording
   fixed typo in test method name
 - Merge branch 'openjdk:master' into JDK-8244681
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/c9065915...455720ef

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=08
  Stats: 441 lines in 18 files changed: 438 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From asotona at openjdk.java.net  Mon May 23 11:02:32 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Mon, 23 May 2022 11:02:32 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v10]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <BjXRwHICfpOB1Ol2lbijomFjPYp0eaUL2Y2NRkHYuRQ=.346a7ec5-96ed-48a3-9c36-af1aea010a8e@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module
 - Added man-page line about lossy-conversion lint

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8599/files
  - new: https://git.openjdk.java.net/jdk/pull/8599/files/455720ef..4978c2a6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=08-09

  Stats: 5 lines in 3 files changed: 3 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From egahlin at openjdk.java.net  Mon May 23 12:41:56 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Mon, 23 May 2022 12:41:56 GMT
Subject: RFR: JDK-8228990: JFR: TestNetworkUtilizationEvent.java expects 2+
 Network interfaces on Linux but finding 1
Message-ID: <w1QGoY8HW-YtDs2miB7I05rQ8rwVEwqkv3-sU0yP-ps=.df7f1e8f-8d7a-4831-801a-78e7d3eab01f@github.com>

Could I have a review of a PR that changes the test for the Network Utilization event so it only validates the loopback interface. 

The test fail intermittently on the real network interface, so it's been on the problem list for years. This means the event hasn't got any testing. If there is an interest and resources to investigate this further, a separate issue can be filed to add back testing for more than the loopback interface.

Testing: 
Running /test/jdk/jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java 400 times on Mac, Linux and Windows.

Thanks
Erik

-------------

Commit messages:
 - Initial

Changes: https://git.openjdk.java.net/jdk/pull/8841/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8841&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8228990
  Stats: 16 lines in 2 files changed: 0 ins; 12 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8841.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8841/head:pull/8841

PR: https://git.openjdk.java.net/jdk/pull/8841

From egahlin at openjdk.java.net  Mon May 23 15:16:42 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Mon, 23 May 2022 15:16:42 GMT
Subject: Integrated: 8287113: JFR: Periodic task thread uses period for method
 sampling events
In-Reply-To: <V4NWtE45ks-Fh_x0wcLaGAEFyFfsNB-HiJbS-vP7nl4=.a36b38c8-f775-48cf-8edb-090e37afeddd@github.com>
References: <V4NWtE45ks-Fh_x0wcLaGAEFyFfsNB-HiJbS-vP7nl4=.a36b38c8-f775-48cf-8edb-090e37afeddd@github.com>
Message-ID: <SGCfSHbU8EQ5KPEMKWzMdn0nL9toONkVuoT2eTfzq2o=.17dd2b10-7985-4811-8177-fbadcac2f36e@github.com>

On Sat, 21 May 2022 14:22:52 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a change that excludes the native method sampling event type from the JFR Periodic Task thread. Sampling is done in native code, not in the periodic task thread. 
> 
> The method sampling event (jdk.ExecutionSample) was already excluded, but jdk.NativeMethodSample was missing. This lead to the periodic task thread waking up 50 times per second instead of once (when using the default configuration). Each time the thread waits an unnecessary JavaMonitorWait event was emitted.
> 
> Testing: jdk/jdk/jfr

This pull request has now been integrated.

Changeset: 8122466f
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8122466fbb8e3f3450131895551ec5b832845938
Stats:     5 lines in 2 files changed: 4 ins; 0 del; 1 mod

8287113: JFR: Periodic task thread uses period for method sampling events

Reviewed-by: jbachorik

-------------

PR: https://git.openjdk.java.net/jdk/pull/8824

From egahlin at openjdk.java.net  Mon May 23 16:17:25 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Mon, 23 May 2022 16:17:25 GMT
Subject: RFR: 8287165: JFR: Add logging to
 jdk/jfr/api/consumer/recordingstream/TestOnEvent.java
Message-ID: <mg5cQs72QGOr3sDG2lV7jWD8s_7ZtPHbh4d-O9ax0U4=.7c97000b-d063-4b7f-8de7-448b0e8cfe16@github.com>

Could I have review of PR that adds logging to a test that fails intermittently. Drawback of adding logging is that it might prevent race conditions to occur, but keeping the test on problem list prevents other use cases of the onEvent-method to be tested. 

Testing: test/jdk/jdk/jfr/api/consumer/recordingstream/TestOnEvent.java

We can revisit the main issue https://bugs.openjdk.java.net/browse/JDK-8255404 in 6-12 months if hasn't failed. 

Thanks
Erik

-------------

Commit messages:
 - Initial

Changes: https://git.openjdk.java.net/jdk/pull/8847/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8847&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287165
  Stats: 9 lines in 2 files changed: 8 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8847.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8847/head:pull/8847

PR: https://git.openjdk.java.net/jdk/pull/8847

From mgronlun at openjdk.java.net  Tue May 24 12:32:55 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 24 May 2022 12:32:55 GMT
Subject: RFR: 8287165: JFR: Add logging to
 jdk/jfr/api/consumer/recordingstream/TestOnEvent.java
In-Reply-To: <mg5cQs72QGOr3sDG2lV7jWD8s_7ZtPHbh4d-O9ax0U4=.7c97000b-d063-4b7f-8de7-448b0e8cfe16@github.com>
References: <mg5cQs72QGOr3sDG2lV7jWD8s_7ZtPHbh4d-O9ax0U4=.7c97000b-d063-4b7f-8de7-448b0e8cfe16@github.com>
Message-ID: <UWjLuZWikSMG-AplpnNPMUQU0YlMOXwKTuKpeAxDyIs=.3691a100-af9f-420d-adec-3cd0770b325d@github.com>

On Mon, 23 May 2022 15:55:06 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of PR that adds logging to a test that fails intermittently. Drawback of adding logging is that it might prevent race conditions to occur, but keeping the test on problem list prevents other use cases of the onEvent-method to be tested. 
> 
> Testing: test/jdk/jdk/jfr/api/consumer/recordingstream/TestOnEvent.java
> 
> We can revisit the main issue https://bugs.openjdk.java.net/browse/JDK-8255404 in 6-12 months if hasn't failed. 
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8847

From mgronlun at openjdk.java.net  Tue May 24 15:46:47 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 24 May 2022 15:46:47 GMT
Subject: RFR: JDK-8228990: JFR: TestNetworkUtilizationEvent.java expects 2+
 Network interfaces on Linux but finding 1
In-Reply-To: <w1QGoY8HW-YtDs2miB7I05rQ8rwVEwqkv3-sU0yP-ps=.df7f1e8f-8d7a-4831-801a-78e7d3eab01f@github.com>
References: <w1QGoY8HW-YtDs2miB7I05rQ8rwVEwqkv3-sU0yP-ps=.df7f1e8f-8d7a-4831-801a-78e7d3eab01f@github.com>
Message-ID: <d3L_ZlE9GG3ZPw-OTaltcoTnnDbKcvGZndKid_h-hE4=.91b87ef0-0106-444d-b3ad-500e420b31d4@github.com>

On Mon, 23 May 2022 12:25:36 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that changes the test for the Network Utilization event so it only validates the loopback interface. 
> 
> The test fail intermittently on the real network interface, so it's been on the problem list for years. This means the event hasn't got any testing. If there is an interest and resources to investigate this further, a separate issue can be filed to add back testing for more than the loopback interface.
> 
> Testing: 
> Running /test/jdk/jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java 400 times on Mac, Linux and Windows.
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8841

From egahlin at openjdk.java.net  Tue May 24 15:56:58 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Tue, 24 May 2022 15:56:58 GMT
Subject: Integrated: 8287165: JFR: Add logging to
 jdk/jfr/api/consumer/recordingstream/TestOnEvent.java
In-Reply-To: <mg5cQs72QGOr3sDG2lV7jWD8s_7ZtPHbh4d-O9ax0U4=.7c97000b-d063-4b7f-8de7-448b0e8cfe16@github.com>
References: <mg5cQs72QGOr3sDG2lV7jWD8s_7ZtPHbh4d-O9ax0U4=.7c97000b-d063-4b7f-8de7-448b0e8cfe16@github.com>
Message-ID: <g7GGIJJxSdmzkP5Li3RlBcr6Nyo3HoWKTDqM94vJ-rw=.a201fb4a-7682-4de6-89e9-74038f2f3a37@github.com>

On Mon, 23 May 2022 15:55:06 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of PR that adds logging to a test that fails intermittently. Drawback of adding logging is that it might prevent race conditions to occur, but keeping the test on problem list prevents other use cases of the onEvent-method to be tested. 
> 
> Testing: test/jdk/jdk/jfr/api/consumer/recordingstream/TestOnEvent.java
> 
> We can revisit the main issue https://bugs.openjdk.java.net/browse/JDK-8255404 in 6-12 months if hasn't failed. 
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: d888c80b
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d888c80bbad5bf388cdd65ea4d5749f04bbda94b
Stats:     9 lines in 2 files changed: 8 ins; 1 del; 0 mod

8287165: JFR: Add logging to jdk/jfr/api/consumer/recordingstream/TestOnEvent.java

Reviewed-by: mgronlun

-------------

PR: https://git.openjdk.java.net/jdk/pull/8847

From egahlin at openjdk.java.net  Wed May 25 12:17:00 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 25 May 2022 12:17:00 GMT
Subject: Integrated: JDK-8228990: JFR: TestNetworkUtilizationEvent.java expects
 2+ Network interfaces on Linux but finding 1
In-Reply-To: <w1QGoY8HW-YtDs2miB7I05rQ8rwVEwqkv3-sU0yP-ps=.df7f1e8f-8d7a-4831-801a-78e7d3eab01f@github.com>
References: <w1QGoY8HW-YtDs2miB7I05rQ8rwVEwqkv3-sU0yP-ps=.df7f1e8f-8d7a-4831-801a-78e7d3eab01f@github.com>
Message-ID: <csYxWnmmZWRlDucAL7KF73omIWlvWehvBBAJsppA6Rs=.03bf2e7d-199a-40ad-b341-d62cde654824@github.com>

On Mon, 23 May 2022 12:25:36 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that changes the test for the Network Utilization event so it only validates the loopback interface. 
> 
> The test fail intermittently on the real network interface, so it's been on the problem list for years. This means the event hasn't got any testing. If there is an interest and resources to investigate this further, a separate issue can be filed to add back testing for more than the loopback interface.
> 
> Testing: 
> Running /test/jdk/jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java 400 times on Mac, Linux and Windows.
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: e21b527b
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e21b527b185888699d0bbb64c5e6bfacab337ce4
Stats:     16 lines in 2 files changed: 0 ins; 12 del; 4 mod

8228990: JFR: TestNetworkUtilizationEvent.java expects 2+ Network interfaces on Linux but finding 1

Reviewed-by: mgronlun

-------------

PR: https://git.openjdk.java.net/jdk/pull/8841

From egahlin at openjdk.java.net  Wed May 25 19:18:13 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 25 May 2022 19:18:13 GMT
Subject: RFR: 8282947 JFR: Dump on shutdown live-locks in some conditions
Message-ID: <huCj1hbe6c3xiEXwd14OnGrZwhYQMwPo4O6CXYrjxug=.7e761ab3-82a1-44d1-a23a-170efeaf85cd@github.com>

Could I have review that fixes a livelock when using /dev/null as dump path.

Testing: test/jdk/jdk/jfr + tier1

-------------

Commit messages:
 - Initial

Changes: https://git.openjdk.java.net/jdk/pull/8891/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8891&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282947
  Stats: 66 lines in 3 files changed: 62 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8891.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8891/head:pull/8891

PR: https://git.openjdk.java.net/jdk/pull/8891

From david.holmes at oracle.com  Thu May 26 02:10:06 2022
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 26 May 2022 12:10:06 +1000
Subject: How can Java developers best understand their impact on the
 start-up of the JVM?
In-Reply-To: <BN8PR00MB0595D22FCDB1F429B1B069C68AD69@BN8PR00MB0595.namprd00.prod.outlook.com>
References: <BN8PR00MB0595D22FCDB1F429B1B069C68AD69@BN8PR00MB0595.namprd00.prod.outlook.com>
Message-ID: <be827a1a-4559-6960-34e3-db01bbf622ab@oracle.com>

cc'ing hotspot-jfr-dev

On 26/05/2022 9:45 am, Mat Carter wrote:
> The Microsoft Java Engineering Group (JEG) have been looking at how Java developers can best understand the impact of their decisions on start-up time. Specifically, how developers can identify and mitigate the dominant activities that occur during start-up, through to their app / service reaching a steady state (warmed up).
> 
> Upon investigation into the available tooling (i.e., jstat, jcmd, jmc, VisualVM, MXBeans), it seems that Performance Counters (PCs) and JDK Flight Recorder events (JFREs) are the main source of the available startup metrics that get surfaced.
> 
> Whilst the tooling does provide insight to specific areas (GC, JIT Compilation etc.), there does not seem to be one view to help a developer identify the dominant activities that are impacting start-up.
> 
> Q: Has the above been discussed before and are there any existing plans to address the outcomes that I might have missed?
> 
> Looking at the specific PCs and JFREs there are a few ?missing? metrics, for example a timestamp at the very beginning entry point of the JVM. Also, it appears that the JFREs represent a subset of the PCs - does this indicate that either some PCs should be removed (or only enabled for JVM development) or that there remain JFREs to be added?
> 
> Q: Is there a current position on whether PCs and JFREs will continue to co-exist (the former supporting JMX MXBeans, et al.), or is there a plan to phase out PCs in favor of JFREs?
> 
> Q: Assuming PCs should continue to exist, do folks see the value in documenting them and making them readily accessible to the running application? Especially in the deployment scenario where running a second application or tool (to sample the PCs remotely) is not feasible. FYI - during our initial investigations we wrote some scripts to find all possible PCs. We did this because jcmd only lists instantiated PCs and the PC names are procedurally generated, making them non-trivial to search for.
> 
> Q: Do folks see value in documenting the JFREs, especially since the application can access the JFR Event stream? (There is non-official documentation available [1])
> 
> Q: While Project Leyden concerns itself primarily with improving start-up times, are there any other known activities targeting profiling of Java applications (esp. start-up)?
> 
> Answers and discussion of the above is most welcome so that our group moves forward in helping our customers, whilst staying aligned with and contributing to the OpenJDK community!
> 
> Thanks in advance
> Mat Carter
> 
> [1] https://bestsolution-at.github.io/jfr-doc/index.html

From dholmes at openjdk.java.net  Thu May 26 02:30:49 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 26 May 2022 02:30:49 GMT
Subject: RFR: 8286707: JFR: Don't commit JFR internal jdk.JavaMonitorWait
 events
In-Reply-To: <ksWcEZXtn5JBF9PJKOBU6H0LINTtWNFcV7CjDawvfL4=.429515a1-04a5-4dfc-8bb7-5e40d32b1b8c@github.com>
References: <ksWcEZXtn5JBF9PJKOBU6H0LINTtWNFcV7CjDawvfL4=.429515a1-04a5-4dfc-8bb7-5e40d32b1b8c@github.com>
Message-ID: <iufn4bho8QPtue7lUTg2e7l7TBNKLINj9KsQlpRmbUM=.f0be708f-0d5c-48e2-9cc7-3e94e9168785@github.com>

On Wed, 25 May 2022 12:24:03 GMT, Joakim Nordstr?m <jnordstrom at openjdk.org> wrote:

> Changed the JFR chunk rotation lock object to specific internal class. This allows that specific Object.wait() event to be skipped, thus not adding JFR internal noise to recordings. 
> 
> # Testing
> - jdk_jfr

I think any filtering should be handled internally to JFR not in the ObjectMonitor code.

-------------

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8883

From mgronlun at openjdk.java.net  Fri May 27 09:31:28 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 27 May 2022 09:31:28 GMT
Subject: RFR: 8282947 JFR: Dump on shutdown live-locks in some conditions
In-Reply-To: <huCj1hbe6c3xiEXwd14OnGrZwhYQMwPo4O6CXYrjxug=.7e761ab3-82a1-44d1-a23a-170efeaf85cd@github.com>
References: <huCj1hbe6c3xiEXwd14OnGrZwhYQMwPo4O6CXYrjxug=.7e761ab3-82a1-44d1-a23a-170efeaf85cd@github.com>
Message-ID: <gRAT3Fk11hBaS1yCx-94mdGGK6GKBrDG2vSiSoR2gCk=.cb372452-a5a2-42b7-a3fc-161243f6bce4@github.com>

On Wed, 25 May 2022 19:08:16 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of PR that fixes a livelock when using /dev/null as dump path.
> 
> Testing: test/jdk/jdk/jfr + tier1

Marked as reviewed by mgronlun (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8891

From egahlin at openjdk.java.net  Fri May 27 13:03:44 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Fri, 27 May 2022 13:03:44 GMT
Subject: Integrated: 8282947 JFR: Dump on shutdown live-locks in some
 conditions
In-Reply-To: <huCj1hbe6c3xiEXwd14OnGrZwhYQMwPo4O6CXYrjxug=.7e761ab3-82a1-44d1-a23a-170efeaf85cd@github.com>
References: <huCj1hbe6c3xiEXwd14OnGrZwhYQMwPo4O6CXYrjxug=.7e761ab3-82a1-44d1-a23a-170efeaf85cd@github.com>
Message-ID: <PoHON0keronbmbWf2fN6fvJVauk8YcR4hQ9aA1pAQWg=.51300b02-58f0-47b9-ad09-e557fbd20654@github.com>

On Wed, 25 May 2022 19:08:16 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of PR that fixes a livelock when using /dev/null as dump path.
> 
> Testing: test/jdk/jdk/jfr + tier1

This pull request has now been integrated.

Changeset: 63eb0b7e
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/63eb0b7e8606dd9cd145e92eeeb744ff5b7be569
Stats:     66 lines in 3 files changed: 62 ins; 1 del; 3 mod

8282947: JFR: Dump on shutdown live-locks in some conditions

Reviewed-by: mgronlun

-------------

PR: https://git.openjdk.java.net/jdk/pull/8891

From egahlin at openjdk.java.net  Fri May 27 17:42:24 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Fri, 27 May 2022 17:42:24 GMT
Subject: RFR: 8285008: JFR: jdk/jfr/jmx/streaming/TestClose.java failed with
 "Exception: Expected repository to be empty"
Message-ID: <P3AKKfMDhQNrXezDg3Wa06J__RFS713TzG1C1e9LKjg=.d446443e-d5ea-4f42-92d1-6c4e55f8965e@github.com>

Could I have a review of a change that avoids a race condition.

Problem occurs if the main thread enters awaitTermination() after closed() has been called but before it has finished. If this happens, the main thread will not wait and instead proceed and check if files have been removed, potentially before this has actually happened. This can be reproduced by putting a Thread.sleep in the RecordingStream::close() method.

The solution is to check the terminated state instead of the closed state. This can be done using a CoundDownLatch in awaitTermination() which avoids much of the logic that is there today. 

I'm not sure it is the race that causes the test to fail. It could also be something related to deleting files on Windows, so I enabled logging to make it easier to diagnose. 

Testing: jdk/jdk/jfr

Thanks
Erik

-------------

Commit messages:
 - Merge branch 'openjdk:master' into remoteclose
 - Remove whitespaces
 - Initial

Changes: https://git.openjdk.java.net/jdk/pull/8927/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8927&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285008
  Stats: 31 lines in 2 files changed: 2 ins; 20 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8927.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8927/head:pull/8927

PR: https://git.openjdk.java.net/jdk/pull/8927

From mgronlun at openjdk.java.net  Fri May 27 19:18:41 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 27 May 2022 19:18:41 GMT
Subject: RFR: 8285008: JFR: jdk/jfr/jmx/streaming/TestClose.java failed
 with "Exception: Expected repository to be empty"
In-Reply-To: <P3AKKfMDhQNrXezDg3Wa06J__RFS713TzG1C1e9LKjg=.d446443e-d5ea-4f42-92d1-6c4e55f8965e@github.com>
References: <P3AKKfMDhQNrXezDg3Wa06J__RFS713TzG1C1e9LKjg=.d446443e-d5ea-4f42-92d1-6c4e55f8965e@github.com>
Message-ID: <W916B3416dQtrorfeD6KJ8a68G5dYd8DjXLtwBEPxwg=.20669891-35b2-40cc-8c72-04376d082159@github.com>

On Fri, 27 May 2022 17:27:27 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a change that avoids a race condition.
> 
> Problem occurs if the main thread enters awaitTermination() after closed() has been called but before it has finished. If this happens, the main thread will not wait and instead proceed and check if files have been removed, potentially before this has actually happened. This can be reproduced by putting a Thread.sleep in the RecordingStream::close() method.
> 
> The solution is to check the terminated state instead of the closed state. This can be done using a CoundDownLatch in awaitTermination() which avoids much of the logic that is there today. 
> 
> I'm not sure it is the race that causes the test to fail. It could also be something related to deleting files on Windows, so I enabled logging to make it easier to diagnose. 
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8927

From egahlin at openjdk.java.net  Fri May 27 21:07:11 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Fri, 27 May 2022 21:07:11 GMT
Subject: Integrated: 8287463: JFR: Disable TestDevNull.java on Windows
Message-ID: <IcXLv5PNm19kBiXyxEx4c300F8b8A7ERLBF0F3xSYWM=.d69c48fd-cc79-4e89-8809-9dad2646f582@github.com>

Could I have review of a change that disable TestDevNull.java on Windows.

Testing: jdk/jdk/jfr/api/recording/dump/TestDevNull.java

Thanks
Erik

-------------

Commit messages:
 - Initial

Changes: https://git.openjdk.java.net/jdk/pull/8929/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8929&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287463
  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8929.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8929/head:pull/8929

PR: https://git.openjdk.java.net/jdk/pull/8929

From mgronlun at openjdk.java.net  Fri May 27 21:07:11 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 27 May 2022 21:07:11 GMT
Subject: Integrated: 8287463: JFR: Disable TestDevNull.java on Windows
In-Reply-To: <IcXLv5PNm19kBiXyxEx4c300F8b8A7ERLBF0F3xSYWM=.d69c48fd-cc79-4e89-8809-9dad2646f582@github.com>
References: <IcXLv5PNm19kBiXyxEx4c300F8b8A7ERLBF0F3xSYWM=.d69c48fd-cc79-4e89-8809-9dad2646f582@github.com>
Message-ID: <6Gs_K0P8nyEQGsHUmAyE7QEw6r06Jhin5Kgp_Q0UISc=.6b41a176-2645-4936-b669-946fc94bc0c2@github.com>

On Fri, 27 May 2022 19:26:35 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of a change that disable TestDevNull.java on Windows.
> 
> Testing: jdk/jdk/jfr/api/recording/dump/TestDevNull.java
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8929

From egahlin at openjdk.java.net  Fri May 27 21:07:12 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Fri, 27 May 2022 21:07:12 GMT
Subject: Integrated: 8287463: JFR: Disable TestDevNull.java on Windows
In-Reply-To: <IcXLv5PNm19kBiXyxEx4c300F8b8A7ERLBF0F3xSYWM=.d69c48fd-cc79-4e89-8809-9dad2646f582@github.com>
References: <IcXLv5PNm19kBiXyxEx4c300F8b8A7ERLBF0F3xSYWM=.d69c48fd-cc79-4e89-8809-9dad2646f582@github.com>
Message-ID: <5DuED7f9O6GMZWYMzsa1lCQjw2i_Aeuli8fXQIJ1bBs=.337b6764-a034-4df3-9c12-b07c97739f79@github.com>

On Fri, 27 May 2022 19:26:35 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of a change that disable TestDevNull.java on Windows.
> 
> Testing: jdk/jdk/jfr/api/recording/dump/TestDevNull.java
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 0df47482
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0df4748216ab71937cfcfb86a2d66f3568bced1e
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8287463: JFR: Disable TestDevNull.java on Windows

Reviewed-by: mgronlun

-------------

PR: https://git.openjdk.java.net/jdk/pull/8929

From egahlin at openjdk.java.net  Sat May 28 07:02:58 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Sat, 28 May 2022 07:02:58 GMT
Subject: RFR: 8287484 JFR: Seal RecordedObject
Message-ID: <qQ75Jl-efPmPfF7c4ZYEzJ1B82XMEgtD0ADksxsnR_s=.438b3f39-69e7-4daa-8ffe-5136e78f649e@github.com>

Could I have a review of an enhancement. The RecordedObject class is not meant to be subclasses outside the jdk.jfr.consumer package. Today it is prevented by a package private constructor. It would be good to make it explicit by making the class sealed.

Testing: jdk/jdk/jfr

Thanks
Erik

-------------

Commit messages:
 - Remove whitespace
 - Initial

Changes: https://git.openjdk.java.net/jdk/pull/8930/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8930&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287484
  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8930.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8930/head:pull/8930

PR: https://git.openjdk.java.net/jdk/pull/8930

From mgronlun at openjdk.java.net  Sat May 28 10:55:41 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 28 May 2022 10:55:41 GMT
Subject: RFR: 8287484 JFR: Seal RecordedObject
In-Reply-To: <qQ75Jl-efPmPfF7c4ZYEzJ1B82XMEgtD0ADksxsnR_s=.438b3f39-69e7-4daa-8ffe-5136e78f649e@github.com>
References: <qQ75Jl-efPmPfF7c4ZYEzJ1B82XMEgtD0ADksxsnR_s=.438b3f39-69e7-4daa-8ffe-5136e78f649e@github.com>
Message-ID: <Fd7aEggjAybAh5P7shLjOWpR8xTfBXRN-hB8TaxnZo8=.1bd92b2b-4cd5-42bc-b0dd-9ea26846148f@github.com>

On Fri, 27 May 2022 19:44:23 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of an enhancement. The RecordedObject class is not meant to be subclasses outside the jdk.jfr.consumer package. Today it is prevented by a package private constructor. It would be good to make it explicit by making the class sealed.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8930

From egahlin at openjdk.java.net  Sat May 28 17:25:29 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Sat, 28 May 2022 17:25:29 GMT
Subject: Integrated: 8285008: JFR: jdk/jfr/jmx/streaming/TestClose.java failed
 with "Exception: Expected repository to be empty"
In-Reply-To: <P3AKKfMDhQNrXezDg3Wa06J__RFS713TzG1C1e9LKjg=.d446443e-d5ea-4f42-92d1-6c4e55f8965e@github.com>
References: <P3AKKfMDhQNrXezDg3Wa06J__RFS713TzG1C1e9LKjg=.d446443e-d5ea-4f42-92d1-6c4e55f8965e@github.com>
Message-ID: <6-b4akvSqouORpRPyg_4Y74SHbMirR_SStdafBbi1xA=.4dc0d5e9-0ede-484b-9203-4862faa010f8@github.com>

On Fri, 27 May 2022 17:27:27 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a change that avoids a race condition.
> 
> Problem occurs if the main thread enters awaitTermination() after closed() has been called but before it has finished. If this happens, the main thread will not wait and instead proceed and check if files have been removed, potentially before this has actually happened. This can be reproduced by putting a Thread.sleep in the RecordingStream::close() method.
> 
> The solution is to check the terminated state instead of the closed state. This can be done using a CoundDownLatch in awaitTermination() which avoids much of the logic that is there today. 
> 
> I'm not sure it is the race that causes the test to fail. It could also be something related to deleting files on Windows, so I enabled logging to make it easier to diagnose. 
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: a6e2e223
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a6e2e223ea0339117c89f46e074a92dc2f31dfd5
Stats:     31 lines in 2 files changed: 2 ins; 20 del; 9 mod

8285008: JFR: jdk/jfr/jmx/streaming/TestClose.java failed with "Exception: Expected repository to be empty"

Reviewed-by: mgronlun

-------------

PR: https://git.openjdk.java.net/jdk/pull/8927

From egahlin at openjdk.java.net  Sun May 29 14:00:25 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Sun, 29 May 2022 14:00:25 GMT
Subject: Integrated: 8287484 JFR: Seal RecordedObject
In-Reply-To: <qQ75Jl-efPmPfF7c4ZYEzJ1B82XMEgtD0ADksxsnR_s=.438b3f39-69e7-4daa-8ffe-5136e78f649e@github.com>
References: <qQ75Jl-efPmPfF7c4ZYEzJ1B82XMEgtD0ADksxsnR_s=.438b3f39-69e7-4daa-8ffe-5136e78f649e@github.com>
Message-ID: <LHaZkQZmXjBqsKFHetwKNp44APVSQymuugSLAE9L2S4=.6c8a10ec-2dd3-43fc-a9be-f0babb465390@github.com>

On Fri, 27 May 2022 19:44:23 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of an enhancement. The RecordedObject class is not meant to be subclasses outside the jdk.jfr.consumer package. Today it is prevented by a package private constructor. It would be good to make it explicit by making the class sealed.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 36350bf1
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/36350bf1be1ae3c5b58cc7c7ca95acd9bfa26949
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8287484: JFR: Seal RecordedObject

Reviewed-by: mgronlun

-------------

PR: https://git.openjdk.java.net/jdk/pull/8930