JDK-8337221 : CompileFramework: test library to conveniently compile java and jasm sources for fuzzing
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 24
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2024-07-25
  • Updated: 2025-03-20
  • Resolved: 2024-10-16
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 17 JDK 21 JDK 24
17.0.16-oracleFixed 21.0.8-oracleFixed 24 b20Fixed
Related Reports
Causes :  
JDK-8351998 - Test testlibrary_tests/compile_framework/tests/TestConcurrentCompilation.java failed
Relates :  
JDK-8344942 - Template-Based Testing Framework
Relates :  
JDK-8342387 - C2 SuperWord: refactor and improve compiler/loopopts/superword/TestDependencyOffsets.java
Relates :  
JDK-8352020 - [CompileFramework] enable compilation for VectorAPI
Description
The idea is this:
We should be able to create java and jasm code during a jtreg test, compile and execute it. This can be used to fuzz various compiler optimizations.
Comments
Fix request [17u] I backport this for parity with 17.0.16-oracle from 21. No risk, only a test change. Clean backport, but I had to adapt one test. Tests and examples pass. SAP nightly testing passed.
19-03-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk17u-dev/pull/3377 Date: 2025-03-18 11:36:24 +0000
18-03-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk21u-dev/pull/1501 Date: 2025-03-15 20:59:07 +0000
15-03-2025
Fix request [21u] I backport this for parity with 21.0.8-oracle. No risk, only a test change Clean backport, but tests needed small adaption to compile. Test/examples pass.
15-03-2025
Changeset: b9b0bd08 Branch: master Author: Emanuel Peter <epeter@openjdk.org> Date: 2024-10-16 07:23:12 +0000 URL: https://git.openjdk.org/jdk/commit/b9b0bd0871886eb65f87864f262424b119f2c748
16-10-2024
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/20184 Date: 2024-07-15 15:56:10 +0000
12-09-2024
Here my draft, together with some use-cases where I'm frustrated / limited with my current approaches: https://github.com/openjdk/jdk/pull/20184
29-07-2024
> fuzzing tends to create constructs that are not legal at the language level I think there is a misunderstanding around the term "fuzzing" here. What Emanuel is referring to, and what's the main use case of this RFE, is to enable dynamic generation of tests at runtime based on String manipulation (for example, test loops with many different constant strides). This is not completely random and the generated tests will be legal Java code. Using Strings is most convenient and readable because we usually don't write tests in bytecodes.
29-07-2024
[~dholmes] The java-fuzzer has found many bugs that reduce down to very small snippets that look reasonably likely that it could happen out in the world. And class-file fuzzing does often find unlikely code shapes. But sometimes they can be turned into java examples as well. For example there are lots of infinite-loop bugs. Infinite loops seem not to be generated by the java-fuzzer, but much more likely by classfile / jasm fuzzing. It is just going to be a tool for now. And the tool has to be convenient to use. This is why I prefer strings.
29-07-2024
> As far as I know, the classfile API and ASM do not work with strings, right? AFAIK that is right. From a fuzzing perspective I didn't think that strings would that useful, at least for java source, as fuzzing tends to create constructs that are not legal at the language level. I don't know of any mechanism to do in-memory jasm compilation of strings.
28-07-2024
As far as I know, the classfile API and ASM do not work with strings, right? That has advantages, but also disadvantages. It should be easy to extract the files that the fuzzer generated, and run them outside the fuzzer and reduce the files to a small reproducer. Does that make sense? Or do you have other ideas?
26-07-2024
[~dholmes] My goal is this: create some strings that are either Java files or Jasm files. Then dynamically compile. Java and Jasm are very convenient formats. If required jdec could easily be added. I know that I could use InMemoryJavaCompiler (instead of calling javac with ProcessBuilder). We can benchmark later if that would be worth it. I actually had it working with the InMemoryJavaCompiler, but decided to use the ProcessBuilder, since I'm also using that with asmtools.jar, that is delivered with jtreg - to compile Jasm files. I want something that is VERY convenient. Basically you just give it some strings, then "compile()", then "call(className, methodName, varargs)". The idea is that it should be stupid simple to create nice small dedicated fuzzers this way. I want the framework to deal with all the classpaths, deciding where the classfiles end up, how to chose compilation method based on file type, etc.
26-07-2024
Not sure if I am misunderstanding but you can use the InMemoryJavaCompiler to dynamically compile Java source code, and use ASM (or the new Classfile API) to generate class files directly.
26-07-2024