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 Mon, 5 Feb 2024 09:25:24 GMT, Yi Yang wrote:
> jcmd VM.debug MyDebugCode.java
Are you thinking to run some Java code in the target JVM?
VM.debug as presented here is all about inspecting JVM state, mostly using
existing mechanisms but which were not already exposed in jcmd. I think this
On Mon, 5 Feb 2024 12:07:45 GMT, Matthias Baesken wrote:
> Current commit compiles nicely on AIX. One issue we might still have
> statvfs/statvfs64 is not mentioned here in the table of functions/structs
> redefined on AIX
>
On Mon, 5 Feb 2024 07:21:05 GMT, Alan Bateman wrote:
> ...needs wider review and a CSR should be submitted for this.
Sure no problem I will refresh the linked CSR.
-
PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-1926513588
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 Mon, 5 Feb 2024 12:17:33 GMT, Joachim Kern wrote:
> Yes, if statvfs64() is replaced by statvfs() in the code, we will fallback on
> AIX to 32-Bit. _LARGE_FILES really does not help in this case!
Thanks for confirming. I think we do not want to fallback on AIX, so the <*>64
variant needs to
> 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 ibm_16_am.a shared archive file
> on AIX.
> Hence we are providing a
On Fri, 2 Feb 2024 02:22:54 GMT, David Holmes 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;
>>
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 Mon, 5 Feb 2024 12:38:03 GMT, Magnus Ihse Bursie wrote:
> It seems like the statvfs64 is a pre-existing bug in AIX in that case. I have
> not removed any statvfs64 for AIX; all such changes are guarded by `#ifdef
> _ALLBSD_SOURCE`, which I presume is not defined on AIX.
>
> I recommend
Hi Thomas -
Yes, it goes into all builds, and yes this is a new jcmd with sub-commands,
you could call it a group. It's not a large group of commands, and the
commands themselves are not exactly new (but no objection to a CSR).
Getting these debug utilities into a jcmd is about making them
On Mon, 5 Feb 2024 09:01:06 GMT, Martin Doerr wrote:
>> Suchismith Roy has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Change logging
>
> src/hotspot/os/aix/os_aix.cpp line 1183:
>
>> 1181: // If the load fails,we try to reload by
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 Mon, 5 Feb 2024 08:52: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 Wed, 31 Jan 2024 11:22:27 GMT, Joachim Kern wrote:
>> The load library gets the entire library name, after construction from
>> dll_build_name. This is always a .so file name. When .so file name fails to
>> load, we fallback to .a filename.
>> Do i need to mention the filename as
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
On Sun, 4 Feb 2024 23:07:27 GMT, David Holmes wrote:
> > not including them in the jcmd help output, is to remind us they are not
> > general customer-facing tools.
>
> Then who are they for? and do they really belong in the `jcmd` tool, or is
> that just convenient?
>
> Without help
On Mon, 5 Feb 2024 14:03:45 GMT, Magnus Ihse Bursie wrote:
> I hope finally the AIX part of this PR is done.
Thanks for the AIX related effort ; I put it again into our internal build/test
queue.
-
PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1927105669
On 2/5/24 1:56 AM, Kevin Walls wrote:
On Mon, 5 Feb 2024 09:25:24 GMT, Yi Yang wrote:
jcmd VM.debug MyDebugCode.java
Are you thinking to run some Java code in the target JVM?
VM.debug as presented here is all about inspecting JVM state, mostly using
existing mechanisms but which were
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
Marked as
On Tue, 30 Jan 2024 10:47:22 GMT, Sebastian Lövdahl wrote:
> 8307977: jcmd and jstack broken for target processes running with elevated
> capabilities
This looks good to me, but would like for somebody from the serviceability
group to look at this as well. @plummercj perhaps?
> _Mailing list
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 Tue, 28 Mar 2023 17:36:33 GMT, Chris Plummer wrote:
>> According to [the
>> specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader))
>> trailing whitespaces in the values of properties files are (somewhat
>> surprisingly)
On Tue, 28 Mar 2023 17:36:33 GMT, Chris Plummer wrote:
> What was the reason for not moving forward with this PR?
Me going on medical leave most of 2023... :-/
I intend to get this done now.
-
PR Comment: https://git.openjdk.org/jdk/pull/11490#issuecomment-1927376112
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
> 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 Mon, 5 Feb 2024 16:53:54 GMT, Magnus Ihse Bursie wrote:
>> According to [the
>> specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader))
>> trailing whitespaces in the values of properties files are (somewhat
>>
> According to [the
> specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader))
> trailing whitespaces in the values of properties files are (somewhat
> surprisingly) actually significant.
>
> We have multiple files in the JDK
> According to [the
> specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader))
> trailing whitespaces in the values of properties files are (somewhat
> surprisingly) actually significant.
>
> We have multiple files in the JDK
On Wed, 31 Jan 2024 21:28:34 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 walking
> According to [the
> specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader))
> trailing whitespaces in the values of properties files are (somewhat
> surprisingly) actually significant.
>
> We have multiple files in the JDK
On Mon, 5 Feb 2024 16:53:33 GMT, Magnus Ihse Bursie wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Restore period
>
> src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ko.properties
On Mon, 5 Feb 2024 21:51:02 GMT, Magnus Ihse Bursie wrote:
>> According to [the
>> specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader))
>> trailing whitespaces in the values of properties files are (somewhat
>>
On Mon, 5 Feb 2024 19:48:14 GMT, Chris Plummer wrote:
>> src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ko.properties
>> line 27:
>>
>>> 25:
>>> 26: agent.err.error= 오류
>>> 27: agent.err.exception= 에이전트에 예외사항이 발생했습니다.
>>
>> I
On Thu, 25 Jan 2024 23:05:19 GMT, Alex Menkov wrote:
> The fix adds new test for FollowReferences JVMTI function to verify
> correctness of reported field indexes.
This pull request has now been integrated.
Changeset: f31957e6
Author:Alex Menkov
URL:
On Sun, 4 Feb 2024 22:43:28 GMT, David Holmes wrote:
> This update drops the "ea" from the version string.
>
> We also propagate the following fixes from the markdown sources to the troff
> manpage file:
>
> JDK-8322478: Update java manpage for multi-file source-code launcher
> JDK-8302233:
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
Marked as
On Sun, 4 Feb 2024 22:43:28 GMT, David Holmes wrote:
> This update drops the "ea" from the version string.
>
> We also propagate the following fixes from the markdown sources to the troff
> manpage file:
>
> JDK-8322478: Update java manpage for multi-file source-code launcher
> JDK-8302233:
On Mon, 5 Feb 2024 21:58:23 GMT, Joe Darcy wrote:
>> This update drops the "ea" from the version string.
>>
>> We also propagate the following fixes from the markdown sources to the troff
>> manpage file:
>>
>> JDK-8322478: Update java manpage for multi-file source-code launcher
>>
On Sun, 4 Feb 2024 22:43:28 GMT, David Holmes wrote:
> This update drops the "ea" from the version string.
>
> We also propagate the following fixes from the markdown sources to the troff
> manpage file:
>
> JDK-8322478: Update java manpage for multi-file source-code launcher
> JDK-8302233:
> 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;
>
41 matches
Mail list logo
