Rename various 'jvm' variables to 'jvm_' to avoid duplicate symbol
problems when statically linking the launcher executable with JDK native
libraries.
8305761: Resolve multiple definition of 'jvm' when statically linking with JDK
native libraries
-
Commit messages:
- Resolve link
On Fri, 7 Apr 2023 23:32:46 GMT, Jiangli Zhou wrote:
> Rename various 'jvm' variables to 'jvm_' to avoid duplicate symbol
> problems when statically linking the launcher executable with JDK native
> libraries.
>
> 8305761: Resolve multiple definition of
… with JDK native libraries
-
Commit messages:
- 8305761: Resolve multiple definition of 'jvm' when statically linking with
JDK native libraries
Changes: https://git.openjdk.org/jdk/pull/13397/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13397&range=00
Issue: https://b
On Mon, 10 Apr 2023 13:52:39 GMT, Alan Bateman wrote:
>> Rename various 'jvm' variables to 'jvm_' to avoid duplicate symbol
>> problems when statically linking the launcher executable with JDK native
>> libraries.
>
> src/java.management/share/native/libmanagement/management.c line 36:
>
>> 34
> Rename various 'jvm' variables to 'jvm_' to avoid duplicate symbol
> problems when statically linking the launcher executable with JDK native
> libraries.
Jiangli Zhou has updated the pull request incrementally with one additional
commit since the last revisio
On Sat, 8 Apr 2023 01:11:08 GMT, Jiangli Zhou wrote:
> Rename various 'jvm' variables to 'jvm_' to avoid duplicate symbol
> problems when statically linking the launcher executable with JDK native
> libraries.
This pull request has now been integrated.
Changeset
On Mon, 10 Apr 2023 19:38:18 GMT, Jiangli Zhou wrote:
>> Rename various 'jvm' variables to 'jvm_' to avoid duplicate symbol
>> problems when statically linking the launcher executable with JDK native
>> libraries.
>
> Jiangli Zhou has updated the pu
Rename 'jmm_' to 'jmm__management_ext' in
libmanagement_ext to resolve related linker errors when statically linking with
both libmanagement and libmanagement_ext.
-
Commit messages:
- 8305935: Resolve multiple definition of 'jmm_' when
statically linking with JDK native libraries
On Thu, 13 Apr 2023 06:56:46 GMT, David Holmes wrote:
> Is there not a way to stop these from being exported from the library, as I
> assume they are not actually intended for external use. ??
Good question.
We could make those as weak symbols as long as there is no concern about
portability.
On Thu, 13 Apr 2023 20:04:15 GMT, Jiangli Zhou wrote:
>> src/jdk.management/share/native/libmanagement_ext/management_ext.c line 36:
>>
>>> 34: const JmmInterface* jmm_interface_management_ext = NULL;
>>> 35: static JavaVM* jvm = NULL;
>>> 36: jint jm
On Thu, 13 Apr 2023 23:07:23 GMT, David Holmes wrote:
>> I'm not familiar with the details of symbol scoping and linkage with
>> libraries, but I would have hoped there was a way to have symbols like this
>> shareable throughout the code that comprises the library without exposing
>> them to u
On Fri, 14 Apr 2023 00:34:14 GMT, Jiangli Zhou wrote:
>>> The direct renaming in this case seems to be more strait forward.
>>
>> If we were to do this then we should have a naming convention of some kind
>> e.g. `_` but it strikes me as wrong as the code
>
On Fri, 14 Apr 2023 00:54:22 GMT, Jiangli Zhou wrote:
>>> I'm not familiar with the details of symbol scoping and linkage with
>>> libraries, but I would have hoped there was a way to have symbols like this
>>> shareable throughout the code that comprises the li
> Rename 'jmm_' to 'jmm__management_ext'
> in libmanagement_ext to resolve related linker errors when statically linking
> with both libmanagement and libmanagement_ext.
Jiangli Zhou has updated the pull request incrementally with one additional
commit since the
On Wed, 12 Apr 2023 23:35:02 GMT, Jiangli Zhou wrote:
> Rename 'jmm_' to 'jmm__management_ext'
> in libmanagement_ext to resolve related linker errors when statically linking
> with both libmanagement and libmanagement_ext.
Thanks for the review and discussio
On Fri, 14 Apr 2023 05:20:48 GMT, David Holmes wrote:
>> src/jdk.management/share/native/libmanagement_ext/management_ext.c line 34:
>>
>>> 32: #define ERR_MSG_SIZE 128
>>> 33:
>>> 34: const JmmInterface* jmm_interface_management_ext = NULL;
>>
>> Can you add a comment before declaring the two
On Wed, 12 Apr 2023 23:35:02 GMT, Jiangli Zhou wrote:
> Rename 'jmm_' to 'jmm__management_ext'
> in libmanagement_ext to resolve related linker errors when statically linking
> with both libmanagement and libmanagement_ext.
This pull request has now been int
- Make functions 'static' when feasible:
- throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c.
- throwByName(), throwIOException() and throwNullPointerException() in
src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c.
- throwByName() in
src/jdk.crypto.cryptoki/shar
On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou wrote:
> - Make functions 'static' when feasible:
> - throwByName() in
> src/java.security.jgss/share/native/libj2gss/NativeUtil.c.
> - throwByName(), throwIOException() and throwNullPointerException() in
> src/jav
On Wed, 19 Apr 2023 11:01:07 GMT, Jaikiran Pai wrote:
> Even if it doesn't get enrolled in the pre-submit testing, I think the fact
> that there will be a build within the JDK which can catch these issues is a
> good thing. It might catch the issue(s) after the integration, but I think
> it's
On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou wrote:
> - Make functions 'static' when feasible:
> - throwByName() in
> src/java.security.jgss/share/native/libj2gss/NativeUtil.c.
> - throwByName(), throwIOException() and throwNullPointerException() in
> src/jav
On Mon, 24 Apr 2023 22:41:53 GMT, Mark Powers wrote:
> Update copyrights to 2023.
Done, thanks.
> src/java.security.jgss/share/native/libj2gss/GSSLibStub.c line 201:
>
>> 199: cb = malloc(sizeof(struct gss_channel_bindings_struct));
>> 200: if (cb == NULL) {
>> 201: gssThrowOutOfMemory
other throw functions.
>
> - Remove throw_internal_error() from
> src/java.management/share/native/libmanagement/management.h and
> src/java.management/share/native/libmanagement/management.c. It's not used.
> - Remove throw_internal_error() from
> src/jdk.management/share/n
On Tue, 25 Apr 2023 00:47:17 GMT, Jiangli Zhou wrote:
>> - Make functions 'static' when feasible:
>> - throwByName() in
>> src/java.security.jgss/share/native/libj2gss/NativeUtil.c.
>> - throwByName(), throwIOException() and throwNullPointerException(
On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou wrote:
> - Make functions 'static' when feasible:
> - throwByName() in
> src/java.security.jgss/share/native/libj2gss/NativeUtil.c.
> - throwByName(), throwIOException() and throwNullPointerException() in
> src/jav
Please review this simple change from @cjmoon1 for resolving static linking
issue caused by multiple definition of 'normalize'. @cjmoon1's branch can be
found at:
https://github.com/openjdk/jdk/compare/master...cjmoon1:jdk:fix_normalize.
The change incorporated suggestions from both @sspitsyn a
On Wed, 30 Aug 2023 02:45:42 GMT, David Holmes wrote:
> I'm sure I've said it before but there has to be a better way to handle this.
> We should not have to rename perfectly well-named functions to insert a
> unique prefix due to static linking conflicts. If this were C++ code rather
> than C
On Thu, 31 Aug 2023 04:53:26 GMT, David Holmes wrote:
> No not namespaces, just by using C++ so it a member function, then C++ name
> mangling would mean the symbol would be different to some same-named function
> in some other library - in essence the class name part of the symbol would
> pro
On Thu, 31 Aug 2023 05:00:18 GMT, David Holmes wrote:
> Is `normalize` the only function that causes a conflict and the other changes
> are just for consistency? If so please just rename normalize to e.g.
> `normalize_path`
Right, only `normalize` showed up in our testing so far. I suggested @
rg/browse/JDK-8313277?focusedCommentId=14604187&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14604187
Jiangli Zhou has updated the pull request incrementally with one additional
commit since the last revision:
Update from @cjmoon1 to incorporate @dholme
On Fri, 1 Sep 2023 21:11:03 GMT, Jiangli Zhou wrote:
>> Please review this simple change from @cjmoon1 for resolving static linking
>> issue caused by multiple definition of 'normalize'. @cjmoon1's branch can be
>> found at:
>> https://github.c
On Fri, 1 Sep 2023 21:11:03 GMT, Jiangli Zhou wrote:
>> Please review this simple change from @cjmoon1 for resolving static linking
>> issue caused by multiple definition of 'normalize'. @cjmoon1's branch can be
>> found at:
>> https://github.c
On Tue, 29 Aug 2023 23:37:06 GMT, Jiangli Zhou wrote:
> Please review this simple change from @cjmoon1 for resolving static linking
> issue caused by multiple definition of 'normalize'. @cjmoon1's branch can be
> found at:
> https://github.com/openjdk/j
Please review JvmtiThreadState::state_for_while_locked change to handle the
state->get_thread_oop() null case. Please see
https://bugs.openjdk.org/browse/JDK-8319935 for details.
-
Commit messages:
- 8319935: Ensure only one JvmtiThreadState is create for one JavaThread
associated
On Mon, 13 Nov 2023 22:15:18 GMT, Daniel D. Daugherty
wrote:
> @jianglizhou - I fixed a typo in the bug's synopsis line. Change this PR's
> title: s/is create/is created/
Thanks, @dcubed-ojdk!
-
PR Comment: https://git.openjdk.org/jdk/pull/16642#issuecomment-1809279446
On Mon, 13 Nov 2023 23:21:56 GMT, Man Cao wrote:
>> Please review JvmtiThreadState::state_for_while_locked change to handle the
>> state->get_thread_oop() null case. Please see
>> https://bugs.openjdk.org/browse/JDK-8319935 for details.
>
> src/hotspot/share/prims/jvmtiThreadState.inline.hpp li
On Tue, 14 Nov 2023 03:10:20 GMT, David Holmes wrote:
> Is this a case where the code should be checking for `is_attaching_via_jni()`?
That's a good question. I think maybe we should try to completely avoid the
situation where a 'partial' `JvmtiThreadState` is created when a native thread
is a
> Please review JvmtiThreadState::state_for_while_locked change to handle the
> state->get_thread_oop() null case. Please see
> https://bugs.openjdk.org/browse/JDK-8319935 for details.
Jiangli Zhou has updated the pull request incrementally with one additional
commit since the l
On Mon, 13 Nov 2023 23:04:19 GMT, Man Cao wrote:
>> Jiangli Zhou has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Don't try to setup_jvmti_thread_state for obj allocation sampling if the
>> current thr
On Tue, 14 Nov 2023 20:57:09 GMT, Jiangli Zhou wrote:
>> Please review JvmtiThreadState::state_for_while_locked change to handle the
>> state->get_thread_oop() null case. Please see
>> https://bugs.openjdk.org/browse/JDK-8319935 for details.
>
> Jiangli Zhou h
> Please review JvmtiThreadState::state_for_while_locked change to handle the
> state->get_thread_oop() null case. Please see
> https://bugs.openjdk.org/browse/JDK-8319935 for details.
Jiangli Zhou has updated the pull request incrementally with one additional
commit since the l
On Thu, 16 Nov 2023 09:48:48 GMT, David Holmes wrote:
>> Jiangli Zhou has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Don't try to setup_jvmti_thread_state for obj allocation sampling if the
>> curr
> Please review JvmtiThreadState::state_for_while_locked change to handle the
> state->get_thread_oop() null case. Please see
> https://bugs.openjdk.org/browse/JDK-8319935 for details.
Jiangli Zhou has updated the pull request with a new target base due to a merge
or a rebase. The
> Please review JvmtiThreadState::state_for_while_locked change to handle the
> state->get_thread_oop() null case. Please see
> https://bugs.openjdk.org/browse/JDK-8319935 for details.
Jiangli Zhou has updated the pull request incrementally with one additional
commit since the l
On Wed, 22 Nov 2023 02:53:23 GMT, David Holmes wrote:
>> src/hotspot/share/prims/jvmtiExport.cpp line 3144:
>>
>>> 3142: // If the current thread is attaching from native and its thread
>>> oop is being
>>> 3143: // allocated, things are not ready for allocation sampling.
>>> 3144: if (th
On Tue, 21 Nov 2023 23:32:13 GMT, Serguei Spitsyn wrote:
>> Jiangli Zhou has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add a check for a thread is_attaching_via_jni, based on David Holmes'
>> c
On Fri, 17 Nov 2023 02:51:03 GMT, Jiangli Zhou wrote:
>> Jiangli Zhou has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Don't try to setup_jvmti_thread_state for obj allocation sampling if the
>> curr
On Wed, 22 Nov 2023 01:24:46 GMT, Serguei Spitsyn wrote:
> Thank you for filing and fixing this issue! I'm kind of late here. Sorry for
> that. Is it hard to create a JTreg test for an attaching native thread? I can
> help if you have a standalone prototype. You can look for some examples in
>
On Tue, 28 Nov 2023 05:08:58 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmtiThreadState.inline.hpp line 98:
>>
>>> 96:state->get_thread_oop() != thread_oop)) {
>>> 97: // Check if java_lang_Thread already has a link to the
>>> JvmtiThreadState.
>>> 9
On Tue, 28 Nov 2023 20:43:15 GMT, Serguei Spitsyn wrote:
> This fix looks good to me, so approved now. I assume it is for 22. Is it
> correct?
Thanks for the careful review, @sspitsyn! The fix is for 22. We probably should
also consider back-porting to JDK 11 to prevent any potential changes i
On Thu, 16 Nov 2023 21:58:17 GMT, Man Cao wrote:
>> Jiangli Zhou has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Don't try to setup_jvmti_thread_state for obj allocation sampling if the
>> current thr
On Tue, 28 Nov 2023 21:28:31 GMT, Jiangli Zhou wrote:
>> This fix looks good to me, so approved now.
>> I assume it is for 22. Is it correct?
>
>> This fix looks good to me, so approved now. I assume it is for 22. Is it
>> correct?
>
> Thanks for the careful
On Mon, 13 Nov 2023 21:52:22 GMT, Jiangli Zhou wrote:
> Please review JvmtiThreadState::state_for_while_locked change to handle the
> state->get_thread_oop() null case. Please see
> https://bugs.openjdk.org/browse/JDK-8319935 for details.
This pull request has now been integrated
On Wed, 29 Nov 2023 23:06:10 GMT, Daniel D. Daugherty
wrote:
> A belated thumbs up. Sorry I didn't get back to this review before the fix
> was integrated.
Still thanks for reviewing the change, @dcubed-ojdk.
>
> I found just a nit comment that could be more clear.
The particular issue occu
On Sat, 2 Dec 2023 17:15:57 GMT, Daniel D. Daugherty wrote:
> In the fix for the following bug:
>
> [JDK-8319935](https://bugs.openjdk.org/browse/JDK-8319935) Ensure only one
> JvmtiThreadState is created for one JavaThread associated with attached
> native thread
>
> JvmtiThreadState::state_
On Mon, 4 Dec 2023 05:16:59 GMT, Jiangli Zhou wrote:
>> In the fix for the following bug:
>>
>> [JDK-8319935](https://bugs.openjdk.org/browse/JDK-8319935) Ensure only one
>> JvmtiThreadState is created for one JavaThread associated with attached
>> native
On Mon, 4 Dec 2023 18:16:52 GMT, Daniel D. Daugherty wrote:
>> In the fix for the following bug:
>>
>> [JDK-8319935](https://bugs.openjdk.org/browse/JDK-8319935) Ensure only one
>> JvmtiThreadState is created for one JavaThread associated with attached
>> native thread
>>
>> JvmtiThreadState:
On Mon, 4 Dec 2023 20:52:46 GMT, Daniel D. Daugherty wrote:
>>> @jianglizhou - Thanks for doing the testing. Can you also do a review? We
>>> need two reviewers for this change.
>>
>> Complete test run finished. Checking the results, looks like there's no
>> issue related to JVMTIThreadState c
On Mon, 4 Dec 2023 20:52:46 GMT, Daniel D. Daugherty wrote:
> In the interest of reducing the noise in the Mach5 CI, I'm going ahead with
> integrating this fix without waiting for a reply to my comment above. If
> there are remaining issues, then we'll deal with them in a follow-up bug/RFE.
T
Please review this PR with a simple solution for resolving duplicate `Thread`
symbol issue. In https://github.com/openjdk/jdk/pull/14808 comments, there was
an alternative suggestion to redefine the symbol at build time, such as
using`-DThread=HotSpotThread`. That would not address issues when
On Wed, 17 Jan 2024 10:07:15 GMT, Andrew Haley wrote:
>> Please review this PR with a simple solution for resolving duplicate
>> `Thread` symbol issue. In https://github.com/openjdk/jdk/pull/14808
>> comments, there was an alternative suggestion to redefine the symbol at
>> build time, such as
On Wed, 17 Jan 2024 23:06:19 GMT, Coleen Phillimore wrote:
>> Please review this PR with a simple solution for resolving duplicate
>> `Thread` symbol issue. In https://github.com/openjdk/jdk/pull/14808
>> comments, there was an alternative suggestion to redefine the symbol at
>> build time, su
On Fri, 19 Jan 2024 01:57:58 GMT, David Holmes wrote:
> > It seems that we may be converging on using hotspot namespace?
>
> Based on previous discussions I had been expecting to see a JEP on this after
> last US summer. I was surprised to see this PR pop up in this form.
Ah, I see. Thanks for
On Fri, 19 Jan 2024 08:58:29 GMT, Andrew Haley wrote:
> > > > It seems that we may be converging on using hotspot namespace?
> > >
> > >
> > > Based on previous discussions I had been expecting to see a JEP on this
> > > after last US summer. I was surprised to see this PR pop up in this form.
On Fri, 19 Jan 2024 14:00:58 GMT, Coleen Phillimore wrote:
> You could support one build by adding something like -DSUPPORTS_STATIC_LINK
> for both .so and .a builds for Google, then use that to protect the renaming.
Thanks, @coleenp. I think that could work for all different cases. I'll reflec
On Sat, 20 Jan 2024 18:00:15 GMT, Andrew Haley wrote:
> > > You could support one build by adding something like
> > > -DSUPPORTS_STATIC_LINK for both .so and .a builds for Google, then use
> > > that to protect the renaming.
> >
> >
> > Thanks, @coleenp. I think that could work for all diffe
On Wed, 24 Jan 2024 09:29:16 GMT, Andrew Haley wrote:
> > > I think you should be able to use ld and objcopy to merge the .o files
> > > and hide all of the symbols you don't want to export.
> >
> >
> > We also discussed about `objcopy` in [#14808
> > (comment)](https://github.com/openjdk/jdk
On Mon, 29 Jan 2024 09:42:20 GMT, Andrew Haley wrote:
> > Maybe we could live with symbol redefinition using #define (conditionally
> > for static linking in OpenJDK, as Coleen suggested earlier) for now, until
> > the tooling can support symbol localizing better. Then localizing symbols
> > u
On Wed, 17 Jan 2024 00:14:58 GMT, Jiangli Zhou wrote:
> Please review this PR with a simple solution for resolving duplicate `Thread`
> symbol issue. In https://github.com/openjdk/jdk/pull/14808 comments, there
> was an alternative suggestion to redefine the symbol at build time
Please help review this trivial fix for resolving `ld: error: duplicate symbol:
closeDescriptors` when static linking with both libjdwp and libjava, thanks.
-
Commit messages:
- Make closeDescriptors() as static function in
src/java.base/unix/native/libjava/childproc.c and
src/jdk
On Mon, 26 Feb 2024 20:40:52 GMT, Chris Plummer wrote:
>> Please help review this trivial fix for resolving `ld: error: duplicate
>> symbol: closeDescriptors` when static linking with both libjdwp and libjava,
>> thanks.
>
> src/java.base/unix/native/libjava/childproc.h line 134:
>
>> 132: int
> Please help review this trivial fix for resolving `ld: error: duplicate
> symbol: closeDescriptors` when static linking with both libjdwp and libjava,
> thanks.
Jiangli Zhou has updated the pull request incrementally with two additional
commits since the last revision:
On Mon, 26 Feb 2024 22:15:00 GMT, Jiangli Zhou wrote:
>> src/java.base/unix/native/libjava/childproc.h line 134:
>>
>>> 132: int closeSafely(int fd);
>>> 133: int isAsciiDigit(char c);
>>> 134: int closeDescriptors(void);
>>
>> It seems tha
On Mon, 26 Feb 2024 20:37:45 GMT, Chris Plummer wrote:
>> Jiangli Zhou has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Address plummercj's comment and make forkedChildProcess static.
>> - Rever
On Mon, 26 Feb 2024 23:50:11 GMT, Chris Plummer wrote:
> Looks good.
Thanks for the quick review, @plummercj.
-
PR Comment: https://git.openjdk.org/jdk/pull/18013#issuecomment-1965539618
On Tue, 27 Feb 2024 00:34:49 GMT, Serguei Spitsyn wrote:
>> Jiangli Zhou has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Address plummercj's comment and make forkedChildProcess static.
>> - Rever
On Mon, 26 Feb 2024 20:20:31 GMT, Jiangli Zhou wrote:
> Please help review this trivial fix for resolving `ld: error: duplicate
> symbol: closeDescriptors` when static linking with both libjdwp and libjava,
> thanks.
This pull request has now been integrated.
Changeset: 0901de
On Fri, 8 Mar 2024 02:35:08 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
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 Thu, 22 Aug 2024 00:30:07 GMT, Jiangli Zhou wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Also update build to link properly
>
> I compared the extracted changes in thi
On Tue, 27 Aug 2024 13:55:51 GMT, Magnus Ihse Bursie wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Also update build to link properly
>
> And the discussion whether the checks are made "dynamically" or "sta
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 Tue, 27 Aug 2024 13:55:51 GMT, Magnus Ihse Bursie wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Also update build to link properly
>
> And the discussion whether the checks are made "dynamically" or "sta
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 slight
On Thu, 29 Aug 2024 08:26:16 GMT, Magnus Ihse Bursie wrote:
> Okay. Unless I misunderstand something, there were no additional authors to
> be credited for these two commits.
That's correct for these.
-
PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2317982354
> Please review this trivial fix that adds missing DEF_STATIC_JNI_OnLoad in
> libjimage and libsaproc native libraries. Thanks.
Jiangli Zhou has updated the pull request incrementally with one additional
commit since the last revision:
Fix macos build issue.
-
Changes:
On Mon, 4 Nov 2024 00:28:46 GMT, Jiangli Zhou wrote:
>> Please review this trivial fix that adds missing DEF_STATIC_JNI_OnLoad in
>> libjimage and libsaproc native libraries. Thanks.
>
> Jiangli Zhou has updated the pull request incrementally with one additional
>
On Sun, 3 Nov 2024 20:19:47 GMT, Jiangli Zhou wrote:
> Please review this trivial fix that adds missing DEF_STATIC_JNI_OnLoad in
> libjimage and libsaproc native libraries. Thanks.
This pull request has now been integrated.
Changeset: 774de278
Author:Jiangli Zhou
URL:
Please review this trivial fix that adds missing DEF_STATIC_JNI_OnLoad in
libjimage and libsaproc native libraries. Thanks.
-
Commit messages:
- Add DEF_STATIC_JNI_OnLoad to libjimage and libsaproc native libraries.Q
Changes: https://git.openjdk.org/jdk/pull/21861/files
Webrev: h
Please review the fix in following tests to not check for shared libraries when
running on static JDK:
test/hotspot/jtreg/serviceability/dcmd/vm/DynLibsTest.java
test/hotspot/jtreg/serviceability/dcmd/vm/SystemDumpMapTest.java
test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTest.java
Please review the test fix that removes `libVThreadEventTest` explicit
dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in
`Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. With
the change, `libVThreadEventTest` no longer needs to be linked with `libj
On Fri, 28 Feb 2025 01:40:34 GMT, Jiangli Zhou wrote:
> Please review the test fix that removes `libVThreadEventTest` explicit
> dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in
> `Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. Wi
On Mon, 3 Mar 2025 17:36:00 GMT, Jiangli Zhou wrote:
>> Please review the test fix that removes `libVThreadEventTest` explicit
>> dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in
>> `Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAtt
On Sat, 22 Feb 2025 03:31:53 GMT, Jiangli Zhou wrote:
> Please review the fix in following tests to not check for shared libraries
> when running on static JDK:
>
> test/hotspot/jtreg/serviceability/dcmd/vm/DynLibsTest.java
> test/hotspot/jtreg/serviceability/dcmd/vm/SystemD
iceability/dcmd/vm/SystemMapTest.java
Jiangli Zhou has updated the pull request incrementally with one additional
commit since the last revision:
Address @tstuefe review:
- Renamed shouldMatchUnconditionally__libjvm to shouldMatch__libjvm
in SystemMapTestBase.
- Added comments to shouldMatchUncondition
On Thu, 13 Mar 2025 19:35:27 GMT, Thomas Stuefe wrote:
>> Jiangli Zhou has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address @tstuefe review:
>> - Renamed shouldMatchUnconditionally__libjvm
On Tue, 4 Mar 2025 19:05:57 GMT, Alan Bateman wrote:
> I'm not familiar with details of the output from the System.map command but
> the change looks reasonable, hopefully @tstuefe or someone familar with this
> command and these tests can review.
Thanks, @AlanBateman!
Could anyone help revie
On Fri, 28 Feb 2025 01:40:34 GMT, Jiangli Zhou wrote:
> Please review the test fix that removes `libVThreadEventTest` explicit
> dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in
> `Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. Wi
On Sat, 22 Feb 2025 03:31:53 GMT, Jiangli Zhou wrote:
> Please review the fix in following tests to not check for shared libraries
> when running on static JDK:
>
> test/hotspot/jtreg/serviceability/dcmd/vm/DynLibsTest.java
> test/hotspot/jtreg/serviceability/dcmd/vm/SystemD
Please review this fix that avoids `JvmtiAgent::convert_xrun_agent` from
prematurely exiting VM if `lookup_On_Load_entry_point` cannot load the agent
using `JVM_OnLoad` symbol. Thanks
`lookup_On_Load_entry_point` first tries to load the builtin agent from the
executable by checking the requeste
1 - 100 of 105 matches
Mail list logo
