Re: next meeting: Monday Feb 10, 10:00 - 12:00 CET

[Samuel Hym <samuel@xxxxxxxxxxx>]

Hi,

Le 05 février 2025 à 10h36, Hannes Mehnert disait :

> > > He confirmed that our implementation is correct.
>
> By "correct", if I understand you correctly, it is "this abort will never be
> triggered"?

That’s what I meant, indeed.

> > > What happens is that, as pools are allocated by the GC, they will
> > > probably follow each other in the virtual memory address space; the
> > > compactor might decide to release a pool in the middle of that
> > > sequence of pools, so we’ll end up with (coarse-grained) fragmentation
> > > with our `malloc`/`free` implementation. But it will be valid
> > > nevertheless!
>
> I don't quite understand the impact of that paragraph. "it will be valid
> nevertheless" - does this mean, we won't run into the "abort()"?

Yes, no `abort`.
I was just underlining the fact that it won’t compact our memory
completely, as far as our `malloc`/`free` will see it.

> (I'm not sure what Unikraft uses, neither what "newlib's malloc
> implementation" refers to).

Unikraft comes with various implementations, including a buddy
allocator coming from Xen.

> To me, the underlying question is about the tradeoff between code size and
> performance -- and performance should be taken into account with a concrete
> (unikernel) example [plus the variance in terms of bytes vs Bigarray, and
> allocation strategies].

Indeed!

-- 
Samuel