mirror of
https://git.savannah.gnu.org/git/guile.git
synced 2025-06-06 12:10:28 +02:00
Docs docs
This commit is contained in:
parent
50e90a026a
commit
22f5b44330
1 changed files with 9 additions and 8 deletions
|
@ -114,14 +114,15 @@ After all these years, *whether* to mark stacks conservatively or not is
|
|||
still an open research question. Conservative stack scanning can retain
|
||||
too much data if an integer is confused for an object reference and
|
||||
removes a layer of correctness-by-construction from a system. Sometimes
|
||||
it is required, for example if your embedder cannot enumerate roots
|
||||
precisely. But there are reasons to consider it even if you can do
|
||||
precise roots: it removes the need for the compiler to produce a stack
|
||||
map to store the precise root enumeration at every safepoint; it removes
|
||||
the need to look up a stack map when tracing; and it allows C or C++
|
||||
support code to avoid having to place roots in traceable locations
|
||||
published to the garbage collector. And the [performance question is
|
||||
still open](https://dl.acm.org/doi/10.1145/2660193.2660198).
|
||||
conservative stack-scanning is required, for example if your embedder
|
||||
cannot enumerate roots precisely. But there are reasons to consider it
|
||||
even if you can do precise roots: conservative scanning removes the need
|
||||
for the compiler to produce a stack map to store the precise root
|
||||
enumeration at every safepoint; it removes the need to look up a stack
|
||||
map when tracing; and it allows C or C++ support code to avoid having to
|
||||
place roots in traceable locations published to the garbage collector.
|
||||
And the [performance question is still
|
||||
open](https://dl.acm.org/doi/10.1145/2660193.2660198).
|
||||
|
||||
Anyway. Whippet can scan roots conservatively. Those roots are pinned
|
||||
for the collection; even if the collection will compact via evacuation,
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue