@Nullable Annotations lead to OutOfMemoryError

[SimonB]

Hello.
if you use more than about 25 @javax.annotation.Nullable Annotations as method parameter, the analysis get stuck:

public void method(
            @Nullable String a,
            @Nullable String b,
            @Nullable String c,
            @Nullable String d,
            @Nullable String e,
            @Nullable String f,
            @Nullable String g,
            @Nullable String h,
            @Nullable String i,
            @Nullable String j,
            @Nullable String k,
            @Nullable String l,
            @Nullable String m,
            @Nullable String n,
            @Nullable String o,
            @Nullable String p,
            @Nullable String q,
            @Nullable String r,
            @Nullable String s,
            @Nullable String t,
            @Nullable String u,
            @Nullable String v,
            @Nullable String w,
            @Nullable String x,
            @Nullable String y,
            @Nullable String z,
            @Nullable String a1
    ){
        //nothing to do here
    }

[INFO] 1 source files to be analyzed
[INFO] 0/1 files analyzed, current file: A/src/main/java/a/A.java
[INFO] 0/1 files analyzed, current file: A/src/main/java/a/A.java
[INFO] 0/1 files analyzed, current file: A/src/main/java/a/A.java
[INFO] 0/1 files analyzed, current file: A/src/main/java/a/A.java
[INFO] 0/1 files analyzed, current file: A/src/main/java/a/A.java
...

leading to OutOfMemoryError: Java heap space.

Best Regards.

[Tibor Blenessy]

Hello,

I presume this is not realistic piece of code, however it seems that you are interested in the internals of the analyzer, so I can explain what happens here. For every parameter annotated with @Nullable annotation we will try to explore what happens inside the method for both possibilities - parameter being either null or not-null. For every annotated parameter the number of possibilities doubles. This  means that for example you provided we create 2^25 possible "executions" of the method, which will exhaust the memory.

This is not very optimal, because we create those states eagerly, even if the parameter is not used inside the method in the end. I believe we could evaluate those states lazily, so I created following ticket to implement this improvement SONARJAVA-2538 .  I believe we are unlikely to encounter the limitation in the real world scenario, however this might improve also other functionalities of the analyzer, like reporting. Thank you for providing interesting edge case.

Regards

Tibor

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/91f84050-ce89-4198-b856-463bcbc23304%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Tibor Blenessy | SonarSource

SonarJava Developer

https://sonarsource.com