Bug 24393 – Going into ROM operator overload

Status
NEW
Severity
enhancement
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2024-02-13T19:42:31Z
Last change time
2024-12-13T19:33:17Z
Assigned to
No Owner
Creator
Richard (Rikki) Andrew Cattermole
Moved to GitHub: dmd#18214 →

Comments

Comment #0 by alphaglosined — 2024-02-13T19:42:31Z
When a block of memory goes into read only memory (cast or new), the operator overload ``opGoingIntoROM`` should be called upon it. Without this: - Classes cannot have optimizations that assume that the memory is actually immutable. As a result LDC does not apply it to ANY type causing performance problems. https://forum.dlang.org/post/[email protected] - Reference counting types cannot be immutable and therefore turn off reference counting. Otherwise segfaults if the memory is read only.
Comment #1 by razvan.nitu1305 — 2024-02-15T11:13:03Z
I fail to see how implementing opGoingIntoROM is gonna help either of the 2 mentioned cases. What can user code do to instruct LDC to put the data in ROM?
Comment #2 by alphaglosined — 2024-02-15T17:57:33Z
You have that backward. When you are going to mark memory as immutable (and with that potentially flagged as read only at CPU level), an object needs to be able to alter its behavior with respect to this. That is what this method does, it allows it to turn off the mutex so that it always locks/unlocks without mutation, and to turn off the reference count. It also means if disabled or missing that the type does not support being in ROM and hence cannot be immutable. So we kinda have three options as I see it: 1. Add some way for the object to adjust itself, so that immutable actually does mean process-wide immutability for a given object. 2. Disallow reference counting and Object to ever be immutable. We would of course need some way of detecting reference counting and that means we need it in the language. 3. Remove immutable as it doesn't offer the guarantees that the spec says it does (and cannot). This ticket focusses on the first one, as it doesn't break code and strengthens what guarantees the language "offers".
Comment #3 by robert.schadek — 2024-12-13T19:33:17Z
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/18214 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB