Missing Modeling of System.out Bootstrap Initialization Leads to Incomplete Call Graphs

[mohPYdev]

Description

Summary

OPAL does not fully model JVM-initialized native-backed static fields such as java.lang.System.out. As a result, receivers obtained from such fields may have an empty points-to set in a 0-CFA analysis, even though they are guaranteed at runtime to reference concrete library objects.

In particular, the value stored in System.out is initialized during JVM bootstrap via native methods (not via Java bytecode visible to the analysis). Since OPAL’s points-to analysis relies on bytecode-visible assignments (or explicitly modeled native flows), it fails to associate System.out with its concrete runtime type java.io.PrintStream.

Consequently, virtual calls on System.out, such as println, may not be resolved, leading to missing call graph edges.

---

Minimal Reproduction

A minimal Maven-based project is provided in which a program invokes System.out.println(...) directly from a main method.

How to reproduce

Run OPAL’s 0-CFA call graph construction (TypeBasedPointsToCallGraphKey) using the provided interface script.
opal version: 5.0.1
java version: 8

Unzip the artifact. The test program is located in reproducing/, and the analysis driver is in interface/.

attachment.zip

python analysis_interface.py \
  --framework OPAL \
  --algorithm 0-CFA \
  --project reproducing \
  --type static \
  --reproducing_test_case_path ../reproducing \
  --boundary_id 1

---

Observed Behavior

• The getstatic java.lang.System.out instruction is modeled, but the resulting value has an empty or incomplete points-to set
• The receiver of println is therefore not associated with any concrete PrintStream type
• As a result, the virtual call PrintStream.println(java.lang.String) is not resolved
• The call graph omits the edge:

java.io.PrintStream.println(java.lang.String)

• This occurs despite the call being present in the bytecode (invokevirtual on a valid receiver)

---

Expected Behavior

For programs that use JVM-initialized static fields such as System.out:

• The analysis should model bootstrap/native initialization of core JDK fields
• The static field System.out should be assigned a concrete type (e.g., java.io.PrintStream)
• The receiver of println should have a non-empty points-to set
• The call graph should include:

{
  "caller": "com.example.App.main(java.lang.String[])",
  "callee": "java.io.PrintStream.println(java.lang.String)"
}

---

Notes on Implementation (inspected behavior)

From inspection of OPAL’s points-to and call graph construction:

• The receiver type for invokevirtual is computed via the points-to analysis over SSA variables
• For getstatic java.lang.System.out, OPAL relies on a configured native initialization chain
• The initialization of System.out occurs in JVM bootstrap code (native method setOut0)
• This initialization is not represented as standard Java bytecode assignments
• OPAL’s configured points-to analysis does not consistently inject a concrete abstract object for System.out
• As a result, typeIterator.typesProperty(...) returns an empty set for the receiver
• The call graph builder therefore has no candidate receiver types to dispatch println

Relevant components:

• CallGraphAnalysis.scala (virtual call dispatch logic)
• AbstractPointsToAnalysis.scala (points-to propagation)
• ConfiguredMethodsPointsToAnalysis.scala (native/config-driven modeling)
• reference.conf (configuration for JDK modeling / initialization behavior)

The core issue is a missing or incomplete modeling of JVM bootstrap initialization for critical JDK static fields, leading to an empty receiver abstraction and loss of virtual dispatch resolution.

---

Impact

If this limitation is unintended, it affects the precision of call graph construction in very common Java programs.

Static fields initialized by JVM bootstrap (especially in core libraries) are widely used, and include objects such as standard output streams, logging facilities, and system-level services.

Missing their modeling can lead to:

• Loss of virtual call resolution for standard library usage
• Incomplete call graphs even in trivial programs
• Cascading imprecision in interprocedural analyses relying on library entry points
• Reduced reliability of downstream analyses such as impact analysis, bug detection, and security auditing

Overall, this leads to under-approximation of call graphs in cases where runtime initialization occurs outside analyzable bytecode, particularly for JVM-native initialization paths.

[johannesduesing]

Hi @mohPYdev ,

thanks for taking the time to write such a detailed issue report! Unfortunately i am having trouble reproducing those issues. I used the App.java that you provided, and the following basic analysis setup using Java 8 and OPAL 5.0.0:

def main(args: Array[String]): Unit = {
    val p = Project(new File("./src/main/resources/App.class"))
    val cg = p.get(TypeBasedPointsToCallGraphKey)

    val printlnOpt = cg.reachableMethods().find(ctx => ctx.method.toJava.equals("java.io.PrintStream{ void println(java.lang.String) }"))

    assert(printlnOpt.isDefined)
  }

This test always passes on my machine, meaning that println is always found (also for all other CG-Keys i tested). This is also expected behavior as we do have configuration files that model the behavior of methods like System.initPhase1 and setOut0, and - as you rightfully point out - there are analyses that integrate this configured behavior into the overall result.

You say that you are using OPAL 5.0.1, however we never officially released a version like that. I checked out the specific commit fa37a36181cdcb3135999e76ffe90e617a434f8e used in your interface/Dockerfile and used it for the analysis code above, but still i was not able to reproduce the issue, the call to println was always found. My best guess is that this might be a JCG issue, or an issue with the changes you made to JCG in your fork - is there any way you might accidentally discard methods when e.g. the defining class is not available?