RFR: 8311971: SA's ConstantPool.java uses incorrect computation to read long value in the constant pool

[Thomas Stuefe]

On Fri, 14 Jul 2023 17:33:59 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This raises a few questions for me.
>> 
>> First, what is it about constructing the long from two ints that is incorrect?
>> 
>> Second, the fact we have `VM.buildLongFromIntsPD` suggests this is the intended way to do things. Why do we also have `Address.getJLongAt()`? Do we not actually need  `VM.buildLongFromIntsPD`? Is its other use in the code in ./jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/StackValueCollection.java also incorrect?
>> 
>> And third, how can it be that we seemingly have no test for this???
>
> @dholmes-ora Could this code precede the 64-bit version of java? It would certainly make sense for 32-bit when a 64-bit value needs to be cobbled together by reading two slots. The function precedes the initial OpenJDK load, so I cannot check.

> @tstuefe I don't think this pre-dates 64-bit as the change was made in August 2002. The irony here is that the new code in the PR is what we originally had in August 2002 until we had to fix a "jlong unaligned access" issue! At that point I think someone simply got confused about how classfile parsing needs to interpret the `CONSTANT_Long_info` when filling out the constant pool entry, versus reading back that existing CP entry.

That sounds likely. Pity we don't have the history prior to opensourcing the JDK.

Thanks, Thomas

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

PR Comment: https://git.openjdk.org/jdk/pull/14855#issuecomment-1638670065