Hi all,
We know why now, but we don't have a good sense of overall impact.
There is actually a bit of magic at play here, so it's not obvious.
I'll just try to explain as briefly as I can
1. Association>>value: uses a special primitive call (marked in the 3rd byte of the compiled method, not a prim call like you would see it in the source code)
for setting inst vars efficiently. (VMprSetInstVarWP or VMprMBASetInstVarWP)
2. The smalltalk compiler does this in CodeStream>>inlineSetter and its able to to effectively do all those push/pops you see in inlineSetter in one prim call without interpreter overhead.
3. The code you see in Association>>value: code browser ... under most circumstances that is never run during normal execution.
4. Unless, VMprSetInstVarWP triggers a primitive failure ... in which case the code you see in the code browser is the fallback code that will be executed.
5. Why would VMprSetInstVarWP trigger a primitive failure ... how about a failed read-only object check (how this whole discussion got started).
6. When the prim failure occurs, it returns and starts executing the code from the bytecodes of the Association>>value: compiled method.
7. Unfortunately, when this got run through the 64-bit autoconverter, it didn't fix it up correctly.
8. The byte at position 6 in the bytecode array should be an 8 on 64-bit...not a 4.
9. The smalltalk compiler in the image can do it right...touch the method and save....now its correct.
We are reviewing the portion of the vm that must fixup 32-bit bytecodes into their 64-bit equivalents to see how far reaching.
I suspect its pretty isolated to this, and possibly a few others, since this has been true since 9.0 back in 2017 and this is the first we are hearing about it.
Naturally, we will get to work fixing it up.
Thanks to all for bringing this forward.
- Seth