Any way to identify a specific goroutine dynamically?

[xiangd...@gmail.com]

Hi all,

I wonder if there is any way to identify a goroutine, which runs a function I wish to analyze its behavior in details, at runtime?

say:

func wrapper() bool {

        go f()

        .....

}

I wish to add some monitoring code in runtime only for the goroutine running 'f', is it feasible?

Thanks a lot. 

[Dave Cheney]

If there were a way to identify that goroutine what would this enable
you to do? Said another way, what API would you like for identifying a
goroutine and how would you use its result?

> --
> 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.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/20ed27ff-2ca3-4f25-a59b-70127b779d6ao%40googlegroups.com.

[xiangd...@gmail.com]

Thanks Dave.

At first I'd like to monitor the behavior of that goroutine in GC, say what prevents it being suspended quickly, the detailed progress of how its stack being scanned, etc.,

then demands to further details might be created.  

On Friday, July 10, 2020 at 11:26:12 AM UTC+8, Dave Cheney wrote:

If there were a way to identify that goroutine what would this enable
you to do? Said another way, what API would you like for identifying a
goroutine and how would you use its result?

On Fri, 10 Jul 2020 at 13:21, xiang...@gmail.com
<xiang...@gmail.com> wrote:
>
> Hi all,
>
> I wonder if there is any way to identify a goroutine, which runs a function I wish to analyze its behavior in details, at runtime?
>
> say:
>
> func wrapper() bool {
>         go f()
>         .....
> }
>
> I wish to add some monitoring code in runtime only for the goroutine running 'f', is it feasible?
>
> Thanks a lot.
>
> --
> 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 golan...@googlegroups.com.

[Dave Cheney]

Some of that information is available via the trace package. 

On 10 Jul 2020, at 13:45, "xiangd...@gmail.com" <xiangd...@gmail.com> wrote:



To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/c5ae41b4-2d06-48f7-84a9-a57408bc6a28o%40googlegroups.com.

[Liam]

This issue links a patch to the runtime which enables goroutine names:

  https://github.com/golang/go/issues/35178

And another solution via pprof:

  https://blog.jetbrains.com/go/2020/03/03/how-to-find-goroutines-during-debugging/

[xiangd...@gmail.com]

Yes, that target goroutine was what the trace tool identified as a potential bottleneck, and with the help of some debugging output seems that its background marker tried multiple thousands of times to suspend it, frankly speaking I'm not sure whether it's expected behavior or not w.r.t its implementation but think it might be worthy further investigation, would share more details if any progress is made, thanks a lot.

On Friday, July 10, 2020 at 12:11:02 PM UTC+8, Dave Cheney wrote:

Some of that information is available via the trace package. 

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/c5ae41b4-2d06-48f7-84a9-a57408bc6a28o%40googlegroups.com.

[xiangd...@gmail.com]

Hi Liam,

Thanks for the pointers, I'm taking a look.

[Dave Cheney]

This sounds like it could be a bug. Would you be able to raise an
issue https://github.com/golang/go/issues/new

> To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/e4adbe3d-eae8-4ded-813c-5c8f840bf6d5o%40googlegroups.com.

[xiangd...@gmail.com]

Looks like it's a live-lock problem when a goroutine running time-consuming nonpreemptible functions is under suspending by its bg worker at the same time, I tried a few changes to reduce the cost, looks like one of them is promising, details and data are posted in https://github.com/golang/go/issues/40229, thanks.

Furthermore, functions like bulkBarrierPreWriteSrcOnly rely on heap bits to identifier pointer fields, perhaps we can utilize the known layout of some built-in types, say if the element type is 'slice', a specialized version outperforms a little, but not sure if it's worth the complexity, and the layout of slice might be changed later.

general version:

h := heapBitsForAddr(dst)

for i := uintptr(0); i < size; i += sys.PtrSize {

if h.isPointer() {

srcx := (*uintptr)(unsafe.Pointer(src + i))

if !buf.putFast(0, *srcx) {

wbBufFlush(nil, 0)

}

}

h = h.next()

}

specialized version for 'slice of slice':

for i := uintptr(0); i < size; i += sys.PtrSize * 3 {

srcx := (*uintptr)(unsafe.Pointer(src + i))

if !buf.putFast(0, *srcx) {

wbBufFlush(nil, 0)

}

}

On Friday, July 10, 2020 at 5:18:28 PM UTC+8, Dave Cheney wrote:

This sounds like it could be a bug. Would you be able to raise an
issue https://github.com/golang/go/issues/new

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/e4adbe3d-eae8-4ded-813c-5c8f840bf6d5o%40googlegroups.com.