FAQ
Hello,

I want to do to two improvements to cmd/trace in this release cycle.

1. Currently there is a global variable used to assign sequence
numbers to all events. There sequence numbers allow to detect
inconsistent traces (when rdtsc is broken). Synchronization on this
variable causes up to 60x slowdown (measured on a 48-core machine). I
want to (1) emit sequence numbers only for events that participate in
causal relations (e.g. goroutine creation and goroutine start), then
make these sequence numbers per-goroutine or per-processor. This is
enough to assess trace validity.

2. Embed file:line info right into trace file. This will make trace
files self-contained and simplify analysis of traces collected from
live servers (when you don't know the exact binary, or trace collected
some time ago and now the binary is lost). On implementation level I
want to emit dictionary of file and function names, and then for each
involved PC refer to (file id, func id, line). The dictionary building
is done during trace finalization, in a separate goroutine, outside of
stop-the-world so should not be a performance issue. Cmd/trace will
then accept only trace file (if supplied with two args, the first one
is ignored for compatibility).

Is there any interest in these improvements in this release cycle?

--
Dmitry Vyukov, Software Engineer, Google Germany GmbH, Dienerstraße
12, 80331, München
Hamburg, HRB 86891 | Sitz der Gesellschaft: Hamburg | Geschäftsführer:
Graham Law, Christine Elizabeth Flores

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Sameer at Sep 23, 2015 at 12:31 pm
    Sounds good to me.
    On Wed, Sep 23, 2015, 5:18 AM Dmitry Vyukov wrote:

    Hello,

    I want to do to two improvements to cmd/trace in this release cycle.

    1. Currently there is a global variable used to assign sequence
    numbers to all events. There sequence numbers allow to detect
    inconsistent traces (when rdtsc is broken). Synchronization on this
    variable causes up to 60x slowdown (measured on a 48-core machine). I
    want to (1) emit sequence numbers only for events that participate in
    causal relations (e.g. goroutine creation and goroutine start), then
    make these sequence numbers per-goroutine or per-processor. This is
    enough to assess trace validity.

    2. Embed file:line info right into trace file. This will make trace
    files self-contained and simplify analysis of traces collected from
    live servers (when you don't know the exact binary, or trace collected
    some time ago and now the binary is lost). On implementation level I
    want to emit dictionary of file and function names, and then for each
    involved PC refer to (file id, func id, line). The dictionary building
    is done during trace finalization, in a separate goroutine, outside of
    stop-the-world so should not be a performance issue. Cmd/trace will
    then accept only trace file (if supplied with two args, the first one
    is ignored for compatibility).

    Is there any interest in these improvements in this release cycle?

    --
    Dmitry Vyukov, Software Engineer, Google Germany GmbH, Dienerstraße
    12, 80331, München
    Hamburg, HRB 86891 | Sitz der Gesellschaft: Hamburg | Geschäftsführer:
    Graham Law, Christine Elizabeth Flores
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Hyang-Ah Hana Kim at Sep 23, 2015 at 3:20 pm
    SGTM.

    On Wed, Sep 23, 2015 at 6:23 AM, sameer via golang-dev wrote:

    Sounds good to me.
    On Wed, Sep 23, 2015, 5:18 AM Dmitry Vyukov wrote:

    Hello,

    I want to do to two improvements to cmd/trace in this release cycle.

    1. Currently there is a global variable used to assign sequence
    numbers to all events. There sequence numbers allow to detect
    inconsistent traces (when rdtsc is broken). Synchronization on this
    variable causes up to 60x slowdown (measured on a 48-core machine). I
    want to (1) emit sequence numbers only for events that participate in
    causal relations (e.g. goroutine creation and goroutine start), then
    make these sequence numbers per-goroutine or per-processor. This is
    enough to assess trace validity.

    2. Embed file:line info right into trace file. This will make trace
    files self-contained and simplify analysis of traces collected from
    live servers (when you don't know the exact binary, or trace collected
    some time ago and now the binary is lost). On implementation level I
    want to emit dictionary of file and function names, and then for each
    involved PC refer to (file id, func id, line). The dictionary building
    is done during trace finalization, in a separate goroutine, outside of
    stop-the-world so should not be a performance issue. Cmd/trace will
    then accept only trace file (if supplied with two args, the first one
    is ignored for compatibility).

    Is there any interest in these improvements in this release cycle?

    --
    Dmitry Vyukov, Software Engineer, Google Germany GmbH, Dienerstraße
    12, 80331, München
    Hamburg, HRB 86891 | Sitz der Gesellschaft: Hamburg | Geschäftsführer:
    Graham Law, Christine Elizabeth Flores
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.


    --
    __

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Shane Hansen at Sep 28, 2015 at 5:41 pm
    I'm interested in that. If I understand you correctly I could take trace
    events off of a server and later analyze them (in the correct source tree)
    without needing to have a copy of the binary artifact?
    On Wed, Sep 23, 2015 at 9:20 AM, Hyang-Ah Hana Kim wrote:

    SGTM.


    On Wed, Sep 23, 2015 at 6:23 AM, sameer via golang-dev <
    golang-dev@googlegroups.com> wrote:
    Sounds good to me.
    On Wed, Sep 23, 2015, 5:18 AM Dmitry Vyukov wrote:

    Hello,

    I want to do to two improvements to cmd/trace in this release cycle.

    1. Currently there is a global variable used to assign sequence
    numbers to all events. There sequence numbers allow to detect
    inconsistent traces (when rdtsc is broken). Synchronization on this
    variable causes up to 60x slowdown (measured on a 48-core machine). I
    want to (1) emit sequence numbers only for events that participate in
    causal relations (e.g. goroutine creation and goroutine start), then
    make these sequence numbers per-goroutine or per-processor. This is
    enough to assess trace validity.

    2. Embed file:line info right into trace file. This will make trace
    files self-contained and simplify analysis of traces collected from
    live servers (when you don't know the exact binary, or trace collected
    some time ago and now the binary is lost). On implementation level I
    want to emit dictionary of file and function names, and then for each
    involved PC refer to (file id, func id, line). The dictionary building
    is done during trace finalization, in a separate goroutine, outside of
    stop-the-world so should not be a performance issue. Cmd/trace will
    then accept only trace file (if supplied with two args, the first one
    is ignored for compatibility).

    Is there any interest in these improvements in this release cycle?

    --
    Dmitry Vyukov, Software Engineer, Google Germany GmbH, Dienerstraße
    12, 80331, München
    Hamburg, HRB 86891 | Sitz der Gesellschaft: Hamburg | Geschäftsführer:
    Graham Law, Christine Elizabeth Flores
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.


    --
    __

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dmitry Vyukov at Sep 28, 2015 at 5:44 pm

    On Mon, Sep 28, 2015 at 7:40 PM, Shane Hansen wrote:
    I'm interested in that. If I understand you correctly I could take trace
    events off of a server and later analyze them (in the correct source tree)
    without needing to have a copy of the binary artifact?
    Yes, that is correct.
    Even source files won't be required, as cmd/trace just outputs
    function names and file:line info (of course, if you want to manually
    match these lines onto source, then you need correct sources, but I
    suspect in most cases it will be possible to figure out what happens
    even without matching sources).
    On Wed, Sep 23, 2015 at 9:20 AM, Hyang-Ah Hana Kim wrote:

    SGTM.


    On Wed, Sep 23, 2015 at 6:23 AM, sameer via golang-dev
    wrote:
    Sounds good to me.

    On Wed, Sep 23, 2015, 5:18 AM Dmitry Vyukov wrote:

    Hello,

    I want to do to two improvements to cmd/trace in this release cycle.

    1. Currently there is a global variable used to assign sequence
    numbers to all events. There sequence numbers allow to detect
    inconsistent traces (when rdtsc is broken). Synchronization on this
    variable causes up to 60x slowdown (measured on a 48-core machine). I
    want to (1) emit sequence numbers only for events that participate in
    causal relations (e.g. goroutine creation and goroutine start), then
    make these sequence numbers per-goroutine or per-processor. This is
    enough to assess trace validity.

    2. Embed file:line info right into trace file. This will make trace
    files self-contained and simplify analysis of traces collected from
    live servers (when you don't know the exact binary, or trace collected
    some time ago and now the binary is lost). On implementation level I
    want to emit dictionary of file and function names, and then for each
    involved PC refer to (file id, func id, line). The dictionary building
    is done during trace finalization, in a separate goroutine, outside of
    stop-the-world so should not be a performance issue. Cmd/trace will
    then accept only trace file (if supplied with two args, the first one
    is ignored for compatibility).

    Is there any interest in these improvements in this release cycle?

    --
    Dmitry Vyukov, Software Engineer, Google Germany GmbH, Dienerstraße
    12, 80331, München
    Hamburg, HRB 86891 | Sitz der Gesellschaft: Hamburg | Geschäftsführer:
    Graham Law, Christine Elizabeth Flores
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.



    --
    __

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Hyang-Ah Hana Kim at Mar 18, 2016 at 7:00 pm

    On Wednesday, September 23, 2015 at 5:18:29 AM UTC-4, Dmitry Vyukov wrote:
    Hello,

    I want to do to two improvements to cmd/trace in this release cycle.

    1. Currently there is a global variable used to assign sequence
    numbers to all events. There sequence numbers allow to detect
    inconsistent traces (when rdtsc is broken). Synchronization on this
    variable causes up to 60x slowdown (measured on a 48-core machine). I
    want to (1) emit sequence numbers only for events that participate in
    causal relations (e.g. goroutine creation and goroutine start), then
    make these sequence numbers per-goroutine or per-processor. This is
    enough to assess trace validity.

    2. Embed file:line info right into trace file. This will make trace
    files self-contained and simplify analysis of traces collected from
    live servers (when you don't know the exact binary, or trace collected
    some time ago and now the binary is lost). On implementation level I
    want to emit dictionary of file and function names, and then for each
    involved PC refer to (file id, func id, line). The dictionary building
    is done during trace finalization, in a separate goroutine, outside of
    stop-the-world so should not be a performance issue. Cmd/trace will
    then accept only trace file (if supplied with two args, the first one
    is ignored for compatibility).

    Is there any interest in these improvements in this release cycle?
    I want these features to be added in 1.7. I have a partial cl for 2),
    Dmitry has a partial cl for 1).

    Dmitry, since you are already looking into the runtime this week, are you
    willing to revisit your cl?



    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Russ Cox at Mar 18, 2016 at 7:11 pm
    I was on leave when this thread started, but these sound great for Go 1.7
    if we can still get them done in time (April 30).

    Thanks.
    Russ
    On Fri, Mar 18, 2016 at 3:00 PM Hyang-Ah Hana Kim wrote:


    On Wednesday, September 23, 2015 at 5:18:29 AM UTC-4, Dmitry Vyukov wrote:

    Hello,

    I want to do to two improvements to cmd/trace in this release cycle.

    1. Currently there is a global variable used to assign sequence
    numbers to all events. There sequence numbers allow to detect
    inconsistent traces (when rdtsc is broken). Synchronization on this
    variable causes up to 60x slowdown (measured on a 48-core machine). I
    want to (1) emit sequence numbers only for events that participate in
    causal relations (e.g. goroutine creation and goroutine start), then
    make these sequence numbers per-goroutine or per-processor. This is
    enough to assess trace validity.

    2. Embed file:line info right into trace file. This will make trace
    files self-contained and simplify analysis of traces collected from
    live servers (when you don't know the exact binary, or trace collected
    some time ago and now the binary is lost). On implementation level I
    want to emit dictionary of file and function names, and then for each
    involved PC refer to (file id, func id, line). The dictionary building
    is done during trace finalization, in a separate goroutine, outside of
    stop-the-world so should not be a performance issue. Cmd/trace will
    then accept only trace file (if supplied with two args, the first one
    is ignored for compatibility).

    Is there any interest in these improvements in this release cycle?
    I want these features to be added in 1.7. I have a partial cl for 2),
    Dmitry has a partial cl for 1).

    Dmitry, since you are already looking into the runtime this week, are you
    willing to revisit your cl?



    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedSep 23, '15 at 9:18a
activeMar 18, '16 at 7:11p
posts7
users5
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase