Use trace instead of tracing

[patricoferris]

This switches the fuchsia format backend away from using tracing to trace.

I find myself frequently reaching for these tools when doing some light performance analysis. Unfortunately, the dependency cone is quite large because of tracing pulling in lots of Janestreet packages. tracehas a much smaller dependency cone. The transitive dependencies have gone from 129 to 51 (as reported by opam list --required-by=runtime_events_tools -s | wc -l)!

The downside is that the fuchsia backend to trace is a little confusing to use (as it is intended to trace your own program manually via the Trace module, not to be used directly to output a fuchsia trace). Maybe @c-cube can make sure I am holding it correctly :) (no worries if not!) ?

[c-cube]

This looks fine! The backend wasn't really meant to be used directly but it's fine, and you made sense of the API just fine :). I think you could just use Trace_subscriber.Subscriber.Callbacks callbacks but it's really a detail.

[c-cube]

you could direct use the Trace_fuchsia.Subscriber' callbacks here, too, without going through Trace.Event`.

[c-cube]

same here, with subscriber

[patricoferris]

Thanks @c-cube ! I had a quick look and I think I might keep it as is just to keep it consistent in which module we use to make the events? I had a look for something for an Instant but couldn't find anything in the Subscriber callback module. Do you reckon the Writer.Event module is stable enough to use like this?

[kayceesrk]

Thanks @patricoferris. I'm approving this based on @c-cube's review.

[c-cube]

Yes, it's fine to rely on it :)

[kayceesrk]

Let me know when it is ready to merge.

[patricoferris]

I think this should be good to go now @kayceesrk -- the codebase could use a dune fmt but that hasn't been run in a long time so perhaps a separate PR with just that would be an idea there (unless formatting is not a concern).

[tmcgilchrist]

Thanks @patricoferris minimising the dependencies makes sense.
Please remove ocaml_intrinsics then it looks good to go.

[tmcgilchrist]

I'm getting an exception using this @patricoferris @c-cube
Any ideas on what I should be looking for?

$ OCAMLRUNPARAM=b,s=8192k,o=40 olly trace infer-multicore-5-3.8192k.nopoll.trace "../infer/infer/bin/infer analyze --no-progress-bar --no-report --multicore -j 16"
Found 747 source files to analyze in /home/tsmc/openssl-1.0.2d/infer-out
olly: internal error, uncaught exception:
      Failure("fuchsia: buffer is too small (available: 24 bytes, needed: 32 bytes)")
      Raised by primitive operation at Runtime_events in file "runtime_events.ml" (inlined), lines 409-410, characters 0-76
      Called from Olly_common__Launch.collect_events in file "lib/olly_common/launch.ml", line 105, characters 4-56
      Called from Stdlib__Fun.protect in file "fun.ml", line 34, characters 8-15
      Re-raised at Stdlib__Fun.protect in file "fun.ml", line 39, characters 6-52
      Called from Stdlib__Fun.protect in file "fun.ml", line 34, characters 8-15
      Re-raised at Stdlib__Fun.protect in file "fun.ml", line 39, characters 6-52
      Called from Cmdliner_term.app.(fun) in file "cmdliner_term.ml", line 24, characters 19-24
      Called from Cmdliner_eval.run_parser in file "cmdliner_eval.ml", line 35, characters 37-44

(lldb) bt                                               
* thread #1, name = 'olly', stop reason = breakpoint 1.1
  * frame #0: 0x00005555556f651e olly`camlTrace_fuchsia__Buf_chain.assert_available_148 at buf.ml:16:54
    frame #1: 0x00005555556f6b1c olly`camlTrace_fuchsia__Buf_chain.with_buf_383 at buf_chain.ml:109:4           
    frame #2: 0x00005555557e36e8 olly`caml_start_program + 112                                                  
    frame #3: 0x00005555557bafc9 olly`caml_callback3_exn(closure=<unavailable>, arg1=<unavailable>, arg2=<unavai
lable>, arg3=<unavailable>) at callback.c:267:12
    frame #4: 0x00005555557b1c71 olly`ml_runtime_begin(domain_id=<unavailable>, callback_data=0x00007fffffffdc90
