Im ok on regions , personally i think there must be more research on GCs and regions. Though it may be obious since regions are just glorified stacks and i presume the stack scan code can be used on regions .
Not really keen on automated reference counting on heaps ..unless they are single threaded , having to do a LOCK CMPXCHG on each reference is terribly expensive . If i want to do it , it will be to track system resources and to take things away from the GC but i can do that manually ( and manual allocation via reusable objects is preffered over ref counting). Speaking of which while i think a language should make things safer and faster ,but it does not need to come by reducing developer skill ( though framework and dev kits can and should do this). Many developers in the GC world who did not come from C lack the memory management skills to reduce the GC work and size .There is an important parralel with aviation here where greater automation is leading to a lower level of skills which has caused crashes when presented with unusual conditions which the automated systems dont cope with . The idea that regions allow the detection and removal of GCs is great ... A scoped region is basically a stack. So it comes to reason that many regions just degenerate to stacks but with the proviso that pointers can access the stack outside the current scope and the unwinding is the whole stack ..So if you can manage stack overflows just treat them as named stacks and copy all the stack logic. There may be a point though which is what David may be implying that the analysis pushes everything into stack or GC , with a very small amount of objects in region . eg the analysis is important but you may find that after analysis it is rare that you have objects in regions ( or they are so few you may as well put them in the GC) "I'm looking for examples where regions help but CLR-like stack-based value-types don't. " recusrsion with Out of stack can be a issue.. regions allow better management of stack eg you can have a lower default stack size, You cant really implement segmented stacks efficiently ( without a very good compiler) but i see less issues with segmented regions. ( no calls or contexts which are split across 2 segments ). Which means that even though you may find ideally that a program would be say 40% stack , 5% region , 55% GC and you could dispense with regions , it may need a default stack size that is too large and you are better of with say 20 % stack m 25% region for lower stack sizes. Rust tried to go with segmented stacks but its too slow. Ben On Sat, Aug 3, 2013 at 2:19 AM, Jonathan S. Shapiro <[email protected]>wrote: > On Fri, Aug 2, 2013 at 11:12 AM, David Jeske <[email protected]> wrote: > >> On Fri, Aug 2, 2013 at 10:55 AM, Jonathan S. Shapiro <[email protected]>wrote: >> >>> Because it never escapes, that temporary could be stack allocated. >>> Region analysis can easily detect this, and allocating the temporary in >>> that way reduces GC pressure. >>> >> >> I'm looking for examples where regions help but CLR-like stack-based >> value-types don't. >> > > But yes, an implementation using your approach could eliminate the second > of the two allocations in the majority of cases. The catch is that doing so > would preclude use of regions for cleaning up the temporary. > > >> >>
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
