On Fri, 8 Mar 2024 01:07:50 GMT, Man Cao wrote:
> Hi all,
>
> Could anyone review this fix to make serial heap dump only write to a single
> file?
> We highly appreciate the work in https://bugs.openjdk.org/browse/JDK-8306441.
> However, many of our customers still need to use serial heap dump
On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski wrote:
> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
>
> `MEMFLAGS` implies that we can use more than one at the same time, but those
> are exclusive values, so `MemType` is much more suitable name.
>
> There is a bunch o
On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski wrote:
> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
>
> `MEMFLAGS` implies that we can use more than one at the same time, but those
> are exclusive values, so `MemType` is much more suitable name.
>
> There is a bunch o
On Wed, 28 Aug 2024 06:38:48 GMT, Kim Barrett wrote:
> We should make a similar set of changes for clang, though doing that in a
> separate
proposal is good. Is there a JBS issue for that yet?
Yes, we should. I am 80% done with that patch, but I have not yet opened a JBS
ticket. Will do that n
> Currently, we issue -Wno-unused for all files in gcc, which is a rather big
> sledgehammer to get rid of some warnings that proliferate in a few areas of
> the build.
>
> We should instead leave -Wunused turned on (as done by -Wall) and use a much
> more fine-grained approach to disabling spe
On Wed, 28 Aug 2024 11:26:01 GMT, Magnus Ihse Bursie wrote:
>> make/autoconf/flags-cflags.m4 line 239:
>>
>>> 237: # Additional warnings that are not activated by -Wall and -Wextra
>>> 238: WARNINGS_ENABLE_ADDITIONAL="-Wpointer-arith -Wreturn-type
>>> -Wsign-compare \
>>> 239:
On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski wrote:
> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
>
> `MEMFLAGS` implies that we can use more than one at the same time, but those
> are exclusive values, so `MemType` is much more suitable name.
>
> There is a bunch o
On Tue, 27 Aug 2024 23:15:03 GMT, Jiangli Zhou wrote:
>> And the discussion whether the checks are made "dynamically" or "statically"
>> is too simplified to be really helpful.
>>
>> Currently, we compile two sets of all object files, with slightly different
>> compiler arguments, one for dyna
> Currently, we issue -Wno-unused for all files in gcc, which is a rather big
> sledgehammer to get rid of some warnings that proliferate in a few areas of
> the build.
>
> We should instead leave -Wunused turned on (as done by -Wall) and use a much
> more fine-grained approach to disabling spe
On Wed, 28 Aug 2024 13:02:55 GMT, Magnus Ihse Bursie wrote:
>> Currently, we issue -Wno-unused for all files in gcc, which is a rather big
>> sledgehammer to get rid of some warnings that proliferate in a few areas of
>> the build.
>>
>> We should instead leave -Wunused turned on (as done by -
> 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 Mon, 26 Aug 2024 02:07:39 GMT, David Holmes wrote:
> I understand the cost overhead experienced by any individual Java run may be
> lost in the noise, but it still impacts every single Java run just to save
> some time/resources for the handful of builders of statically linked VMs. I
> am n
> Currently, we issue -Wno-unused for all files in gcc, which is a rather big
> sledgehammer to get rid of some warnings that proliferate in a few areas of
> the build.
>
> We should instead leave -Wunused turned on (as done by -Wall) and use a much
> more fine-grained approach to disabling spe
> Currently, we issue -Wno-unused for all files in gcc, which is a rather big
> sledgehammer to get rid of some warnings that proliferate in a few areas of
> the build.
>
> We should instead leave -Wunused turned on (as done by -Wall) and use a much
> more fine-grained approach to disabling spe
On Wed, 28 Aug 2024 13:35:19 GMT, Kim Barrett wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix aarch54
>
> make/modules/java.desktop/lib/ClientLibraries.gmk line 284:
>
>> 282:
>> 283: ifeq ($(USE_EXTERN
On Wed, 28 Aug 2024 12:29:36 GMT, Magnus Ihse Bursie wrote:
>> Good point, I'll try that.
>
> It turned out to be sort-of okay-ish. I explicitly listed like 6 or so
> per-file exclusions in Hotspot (even though my normal cutoff for just setting
> a component-wide exclude is 3-4) since it seems
> Currently, we issue -Wno-unused for all files in gcc, which is a rather big
> sledgehammer to get rid of some warnings that proliferate in a few areas of
> the build.
>
> We should instead leave -Wunused turned on (as done by -Wall) and use a much
> more fine-grained approach to disabling spe
On Wed, 28 Aug 2024 15:15:03 GMT, Magnus Ihse Bursie wrote:
>> Currently, we issue -Wno-unused for all files in gcc, which is a rather big
>> sledgehammer to get rid of some warnings that proliferate in a few areas of
>> the build.
>>
>> We should instead leave -Wunused turned on (as done by -
On Wed, 28 Aug 2024 15:17:52 GMT, Magnus Ihse Bursie wrote:
>> Currently, we issue -Wno-unused for all files in gcc, which is a rather big
>> sledgehammer to get rid of some warnings that proliferate in a few areas of
>> the build.
>>
>> We should instead leave -Wunused turned on (as done by -
On Thu, 15 Aug 2024 07:59:21 GMT, Kim Barrett wrote:
>> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
>>
>> `MEMFLAGS` implies that we can use more than one at the same time, but those
>> are exclusive values, so `MemType` is much more suitable name.
>>
>> There is a bun
On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski wrote:
> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
>
> `MEMFLAGS` implies that we can use more than one at the same time, but those
> are exclusive values, so `MemType` is much more suitable name.
>
> There is a bunch o
On Tue, 27 Aug 2024 23:15:03 GMT, Jiangli Zhou wrote:
>> And the discussion whether the checks are made "dynamically" or "statically"
>> is too simplified to be really helpful.
>>
>> Currently, we compile two sets of all object files, with slightly different
>> compiler arguments, one for dyna
This PR changes the status of realpath() from a Posix-specific API to a
globally available API, i.e. adding it to the "Hotspot Porting API". Code
would refer to os::realpath() instead of os::Posix::realpath().
This requires the addition of a stub routine in os_posix.cpp and a Windows
implement
On Wed, 28 Aug 2024 15:17:52 GMT, Magnus Ihse Bursie wrote:
>> Currently, we issue -Wno-unused for all files in gcc, which is a rather big
>> sledgehammer to get rid of some warnings that proliferate in a few areas of
>> the build.
>>
>> We should instead leave -Wunused turned on (as done by -
On Wed, 28 Aug 2024 03:42:27 GMT, Chris Plummer wrote:
> I'm not sure why this is failing. Based on the existing code and comments, it
> seems at some point SA worked without relying on the windbg native symbol
> support. Code like isSharingEnabled() probably got added afterwards and was
> nev
Only allocate the cmdQueueLock once rather than allocate each time there is a
new connection (and destroy when the connection is terminated).
Currently each time there is a new debug agent connection established, the
cmdQueueLock is allocated. It is then destroyed when the connection is dropped,
On Mon, 26 Aug 2024 22:25:34 GMT, Alex Menkov wrote:
>> On Windows SA agent gets a class vtable from symbols, exported from jvm.dll
>> (it exports symbols like "??_7" + type + "@@6B@").
>> But symbol lookup function first requests WinDbg about the symbol.
>> Sometimes WinDbg routine IDebugSymbol
On Mon, 26 Aug 2024 22:25:34 GMT, Alex Menkov wrote:
>> On Windows SA agent gets a class vtable from symbols, exported from jvm.dll
>> (it exports symbols like "??_7" + type + "@@6B@").
>> But symbol lookup function first requests WinDbg about the symbol.
>> Sometimes WinDbg routine IDebugSymbol
> On Windows SA agent gets a class vtable from symbols, exported from jvm.dll
> (it exports symbols like "??_7" + type + "@@6B@").
> But symbol lookup function first requests WinDbg about the symbol.
> Sometimes WinDbg routine IDebugSymbols::GetOffsetByName() returns offset for
> both class and c
On Wed, 28 Aug 2024 03:42:27 GMT, Chris Plummer wrote:
> ```
> public boolean isSharingEnabled() {
> if (sharingEnabled == null) {
> Address address = VM.getVM().getDebugger().lookup(null,
> "UseSharedSpaces");
> if (address == null && getOS().equals("win32")) {
>
On Wed, 28 Aug 2024 23:30:33 GMT, Alex Menkov wrote:
>> On Windows SA agent gets a class vtable from symbols, exported from jvm.dll
>> (it exports symbols like "??_7" + type + "@@6B@").
>> But symbol lookup function first requests WinDbg about the symbol.
>> Sometimes WinDbg routine IDebugSymbol
On Wed, 28 Aug 2024 23:30:33 GMT, Alex Menkov wrote:
>> On Windows SA agent gets a class vtable from symbols, exported from jvm.dll
>> (it exports symbols like "??_7" + type + "@@6B@").
>> But symbol lookup function first requests WinDbg about the symbol.
>> Sometimes WinDbg routine IDebugSymbol
On Wed, 28 Aug 2024 23:47:05 GMT, Alex Menkov wrote:
> Update: usually constants are available for SA by using VMStruct, I'm not
> sure why "UseSharedSpaces" is exported this way
Probably the author just didn't know about the VMStruct approach.
-
PR Comment: https://git.openjdk.or
On Wed, 28 Aug 2024 23:58:50 GMT, Chris Plummer wrote:
> What would happen if it was not extern "C". Would the windbg lookup succeed
> in that case?
without extern "C" the variable is exported as "?UseSharedSpaces@@3EA". So it
wouldn't work with DLL lookup neither windbg.
-
PR Co
On Wed, 28 Aug 2024 23:30:33 GMT, Alex Menkov wrote:
>> On Windows SA agent gets a class vtable from symbols, exported from jvm.dll
>> (it exports symbols like "??_7" + type + "@@6B@").
>> But symbol lookup function first requests WinDbg about the symbol.
>> Sometimes WinDbg routine IDebugSymbol
On Wed, 28 Aug 2024 23:30:33 GMT, Alex Menkov wrote:
>> On Windows SA agent gets a class vtable from symbols, exported from jvm.dll
>> (it exports symbols like "??_7" + type + "@@6B@").
>> But symbol lookup function first requests WinDbg about the symbol.
>> Sometimes WinDbg routine IDebugSymbol
> This work has been split out from JDK-8328877: [JNI] The JNI Specification
> needs to address the limitations of integer UTF-8 String lengths
>
> The modified UTF-8 format used by the VM can require up to six bytes to
> represent one unicode character, but six byte characters are stored as UTF
On Thu, 22 Aug 2024 18:36:39 GMT, Simon Tooke wrote:
> This PR changes the status of realpath() from a Posix-specific API to a
> globally available API, i.e. adding it to the "Hotspot Porting API". Code
> would refer to os::realpath() instead of os::Posix::realpath().
>
> This requires the ad
On Thu, 29 Aug 2024 02:45:53 GMT, David Holmes wrote:
>> This work has been split out from JDK-8328877: [JNI] The JNI Specification
>> needs to address the limitations of integer UTF-8 String lengths
>>
>> The modified UTF-8 format used by the VM can require up to six bytes to
>> represent one
On Thu, 29 Aug 2024 05:52:26 GMT, Thomas Stuefe wrote:
> Many of these translations seem awkward, since they convert to size_t only to
> then convert back to int.
>
> Proposal: I undestand you need to find a good point to tourniquet off the
> int->size_t conversion to minimize the translations
40 matches
Mail list logo
