---
# System prepended metadata

title: Meeting Minute 2021-02-04
tags: [Meeting]

---

Meeting Minute 2021-02-04
===

###### tags: `Meeting`

:::info
- **Date:** 2021-02-04 16:00
- **Agenda**
    1. MemoryAllocator Api
    2. Commit Hooks
- **Participants:**
    - Thomas
    - Matthias
    - Clemens
- **Reference:**
    - [Meeting Minute 2021-01-21](/S1pSGY0BTcCoScCKWSQJsQ?both)

:::

## MemoryAllocator Api

```cpp
class Table {
    TableImpl* impl;
};
class MemoryAllocator {
    std::vector<TableImpl*> table_memory;

public:
    auto allocate_table() -> TableImpl*;
    void free_all();
};

extern MemoryAllocator GLOBAL_ALLOCATOR;
```

- Memory allocator should be the same across all values in the interpreter (otherwise some are freed while other are not which will lead to invalid pointers)
    - It's probably also ok to mix the global allocator with one "local" allocator used in the interpreter
- What Api should we provide to the implementer of a `Function`?
    - `auto CallContext::allocator() -> MemoryAllocator*`
    - **`auto CallContext::make_table() -> Table`**
    - Should we move a `Table` that is created from the `GLOBAL_ALLOCATOR` when inserting it in the environment (or in another `Table`)?
        - this would have to be done recursively
        - probably not a big performance hit
        - **BUT**: The user can't keep around a copy of the table because the (internal) pointers will be different and the old copy would point to different memory than the `Table` value used in the interpreter
        - *I think we should avoid this!*
        - **-> Don't do this. Sometimes the use wants to keep a `Table` outside of the interpreter**
- Should be (internally and externally) use a wrapper type for the pointers (e.g. `gc_ptr<T>` instead of `T*`) allocated by the `MemoryAllocator`.
    - This would be just to differentiate between other raw pointers and and pointers created by a `MemoryAllocator`
    - `gc_ptr` would be the dumbest possible implementation of a smart pointer
- Later we can also implement a proper garbage collector for `MemoryAllocator`.
    - This would probably also need to take `Function`s into account
    - and I'm not sure how this would work for `Table`s that are copied and stored outside of the interpreter (they would probably be ignored)
        - but I would argue this is not a real restriction (epecially not once we have metatables) because we could just store the table in lua code and create a wrapper function in lua that call our c++ function with the table as a parameter whenever we need it.
- `Envrionment` should be copied at the start of the interpreter

## Commit Hooks

- Please install the commit hooks `./scripts/install_hooks.sh`
    - also clang-format-10 apparently formats differently than clang-format-11
- Automatically update submodules?

:closed_book: Tasks
--
==Importance== (1 - 5) / Name / **Estimate** (1, 2, 3, 5, 8, 13)

- [x] @Matthias make MemoryAllocator free all its objects when destructed


## Notes
