Hi Alex,
Vladimir I. also mentioned the same as Igor.
One example from the runtime/thread.cpp:
#if INCLUDE_JVMCI
bool force_JVMCI_intialization = false;
if (EnableJVMCI) {
// Initialize JVMCI eagerly when it is explicitly requested.
// Or when JVMCIPrintProperties is enabled.
// The JVMCI Java initialization code will read this flag and
// do the printing if it's set.
force_JVMCI_intialization = EagerJVMCI || JVMCIPrintProperties;
if (!force_JVMCI_intialization) {
// 8145270: Force initialization of JVMCI runtime otherwise
requests for blocking
// compilations via JVMCI will not actually block until JVMCI is
initialized.
force_JVMCI_intialization = UseJVMCICompiler && (!UseInterpreter
|| !BackgroundCompilation);
}
}
#endif
One more example from prims/jni.cpp:
#if INCLUDE_JVMCI
if (EnableJVMCI) {
if (UseJVMCICompiler) {
. . .
}
}
#endif
On 1/30/19 17:34, Igor Ignatyev wrote:
Hi Alex,
UseJVMCICompiler is declared only if INCLUDE_JVMCI is defined, so your current
patch will break builds where it's undefined. the rest (esp. problem list ;) )
looks good to me.
adding hotspot-compiler alias.
Thanks,
-- Igor
On Jan 30, 2019, at 5:27 PM, Alex Menkov <alexey.men...@oracle.com> wrote:
Hi all,
Please review a fix for tck-red bug:
https://bugs.openjdk.java.net/browse/JDK-8218025
webrev:
http://cr.openjdk.java.net/~amenkov/tck_red_disable_caps/webrev/
ForceEarlyReturn and PopFrame JCK tests intermittently fail with Graal.
Real fix for the issue is too risky for jdk12, so we have to disable pop_frame
and force_early_return capabilities running with Graal (the capabilities are
optional).
Currently Graal is the only compiler, so the fix checks if JVMCI compiler is
enabled.
JCK test passes with disabled capabilities.
A number of hotspot tests do not check if the capabilities are enabled (as
hotspot is expected to support all capabilities) and fail with Graal - they are
problem-listed until the real problem (JDK-8195635) is resolved.
--alex