, timestamp=3712971133970224, phase=<unavailable>) at runtime_events_consumer.c:739:11                          
    frame #5: 0x00005555557b25d8 olly`caml_runtime_events_read_poll(cursor=0x0000555555a57860, callback_data=0x00007fffffffdc90, max_events=0, events_consumed=0x00007fffffffdc88) at runtime_events_consumer.c:561:18
    frame #6: 0x00005555557b2e79 olly`caml_ml_runtime_events_read_poll(wrapper=<unavailable>, callbacks_val=<una
vailable>, max_events_val=<unavailable>) at runtime_events_consumer.c:1317:9
    frame #7: 0x00005555557e360b olly`caml_c_call + 31
    frame #8: 0x000055555571f10d olly`camlOlly_common__Launch.collect_events_517 at runtime_events.ml:409
    frame #9: 0x000055555578023f olly`camlStdlib__Fun.protect_99 at fun.ml:34:8                                 
    frame #10: 0x000055555578023f olly`camlStdlib__Fun.protect_99 at fun.ml:34:8                                
    frame #11: 0x00005555557322f0 olly`camlCmdliner_term.anon_fn$5bcmdliner_term.ml$3a19$2c2$2d$2d145$5d_21570 at cmdliner_term.ml:24:19                                                                                        
    frame #12: 0x0000555555735cad olly`camlCmdliner_eval.run_parser_26674 at cmdliner_eval.ml:35:37                 frame #13: 0x0000555555736e11 olly`camlCmdliner_eval.eval_value_inner_27445 at cmdliner_eval.ml:203:14
    frame #14: 0x0000555555720243 olly`camlOlly_common__Cli.main_671 at cmdliner_eval.ml:258:2
    frame #15: 0x00005555556f558f olly`camlDune__exe__Olly.entry at olly.ml:6:2                                     frame #16: 0x00005555556f1a0b olly`caml_program + 1835                                                          frame #17: 0x00005555557e36e8 olly`caml_start_program + 112
    frame #18: 0x00005555557e3065 olly`caml_startup_common [inlined] caml_startup_common(pooling=<unavailable>, 
argv=0x00007fffffffdf28) at startup_nat.c:127:9                                                                 
    frame #19: 0x00005555557e2f80 olly`caml_startup_common(argv=0x00007fffffffdf28, pooling=<unavailable>) at st
artup_nat.c:86:7                                                                                                    frame #20: 0x00005555557e30df olly`caml_main [inlined] caml_startup_exn(argv=<unavailable>) at startup_nat.c
:134:10                                                 
    frame #21: 0x00005555557e30da olly`caml_main [inlined] caml_startup(argv=<unavailable>) at startup_nat.c:139
:15                                                                                                             
    frame #22: 0x00005555557e30da olly`caml_main(argv=<unavailable>) at startup_nat.c:146:3                     
    frame #23: 0x00005555556f11e0 olly`main(argc=<unavailable>, argv=<unavailable>) at main.c:37:3
    frame #24: 0x00007ffff7c2a1ca libc.so.6`__libc_start_call_main(main=(olly`main at main.c:31:1), argc=4, argv
=0x00007fffffffdf28) at libc_start_call_main.h:58:16                                                            
    frame #25: 0x00007ffff7c2a28b libc.so.6`__libc_start_main_impl(main=(olly`main at main.c:31:1), argc=4, argv
=0x00007fffffffdf28, init=<unavailable>, fini=<unavailable>, rtld_fini=<unavailable>, stack_end=0x00007fffffffdf
18) at libc-start.c:360:3                                                                                       
    frame #26: 0x00005555556f1215 olly`_start + 37

[c-cube]

There seems to be a buffer size check error in trace-fuchsia. Would you mind pinning trace-fuchsia at a81785f8c0fc6fdd7481f0ddd1078d5a0fc0fe2b ?

edit: is there a chance that multiple threads might be accessing the fuchsia exporter at once? With ~sharded:false there is no lock on the buffer chain. It could be worth trying ~sharded:true on line 22 of olly_format_fuchsia.ml.