Re: Summary of discussion following LPC2023 sframe talk

[Mathieu Desnoyers]

On 2023-11-15 10:49, Peter Zijlstra wrote:
> On Wed, Nov 15, 2023 at 10:09:16AM -0500, Mathieu Desnoyers wrote:
[...]
> >    - When we have a good understanding of the JIT requirements in terms
> >      of frame description content, the other element that would need to
> >      be solved is how to allow JITs to emit frame data in a data structure
> >      that can expand. We may need something like a reserved memory area, with
> >      a counter of the number of elements which is used to synchronize communication
> >      between the JITs (producer) and kernel (consumer).
>
> Again, huh?! Expand? Typical JIT has the normal epoch like approach to
> text generation, have N>1 text windows, JIT into one until full, once
> full, copy all still active crap into second window, induce grace period
> and wipe first window, rince-repeat.
>
> Just have a sframe thing per window and expand the definition of 'full'
> to be either text of sframe window is full and everything should just
> work, no?

Is the generated text reachable (for execution) before the end of the
window during which it was created, or is there some kind of epoch delay
between text generation and the moment where it becomes reachable ?

If there is a delay between code generation and the moment where it
becomes reachable (e.g. a whole epoch), then I understand your point
that we could consider the whole jitted text window as belonging to a
single sframe section and register it in one go to the kernel. The
overhead of the system call would be amortized over the epoch duration.

However, if JITs are allowed to incrementally add text to the current
window and make it immediately reachable, then we need to have some
way to synchronize appending "sframe functions" into a memory mapping
that do not require issuing a system call every time a new function
is jitted.

Thanks,

Mathieu

--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com