On Mon, Apr 16, 2012 at 10:52 AM, Jonathan S. Shapiro <[email protected]>wrote:
> On Sun, Apr 15, 2012 at 10:56 PM, Matt Oliveri <[email protected]> wrote: >> >>> If you want a typesafe runtime to replace C, then you are essentially >>> saying we should write all programs on top of some fixed runtime. >>> >> >> Yes. That runtime would evolve over time, but yes. >> > > I more or less agree. One thing I would like to see is a successor to CIL > that provides for regions and parametric types, and maybe for "shape types" > (which I need to explain). > Sounds great! (as long as it doesn't stop-the-world) Wait, I think that angelic sound and light beaming down from the heavens is Shape-Jeske unification. Lets go build that. - Are CIL apartments not a different way to achieve Regions? - What about the CIL type-instantiated generics does not meet your definition of parametrics? - very interested to hear about shape-types.. - As for your previous comment about wanting subtyping in structs.... I'm not convinced subtyping is the right reuse mechanism. It creates very large challenges for modular forward upgradability. I'd prefer to see us experiment more with composition and aggregation, more like COM or Google-Go. Composition is a common pattern at the program architecture level as well because of greater flexibility vs locked single-inheritence hierarchies. (i.e. traits, game-component-architectures, flat-driver interfaces, flat-plugin interfaces, etc.) > I object to this. I do not believe people turn to C to avoid compromise. >> If so they would always turn to assembler. I believe they turn to C because >> it offers an improvement in programmer productivity in exchange for a >> linear-performance degregation. >> > > But you yourself note that C is essentially asm with human syntax. > touche! Guilty as charged. I still maintain it is primarily the non-linearity of GC-pausing that has us stuck in C-land, not a linear performance degredation. Linear performance degredation is not a limit to deployment or scalability and is only an issue in the most hyper-optimized of cases (which hardly exist). Wheras GC-pausing is a non-assaultable response-time wall. GC systems which stop the world don't give us ways to avoid it for many application types. (the best we can do is get data out of the heap, which often means just moving to C++) > I think there are a bunch of reasons people turn to C: > I'm really thinking about the reasons people continue to turn-to-C "in the limit case" (i.e. into the forseeable future until we give them a way not to). Not the instantaneous reasons we do. Broadening my scope somewhat, my list is much shorter than yours... - non-linear performance cases (GC-pausing and mandatory stack-walking at exception throw) - lack of a suitable contract model for exceptions (which is a whole additional discussion in itself) - lack of a truly-permissive royalty-free-runtime... (mono-runtime is LGPL, and there is Microsoft patent fear) ( Aside: I wish Microsoft would just solve the patent fear thing already. They kinda did but didn't with the vague promise of non-discriminatory licensing. It would be better if CIL was declared free or had a licensing price-list for runtime patents. Otherwise the industry will probably steer clear for a long time. When I was at Google I encouraged the consideration of CIL for Android, but the MSFT rivalry is challenging to work through. Ironic now given the Oracle lawsuit. Licensing CIL might have been reasonable in comparison. ) I really like your list, so I'm going to deep-end a little commenting on it... > > - Maybe I'm writing something that is dependent on an existing library > in C (e.g. OpenSSL) > > Software is kinda magical in that we can copy it for free, so I'm pretty sure we'd built up a healthy core of pretty much everything as soon as a typesafe system met the criteria. Heck, we've built up a pretty healthy core of stuff in lots of systems that don't actually meet the criteria. > > - Maybe I need decent I/O performance, and safety is pushing me into > data copies that I can't afford to do. Biagioni's work on TCP in ML is > instructive here. Foxnet is painted as a success, but actually it's pretty > depressing. > > I don't see what data-copies are required if CIL talks to the syscall interface directly. CIL also opens the door for post-syscall kernel designs. Again, I'm thinking limit-case here.... of course today I agree with your comment. > > - Maybe my app warm-up time matters (so JIT gets in the way). This was > the main issue for in-transaction database servlets > > This was a problem in JVM, but CIL AOT pretty much solves this. In fact, CIL provides the best of both worlds, because you can AOT something that approaches C-shlib level startup times, and still get JIT inlining across boundaries with polymorphic inline caches and other tricks. CIL can also do a safer and better job assuring there are no field-offset-compatibility mismatches (like expectations of different layout stat_t structs) and can even fix some of them automagically. > > - Maybe pause times worry me > > Isn't that the ugly truth! > > - Maybe the problem of debugging inadvertently retained storage was > too hard > > I read that as "debugging memory leaks". It's always seemed roughly the same as debugging C/C++ memory leaks to me. I suppose automatic-memory management does allow us to build contracts with much more complex memory ownership consequences, which in turn could lead to this problem. I'll have to consider that. > > - Maybe I just don't know any better > > We need to make a better CIL-ish before we can say this. Currently the C-runtime *IS* actually better. > > - Maybe I care about performance, therefore about memory placement, > and therefore need a rich system for unboxed types > > I've been really happy with CIL structs, struct-arrays, type-instantiated generics. What do you think we need that it can't do? > > - Maybe the *physical* heap footprint of my app matters. Either I > can't afford 10x the memory initially, or I'm operating at a scale where I > can't afford to *cool* 10x the memory. That's why Google can't use > some of this stuff. > > Why would CIL take 10x the heap? I don't see that at all. Except for maybe the dubious decision to make all strings UCS-2, I don't see any reason CIL needs to be much bigger than C++. Azul-C4 has a constant heap overhead. One of the projects I ran while at Google started out on .NET 2.0 / Windows as a bit of an experiment. We tried to move it to Linux-mono, but it wasn't viable at the time. It ultimately moved to a mix of C++ and Java. Memory overhead (in CIL or Java) was not an issue. GC pausing was/is. It had "very significant" traffic. > > - Maybe I care about security and modularity, and I've worked out that > taming the Java standard library is utterly hopeless. > > All I'm saying here is that GC is just one of *several* issues that are > getting in the way of safety adoption > Certainly there are more issues than GC-pausing. I guess I single it out because it's among the few issues that no amount of library work can solve. One has to change the runtime, and if Azul C4 is any indication, the operating system and hopefully one-day the processor.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
