Repository navigation
chore: add FFM coverage map benchmarks - #1070
Merged
Merged
Conversation
sun.misc.Unsafe memory access is deprecated for removal (JEP 471/498) and warns on JDK 24+. Add coverage maps backed by the Foreign Function & Memory API to CoverageInstrumentationBenchmark to compare them with the Unsafe-backed map Jazzer uses today: - FfmCoverageMap uses MemorySegment directly (Java 22 source). - FfmMethodHandleCoverageMap accesses the same API via method handles, so it compiles with Java 8 source level and could ship in the same jar as the Unsafe-backed map. Since FFM requires JDK 22+, the FFM benchmarks are only built with --java_runtime_version=remotejdk_25. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: fc8e7077-31cc-47a3-acb9-050440f42ea5
GitHub retired the macos-14 runner image on 2026-11-02. Use Xcode 16.4, the default on macos-15.
The JVM reconstitutes retransformed classes with their methods in an order that varies between runs. Since coverage and hook IDs are assigned in method order, fuzzing with a fixed seed wasn't reproducible, e.g. ReactorFuzzTest timed out on macOS CI with JDK 8. Sort the methods first.
On macOS, libraries built with -fsanitize=fuzzer-no-link load the UBSan runtime, which then turns the JVM's own SIGSEGV/SIGBUS into crashes, e.g. in NativeValueProfileFuzzer.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Refs #1069
sun.misc.Unsafememory access is deprecated for removal (JEP 471/498) and warns on JDK 24+.CoverageMap.recordCoverageruns on every instrumented edge, so this PR adds FFM-backed coverage maps toCoverageInstrumentationBenchmarkto measure what replacingUnsafewould cost:FfmCoverageMapusesMemorySegmentdirectly (Java 22 source).FfmMethodHandleCoverageMapuses the same API via method handles. It compiles with Java 8 source level, so it could ship in the same jar as theUnsafe-backed map and only be loaded on JDK 22+.Both use the same update rule, instrumentation strategy and map size as the existing
Unsafebenchmarks. Since FFM requires JDK 22+, the FFM benchmarks are only built with--java_runtime_version=remotejdk_25, the only JDK >= 22 that rules_java provides. CI runs on JDK 8 and 21, so it doesn't run them.Results
JDK 25.0.2, macOS arm64, JMH defaults (5 forks, 5 × 10 s warmup and measurement):
Unsafe_NeverZero2uninstrumentedstaticMethod_Unsafe_NeverZero2(what Jazzer uses today)staticMethod_Ffm_NeverZerostaticMethod_FfmMethodHandle_NeverZerostaticMethod_DirectByteBuffer2_NeverZeroFFM costs about 21% throughput on this benchmark, which only measures the instrumented target, not libFuzzer's loop. The method-handle variant is within about 2% of direct FFM, so a single release could use
Unsafewhere it's still allowed and fall back to FFM otherwise.Running