Precise garbage collection of stack roots

[Carl Shapiro]

Golang-dev,

There has been some interest in a change I recently uploaded regarding the precise collection of stack roots.

This document describes the general approach I will be following to implement support for precise stack roots in the garbage collector and compiler

https://docs.google.com/document/d/13v_u3UrN2pgUtPnH4y-qfmlXwEEryikFu0SQiwk35SA/pub

Replies with questions or comments are welcome.

Kind regards,

Carl

P.S. I sent this to another address last week, sorry if you are receiving this in duplicate

[Daniel Morsing]

> --
>

Great stuff. Just a question and a suggestion.

Atoms garbage collection scheme need the type of a pointer to work
best. How will you encode that in the bitmap?

The memory for arguments is allocated by the caller, but the types in
that memory will change depending on which function is called. It
might be a better idea to build the bitmap between the high end of the
callees local stack space and the low end of the argument memory past
the return address on the stack.

Regards,
Daniel Morsing

[Carl Shapiro]

On Thu, Feb 14, 2013 at 12:04 PM, Daniel Morsing <daniel....@gmail.com> wrote:

Atoms garbage collection scheme need the type of a pointer to work

best. How will you encode that in the bitmap?

For the purposes of eliminating false retention and relocation, knowing a value is a pointer is usually sufficient.  The type of the object pointed to is available elsewhere in the runtime but it would be preferable for that information to be encoded in the object as opposed to being encoded in the description of the pointer locations of a stack frame.

 

The memory for arguments is allocated by the caller, but the types in
that memory will change depending on which function is called. It
might be a better idea to build the bitmap between the high end of the
callees local stack space and the low end of the argument memory past
the return address on the stack.

Correct.  I misstated the region of interest.  In the change I uploaded, the frame is scanned as you describe, from the incoming arguments area downward.  The intent is to stop at the end of the locals area.  The extent of the locals area is not available but that will be corrected in a forthcoming change.

Thanks for catching this.  I will update my document.

[Robert Griesemer]

Thanks for the write-up. If gccgo shares the runtime and gc,
presumably there needs to also be some coordination between the gc
data structures representing stack frames and the ones used by gccgo.
- gri

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Ian Lance Taylor]

On Thu, Feb 14, 2013 at 8:54 PM, Robert Griesemer <g...@golang.org> wrote:
> Thanks for the write-up. If gccgo shares the runtime and gc,
> presumably there needs to also be some coordination between the gc
> data structures representing stack frames and the ones used by gccgo.

The gccgo runtime is based on the gc runtime. It is not identical.
Changes in the gc runtime are periodically merged into the gccgo
runtime, and I resolve the merge conflicts by hand.

It will never make sense to use the exact same data structures for the
gccgo stack frame, because the stack frame is fundamentally different.
gccgo will require a different approach, hopefully similar in general
but certainly different in specific details.

Ian

[⚛]

On Thursday, February 14, 2013 9:04:58 PM UTC+1, Daniel Morsing wrote:

On Wed, Feb 13, 2013 at 11:03 PM, Carl Shapiro <csha...@golang.org> wrote:
> Golang-dev,
>
> There has been some interest in a change I recently uploaded regarding the
> precise collection of stack roots.
>
> This document describes the general approach I will be following to
> implement support for precise stack roots in the garbage collector and
> compiler
>
> https://docs.google.com/document/d/13v_u3UrN2pgUtPnH4y-qfmlXwEEryikFu0SQiwk35SA/pub
>
> Replies with questions or comments are welcome.
>
> Kind regards,
>
> Carl
>
> P.S. I sent this to another address last week, sorry if you are receiving
> this in duplicate
>
> --
>

Great stuff. Just a question and a suggestion.

Atoms garbage collection scheme need the type of a pointer to work
best. How will you encode that in the bitmap?

This isn't a major issue. In my opinion, the initially hardest parts in precise GC of stack frames are in the compiler (structure of the stack frame of a function) and in determining the starting addresses of frames during a garbage collection.