On Tue, 1 Apr 2025 20:00:22 GMT, Chris Plummer wrote:
>> Calling ThreadGroupReference.groups() from an event handler can cause a
>> deadlock. Details in first comment. Tested with :jdk_lang on all supported
>> platforms and tier1, tier2, tier3, and tier5 svc testing.
>
On Tue, 25 Mar 2025 20:36:28 GMT, Chris Plummer wrote:
> Calling ThreadGroupReference.groups() from an event handler can cause a
> deadlock. Details in first comment. Tested with :jdk_lang on all supported
> platforms and tier1, tier2, tier3, and tier5 svc testing.
The reason is bec
On Tue, 25 Mar 2025 20:36:28 GMT, Chris Plummer wrote:
> Calling ThreadGroupReference.groups() from an event handler can cause a
> deadlock. Details in first comment. Tested with :jdk_lang on all supported
> platforms and tier1, tier2, tier3, and tier5 svc testing.
This pull reques
> Calling ThreadGroupReference.groups() from an event handler can cause a
> deadlock. Details in first comment. Tested with :jdk_lang on all supported
> platforms and tier1, tier2, tier3, and tier5 svc testing.
Chris Plummer has updated the pull request incrementally with one additiona
On Sat, 29 Mar 2025 08:55:43 GMT, Alan Bateman wrote:
>> Chris Plummer has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> undo change that wasn't suppose to be committed.
>
> src/java.base/share/classes/
> Calling ThreadGroupReference.groups() from an event handler can cause a
> deadlock. Details in first comment. Tested with :jdk_lang on all supported
> platforms and tier1, tier2, tier3, and tier5 svc testing.
Chris Plummer has updated the pull request incrementally with one additiona
On Thu, 27 Mar 2025 20:47:31 GMT, Serguei Spitsyn wrote:
> The fix looks okay to me. I guess new test fails with a deadlock without your
> fix.
Yes. That is the failure mode. There is no detecting the failure other than a
timeout.
-
PR Comment: https://git.openjdk.org/jdk/pull/24
On Thu, 27 Mar 2025 11:07:31 GMT, Coleen Phillimore wrote:
>> Chris Plummer has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> remove unused locals.
>
> src/java.base/share/classes/java/lang/Thread
> Calling ThreadGroupReference.groups() from an event handler can cause a
> deadlock. Details in first comment. Tested with :jdk_lang on all supported
> platforms and tier1, tier2, tier3, and tier5 svc testing.
Chris Plummer has updated the pull request incrementally with one additiona
On Wed, 26 Mar 2025 20:36:22 GMT, Chris Plummer wrote:
>> test/jdk/com/sun/jdi/EarlyThreadGroupChildrenTest.java line 83:
>>
>>> 81: public void classPrepared(ClassPrepareEvent event) {
>>> 82: try {
>>> 83: ++classPreparedCount;
&g
On Wed, 26 Mar 2025 19:11:01 GMT, Alan Bateman wrote:
>> Chris Plummer has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Use explicit array copying code. Better comment.
>
> test/jdk/com/sun/jdi/EarlyThread
On Wed, 26 Mar 2025 19:01:13 GMT, Alan Bateman wrote:
>> Chris Plummer has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Use explicit array copying code. Better comment.
>
> test/jdk/com/sun/jdi/EarlyThread
> Calling ThreadGroupReference.groups() from an event handler can cause a
> deadlock. Details in first comment. Tested with :jdk_lang on all supported
> platforms and tier1, tier2, tier3, and tier5 svc testing.
Chris Plummer has updated the pull request incrementally with one additiona
On Wed, 26 Mar 2025 16:39:27 GMT, Jaikiran Pai wrote:
>> Regarding adding a comment, I wasn't too sure what the comment should say
>> because once you start down that path, it's hard to not end up with too much
>> detail, and then things just get very wordy. Since we have a test that will
>> f
> Calling ThreadGroupReference.groups() from an event handler can cause a
> deadlock. Details in first comment. Tested with :jdk_lang on all supported
> platforms and tier1, tier2, tier3, and tier5 svc testing.
Chris Plummer has updated the pull request incrementally with one additiona
On Wed, 26 Mar 2025 09:31:37 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/java/lang/ThreadGroup.java line 664:
>>
>>> 662: private ThreadGroup[] subgroupsAsArray() {
>>> 663: List groups = synchronizedSubgroups();
>>> 664: return groups.toArray(new ThreadGroup[grou
Calling ThreadGroupReference.groups() from an event handler can cause a
deadlock. Details in first comment. Tested with :jdk_lang on all supported
platforms and tier1, tier2, tier3, and tier5 svc testing.
-
Commit messages:
- get rid of unused breakpoint event code
- fix more jche
On Tue, 25 Mar 2025 20:36:28 GMT, Chris Plummer wrote:
> Calling ThreadGroupReference.groups() from an event handler can cause a
> deadlock. Details in first comment. Tested with :jdk_lang on all supported
> platforms and tier1, tier2, tier3, and tier5 svc testing.
Sorry, I used
On Wed, 22 Jan 2025 08:49:52 GMT, Matthias Baesken wrote:
>> test/jdk/sun/tools/jhsdb/JShellHeapDumpTest.java line 104:
>>
>>> 102: if (!res) { // try once more
>>> 103: launch(expectedMessage, Arrays.asList(toolArgs), false);
>>> 104: }
>>
>> `launch()` should take
On Tue, 21 Jan 2025 13:24:41 GMT, Matthias Baesken wrote:
> We were running into this error :
> sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java on Linux aarch64, jdk25
>
> stderr: [java.lang.RuntimeException: Unable to deduce type of thread from
> address 0x34144e30 (expected type Ja
On Fri, 13 Dec 2024 23:07:53 GMT, Alex Menkov wrote:
>> In some circumstances ClassFileTransformer.transform can get
>> ClassCircularityError or LinkageError concatenating strings (see
>> JDK-8264667, JDK-8262002).
>> VerifyLocalVariableTableOnRetransformTest fails sometimes on Oracle CI.
>> Th
On Fri, 13 Dec 2024 21:51:10 GMT, Alex Menkov wrote:
>> In some circumstances ClassFileTransformer.transform can get
>> ClassCircularityError or LinkageError concatenating strings (see
>> JDK-8264667, JDK-8262002).
>> VerifyLocalVariableTableOnRetransformTest fails sometimes on Oracle CI.
>> Th
On Fri, 13 Dec 2024 02:21:42 GMT, Alex Menkov wrote:
> In some circumstances ClassFileTransformer.transform can get
> ClassCircularityError or LinkageError concatenating strings (see JDK-8264667,
> JDK-8262002).
> VerifyLocalVariableTableOnRetransformTest fails sometimes on Oracle CI.
> The fix
On Wed, 20 Nov 2024 21:18:01 GMT, David Holmes wrote:
> In JDK 16 we deprecated the old signal and sigset signal-chaining interfaces
> under [JDK-8257572](https://bugs.openjdk.org/browse/JDK-8257572). The
> deprecation warning was written to stdout but all other warnings go to
> stderr. Having
On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and locals that trigger the
>> u
On Thu, 31 Oct 2024 07:13:56 GMT, Julian Waters wrote:
> > I do wonder if mutex support can be implemented for Windows with
> > Acquire/ReleaseSRWLockExclusive. I know it's not strictly needed, but it
> > would be nice to have. Shame threads.h is not available with some Visual
> > Studio versi
On Thu, 31 Oct 2024 07:18:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and locals that trigger the
>> u
On Sun, 27 Oct 2024 06:25:02 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and locals that trigger the
>> u
On Thu, 24 Oct 2024 03:31:31 GMT, Julian Waters wrote:
>> I'm not sure what you mean by "that one". It's the static one that should be
>> removed. The local variables always hide the static, and there seems to be
>> no reason for the value of memHandle to survive outside of the local scope
>>
On Wed, 23 Oct 2024 05:22:45 GMT, Julian Waters wrote:
>> src/jdk.jdi/windows/native/libdt_shmem/shmem_md.c line 47:
>>
>>> 45: {
>>> 46: void *mappedMemory;
>>> 47: // HANDLE memHandle;
>>
>> Why comment out this one but not the one at line 88? It seems they are both
>> equally problemat
On Wed, 23 Oct 2024 05:23:39 GMT, Julian Waters wrote:
>> src/jdk.jdwp.agent/share/native/libjdwp/log_messages.c line 53:
>>
>>> 51: #ifndef _WIN32
>>> 52: static MUTEX_T my_mutex = MUTEX_INIT;
>>> 53: #endif
>>
>> The reason for no reference on windows is because of the following on
>> window
On Mon, 21 Oct 2024 14:34:30 GMT, Julian Waters wrote:
> After 8339120, gcc began catching many different instances of unused code in
> the Windows specific codebase. Some of these seem to be bugs. I've taken the
> effort to mark out all the relevant globals and locals that trigger the
> unuse
On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan wrote:
> This is the implementation of JEP 486: Permanently Disable the Security
> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
> main change
On Fri, 11 Oct 2024 06:43:33 GMT, Axel Boldt-Christmas
wrote:
>> This is the implementation task for `JEP 490: ZGC: Remove the
>> Non-Generational Mode`. See the JEP for details.
>> [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christmas has updated the pull request
On Wed, 9 Oct 2024 10:36:28 GMT, Matthias Baesken wrote:
>> Might be a good idea to have rslt commented out rather than removed outright
>> if we don't want to forget about it. guarantee on a variable that doesn't
>> exist will be rather confusing to anyone reading through the code
>
>> Might b
On Wed, 9 Oct 2024 11:44:35 GMT, Matthias Baesken wrote:
>> There are a few warnings as errors occurring when building on Linux with
>> clang (clang15). Mostly these are some kind of 'unused' warnings.
>> Might be related to https://bugs.openjdk.org/browse/JDK-8339156 .
>
> Matthias Baesken has
On Tue, 8 Oct 2024 13:38:54 GMT, Matthias Baesken wrote:
> There are a few warnings as errors occurring when building on Linux with
> clang (clang15). Mostly these are some kind of 'unused' warnings.
> Might be related to https://bugs.openjdk.org/browse/JDK-8339156 .
src/jdk.hotspot.agent/linux
On Thu, 15 Aug 2024 20:28:28 GMT, Dhamoder Nalla wrote:
>> Use the GetTempPath2 APIs instead of the GetTempPath APIs in native code
>> across the OpenJDK repository to retrieve the temporary directory path, as
>> GetTempPath2 provides enhanced security. While GetTempPath may still
>> function
On Tue, 17 Sep 2024 18:30:16 GMT, Dhamoder Nalla wrote:
> > Do we have any apps commonly run as a Windows SYSTEM account which expect
> > to attach to other Java apps run by a different Java version? You're
> > suggesting that will have no impact and agreed it would seem really
> > unusual. 8-
On Tue, 3 Sep 2024 03:00:56 GMT, David Holmes wrote:
>> This is the implementation of a new method added to the JNI specification.
>>
>> From the CSR request:
>>
>> The `GetStringUTFLength` function returns the length as a `jint` (`jsize`)
>> value and so is limited to returning at most `Integ
On Fri, 30 Aug 2024 05:21:54 GMT, David Holmes wrote:
>> This is the implementation of a new method added to the JNI specification.
>>
>> From the CSR request:
>>
>> The `GetStringUTFLength` function returns the length as a `jint` (`jsize`)
>> value and so is limited to returning at most `Inte
On Fri, 30 Aug 2024 02:07:54 GMT, David Holmes wrote:
> This is the implementation of a new method added to the JNI specification.
>
> From the CSR request:
>
> The `GetStringUTFLength` function returns the length as a `jint` (`jsize`)
> value and so is limited to returning at most `Integer.MA
On Thu, 15 Aug 2024 22:06:14 GMT, Dhamoder Nalla wrote:
>> src/hotspot/os/windows/os_windows.cpp line 1522:
>>
>>> 1520: const char* os::get_temp_directory() {
>>> 1521: static char path_buf[MAX_PATH];
>>> 1522: if (_GetTempPath2A != nullptr) {
>>
>> Where does _GetTempPath2A get initialize
On Thu, 15 Aug 2024 16:23:18 GMT, Dhamoder Nalla wrote:
> Use the GetTempPath2 APIs instead of the GetTempPath APIs in native code
> across the OpenJDK repository to retrieve the temporary directory path, as
> GetTempPath2 provides enhanced security. While GetTempPath may still function
> with
On Thu, 4 Jul 2024 10:08:30 GMT, Kevin Walls wrote:
> There are two similarly names tests.
> Recently:
> JDK-8335124: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed
> with CPU time out of expected range
> ...made a simple change to try and avoid noisy test failures. The same fix
On Tue, 11 Jun 2024 18:11:55 GMT, Kevin Walls wrote:
>> jstatd is an RMI server application which monitors HotSpot VMs, and provides
>> an interface to the monitoring tool jstat, for use across a remote RMI
>> connection.
>>
>> RMI is not how modern applications communicate. It is an old trans
On Mon, 10 Jun 2024 21:58:29 GMT, Damon Nguyen wrote:
>> This issue is responsible for updating the translations of all the
>> localize(able) resources in the JDK. Primarily, the changes between JDK 22
>> RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>>
>> The tra
On Mon, 10 Jun 2024 21:58:29 GMT, Damon Nguyen wrote:
>> This issue is responsible for updating the translations of all the
>> localize(able) resources in the JDK. Primarily, the changes between JDK 22
>> RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>>
>> The tra
On Mon, 26 Feb 2024 22:55:06 GMT, Jiangli Zhou wrote:
>> Please help review this trivial fix for resolving `ld: error: duplicate
>> symbol: closeDescriptors` when static linking with both libjdwp and libjava,
>> thanks.
>
> Jiangli Zhou has updated the pull request incrementally with two additi
On Mon, 26 Feb 2024 20:20:31 GMT, Jiangli Zhou wrote:
> Please help review this trivial fix for resolving `ld: error: duplicate
> symbol: closeDescriptors` when static linking with both libjdwp and libjava,
> thanks.
src/java.base/unix/native/libjava/childproc.h line 134:
> 132: int closeSafe
On Sat, 16 Dec 2023 17:25:20 GMT, Alan Bateman wrote:
> A lot of test changes have accumulated in the loom repo, this includes both
> new tests and updates to existing tests. Some of these updates can be brought
> to the main line. This update brings over:
>
> - The existing tests for pinning
On Fri, 1 Dec 2023 00:58:57 GMT, Leonid Mesnik wrote:
> Description of problem and propsed fix from @plummercj
> '
> In test/failure_handler/src/share/conf/mac.properties we have:
>
> process.top.app=top
> process.top.args=-l 1
>
> So top is run with the "-l 1" args, causing it to do one itera
On Wed, 6 Sep 2023 16:06:29 GMT, Erik Joelsson wrote:
> > I wonder if this is the right thing to do for the hprof files. I believe
> > they originated from some hprof tools that we no longer ship. 3rd parties
> > might choose to integrate them into their own tools.
>
> Do you think I should re
On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson wrote:
> There are a number of files in the `test` directory that have an incorrect
> copyright header, which includes the "classpath" exception text. This patch
> removes that text from all test files that I could find it in. I did this
> using a
On Tue, 29 Aug 2023 09:12:51 GMT, Leo Korinth wrote:
>> Rename createJavaProcessBuilder so that it is not used by mistake instead of
>> createTestJvm.
>>
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed
>> -i -e
>> "s/createJavaProcessBuilder(/createJavaProcessBu
On Wed, 9 Aug 2023 11:06:04 GMT, Matthias Baesken wrote:
>> There is coding e.g. in
>> https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72
>> that deals with shared lib naming on different OS.
>> This code should be simplified.
>
> Matthias
Normally we want the test args passed to the SA debuggee. In fact for proper SA
test coverage, it is more important for the test args to be passed to the
debuggee than to be passed to the test or the the SA tool that the test
launches. For a couple of jhsdb tests that launch jshell as the debugg
On Fri, 4 Aug 2023 09:59:41 GMT, Matthias Baesken wrote:
> There is coding e.g. in
> https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72
> that deals with shared lib naming on different OS.
> This code should be simplified.
Changes requeste
On Wed, 19 Jul 2023 10:58:58 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to deprecate for
>> removal the `-Xdebug` option and `-debug` option of the `java` command?
>> This addresses https://bugs.openjdk.org/browse/JDK-8227229.
>>
>> As noted in the JBS
On Fri, 30 Jun 2023 12:35:27 GMT, Matthias Baesken wrote:
> 8310380: Handle problems in core-related tests on macOS when codesign tool
> does not work
Marked as reviewed by cjplummer (Reviewer).
-
PR Review: https://git.openjdk.org/jdk21/pull/87#pullrequestreview-1507621309
On Tue, 27 Jun 2023 13:45:27 GMT, Matthias Baesken wrote:
>> Currently, a number of tests fail on macOS because they miss the core file
>> (e.g. serviceability/sa/TestJmapCore.java).
>> The reason is that configure detects on some setups that codesign does not
>> work ("checking if debug mode c
On Thu, 22 Jun 2023 11:51:15 GMT, Matthias Baesken wrote:
>> Currently, a number of tests fail on macOS because they miss the core file
>> (e.g. serviceability/sa/TestJmapCore.java).
>> The reason is that configure detects on some setups that codesign does not
>> work ("checking if debug mode c
On Fri, 23 Jun 2023 08:37:16 GMT, Matthias Baesken wrote:
> Chris are you okay with the latest rev. of this change?
Sorry, I've been on vacation the past few days. I will have a look at it
tomorrow.
-
PR Comment: https://git.openjdk.org/jdk/pull/14562#issuecomment-1606661232
On Tue, 20 Jun 2023 13:23:16 GMT, Matthias Baesken wrote:
> Currently, a number of tests fail on macOS because they miss the core file
> (e.g. serviceability/sa/TestJmapCore.java).
> The reason is that configure detects on some setups that codesign does not
> work ("checking if debug mode codes
On Tue, 20 Jun 2023 13:23:16 GMT, Matthias Baesken wrote:
> Currently, a number of tests fail on macOS because they miss the core file
> (e.g. serviceability/sa/TestJmapCore.java).
> The reason is that configure detects on some setups that codesign does not
> work ("checking if debug mode codes
On Tue, 20 Jun 2023 13:23:16 GMT, Matthias Baesken wrote:
> Currently, a number of tests fail on macOS because they miss the core file
> (e.g. serviceability/sa/TestJmapCore.java).
> The reason is that configure detects on some setups that codesign does not
> work ("checking if debug mode codes
On Fri, 16 Jun 2023 11:59:39 GMT, Matthias Baesken wrote:
>> After push of [JDK-8307478](https://bugs.openjdk.org/browse/JDK-8307478) ,
>> the following test started to fail on AIX :
>> com/sun/tools/attach/warnings/DynamicLoadWarningTest.java ; failure output :
>>
>> java.lang.RuntimeException
On Fri, 9 Jun 2023 13:39:26 GMT, Matthias Baesken wrote:
> On AIX , new jtreg test
> com/sun/tools/attach/warnings/DynamicLoadWarningTest.java always failed with
> the output :
>
> --System.err:(294/28579)--
> STARTED DynamicLoadWarningTest::testLoadJavaAgent 'testLoadJavaAg
On Mon, 5 Jun 2023 15:10:18 GMT, Alan Bateman wrote:
>> test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/ThreadController.java
>> line 660:
>>
>>> 658: expectedMethods.add(Thread.class.getName() + ".sleep");
>>> 659: expectedMethods.add(Thread.class.getName() + ".sleepNanos");
On Fri, 2 Jun 2023 21:30:46 GMT, Chris Plummer wrote:
> Normally when a virtual thread wrapper is used to run a test, the main thread
> is renamed to "old-m-a-i-n" and the new virtual thread that will act as the
> main thread is named "main". Neither is bei
On Sat, 3 Jun 2023 21:34:16 GMT, Chris Plummer wrote:
>> Normally when a virtual thread wrapper is used to run a test, the main
>> thread is renamed to "old-m-a-i-n" and the new virtual thread that will act
>> as the main thread is named "main". Neither i
wse/JDK-8309396), which will also
> subsequently be fixed.
>
> Note this fix messed up one runtime test. It was expecting an exception
> message to mention the "main" thread rather than "old-m-a-i-n". Loosening the
> exception message matching pattern a bit
wse/JDK-8309396), which will also
> subsequently be fixed.
>
> Note this fix messed up one runtime test. It was expecting an exception
> message to mention the "main" thread rather than "old-m-a-i-n". Loosening the
> exception message matching pattern a bit
On Sat, 3 Jun 2023 14:07:52 GMT, Alan Bateman wrote:
>> Normally when a virtual thread wrapper is used to run a test, the main
>> thread is renamed to "old-m-a-i-n" and the new virtual thread that will act
>> as the main thread is named "main". Neither is being done by
>> `ProcessTools.main()`
Normally when a virtual thread wrapper is used to run a test, the main thread
is renamed to "old-m-a-i-n" and the new virtual thread that will act as the
main thread is named "main". Neither is being done by `ProcessTools.main()`.
This can cause problems for tests that expect the main thread tha
The JDWP spec for StackFrame.SetValue currently states:
"If the thread is a virtual thread then this command can be used to set
"
"the value of local variables in the top-most frame when the thread is "
"suspended at a breakpoint or single step event. The target VM may
su
This is a follow-on to
[JDK-8264699](https://bugs.openjdk.org/browse/JDK-8264699) which adds JVMTI
PopFrames support for virtual thread. For JDWP and JDI this is mostly a spec
update, although JDI needs minor changes to properly throw the correct
exception. Note this PR needs JDK-8264699 in ord
On Fri, 12 May 2023 00:05:21 GMT, Daniel D. Daugherty
wrote:
> A trivial fix to ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java
> on linux-x64.
Maybe linux-all would be better.
-
PR Comment: https://git.openjdk.org/jdk/pull/13946#issuecomment-1544916181
On Fri, 21 Apr 2023 21:43:39 GMT, Leonid Mesnik wrote:
> ProcessTools.startProcess() creates process and read it's output error
> streams. So the any other using of corresponding Process.getInputStream() and
> Process.getErrorStream() doesn't get process streams.
>
> This fix preserve process
On Thu, 20 Apr 2023 18:40:52 GMT, Leonid Mesnik wrote:
>> ProcessTools.startProcess() creates process and read it's output error
>> streams. So the any other using of corresponding Process.getInputStream()
>> and Process.getErrorStream() doesn't get process streams.
>>
>> This fix preserve pro
On Fri, 31 Mar 2023 06:07:39 GMT, Julian Waters wrote:
> C11 has been stable for a long time on all platforms, so native code can use
> the standard alignas operator for alignment requirements
I'm not sure what you mean by hotspot requiring a special review, but
serviceability code does requir
On Fri, 31 Mar 2023 06:07:39 GMT, Julian Waters wrote:
> C11 has been stable for a long time on all platforms, so native code can use
> the standard alignas operator for alignment requirements
> I don't think I can touch the freetype code since I think it's an external
> library that was impor
On Fri, 31 Mar 2023 06:07:39 GMT, Julian Waters wrote:
> C11 has been stable for a long time on all platforms, so native code can use
> the standard alignas operator for alignment requirements
I don't have any comments on this change in general (it's not something I've
dealt with in the past),
On Wed, 29 Mar 2023 08:00:36 GMT, Alan Bateman wrote:
>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The
>> APIs that were preview APIs in Java 19/20 are changed to permanent and their
>> `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The
>>
On Wed, 29 Mar 2023 07:27:50 GMT, Alan Bateman wrote:
>> test/jdk/com/sun/management/ThreadMXBean/VirtualThreads.java line 143:
>>
>>> 141: long[] tids = new long[] { tid0, tid1 };
>>> 142: long[] cpuTimes = bean.getThreadCpuTime(tids);
>>> 143: if (Thread.cur
On Wed, 29 Mar 2023 08:00:36 GMT, Alan Bateman wrote:
>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The
>> APIs that were preview APIs in Java 19/20 are changed to permanent and their
>> `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The
>>
On Wed, 8 Mar 2023 11:30:27 GMT, Daniel Jeliński wrote:
> This patch modifies the `getLastErrorString` method to return a `jstring`.
> Thanks to that we can avoid unnecessary back and forth conversions between
> Unicode and other charsets on Windows.
>
> Other changes include:
> - the Windows
On Wed, 8 Mar 2023 11:30:27 GMT, Daniel Jeliński wrote:
> This patch modifies the `getLastErrorString` method to return a `jstring`.
> Thanks to that we can avoid unnecessary back and forth conversions between
> Unicode and other charsets on Windows.
>
> Other changes include:
> - the Windows
On Fri, 3 Mar 2023 16:40:41 GMT, Roger Riggs wrote:
> Remove VMOutOfMemoryException001.java from the problem list, after
> JDK-8303198.
>
> The logging of Runtime.exit interfered with out-of-memory exception handling
> in this test.
> Making the logging more robust in JDK-8303198 by handling e
On Wed, 1 Mar 2023 16:59:51 GMT, Roger Riggs wrote:
>> Consolidate logging and handle exceptions by printing to standard error and
>> ignoring the exception.
>> Exceptions while logging will not interfere with Runtime.exit.
>
> Roger Riggs has updated the pull request incrementally with one addi
On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo wrote:
> Please review this superficial documentation cleanup that was triggered by
> unrelated analysis of doc comments in JDK API.
>
> The only effect that this multi-area PR has on the JDK API Documentation
> (i.e. the observable effect on the ge
On Tue, 24 Jan 2023 20:50:00 GMT, Damon Nguyen wrote:
> Open l10n drop. Files have been updated with translated versions. Whitespace
> tool has been ran on files.
> All tests passed
jdk.console and jdk.management.agent changes look good.
-
Marked as reviewed by cjplummer (Reviewer
On Tue, 3 Jan 2023 19:08:59 GMT, Serguei Spitsyn wrote:
> Michael, I've reviewed the changes but the
> [JDK-8294321](https://bugs.openjdk.org/browse/JDK-8294321) seems to be
> already resolved. So, what JBS issue are you actually trying to fix?
It's closed because #11385 used it to fix some of
On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen wrote:
>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Revert old translation. Fix lang codes
`src/jdk.jdi/share/classes/com/sun/tools` c
On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons wrote:
> Please review a "somewhat automated" change to insert `@spec` tags into doc
> comments, as appropriate, to leverage the recent new javadoc feature to
> generate a new page listing the references to all external specifications
> listed
Fix typo: "and and" => "and"
-
Commit messages:
- fix typo in VirtualMachine.AllThreads
Changes: https://git.openjdk.org/jdk/pull/10895/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10895&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8294672
Stats: 1 line in 1 fi
On Fri, 7 Oct 2022 12:51:26 GMT, Alan Bateman wrote:
>> Michael Ernst has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains six commits:
>>
>> - Reinstate typos in Apache code that is copied into the JDK
>> - Merge ../jdk-openjdk into
On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote:
>> Properties files is essentially source code. It should have the same
>> whitespace checks as all other source code, so we don't get spurious
>> trailing whitespace changes.
>>
>> With the new Skara jcheck, it is possible to increas
On Thu, 20 Oct 2022 18:38:43 GMT, Andy Goryachev wrote:
> `White space following the property value is not ignored, and is treated as
> part of the property value.`
Although I didn't know this was in the spec, I suspected it might be the case.
When looking at the jdk.management.agent changes,
On Thu, 6 Oct 2022 13:39:25 GMT, Alan Bateman wrote:
>> This is a test only change for two tests for virtual threads that
>> hang/timeout on single core systems. The two tests involve pinning and
>> require at least two carrier threads. The test lib used by these tests is
>> updated to define
1 - 100 of 128 matches
Mail list logo
