[julia-users] Understanding immutables

[Cedric St-Jean]

There's an issue  on Github 
to add GC support for stack-allocated objects, and that makes no sense to 
me! Could someone please help me out? In my mind, stack-allocated objects = 
Int+Float+...+Immutable (in some circumstances). I thought that with 
Immutables, if I have

immutable ImagePos
   img::Image
   x::Int
   y::Int
end

function blah(img)
   a = ImagePos(img, 10, 20)
   foo(a)
   l = Any[40, a]
end

then `a` is stack-allocated. The foo(a) call may either copy `a` further, 
or just pass on a stack pointer to the existing `a`, depending on compiler 
details. Any stack-allocated object gets automatically wiped as the stack 
unwinds, hence does not need GC'ing.

Then on the `l` line, because it's an Any array, the ImagePos needs to be 
copied, boxed and heap-allocated. So that one needs GC.

What did I miss?

Cédric

Re: [julia-users] Understanding immutables

[Yichao Yu]

On Sun, Feb 7, 2016 at 9:39 AM, Cedric St-Jean  wrote:
> There's an issue on Github to add GC support for stack-allocated objects,
> and that makes no sense to me! Could someone please help me out? In my mind,
> stack-allocated objects = Int+Float+...+Immutable (in some circumstances). I
> thought that with Immutables, if I have

by `Int + Float + ...` I think you mean bitstype.

>
> immutable ImagePos
>img::Image
>x::Int
>y::Int
> end
>
> function blah(img)
>a = ImagePos(img, 10, 20)
>foo(a)
>l = Any[40, a]
> end
>
> then `a` is stack-allocated. The foo(a) call may either copy `a` further, or
> just pass on a stack pointer to the existing `a`, depending on compiler

Right

> details. Any stack-allocated object gets automatically wiped as the stack
> unwinds, hence does not need GC'ing.

s/GC/root/ might be a better word.

>
> Then on the `l` line, because it's an Any array, the ImagePos needs to be
> copied, boxed and heap-allocated. So that one needs GC.

I'm not really sure what you mean by `needs GC` here. What will happen
is that the element of a `Any` array will be heap(GC) allocated
(boxed) and so is the Array l itself. Therefore, `l` wiill be GC
rooted and elements in the `l` array are reachable by the GC from the
array `l`.

>
> What did I miss?
>
> Cédric

Re: [julia-users] Understanding immutables

[Cedric St-Jean]

On Sun, Feb 7, 2016 at 9:54 AM, Yichao Yu  wrote:

> On Sun, Feb 7, 2016 at 9:39 AM, Cedric St-Jean 
> wrote:
> > There's an issue on Github to add GC support for stack-allocated objects,
> > and that makes no sense to me! Could someone please help me out? In my
> mind,
> > stack-allocated objects = Int+Float+...+Immutable (in some
> circumstances). I
> > thought that with Immutables, if I have
>
> by `Int + Float + ...` I think you mean bitstype.
>

Yes.


>
> > details. Any stack-allocated object gets automatically wiped as the stack
> > unwinds, hence does not need GC'ing.
>
> s/GC/root/ might be a better word.
>

Agreed.


>
> >
> > Then on the `l` line, because it's an Any array, the ImagePos needs to be
> > copied, boxed and heap-allocated. So that one needs GC.
>
> I'm not really sure what you mean by `needs GC` here. What will happen
> is that the element of a `Any` array will be heap(GC) allocated
> (boxed) and so is the Array l itself. Therefore, `l` wiill be GC
> rooted and elements in the `l` array are reachable by the GC from the
> array `l`.
>

Yes, that's what I meant.

Could you please explain what the Github issue is about?


> >
> > What did I miss?
> >
> > Cédric
>

Re: [julia-users] Understanding immutables

[Tim Holy]

I'm not certain this is correct, but here's my understanding: `a = 
ImagePos(img, 10, 20)` absolutely must protect `img` from being GCed in code 
like this:

function foo()
img = rand(5,5)
return ImagePos(img, 10, 20)
end

But currently objects on the heap do not seem to protect stack-allocated 
objects from being GCed. So, the current choice is stack-allocate all(?) 
immutables that are non-bitstypes, just to make sure we adequately protect 
objects from being GCed. IICU, the new PR adds the ability to support 
protection from heap-allocated objects, which means that it will no longer be 
necessary to stack-allocate non-bitstypes immutables.

Best,
--Tim

On Sunday, February 07, 2016 06:39:51 AM Cedric St-Jean wrote:
> There's an issue  on Github
> to add GC support for stack-allocated objects, and that makes no sense to
> me! Could someone please help me out? In my mind, stack-allocated objects =
> Int+Float+...+Immutable (in some circumstances). I thought that with
> Immutables, if I have
> 
> immutable ImagePos
>img::Image
>x::Int
>y::Int
> end
> 
> function blah(img)
>a = ImagePos(img, 10, 20)
>foo(a)
>l = Any[40, a]
> end
> 
> then `a` is stack-allocated. The foo(a) call may either copy `a` further,
> or just pass on a stack pointer to the existing `a`, depending on compiler
> details. Any stack-allocated object gets automatically wiped as the stack
> unwinds, hence does not need GC'ing.
> 
> Then on the `l` line, because it's an Any array, the ImagePos needs to be
> copied, boxed and heap-allocated. So that one needs GC.
> 
> What did I miss?
> 
> Cédric

