On Sat, 2007-01-27 at 11:49 +0100, Pierre THIERRY wrote:
> I may have missed it in BitC specification, but I didn't find anything
> about how value and ref types will be allocated and, for ref types,
> manually deallocated.
Value types fall into two cases:
1. Those that are stack-allocated. These are allocated by the compiler
when the constructor is encountered.
2. Those that are contained by some other object. The containing object
may be either a value type or a ref type, and the allocation follows
the rule for the containing "box".
For ref type deallocation, we initially expected that BitC would be used
in two modes:
1. A "normal" mode, where ref types would be deallocated through GC.
2. A "discharge" mode, where one can write:
(free <ptr>)
but this incurs a proof discharge obligation to show that no copy
of <ptr> is live after the call to free returns.
As things have progressed, I am coming increasingly to believe that the
second model will never be used. In Coyotos, we appear to have three
cases:
1. Critical processes. These must operate in bounded resource anyway.
These processes have the property that they allocate but never
free.
2. Event-loop processes: these processes have a natural point where
GC can be done efficiently (the top of the event loop), and when
it is done at that point the result is probably more efficient than
free.
3. General processes. These were unlikely to be able to accomplish
the proof discharge in any case, and we always assumed GC for
these.
Note that in support of type (1) processes, we do intend to provide a
compile mode in which operations that lead to heap allocation are
identified as errors by the compiler.
> I suppose that at least in the bootstrapping of the language, using some
> kind of free primitive will be necessary (probably at least to write the
> GC...).
Perhaps surprisingly, this is not true. The only place that I have ever
seen a GC implementation use anything like a "free" operation was in
unmapping parts of the underlying heap.
> I'm also wondering how a process like the network stack described in
> "Network Subsystems Reloaded" would be written: it should at least be
> able to specify where to allocate space for objects according to the
> client they will be used for.
This is outside the scope of the language definition. It demands support
for explicit heaps, and we don't have a story for that at the moment.
> I suppose there should be some mechanism to specify the address of the
> heap where heap-allocated types would be allocated. The space where this
> heap would reside would be given by invoking a capability to the space
> bank given by the client.
Definitely not. BitC as a language will not have any Coyotos
dependencies. What you are talking about here is one possible low-level
implementation of the runtime, but BitC is not a Coyotos-specific
language.
--
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
+1 443 927 1719 x5100
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
