| blob | e1e907caeb58849a36e64eab5172b3552a97fa1c |
1 # 2016/06/04
3 ## 08:52
5 Ok, so there will be a garbage collector interface and some classes, and then
6 another project will have the actual implementation.
8 ## 09:01
10 One thing that will be complex though, is when threads are active and running
11 that local variables can point to objects. Due to this, going through the
12 call stack will be extremely complex and potentially a very expensive
13 sequence because objects would have to be checked for each potential position
14 in the stack to make sure that the given integers are objects.
16 ## 09:05
18 As for native object layout and references, there will be a singular chain
19 of positions which contain object information. There would then be a pointer
20 to the actual object data (and array elements). Although doubly referenced
21 this would allow all the objects to easily be traversed (because they would
22 be in a chain) and would also allow the objects to be compacted if they are
23 not "locked". Compaction however, could be a complex process. Before an object
24 is accessed (such as to determine if it is an instance of a class) a flag can
25 be set to indicate that it should not be moved elsewhere (the data pointer
26 of the reference). When the operation completes, the flag is cleared so the
27 object may be moved around. Actual interaction in this case is very short so
28 the flag should only be set for short durations. Due to multi-threading however
29 and context switching, there would need to be an atomic update to the usage
30 count of an object before its pointer can safely be used. There would also have
31 to be a usage count. If there is an error and the usage count is never
32 decremented then the object may never get garbage collected, so there will have
33 to be some kind of guard regardless of kernel/program exceptions being thrown
34 so that the count lowers.
36 ## 09:12
38 Back to what I was previously writing, I could have two stacks: one for objects
39 and the other for everything else. However that would complicate memory
40 allocation and require another set of registers. So it would be best if it
41 were kept to a single stack. So, instead there could be a reference zone which
42 is used to store references that are in a given position. The stack would be
43 structured in a way where it can easily be scanned. The start of the stack
44 would indicate its length and the number of references in the reference zone.
45 This way, objects which are not in the reference zone do not have to be checked
46 at all to determine if they point to objects. So due to this, any reference
47 which is set to an object will have to be placed in the reference zone.
49 ## 09:20
51 The garbage collector will need to have a generic object window kind of thing.
52 Basically it is an interface which acts as a rover over the objects which
53 are currently allocated. One window would go over the objects which are
54 associated with variables running in methods. Another window would go over the
55 static fields inside of a class. There would just be these two windows as that
56 is all that is needed. If the window reaches an Object, it would potentially
57 have fields. If a class has object fields, then they are scanned with the
58 mark and sweep algorithm. Generally any field which is not strongly reached
59 by a variable or static field can be garbage collected. I would have to handle
60 cases where a field refers to `this`. In these cases the object must not be
61 marked, otherwise any objects could just not be garbage collected by just
62 referring to themselves. However cyclic references with one or more objects
63 will not be garbage collected unless no class static or local points to those
64 given objects. Another rover that would be needed would be one that can go
65 over arrays of objects also.
67 ## 10:59
69 I could also probably use a kind of allocation scheme of sorts. This way there
70 can be a completely shared interface which is used to access any and all
71 objects that exist.
73 ## 11:27
75 For the queue, I should make it concrete and then have associated object
76 providers and such which are implemented by providers of objects.
78 ## 16:28
80 When it comes to object allocation, I should have differing allocators
81 potentially or just an interface and a standard one. I would propose that the
82 standard and rerecording interpreters use the allocators themselves. In fact
83 the allocators could act as access to object memory spaces. So rather than
84 having a bunch of discrete actual objects in the interpreter, there is really
85 just a pool that is used and such. The size of the memory pool could be fixed
86 or it could grow along with the application. However to be friendly to other
87 systems, the allocator would have to be able to detect system memory usage and
88 the amount of memory that the VM is using so that GCs happen when system memory
89 gets a bit low. This way another program for example can claim that memory.
90 Also, if a system supports it there could even be garbage collection callbacks
91 performed.
93 ## 16:32
95 One thing to consider however is that when it comes to the rerecording
96 allocator, that it must be deterministic. I would suppose then that the
97 garbage collector that would run on the allocator would run when requested by a
98 running program. When the allocator determines that memory is a bit shrinking
99 and not as available, it can alert the launcher that it may be time for a
100 garbage collection. This way in the rerecording interpreter the GC events and
101 such can be recorded by the launcher and executed from there.
103 ## 16:34
105 What I then need object representation access, some pointers, other ranges, and
106 other kind of memory regions that could be used. The memory interface would
107 need to handle cases where the layout of memory is dynamic and potentially
108 where code and data are stored in differing regions. There would also have to
109 be a compact and generic means to modify memory bytes, values, and such.