Opened 10 years ago
Last modified 7 years ago
#1112 new defect
Figure out a way to safely release objects
Reported by: | sjamaan | Owned by: | |
---|---|---|---|
Priority: | critical | Milestone: | someday |
Component: | core libraries | Version: | 4.8.x |
Keywords: | Cc: | ||
Estimated difficulty: | hard |
Description
The {{release-object}} procedure will just call {{free()}} on the object's pointer. This means that any Scheme variable still referring to the object will now point to free memory, which may get overwritten with arbitrary values.
The GC will not touch memory outside the heap, but it's possible that the freed object's memory gets "pulled in" when resizing the heap upon major GC, which means the GC's tests for whether it's in the heap space will succeed, causing it to treat the object as "valid", even if something else has temporarily written bogus stuff to that memory space in between.
We need a way for the GC to kill all references to the released object, but this is currently impossible: these references are plain pointers, and there is no way to ensure a GC won't find any references to these objects.
The trick used by object-become is to collect these objects on a special stack, and force a major GC, which then treats these objects specially. This is probably too much of performance impact though, because object-evict generally tends to be used for performance reasons.
Perhaps some form of "weak evicted object pointers" can be introduced?
Change History (3)
comment:1 Changed 9 years ago by
Milestone: | 4.10.0 → 4.11.0 |
---|
comment:2 Changed 9 years ago by
Milestone: | 4.11.0 → someday |
---|
comment:3 Changed 7 years ago by
Estimated difficulty: | → hard |
---|
This is too complicated and it's unrealistic to include it in 4.11 or 5.0, so I'll just relax the timeline to "someday". If anyone disagrees, they're welcome to write a patch for it ;)