On Wed, May 16, 2012 at 3:23 AM, Jonathan S. Shapiro <[email protected]> wrote:
> > There is also a bunch of static analysis that can be done to automatically > stack-allocate storage and/or identify heap objects that are accessed by a > single thread. Both of these are really worthwhile. While I agree here I always wondered if there was someway to improve the language GC interaction , the obvious cases is static allocation ( stack or manual buffers) and if this is done in an isolated single thread in a task like system it should be possible to be pause less and not incur the write barrier. With pauseless collectors is the next phase the ability to improve performance by removing the costs under isolated conditions like the above ? > > >> >> ...However GC has speed penalties... > > > The empirical data says that this isn't true. For some cases it can be , I was with some clients which had a large scale message based pub sub system , 90% of the work was just writing memory and sending it to the network and there prototype system suffered heavily from the GC write barrier ( and the business requirement algorithmic trading was sensitive to 1ms ) . I think safe memory system have speed issues not necessarily the GC , I think these in order are - bounds checks ( Java has mostly eliminated these but mono for example does a very poor job even after 8-10 years ) , its a good example of the theory being there but expensive to implement well. - GC write barrier . To avoid this you need to have some way to know that some stack allocated types don't references and hence don't need this cost .. - Sycnronization issues . The locks around various points are costly especially nursery allocation. Again they don't need to be there . - GC itself . No great performance impact . So while GC don't theoretically have theoretical speed penalties its a massive engineering problem to do well. > What is true is that (a) GC > amortized storage allocation costs differently, and therefore has an > occasional long pause time (~20ms in modern collectors), and (b) > high-performance GC typically requires 3x-10x more DRAM (real memory, not > virtual) than a comparable program using manual storage. Or at least, these > statements were true before the C4 collector was announced. I'm not sure how > that collector may have changed the answers. C4 seems to need a lot of memory ... >> >> To handle this problem, I introduced an allocation type, e.g. the >> metacore-programmer >> can force allocation to occur on the call stack, like C automatic >> variables. >> i.e. >> >> tmp var x:FooDataType ; >> >> will force x of data-type FooDataType to be allocated on the stack. In >> conjunction with call by ref procedures >> this allows write C style code regarding local memory. This temp memories >> allows closures and >> dictionaries for (type) classes to be be allocated on the stack if >> possible, by using some simple form of >> allocation-type-inference. > > > These are known as unboxed types. Automatic stack allocation is a good > thing, but it should be done generally. What you need to do this is escape > analysis, which is *not* a simple inference problem in the general case. > Conservative escape analysis is often good enough in practice. > > However, note that automatically stack-allocated objects are still in the > heap conceptually, and you still need to pass around pointers to these > objects. It is helpful if your compiler can implement the stack-allocation > pass as a source-to-source (or at least IL to IL) transformation. This can't > be done without region types in the IL. unboxed types ( value types) work well here .. passed by value not reference. And it is here where most system programming needs the performance eg arrays of ints on the stack or in a custom static buffer ( non GC ) etc. Though the GC really needs to know if these types contain references , if the compiler knows it does not need to be passed for marks. Again more complexity and more expensive engineering. Java is not the best language but it gets good results/benchmarks. . Ben _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
