Changes between Version 23 and Version 24 of GCTasklist

Show
Ignore:
Timestamp:
09/05/09 11:51:50 (5 years ago)
Author:
bacek
Comment:

GC irc talk

Legend:

Unmodified
Added
Removed
Modified
  • GCTasklist

    v23 v24  
    105105 
    106106new revision: r35380 
     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