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

[Thomas Stuefe]

On Wed, 12 Jul 2023 19:48:52 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> Please review this fix to correctly read a long value in the runtime constant pool. Details are mentioned in the issue [0].
> As an example, before this fix the long value generated by SA's dumpclass for java.lang.String.serialVersionUID was:
> 
> 
>   private static final long serialVersionUID;
>     descriptor: J
>     flags: (0x001a) ACC_PRIVATE, ACC_STATIC, ACC_FINAL
>     ConstantValue: long 2050732866l
> 
> 
> After this fix value of java.lang.String.serialVersionUID is:
> 
> 
>   private static final long serialVersionUID;
>     descriptor: J
>     flags: (0x001a) ACC_PRIVATE, ACC_STATIC, ACC_FINAL
>     ConstantValue: long -6849794470754667710l
> 
> 
> Correct value as obtained from original java.lang.String is `-6849794470754667710l`.
> 
> Testing: tests under `serviceability/sa` and `sun/tools/jhsdb` are passing.
> 
> [0] https://bugs.openjdk.org/browse/JDK-8311971

Patch is correct. Tested manually, works and fixes both long constants and double constants.

AFAICT the problem only shows up for values > 32-bit, at least on little endian machines, that may have been the reason it had not been discovered before. Still, odd, for such a long time. We really should have better tests for that.

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14855#pullrequestreview-1530755805