Heap management and Datum refactor #35

New issue

Closed

opened 2025-07-24 11:55:40 -07:00 by affine · 0 comments

affine commented

2025-07-24 11:55:40 -07:00

Owner

Actual encapsulated data (individual vecs, ints, anything non datum) goes into Rc<RefCell<..>> in a heap manager.
- Heap manager returns mutable references that cast immediately into Datum
- Heap manager will return a mutable reference for a given index by cloning the rc and turning it into a ptr or ref.
- Heap manager can alloc and return new data at any time if the VM suddenly wants new memory for a result
- Heap manager can receive a ptr or ref, turn it back into an Rc, and then drop it. AT THIS POINT test if can drop original data as well
- Heap manager in oncelock so it can be accessed as singleton without being allocated elsewhere
Datum wrap around heap indexes.
- Datum has a custom drop impl that tells heap manager to decrement some reference count
Registers store Datum directly with copy/clone

We want a polymorphic datum type. We want one that will fit into a physical register on any machine. Even if we opt to stay stack based. The datum type does not fit in a single register on any machine. Plan to solve: 1. Actual encapsulated data (individual vecs, ints, anything non datum) goes into Rc<RefCell<..>> in a heap manager. - Heap manager returns mutable references that cast immediately into Datum - Heap manager will return a mutable reference for a given index by cloning the rc and turning it into a ptr or ref. - Heap manager can alloc and return new data at any time if the VM suddenly wants new memory for a result - Heap manager can receive a ptr or ref, turn it back into an Rc, and then drop it. AT THIS POINT test if can drop original data as well - Heap manager in oncelock so it can be accessed as singleton without being allocated elsewhere 2. Datum wrap around heap indexes. - Datum has a custom drop impl that tells heap manager to decrement some reference count 3. Registers store Datum directly with copy/clone