On 2023-12-10, at 5:45 AM, Juan Vuletich juan@cuis.st wrote:
BTW, I guess this means that the Display bits are also pinned by the VM upon calling #beDisplay, right? Otherwise the GC would move them, and the crash would happen all the time.
That depends. If you use the Display bits by starting from an oop that the GC pays attention to then you're safe unless the relevant code tries to run in the middle of a gc that affects the display bits. That's a danger of multithreaded systems and then we get into putting locks on things and failing to release the lock at the right time and then nasty creatures from the dungeon dimensions leak out and eat you.
I used to copy bits from the squeak Display object to an OS sprite (yes, RISC OS kept ancient terminology) so that the OS code could do anything it liked at any time. It's wasteful of memory, obviously. It used to seem like a lot of waste in the days of 4Mb ram machines. Now with vast 32bpp screens it seems like a lot to me still! Then again, when even a Pi can have 8Gb, who really cares? I mean have you seen what other applications use to do a tiny fraction of what smalltalk does?
In other older systems I used to allocate fixed memory outside of object space and set the bitmap instvar in the Display from, and modified the GC to ignore the relevant bits. In another old system we could actually just set the hardware pointer for the physical display to point anywhere and the gc could update that if needed.
I'm not huge fan of pinning objects because they can make for nasty logjams in compaction. Maybe it would be practical to pin the display bits intermittently, ie only when it really needs to be locked? That might have the same issues as a thread lock though.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Overdue for deincarnation.