RE: [libattach] misleading error message when checking gid fails

Hi, the manpage of getegid https://man7.org/linux/man-pages/man3/getegid.3p.html says : " The getegid() function shall always be successful and no return value is reserved to indicate an error." So I am not sure what kind of additional check or error message you would expect ? > In this

RE: OpenJDK SADebugDTest.java test : handling of "Address already in use"

Hi Yasumasa, thanks for addressing the issue . I put your patch into our internal nightly test queue . Best regards, Matthias > >> `testResult` and `portInUse` are important variables in this logic, >> however they are overwritten in lambda expression - they won't affect >> to the caller. >> (I

OpenJDK SADebugDTest.java test : handling of "Address already in use"

Hello, I have a question regarding the test SADebugDTest.java . The test https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/serviceability/sa/sadebugd/SADebugDTest.java seems to handle already cases where "Address already in use" is found in the output (see line 120 ). However in

RE: [PING?] RFR(s): 8247863: Unreachable code in OperatingSystemImpl.getTotalSwapSpaceSize()

>The only reason why a 0 was observed, was because the cgroup interface >files were missing and the old code mapped that to a 0. That's no >longer the case and, thus, it seems it would make the code clearer if >it wouldn't be there any more. > >I don't feel strongly about this, though, and can

RE: [PING?] RFR(s): 8247863: Unreachable code in OperatingSystemImpl.getTotalSwapSpaceSize()

So the check you want to clean up does no harm, and might handle "strange" cases - why not keep it? Best regards, Matthias -Original Message- From: Severin Gehwolf Sent: Mittwoch, 15. Juli 2020 11:47 To: core-libs-dev ; serviceability-dev Cc: Baesken, Matthias ;

RE: RFR(XS): 8245521: Remove STACK_BIAS

Hi Mikael, looks good, thanks for the cleanup . Best regards, Matthias -Original Message- From: ppc-aix-port-dev On Behalf Of Mikael Vidstedt Sent: Freitag, 22. Mai 2020 05:37 To: hotspot compiler ; hotspot-runtime-...@openjdk.java.net runtime ; serviceability-dev ;

RE: RFR [XS]: 8239462: jdk.hotspot.agent misses some ReleaseStringUTFChars calls in case of early returns

alex > > On 02/21/2020 00:32, Baesken, Matthias wrote: > > Hi Alex , > > > > new webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8239462.2/ > > > > Best Regards, Matthias > > > > > >> > >> Hi Matthias, >

RE: RFR [XS]: 8239462: jdk.hotspot.agent misses some ReleaseStringUTFChars calls in case of early returns

Hi Alex , new webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8239462.2/ Best Regards, Matthias > > Hi Matthias, > > Looks good in general, but I think it makes sense to fix #2 cases (at > least I see them in LinuxDebuggerLocal). If GetStringUTFChars fails, the > code will crash. >

RE: RFR [XS]: 8239462: jdk.hotspot.agent misses some ReleaseStringUTFChars calls in case of early returns

oc/sawindbg.cpp > It would make the code simpler and less error prone. > > --alex > > On 02/20/2020 00:53, Baesken, Matthias wrote: > > Hi Alex / Christoph, thanks for the reviews. > > > > New webrev : > > > > http://cr.openjdk.java.net/~mbaesken/web

RE: RFR [XS]: 8239462: jdk.hotspot.agent misses some ReleaseStringUTFChars calls in case of early returns

ex > > On 02/19/2020 06:21, Baesken, Matthias wrote: > > Hello, please review this small change . > > We miss at a few places ReleaseStringUTFChars calls in the native > > jdk.hotspot.agent coding. > > This happens in case of early returns . > > > >

RFR [XS]: 8239462: jdk.hotspot.agent misses some ReleaseStringUTFChars calls in case of early returns

Hello, please review this small change . We miss at a few places ReleaseStringUTFChars calls in the native jdk.hotspot.agent coding. This happens in case of early returns . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8239462 http://cr.openjdk.java.net/~mbaesken/webrevs/8239462.0/

