Deprecations for 3.0

[Luben Karavelov]

On Fri, 17 Sep 2010 11:43:55 -0400, Andrew Whitworth
<wknight8111 at gmail.com> wrote:
> On Fri, Sep 17, 2010 at 11:18 AM, Peter Lobsinger <plobsing at gmail.com> 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