[go-nuts] Any pkg/debug/dwarf people around?

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

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.
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

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