RE: RFR [XS]: 8238602: remove obsolete functions from libinstrument/FileSystemSupport_md.c

Hi Christoph, thanks for the review ! Will push it as XS in case no objections show up . Best regards, Matthias From: Langer, Christoph Sent: Montag, 10. Februar 2020 10:01 To: Baesken, Matthias ; serviceability-dev@openjdk.java.net Subject: RE: RFR [XS]: 8238602: remove obsolete functions

RFR [XS]: 8238602: remove obsolete functions from libinstrument/FileSystemSupport_md.c

Hello, the link time section gc (see https://bugs.openjdk.java.net/browse/JDK-8236714 , on linux s390x it prints the removed sections) showed some obsolete / unused functions in FileSystemSupport_md.c : ld: Removing unused section '.text.pathSeparator' in file

RE: serviceability agent : problems when using gcc LTO (link time optimization)

e with LTO/gold and know if gold could maybe improve linking times with LTO? [1] https://gcc.gnu.org/wiki/LinkTimeOptimization [2] https://stackoverflow.com/questions/31688069/requirements-to-use-flto Baesken, Matthias mailto:matthias.baes...@sap.com>> schrieb am Mi., 15. Jan. 2020, 07:02: He

RE: serviceability agent : problems when using gcc LTO (link time optimization)

Hello, I used the "normal" linker so I think what https://stackoverflow.com/questions/31688069/requirements-to-use-flto says is true , one can use also the "normal" linker . Haven't checked for any performance (or other) improvements when using gold instead . Best regards,

RE: serviceability agent : problems when using gcc LTO (link time optimization)

20 14:40 To: Aleksei Voitylov Cc: Baesken, Matthias ; Magnus Ihse Bursie ; serviceability-dev@openjdk.java.net; build-dev ; hotspot-...@openjdk.java.net Subject: Re: serviceability agent : problems when using gcc LTO (link time optimization) While we are speaking about all the drawbacks of LTO, it's s

RE: serviceability agent : problems when using gcc LTO (link time optimization)

Hello Magnus and Aleksei, thanks for the input . The times you provided really look like they make a big difference at least for people often building minimal-vm . Guess I have to measure myself a bit (maybe the difference is not that big on our linux s390x / ppc64(le) ) . > > If the

RE: serviceability agent : problems when using gcc LTO (link time optimization)

). Best regards, Matthias On 2020-01-10 11:01, Baesken, Matthias wrote: Hello, I recently looked into the gcc lto optimization mode (see for some details https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html and http://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-inter

RE: serviceability agent : problems when using gcc LTO (link time optimization)

sentation in the SA), because it doesn't seem to be needed. > > > > Notice that other places in the VM may also rely on this. E.g. CDS stores > > Metadata objects in the CDS archive and restores their vtable pointers > when > > they are loaded. On the other hand, if the

serviceability agent : problems when using gcc LTO (link time optimization)

