What is a gc frame?

490 views
Skip to first unread message

Uwe Fechner

unread,
Jul 24, 2016, 6:03:22 AM7/24/16
to julia-users
Hello,
in the issues on github I see a lot that refer to gc frames.

What is a gc frame? I know how garbage collection works in general,
but I don't understand the meaning of gc frames in the context of Julia.

Could someone explain:
- What they are used for?
- When they need to be created?
- If they have a lifetime, that needs to be managed.

Thank you very much!

Uwe

Yichao Yu

unread,
Jul 24, 2016, 7:56:05 AM7/24/16
to Julia Users
On Sun, Jul 24, 2016 at 6:03 AM, Uwe Fechner <uwe.fec...@gmail.com> wrote:
> Hello,
> in the issues on github I see a lot that refer to gc frames.
>
> What is a gc frame? I know how garbage collection works in general,
> but I don't understand the meaning of gc frames in the context of Julia.
>
> Could someone explain:
> - What they are used for?

Keep reference to local variables.

> - When they need to be created?

When there's local variables that are heap allocated.

> - If they have a lifetime, that needs to be managed.

They are stack allocated.

Uwe Fechner

unread,
Jul 24, 2016, 8:26:34 AM7/24/16
to julia-users
Thanks for your answer. Some more questions:
- is a gc frame just a pointer?
- if not, which information does it hold? In which file is the gc frame type/
  structure defined?
- is there exactly one gc frame for each local variable?
- why is it called "frame"? The term implies, that it is around something.
  Is this the case?

Yichao Yu

unread,
Jul 24, 2016, 8:39:18 AM7/24/16
to Julia Users
On Sun, Jul 24, 2016 at 8:26 AM, Uwe Fechner <uwe.fec...@gmail.com> wrote:
> Thanks for your answer. Some more questions:
> - is a gc frame just a pointer?

Parent point (it forms a linked list)
Length
GC Roots

> - if not, which information does it hold? In which file is the gc frame
> type/
> structure defined?

`jl_gcframe_t` in `julia.h`

> - is there exactly one gc frame for each local variable?

There's one GC frame for each ..... "scope" or whatever way you want
to group roots.
We emit one GC frame per function for JIT code.
Each root has it's own slot in the frame.
There might be duplicated roots in a frame and that's what the GC
frame optimizations are talking about.
See also the various `JL_GC_PUSH` macros in `julia.h` for how they are
created/used.

> - why is it called "frame"? The term implies, that it is around something.
> Is this the case?

Since it's an array of multiple pointers. The use of "frame" is
probably similar to that in stack frame.

P.S. Although you probably know already but just to be clear, one
don't need to worry about creating/accessing/maintaining GC frames
except for really low level stuff (GC and codegen). You are welcome to
learn more about julia internals of course.

Cedric St-Jean

unread,
Jul 24, 2016, 9:44:39 AM7/24/16
to julia-users
Thank you for the explanations. With that in mind, why is stack-allocating heap-object-containing immutables hard? Doesn't it boil down to inspecting the immutable type at compile-time to find the offset of the heap-allocated objects' pointers, and pushing those onto the GC frame?

Yichao Yu

unread,
Jul 24, 2016, 11:08:07 AM7/24/16
to Julia Users
On Sun, Jul 24, 2016 at 9:44 AM, Cedric St-Jean <cedric...@gmail.com> wrote:
> Thank you for the explanations. With that in mind, why is stack-allocating
> heap-object-containing immutables hard? Doesn't it boil down to inspecting
> the immutable type at compile-time to find the offset of the heap-allocated
> objects' pointers, and pushing those onto the GC frame?

Well, "boil down to" is not the right way to estimate how hard
something can be implemented. There's a lot of details one need to
consider to implement it and to make sure it doesn't cause regression.
A few important points one need to know are,

1. Memory allocations are **NOT** as expensive as one might think.
2. Making copies can be very expensive.
3. Reboxing is hard to avoid without escape analysis or ABI change.

Cedric St-Jean

unread,
Jul 24, 2016, 8:02:07 PM7/24/16
to julia-users
Yes, sorry, I'm sure the devil is in the details, otherwise it would have been done a long time ago...
Reply all
Reply to author
Forward
0 new messages