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

[Reynir Björnsson <reynirr@xxxxxxxxx>]

Dear list,

The next meeting is Feb 10, 10-12 CET. Please see the following link for 
the agenda and previous meeting notes. Please also feel free to add 
items to the agenda:
https://pad.data.coop/To6IOSeNSOK9kFVlgo7XWw

And please find at the end the meeting notes of today's meeting.

Best,
Reynir

## Meeting January 27th 10:00 - 12:00 CET

- Participants: Pierre, Sam, Reynir, Pixie

### GC compactor
- The GC compactor will unmap _ leading to ABORT
- As you have to call the compactor explicitly we probably did not test it
- Maybe we don't actually need compaction?
- Sam: Observeration from mirage-www:
  - the behavior was similar to ocaml 4 version
  - if we tweak space overhead to 80 we get a similar profile as ocaml 
4 version
- Pierre: we can't deny users to call `Gc.compact ()` which would lead 
to a crash
- Pierre: implementing mmap/munmap would be a huge effort
- Sam: https://github.com/ocaml-flambda/flambda-backend/pull/3179 
propose  a different version of the compactor that doesn't fragment memory
- Sam: So we could switch the whole GC (but this is a lot of work)
- Pierre: Maybe time to investigate another allocator (e.g. jemalloc)
- Pierre: everytime I looked into this it was very difficult
- Sam: is writing or switch the allocator difficult?
- Pierre: switching is easy, writing one is hard. Writing an allocator 
based on mmap/munmap is easy, the other way is hard.
- Sam: we can imagine something radical like we know how much we will 
allocate to the unikernel.
- Pierre: we know that: all the memory at the beginning. It's in 
sysdeps_solo5.c. We have `_nolibc_init()` where we can init everything.
- Pierre: doesn't have time, but can look into a list of allocators
- Pierre: We want to have very fast free memory estimation like we do in 
Qubes firewall. Will check that.
- Sam: we do many small allocations in Mirage unikernels?
- Pierre: we do as long as we have BigArrays
- Pierre, with Sam agreeing: in the meantime we should encourage users 
to not call `Gc.compact ()`
### Performance: bytes vs. bigarray (cstruct)
- Pierre: No news :D
- Sam: I agree about reducing small (bigarray) allocations cf. previous 
item.
### Unikraft
- Sam: Unikraft has real mmap/munmap which would be another way to solve 
the GC compactor issue
- Pierre: is it possible to "steal" the allocator from unikraft? Also 
wrt. licensing.
- Sam: Re: licensing, it may be quite a mess. In the code base it's 
already quite a mix of licenses: GPL, MIT, ...
- Sam: also possible their implementation uses part of musl
- Sam: all in all, not so simple