Build fails when disabling jvmti

[Ashutosh Mehra]

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> 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> 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/a24cf0e9/attachment.htm>