Build fails when disabling jvmti
Ashutosh Mehra
asmehra at redhat.com
Mon Jul 8 18:57:02 UTC 2024
Here is the issue for mainline: https://bugs.openjdk.org/browse/JDK-8335921
- Ashutosh Mehra
On Mon, Jul 8, 2024 at 2:10 PM Vladimir Kozlov <vladimir.kozlov at oracle.com>
wrote:
> Ashutosh, please file bug for mainline hotspot/jvmti component.
>
> Thanks,
> Vladimir K
>
> On 7/8/24 9:43 AM, Ashutosh Mehra wrote:
> > Hi Sanne,
> > For the record I am able to recreate this issue if I create a custom
> variant and omit jvmti feature using the following
> > configure command:
> >
> > bash ./configure --with-conf-name=no-jvmti-release
> >
> --with-jvm-features=cds,compiler1,compiler2,g1gc,serialgc,jfr,jni-check,jvmci,management,services
> --with-jvm-variants=custom
> >
> > I tried to fix it by enclosing the code in SCCache.cpp
> with INCLUDE_JVMTI but the build failed again in premain specific
> > code with this error:
> >
> >
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/interpreter/interpreterRuntime.cpp:1804:23:
> error:
> > ‘_perf_InterpreterRuntime_member_name_arg_or_null_timer’ was not
> declared in this scope; did you mean
> > ‘_perf_InterpreterRuntime_prepare_native_call_timer’?
> > 1804 | NEWPERFTICKCOUNTERS(_perf_##sub##_##name##_timer, SUN_CI,
> #sub "::" #name); \
> > | ^~~~~~
> >
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/runtime/perfData.hpp:854:4:
> note: in definition of macro
> > ‘NEWPERFTICKCOUNTERS’
> > 854 | {counter = PerfDataManager::create_tick_counters(counter_ns,
> counter_name, counter_name "_elapsed_time", \
> > | ^~~~~~~
> >
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/interpreter/interpreterRuntime.cpp:1798:3:
> note: in expansion of
> > macro ‘INIT_COUNTER’
> > 1798 | macro(InterpreterRuntime, member_name_arg_or_null)
> > | ^~~~~
> >
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/interpreter/interpreterRuntime.cpp:1812:5:
> note: in expansion of
> > macro ‘DO_JVMTI_COUNTERS’
> > 1812 | DO_JVMTI_COUNTERS(INIT_COUNTER)
> > | ^~~~~~~~~~~~~~~~~
> >
> > I worked around it and it next failed with following errors:
> >
> > /usr/bin/ld:
> >
> /home/asmehra/data/ashu-mehra/leyden/build/premain-release/hotspot/variant-custom/libjvm/objs/jfrJvmtiAgent.o:
> in
> > function `JvmtiUtil::error_name(int)':
> > make/hotspot/src/hotspot/share/prims/jvmtiUtil.hpp:51: undefined
> reference to `JvmtiUtil::_error_names'
> > /usr/bin/ld:
> >
> /home/asmehra/data/ashu-mehra/leyden/build/premain-release/hotspot/variant-custom/libjvm/objs/jfrJvmtiAgent.o:
> in
> > function `JvmtiEnvBase::get_phase()':
> > make/hotspot/src/hotspot/share/prims/jvmtiEnvBase.hpp:77: undefined
> reference to `JvmtiEnvBase::_phase'
> > /usr/bin/ld:
> >
> /home/asmehra/data/ashu-mehra/leyden/build/premain-release/hotspot/variant-custom/libjvm/objs/jfrPeriodic.o:
> in function
> > `JfrPeriodicEventSet::requestJavaAgent()':
> > make/hotspot/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:294:
> undefined reference to `JvmtiAgentList::java_agents()'
> > /usr/bin/ld:
> >
> /home/asmehra/data/ashu-mehra/leyden/build/premain-release/hotspot/variant-custom/libjvm/objs/jfrPeriodic.o:
> in function
> > `JfrPeriodicEventSet::requestNativeAgent()':
> > make/hotspot/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:314:
> undefined reference to `JvmtiAgentList::native_agents()'
> > /usr/bin/ld:
> make/hotspot/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:316: undefined
> reference to
> > `JvmtiAgentList::xrun_agents()'
> > /usr/bin/ld:
> >
> /home/asmehra/data/ashu-mehra/leyden/build/premain-release/hotspot/variant-custom/libjvm/objs/jvmciCompilerToVMInit.o:
>
> > in function `CompilerToVM::Data::initialize(JVMCIEnv*)':
> > make/hotspot/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp:212:
> undefined reference to
> > `JvmtiExport::_should_notify_object_alloc'
> > collect2: error: ld returned 1 exit status
> >
> > This is not specific to premain, and I can reproduce it with mainline as
> well. It doesn't look like it is
> > straightforward to remove the jvmti feature. Seems like there may be
> other components (like jfr) missing INCLUDE_JVMTI
> > macro.
> > My suggestion, if you are interested in pursuing it further, would be to
> try and wrinkle out the problems with the
> > mainline first.
> >
> > Meanwhile I will push the changes to use INCLUDE_JVMTI in the premain
> specific code.
> >
> > - Ashutosh Mehra
> >
> >
> > On Mon, Jul 8, 2024 at 11:17 AM Ashutosh Mehra <asmehra at redhat.com
> <mailto:asmehra at redhat.com>> wrote:
> >
> > Hi Sanne, thanks for reporting this. It looks like a bug. It can be
> fixed by enclosing the relevant code under the
> > "INCLUDE_JVMTI" macro.
> >
> > - Ashutosh Mehra
> >
> >
> > On Mon, Jul 8, 2024 at 9:58 AM Sanne Grinovero <sanne at redhat.com
> <mailto:sanne at redhat.com>> wrote:
> >
> > Hello all,
> >
> > I'm experimenting building Leyden locally with non-default
> configurations, with the intent of comparing its
> > potential as an alternative to GraalVM native-images, and one of
> my goals would be to produce a minimal JVM
> > build which exclusively includes the components that our
> applications are going to need at runtime.
> >
> > This implies being very selective with the JVM features I choose
> at configuration time; I've already opened some
> > minor issues identified during such experiments.
> >
> > Today I noticed today that if I exclude the "jvmti" feature, the
> premain branch of Leyden doesn't compile:
> >
> >
> > === Output from failing command(s) repeated here ===
> > * For target hotspot_variant-custom_libjvm_objs_SCCache.o:
> > /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:
> In member function ‘void
> > SCAddressTable::init_opto()’:
> >
> /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3815:39:
> error: ‘notify_jvmti_vthread_start’ is
> > not a member of ‘OptoRuntime’
> > 3815 | SET_ADDRESS(_C2_blobs,
> OptoRuntime::notify_jvmti_vthread_start());
> > |
> ^~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3511:47:
> note: in definition of macro ‘SET_ADDRESS’
> > 3511 | type##_addr[type##_length++] = (address) (addr);
> \
> > | ^~~~
> >
> /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3816:39:
> error: ‘notify_jvmti_vthread_end’ is not
> > a member of ‘OptoRuntime’
> > 3816 | SET_ADDRESS(_C2_blobs,
> OptoRuntime::notify_jvmti_vthread_end());
> > |
> ^~~~~~~~~~~~~~~~~~~~~~~~
> >
> /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3511:47:
> note: in definition of macro ‘SET_ADDRESS’
> > 3511 | type##_addr[type##_length++] = (address) (addr);
> \
> > | ^~~~
> >
> /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3817:39:
> error: ‘notify_jvmti_vthread_mount’ is
> > not a member of ‘OptoRuntime’
> > 3817 | SET_ADDRESS(_C2_blobs,
> OptoRuntime::notify_jvmti_vthread_mount());
> > |
> ^~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3511:47:
> note: in definition of macro ‘SET_ADDRESS’
> > 3511 | type##_addr[type##_length++] = (address) (addr);
> \
> > | ^~~~
> >
> /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3818:39:
> error: ‘notify_jvmti_vthread_unmount’ is
> > not a member of ‘OptoRuntime’
> > 3818 | SET_ADDRESS(_C2_blobs,
> OptoRuntime::notify_jvmti_vthread_unmount());
> > |
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3511:47:
> note: in definition of macro ‘SET_ADDRESS’
> > 3511 | type##_addr[type##_length++] = (address) (addr);
> \
> > | ^~~~
> > ... (rest of output omitted)
> >
> > I'm wondering if I should open an issue for this case? I
> appreciate it's early days and that such aspects might
> > not be a priority currently!
> >
> > Thanks,
> > Sanne
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240708/4096b7f9/attachment.htm>
More information about the leyden-dev
mailing list