The test serviceability/sa/sadebugd/SADebugDTest.java can pass under some
circumstances a negative rmiport (--rmiport -1) to SALauncher.java.
This leads to a somewhat misleading message
`[debugd] Argument is expected for 'rmiport' `
(we set an argument [-1] but probably this is not what is really
On Mon, 2 Jan 2023 14:31:14 GMT, Matthias Baesken wrote:
> The test serviceability/sa/sadebugd/SADebugDTest.java can pass under some
> circumstances a negative rmiport (--rmiport -1) to SALauncher.java.
> This leads to a somewhat misleading message
> `[debugd] Argument is expected
but probably this is not what is really expected)
> and additionally the real exception is not shown.
> Probably also a warning in case of negative rmiport values should be printed
> because they seem to lead to errors.
Matthias Baesken has updated the pull request incrementally with one
but probably this is not what is really expected)
> and additionally the real exception is not shown.
> Probably also a warning in case of negative rmiport values should be printed
> because they seem to lead to errors.
Matthias Baesken has updated the pull request incrementally with one
On Wed, 4 Jan 2023 14:19:18 GMT, Kevin Walls wrote:
> In the "if (useRmiPort) {" block, we should be failing the test if rmiPort is
> -1, saying something like "cannot find an rmiPort, findUnreservedFreePort
> returns -1"
>
> A similar abort if setting registryPort gets -1 might also be good?
but probably this is not what is really expected)
> and additionally the real exception is not shown.
> Probably also a warning in case of negative rmiport values should be printed
> because they seem to lead to errors.
Matthias Baesken has updated the pull request incrementally with one
On Wed, 4 Jan 2023 14:39:14 GMT, Kevin Walls wrote:
> SADebugDTest is only one test, so seems OK to have it fail as soon as we
> realise we need a port, and it has a value of -1.
>
> I would do it in this change as they are so connected, but really whichever
> works best for you. (I don't see
but probably this is not what is really expected)
> and additionally the real exception is not shown.
> Probably also a warning in case of negative rmiport values should be printed
> because they seem to lead to errors.
Matthias Baesken has updated the pull request incrementally with one
On Mon, 2 Jan 2023 14:31:14 GMT, Matthias Baesken wrote:
> The test serviceability/sa/sadebugd/SADebugDTest.java can pass under some
> circumstances a negative rmiport (--rmiport -1) to SALauncher.java.
> This leads to a somewhat misleading message
> `[debugd] Argument is expected
Some exception/error message changed with 8299470 so we have to adjust the test.
Current error is
Unexpected error 'Successor argument without leading - is expected for 'd' but
we got '-c''
java.lang.RuntimeException: Bad option test 4 failed
at SAGetoptTest.badOptionsTest(SAGetoptTest.java:124)
On Thu, 5 Jan 2023 08:55:32 GMT, Matthias Baesken wrote:
> Some exception/error message changed with 8299470 so we have to adjust the
> test.
> Current error is
>
> Unexpected error 'Successor argument without leading - is expected for 'd'
> but we got '
On Thu, 5 Jan 2023 08:55:32 GMT, Matthias Baesken wrote:
> Some exception/error message changed with 8299470 so we have to adjust the
> test.
> Current error is
>
> Unexpected error 'Successor argument without leading - is expected for 'd'
> but we got '
There are a few places in the instrument coding where errors occur in our jtreg
test, but the already existing error logging method jplis_assert_msg /
jplis_assert is unfortunately missing so not much details are shown. This could
be enhanced.
-
Commit messages:
- JDK-8299957
Cha
On Thu, 12 Jan 2023 08:10:29 GMT, Matthias Baesken wrote:
> There are a few places in the instrument coding where errors occur in our
> jtreg test, but the already existing error logging method jplis_assert_msg /
> jplis_assert is unfortunately missing so not much details are sh
On Thu, 19 Jan 2023 17:24:57 GMT, Severin Gehwolf wrote:
>> Please review this refactoring of a container test. It now uses WhiteBox to
>> retrieve the host values it asserts for. In terms of functionality this is
>> basically a no-op except for the now more precise assertion on systems with
>
On Tue, 24 Jan 2023 14:34:35 GMT, Severin Gehwolf wrote:
>> Please review this refactoring of a container test. It now uses WhiteBox to
>> retrieve the host values it asserts for. In terms of functionality this is
>> basically a no-op except for the now more precise assertion on systems with
>
On Mon, 3 Apr 2023 08:29:55 GMT, Johannes Bechberger
wrote:
>> Fixes the issue by disabling PCDesc cache modifications when in ASGCT.
>>
>> Tested on my M1 mac.
>
> Johannes Bechberger has updated the pull request incrementally with two
> additional commits since the last revision:
>
> - Fix
On Tue, 18 Apr 2023 16:59:29 GMT, Markus Grönlund wrote:
> Greetings,
>
> For most platforms, os::dll_address_to_library_name() only sets offset = -1
> in case of errors. If there is an error, the function returns false. This is
> fine.
>
> On AIX, the offset, being optional, is invariantly s
On Thu, 25 May 2023 09:14:14 GMT, JoKern65 wrote:
> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk
> on AIX , we run into various "warnings as errors".
> Some of those are in shared codebase and could be addressed by small
> adjustments.
> A lot of those changes ar
On Thu, 25 May 2023 16:13:49 GMT, JoKern65 wrote:
>> test/jdk/java/io/File/libGetXSpace.c line 128:
>>
>>> 126: #else
>>> 127: struct statfs buf;
>>> 128: int result = statfs((char*)chars, &buf);
>>
>> Is this working around a bug in IBM's declaration?
>>
>> Also, pre-existing, the cas
On Fri, 26 May 2023 07:12:07 GMT, Matthias Baesken wrote:
>> This is IBMs declaration of statfs
>> `extern int statfs(char *, struct statfs *);`
>> So the compiler will not accept a `const char*`
>> Indeed I do not know if this ever worked, but my change makes it no
On Fri, 26 May 2023 10:05:56 GMT, JoKern65 wrote:
> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c:1251:7: error:
> '_ALLBSD_SOURCE' is not defined, evaluates to 0 [-Werror,-Wundef]
> #elif _ALLBSD_SOURCE
>
Should probably better be
`#elif defined(_ALLBSD_SOURCE)`
-
P
On Fri, 26 May 2023 10:18:37 GMT, JoKern65 wrote:
> src/java.base/share/native/libjli/java.c:2311:22: error: format string is not
> a string literal [-Werror,-Wformat-nonliteral] vfprintf(stderr, fmt, vl); ^~~
We disable this warning too for clang on all platforms in BUILD_LIBJLI (
DISABLED_WA
On Fri, 26 May 2023 10:18:37 GMT, JoKern65 wrote:
> Here are the reasons for the disabled warnings in
> make/modules/java.base/lib/CoreLibraries.gmk
> DISABLED_WARNINGS_clang_aix_ProcessHandleImpl_unix.c := sign-compare,
> DISABLED_WARNINGS_clang_aix := gnu-pointer-arith, DISABLED_WARNINGS_cla
On Tue, 6 Jun 2023 09:51:09 GMT, JoKern65 wrote:
> The sys_thread_3() function contains an empty while loop, which by the
> standard can be optimized away. Please refer to discussion in
> https://github.com/llvm/llvm-project/issues/60622
> The xlc17 compiler is doing so, and IBM claims that the
On AIX , new jtreg test
com/sun/tools/attach/warnings/DynamicLoadWarningTest.java always failed with
the output :
--System.err:(294/28579)--
STARTED DynamicLoadWarningTest::testLoadJavaAgent 'testLoadJavaAgent()'
SUCCESSFUL DynamicLoadWarningTest::testLoadJavaAgent 'testLoadJa
On Fri, 9 Jun 2023 13:39:26 GMT, Matthias Baesken wrote:
> On AIX , new jtreg test
> com/sun/tools/attach/warnings/DynamicLoadWarningTest.java always failed with
> the output :
>
> --System.err:(294/28579)--
> STARTED DynamicLoadWarningTest:
On Mon, 12 Jun 2023 14:36:56 GMT, Martin Doerr wrote:
> Test fix for test failing on AIX because of undefined behavior in current
> implementation.
Marked as reviewed by mbaesken (Reviewer).
-
PR Review: https://git.openjdk.org/jdk21/pull/9#pullrequestreview-1475121715
After push of [JDK-8307478](https://bugs.openjdk.org/browse/JDK-8307478) , the
following test started to fail on AIX :
com/sun/tools/attach/warnings/DynamicLoadWarningTest.java ; failure output :
java.lang.RuntimeException: 'WARNING: A JVM TI agent has been loaded
dynamically' found in stderr
at
mtiAgent(DynamicLoadWarningTest.java:138)
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
>
> Should be handled in a similar way to
> [JDK-8309549](https://bugs.ope
On Fri, 16 Jun 2023 10:44:47 GMT, Matthias Baesken wrote:
> After push of [JDK-8307478](https://bugs.openjdk.org/browse/JDK-8307478) ,
> the following test started to fail on AIX :
> com/sun/tools/attach/warnings/DynamicLoadWarningTest.java ; failure output :
>
> java.lang.R
On Fri, 16 Jun 2023 10:44:47 GMT, Matthias Baesken wrote:
> After push of [JDK-8307478](https://bugs.openjdk.org/browse/JDK-8307478) ,
> the following test started to fail on AIX :
> com/sun/tools/attach/warnings/DynamicLoadWarningTest.java ; failure output :
>
> java.lang.R
Currently, a number of tests fail on macOS because they miss the core file
(e.g. serviceability/sa/TestJmapCore.java).
The reason is that configure detects on some setups that codesign does not work
("checking if debug mode codesign is possible... no) .
So adding the needed entitlement to generat
8309549: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java fails on AIX
-
Commit messages:
- Backport 4d66d977450e083214da3dba6ad4ed851c6c1cb4
Changes: https://git.openjdk.org/jdk21/pull/44/files
Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=44&range=00
Issue: https:
On Wed, 21 Jun 2023 07:29:03 GMT, Matthias Baesken wrote:
> 8309549: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java fails on
> AIX
Alan and Lucy , thanks !
-
PR Comment: https://git.openjdk.org/jdk21/pull/44#issuecomment-1600349549
On Wed, 21 Jun 2023 07:29:03 GMT, Matthias Baesken wrote:
> 8309549: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java fails on
> AIX
This pull request has now been integrated.
Changeset: 60cae33c
Author:Matthias Baesken
URL:
https://git.openjdk.org/jdk21/
8310191: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java second
failure on AIX
-
Commit messages:
- Backport 6a63badd8ea3e79cd9fc3cb33aff499fc9a6d3f1
Changes: https://git.openjdk.org/jdk21/pull/45/files
Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=45&range=00
Iss
On Wed, 21 Jun 2023 08:27:38 GMT, Matthias Baesken wrote:
> 8310191: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java second
> failure on AIX
This pull request has now been integrated.
Changeset: 1fc60429
Author:Matthias Baesken
URL:
https://git.openjdk.org/jdk21/
There are a few references to rt.jar in comments and in the codebase itself.
Some of them might be removed or adjusted.
-
Commit messages:
- JDK-8310550
Changes: https://git.openjdk.org/jdk/pull/14593/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14593&range=00
Issue: h
On Wed, 21 Jun 2023 15:25:15 GMT, Christoph Langer wrote:
>> Currently, a number of tests fail on macOS because they miss the core file
>> (e.g. serviceability/sa/TestJmapCore.java).
>> The reason is that configure detects on some setups that codesign does not
>> work ("checking if debug mode c
On Wed, 21 Jun 2023 21:46:03 GMT, David Holmes wrote:
>> There are a few references to rt.jar in comments and in the codebase itself.
>> Some of them might be removed or adjusted.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java
> line 196:
>
>> 194:
>> 195:
e needed entitlement to generate cores is not done in the build.
> This is currently not checked later in the tests.
> But without the entitlement, a core is not generated.
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last rev
On Tue, 20 Jun 2023 13:23:16 GMT, Matthias Baesken wrote:
> Currently, a number of tests fail on macOS because they miss the core file
> (e.g. serviceability/sa/TestJmapCore.java).
> The reason is that configure detects on some setups that codesign does not
> work ("check
On Wed, 21 Jun 2023 19:32:23 GMT, Chris Plummer wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Some adjustments
>
> test/lib/jdk/test/lib/util/CoreUtils.java line 131:
e needed entitlement to generate cores is not done in the build.
> This is currently not checked later in the tests.
> But without the entitlement, a core is not generated.
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
On Thu, 22 Jun 2023 09:53:29 GMT, Matthias Baesken wrote:
>> Currently, a number of tests fail on macOS because they miss the core file
>> (e.g. serviceability/sa/TestJmapCore.java).
>> The reason is that configure detects on some setups that codesign does not
>> work
On Thu, 22 Jun 2023 10:54:12 GMT, Christoph Langer wrote:
> Looks a bit better. But I think instead of adding a Utils.javaPath() method,
> you can do all this path handling in Platform.launchCodesignOnJavaBinary().
> Then even more code would be shared.
Okay, I had the idea to later use the
On Thu, 22 Jun 2023 11:51:15 GMT, Matthias Baesken wrote:
>> Currently, a number of tests fail on macOS because they miss the core file
>> (e.g. serviceability/sa/TestJmapCore.java).
>> The reason is that configure detects on some setups that codesign does not
>> work
e needed entitlement to generate cores is not done in the build.
> This is currently not checked later in the tests.
> But without the entitlement, a core is not generated.
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revi
On Thu, 22 Jun 2023 11:51:15 GMT, Matthias Baesken wrote:
>> Currently, a number of tests fail on macOS because they miss the core file
>> (e.g. serviceability/sa/TestJmapCore.java).
>> The reason is that configure detects on some setups that codesign does not
>> work
On Tue, 20 Jun 2023 13:23:16 GMT, Matthias Baesken wrote:
> Currently, a number of tests fail on macOS because they miss the core file
> (e.g. serviceability/sa/TestJmapCore.java).
> The reason is that configure detects on some setups that codesign does not
> work ("check
On Tue, 27 Jun 2023 13:45:27 GMT, Matthias Baesken wrote:
>> Currently, a number of tests fail on macOS because they miss the core file
>> (e.g. serviceability/sa/TestJmapCore.java).
>> The reason is that configure detects on some setups that codesign does not
>> work
On Thu, 22 Jun 2023 14:20:30 GMT, Alan Bateman wrote:
>> There are a few references to rt.jar in comments and in the codebase itself.
>> Some of them might be removed or adjusted.
>
> src/java.sql/share/classes/java/sql/DriverManager.java line 658:
>
>> 656: * (which is invoking this c
On Wed, 28 Jun 2023 13:16:30 GMT, Alan Bateman wrote:
>> Hi Alan, regarding usage of class VM I get
>> 'package jdk.internal.misc is declared in module java.base, which does not
>> export it to module java.sql'
>> Is there any concern to export it as well to module java.sql ?
>> And btw did yo
Most G1 tests set -XX:+UseG1GC, but a few (e.g.
gc/g1/TestVerificationInConcurrentCycle.java) miss that.
This is usually just fine and no problem because G1 is the default anyway.
However in some cases, where a custom JVM changes the default GC, those tests
start to fail which is not really neces
On Wed, 28 Jun 2023 13:22:20 GMT, Matthias Baesken wrote:
>>> Hi Alan, regarding usage of class VM I get 'package jdk.internal.misc is
>>> declared in module java.base, which does not export it to module java.sql'
>>> Is there any concern to export it as
> There are a few references to rt.jar in comments and in the codebase itself.
> Some of them might be removed or adjusted.
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
Adjust comment in src/java.sql/share/classes/ja
> There are a few references to rt.jar in comments and in the codebase itself.
> Some of them might be removed or adjusted.
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
remove import
-
Changes:
- all:
On Fri, 30 Jun 2023 08:11:47 GMT, Matthias Baesken wrote:
> Most G1 tests set -XX:+UseG1GC, but a few (e.g.
> gc/g1/TestVerificationInConcurrentCycle.java) miss that.
> This is usually just fine and no problem because G1 is the default anyway.
> However in some cases, where a custom
On Fri, 30 Jun 2023 08:11:47 GMT, Matthias Baesken wrote:
> Most G1 tests set -XX:+UseG1GC, but a few (e.g.
> gc/g1/TestVerificationInConcurrentCycle.java) miss that.
> This is usually just fine and no problem because G1 is the default anyway.
> However in some cases, where a custom
8310380: Handle problems in core-related tests on macOS when codesign tool does
not work
-
Commit messages:
- Backport 39c104df44f17c1d65e35becd4272f73e2c6610c
Changes: https://git.openjdk.org/jdk21/pull/87/files
Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=87&range=00
Iss
On Fri, 30 Jun 2023 12:35:27 GMT, Matthias Baesken wrote:
> 8310380: Handle problems in core-related tests on macOS when codesign tool
> does not work
This pull request has now been integrated.
Changeset: 6f3f4aa2
Author:Matthias Baesken
URL:
https://git.openjdk.org/jdk21/
> There are a few references to rt.jar in comments and in the codebase itself.
> Some of them might be removed or adjusted.
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
Adjust comments
-
Changes:
- all:
On Fri, 30 Jun 2023 11:37:10 GMT, Matthias Baesken wrote:
>> There are a few references to rt.jar in comments and in the codebase itself.
>> Some of them might be removed or adjusted.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional
> There are a few references to rt.jar in comments and in the codebase itself.
> Some of them might be removed or adjusted.
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
Adjust comment
-
Changes:
- all:
On Wed, 5 Jul 2023 15:07:15 GMT, Matthias Baesken wrote:
>> There are a few references to rt.jar in comments and in the codebase itself.
>> Some of them might be removed or adjusted.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional
There seems to be a case where utf_util.c getWideString might leak memory in an
early return.
-
Commit messages:
- JDK-8292595
Changes: https://git.openjdk.org/jdk/pull/9918/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9918&range=00
Issue: https://bugs.openjdk.org/brow
On Thu, 18 Aug 2022 12:30:57 GMT, Alan Bateman wrote:
>> There seems to be a case where utf_util.c getWideString might leak memory in
>> an early return.
>
> src/jdk.jdwp.agent/share/native/libjdwp/utf_util.c line 346:
>
>> 344: if (MultiByteToWideChar(codePage, 0, str, len, wstr, wlen) ==
On Thu, 18 Aug 2022 11:51:52 GMT, Matthias Baesken wrote:
> There seems to be a case where utf_util.c getWideString might leak memory in
> an early return.
In case of failing getWideString, we have already a fallback in place that is
just copying bytes :
wstr = getWideString(C
There seems to be a case where EncodingSupport_md.c convertUtf8ToPlatformString
might leak memory because of a wrong placing of free..
-
Commit messages:
- JDK-8292778
Changes: https://git.openjdk.org/jdk/pull/9981/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9981&range=
On Tue, 23 Aug 2022 13:59:53 GMT, Matthias Baesken wrote:
> There seems to be a case where EncodingSupport_md.c
> convertUtf8ToPlatformString might leak memory because of a wrong placing of
> free..
Thanks for the reviews !
-
PR: https://git.openjdk.org/jdk/pull/9981
On Tue, 23 Aug 2022 13:59:53 GMT, Matthias Baesken wrote:
> There seems to be a case where EncodingSupport_md.c
> convertUtf8ToPlatformString might leak memory because of a wrong placing of
> free..
This pull request has now been integrated.
Changeset: ad2e0c4d
Author: Matthia
> There seems to be a case where utf_util.c getWideString might leak memory in
> an early return.
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
Introduce UTF_WARNING and use the fallback
-
Changes:
- all:
On Fri, 26 Aug 2022 12:04:57 GMT, Matthias Baesken wrote:
>> There seems to be a case where utf_util.c getWideString might leak memory in
>> an early return.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional commit since the last revis
On Thu, 18 Aug 2022 11:51:52 GMT, Matthias Baesken wrote:
> There seems to be a case where utf_util.c getWideString might leak memory in
> an early return.
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.org/jdk/pull/9918
On Wed, 21 Jun 2023 15:18:19 GMT, Matthias Baesken wrote:
> There are a few references to rt.jar in comments and in the codebase itself.
> Some of them might be removed or adjusted.
This pull request has now been integrated.
Changeset: 25cbe85d
Author:Matthias Baesken
URL:
There is coding e.g. in
https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72
that deals with shared lib naming on different OS.
This code should be simplified.
-
Commit messages:
- JDK-8313670
Changes: https://git.openjdk.org/jd
> There is coding e.g. in
> https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72
> that deals with shared lib naming on different OS.
> This code should be simplified.
Matthias Baesken has updated the pull request incrementa
On Wed, 9 Aug 2023 08:42:35 GMT, Matthias Baesken wrote:
>> There is coding e.g. in
>> https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72
>> that deals with shared lib naming on different OS.
>> This code should be
> There is coding e.g. in
> https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72
> that deals with shared lib naming on different OS.
> This code should be simplified.
Matthias Baesken has updated the pull request incrementa
> There is coding e.g. in
> https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72
> that deals with shared lib naming on different OS.
> This code should be simplified.
Matthias Baesken has updated the pull request incrementa
On Wed, 9 Aug 2023 11:06:04 GMT, Matthias Baesken wrote:
>> There is coding e.g. in
>> https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72
>> that deals with shared lib naming on different OS.
>> This code should be
On Fri, 4 Aug 2023 09:59:41 GMT, Matthias Baesken wrote:
> There is coding e.g. in
> https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72
> that deals with shared lib naming on different OS.
> This code should be simplified
AttachListener::pd_find_operation always returns nullptr and seems to be
obsolete, so we could probably remove it and clean up the coding a bit.
-
Commit messages:
- JDK-8314197
Changes: https://git.openjdk.org/jdk/pull/15265/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=
On Mon, 14 Aug 2023 10:13:21 GMT, Matthias Baesken wrote:
> AttachListener::pd_find_operation always returns nullptr and seems to be
> obsolete, so we could probably remove it and clean up the coding a bit.
Hi David, thanks for the review ! If it is 'trivial' , afaik one revie
On Mon, 14 Aug 2023 10:13:21 GMT, Matthias Baesken wrote:
> AttachListener::pd_find_operation always returns nullptr and seems to be
> obsolete, so we could probably remove it and clean up the coding a bit.
Hi Chris and Serguei, thanks for the reviews !
-
PR Comment:
On Mon, 14 Aug 2023 10:13:21 GMT, Matthias Baesken wrote:
> AttachListener::pd_find_operation always returns nullptr and seems to be
> obsolete, so we could probably remove it and clean up the coding a bit.
This pull request has now been integrated.
Changeset: 63389272
Author:Ma
AttachListener::pd_set_flag is the same across platforms (always returning
JNI_ERR ). So it can be centralized or removed.
-
Commit messages:
- JDK-8314389
Changes: https://git.openjdk.org/jdk/pull/15304/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15304&range=00
Issue
On Wed, 16 Aug 2023 08:09:42 GMT, Matthias Baesken wrote:
> AttachListener::pd_set_flag is the same across platforms (always returning
> JNI_ERR ). So it can be centralized or removed.
Hi Chris, Martin, Serguei, thanks for the reviews !
-
PR Comment: https://git.openjdk.o
On Wed, 16 Aug 2023 08:09:42 GMT, Matthias Baesken wrote:
> AttachListener::pd_set_flag is the same across platforms (always returning
> JNI_ERR ). So it can be centralized or removed.
This pull request has now been integrated.
Changeset: 5058854b
Author:Matthias Baeske
On Tue, 29 Aug 2023 13:46:08 GMT, Matthias Baesken wrote:
> The sun/tools/jhsdb tests have issues when we run them concurrently .
> So add a related config to TEST.root.
Hi Alan and Chris , thanks for the reviews !
-
PR Comment: https://git.openjdk.org/jdk/pull/15469#issuec
On Tue, 29 Aug 2023 13:46:08 GMT, Matthias Baesken wrote:
> The sun/tools/jhsdb tests have issues when we run them concurrently .
> So add a related config to TEST.root.
This pull request has now been integrated.
Changeset: 1e7e2bcf
Author:Matthias Baesken
URL:
There are some remaining places in 'general' JDK code (= code not related to
e.g. a specific tool) getting properties like :
osName = System.getProperty(os.name)
https://github.com/openjdk/jdk/blob/master/src/java.management/share/classes/sun/management/VMManagementImpl.java#L225
https://github
On Fri, 8 Sep 2023 08:26:16 GMT, Matthias Baesken wrote:
> There are some remaining places in 'general' JDK code (= code not related to
> e.g. a specific tool) getting properties like :
>
> osName = System.getProperty(os.name)
>
> https://github.com/openjdk/jdk/blo
On Fri, 8 Sep 2023 14:01:24 GMT, Alexey Ivanov wrote:
> > So what about FontConfiguration? Is that something using the class directly
> > too?
>
> I think this is not needed either. As far as I can see, the instance of
> `FontConfiguration` is created from `doPrivileged`, therefore these two
On Fri, 8 Sep 2023 13:02:07 GMT, Alan Bateman wrote:
> > So probably we could avoid changing VMManagementImpl.java because it is not
> > needed any more at least in jdk-head .
>
> It's a JDK internal class so should never have been used directly. I can't
> imagine what might be using a JDK int
On Fri, 15 Sep 2023 07:22:32 GMT, Joachim Kern wrote:
>> After push of [JDK-8307478](https://bugs.openjdk.org/browse/JDK-8307478) ,
>> the following test started to fail on AIX :
>> com/sun/tools/attach/warnings/DynamicLoadWarningTest.java;
>> The problem was described in
>> [JDK-8309549](https
On Fri, 8 Sep 2023 08:26:16 GMT, Matthias Baesken wrote:
> There are some remaining places in 'general' JDK code (= code not related to
> e.g. a specific tool) getting properties like :
>
> osName = System.getProperty(os.name)
>
> https://github.com/openjdk/jdk/blo
The allow option of agentlib:jdwp has been introduced a long time ago (see
JDK-8061228) and is documented here :
https://docs.oracle.com/en/java/javase/17/docs/specs/jpda/conninv.html#oracle-vm-invocation-options
However it is still missing in the agentlib:jdwp help output and should be
added the
nd should be
> added there too.
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
More info about address lists
-
Changes:
- all: https://git.openjdk.org/jdk/pull/16393/files
- new: https://git.openjdk.org/jdk/p
1 - 100 of 324 matches
Mail list logo