Hello, I recently looked into the gcc lto optimization mode (see for some details https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html and http://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-inter-procedural.html ). This mode can lead to more compact binaries (~10% smaller) ,

RE: RFR [XS]: 8234968: check calloc rv in libinstrument InvocationAdapter

Hi Thomas, probably jplis_assert(x)should better be named jplis_warn(x) . Additionally the TRANSFORM macro could be enhanced by an abort() call (or abortJVM ?) or something similar . Best regards, Matthias Just

RE: RFR [XS]: 8234968: check calloc rv in libinstrument InvocationAdapter

: http://cr.openjdk.java.net/~mbaesken/webrevs/8234968.2/ Best regards, Matthias From: Thomas Stüfe Sent: Freitag, 29. November 2019 07:30 To: Baesken, Matthias Cc: serviceability-dev@openjdk.java.net Subject: Re: RFR [XS]: 8234968: check calloc rv in libinstrument InvocationAdapter Hi Matthias

RFR [XS]: 8234968: check calloc rv in libinstrument InvocationAdapter

Hello, please review this small patch . It adds return value checking for calloc at one place where it is missing . Thanks, Matthias Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8234968 http://cr.openjdk.java.net/~mbaesken/webrevs/8234968.1/

RE: RFR [XS]: 8230901: missing ReleaseStringUTFChars in servicability native code

Sent: Samstag, 14. September 2019 00:18 To: Baesken, Matthias ; Thomas Stüfe Cc: serviceability-dev@openjdk.java.net Subject: Re: RFR [XS]: 8230901: missing ReleaseStringUTFChars in servicability native code Hi Matthias, On 9/12/19 4:52 AM, Baesken, Matthias wrote: Hi Thomas, thanks for the

RE: RFR [XS]: 8230901: missing ReleaseStringUTFChars in servicability native code

Hello , my colleague Ralf pointed out that the NULL-check of the result of GetStringUTFChars should be done right after the GetStringUTFChars so I moved the NULL-check up : http://cr.openjdk.java.net/~mbaesken/webrevs/8230901.2/ Best regards, Matthias Hi Thomas, thanks for the

RE: RFR [XS]: 8230901: missing ReleaseStringUTFChars in servicability native code

/java.desktop/unix/native/common/awt/X11Color.c:782:cmapsize = atoi(getenv("CMAPSIZE")); Should I open a bug for these ? Best regards, Matthias From: Thomas Stüfe Sent: Donnerstag, 12. September 2019 12:22 To: Baesken, Matthias Cc: serviceability-dev@openjdk.ja

RFR [XS]: 8230901: missing ReleaseStringUTFChars in servicability native code

Hello, please reviews this small change . It adds ReleaseStringUTFChars calls at some places in early return cases . ( in src/jdk.hotspot.agent/solaris/native/libsaproc/saproc.cpp THROW_NEW_DEBUGGER_EXCEPTION contains a return , see the macro declaration 39 #define

RE: RFR: 8230466: check malloc/calloc results in jdk.hotspot.agent

Hello Serguei, thanks for the comments . > > http://cr.openjdk.java.net/~mbaesken/webrevs/8230466.1/src/jdk.hotspot. > agent/linux/native/libsaproc/symtab.c.frames.html > >  279 build_id_to_debug_filename (size_t size, unsigned char *data) >  280 { >  . . . >  283   filename =

RE: RFR: 8230466: check malloc/calloc results in jdk.hotspot.agent

id Holmes wrote: > > Hi Matthias, > > > > Re-directing to serviceability-dev. > > > > David > > > > On 3/09/2019 5:42 pm, Baesken, Matthias wrote: > >> Hello, please review the following small fix . > >> > >> In jdk.hotspot.agent

RE: RFR: [XS] 8228658: test GetTotalSafepointTime.java fails on fast Linux machines with Total safepoint time 0 ms

Hi David + JC , thanks for the reviews . David - I added the suggested print-outputs , and also the parameter to executeThreadDumps . Best regards, Matthias > -Original Message- > From: David Holmes > Sent: Mittwoch, 31. Juli 2019 23:57 > To: Baesken, Matthias ; Jea

RE: RFR: [XS] 8228658: test GetTotalSafepointTime.java fails on fast Linux machines with Total safepoint time 0 ms

019 05:04 > To: Jean Christophe Beyler > Cc: Baesken, Matthias ; hotspot- > d...@openjdk.java.net; serviceability-dev d...@openjdk.java.net> > Subject: Re: RFR: [XS] 8228658: test GetTotalSafepointTime.java fails on fast > Linux machines with Total safepoint time 0 ms > > On 31

RE: RFR: [XS] 8228658: test GetTotalSafepointTime.java fails on fast Linux machines with Total safepoint time 0 ms

t regards, Matthias > -Original Message- > From: David Holmes > Sent: Dienstag, 30. Juli 2019 14:12 > To: Baesken, Matthias ; Jean Christophe > Beyler > Cc: hotspot-...@openjdk.java.net; serviceability-dev d...@openjdk.java.net> > Subject: Re: RFR: [XS] 822

RE: RFR: [XS] 8228658: test GetTotalSafepointTime.java fails on fast Linux machines with Total safepoint time 0 ms

to cause timeouts etc.).I removed a check for MAX_VALUE_FOR_PASS because we cannot go over Long.MAX_VALUE . Hope you like this version better. Best regards, Matthias From: Jean Christophe Beyler Sent: Dienstag, 30. Juli 2019 05:39 To: David Holmes Cc: Baesken, Matthias ; hotspot

RFR: [XS] 8228658: test GetTotalSafepointTime.java fails on fast Linux machines with Total safepoint time 0 ms

Hello , please review this small test fix . The test test/jdk/sun/management/HotspotRuntimeMBean/GetTotalSafepointTime.java fails sometimes on fast Linux machines with this error message : java.lang.RuntimeException: Total safepoint time illegal value: 0 ms (MIN = 1; MAX = 9223372036854775807)

RE: RFR [XS] : 8226943: compile error in libfollowref003.cpp with XCode 10.2 on macosx

> > > > Dropped build-dev and added serviceability-dev as this is a > > servicability test. > > > > On 28/06/2019 7:43 am, Baesken, Matthias wrote: > >> Hello please review this  small fix for a compile issue  on OSX . > >> Today I  compiled   jdk/jdk   o

Re: RFR [XS] : 8226943: compile error in libfollowref003.cpp with XCode 10.2 on macosx

is a servicability >> test. >> >>> On 28/06/2019 7:43 am, Baesken, Matthias wrote: >>> Hello please review this small fix for a compile issue on OSX . >>> Today I compiled jdk/jdk on a machine with XCode 10.2 . It worked >>> pretty well .

Re: RFR 8223065: Add jcmd to get the listen address of the debugger

Hello, looked at the latest web rev ( http://cr.openjdk.java.net/~rschmelter/webrevs/8223065/webrev.3/ ) , looks good to me ! (not a Reviewer however ) Best regards, Matthias > > On 30/04/2019 9:33 pm, Schmelter, Ralf wrote: > > Hi David, > > > > good catch. I've moved the vm->native

RE: RFR: 8220355: Improve assertion texts and exception messages in eventHandlerVMInit

Updated webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8220355.2/ Alan + JC , may I add you as reviewers ? Thanks, Matthias From: Baesken, Matthias Sent: Montag, 18. März 2019 11:01 To: 'Alan Bateman' ; Jean Christophe Beyler Cc: serviceability-dev@openjdk.java.net Subject: RE: RFR

RE: RFR: 8220355: Improve assertion texts and exception messages in eventHandlerVMInit

18. März 2019 10:09 To: Baesken, Matthias ; Jean Christophe Beyler Cc: serviceability-dev@openjdk.java.net Subject: Re: RFR: 8220355: Improve assertion texts and exception messages in eventHandlerVMInit On 18/03/2019 08:54, Baesken, Matthias wrote: Hi JC, thanks for your comments . Second webr

RE: RFR: 8220355: Improve assertion texts and exception messages in eventHandlerVMInit

changing the test to if (environment == NULL) { … } or is this resolved now on all platforms ? Best regards, Matthias From: Jean Christophe Beyler Sent: Freitag, 15. März 2019 15:53 To: Baesken, Matthias Cc: serviceability-dev@openjdk.java.net Subject: Re: RFR: 8220355: Improve assertion texts

RFR: 8220355: Improve assertion texts and exception messages in eventHandlerVMInit

Hello, please review the following change . It enhances the error messages in libinstrument in case initialization fails . ( I found the enhanced error messages helpful when analyzing jtreg failures on one of our platforms in the java/lang/instrument/PremainClass/PremainClassTest.java

RE: RFR: [XS] 8215411: some GetByteArrayElements calls miss corresponding Release

s > Sent: Dienstag, 18. Dezember 2018 10:04 > To: Baesken, Matthias ; 'hotspot- > d...@openjdk.java.net' ; serviceability- > d...@openjdk.java.net; security-...@openjdk.java.net; JC Beyler > > Subject: Re: RFR: [XS] 8215411: some GetByteArrayElements calls miss > correspo

RE: RFR: [XS] 8215411: some GetByteArrayElements calls miss corresponding Release

efore returning here 735 if (bytesRead != numBytes) { 736 return 0; 737 } ? Best regards, Matthias > -Original Message- > From: David Holmes > Sent: Dienstag, 18. Dezember 2018 01:20 > To: Baesken, Matthias ; 'hotspot- > d...@openjdk.java.net' ; serviceabili

RFR: [XS] 8215411: some GetByteArrayElements calls miss corresponding Release

Hello, please review the following change. I noticed that we miss at some places (for example in case of early returns) where GetByteArrayElements is used, the corresponding ReleaseByteArrayElements call. In VirtualMachineImpl.c I also removed a check for isCopy (is the returned byte array a

RE: RFR : [XS] 8214373: adjust usage of ReleaseLongArrayElements in MacosxDebuggerLocal

Hi Thomas and JC , thanks for the reviews ! Best regards, Matthias From: JC Beyler Sent: Dienstag, 27. November 2018 16:48 To: Baesken, Matthias Cc: hotspot-dev Source Developers ; serviceability-dev@openjdk.java.net Subject: Re: RFR : [XS] 8214373: adjust usage of ReleaseLongArrayElements

RFR : [XS] 8214373: adjust usage of ReleaseLongArrayElements in MacosxDebuggerLocal

Hello, please review this small fix . In MacosxDebuggerLocal.m , at a few places the functions GetLongArrayElements and ReleaseLongArrayElements are used. However there is one place where in an early return the ReleaseLongArrayElements call has been forgotten . Additionally at

RE: OOM counters

of our SAP-internal JDK . Best regards, Matthias From: JC Beyler Sent: Freitag, 21. September 2018 16:59 To: Baesken, Matthias Cc: David Holmes ; serviceability-dev@openjdk.java.net Subject: Re: OOM counters Sorry, when I said "we added" I meant "in our internal JDK at Googl

RE: OOM counters

Beyler Sent: Donnerstag, 20. September 2018 17:52 To: Baesken, Matthias Cc: David Holmes ; serviceability-dev@openjdk.java.net Subject: Re: OOM counters Hi Matthias, - hotspot-dev to be in two mailing lists I'm still confused of why you want this via a Java API or why you want to look at those

RE: OOM counters

Holmes > Sent: Donnerstag, 20. September 2018 03:13 > To: Baesken, Matthias ; 'hotspot- > d...@openjdk.java.net' ; serviceability- > d...@openjdk.java.net serviceability-dev@openjdk.java.net d...@openjdk.java.net> > Subject: Re: OOM counters > > Hi Matthias, > >

RE: OOM counters

16:49 To: Baesken, Matthias Cc: hotspot-dev Source Developers ; serviceability-dev@openjdk.java.net Subject: Re: OOM counters Hi Matthias, In the case of an OOM, what's the use-case here? Are there cases where you are recuperating often from OOMs that the counters have different values and it's

OOM counters

Hello, Currently we have already counters in the Hotspot codebase counting Java heap, Metaspace and class metaspace related OOMs. See declarations: jdk/src/hotspot/share/utilities/exceptions.hpp 107 // Count out of memory errors that are interesting in error diagnosis 108 static volatile

RE: 8206456 - [TESTBUG] docker jtreg tests fail on systems without cpuset.effective_cpus / cpuset.effective_mem

ability- > d...@openjdk.java.net ; core-libs- > dev > Cc: Baesken, Matthias ; Schmidt, Lutz > > Subject: RFR: 8206456 - [TESTBUG] docker jtreg tests fail on systems without > cpuset.effective_cpus / cpuset.effective_mem > > Please review this fix which eliminates some docker/cgroup t

RE: 8206145 : dbgsysSocketClose - do not restart close if errno is EINTR [linux] - was : RE: RFR : 8205959 : Do not restart close if errno is EINTR

Ok, I change the comment to "AIX recommends to repeat the close call on EINTR" and push , is that fine with you ? Best regards, Matthias > -Original Message- > From: Alan Bateman [mailto:alan.bate...@oracle.com] > Sent: Mittwoch, 4. Juli 2018 13:43 > To: Bae

RE: 8206145 : dbgsysSocketClose - do not restart close if errno is EINTR [linux] - was : RE: RFR : 8205959 : Do not restart close if errno is EINTR

, 3. Juli 2018 23:26 > To: Alan Bateman ; Thomas Stüfe > > Cc: Baesken, Matthias ; serviceability-dev > (serviceability-dev@openjdk.java.net) d...@openjdk.java.net> > Subject: Re: 8206145 : dbgsysSocketClose - do not restart close if errno is > EINTR [linux] - was : RE: RFR :

RE: RFR: 8205928 - [TESTBUG]: jdk/internal/platform/docker/TestDockerMemoryMetrics.java fails depending on kernel config

Stüfe > Cc: serviceability-dev@openjdk.java.net serviceability- > d...@openjdk.java.net ; Baesken, > Matthias > Subject: Re: RFR: 8205928 - [TESTBUG]: > jdk/internal/platform/docker/TestDockerMemoryMetrics.java fails > depending on kernel config > > Matthais, who reported the iss

RE: 8206145 : dbgsysSocketClose - do not restart close if errno is EINTR [linux] - was : RE: RFR : 8205959 : Do not restart close if errno is EINTR

.openjdk.java.net/~mbaesken/webrevs/8206145.1/ Please review ! Thanks, Matthias > -Original Message- > From: Alan Bateman [mailto:alan.bate...@oracle.com] > Sent: Dienstag, 3. Juli 2018 12:09 > To: Baesken, Matthias ; David Holmes > ; Thomas Stüfe > Cc: service

RE: 8206145 : dbgsysSocketClose - do not restart close if errno is EINTR [linux] - was : RE: RFR : 8205959 : Do not restart close if errno is EINTR

David Holmes ; Thomas Stüfe > > Cc: serviceability-dev (serviceability-dev@openjdk.java.net) d...@openjdk.java.net>; Baesken, Matthias > Subject: Re: 8206145 : dbgsysSocketClose - do not restart close if errno is > EINTR [linux] - was : RE: RFR : 8205959 : Do not restart close if e

8206145 : dbgsysSocketClose - do not restart close if errno is EINTR [linux] - was : RE: RFR : 8205959 : Do not restart close if errno is EINTR

> -Original Message- > From: Thomas Stüfe [mailto:thomas.stu...@gmail.com] > Sent: Montag, 2. Juli 2018 12:08 > To: Baesken, Matthias ; Langer, Christoph > > Cc: serviceability-dev (serviceability-dev@openjdk.java.net) d...@openjdk.java.net>; Stuefe, Thomas ; net- &g

RE: RFR: JDK-8202200: set INCLUDE_SA to false on s390x by default -was : RE: INCLUDE_SA/serviceability agent - support on s390x

...@oracle.com] Sent: Montag, 23. April 2018 17:43 To: Baesken, Matthias <matthias.baes...@sap.com>; 'build-...@openjdk.java.net' <build-...@openjdk.java.net> Cc: serviceability-dev@openjdk.java.net; Schmidt, Lutz <lutz.schm...@sap.com> Subject: Re: INCLUDE_SA/serviceability agent

INCLUDE_SA/serviceability agent - support on s390x

Hello, as far as I know the serviceability agent is not supported on linux s390x . However (unlike on aix where it is not supported as well) , INCLUDE_SA=falseis not set in the central configure m4 files . Should we set it ( suggested diff below) ? Best regards, Matthias hg

RE: [XS] JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent

Sure, I forward it to serviceability-dev . -Original Message- From: Alan Bateman [mailto:alan.bate...@oracle.com] Sent: Dienstag, 16. Mai 2017 11:51 To: Baesken, Matthias <matthias.baes...@sap.com>; core-libs-...@openjdk.java.net Cc: Simonis, Volker <volker.simo...@sap.com>