| 107 | |
| 108 | |
| 109 | ---- |
| 110 | |
| 111 | == GC rewrapping talk == |
| 112 | |
| 113 | <bacek> Whiteknight: I want to break something in parrot. And I'll need your help with this idea :) |
| 114 | <Whiteknight> i like breaking, and ideas! |
| 115 | <bacek> Current GC API. |
| 116 | It's broken-by-design. |
| 117 | <bacek> E.g. using "Small_Object_Pool" directly for allocating objects enforce particular implementation. |
| 118 | <bacek> Whiteknight: also, current GC API doesn't allow something like "Gimme chunk of memory with this size" |
| 119 | Whiteknight: and without this ability I can merge "PMC" and "ATTRibutes" into single allocation. |
| 120 | Or convert Context to use ATTRibutes. |
| 121 | <Whiteknight> bacek: we need PMCs to be located together so we can sweep |
| 122 | <purl> thanks bacek :) |
| 123 | <bacek> So, "mark-sweep" enforces particular design. And it's bad |
| 124 | What about compacting GCs? |
| 125 | <Whiteknight> bacek: any GC is going to have a sweep |
| 126 | <bacek> Or trademills |
| 127 | Whiteknight: not all of them |
| 128 | <Whiteknight> bacek: I can't think of a single algorithm that doesn't use some sort of sweep |
| 129 | <bacek> In many cases it can be implicit |
| 130 | <Whiteknight> ACTUALLY, chromatic's idea might work here |
| 131 | <bacek> "Uniprocessor Garbage Collection Techniques" |
| 132 | http://www.cs.rice.edu/~javaplt/311/Readings/wilson92uniprocessor.pdf |
| 133 | anyway, "sweep" doesn't require all objects to be same size |
| 134 | and allocated from "Small_Object_Pool" |
| 135 | <dukeleto> 67 pages of GC goodness |
| 136 | <bacek> dukeleto: indeed |
| 137 | Whiteknight: check src/gc/api.c, line 329 |
| 138 | <Whiteknight> dukeleto: You jest, but I'm going to print and read every one of them |
| 139 | <bacek> My idea is not to have "arenas" in interp, but some "struct gc*" with few functions and "void * gc_private" |
| 140 | <Whiteknight> bacek: Then you are going to love the new patch from jrtayloriv: It does exactly that |
| 141 | <bacek> So, all implementation details will be decoupled from Interp. |
| 142 | <dukeleto> Whiteknight: I don't jest. that looks like a really good introductory/overview paper. |
| 143 | <bacek> Whiteknight: Yay! jrtayloriv++ |
| 144 | <Whiteknight> bacek: I like that idea a lot. I've wanted to do it myself for a while |
| 145 | <bacek> Just ensure that this functions has explicit ""size" argument |
| 146 | <Whiteknight> bacek: if we changed the fixed-size attributes pool to include PMC and ATTR together, we could get the effect you are talking about |
| 147 | <bacek> yes |
| 148 | <Whiteknight> then we could sweep those pools because all objects would be guaranteed to be PMCs |
| 149 | <bacek> Why sweeping require all objects to be PMC? |
| 150 | It's just chunks of memory |
| 151 | <Whiteknight> bacek: If we sweep linearly over a pool, we don't know if the block is a PMC or not |
| 152 | <bacek> We know size. |
| 153 | <Whiteknight> PMCs have flags, need destruction, etc. We need to know if an object is a PMC |
| 154 | but I can allocate an X byte buffer in the same pool I allocate an X byte PMC |
| 155 | and I don't want to call VTABLE_destroy on the buffer |
| 156 | <bacek> Ok. |
| 157 | We just need pairs of function "get_raw_chunk" and "get_pmc" in gc* |
| 158 | no, bad idea. |
| 159 | All we need is pass (optional) pointer to "destroy function". |
| 160 | Which will be invoked by GC during sweep. |
| 161 | <Whiteknight> so store the destroy function in the pool? |
| 162 | that idea actually has some merit |
| 163 | <bacek> In allocated object. |
| 164 | <Whiteknight> so for every object we add a header with a pointer to a destroy function? |
| 165 | <bacek> Whiteknight: only when requested. GC can be smart enough to not store it always. |
| 166 | E.g. in most PMC without "destroy" VTABLE it's useless. |
| 167 | <bacek> Bah! We have to change Pmc2s to set "active_destroy" as pragma, not in "VTABLE_init" |
| 168 | <bacek> This step is too big... Ok, scratch last idea. |
| 169 | <Whiteknight> yes, and custom_mark |
| 170 | <bacek> Let's just have pair of functions for allocate memory. |
| 171 | Both of them should accept explicit size. |
| 172 | <Whiteknight> I like that idea, but we need to be able to tell whether an item is a PObj or not |
| 173 | and then we need to be able to find all STRING headers that point to a string buffer |
| 174 | because of COW, it can be N:1 |
| 175 | <bacek> Immutable strings ftw! |
| 176 | <Whiteknight> I want immutable strings. That would be a very good idea |
| 177 | <dukeleto> i like cows |
| 178 | <Whiteknight> but, it would be a huge job |
| 179 | <bacek> Actually, with this approach we can just drop STRING and always use String PMC. |
| 180 | Just reimplement it use ATTRibutes and allocate raw chunk of memory for real string |
| 181 | Then, String,mark will do all required job |
| 182 | <Whiteknight> there is some merit to that. I think the string compactor is very expensive |
| 183 | <bacek> And incomprehensible :) |
| 184 | <NotFound> Note that in order to make PMC variable size we might need to forbid morphing assignments |
| 185 | <Whiteknight> NotFound: Yes, I hadn't even thought about that |
| 186 | <bacek> (morphing) VTABLE_morph is way-too-premature optimisation |
| 187 | <Whiteknight> yes, but some people do use the morph opcode |
| 188 | so we can't kill it entirely |
| 189 | at least, not yet |
| 190 | <bacek> Fortunately, I've put broad deprecation warning for all VTABLEs in 1.4 :) |
| 191 | <NotFound> bacek: morph is not the only way of morphing. Look for example at the Undef pmc. |
| 192 | <Whiteknight> yeah, we lose a lot of flexibility |
| 193 | I really like this idea. Hard part is finding a way to do it without breaking the whole damn codebase |
| 194 | <Whiteknight> bacek: yes, dump some of your ideas onto the wiki. I think there is a "GCTasklist" page you can use |
| 195 | <NotFound> You can start thinking about how to avoid assignment to Undef |
| 196 | <bacek> NotFound: anyway, we have to have something for implementing compacting GC. |
| 197 | And it's closely related to "assign to Undef" |
| 198 | Because we have to update all pointers to PMC. |
| 199 | Or wrap "PMC" into struct with single pointer. |
| 200 | |