On Wed, 21 Aug 2024 22:27:27 GMT, David Holmes wrote:
>> I want to provide advice for how this API should be used.
>>
>> The "recent period of time observed" is vague (Who's the observer? Who
>> decides the "recent period"? The API user or the JVM?). In essence it is the
>> time between two co
On Thu, 22 Aug 2024 02:46:34 GMT, David Holmes wrote:
> Sorry but I don't understand the point of changing build-time constructs
> using `ifdef STATIC_BUILD` into what appear to be runtime checks, but the
> result of which is already determined at build time. These are not really
> runtime che
On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie wrote:
>> As a preparation for Hermetic Java, we need to have a way to look up during
>> runtime if we are using a statically linked library or not.
>>
>> This change will be the first step needed towards compiling the object files
>> only o
On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie wrote:
>> As a preparation for Hermetic Java, we need to have a way to look up during
>> runtime if we are using a statically linked library or not.
>>
>> This change will be the first step needed towards compiling the object files
>> only o
On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie wrote:
>> As a preparation for Hermetic Java, we need to have a way to look up during
>> runtime if we are using a statically linked library or not.
>>
>> This change will be the first step needed towards compiling the object files
>> only o
On Wed, 21 Aug 2024 13:49:08 GMT, Joakim Nordström
wrote:
>> Ok yes maybe "not idempotent" isn't a great term here.
>> Just removing that phrase, "This method is not idempotent.", this would
>> still be a helpful update.
>
> I want to provide advice for how this API should be used.
>
> The "re
> As a preparation for Hermetic Java, we need to have a way to look up during
> runtime if we are using a statically linked library or not.
>
> This change will be the first step needed towards compiling the object files
> only once, and then link them into either dynamic or static libraries. (T
As a preparation for Hermetic Java, we need to have a way to look up during
runtime if we are using a statically linked library or not.
This change will be the first step needed towards compiling the object files
only once, and then link them into either dynamic or static libraries. (The
only e
On Wed, 21 Aug 2024 14:54:40 GMT, Simon Tooke wrote:
>> This is a port of [JDK-8318636](https://github.com/openjdk/jdk/pull/16301)
>> to Windows.
>>
>> System.map and System.dump_map are implemented using the Windows API and
>> provide roughly the same information in the same format. Most of
On Mon, 29 Jul 2024 14:18:24 GMT, Severin Gehwolf wrote:
>> Please review this fix for cgroups-based metrics reporting in the
>> `jdk.internal.platform` package. This fix is supposed to address wrong
>> reporting of certain limits if the limits aren't set at the leaf nodes.
>>
>> For example,
> Please review this fix for cgroups-based metrics reporting in the
> `jdk.internal.platform` package. This fix is supposed to address wrong
> reporting of certain limits if the limits aren't set at the leaf nodes.
>
> For example, on cg v2, the memory limit interface file is `memory.max`.
> Co
On Wed, 21 Aug 2024 14:54:40 GMT, Simon Tooke wrote:
>> This is a port of [JDK-8318636](https://github.com/openjdk/jdk/pull/16301)
>> to Windows.
>>
>> System.map and System.dump_map are implemented using the Windows API and
>> provide roughly the same information in the same format. Most of
> This is a port of [JDK-8318636](https://github.com/openjdk/jdk/pull/16301) to
> Windows.
>
> System.map and System.dump_map are implemented using the Windows API and
> provide roughly the same information in the same format. Most of the heavy
> lifting was implemented by @tstuefe in #16301 -
On Tue, 20 Aug 2024 10:07:26 GMT, Roman Kennke wrote:
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All
> changes in this PR are protected by this flag. The purpose of the fl
On Wed, 21 Aug 2024 13:18:03 GMT, Roman Kennke wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> Main changes:
>> - Introduction of the (experimental) flag UseCompactObjectHeaders. All
>> changes in this PR are protected by this flag. The purpose of t
On Wed, 21 Aug 2024 13:42:18 GMT, Joakim Nordström
wrote:
>> Can I get a review of this documentation update to clarify the usage of
>> GetCpuLoad (and inherently deprecated GetSystemCpuLoad) and
>> GetProcessCpuLoad.
>>
>> Calling either of these methods in quick succession can lead to
>> u
On Tue, 20 Aug 2024 10:07:26 GMT, Roman Kennke wrote:
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All
> changes in this PR are protected by this flag. The purpose of the fl
On Wed, 21 Aug 2024 12:25:48 GMT, Kevin Walls wrote:
>> You beat me to it. We specify some methods (close, dispose, ...) as
>> idempotent. Specifying a getter as non-idempotent looks very strange here.
>>
>> I can't tell if you are looking to specify implementation behavior (as David
>> asks)
> Can I get a review of this documentation update to clarify the usage of
> GetCpuLoad (and inherently deprecated GetSystemCpuLoad) and GetProcessCpuLoad.
>
> Calling either of these methods in quick succession can lead to
> unrepresentative results due to too few data points.
>
> This behavior
On Wed, 21 Aug 2024 13:08:23 GMT, Andrew Haley wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> Main changes:
>> - Introduction of the (experimental) flag UseCompactObjectHeaders. All
>> changes in this PR are protected by this flag. The purpose of t
On Tue, 20 Aug 2024 10:07:26 GMT, Roman Kennke wrote:
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All
> changes in this PR are protected by this flag. The purpose of the fl
> This is a port of [JDK-8318636](https://github.com/openjdk/jdk/pull/16301) to
> Windows.
>
> System.map and System.dump_map are implemented using the Windows API and
> provide roughly the same information in the same format. Most of the heavy
> lifting was implemented by @tstuefe in #16301 -
On Tue, 20 Aug 2024 06:06:39 GMT, Thomas Stuefe wrote:
>> Simon Tooke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> changes from tstuefe review
>
> src/hotspot/os/windows/memMapPrinter_windows.cpp line 3:
>
>> 1: /*
>> 2: * Copyright
> This is a port of [JDK-8318636](https://github.com/openjdk/jdk/pull/16301) to
> Windows.
>
> System.map and System.dump_map are implemented using the Windows API and
> provide roughly the same information in the same format. Most of the heavy
> lifting was implemented by @tstuefe in #16301 -
On Tue, 20 Aug 2024 10:07:26 GMT, Roman Kennke wrote:
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All
> changes in this PR are protected by this flag. The purpose of the fl
On Wed, 21 Aug 2024 11:35:26 GMT, Alan Bateman wrote:
>> src/jdk.management/share/classes/com/sun/management/OperatingSystemMXBean.java
>> line 142:
>>
>>> 140: * negative value.
>>> 141: *
>>> 142: * This method is not idempotent. The recent period of
>>> observation
>>
>> I
This is the main body of the JEP 450: Compact Object Headers (Experimental).
Main changes:
- Introduction of the (experimental) flag UseCompactObjectHeaders. All changes
in this PR are protected by this flag. The purpose of the flag is to provide a
fallback, in case that users unexpectedly obse
On Wed, 21 Aug 2024 11:27:44 GMT, David Holmes wrote:
>> Can I get a review of this documentation update to clarify the usage of
>> GetCpuLoad (and inherently deprecated GetSystemCpuLoad) and
>> GetProcessCpuLoad.
>>
>> Calling either of these methods in quick succession can lead to
>> unrepr
On Mon, 12 Aug 2024 12:33:04 GMT, Joakim Nordström
wrote:
> Can I get a review of this documentation update to clarify the usage of
> GetCpuLoad (and inherently deprecated GetSystemCpuLoad) and GetProcessCpuLoad.
>
> Calling either of these methods in quick succession can lead to
> unrepresen
On Mon, 12 Aug 2024 12:33:04 GMT, Joakim Nordström
wrote:
> Can I get a review of this documentation update to clarify the usage of
> GetCpuLoad (and inherently deprecated GetSystemCpuLoad) and GetProcessCpuLoad.
>
> Calling either of these methods in quick succession can lead to
> unrepresen
Can I get a review of this documentation update to clarify the usage of
GetCpuLoad (and inherently deprecated GetSystemCpuLoad) and GetProcessCpuLoad.
Calling either of these methods in quick succession can lead to
unrepresentative results due to too few data points.
This behavior is easy to re
On 21/08/2024 10:50, Egor Ushakov wrote:
Hi Chris,
I tried it on jdk 23 and it works the same way :(
It is clear that calling Thread.interrupted() in debugger should
modify the interrupted state, but it does not...
It looks like the debugger is taking thread interrupted state from
somewhere
On Tue, 13 Aug 2024 15:07:17 GMT, Sonia Zaldana Calles
wrote:
> Hi all,
>
> This PR addresses [8204681](https://bugs.openjdk.org/browse/JDK-8204681)
> enabling support for timestamp expansion in filenames specified in
> `-XX:HeapDumpPath` using `%t`.
>
> As mentioned in this comments for t
On Thu, 15 Aug 2024 20:28:28 GMT, Dhamoder Nalla wrote:
>> Use the GetTempPath2 APIs instead of the GetTempPath APIs in native code
>> across the OpenJDK repository to retrieve the temporary directory path, as
>> GetTempPath2 provides enhanced security. While GetTempPath may still
>> function
34 matches
Mail list logo
