d-iii-s / java-ubench-agent Goto Github PK

Now, PAPI component has to be specified manually (via PAPI/comp_name:event_name). However, if the event name is valid, it should be possible to retrieve its component id via PAPI_get_event_info. This should simplify event specification a little bit.

Trying to measure JVMCI threads with JDK 9 ends with an exception:

Exception in thread "main" cz.cuni.mff.d3s.perf.MeasurementException: PAPI_attach failed: Invalid argument.
at cz.cuni.mff.d3s.perf.Measurement.createAttachedEventSetNative(Native Method)
at cz.cuni.mff.d3s.perf.Measurement.createAttachedEventSet(Measurement.java:27)
at cz.cuni.mff.d3s.perf.SamplingHelper.lambda$__initJvmciExtraEvents$0(SamplingHelper.java:283)
at java.base/java.util.stream.ReferencePipeline$4$1.accept(ReferencePipeline.java:212)
at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1494)
at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:550)
at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
at java.base/java.util.stream.IntPipeline.toArray(IntPipeline.java:516)
at cz.cuni.mff.d3s.perf.SamplingHelper.__initJvmciExtraEvents(SamplingHelper.java:286)
at cz.cuni.mff.d3s.perf.SamplingHelper.(SamplingHelper.java:201)
at cz.cuni.mff.d3s.perf.SamplingHelper.(SamplingHelper.java:153)
at spec.harness.LaunchPlain.main(LaunchPlain.java:38)

In some of the ScalaBench measurements with JVMCI merge threads turned OFF, the values in the instruction count column are occassionally negative. This could be a problem in the ScalaBench sampling helper class, but since it does very little with the data, it is more likely an agent issue.

Currently, the code compiles on Windows but it does not collect any events except those native to JVM. Add at least the following ones:

• QueryPerformanceCounter()
• GetProcessMemoryInfo()

Now, data are stored to a standalone file, identified by name. Extend the API so the caller can collect the data in a better form: either print to a provided stream or return plain array and leave the processing completely on the Java (not JNI) side.

The agent uses PAPI_assign_eventset_component to always assign component 0 (the CPU component) to the eventset, which means that events from other components (for example RAPL) cannot be collected.

Following shall be probably enough for a list:

String[] Benchmark.getSupportedEvents();

and maybe extended with

String Benchmark.getEventDescription(String event);

for more detailed event description (when possible).

Using the default Windows configuration for GitHub Actions ends with the following bug:

compile-agent-gcc:
    [apply] D:\a\java-ubench-agent\java-ubench-agent\src\c\events.c: In function 'getter_thread_time':
    [apply] D:\a\java-ubench-agent\java-ubench-agent\src\c\events.c:96:60: warning: unused parameter 'bench' [-Wunused-parameter]
    [apply]    96 | static long long getter_thread_time(const benchmark_run_t *bench, const ubench_event_info_t *UNUSED_PARAMETER(info)) {
    [apply]       |                                     ~~~~~~~~~~~~~~~~~~~~~~~^~~~~
    [apply] In file included from D:\a\java-ubench-agent\java-ubench-agent\src\c\jnifunc.c:22:
    [apply] D:\a\java-ubench-agent\java-ubench-agent\src\c\jnifunc.c: In function 'Java_cz_cuni_mff_d3s_perf_NativeThreads_getNativeId':
    [apply] D:\a\java-ubench-agent\java-ubench-agent\out\agent/cz_cuni_mff_d3s_perf_NativeThreads.h:11:63: error: invalid suffix "i64" on integer constant
    [apply]    11 | #define cz_cuni_mff_d3s_perf_NativeThreads_INVALID_THREAD_ID -1i64
    [apply]       |                                                               ^~~~
    [apply] D:\a\java-ubench-agent\java-ubench-agent\src\c\jnifunc.c:39:32: note: in expansion of macro 'cz_cuni_mff_d3s_perf_NativeThreads_INVALID_THREAD_ID'
    [apply]    39 |                 return (jlong) cz_cuni_mff_d3s_perf_NativeThreads_INVALID_THREAD_ID;
    [apply]       |                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Probably caused by javah generating MSVC-specific header as i64 suffix is a non-standard MS extension.

Currently, the filtering of supported events is based solely on the ability to resolve the event name.

But when running in some kind of sandbox, the event may exist but may not be available due to other restrictions.

For PAPI events, we should create a dummy event set, add the event there and only if this is OK we can mark the event as supported.

This is easily demonstrated on CI builds on GitHub actions where PAPI is available but no events are permitted.