FAQ
I think there may be ways to hack the gccgo heap to use SOA memory layout
(structure of arrays) rather than AOS, even though the GC is conservative
rather than precise. I'm making a lot of likely incorrect assumptions, but
would something like this work? It is not clear from the language
specification, but goroutines must yield control to allow others to run,
right? Can I assume GC is only done once all threads have yielded, so we
can assume the registers do not contain important root pointers into the
heap? If all this is right, then would the following work?

- First, only objects on the heap would be changed. Objects on the stack
would work as they do now.
- Heap object field access needs to be done through static inline functions
(or macros or equiv).
- To insure all heap access is being done through the accessor functions,
I'd return modified pointers that point to unallocated space. Any place
the system does a direct read/write would cause a memory violation.
- Initially, the accessor functions would just add/subtract some random
constant to convert the invalid pointer to the real pointer and vise versa.
- Once the accessor functions are enforced and known to work, changing the
memory layout should be trivial, so long as it is transparently done by the
accessor functions
- Pointers to struct fields would simply return pointers to the actual
field, wherever it is in memory.

Where would be a good place to start to try and figure out how the gccgo
heap related code works?

Thanks,
Bill

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

Search Discussions

  • Ian Lance Taylor at Jan 28, 2015 at 4:03 pm

    On Tue, Jan 27, 2015 at 6:35 AM, 'Bill Cox' via golang-nuts wrote:

    I think there may be ways to hack the gccgo heap to use SOA memory layout
    (structure of arrays) rather than AOS, even though the GC is conservative
    rather than precise. I'm making a lot of likely incorrect assumptions, but
    would something like this work? It is not clear from the language
    specification, but goroutines must yield control to allow others to run,
    right?
    Correct in the current implementation, though not guaranteed by the
    language. And of course multiple goroutines may run simultaneously.

    Can I assume GC is only done once all threads have yielded, so we
    can assume the registers do not contain important root pointers into the
    heap?
    Yes.

    If all this is right, then would the following work?

    - First, only objects on the heap would be changed. Objects on the stack
    would work as they do now.
    - Heap object field access needs to be done through static inline functions
    (or macros or equiv).
    - To insure all heap access is being done through the accessor functions,
    I'd return modified pointers that point to unallocated space. Any place the
    system does a direct read/write would cause a memory violation.
    - Initially, the accessor functions would just add/subtract some random
    constant to convert the invalid pointer to the real pointer and vise versa.
    - Once the accessor functions are enforced and known to work, changing the
    memory layout should be trivial, so long as it is transparently done by the
    accessor functions
    - Pointers to struct fields would simply return pointers to the actual
    field, wherever it is in memory.
    This seems to assume that there is a clear distinction between stack
    and heap memory, which isn't really true in Go. Given a pointer,
    there is no clear way to decide whether it points into the stack or
    the heap. So I think that to make this work you would have to force
    all structs onto the heap. You could do that but there would be a
    significant performance penalty.

    Where would be a good place to start to try and figure out how the gccgo
    heap related code works?
    libgo/runtime/malloc.h.

    The heap is pretty much the same in gccgo and gc.

    Ian

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Bill Cox at Jan 29, 2015 at 1:43 am

    On Wed, Jan 28, 2015 at 8:03 AM, Ian Lance Taylor wrote:

    This seems to assume that there is a clear distinction between stack
    and heap memory, which isn't really true in Go. Given a pointer,
    there is no clear way to decide whether it points into the stack or
    the heap. So I think that to make this work you would have to force
    all structs onto the heap. You could do that but there would be a
    significant performance penalty.
    Thanks for all the tips! I would probably move all structs to the heap to
    start, but most structs have an affinity for one place or the other. For
    example, a simple struct like Point with 2 ints might as well be passed
    around by value. A more complex object with 1KiB of data is more likely to
    be inll the heap. I rarely allocate large structs on the stack. With
    struct data access going through an inline accessor function, it's not too
    ugly to have both types around.

    I read all the header files in libgo/runtime, and they make a lot of sense
    to me. Where would I look to find the code the gccgo compiler runs to
    generate code to access struct data?

    BTW, very impressive work, Ian. I guess you don't need to be told that :-)

    Thanks,
    Bill

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Lance Taylor at Jan 29, 2015 at 2:23 am

    On Wed, Jan 28, 2015 at 5:43 PM, Bill Cox wrote:
    I read all the header files in libgo/runtime, and they make a lot of sense
    to me. Where would I look to find the code the gccgo compiler runs to
    generate code to access struct data?
    go/expressions.cc. Look for Selector_expression and things it gets
    lowered to. As you will see, the '.' operator in Go is heavily
    overloaded. References to fields in structs lower down into
    Field_reference_expression's.

    Ian

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJan 27, '15 at 2:35p
activeJan 29, '15 at 2:23a
posts4
users2
websitegolang.org

2 users in discussion

Ian Lance Taylor: 2 posts Bill Cox: 2 posts

People

Translate

site design / logo © 2021 Grokbase