On Mon, 13 May 2024 15:32:27 GMT, Alan Bateman wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Fix another typo
>> - Fix typo
>> - Add more comments
>
> src/hotspot/share/runtime/arguments.cpp line
On Tue, 14 May 2024 18:10:28 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and
Hello,
I discovered after some recent work around javadoc that `javac` does not
recognize `package.html` files, which predate `package-info.java`. Some tools
that want to analyze doc comments need to deal with this in special ways.
Maybe optional support for these files can be added into
> The fix is to degrade virtual threads support in the JVM TI
> `GetObjectMonitorUsage` function so that it is specified to only return an
> owner when the owner is a platform thread. Also, virtual threads are not
> listed in the both `waiters` and `notify_waiters` lists returned in the
>
On Wed, 1 May 2024 20:45:58 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: tweaks in JVMTI and JDWP changes
>
> src/jdk.jdi/share/classes/com/sun/jdi/ObjectReference.java line 348:
>
On Thu, 2 May 2024 21:50:26 GMT, Chris Plummer wrote:
>> src/java.se/share/data/jdwp/jdwp.spec line 1622:
>>
>>> 1620: (threadObject owner "The platform thread owning this
>>> monitor, or nullptr "
>>> 1621: "if owned` by a virtual thread or not
>>>
On Tue, 14 May 2024 23:13:28 GMT, Serguei Spitsyn wrote:
>> I don't understand the issue with the updated commented. It is precisely
>> telling you what the expected "count" values should be. If you leave the
>> macros in the comment, then the comment is wrong for virtual threads. If you
>>
On Tue, 14 May 2024 17:51:03 GMT, Chris Plummer wrote:
>>> expEnteringCount/expWaitingCount contain the tested patterns.
>>
>> I kind of disagree.
>> Please, take look at the loop below:
>>
>> for (int i = 0; i < NUMBER_OF_WAITING_THREADS; i++) {
>> expEnteringCount
On Tue, 14 May 2024 22:19:19 GMT, Leonid Mesnik wrote:
>> The nsk.share.Log doing some cleanup and reporting errors in the cleanup
>> method. This method is supposed to be executed by finalizer originally.
>> However, now it is called only during shutdown hook.
>> The cleanup using Cleaner
> The nsk.share.Log doing some cleanup and reporting errors in the cleanup
> method. This method is supposed to be executed by finalizer originally.
> However, now it is called only during shutdown hook.
> The cleanup using Cleaner doesn't work. See
>
On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo wrote:
> Please review this mechanical change to man pages. This PR should be
> integrated after https://github.com/openjdk/jdk/pull/18787.
This pull request has been closed without being integrated.
-
PR:
On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo wrote:
> Please review this mechanical change to man pages. This PR should be
> integrated after https://github.com/openjdk/jdk/pull/18787.
Withdrawing this, as a different approach is required.
-
PR Comment:
On Sun, 12 May 2024 21:34:41 GMT, Leonid Mesnik wrote:
> The nsk.share.Log doing some cleanup and reporting errors in the cleanup
> method. This method is supposed to be executed by finalizer originally.
> However, now it is called only during shutdown hook.
> The cleanup using Cleaner
> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
> the use of JNI in the following ways:
>
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
> * binding a JNI `native`
On Fri, 3 May 2024 10:42:45 GMT, Serguei Spitsyn wrote:
>> ...and there are also comments above with this issue.
>
>> expEnteringCount/expWaitingCount contain the tested patterns.
>
> I kind of disagree.
> Please, take look at the loop below:
>
> for (int i = 0; i <
On Fri, 10 May 2024 09:06:08 GMT, Thomas Stuefe wrote:
> MEMFLAGS, as well as its enum constants, should live in its own include.
>
> The constants are used throughout the code base, often without needing the
> allocation APIs exposed through allocation.hpp.
>
> The MEMFLAGS enum def is
On Tue, 14 May 2024 07:19:32 GMT, Thomas Stuefe wrote:
>> MEMFLAGS, as well as its enum constants, should live in its own include.
>>
>> The constants are used throughout the code base, often without needing the
>> allocation APIs exposed through allocation.hpp.
>>
>> The MEMFLAGS enum def
On Tue, 14 May 2024 07:19:32 GMT, Thomas Stuefe wrote:
>> MEMFLAGS, as well as its enum constants, should live in its own include.
>>
>> The constants are used throughout the code base, often without needing the
>> allocation APIs exposed through allocation.hpp.
>>
>> The MEMFLAGS enum def
On Mon, 13 May 2024 21:08:08 GMT, Evgeny Astigeevich
wrote:
>> Backout of [JDK-8309271](https://bugs.openjdk.org/browse/JDK-8309271) which
>> has known bugs, possible bugs and performance issues. REDO work is tracked
>> by [JDK-8331749](https://bugs.openjdk.org/browse/JDK-8331749).
>>
>>
On Tue, 14 May 2024 01:53:20 GMT, Alex Menkov wrote:
>> The fix updates descriptions of `HeapDumpPath`/`HeapDumpGzipLevel` and
>> `HeapDumpBeforeFullGC`/`HeapDumpAfterFullGC`/`HeapDumpOnOutOfMemoryError` VM
>> options
>
> Alex Menkov has updated the pull request incrementally with one
On Tue, 14 May 2024 01:53:20 GMT, Alex Menkov wrote:
>> The fix updates descriptions of `HeapDumpPath`/`HeapDumpGzipLevel` and
>> `HeapDumpBeforeFullGC`/`HeapDumpAfterFullGC`/`HeapDumpOnOutOfMemoryError` VM
>> options
>
> Alex Menkov has updated the pull request incrementally with one
On Sun, 12 May 2024 21:34:41 GMT, Leonid Mesnik wrote:
> The nsk.share.Log doing some cleanup and reporting errors in the cleanup
> method. This method is supposed to be executed by finalizer originally.
> However, now it is called only during shutdown hook.
> The cleanup using Cleaner
On Mon, 13 May 2024 15:53:26 GMT, Leonid Mesnik wrote:
> Every log (as any Finalazible object) is registered using registerCleanup()
But you have changed Log so it is no longer a FinalizableObject. ?? Ah I see
this is what you meant by disabling it. Now a Log is a plain old Java object
with
On Mon, 13 May 2024 10:17:57 GMT, Stefan Karlsson wrote:
>> Thomas Stuefe has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update mallocLimit.hpp
>
> Changes requested by stefank (Reviewer).
@stefank New version, hopefully addressed all
> MEMFLAGS, as well as its enum constants, should live in its own include.
>
> The constants are used throughout the code base, often without needing the
> allocation APIs exposed through allocation.hpp.
>
> The MEMFLAGS enum def is often needed within NMT itself, again often without
>
On Mon, 13 May 2024 15:48:43 GMT, Stefan Karlsson wrote:
>> I tend to agree with that. My earlier question still stands: is there a
>> better place to put it? Right now the "enforced with code" in a stand-alone
>> file doesn't tell me "why" this rule is important.
>
> If you want to keep the
On Mon, 13 May 2024 14:47:18 GMT, Stefan Karlsson wrote:
>> I don't feel like starting that particular bike shedding discussion :) But
>> sure, sometime in the future we should do this. Here, I want it to be a
>> simple renaming change.
>
> Right. That's why I prefixed this with "Open-ended
On Wed, 8 May 2024 01:19:05 GMT, SendaoYan wrote:
>> Hi,
>> GHA
>> [runner](https://github.com/sendaoYan/jdk-ysd/actions/runs/8881868940/job/24386063136)
>> shows that serviceability/dcmd/gc/RunFinalizationTest.java intermittent
>> fail on macos-aarch64. The testcase has been problemlisted
28 matches
Mail list logo
