blob: 7eeeca538bf416228f18724c94ee68551789a685 (
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
|
Arena allocation keywords
-------------------------
(subject to change. see also own.txt)
Inspired by this:
http://www.barnowl.org/research/rc/
LRL could have an "arenaown" keyword, which tells that a pointer is owned
by the arena in which the object is allocated. For such pointers there
can be some safety rules:
- Ownership can't be transfered away to another pointer outside of the arena
(but the pointer can used without taking ownership).
- A such pointer can't take ownership of an object allocated outside of the
arena (but may point to an unowned object, or something in the constant
data section, or a function pointer*).
- By default, all function parameters marked with "arenaown" or "arena" must
belong to the same arena.
- A parameter marked "arena" will not take ownership but is used to enforce
that "arenaown" parameters are also allocated in the same arena. A function
that allocates something in a given arena, must have at least one pointer
marked with "arena" or "arenaown" and must pass it to the allocator
function.
- Future versions of LRL may add a special syntax to indicate which arena
something is owned by.
* actually, even function pointers and pointers to the data section are risky
since they may be part of a dynamic library, which can be unmapped from
memory.
Code that doesn't use static variables, and at least one non-null pointer
parameter, can instead use a transparent arena allocation (by allocating
in the same arena as the parameter).
|
