On 13/03/2010 2:47 PM, Jonathan S. Shapiro wrote:
> In order to run on CLR, there are two requirements you need to be able to
> meet:
>
> 1. Your program needs to be expressible in CIL. Ideally, but not
> necessarily, in safe CIL Your proposal above would address the safety
> requirement, though it isn't clear that the verifier in CLR (or any
> other implementation of CIL) is a safe component.
>
> 2. Your program needs to be expressible in a way that the CLR runtime
> (specifically the GC) can handle.
>
> Unfortunately, Microsoft does not seem to have given much attention to
> GC in an unverified environment. The presumptive purpose of unverified
> code seems to have been unmanaged languages. In particular, it appears
> that the GC only knows how to interpret types that are expressible in
> the verified subset of CTS. I spent some time looking in to this
> yesterday.
Yes, unsafe code must manage its own memory. This is the source of the
distinction "managed" vs. "unmanaged", ie. memory which the GC knows how
to traverse and collect vs. everything else.
> There is a range of possible solutions:
>
> 1. Somehow inform the GC about how to interpret these types.
> Unfortunately, the CLI specification does not appear to make any
> provision for this.
Perhaps via the CLR hosting APIs [1,2,3]. I know only of their
existence, not exactly what they offer. I just know that it's possible
to inspect and alter various aspects of a VM instance. For instance, you
can hook into Monitor.Enter/Exit logic and implement deadlock detection;
I believe such extensions must be written in an unmanaged language, as
all the examples I've seen have been in C++.
Unfortunately, I'm almost certain this API is specific to MS.NET. Not
sure if Mono provides something similar.
> 2. Reject unboxed unions containing references as "CLI unsafe". This
> is probably the most feasible solution.
> 3. Implement all unions containing references as boxed, but implement
> the copy semantics of unboxed unions for them.
> 4. Give up and compile to unsafe CLI, implementing the garbage
> collector by ourselves. At that point the only advantage over LLVM is
> the potential for interop. We would lose any/all advantage of the very
> mature CLI GC system.
>
> Off hand, those are the options I see, and of them, I think that [1]
> is infeasible and [4] gives us very little advantage that I can see.
Another advantage of unsafe CIL over LLVM: Mono supports JIT/native code
for way more platforms than LLVM.
Another advantage of LLVM over Mono: you can compile stand-alone
programs that don't require a runtime or GC.
I've only had brushes with unsafe CIL, so there may be further
disadvantages. I don't know how it interacts with generics for instance, ie.
[StructLayout(LayoutKind.Explicit)]
public class Foo<T>
{
[FieldOffset(0)] byte field1;
[FieldOffset(0)] T field2;
[FieldOffset(1)] byte field3;
}
Sandro
[1] http://blogs.msdn.com/shawnfa/archive/2004/11/12/256550.aspx
[2] http://msdn.microsoft.com/en-us/library/ms404385.aspx
[3] http://msdn.microsoft.com/en-us/library/9x0wh2z3.aspx
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
