[Dlang-study] [lifetime] Let's focus on escape analysis
deadal nix
deadalnix at gmail.com
Sun Nov 1 14:09:04 PST 2015
There has been a fair amount of discussion about RC here, but I think it is
missing the bigger picture.
There are a lot of variation of RC that can be done, but it doesn't really
matter. After all, the problem that we want to solve as languages designer
here is to control how references escape.
This is mandatory to have safe RC. After all, reference counted objects
will have member data, which aren't themselves reference counted, and the
language have to ensure these do not escape in unsafe manner.
But here is the plot twist: if we can provide a language solution that
ensure member data do not escape in unsafe manner, then we can ensure that
whatever is in a RC wrapper doesn't escape in an uncontrolled manner. We
win 2 things going that road:
- All variations of RC become a library problems. We don't need to make a
judgement call on them at language level.
- Functionality and memory management can be decoupled (upcast problem,
library can delegate RC/GC choice on their users).
Additionally, RC is a fairly small part of the problem. Unique reference
require the same kind of escape analysis while being WAY more common than
RC. Some here already did some grepping in Rust's source code to get an
idea of this, but here are the number I get grepping into clang/llvm :
$ grep -r ../llvm/lib/ ../clang/lib/ -e unique_ptr | wc -l
1362
$ grep -r ../llvm/lib/ ../clang/lib/ -e shared_ptr | wc -l
73
It is not even close.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dlang-study/attachments/20151101/f3681a76/attachment.html>
More information about the Dlang-study
mailing list