Move data recorded with yk_promote into MTThread.
#976
Conversation
| let (thrdtrcr, promotions) = THREAD_MTTHREAD.with(|mtt| { | ||
| ( | ||
| mtt.thread_tracer.take().unwrap(), | ||
| mtt.promotions.take().unwrap(), |
There was a problem hiding this comment.
we should say why the unwraps are safe.
There was a problem hiding this comment.
The existing comment on line 296 explains.
There was a problem hiding this comment.
Oh right. I thought that was referring to something else because it's singular. Maybe wack and s on the end?
(Top-notch pedantry right here!)
|
If I understand correctly, you move the promotions from a trace recorder (local to a thread by definition) into a thread local mtthread? At the risk of sounding like a dummy, what is the advantage of this? Just more convenient, or something more profound? |
I originally thought that all tracing backends could work out when |
|
OK |
I've slowly come to realise that calls to `yk_promote` could (but don't
currently!) end up being in compiled in two different ways:
1. A literal call to `yk_promote_*`.
2. An inlined call to a side-band recording mechanism (e.g.
`PTWRITE`).
Because I hadn't teased these two apart in my mind, my previous attempt
had kind-of tried to merge the two together in one API. It's now clear
that was entirely misguided on my part.
This commit can be seen as partly undoing my previous attempt: literal
calls to `yk_promote_*` now record the data in `MTThread` which is a
thread local. However, when tracing stops, the promotion data is now
extracted from `MTThread` so it can safely be moved to another thread.
That means we can now handle ykjit#1 above: but we don't yet have an API that
can handle ykjit#2.
|
Please squash. |
ltratt
force-pushed
the
move_yk_promote_to_mtthread
branch
from
ef0b3e1 to
7eff562
Compare
|
Squashed. |
I've slowly come to realise that calls to
yk_promotecould (but don't currently!) end up being in compiled in two different ways:yk_promote_*.PTWRITE).Because I hadn't teased these two apart in my mind, my previous attempt had kind-of tried to merge the two together in one API. It's now clear that was entirely misguided on my part.
This commit can be seen as partly undoing my previous attempt: literal calls to
yk_promote_*now record the data inMTThreadwhich is a thread local. However, when tracing stops, the promotion data is now extracted fromMTThreadso it can safely be moved to another thread.That means we can now handle #1 above: but we don't yet have an API that can handle #2.