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
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
|
Implicit arenas
===============
Arenas is a quite different and new concept to programmers who are used
to other programming languages.
Also, it might not be clear when an arena qualifier should be used and
when it shouldn't.
Rough idea + problems:
* If there is a distinction between objects and records:
Implicitly make all objects take the "this" parameter as an arena,
if it is modifiable.
* Constructors always take an arena parameter.
- Something that takes no var parameter and returns a var value/object
MUST take an arena.
- How to define "constructor" in SLUL?
Constructors are simply functions in a type scope.
Perhaps everything in a type scope should implicitly take an arena?
* For local variables?
* For structs, the arena keyword might be bad idea anyway. It could be used
to create "loophole objects", which would have more permissions than the
struct they are contained in (could be useful, but also confusing and cause
security holes). Additionally, it could possibly prevent some optimizations.
* For global variables, the arena keyword makes no sense.
(Because references make no sense there)
* Syntax for passing an arena to a function/constructor?
Syntax test
-----------
With arena keywords:
func .new() -> arena Obj
func arena Obj.do_stuff() {
arena OtherObj x = .new()
work1(arena, x)
work2(arena x)
...
}
Without, but with var, and with arena at call sites:
func .new() -> Obj
func var Obj.do_stuff() {
var OtherObj x = .new()
work1(arena, x)
work2(arena x)
}
Problems:
* Arenas could leak into unexpected locations of the program
* No way to give non-arena access to an object.
Solution?
* Make only *allocation* access implicit, and
* Have a keyword for *system* access
What should this be called?
- system, sys, monad?
Can arenas be garbage-collected?
--------------------------------
When should the garbage collection be done?
* Perhaps when a block is full?
Fragmentation can arise, which is hard to prevent:
* There can be multiple arenas with large "holes", but those cannot accept
allocations from other arenas.
* De-fragmenting an arena (e.g. via copying GC) only works if:
- The arena has no incoming pointers, OR
- There are only incoming pointers that a trivial to update
* Garbage collection requires knowledge of:
- the location of all references inside the arena
- the size of each object
This can be solved with runtime-type information, but more efficient
solutions might be possible (in particular, more memory efficient
solutions).
|
