On Tue, 30 Jul 2024 06:54:04 GMT, Kim Barrett wrote:
>> src/hotspot/share/prims/jni.cpp line 1151:
>>
>>> 1149: \
>>> 1150: EntryProbe; \
>>> 1151: ResultType ret{}; \
>>
>> This looks bogus. ResultType is just a macro variable and could be a
>> primitive type. ?? Does the local need initi
On Tue, 30 Jul 2024 04:12:33 GMT, Kim Barrett wrote:
> Please review this change that removes some uses of literal 0 as a null
> pointer constant in prims code.
>
> Testing: mach5 tier1
Okay - looks good. Thanks.
-
Marked as reviewed by dholmes (Reviewer).
PR Review: https://git.
On Tue, 30 Jul 2024 07:16:21 GMT, Kim Barrett wrote:
>> This is value-initialization syntax. Value-initialization of a primitive
>> type is zero-initialization.
>>
>> However, I think we don't need the local variable at all. Here and in the
>> other 5(?) similar places, rather than
>>
>>
On Mon, 29 Jul 2024 19:08:17 GMT, Sonia Zaldana Calles
wrote:
>> Hi all,
>>
>> This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492)
>> enabling jcmd diagnostic commands that issue an output file to accept the
>> `%p` pattern in the file name and substitute it for the PID.
On Tue, 30 Jul 2024 04:12:33 GMT, Kim Barrett wrote:
> Please review this change that removes some uses of literal 0 as a null
> pointer constant in prims code.
>
> Testing: mach5 tier1
All right, this looks fine. (I am somewhat allergic to `{}` syntax, but it is
what it is.)
-
M
On Wed, 3 Jul 2024 13:58:51 GMT, Kevin Walls wrote:
> CmdLine::is_executable() looks wrong, surely an empty line is not executable.
>
> With this change, in DCmd::parse_and_execute() we will avoid needlessly
> entering the code block to try and execute the command.
>
> DCmd tests all good:
> m
On Wed, 3 Jul 2024 13:58:51 GMT, Kevin Walls wrote:
> CmdLine::is_executable() looks wrong, surely an empty line is not executable.
>
> With this change, in DCmd::parse_and_execute() we will avoid needlessly
> entering the code block to try and execute the command.
>
> DCmd tests all good:
> m
On Tue, 30 Jul 2024 01:57:33 GMT, Alex Menkov wrote:
> Obsolete UseNotificationThread flag which was deprecated in JDK 23.
>
> Testing: tier1..tier5
Looks good
-
Marked as reviewed by kevinw (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/20381#pullrequestreview-220737651
On Tue, 30 Jul 2024 06:46:20 GMT, Jiawei Tang wrote:
>> I add the testcase which can reproduce the crash. I hope that I could get
>> some advise if the codes need changing.
>
> Jiawei Tang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> re
On Tue, 30 Jul 2024 06:46:38 GMT, Alan Bateman wrote:
> > Can you convert the test to use .cpp instead of .c as well?
> or maybe it could use VThreadPinner which allows calling through a native
> frame for tests like this.
This is a good suggestion, I was also thinking about it.
An example ca
On Tue, 30 Jul 2024 04:12:33 GMT, Kim Barrett wrote:
> Please review this change that removes some uses of literal 0 as a null
> pointer constant in prims code.
>
> Testing: mach5 tier1
Looks Good!
-
Marked as reviewed by jwaters (Committer).
PR Review: https://git.openjdk.org/jd
On Tue, 30 Jul 2024 06:54:10 GMT, Kim Barrett wrote:
>> src/hotspot/share/prims/methodHandles.cpp line 439:
>>
>>> 437: default:
>>> 438: fatal("unexpected intrinsic id: %d %s", vmIntrinsics::as_int(iid),
>>> vmIntrinsics::name_at(iid));
>>> 439: return 0;
>>
>> Do we no longer need
On Tue, 30 Jul 2024 05:18:17 GMT, Thomas Stuefe wrote:
>> Ashutosh Mehra has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address review comments by Thomas S.
>>
>> Signed-off-by: Ashutosh Mehra
>
> src/hotspot/share/compiler/compil
> Hi all,
>
> This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492)
> enabling jcmd diagnostic commands that issue an output file to accept the
> `%p` pattern in the file name and substitute it for the PID.
>
> This PR addresses the following diagnostic commands:
> - [x] C
On Tue, 30 Jul 2024 14:33:10 GMT, Sonia Zaldana Calles
wrote:
>> Hi all,
>>
>> This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492)
>> enabling jcmd diagnostic commands that issue an output file to accept the
>> `%p` pattern in the file name and substitute it for the PID.
> Some minor improvements to CompilationMemoryStatistic. More details are in
> [JDK-8337031](https://bugs.openjdk.org/browse/JDK-8337031)
>
> Testing:
> test/hotspot/jtreg/compiler/print/CompileCommandPrintMemStat.java
>
> test/hotspot/jtreg/serviceability/dcmd/compiler/CompilerMemoryStatist
On Wed, 24 Jul 2024 10:45:05 GMT, Thomas Stuefe wrote:
>> Some minor improvements to CompilationMemoryStatistic. More details are in
>> [JDK-8337031](https://bugs.openjdk.org/browse/JDK-8337031)
>>
>> Testing:
>> test/hotspot/jtreg/compiler/print/CompileCommandPrintMemStat.java
>>
>> test/
On Tue, 30 Jul 2024 15:02:51 GMT, Ashutosh Mehra wrote:
>> Some minor improvements to CompilationMemoryStatistic. More details are in
>> [JDK-8337031](https://bugs.openjdk.org/browse/JDK-8337031)
>>
>> Testing:
>> test/hotspot/jtreg/compiler/print/CompileCommandPrintMemStat.java
>>
>> test
On Tue, 2 Jul 2024 11:07:56 GMT, Sebastian Lövdahl wrote:
>> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid
>> (Kubernetes debug container)
>
> Sebastian Lövdahl has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Clarify
On Tue, 16 Jul 2024 16:25:50 GMT, Sonia Zaldana Calles
wrote:
> Hi all,
>
> This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492)
> enabling jcmd diagnostic commands that issue an output file to accept the
> `%p` pattern in the file name and substitute it for the PID.
>
> "Attach fails" scenarios (debuggee starts listening and debugger is expected
> to fail trying to attach) sometimes interfere with other JDI tests (so
> JdwpNetProps.java test or other JDI test or both fail).
> The fix disables the scenarios to remove noise in the CI.
Alex Menkov has updated th
On Tue, 30 Jul 2024 15:02:51 GMT, Ashutosh Mehra wrote:
>> Some minor improvements to CompilationMemoryStatistic. More details are in
>> [JDK-8337031](https://bugs.openjdk.org/browse/JDK-8337031)
>>
>> Testing:
>> test/hotspot/jtreg/compiler/print/CompileCommandPrintMemStat.java
>>
>> test
The test has been fixed to:
- add a guard against JVMTI_ERROR_WRONG_PHASE
- replace `exit(err)` with `abort()` in the `check_jvmti_error()`
The JVMTI `VMDeath` event is enabled and a `RawMonitor` is introduced to
prevent JVMTI_ERROR_WRONG_PHASE in the `ClassPrepare` events.
Testing:
- run th
On Tue, 30 Jul 2024 23:13:23 GMT, Serguei Spitsyn wrote:
> The test has been fixed to:
> - add a guard against JVMTI_ERROR_WRONG_PHASE
> - replace `exit(err)` with `abort()` in the `check_jvmti_error()`
>
> The JVMTI `VMDeath` event is enabled and a `RawMonitor` is introduced to
> prevent JV
On Tue, 23 Jul 2024 21:46:50 GMT, Ashutosh Mehra wrote:
> Some minor improvements to CompilationMemoryStatistic. More details are in
> [JDK-8337031](https://bugs.openjdk.org/browse/JDK-8337031)
>
> Testing:
> test/hotspot/jtreg/compiler/print/CompileCommandPrintMemStat.java
>
> test/hotspo
On Wed, 24 Jul 2024 10:45:05 GMT, Thomas Stuefe wrote:
>> Some minor improvements to CompilationMemoryStatistic. More details are in
>> [JDK-8337031](https://bugs.openjdk.org/browse/JDK-8337031)
>>
>> Testing:
>> test/hotspot/jtreg/compiler/print/CompileCommandPrintMemStat.java
>>
>> test/
On Tue, 30 Jul 2024 11:51:37 GMT, Julian Waters wrote:
>> Now that we have, and are using, `[[noreturn]]` on all platforms, we no
>> longer need that dead code.
>
> I'll admit, I do prefer having a return to end all possible control flows in
> a non void method, but oh well
I would rather it n
On Tue, 30 Jul 2024 10:19:59 GMT, Aleksey Shipilev wrote:
> All right, this looks fine. (I am somewhat allergic to `{}` syntax, but it is
> what it is.)
The hoops one had to go through to get guaranteed value-initialization before
we had brace initialization are really
not pretty. See
https://
On Thu, 25 Jul 2024 15:13:29 GMT, Jaikiran Pai wrote:
> Can I please get a review of this test-only backport of the fix that we did
> in master branch a few weeks back?
>
> This isn't a clean backport, there were trivial merge issues in the
> `NativeMethodPrefixApp` test class, which I have re
29 matches
Mail list logo
