On Wed, Aug 7, 2013 at 10:40 PM, Jonathan S. Shapiro <[email protected]>wrote:
> On Tue, Aug 6, 2013 at 8:50 PM, Bennie Kloosteman <[email protected]>wrote: > >> Why a sub heap and not a seperate heap ? Or is it because its still >> under the GCs nominal control ? >> > > At the time I wrote that, I was considering this as a problem of how to > subset the GC heap. In that frame, thinking of it as a sub-heap seemed to > make sense. > > Ultimately, there are no separate heaps. At a certain level, all objects > live in some portion of the heap and need sufficiently compatible semantics > for a single set of pointer types to make sense. The minute you can have a > pointer from one "separate heap" to another you have a single heap again. > Q. If region analysis shows no ref , you can put it in a sub heap .. what happens when the region scope finishes and you can set such pointers are you envisaging the sub heap just automatically becomes part of the whole GC or do you move / copy such objects . > > >> ** >> Why do we need ARC at all in the automatic system , since It can be slow >> for the non single threaded cases. ? >> > > I raised ARC in the context of trying to avoid mark/sweep overheads on > sub-heaps. If you aren't marking in a sub-heap, you need something that > lets you know when to release. ARC is one possibility. This is one of > several possible approaches to reducing the tenured churn problem. > Can region analysis show how often references will be counted and make a performance cost here ? Is it possible to have a "sub" GC as one of the options eg Stack , Region type Stack , ARC , Sub GC , Type reuse heap .. ? What would you use for lots of string work , strings are very likely to be the main use of a sub heap ( no ref to anything else) ? ARC if the number of refs is not high but it can be. ( and i think the .NET GC has a seperate pool for strings as it does not need to mark them , in fact all immutable objects containing no references ) . That said is there a way to have lots of string work , but not affect the main GC pauses or use ARC ? > >> ...why is the pauseless GC not doing it on a separate heap? >> > > Again, I don't think there *is* a separate heap. As to why pauseless GC > doesn't solve this: > > 1. We don't have a readily available pauseless GC implementation, and we > don't know whether such an implementation is feasible on a weakly > consistent memory. > 2. If we *know* a region has certain liveness properties, there is no > reason to trace it, regardless of the tracing technology. Pauseless > concurrent GC may "keep up", but it still places a workload on the CPU and > the memory subsystem. Techniques that let us reduce that work help us for > *any* GC technology, and are worth exploring for that reason. > > In terms of relieving the GC regions , type aware heaps seem more >> promising. >> > > The early research showed some fairly bad fragmentation issues with > type-aware heaps, and I think you may be under-rating the problems that can > arise when pointers you thought were dead become valid again through > reallocation. > Dead pointers that become live would be nasty - an engineering problem ;-) , but i was more thinking of your attributed regions ie ptr[Nodes] where nodes is just a sub heap of type nodes with a large amount of allocation and deallocation and hence reusing the node slots . Many algos here nodes ,fixed size buffers etc. Im thinking short ( but for a significant amount of work that would exceed say a nursery capacity) or program lifetime. Sure you can do it yourself but doing it in the language may encourage more allocation like this relieving the GC - programmers shoudl do this . Many Malloc imps does it automatically ( though on size but in many cases of high use the type will also be the same) so would be nice to have a similar result with a similar technique even just for the PR on the micro benches. Yes with type reuse where the size is different eg strings fragmentation would be a nightmare , but for same size why is frag. worse than malloc ? Is it the overhead of N heaps , 1 for each type that would be bad.. but we are looking at short lived or specialised heaps here.. > > >> Not many type safe languages that allow these sort of things done in a >> lib .. >> > > Who said anything about doing this stuff in a library? > You did :-) "Some of them can be built as libraries. " They all look pretty hard to put in a lib , the freeze / mutability could be a lib but its nice for the system to know mutability . Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
