From: [email protected] [mailto:[email protected]] On Behalf Of Jonathan S. Shapiro Sent: Thursday, March 24, 2011 3:05 PM To: [email protected]; Discussions about the BitC language Subject: Re: [bitc-dev] Inner references, regions, and CLI On Wed, Mar 23, 2011 at 11:52 PM, Ben Kloosterman <[email protected]> wrote: Basically safe = Java like language eg user app not system or high perf lib . Unsafe is where BitC should go since the Language itself will provide the safety. Since the only reason to target CLI at all is to get a quick solution for GC, I tend to disagree. Once we have to do our own GC, I think I'ld prefer to go with LLVM. Im talking unsafe with the GC which I have done quite a lot with. C# has stackalloc and fixed for pointers which do work with the GC , is this not enough ? Is the cost of fixed on a stack/static object to prevent compaction too high ? Fixed is not permissable within the safe subset. Can you point me to a description of stackalloc? http://msdn.microsoft.com/en-us/library/cx9s2sy4(v=VS.100).aspx const int arraySize = 20; int* fib = stackalloc int[arraySize]; int* p = fib; // The sequence begins with 1, 1. *p++ = *p++ = 1; for (int i = 2; i < arraySize; ++i, ++p) { // Sum the previous two numbers. *p = p[-1] + p[-2]; } Which basically generates what you expect for C code. ( and I love negatives for pointer offset! ) If you know the constraints than the C# fixed and stackalloc CIL equivalents will work with the GC and there shouldn't be a high cost. OK. So now we're looking at a weird middle position where the CIL modules will need to be compiled with /unsafe, and we propose to rely on "fixed" to deal with some of the mess. The "fixed" construct in CLR is surprisingly delicate, and *very* easy to get wrong from the perspective of the programmer. It fails completely if the captured reference ever escapes. There are legal and safe programs within a region framework where this kind of escape happens. I posted the API that fixed..uses But I agree that we are getting much closer to a resolution, and that this puts us on the bring of a workable pragmatic solution. Food for thought. The big issue with this scheme is you can do lots of nice static data / stack stuff BUT you need to know 1) The lifetime of static objects which have references to and from them and how long to pin it. [ Bitc has ] 2) The lifetime of unsafe operations for heap objects [ Bitc can do I think] 3) Is the unsafe operation worth it compared to just boxing it . Obviously with a call to the GC ( and likely a hash lookup) at the start and end it is only really worth doing for loops . [ This is a pain , do you push it to the programmer etc ] 4) Such code may have issues with finalization ie it must be manually released While it would be very nice ,not 100% convinced it's worth the effort . You do have a system / high performance role in the CLR but .NET libs are not easily usable as an OS and the libs are not callable from non .NET apps - still .NET is big and Merchant banks I have talked to what love to drop C++ for C# if it could offer similar performance . Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
