On Mon, 23 Mar 2026 07:40:46 GMT, Matthias Baesken <[email protected]> wrote:
>> It is new to have a platform-specific JVM API but better that than just >> ad-hoc-ly exposing a piece of code in libjvm IMO. If you want to have one >> version of this code and you want libawt to obtain it from libjvm then that, >> by definition, should be part of the exposed JVM API on AIX. > > Hi David, in practise there is quite a bit more exported from libjvm and not > only the JVM API (JVM_). > E.g. the debug helpers, jio_ , AsyncGetCallTrace and some numa methods. > > > 000000000088dc30 T AsyncGetCallTrace > 0000000000787ec0 T blob > 00000000007890b0 T debug > 00000000007880b0 T disnm > 0000000000787f60 T dump_vtable > 00000000007892a0 T events > 0000000000789480 T find > 00000000007899a0 T findbcp > 0000000000789700 T findclass > 0000000000789330 T findm > 0000000000789850 T findmethod > 00000000007893e0 T findnm > 00000000007895c0 T findpc > 0000000000789210 T flush > 0000000000789d30 T help > 0000000000b16990 T jio_fprintf > 0000000000b16a20 T jio_printf > 0000000000b16430 T jio_snprintf > 0000000000b16970 T jio_vfprintf > 0000000000b163f0 T jio_vsnprintf > ... > 0000000000e69120 T numa_error > 0000000000e69110 T numa_warn Sure there are other groups of exported symbols - debug helpers and jio_* the main ones plus AGCT. But that doesn't mean we should just add another ad-hoc entry. The numa entries are interesting because we need to export those to override the libnuma defaults. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30295#discussion_r2979348398
