> This PR adds G1 support to PointerFinder/PointerLocation. Previously we only
> had SerialGC support. Previously for G1 addresses SA would only report that
> the address is "In unknown section of Java heap" with no other details. Now
> it provides details for G1 addresses. Here are some example
On Sat, 3 Feb 2024 00:44:42 GMT, Serguei Spitsyn wrote:
>> Alex Menkov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> indent
>
> test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp
> line 64:
>
> The fix adds new test for FollowReferences JVMTI function to verify
> correctness of reported field indexes.
Alex Menkov has updated the pull request incrementally with one additional
commit since the last revision:
indent
-
Changes:
- all: https://git.openjdk.org/jdk/pull/1
On Fri, 2 Feb 2024 23:10:32 GMT, Alex Menkov wrote:
>> The fix adds new test for FollowReferences JVMTI function to verify
>> correctness of reported field indexes.
>
> Alex Menkov has updated the pull request incrementally with one additional
> commit since the last revision:
>
> indent
Ma
On Sat, 3 Feb 2024 00:14:15 GMT, Alex Menkov wrote:
>> FilteredFieldStream used by heap walking functions to iterate through
>> klass/superclasses/interfaces fields are known to have poor performance (see
>> [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details).
>> Heap walkin
On Fri, 2 Feb 2024 08:05:06 GMT, Serguei Spitsyn wrote:
>> Alex Menkov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> jcheck
>
> src/hotspot/share/prims/jvmtiTagMap.cpp line 499:
>
>> 497: }
>> 498: // update total_field_number
> FilteredFieldStream used by heap walking functions to iterate through
> klass/superclasses/interfaces fields are known to have poor performance (see
> [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details).
> Heap walking API implementation is the last user of the klasses.
> Th
This PR adds G1 support to PointerFinder/PointerLocation. Previously we only
had SerialGC support. Previously for G1 addresses SA would only report that the
address is "In unknown section of Java heap" with no other details. Now it
provides details for G1 addresses. Here are some examples for cl
On Fri, 2 Feb 2024 06:47:22 GMT, Serguei Spitsyn wrote:
>> Alex Menkov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> feedback
>
> test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp
> line 512
> The fix adds new test for FollowReferences JVMTI function to verify
> correctness of reported field indexes.
Alex Menkov has updated the pull request incrementally with one additional
commit since the last revision:
indent
-
Changes:
- all: https://git.openjdk.org/jdk/pull/1
Hi Kevin,
Having a clear command spec to read and argue about would be helpful,
especially since this is not a simple commnd but a whole command group.
Exposing such a low level interface (this is supposed to go into product
VMs, right?) may carry some risks that could arguably fall unter CSR.
T
On Thu, 18 Jan 2024 22:54:26 GMT, Chris Plummer wrote:
> In PointerFinder.java we have some code to determine if a pointer is in a
> TLAB, but it only executes for the SerialGC. It should work for all GCs, so I
> moved the code out of the SerialGC block.
>
> I also cleaned up the printing in P
On Fri, 26 Jan 2024 21:20:04 GMT, Chris Plummer wrote:
>> In PointerFinder.java we have some code to determine if a pointer is in a
>> TLAB, but it only executes for the SerialGC. It should work for all GCs, so
>> I moved the code out of the SerialGC block.
>>
>> I also cleaned up the printing
On Wed, 31 Jan 2024 14:22:44 GMT, Kevin Walls wrote:
> Introduce the jcmd "VM.debug" to implement access to a useful set of the
> established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...".
>
> Not recommended for live production use. Calling these "debug" utilities,
> and not i
On Thu, 1 Feb 2024 15:47:24 GMT, Ludvig Janiuk wrote:
>> Introduce the jcmd "VM.debug" to implement access to a useful set of the
>> established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...".
>>
>> Not recommended for live production use. Calling these "debug" utilities,
>> and
Introduce the jcmd "VM.debug" to implement access to a useful set of the
established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...".
Not recommended for live production use. Calling these "debug" utilities, and
not including them in the jcmd help output, is to remind us they are n
On Wed, 31 Jan 2024 14:22:44 GMT, Kevin Walls wrote:
> Introduce the jcmd "VM.debug" to implement access to a useful set of the
> established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...".
>
> Not recommended for live production use. Calling these "debug" utilities,
> and not i
On Fri, 2 Feb 2024 16:34:19 GMT, Kim Barrett wrote:
> Please review this trivial change that renames the file
> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_FollowRefObjects.h
> to jvmti_FollowRefObjects.hpp, and replaces uses of NULL in the file.
>
> Testing: mach5 tier1
Looks good.
--
Please review this trivial change that renames the file
test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_FollowRefObjects.h
to jvmti_FollowRefObjects.hpp, and replaces uses of NULL in the file.
Testing: mach5 tier1
-
Commit messages:
- rename NULLs in jvmti_FollwRefObjects.hpp
-
On Wed, 31 Jan 2024 15:08:14 GMT, Kim Barrett wrote:
> Please review this trivial change that renames the file
> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/Injector.h to Injector.hpp.
>
> Testing: mach5 tier1
This pull request has now been integrated.
Changeset: 6787c4c3
Author:Kim Barr
On Thu, 1 Feb 2024 07:12:08 GMT, David Holmes wrote:
>> Kim Barrett 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 three additional
>> commits
> Please review this trivial change that renames the file
> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/Injector.h to Injector.hpp.
>
> Testing: mach5 tier1
Kim Barrett has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the unrelated
On Fri, 2 Feb 2024 07:01:33 GMT, Sam James wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add kludge to BufferedRenderPipe.c for AIX
>
> make/modules/jdk.hotspot.agent/Lib.gmk line 31:
>
>> 29:
>> 30: ifeq
On Fri, 2 Feb 2024 15:48:04 GMT, Magnus Ihse Bursie wrote:
>> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 365:
>>
>>> 363: #else
>>> 364: // Make sure we link to the 64-bit version of the functions
>>> 365: my_openat_func = (openat_func*) dlsym(RTLD_DEFAULT, "openat64
On Fri, 2 Feb 2024 07:02:43 GMT, Sam James wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add kludge to BufferedRenderPipe.c for AIX
>
> src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c line 94:
>
On Fri, 2 Feb 2024 07:38:24 GMT, Doug Simon wrote:
>> The `com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java` can
>> transiently fail when run with `-Xcomp`. This happens when the compilation
>> of methods on the worker threads interleaves with the 2 calls on the main
>> thread to `mbean
On Fri, 2 Feb 2024 10:48:26 GMT, Kevin Walls wrote:
> Or maybe they are not done the initial -Xcomp compile and
> waitUntilThreadBlocked() is mistakenly thinking they are now idle...
Yes, I believe this is the case.
It's not really clear to me what the test is testing. As far as I can see, if
On Fri, 2 Feb 2024 07:38:24 GMT, Doug Simon wrote:
>> The `com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java` can
>> transiently fail when run with `-Xcomp`. This happens when the compilation
>> of methods on the worker threads interleaves with the 2 calls on the main
>> thread to `mbean
On Thu, 1 Feb 2024 18:25:33 GMT, Doug Simon wrote:
> The `com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java` can transiently
> fail when run with `-Xcomp`. This happens when the compilation of methods on
> the worker threads interleaves with the 2 calls on the main thread to
> `mbean.get
On Fri, 2 Feb 2024 07:38:24 GMT, Doug Simon wrote:
>> The `com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java` can
>> transiently fail when run with `-Xcomp`. This happens when the compilation
>> of methods on the worker threads interleaves with the 2 calls on the main
>> thread to `mbean
On Fri, 2 Feb 2024 07:38:24 GMT, Doug Simon wrote:
>> The `com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java` can
>> transiently fail when run with `-Xcomp`. This happens when the compilation
>> of methods on the worker threads interleaves with the 2 calls on the main
>> thread to `mbean
On Wed, 31 Jan 2024 15:15:16 GMT, Kim Barrett wrote:
>> Please review this trivial change that renames the file
>> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/Injector.h to Injector.hpp.
>>
>> Testing: mach5 tier1
>
> Kim Barrett has updated the pull request incrementally with one additional
On Fri, 26 Jan 2024 21:20:04 GMT, Chris Plummer wrote:
>> In PointerFinder.java we have some code to determine if a pointer is in a
>> TLAB, but it only executes for the SerialGC. It should work for all GCs, so
>> I moved the code out of the SerialGC block.
>>
>> I also cleaned up the printing
On Fri, 2 Feb 2024 02:49:13 GMT, Alex Menkov wrote:
>> FilteredFieldStream used by heap walking functions to iterate through
>> klass/superclasses/interfaces fields are known to have poor performance (see
>> [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details).
>> Heap walkin
34 matches
Mail list logo
