native-image does not respect ConstantValue, if initialized at run-time

[Vukooo]

Describe the issue
If a class defines their initial value of a static field with the "ConstantValue" attribute, svm evaluates the field to null, if the class get's initialized at runtime. If the class get's initialized at build time, it works fine.

Steps to reproduce the issue
Please include both build steps as well as run steps

1. git clone https://github.com/Vukooo/NativeImageFinallyReproducer -b bug-constantvalue
2. sh run_not_working.sh // Null will be printed
3. sh run_working.sh // "INITIAL-VALUE" will be correctly printed

Describe GraalVM and your environment:

• GraalVM version: GraalVM Runtime Environment GraalVM CE 17.0.7+7.1 (build 17.0.7+7-jvmci-23.0-b12)
• JDK major version: 17
• OS: macOS Ventura
• Architecture: arm64

[smthelusive]

Hi @Vukooo,

I was curious to look into your issue and I found some information that might be helpful for you.
In the section that you mentioned from the JVM specs, it doesn't say explicitly that the constant field also should be final. However, the constant fields in Java are always the ones that are static and final.

Also, it's possible to make such conclusion from the other chapter, which describes the initialization process:
Then, initialize each final static field of C with the constant value in its ConstantValue attribute, in the order the fields appear in the ClassFile structure.

If you change your code to make that field also final, it will work, like so:
fieldVisitor = classWriter.visitField(ACC_PUBLIC | ACC_STATIC | ACC_FINAL, "test", "Ljava/lang/String;", null, "INITIAL-VALUE");
Both with initialization during build time and during runtime.

(I do agree that the JVM specs are not always super explicit).
Hope this helps.

[Vukooo]

Hi @smthelusive,
Thanks for pointing out the part of the specs that suggest, that it only evaluates for final fields. I missed that part and I do agree, that it sounds like, ACC_FINAL is required!
The problem I currently have is, that a bytecode emitter (r8) emits bytecode in a way, you see in my reproducer. I don't have immediate control over it. So for me the question is, where does the bug needs to get fixed. Is it in graal for requiring the ACC_FINAL flag to evaluate ConstantValue, or is it in r8 for emitting a ConstantValue without ACC_FINAL?

// EDIT: For some reason github posted this twice, I'm sorry about that.

[oubidar-Abderrahim]

Thank you for reporting this, we'll take a look into it shortly

Tracked internally on GR 47069

[Vukooo]

Hi,
I just wanted to ask, whether there is any update to this? Is it confirmed, that this is a native-image issue?

[christianwimmer]

Thanks for the report, it is fixed in the upcoming GraalVM for JDK 21 release.

Some details if you are interested: before #6463 there was no proper way to read the ConstantValue attribute via the JVMCI interface that the native image generator relies on. So there was heuristic to read field values via Unsafe, and it was only enabled for final fields: https://github.com/oracle/graal/pull/6463/files#diff-d1d1982c1cf83e40b967cf8bceebf42e6c70341394f77ad7a2f47b8fc76c87ccL75

[Vukooo]

Thank you very much for fixing this!
Would this be able to get backported into GraalVM for JDK 17? I'm currently running on that and upgrading is not that easy for me.

[christianwimmer]

Would this be able to get backported into GraalVM for JDK 17?

That is a tricky problem. On the one hand, the behavior that you see is clearly a bug, which could be fixed in an update release. On the other hand, that fix also changes a pretty fundamental part of the image generator, how the lookup of static field values is done. So for the upcoming October patch release, it is too risky. But I will try to estimate possible impact, and how we can test that and ensure no user observes changes except the bugfix, for the next update release. I also need to double-check all necessary parts are in JVMCI.