Some things that come to mind...
You can put reference types in a stack like region and pass around the
pointer..
eg
windowSetSize( )
var size = new Size() {...
var point = new Point() { ...
var window = new Window() { Size = size , Point = pint ...
CallMethodUpdateWindows( new List<Window>() {window})
{
// do something with size and point
} // window is out of scope and region will deallocate all
At no stage is the heap needed and window can be a reference type. And the
objects can live on a stack like data structure., You cant do this
without resorting to value types and unsafe ( to avoid autoboxing) on a
stack . Also value types being copied cant be large if you pass them
around , reference types in a region can be.
Also a region could be controlled and last a long time .. eg you may have
2 threads one allocating very slow and another doing lots of reading but
slowly allocating. In most shared nursery GC s allocations get mixed and
you will have many nursery collects ( scavanges) interfering with your
mainly reading thread ( eg cache flushes etc). WIth a region those
allocations can happen to a seperate heap and the threads runs along and
when it finsihes a long time later the whole region is just dropped.
Laslly even if the benefit of regions themselves is low the analysis which
pushes more types automatically onto the stack is a win .. since it makes
the GC heap smaller and uses the faster stack allocation scheme.
Shap ,
Wouldnt you just use a seperate stack like memory structure rather than the
actual stack ? You wouldnt want to increase the default stack size and
risk over flows ( unless very small) . What is the gain by putting it on
the stack ? Is the locality of data with variables worth it ?
On Mon, Aug 5, 2013 at 12:21 PM, Jonathan S. Shapiro <[email protected]>wrote:
> On Sun, Aug 4, 2013 at 6:24 PM, David Jeske <[email protected]> wrote:
>
>>
>> On Aug 4, 2013 2:50 PM, "Jonathan S. Shapiro" <[email protected]> wrote:
>> > Yes. This "one, maybe two" problem is an example of a region whose size
>> is not statically boundable. Such regions may indeed need GC, though it's
>> at least a very fast, generational-style GC that does not have to consider
>> pointers from tenured space to new space.
>>
>> ... What is the difference between this and young generation scavenge?
>> Seems the same to me.
>>
>
> One requires a scavenge. The other usually doesn't.
>
>
>> To me it seems we are discussing (a) statically sized regions... Which
>> are already handled well by the stack, and (b) dynamic regions which need
>> GC that are already handled well by young generation scavenge.
>>
>
> It's not that black and white, and while regions can go on the stack, you
> have to *do* the region analysis to learn which items can safely be stack
> allocated.
>
>
> shap
>
> _______________________________________________
> bitc-dev mailing list
> [email protected]
> http://www.coyotos.org/mailman/listinfo/bitc-dev
>
>
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
