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 Wed, 1 May 2024 14:14:22 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 on
>
On Mon, 13 May 2024 11:47:38 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
On Thu, 9 May 2024 07:50:00 GMT, Julian Waters wrote:
>> WIP
>>
>> This changeset contains hsdis for Windows/gcc Port. It supports both the
>> binutils and capstone backends, though the LLVM backend is left out due to
>> compatibility issues encountered during the build. Currently, which gcc
On Mon, 13 May 2024 13:03:26 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).
>
> Found
On Mon, 13 May 2024 21:08:08 GMT, Evgeny Astigeevich
wrote:
> What if instead of backing out we will use an experimental JVM flag:
> `XX:+CompilerDirectivesRefreshSupport`?
I don't think this is correct way to fix the bug.
-
PR Comment:
On Mon, 13 May 2024 20:46:06 GMT, Evgeny Astigeevich
wrote:
> There is a race among a thread updating directives, compiler threads and
> CodeCache cleaning threads. We don't properly lock the directives stack, the
> compile queue and CodeCache to manage the race.
This is indeed concerning.
On Mon, 13 May 2024 21:47:32 GMT, Alex Menkov wrote:
> If debugger attaches to the debuggee, detaches and re-attaches again, are the
> monitors recreated again?
> (with rankedMonitor you added an assert if `DebugRawMonitor::monitor` is not
> null)
Almost all of the debugMonitorCreate() calls
On Mon, 13 May 2024 18:32:45 GMT, Chris Plummer wrote:
>> FWIW Deleting monitors is a tricky business and needs to be done with great
>> care. You have to ensure all threads using the monitor are completely done
>> with it. Simply locking it first to check it is "unused" is not sufficient.
>
>
On Mon, 13 May 2024 13:03:26 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).
>
> Found
On Mon, 13 May 2024 16:29:35 GMT, Vladimir Kozlov wrote:
> How you found these issues?
I've been backporting JDK-8309271 to downstream 17 and 21. As compilations
happens in background but a test from JDK-8309271 runs with background
compilation off, I asked myself what might happen with
On Mon, 13 May 2024 13:03:26 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).
>
> Found
On Mon, 13 May 2024 19:30:31 GMT, Nizar Benalla wrote:
>> Please review this simple change where I add "@ since" tags to the
>> package-info file of the following packages
>>
>> com.sun.jdi
>> com.sun.jdi.connect
>> com.sun.jdi.connect.spi
>> com.sun.jdi.event
>> com.sun.jdi.request
>>
>> I
On Mon, 13 May 2024 16:29:35 GMT, Vladimir Kozlov wrote:
> do you have tests which shows issues you listed in description?
Here is a jtreg test:
- `refresh_control.02.txt`
[
{
match: "serviceability.dcmd.compiler.DirectivesRefreshTest::callable",
c2: {
PrintOptoAssembly: true
On Mon, 13 May 2024 19:30:31 GMT, Nizar Benalla wrote:
>> Please review this simple change where I add "@ since" tags to the
>> package-info file of the following packages
>>
>> com.sun.jdi
>> com.sun.jdi.connect
>> com.sun.jdi.connect.spi
>> com.sun.jdi.event
>> com.sun.jdi.request
>>
>> I
> Please review this simple change where I add "@ since" tags to the
> package-info file of the following packages
>
> com.sun.jdi
> com.sun.jdi.connect
> com.sun.jdi.connect.spi
> com.sun.jdi.event
> com.sun.jdi.request
>
> I used the unix grep command to find the oldest "@ since" in each
On Sun, 12 May 2024 01:58:38 GMT, Nizar Benalla wrote:
> Please review this simple change where I add `@since` tags to the
> package-info file of the following packages
> ```com.sun.jdi
> com.sun.jdi.connect
> com.sun.jdi.connect.spi
> com.sun.jdi.event
> com.sun.jdi.request
>
> I used the
On Thu, 9 May 2024 12:32:12 GMT, Serguei Spitsyn wrote:
>> But 2 and 1 are very different. You can call them both leaf violations, but
>> they are leaf violations for very different reasons, and 2 is more akin to a
>> rank violation than a leaf violation.
>>
>> I'm reversing the ranks and
On Thu, 9 May 2024 21:40:42 GMT, David Holmes wrote:
>> I guess there could be a race if one thread is destroying this monitor while
>> another is trying to use it. Thus a thread could be doing something like a
>> RawMonitorEnter in the middle of (or after) the monitor being destroyed.
>>
On Mon, 13 May 2024 04:55:24 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 Sun, 12 May 2024 03:04:45 GMT, Lei Zaakjyu wrote:
> Should we also rename 'HeapRegionType' to 'G1HeapRegionType', then rename the
> current 'G1HeapRegionType' to 'G1 HeapRegionTypeEnum'?
For this PR the SA renames should match the hotspot renames. It looks like you
have not renamed this in
On Sat, 11 May 2024 11:12:44 GMT, Lei Zaakjyu wrote:
> > I noticed that the HeapRegionManager and HeapRegionClosure classes were not
> > renamed (in the hotspot source). Is this intentional or an oversite?
>
> OK, I will do all the SA part here. However, I do think that the other
> classes
On Mon, 13 May 2024 14:42:26 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 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 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:36:13 GMT, Stefan Karlsson wrote:
>> To quote @robehn - Why write a comment for a rule if you can enforce it with
>> code instead...
>
> 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"
On Mon, 13 May 2024 11:47:38 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
On Mon, 13 May 2024 15:26:18 GMT, Daniel D. Daugherty
wrote:
>> Could you instead put the static_assert near the code that will break? Right
>> now it looks obscure and weird to have this check when it is obviously
>> correct as long as no one changes the definition. Would it be enough to
>>
On Mon, 13 May 2024 14:44:05 GMT, Stefan Karlsson wrote:
>> I rather have this explicit check. If MEMFLAGS>1byte, things break, and I
>> would like to make that explicit.
>>
>> That said, I can move this static assert to the header. I just wanted to
>> avoid including debug.hpp. My original
On Mon, 13 May 2024 14:31:22 GMT, Thomas Stuefe wrote:
>> src/hotspot/share/nmt/memflags.cpp line 31:
>>
>>> 29:
>>> 30: // Extra insurance that MEMFLAGS truly has the same size as uint8_t.
>>> 31: STATIC_ASSERT(sizeof(MEMFLAGS) == sizeof(uint8_t));
>>
>> I think you can remove this entire
On Mon, 13 May 2024 13:03:26 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).
>
> Found
On Mon, 13 May 2024 14:34:50 GMT, Dmitry Chuyko wrote:
> So there are cases when new functionality doesn't work as expected (I don't
> see any other users impacted). Why not file bugs for those cases and estimate
> their impact?
Do you know any users using the new functionality?
On Mon, 13 May 2024 14:21:35 GMT, Evgeny Astigeevich
wrote:
> > Are there any high severity problems caused by the original PR? Especially
> > not in the new functionality. Minor issues could be probably addressed
> > without backing out the entire functionality.
>
>
>
> Yes, there are:
>
On Mon, 13 May 2024 10:13:50 GMT, Stefan Karlsson wrote:
>> Thomas Stuefe has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update mallocLimit.hpp
>
> src/hotspot/share/nmt/memflags.cpp line 31:
>
>> 29:
>> 30: // Extra insurance that
On Mon, 13 May 2024 10:16:36 GMT, Stefan Karlsson wrote:
>> Thomas Stuefe has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update mallocLimit.hpp
>
> src/hotspot/share/nmt/memflags.hpp line 30:
>
>> 28: #include
On Mon, 13 May 2024 13:52:17 GMT, Dmitry Chuyko wrote:
> Are there any high severity problems caused by the original PR? Especially
> not in the new functionality. Minor issues could be probably addressed
> without backing out the entire functionality.
Yes, there are:
> 1. Usually directives
On Mon, 13 May 2024 11:47:38 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
On Mon, 13 May 2024 13:03:26 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).
>
> Found
On Mon, 13 May 2024 11:47:38 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
On Mon, 13 May 2024 11:47:38 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
Backout of [JDK-8309271](https://bugs.openjdk.org/browse/JDK-8309271) which has
known bugs, possible bugs and performance issues.
Found bugs:
- When refreshing `CompilerDirectivesAddDCmd::execute` will call
`DirectivesStack::hasMatchingDirectives(mh, true)` which only considers the
compiler
On Mon, 13 May 2024 13:03:26 GMT, Evgeny Astigeevich
wrote:
> Backout of [JDK-8309271](https://bugs.openjdk.org/browse/JDK-8309271) which
> has known bugs, possible bugs and performance issues.
>
> Found bugs:
> - When refreshing `CompilerDirectivesAddDCmd::execute` will call
>
On Thu, 9 May 2024 08:18:41 GMT, David Holmes wrote:
>> Please review this mechanical change to man pages. This PR should be
>> integrated after https://github.com/openjdk/jdk/pull/18787.
>
> src/java.base/share/man/java.1 line 3856:
>
>> 3854: .SH REMOVED JAVA OPTIONS
>> 3855: .PP
>> 3856:
> 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`
> 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 Mon, 13 May 2024 11:38:40 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
On Mon, 13 May 2024 10:42:26 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
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` method
On Mon, 13 May 2024 04:55:24 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 Sun, 12 May 2024 06:01:27 GMT, Lei Zaakjyu wrote:
>> follow up 8267941
>
> Lei Zaakjyu has updated the pull request incrementally with one additional
> commit since the last revision:
>
> fix
I'm good with leaving the `heapRegionIterator()` method name as is, but please
make sure that
On Sun, 12 May 2024 01:58:38 GMT, Nizar Benalla wrote:
> Please review this simple change where I add `@since` tags to the
> package-info file of the following packages
> ```com.sun.jdi
> com.sun.jdi.connect
> com.sun.jdi.connect.spi
> com.sun.jdi.event
> com.sun.jdi.request
>
> I used the
On Mon, 13 May 2024 04:55:24 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
52 matches
Mail list logo
