[bitc-dev] Inner references, regions, and CLI
bklooste at gmail.com
Wed Mar 23 23:32:37 PDT 2011
I want to divert for a moment to talk about CLI again. By "CLI", I mean the
safe CLI subset. This is not just a political issue; much of our purpose in
targeting CLI is to gain the advantage of existing GC infrastructure, and we
only get that if we target the safe subset.
There are two notional features in BitC at the moment that have no
translation to CLI within the safe subset. The first is inner references,
and the second is region-based references (which are a specialized form of
If C is a CLI reference type (a class) having a field f of type F, and c is
a reference to an instance of C, then c.f has type F. That is: there is no
way to capture a reference into the interior of an instance of C within the
safe CLI subset.
The consequences of this are unfortunate. While CLI does provide a mechanism
for by-reference parameters, these references are "internal" references that
cannot be captured. In essence, they carry a restriction analogous to the
current BitC by-ref parameter type.
Unfortunately, this touches on region-constrained references as well. In
particular, it means that we cannot stack-allocate certain values even when
we know (and can prove) that the relevant lifetime constraints are
This raises two issues:
* The BitC specification has to be weasily about when stack allocation
is required, in order to leave leeway for a .NET or JVM-based implementation
to be a conforming implementation. In effect, we're driven to introduce a
two-layer conformance scheme, in which we distinguish between a semantically
conforming implementation and an implementation that conforms to a
particular set of unboxing and layout contracts.
* Our ability to make effective use of liveness-constrained references
(that is: regions) is going to be limited.
For liveness-constrained references into the stack, the solution in .NET is
probably going to be to heap-allocate those values in order to eliminate the
liveness constraint. That appears to be the best we can do.
Unfortunately, I don't see any way at the moment to implement capturable,
liveness-constrained references to a struct or class field.
Does anybody know of any work that has been done on this sort of thing in a
.NET context? It's very possible (indeed, damned likely) that someone out
there is more clever than I am.
May be worth looking at the C++ implantation it's the only language ( and
C#) that allows some unsafe stuff. But I do know its very limited.
For completeness, our other alternative is to target the unsafe CLI subset.
At that point we can do almost anything we want, but we are completely on
our own for implementation of GC and the like. I'm not even sure that there
are contracts in that corner of CLI regarding sequence points and
JIT-generated temporary values. Even if those contracts exist in the
specification, it's likely to be an under-explored part of the JIT
subsystem, and one that nobody feels any urgency about addressing.
Anybody see any light at the end of this tunnel?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitc-dev