> 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.getThreadCpuTime` to get the CPU time for all worker
On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request
On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request
On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request
On Thu, 1 Feb 2024 15:54:40 GMT, Matthias Baesken wrote:
>>> @MBaesken So my fix in
>>> [25c691d](https://github.com/openjdk/jdk/pull/17538/commits/25c691df823eb9d9db1451637f28d59dd9508386)
>>> did not help? Maybe then it is some other system library that drags in
>>> `fcntl.h`; I assumed it
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Add
On Thu, 1 Feb 2024 01:38:21 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:
>
> feedback
On Thu, 1 Feb 2024 17:21:23 GMT, Joe Darcy wrote:
> I just suggest double-checking on the current maintenance procedures for the
> java.util.concurrent code.
@jddarcy Any idea how to do that? I tried searching for JSR-166 and
java.util.concurrent, but all I could find was talk about a
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
>
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
On Thu, 1 Feb 2024 18:56:37 GMT, Alex Menkov wrote:
>> src/hotspot/share/prims/jvmtiTagMap.cpp line 453:
>>
>>> 451: InstanceKlass* super_klass = ik->java_super();
>>> 452: if (super_klass != nullptr) {
>>> 453: start_index += add_instance_fields(super_klass, start_index);
>>
>> Does
> 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.
>
On Fri, 2 Feb 2024 00:44:00 GMT, Serguei Spitsyn wrote:
> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the
> spec.
> The function returns the following structure:
>
>
> typedef struct {
> jthread owner;
> jint entry_count;
> jint waiter_count;
>
The implementation of the JVM TI `GetObjectMonitorUsage` does not match the
spec.
The function returns the following structure:
typedef struct {
jthread owner;
jint entry_count;
jint waiter_count;
jthread* waiters;
jint notify_waiter_count;
jthread* notify_waiters;
}
> 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.
>
On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote:
> This is a follow-up on
> [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the
> bin/blessed-modifier-order.sh on the entire code base, and manually checked
> the result. I have reverted all but these trivial
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 Thu, 18 Jan 2024 02:17:56 GMT, Chris Plummer wrote:
> I noticed that "clhsdb jstack" seemed to hang when I attached to process with
> a somewhat large heap. It had taken over 10 minutes when I finally decided to
> have a look at the SA process (using bin/jstack), which came up with the
>
On Wed, 31 Jan 2024 23:07:16 GMT, Chris Plummer wrote:
>> I noticed that "clhsdb jstack" seemed to hang when I attached to process
>> with a somewhat large heap. It had taken over 10 minutes when I finally
>> decided to have a look at the SA process (using bin/jstack), which came up
>> with
On Thu, 1 Feb 2024 07:12:08 GMT, David Holmes wrote:
> Seems fine. Thanks
Trivial?
-
PR Comment: https://git.openjdk.org/jdk/pull/17656#issuecomment-1922036034
On Wed, 31 Jan 2024 23:24:22 GMT, Chris Plummer 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
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.getThreadCpuTime` to get the CPU time for all worker threads.
On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote:
> This is a follow-up on
> [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the
> bin/blessed-modifier-order.sh on the entire code base, and manually checked
> the result. I have reverted all but these trivial
On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote:
> This is a follow-up on
> [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the
> bin/blessed-modifier-order.sh on the entire code base, and manually checked
> the result. I have reverted all but these trivial
On Thu, 1 Feb 2024 12:13:08 GMT, Alan Bateman wrote:
> Can you confirm that you've run tier1-4 at least? Some of the library code
> that is changed here is not tested in the lower tiers.
I have run tier1-4 now, and it passes (bar the tests that are currently failing
in mainline). However,
On Thu, 1 Feb 2024 13:47:45 GMT, Matthias Baesken wrote:
>> After adding this additional patch I fully build fastdebug on AIX (hav to
>> admit it does not look very nice).
>>
>>
>> diff --git
>> a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c
>>
On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote:
> This is a follow-up on
> [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the
> bin/blessed-modifier-order.sh on the entire code base, and manually checked
> the result. I have reverted all but these trivial
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
Magnus Ihse Bursie has updated the pull request with a new target base due to a
merge or a rebase. The pull request now
On Thu, 1 Feb 2024 13:47:45 GMT, Matthias Baesken wrote:
>> After adding this additional patch I fully build fastdebug on AIX (hav to
>> admit it does not look very nice).
>>
>>
>> diff --git
>> a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c
>>
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
On Wed, 31 Jan 2024 09:19:39 GMT, Matthias Baesken wrote:
>> Magnus Ihse Bursie 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 seven
>>
On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote:
> This is a follow-up on
> [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the
> bin/blessed-modifier-order.sh on the entire code base, and manually checked
> the result. I have reverted all but these trivial
On Thu, 1 Feb 2024 09:42:00 GMT, Suchismith Roy wrote:
>> In addition, the nullptr check is important to avoid undefined behavior when
>> passing `pointer_to_dot` to any string function.
>
> Ok. So then may be we can return a nullptr and do a log_info(os) with the
> correct error report ?
On Tue, 30 Jan 2024 14:15:57 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request with
This is a follow-up on
[JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the
bin/blessed-modifier-order.sh on the entire code base, and manually checked the
result. I have reverted all but these trivial and uncontroversial changes.
Almost all of these are about moving
On Wed, 31 Jan 2024 13:17:21 GMT, Suchismith Roy wrote:
>> J2SE agent does not start and throws error when it tries to find the shared
>> library ibm_16_am.
>> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load
>> fails.It fails to identify the shared library
On Thu, 1 Feb 2024 04:17:41 GMT, Martin Doerr wrote:
>> An assertion is only used for debug builds. Such an error should be handled
>> in product builds as well. I think an attempt to load an invalid library
>> should simply fail. You may add logging if needed.
>> @tstuefe: Do you agree or
On Wed, 31 Jan 2024 21:29:14 GMT, Kevin Walls wrote:
>> We have the text "host-or-interface-name" describing the
>> com.sun.management.jmxremote.host property in management.properties, but
>> interface names (like "eth0" or "lo", or "ens3"...) are not what it accepts.
>> It should just say
On Mon, 29 Jan 2024 14:45:24 GMT, Kevin Walls wrote:
> We have the text "host-or-interface-name" describing the
> com.sun.management.jmxremote.host property in management.properties, but
> interface names (like "eth0" or "lo", or "ens3"...) are not what it accepts.
> It should just say it
On Wed, 31 Jan 2024 09:19:39 GMT, Matthias Baesken wrote:
>> Magnus Ihse Bursie 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 seven
>>
40 matches
Mail list logo
