FAQ
I've implemented file tables to decode the AttrDeclFile field. Is there anybody around who knows this code? Also I've been looking at making the package thread safe, well the Type system anyway and new FileTable stuff anyway.

Godfrey van der Linden


--
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/groups/opt_out.

Search Discussions

  • Ian Lance Taylor at Apr 18, 2013 at 4:58 am

    On Wed, Apr 17, 2013 at 9:13 PM, Godfrey van der Linden wrote:
    I've implemented file tables to decode the AttrDeclFile field. Is there anybody around who knows this code? Also I've been looking at making the package thread safe, well the Type system anyway and new FileTable stuff anyway.
    I more or less know the debug/dwarf code if you want to ask a
    question. If you want to send in a code review, just use hg mail and
    it will be sent to golang-dev.

    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/groups/opt_out.
  • Godfrey van der Linden at Apr 18, 2013 at 10:27 pm

    On Apr 17, 2013, at 21:58 , Ian Lance Taylor wrote:
    On Wed, Apr 17, 2013 at 9:13 PM, Godfrey van der Linden wrote:
    I've implemented file tables to decode the AttrDeclFile field. Is there anybody around who knows this code? Also I've been looking at making the package thread safe, well the Type system anyway and new FileTable stuff anyway.
    I more or less know the debug/dwarf code if you want to ask a
    question. If you want to send in a code review, just use hg mail and
    it will be sent to golang-dev.

    Ian
    I have a AttrDeclFile patch just about ready to go, and a couple of other small patches for concurrency support. Is it better to submit a couple of small patches with a narrow purpose or should I just submit a big patch with all of the work I have been doing to the package?

    Also it seems to me that the (d *Data) Type cache is broken under concurrency. Using the go share communications not memory idea, I propose that to keep a typeCache in a Reader created for a CompileUnit. The Types are local to the compile unit in any case.

    The API I propose is :-

    // Type decodes the entry at offset within the dwarf.info section and returns a
    // Type. It must be called in a single threaded context with respect to the
    // dwarf.Reader object. Create a Reader for a CompileUnit and parallelise on
    // each CompileUnit in an executable.
    func (r *Reader) Type(off Offset) (Type, error)

    The origin API is :-

    // Type decodes the entry at offset within the dwarf.info section and returns a
    // Type. It must be called in a single threaded context with respect to the
    // underlying dwarf.Data object.
    func (d *Data) Type(off Offset) (Type, error)


    Am I on the right track?

    Godfrey

    --
    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/groups/opt_out.
  • Ian Lance Taylor at Apr 18, 2013 at 10:39 pm

    On Thu, Apr 18, 2013 at 3:21 PM, Godfrey van der Linden wrote:
    I have a AttrDeclFile patch just about ready to go, and a couple of other small patches for concurrency support. Is it better to submit a couple of small patches with a narrow purpose or should I just submit a big patch with all of the work I have been doing to the package?
    Small patches are better.
    Also it seems to me that the (d *Data) Type cache is broken under concurrency.
    In general the standard types do not support concurrent access unless
    they explicitly say that they do. The idea is to not force every user
    to pay the price of locking. Instead, users can use their own locks
    or can only access the value from a single goroutine.
    Using the go share communications not memory idea, I propose that to keep a typeCache in a Reader created for a CompileUnit. The Types are local to the compile unit in any case.

    The API I propose is :-

    // Type decodes the entry at offset within the dwarf.info section and returns a
    // Type. It must be called in a single threaded context with respect to the
    // dwarf.Reader object. Create a Reader for a CompileUnit and parallelise on
    // each CompileUnit in an executable.
    func (r *Reader) Type(off Offset) (Type, error)

    The origin API is :-

    // Type decodes the entry at offset within the dwarf.info section and returns a
    // Type. It must be called in a single threaded context with respect to the
    // underlying dwarf.Data object.
    func (d *Data) Type(off Offset) (Type, error)


    Am I on the right track?
    The Go 1 compatibility guarantee means that we can not remove the
    existing API. It's OK to add a new one. But I'm not sure I
    understand what the advantage of your proposal is. Given that we
    expect the caller to handle concurrency anyhow, how is your proposal
    better?

    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/groups/opt_out.
  • Godfrey van der Linden at Apr 18, 2013 at 11:28 pm

    On Apr 18, 2013, at 15:39 , Ian Lance Taylor wrote:
    On Thu, Apr 18, 2013 at 3:21 PM, Godfrey van der Linden wrote:
    Using the go share communications not memory idea, I propose that to keep a typeCache in a Reader created for a CompileUnit. The Types are local to the compile unit in any case.

    The API I propose is :-

    // Type decodes the entry at offset within the dwarf.info section and returns a
    // Type. It must be called in a single threaded context with respect to the
    // dwarf.Reader object. Create a Reader for a CompileUnit and parallelise on
    // each CompileUnit in an executable.
    func (r *Reader) Type(off Offset) (Type, error)

    The origin API is :-

    // Type decodes the entry at offset within the dwarf.info section and returns a
    // Type. It must be called in a single threaded context with respect to the
    // underlying dwarf.Data object.
    func (d *Data) Type(off Offset) (Type, error)


    Am I on the right track?
    The Go 1 compatibility guarantee means that we can not remove the
    existing API. It's OK to add a new one. But I'm not sure I
    understand what the advantage of your proposal is. Given that we
    expect the caller to handle concurrency anyhow, how is your proposal
    better?
    I didn't say it, but the new (r *Reader) Type API is in addition to the *Data function. They both build on a new internal routine that gets the cache passed in.

    A large dwarf executable is broken up into many independent CompileUnits(CU). I'd like to farm out the type analysis of a CU to a group of goroutines. Each go routine would use its own keep it's own type cache in a dwarf.Reader.

    The kernel I'm looking at has nearly 2000 compile units and my build servers have 28 logical processors on them. The kernel fits is in memory, so I can use every CPU, L1–3 cache's willing.

    Finally, I am not proposing locking as a solution, the new API is unlocked, but can exploit the independence of each CUs. Formally, the ownership of the CU's typeCache is handed off to each goroutine and is kept totally isolated.

    Godfrey

    --
    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/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedApr 18, '13 at 4:13a
activeApr 18, '13 at 11:28p
posts5
users2
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase