Flight Recorder and non-Oracle platforms

[Markus Gronlund]

Hello again,

many thanks to all of you for your war efforts yesterday.

I would like to pre-empt some about what you can expect once you start getting your platforms building again.

The short "I just got my system building again, please don't have me run into more issues"-version:

We currently have only one specific platform listed that is explicitly excluded out-of-the box for JFR (in addition to MINIMAL target), and that is linux-sparc. 

Please see [1]

  # Enable JFR by default, except on linux-sparcv9 and on minimal.

  if test "x$OPENJDK_TARGET_OS" != xlinux || test "x$OPENJDK_TARGET_CPU" != xsparcv9; then

    NON_MINIMAL_FEATURES="$NON_MINIMAL_FEATURES jfr"

  fi

This code section is ported from closed, and as you can see, it is missing some of the open platforms here. You might want to add your os / cpu here to exclude JFR from building by default (it controls the INCLUDE_JFR macro). Excluded INCLUDE_JFR will also take out the command-line options so one should not even be able to attempt to start the functionality.

In addition, and a more dynamic way to exclude JFR from a build, is to use the JVM_FEATURE configure option:

--with-jvm-features= -jfr feature_1 feature2 (note the minus sign)

 

Still interested?

There are two platform dependent areas that might require some work to get the full functionality of JFR supported on a specific platform.

1. CPU information

"runtime/os_perf.hpp" includes a few interfaces that is used for uniformly pulling out (periodically, at intervals) OS / CPU specific information, for example:

CPUInformationInterface (informational)

Impl:

cpu/<cpu>/VM_Version_Ext.cpp files has been added for this purpose (for some CPUs)

CPUPerformanceInterface (counters)

Impl:

os/<flavor>/os_flavor.cpp which some have seen today as part of our mayhem.

A good thing with the CPUPerformanceInterface related information is that JFR has "support" for FUNCTIONALITY_NOT_IMPLEMENTED, for example see [2]:

The FUNCTIONALITY_NOT_IMPLEMENTED macro is defined in "runtime/os_perf.hpp"

It is therefore possible "stub out" one area of platform dependent functionality (I think our tests are lenient about this too).

One last thing about CPU Information - if JFR functionality be requested, say via command-line:

-XX:StartFlightRecording

Then the CPU Information interface implementation is expected to be successfully initialized for the VM to start. The notion of "successfully initialized" here is very basic indeed, the only thing needed is that:

bool initialize () 

routines return "true" (since false now indicates something is wrong and the VM will not start (command-line) or JFR will do a transactional "rollback" if attempted dynamically)

2. Thread sampling

You might already know that JFR share, or have similar, stack walking code as AsynchGetCallTrace / Forte. And just as Forte had its:

   bool pd_get_top_frame_for_signal_handler(frame* fr_addr, void* ucontext, bool isInJava);

// usually implemented (or not) in os_cpu/thread_<os>.cpp

For example, see  [3]

JFR has introduced its own:

bool pd_get_top_frame_for_profiling(frame* fr_addr, void* ucontext, bool isInJava);

pretty much in the same location as the first top_frame_for_signal_handler.

Why not use the same? We do things slightly different in JFR compared to Forte, we have a tighter collaboration between the suspender and the suspendee (we can also support non sigprof platforms, such as Windows).

Tying back to the linked example for thread_linux_sparc.cpp above, this was the reason that linux-sparc was excluded from building by default if I remember correctly, there was not enough time to craft a profiling () method. It should be possible to look at some x86 platform to see what the relevant differences are as a basis for adding this support.

The invocation of pd_get_top_frame_for_profiling(frame* fr_addr, void* ucontext, bool isInJava) comes from here, see [4] and [5]

It is also possible to "stub out" this code; if pd_get_top_frame_for_profiling(frame* fr_addr, void* ucontext, bool isInJava) returns false, the sampling attempt is skipped. That is totally fine.

There is some additional platform specific support that might need to be implemented in the context of thread sampling, for example "crash protection"

please lookup:

os::ThreadCrashProtection

Now this has been in open for some time, so its status might be better than some of the other parts.

Summary:

If you are not interested in the JFR functionality, and / or want it excluded from the builds, please exclude your platform combo from the default build via hotspot.m4 [1]

Platform specific sensitive areas for JFR are around CPU Information / CPU Performance counters as well as thread sampling  (e.g. stack walking / traversal).

The JFR system should be resilient to withstand running with only a subset of events / implementations in most parts, but the most critical will be the ones listed above.

Hoping for a better day today

Best regards for now

Markus

 

[1] http://hg.openjdk.java.net/jdk/jdk/file/9010b580d8a9/make/autoconf/hotspot.m4#l312

[2] http://hg.openjdk.java.net/jdk/jdk/file/3595bd343b65/src/hotspot/os/bsd/os_perf_bsd.cpp#l98

[3] http://hg.openjdk.java.net/jdk/jdk/file/3595bd343b65/src/hotspot/os_cpu/linux_sparc/thread_linux_sparc.cpp#l40

[4] http://hg.openjdk.java.net/jdk/jdk/file/3595bd343b65/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#l180 

[5] http://hg.openjdk.java.net/jdk/jdk/file/3595bd343b65/src/hotspot/share/jfr/periodic/sampling/jfrCallTrace.cpp#l98