RFR: 8337221: CompileFramework: test library to conveniently compile java and jasm sources for fuzzing [v24]

[Evgeny Nikitin]

On Mon, 14 Oct 2024 12:33:44 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> **Motivation**
>> 
>> I want to write small dedicated fuzzers:
>> - Generate `java` and `jasm` source code: just some `String`.
>> - Quickly compile it (with this framework).
>> - Execute the compiled code.
>> 
>> The primary users of the CompileFramework are Compiler-Engineers. Imagine you are working on some optimization. You already have a list of **hand-written tests**, but you are worried that this does not give you good coverage. You also do not trust that an existing Fuzzer will catch your bugs (at least not fast enough). Hence, you want to **script-generate** a large list of tests. But where do you put this script? It would be nice if it was also checked in on git, so that others can modify and maintain the test easily. But with such a script, you can only generate a **static test**. In some cases that is good enough, but sometimes the list of all possible tests your script would generate is very very large. Too large. So you need to randomly sample some of the tests. At this point, it would be nice to generate different tests with every run: a "mini-fuzzer" or a **fuzzer dedicated to a compiler feature**.
>> 
>> **The CompileFramework**
>> 
>> Java sources are compiled with `javac`, jasm sources with `asmtools` that are delivered with `jtreg`.
>> An important factor: Integration with the IR-Framwrork (`TestFramework`): we want to be able to generate IR-rules for our tests.
>> 
>> I implemented a first, simple version of the framework. I added some tests and examples.
>> 
>> **Example**
>> 
>> 
>> CompileFramework comp = new CompileFramework();
>> comp.add(SourceCode.newJavaSourceCode("XYZ", "<source-code-here>"));
>> comp.compile();
>> comp.invoke("XYZ", "test", new Object[] {5}); // XYZ.test(5);
>> 
>> 
>> https://github.com/openjdk/jdk/blob/e869cce8092ee995cf2f3ad1ab2bca69c5e256ab/test/hotspot/jtreg/testlibrary_tests/compile_framework/examples/SimpleJavaExample.java#L42-L74
>> 
>> **Below some use cases: tests that would have been better with the CompileFramework**
>> 
>> **Use case: test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVectorFuzzer.java**
>> 
>> I needed to test loops with various `init / stride / limit / scale / unrolling-factor / ...`.
>> 
>> For this I used `MethodHandle constant = MethodHandles.constant(int.class, value);`,
>> 
>> to be able to chose different values before the C2 compilation, and then the C2 compilation would see them as constants and optimize assuming those constants. This works, but is difficult to extract reproducers once something i...
>
> Emanuel Peter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update test/hotspot/jtreg/compiler/lib/compile_framework/README.md
>    
>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>  - Apply suggestions from code review
>    
>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>

test/hotspot/jtreg/compiler/lib/compile_framework/Compile.java line 65:

> 63:         List<String> command = new ArrayList<>();
> 64: 
> 65:         command.add("%s/bin/javac".formatted(System.getProperty("compile.jdk")));

1. Use ```jdk.test.lib.JDKToolFinder.getJDKTool("javac");``` ?
2. Store in a static variable once during initialization? To not request properties /  call format string parsing every time?

test/hotspot/jtreg/compiler/lib/compile_framework/Compile.java line 101:

> 99:         List<String> command = new ArrayList<>();
> 100: 
> 101:         command.add("%s/bin/java".formatted(System.getProperty("compile.jdk")));

1. Use ```jdk.test.lib.JDKToolFinder.getJDKTool("java");``` ?
2. Store in a static variable once during initialization? To not request properties /  call format string parsing every time?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20184#discussion_r1801209700
PR Review Comment: https://git.openjdk.org/jdk/pull/20184#discussion_r1801210692