Adapt GraalVM to a state-of-the-art static analysis framework for universal Java program

[ziyilin]

Feature request

Besides the innovation of native image, GraalVM is a state-of-the-art static analysis framework as well. Currently there is no other Java static analysis framework can do points-to analysis as well and practically as GraalVM does. People from both industry and academia are looking for good Java static analysis tool for security analysis, code quality analysis and etc., but can't find a proper one. Making static analysis available for universal Java program can further expand GraalVM's influence and attract more people to the community. However, the current analysis result from GraalVM is only applicable for native image, not for traditional Java programs, because the static analysis framework is cohered with native image features, including but not limited:

• Class pre-initialization: In native image, Core JDK classes are preinitialized so that their <clinit>s are free from analysis, so the methods and fields accesses only from these <clinit>s are not taken as reachable. There will be less reachable methods and fields reported than it should be for traditional Java program.
• Class substitution: Many JDK classes are substituted, so the analysis results are different from original classes.

Describe the solution you'd like. We will propose several commits to adapt the static analysis framework for universal Java program, including:

• An automatic feature to report the static analysis result to a json file
• Disable class substitution for analysis
• Analyze class pre-initialization safety status without initializing all core JDK classes at BUILD_TIME
• Simplify the setup phase. Skip initialization work not required by analysis phase

We would like to contribute the code to the upstream in a branch as a start point, so that any one who is interested in this feature can collaborate with us to make the solution more sophisticated.

Describe who do you think will benefit the most.

• Java users who need a sophisticated points-to analysis as a base for various further static analysis.
• Java users who need to find all possible pre-initializing classes for Java program startup optimization.

This feature can turn these Java users into GraalVM users.

[christianwimmer]

The assessment in this feature request is only partly correct.

The points-to analysis of GraalVM Native Image is actually factored out into separate projects (com.oracle.graal.pointsto) that are independent from Native Image, i.e., this project has no knowledge about class initialization, substitutions, features, or any other Native Image API.

But of course there is no other user of the analysis (that we know of) other than the native image generator. So the API is a bit blurry, i.e., some things are not on the correct side of the project boundary. The major API are the classes BigBang (with its subclass Inflation) and HostVM (with its subclass SVMHost).

If you have commits that strengthen the API boundary, we are happy to review them.

FYI @cstancu @d-kozak

[ziyilin]

Thanks @christianwimmer. I know the com.oracle.graal.pointsto is separate, but its input was prepared by the previous native-image phases. My previous idea was to tailor the native-image framework to make the input clean, and user can still use native-image as analyzing driver. But now it seems creating a brand new main class to drive the analysis would be more clear and easier.

[christianwimmer]

I would start with a dependency just on com.oracle.graal.pointsto to start out as clean as possible. That means you make your own subclasses of BigBang and HostVM. If there are things that are currently in a SVM-specifc project than you can at first copy them over, and then later on we can work on hoisting it out to a VM-independent place.

[cyw3]

Hi, I also think com.oracle.graal.pointsto is very useful.

A easy way to custom rules for pointsto is necessary.

[fernando-valdez]

Hi @christianwimmer, there seems to be a lot of work done referring to this ticket, should we close this ticket?

[christianwimmer]

Depens on @ziyilin if they still plan to contribute PRs for this work.

[ziyilin]

Yes, there are still a few more PRs to go.