On Mon, 26 Feb 2024 17:34:55 GMT, Magnus Ihse Bursie wrote:
>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
>> compiler options and `JNIEXPORT` on all platforms.
>>
>> The bug that this PR solves,
>> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), wa
On Mon, 26 Feb 2024 17:34:55 GMT, Magnus Ihse Bursie wrote:
>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
>> compiler options and `JNIEXPORT` on all platforms.
>>
>> The bug that this PR solves,
>> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), wa
On Fri, 23 Feb 2024 13:54:36 GMT, Erik Joelsson wrote:
> > I just realized I could keep an extremely simplified linker script
> > ("mapfile") for gcc, and thereby keeping the `@SUNWprivate_1.1` on the
> > exported symbols, and keeping `__bss_start` and friends local. This further
> > minimizes
On Mon, 26 Feb 2024 16:18:14 GMT, Magnus Ihse Bursie wrote:
>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
>> compiler options and `JNIEXPORT` on all platforms.
>>
>> The bug that this PR solves,
>> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), wa
> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
> compiler options and `JNIEXPORT` on all platforms.
>
> The bug that this PR solves,
> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in
> 2013. Even back then the use of mapfiles in Hotspot
On Mon, 26 Feb 2024 16:18:14 GMT, Magnus Ihse Bursie wrote:
>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
>> compiler options and `JNIEXPORT` on all platforms.
>>
>> The bug that this PR solves,
>> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), wa
> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
> compiler options and `JNIEXPORT` on all platforms.
>
> The bug that this PR solves,
> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in
> 2013. Even back then the use of mapfiles in Hotspot
On Fri, 23 Feb 2024 12:38:56 GMT, Daniel Jeliński wrote:
> Great. The only remaining difference I see is that the PR adds the following
> export:
>
> ```
> _ZGRN14AsyncLogWriter4NoneE_@@SUNWprivate_1.1
> ```
>
> Any idea what it might be? If not, I guess we can live with that.
No. I vaguely r
On Fri, 23 Feb 2024 12:38:23 GMT, Magnus Ihse Bursie wrote:
>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
>> compiler options and `JNIEXPORT` on all platforms.
>>
>> The bug that this PR solves,
>> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), wa
On Thu, 22 Feb 2024 13:36:23 GMT, Magnus Ihse Bursie wrote:
> I just realized I could keep an extremely simplified linker script
> ("mapfile") for gcc, and thereby keeping the `@SUNWprivate_1.1` on the
> exported symbols, and keeping `__bss_start` and friends local. This further
> minimizes th
On Thu, 22 Feb 2024 15:26:34 GMT, Magnus Ihse Bursie wrote:
>> I see, seems like it's an unfortunate situation where a fix is hard or even
>> impossible. If we file a gcc bug for it now, it'll get fixed in some
>> insanely new gcc version (such as gcc 15 or 16) and we'd have to jump to
>> that
On Fri, 23 Feb 2024 08:18:17 GMT, Daniel Jeliński wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Use #pragma instead of HIDDEN define
>
> src/hotspot/share/oops/accessBackend.cpp line 40:
>
>> 38: #if defin
On Fri, 23 Feb 2024 12:38:23 GMT, Magnus Ihse Bursie wrote:
>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
>> compiler options and `JNIEXPORT` on all platforms.
>>
>> The bug that this PR solves,
>> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), wa
On Fri, 23 Feb 2024 12:33:48 GMT, Magnus Ihse Bursie wrote:
> > We had the PR in our SAP internal build/test queue, so issues seen with it.
>
> What issues did you see? Or was that a typo for "no issues"?
Sorry Magnus, tests were fine no issues were observed.
-
PR Comment: https:/
On Thu, 22 Feb 2024 16:15:23 GMT, Magnus Ihse Bursie wrote:
>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
>> compiler options and `JNIEXPORT` on all platforms.
>>
>> The bug that this PR solves,
>> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), wa
> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
> compiler options and `JNIEXPORT` on all platforms.
>
> The bug that this PR solves,
> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in
> 2013. Even back then the use of mapfiles in Hotspot
On Fri, 23 Feb 2024 11:01:47 GMT, Magnus Ihse Bursie wrote:
> Just to confirm: this PR passes tier 1-5.
We had the PR in our SAP internal build/test queue, so issues seen with it.
-
PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1961232277
On Thu, 22 Feb 2024 16:15:23 GMT, Magnus Ihse Bursie wrote:
>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
>> compiler options and `JNIEXPORT` on all platforms.
>>
>> The bug that this PR solves,
>> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), wa
On Thu, 22 Feb 2024 16:15:23 GMT, Magnus Ihse Bursie wrote:
>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
>> compiler options and `JNIEXPORT` on all platforms.
>>
>> The bug that this PR solves,
>> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), wa
On Thu, 22 Feb 2024 09:26:23 GMT, Magnus Ihse Bursie wrote:
> I tried to be clear, but apparently I failed: There is no change to these
> symbols in the patch! So everything should work just as before!
Yes but "should work" and "does work" may not be the same unless you have
actually verified
On Thu, 22 Feb 2024 20:38:42 GMT, Mikael Vidstedt wrote:
> Just a thought: Perhaps worth introducing some kind of macro that captures
> defining a symbol in assembly code (something that does .globl + .hidden on
> Linux and .private_extern on __APPLE__?
I have thought the same. :) There seem t
On Thu, 22 Feb 2024 16:15:23 GMT, Magnus Ihse Bursie wrote:
>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
>> compiler options and `JNIEXPORT` on all platforms.
>>
>> The bug that this PR solves,
>> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), wa
On Thu, 22 Feb 2024 16:15:23 GMT, Magnus Ihse Bursie wrote:
>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
>> compiler options and `JNIEXPORT` on all platforms.
>>
>> The bug that this PR solves,
>> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), wa
> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
> compiler options and `JNIEXPORT` on all platforms.
>
> The bug that this PR solves,
> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in
> 2013. Even back then the use of mapfiles in Hotspot
On Thu, 22 Feb 2024 14:40:36 GMT, Julian Waters wrote:
>> Windows:
>> Attach Visual Studio,
>> in the Immediate Window, type (funny VS syntax I do not claim to understand):
>>
>> {,,JVM}universe()
>>
>> ...and on the JVM's console window I see:
>>
>> "Executing universe"
>> Heap
>> garbage-fi
On Thu, 22 Feb 2024 14:11:54 GMT, Julian Waters wrote:
>> Well, I hope that can be done, but it depends... As I see it, there are
>> three possible ways to get rid of this `HIDDEN`.
>>
>> 1) Accept that we export these functions on gcc, and just remove the
>> attribute. (Kind of capitulating t
On Thu, 22 Feb 2024 14:28:48 GMT, Erik Joelsson wrote:
> Regarding SUNWprivate_1.1, reading
> [JDK-4916160](https://bugs.openjdk.org/browse/JDK-4916160) it seems like it
> could cause problems for native user libraries linked against an older JDK
> version if we remove it. I think this is what
On Thu, 22 Feb 2024 14:33:18 GMT, Kevin Walls wrote:
> (I do like that we call it jvm.dll.map now, not just "jvm.map"!)
You can thank @fthevenet for that! :)
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1499355063
On Thu, 22 Feb 2024 09:53:53 GMT, Magnus Ihse Bursie wrote:
> The difference is that the data (variable) symbols __bss_start, _edata and
> _end, and the text (function) symbols _fini and _init has changed from local
> to global. Afaik, these are symbols created by the linker. Also, when we used
> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
> compiler options and `JNIEXPORT` on all platforms.
>
> The bug that this PR solves,
> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in
> 2013. Even back then the use of mapfiles in Hotspot
On Thu, 22 Feb 2024 14:05:28 GMT, Kevin Walls wrote:
>> Ok, I see now that there is indeed a slight difference. The debug.cpp
>> symbols are present as local symbols in the .symtab, both before and after
>> this patch. However, before this patch they had visibility DEFAULT and now
>> they have
On Thu, 22 Feb 2024 13:52:26 GMT, Magnus Ihse Bursie wrote:
>> Oh no, by fix I meant removing the HIDDEN attribute and somehow fixing that
>> issue differently, not replacing everything with C++ Attributes!
>
> Well, I hope that can be done, but it depends... As I see it, there are three
> poss
On Thu, 22 Feb 2024 13:28:43 GMT, Magnus Ihse Bursie wrote:
>> Your comment had me go and elfdump the entire libjvm.so and compare the
>> entire output... :-) Now at least I understand why there were so many
>> spurious changes in the linux binary -- the old symbols were named e.g.
>> `JVM_Mon
On Thu, 22 Feb 2024 10:18:21 GMT, Julian Waters wrote:
>> You mean making a search/replace from `__attribute__ ((foo))` to
>> `[[gnu::foo)]]` in the code base? It seems a bit like unnecessary churn to
>> me. We have 100+ places in the code with `__attribute__`. If you really want
>> to try to
> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
> compiler options and `JNIEXPORT` on all platforms.
>
> The bug that this PR solves,
> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in
> 2013. Even back then the use of mapfiles in Hotspot
On Thu, 22 Feb 2024 10:27:06 GMT, Magnus Ihse Bursie wrote:
>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
>> compiler options and `JNIEXPORT` on all platforms.
>>
>> The bug that this PR solves,
>> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), wa
On Thu, 22 Feb 2024 12:27:03 GMT, Magnus Ihse Bursie wrote:
>>> they were absent from .dynsym but available in .symtab as bind: local,
>>> visibility: default. Now they are completely gone.
>>
>> I don't think that statement is correct. Or else my understanding about
>> symbol tables is incomp
On Thu, 22 Feb 2024 12:24:09 GMT, Magnus Ihse Bursie wrote:
>> Thanks - when I last tried, e.g. "call universe()" would work on Linux/gdb,
>> so I think gdb did resolve a local symbol (which cannot be found by callling
>> dlsym, but can be found in the binary symboltable).
>> On Windows the deb
On Thu, 22 Feb 2024 11:16:37 GMT, Kevin Walls wrote:
>>> But for platform consistency, it might make sense to export these even on
>>> gcc as well.
>>
>> JDK-8288293 would definitely like that a lot
>
> Thanks - when I last tried, e.g. "call universe()" would work on Linux/gdb,
> so I think gd
On Thu, 22 Feb 2024 09:46:00 GMT, Magnus Ihse Bursie wrote:
> However, I interpret your comment as that it is possible to remove the
> JNIEXPORT from these functions in a follow-up PR. And that is good to know!
I believe you're right. In any case, most of the JVMCI tests will fail if
JNIEXPORT
On Thu, 22 Feb 2024 09:59:48 GMT, Julian Waters wrote:
>> they were absent from .dynsym but available in .symtab as bind: local,
>> visibility: default. Now they are completely gone.
>>
>> The symbols were supposed to be used from gdb. I'm not sure if gdb can
>> access local symbols, so it's p
On Thu, 22 Feb 2024 09:37:38 GMT, Magnus Ihse Bursie wrote:
> > If the `SUNWprivate_1.1` part of the symbols is still needed, it can be
> > added using `--default-symver` ld parameter.
>
> Ah, good to know. In the spirit of making as minimal changes as possible in
> this PR, I will add it.
Un
> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
> compiler options and `JNIEXPORT` on all platforms.
>
> The bug that this PR solves,
> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in
> 2013. Even back then the use of mapfiles in Hotspot
On Thu, 22 Feb 2024 10:15:54 GMT, Magnus Ihse Bursie wrote:
>> Ah, I should have clarified that I did read the explaination, just that it
>> slipped my mind at the time. I can't remember if C++14 or C++17 is the
>> version for compilers ignoring unknown attributes though
>>
>> Also, you can es
On Thu, 22 Feb 2024 09:55:21 GMT, Julian Waters wrote:
>> We're currently using __attribute__ ((visibility ("X"))) elsewhere, so I
>> think I should stick with that.
>>
>> And, as I said in my long explanation, this is definitely a hack. The reason
>> it is here is that I want to make sure the
On Thu, 22 Feb 2024 09:49:41 GMT, Daniel Jeliński wrote:
>> No, it doesn't. Even after
>> [JDK-8264593](https://bugs.openjdk.org/browse/JDK-8264593) the symbols from
>> debug.cpp were not exported on Linux, since they were not mentioned in
>> `make/data/hotspot-symbols`, and thus were made loc
On Wed, 21 Feb 2024 23:32:15 GMT, Magnus Ihse Bursie wrote:
> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
> compiler options and `JNIEXPORT` on all platforms.
>
> The bug that this PR solves,
> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was cre
On Thu, 22 Feb 2024 09:29:25 GMT, Magnus Ihse Bursie wrote:
>> src/hotspot/share/oops/accessBackend.cpp line 36:
>>
>>> 34:
>>> 35: #if defined(TARGET_COMPILER_gcc)
>>> 36: #define HIDDEN __attribute__ ((visibility ("hidden")))
>>
>> Couldn't this use [[gnu::visibility("hidden")]] instead, sin
On Thu, 22 Feb 2024 00:29:55 GMT, David Holmes wrote:
> My main concern with a change like this as that it likely has little effect
> on the OpenJDK itself, but we may be changing something that 3rd party
> applications linking with libjvm are relying on. I realize this is a bit
> "hand wavy"
On Thu, 22 Feb 2024 09:41:45 GMT, Magnus Ihse Bursie wrote:
>> src/hotspot/share/utilities/debug.cpp line 71:
>>
>>> 69:
>>> 70: #if defined(TARGET_COMPILER_gcc)
>>> 71: #undef JNIEXPORT
>>
>> This partially reverts
>> [JDK-8264593](https://bugs.openjdk.org/browse/JDK-8264593); @kevinjwalls
On Thu, 22 Feb 2024 09:30:30 GMT, Magnus Ihse Bursie wrote:
>> make/hotspot/lib/CompileJvm.gmk line 149:
>>
>>> 147:
>>> 148: ifeq ($(call isTargetOs, windows), true)
>>> 149: WIN_EXPORT_FILE := $(JVM_OUTPUTDIR)/win-exports.txt
>>
>> Why not .def?
>
> I try to stick to established file suffi
On Thu, 22 Feb 2024 07:44:48 GMT, Daniel Jeliński wrote:
>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
>> compiler options and `JNIEXPORT` on all platforms.
>>
>> The bug that this PR solves,
>> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was c
On Thu, 22 Feb 2024 08:46:16 GMT, Doug Simon wrote:
> > The Graal folk will need to chime in here as it may be that these are
> > needed for libgraal.
>
> They should be fine. JNI linkage is only used by the native methods in
> `CompilerToVM.java`.
Once again, it is a misunderstanding that an
On Thu, 22 Feb 2024 07:39:51 GMT, Daniel Jeliński wrote:
>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
>> compiler options and `JNIEXPORT` on all platforms.
>>
>> The bug that this PR solves,
>> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was c
On Thu, 22 Feb 2024 07:50:34 GMT, Daniel Jeliński wrote:
> Thanks for doing this! This is a good improvement IMO.
Thanks!
> If the `SUNWprivate_1.1` part of the symbols is still needed, it can be added
> using `--default-symver` ld parameter.
Ah, good to know. In the spirit of making as mini
On Thu, 22 Feb 2024 07:13:03 GMT, Julian Waters wrote:
>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
>> compiler options and `JNIEXPORT` on all platforms.
>>
>> The bug that this PR solves,
>> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was cre
On Thu, 22 Feb 2024 00:18:16 GMT, David Holmes wrote:
> > it turned out that there were several symbols declared JNIEXPORT that were
> > not included in the symbol list,
>
> There appear to be two main categories of functions here:
>
> 1. Those intended for use from a debugger
>
>
> Have
On Thu, 22 Feb 2024 00:18:16 GMT, David Holmes wrote:
> The Graal folk will need to chime in here as it may be that these are needed
> for libgraal.
They should be fine. JNI linkage is only used by the native methods in
`CompilerToVM.java`.
-
PR Comment: https://git.openjdk.org/j
On Wed, 21 Feb 2024 23:32:15 GMT, Magnus Ihse Bursie wrote:
> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
> compiler options and `JNIEXPORT` on all platforms.
>
> The bug that this PR solves,
> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was cre
On Wed, 21 Feb 2024 23:32:15 GMT, Magnus Ihse Bursie wrote:
> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
> compiler options and `JNIEXPORT` on all platforms.
>
> The bug that this PR solves,
> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was cre
On Wed, 21 Feb 2024 23:32:15 GMT, Magnus Ihse Bursie wrote:
> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
> compiler options and `JNIEXPORT` on all platforms.
>
> The bug that this PR solves,
> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was cre
On Wed, 21 Feb 2024 23:32:15 GMT, Magnus Ihse Bursie wrote:
> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
> compiler options and `JNIEXPORT` on all platforms.
>
> The bug that this PR solves,
> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was cre
On Wed, 21 Feb 2024 23:32:58 GMT, Magnus Ihse Bursie wrote:
> it turned out that there were several symbols declared JNIEXPORT that were
> not included in the symbol list,
There appear to be two main categories of functions here:
1. Those intended for use from a debugger
Have you verified th
On Wed, 21 Feb 2024 23:32:15 GMT, Magnus Ihse Bursie wrote:
> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
> compiler options and JNIEXPORT on all platforms.
>
> The bug that this PR solves,
> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was creat
**Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
compiler options and JNIEXPORT on all platforms.
The bug that this PR solves,
[JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in
2013. Even back then the use of mapfiles in Hotspot was dated, so
65 matches
Mail list logo
