RFR: Load coops base shift from AOTRuntimeConstants in AOT code [v2]

[Andrew Dinn]

On Thu, 12 Sep 2024 23:13:21 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   only check UseCompatibleCompressedOops on 64 bit builds
>
> Thinking more.
> 
> On other hand, only AOT code will suffer. Recompiled code will be optimal which is good for peak performance.
> And with UseCompatibleCompressedOops recompiled code will also suffer.
> 
> I need to see numbers how it affect performance of AOT code.  I hope CPU's prefetcher will keep these values nearby.

@vnkozlov I pushed fixes for your feedback and then planned to get some performance numbers. However, when I rebuilt (on aarch64) and retested a simple javac HelloWorld I got a ClassCastEception from the production run:

java.lang.ClassCastException: class java.util.HashMap$Node cannot be cast to class java.util.HashMap$TreeNode (java.util.HashMap$Node and java.util.HashMap$TreeNode are in module java.base of loader 'bootstrap')


This is happening in the interpreter when executing HashMap::putVal in this code

            Node<K,V> e; K k;
            if (p.hash == hash &&
                ((k = p.key) == key || (key != null && key.equals(k))))
                e = p;
            else if (p instanceof TreeNode)
                e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);
            else {
                for (int binCount = 0; ; ++binCount) {

The callout to the exception handler happens at bytecode 114

     104: aload         7
     106: instanceof    #173                // class java/util/HashMap$TreeNode
     109: ifeq          131
     112: aload         7
     114: checkcast     #173                // class java/util/HashMap$TreeNode
     117: aload_0
     118: aload         6

I looked at the oop in local 7 and it is indeed an instance of HashMap$Node, not HashMap$Treenode. We load both C1 and C2 code from the AOT code cache for this method. So, I supsect this may be a deopt issue. I'll try to catch the deopt callout and see if I can work out where it might be going wrong.

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

PR Comment: https://git.openjdk.org/leyden/pull/20#issuecomment-2361386128