Make MA work on Pharo 9/10 and on GT

[janvrany]

• TFFI not compatible to UFFI - missing #tfPointerAddress on Integer pharo-project/pharo#10737

[janvrany]

As of today and commit 591a83c , MachineArithmetic kinda works on Pharo 9:

cd pharo
make PHARO_DOWNLOAD_VERSION=90
make test

All tests but one (Z3CAPITest >> #testFindModel0) pass.

I believe this is because they disabled Pharo's home-grown implementation of threaded FFI in Pharo 9.

[janvrany]

@guillep: in #47 you mentioned you made MA working in Pharo 11? How?

When I tried to build an image in Pharo 10 in a fresh clone using following incantation:

make PHARO_DOWNLOAD_VERSION=100

the VM just crashed during loading of packages:

MetacelloNotification: Loaded -> PetitAnalyzer-Tests-CompatibleUserName.1593693365 --- [email protected]:shingarov/PetitPars
er.git[ULD] --- cache
MetacelloNotification: Loading -> PreSmalltalks-Pharo-tonel.1 --- tonel:///tmp/MachineArithmetic/pharo/.. --- cache

Segmentation fault Mon Feb  6 12:40:59 2023


/tmp/MachineArithmetic/pharo/lib/pharo
PharoVM version:5.0-Pharo 9.0.21 built on Dec  7 2022 20:44:42 Compiler: 5.4.0 20160609 5.4.0 20160609 [Production Spur 64-bit VM]
Built from: CoInterpreter VMMaker-tonel.1 uuid: c3846ddc-a3ab-0d00-9da8-da3508c6380e Dec  7 2022
 With:StackToRegisterMappingCogit VMMaker-tonel.1 uuid: c3846ddc-a3ab-0d00-9da8-da3508c6380e Dec  7 2022
 Revision: v9.0.21 - Commit: 191b5a0 - Date: 2022-12-07 20:24:02 +0100

C stack backtrace & registers:
        rax 0x19259468 rbx 0x7fc1abd0d2d8 rcx 0x7fc1abd02d00 rdx 0x19c6d7d0
        rdi 0x7ffd9987d150 rsi 0x7ffd9987d150 rbp 0x7ffd9987d150 rsp 0x7ffd9987d118
        r8  0x193f58d8 r9  0x1aa89dd8 r10 0x00000026 r11 0x1ae7ae10
        r12 0x00000001 r13 0x00000001 r14 0x1aa62c70 r15 0x00000000
        rip 0x193f58dd
*[0x193f58dd]
/tmp/MachineArithmetic/pharo/./lib/libPharoVMCore.so(+0xc3e4c)[0x7fc1abac3e4c]
/tmp/MachineArithmetic/pharo/./lib/libPharoVMCore.so(doReport+0xb5)[0x7fc1abac4135]
/tmp/MachineArithmetic/pharo/./lib/libPharoVMCore.so(sigsegv+0x14)[0x7fc1abac41a4]
/lib/x86_64-linux-gnu/libc.so.6(+0x3bf90)[0x7fc1ab85af90]
[0x193f58dd]
[0xffffffffffffffff]


All Smalltalk process stacks (active first):
Process         0x1f0896d8 priority 40
    0x7ffd9987d150 M Array class(SequenceableCollection class)>new:streamContents: 0x1aa62718: a(n) Array class
    0x7ffd9987d190 M AdditionalMethodState>pragmas 0x1986d5c8: a(n) AdditionalMethodState
    0x7ffd9987d1c8 M CompiledMethod>pragmas 0x1983d538: a(n) CompiledMethod
    0x7ffd9987d1f8 M CompiledMethod>cachePragmas 0x1983d538: a(n) CompiledMethod
    0x7ffd9987d230 M MethodDictionary>at:put: 0x1aaff368: a(n) MethodDictionary

Full log attached/
log.txt

[guillep]

Sorry for coming late, this week will be a mess for me.

I can confirm that I did:

Metacello new
  baseline: 'MachineArithmetic';
  repository: 'github://shingarov/MachineArithmetic:pure-z3';
  load: 'Z3only'

Tested in Pharo 11.0.0

• Build information: Pharo-11.0.0+build.442.sha.1946edffbbb0d0f7f78dc8f12a62969535bc015e (64 Bit)
• macOS Monterey 12.2.1, Apple M1
  (and for the record, it's a default P11 downloaded by the Pharo launcher)

Maybe it's the fact that I used Z3Only group?

[janvrany]

Okay, so I dug just a little deeper and I believe the core of the problem is that primitive numbers have changed between Pharo 8.0 and Pharo 11.0:

BlockClosure >> ...	Pharo 8	Pharo 11
... >> value:	prim 202	prim 207
... >> value:value:	prim 203	prim 207
... >> valueWithArguments:	prim 206	prim 208

So. currying support in PreSmalltalks-Pharo breaks Pharo 11 to the point VM crashes. Perhaps some missing checks like in OSVM.

If I remove these methods, MA loads without crashing.

This is quite unfortunate since to fix this (if we want) we'd need to separate currying in yet another set of packages and load them conditionally depending on pharo version...

[janvrany]

I have opened draft PR #52 for fixing MA on P9 and later.

I managed to fix primitives but it turned out that on P10 (at least), ifTrue:ifFalse: deoptimization does not work out of the box, so more work is needed to enable it again (assuming it can be done easily, if not...)

[janvrany]

FYI: @melkyades