ivoanjo / gvl-tracing

Get a timeline view of Global VM Lock usage in your Ruby app
MIT License
115 stars 7 forks source link

OSX compatibility #4

Closed casperisfine closed 2 years ago

casperisfine commented 2 years ago

gettid() isn't available on OSX. But we can use the Ruby's thread_native.h to get an identifier.

ivoanjo commented 2 years ago

Thanks for this! One thing I spotted is that https://ui.perfetto.dev/ seems not too like the big tids we get on macOS. E.g. I just got this trace for example1.json: https://gist.github.com/ivoanjo/31e4699d6dc74dd3e9c042f910aa989b

and here's how it looks in perfetto (this example has 4 threads):

Screen Shot 2022-07-27 at 10 00 11

But... if I just search and replace on my text editor the big thread ids with smaller ids, it works lol:

Screen Shot 2022-07-27 at 10 02 09

I'll try to report it upstream, but in the meanwhile, any preference on how to work around this? I guess we could % or otherwise truncate bigger values, but it is a bit of a shame that it becomes a number with no connection to anything people see on their Ruby VM.

casperisfine commented 2 years ago

Hum, that's annoying indeed.

At some point I wanted to provide a small incremental thread_id in the hook arguments, it's especially important because two Ruby threads may have the same native thread id (threads can be re-used in some cases).

I'll make a PR and see if Koichi is open to it.

casperisfine commented 2 years ago

Upstream PR: https://github.com/ruby/ruby/pull/6189

casperisfine commented 2 years ago

Hum, I just though that short term this library could use a thread local variable and an atomic to generate that same serial identifier. Let me try.

casperisfine commented 2 years ago

I discussed the upstream PR with Koichi, it may or may not be acceptable, it depends on another things he's working on, so we'll know in a bit.

In the meantime I'll use a thread local to generate that same serial.

ivoanjo commented 2 years ago

Sounds reasonable. I'd still probably keep the task id for linux, since it seems like a more useful value than the not-visible-to-users serial. (?)

casperisfine commented 2 years ago

I'd still probably keep the task id for linux, since it seems like a more useful value than the not-visible-to-users serial. (?)

Up to you. I can do that if you prefer. I'd say the advantage of serial id is that it's incremental, so 0 is the main thread, 1 is the first thread you ever created etc etc.

But I can add some code to check if gettid() is present, just let me know.

ivoanjo commented 2 years ago

I'm happy with the current version. Can always re-add the thread id later. (Happy to hear feedback from the community here)

Thanks for the contribution! I'll make a release a bit later today :)