On Fri, 17 Sep 2010 11:43:55 -0400, Andrew Whitworth <[email protected]> wrote: > On Fri, Sep 17, 2010 at 11:18 AM, Peter Lobsinger <[email protected]> wrote: >> But more to the point, they are insufficient for handling aggregates. >> If a PMC cointaining ATTR isn't a simple PMC*, but something more >> complicated (like PMC**), the whole thing falls appart. Clearly you >> can still have one PMC reference another by these means, but the >> SET_ATTR and GET_ATTR macros cannot express these assignments. > > Ah, I see where my problem is. Parrot used to have real write-barrier > macros GC_WRITE_BARRIER() and similar things. I see now that those > macros do not appear to be present anymore. I agree with you that > SET_ATTR and GET_ATTR macros are not sufficient for this purpose. We > previously did have (and will likely have again) better macros which > will be sufficient. > > If we need to add a deprecation note for adding new macros, we can do that. > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev
I am not sure I like barriers implementation as macros. Reasons: - not flexible - could not implement different GC cores - overhead - usually we need read/write barrier only on few assignments.For example, with Generational GC we need only write barrier on old objects I have read the paper that bacek recommends on the GCTaskList page: http://research.microsoft.com/en-us/um/people/simonpj/papers/non-stop/index.htm It is centered around haskel, but it could be implemented on parrot also. The idea is that we could dynamically swap vtables of objects that should be barriered. The new vtable will contain functions that execute barrier-ing logic (card marking, scavenging etc.) and re-dispatch to the original vtable function. This vtable swapping could happen only on PMCs that contain pointer attributes and the new barriering functions could be installed only on attribute modifying vtable slots (for write barriers) or only attribute assess vtable slots (read barriers). Sure, I miss something important as I am new with the code base and I am still trying to figure out how it works. But there are cons if we take this approach: - there could exists multiple vtable versions (each for every GC core) that will not conflict - we add overhead only on action that need to be barriered. - creating the alternative vtables could be automatized. Best regards -- Luben Karavelov Research and development Spectrum Net JSC 36, D-r G. M. Dimitrov Blvd. 1797 Sofia Mobile: +359 884332140 url: www.spnet.net _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
