blob: 6d2c4aa8126a18cca05012ad60a208423eda3adf (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
|
undefined8 type
===============
Note: This is likely to be hard to implement in an efficient way,
without compromising on memory safety.
Idea
----
Perhaps have an `undefined8` type that can be used for custom allocation?
It would be used in embedded arrays:
embed [4096]undefined8 data
There could be up to 3 states:
1. Unused and zero (or freed and zeroed out)
2. In use for allocations
3. In use for metadata
- But perhaps this is just a subset of 2.
Problems
--------
* There has to be a way to mark the data as "consumed".
- A simple way would be to only support a 1-bit all or nothing use flag.
- To support granular arbitrary allocation, a bit-map would be required
(which means 1/8 = 12.5% additional memory usage).
* Some kind of GC support is necessary.
- To avoid stack scanning, it could happen when the whole call
chain has returned. (E.g. in a main loop or similar).
- When there are no inbound pointers, it would be possible to do
some kind of GC. This might need RTTI?
- The GC could either do copy-collection, or be able to mark data
as undefined again somehow.
* It would be good if an `undefined8` structure can be "virtualized"
inside another `undefined8` structure, and if this could be done with
any level of nesting.
Alternative solution
--------------------
Perhaps support specific allocation strategies only, for example:
* Bump-allocation
* Bump-allocation with in-place GC
* Bump-allocation with copying GC
The initial allocator could come via a `giveme`?
|
