JDK-8267942 : jdk build failed for "--with-jvm-variants=minimal"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 11
  • Priority: P4
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2021-05-28
  • Updated: 2021-06-09
  • Resolved: 2021-06-09
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11
11-poolResolved
Related Reports
Duplicate :  
JDK-8227815 - Minimal VM: set_state is not a member of AttachListener
Duplicate :  
JDK-8235456 - Minimal VM is broken after JDK-8212160
Duplicate :  
JDK-8235218 - Minimal VM is broken after JDK-8173361
Description
/git/jdk/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/objs/jfrJvmtiAgent.o: In function `JfrJvmtiAgent::retransform_classes(JNIEnv_*, _jobjectArray*, JavaThread*)':
/git/jdk/./open/src/hotspot/share/prims/jvmtiUtil.hpp:50: undefined reference to `JvmtiUtil::_error_names'
/git/jdk/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/objs/jfrJvmtiAgent.o: In function `JfrJvmtiAgent::create()':
/git/jdk/./open/src/hotspot/share/prims/jvmtiEnvBase.hpp:76: undefined reference to `JvmtiEnvBase::_phase'
collect2: error: ld returned 1 exit status
make[3]: *** [/git/jdk/build/linux-x86_64-server-release/support/modules_libs/java.base/server/libjvm.so] Error 1
lib/CompileJvm.gmk:141: recipe for target /git/jdk/build/linux-x86_64-server-release/support/modules_libs/java.base/server/libjvm.so' failed
make[2]: *** [hotspot-server-libs] Error 2
make/Main.gmk:255: recipe for target 'hotspot-server-libs' failed

ERROR: Build failed for target 'default (exploded-image)' in configuration 'linux-x86_64-server-release' (exit code 2)

=== Output from failing command(s) repeated here ===
* For target hotspot_variant-server_libjvm_objs_BUILD_LIBJVM_link:
/git/jdk/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/objs/jfrJvmtiAgent.o: In function `JfrJvmtiAgent::retransform_classes(JNIEnv_*, _jobjectArray*, JavaThread*)':
/git/jdk/./open/src/hotspot/share/prims/jvmtiUtil.hpp:50: undefined reference to `JvmtiUtil::_error_names'
/git/jdk/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/objs/jfrJvmtiAgent.o: In function `JfrJvmtiAgent::create()':
/git/jdk/./open/src/hotspot/share/prims/jvmtiEnvBase.hpp:76: undefined reference to `JvmtiEnvBase::_phase'
collect2: error: ld returned 1 exit status

* All command lines available in/git/jdk/build/linux-x86_64-server-release/make-support/failure-logs.
=== End of repeated output ===

=== Make failed targets repeated here ===
lib/CompileJvm.gmk:141: recipe for target '/git/jdk/build/linux-x86_64-server-release/support/modules_libs/java.base/server/libjvm.so' failed
make/Main.gmk:255: recipe for target 'hotspot-server-libs' failed
=== End of repeated output ===

Hint: Try searching the build log for the name of the first failed target.
Hint: See doc/building.html#troubleshooting for assistance.

/git/jdk/open/make/Init.gmk:310: recipe for target 'main' failed
make[1]: *** [main] Error 2
/git/jdk/open/make/Init.gmk:186: recipe for target 'default' failed
make: *** [default] Error 2
Comments
Thanks David for the confirmation. Minimal build is broken only in jdk11u-cpu, it is not the case in jdk17. I will triage this only for jdk11.
07-06-2021
It isn't a regression as it isn't a supported configuration. The request requires removal of JVM TI whilst not removing other things - the only supported configuration we have is the Minimal VM where INCLUDE_JVMTI, INCLUDE_JFR and INCLUDE_SERVICES are all false. Now a JVM without JVM TI is perfectly allowable, but we just don't currently support that. I believe there is more to doing so than just fixing the build - certainly there is more for JFR as Erik has stated.
04-06-2021
I saw David comment after posting my last comment. I tried excluding jvmti and jfr both in jdk11 and it still resulted in build failure. This looks like regression from jdk11.0.10 onwards (need to find more). Thanks,
04-06-2021
Thanks Chris for the comment. As you suggested patching the caller of get_phase() which is called from jfrJvmtiAgent.cpp, my first proposed patch (jdk_open.patch) works fine. But it also make sense to exclude JFR when we are excluding JVM TI. In that case there are no build issues in jdk/jdk. Whereas there are build issues in jdk11u-cpu as reported by the submitter. I would prefer to triage this issue only for jdk11. Please let me know if there are any other suggestions. Thanks,
04-06-2021
I think rather than patching get_phase() you should be patching the caller of get_phase() to not call it when JVMTI is not supported. But, also consider the 3 points that Erik made. If JFR requires JVMTI (and I mean really requires, not just has minor build issue without it), then excluding JVMTI should require also excluding JFR. Per David's "skeleton API" reference, yes, we use JVMTI_ONLY and NOT_JVMTI for this. However, in most cases there is no function result. In the cases where there is, it is normally a boolean or some other benign value that results in "disabling" any jvmti related code at the call site.
03-06-2021
When JVM TI is not configured in the VM a skeleton API must still remain present as JVM TI is not optional, only some of its features are optional. You will need to ask serviceability folk exactly what API's must do what in such cases and then work back to see whether things like getPhase make any sense. You also need to check the code that is using JVM TI to see what it should do when JVM TI is not present. This is non-trivial. I think the submitter needs to respond to Erik's query about the exact use case.
31-05-2021
I have reworked on the patch (attached jdk_open_rev02.patch) to remove the dependencies of jfrJvmtiAgent.cpp. The patch itself not right still, as I didn't get the right jvmtiPhase value to be returned in case of NOT_JVMTI. The patch returns "JVMTI_PHASE_DEAD" which may not be the right value. + static jvmtiPhase get_phase() { + JVMTI_ONLY(return (jvmtiPhase)_phase); + NOT_JVMTI(return JVMTI_PHASE_DEAD); + }
31-05-2021
What is the use case? 1) Use JFR without JVM TI. This is a rather large enhancement (not a bug) and I'm not sure it is worth the effort => Work as designed 2) Build without using JVM TI, then it is logical it fails since JFR depends on JVM TI. Fix is to exclude JFR as well => Not an issue 3) A build without JFR and JVMTI fails. Then perhaps something needs to be fixed, even though I think MinimalVM is more of an intended target.
31-05-2021
The build failure error message is different in jdk11u and jdk/jdk case. I created a patch (attached) which would make build to be successful, but if this is not a valid configuration. I prefer to close as not an issue.
29-05-2021
The patch is very strange in that the code is part of a JFR JVMTI agent that we are using when there is no JVM TI. While the additional checks may "fix" the build error this code should be excluded in its entirety when there is no JVM TI configured in the VM.
29-05-2021
It is a bit of a grey area. We never originally intended to allow arbitrary combinations of the defined JVM features (and not all functionality is defined as a feature). If simple fixes can make a given configuration build then that can be an acceptable change even though we do not officially support or test that configuration. It is up to whomever wants this configuration to drive the changes to make it work - we don't just accept it as a bug that has to fixed by the main development teams.
29-05-2021
Does this work in mainline? We don't guarantee that you can arbitrarily select JVM features to include or exclude. The GC's can be individually selected. Some features were always handled as a group to exclude e.g. for the MinimalVM.
28-05-2021