Re: [julia-users] Understanding immutables

[Tim Holy]

heap <--> stack (oops)

On Sunday, February 07, 2016 06:39:51 AM Cedric St-Jean wrote:
> There's an issue  on Github
> to add GC support for stack-allocated objects, and that makes no sense to
> me! Could someone please help me out? In my mind, stack-allocated objects =
> Int+Float+...+Immutable (in some circumstances). I thought that with
> Immutables, if I have
> 
> immutable ImagePos
>img::Image
>x::Int
>y::Int
> end
> 
> function blah(img)
>a = ImagePos(img, 10, 20)
>foo(a)
>l = Any[40, a]
> end
> 
> then `a` is stack-allocated. The foo(a) call may either copy `a` further,
> or just pass on a stack pointer to the existing `a`, depending on compiler
> details. Any stack-allocated object gets automatically wiped as the stack
> unwinds, hence does not need GC'ing.
> 
> Then on the `l` line, because it's an Any array, the ImagePos needs to be
> copied, boxed and heap-allocated. So that one needs GC.
> 
> What did I miss?
> 
> Cédric

Re: [julia-users] Understanding immutables

[Yichao Yu]

On Sun, Feb 7, 2016 at 10:19 AM, Cedric St-Jean  wrote:
>
>
> On Sun, Feb 7, 2016 at 9:54 AM, Yichao Yu  wrote:
>>
>> On Sun, Feb 7, 2016 at 9:39 AM, Cedric St-Jean 
>> wrote:
>> > There's an issue on Github to add GC support for stack-allocated
>> > objects,
>> > and that makes no sense to me! Could someone please help me out? In my
>> > mind,
>> > stack-allocated objects = Int+Float+...+Immutable (in some
>> > circumstances). I
>> > thought that with Immutables, if I have
>>
>> by `Int + Float + ...` I think you mean bitstype.
>
>
> Yes.
>
>>
>>
>> > details. Any stack-allocated object gets automatically wiped as the
>> > stack
>> > unwinds, hence does not need GC'ing.
>>
>> s/GC/root/ might be a better word.
>
>
> Agreed.
>
>>
>>
>> >
>> > Then on the `l` line, because it's an Any array, the ImagePos needs to
>> > be
>> > copied, boxed and heap-allocated. So that one needs GC.
>>
>> I'm not really sure what you mean by `needs GC` here. What will happen
>> is that the element of a `Any` array will be heap(GC) allocated
>> (boxed) and so is the Array l itself. Therefore, `l` wiill be GC
>> rooted and elements in the `l` array are reachable by the GC from the
>> array `l`.
>
>
> Yes, that's what I meant.
>
> Could you please explain what the Github issue is about?

Ahh, I didn't realize that `Image` is `!isbits`

The issue is that the current format of our GC frame can only handle
array of pointers so in order to root an object (and therefore objects
that are referenced by it), it has to be boxed.

>
>>
>> >
>> > What did I miss?
>> >
>> > Cédric
>
>

Re: [julia-users] Understanding immutables

[Cedric St-Jean]

Ahh, that makes sense, thank you for your answers Tim and Yichao!

On Sun, Feb 7, 2016 at 11:27 AM, Yichao Yu  wrote:

> On Sun, Feb 7, 2016 at 10:19 AM, Cedric St-Jean 
> wrote:
> >
> >
> > On Sun, Feb 7, 2016 at 9:54 AM, Yichao Yu  wrote:
> >>
> >> On Sun, Feb 7, 2016 at 9:39 AM, Cedric St-Jean  >
> >> wrote:
> >> > There's an issue on Github to add GC support for stack-allocated
> >> > objects,
> >> > and that makes no sense to me! Could someone please help me out? In my
> >> > mind,
> >> > stack-allocated objects = Int+Float+...+Immutable (in some
> >> > circumstances). I
> >> > thought that with Immutables, if I have
> >>
> >> by `Int + Float + ...` I think you mean bitstype.
> >
> >
> > Yes.
> >
> >>
> >>
> >> > details. Any stack-allocated object gets automatically wiped as the
> >> > stack
> >> > unwinds, hence does not need GC'ing.
> >>
> >> s/GC/root/ might be a better word.
> >
> >
> > Agreed.
> >
> >>
> >>
> >> >
> >> > Then on the `l` line, because it's an Any array, the ImagePos needs to
> >> > be
> >> > copied, boxed and heap-allocated. So that one needs GC.
> >>
> >> I'm not really sure what you mean by `needs GC` here. What will happen
> >> is that the element of a `Any` array will be heap(GC) allocated
> >> (boxed) and so is the Array l itself. Therefore, `l` wiill be GC
> >> rooted and elements in the `l` array are reachable by the GC from the
> >> array `l`.
> >
> >
> > Yes, that's what I meant.
> >
> > Could you please explain what the Github issue is about?
>
> Ahh, I didn't realize that `Image` is `!isbits`
>
> The issue is that the current format of our GC frame can only handle
> array of pointers so in order to root an object (and therefore objects
> that are referenced by it), it has to be boxed.
>
> >
> >>
> >> >
> >> > What did I miss?
> >> >
> >> > Cédric
> >
> >
>