[fpc-devel] Proof of Concept ARC implementation

[Martin Frb]

On 29/10/2014 13:03, Sven Barth wrote:
> On 28.10.2014 09:57, Hans-Peter Diettrich wrote:
>> Sven Barth schrieb:
>>> Take unit Typinfo for example where quite some methods take a TObject
>>> instance.
>>
>> The TypInfo methods can determine the exact type of their arguments, and
>> act inside accordingly.
>
> If you have a method X that takes a TObject parameter how do you plan 
> to pass it a reference counted object when these and TObject are not 
> compatible *at compiletime*?

It would be possible, if you had a special type
TAnyObject (can be ref or none ref-counted)
or a modifier "TObject ref_compatible"

TObject  (not refcounted by default)
TRefObject = class(TObject); refcounted;

The compiler only needs refcounted code, for TRefObject  and TAnyObject 
, but not for TObject

TObject would need virtual methods for Inc- and DerRefcount (but this is 
memory only once per class, not per object).
For TObject they do nothing, for TRefObject  they do what the name says.

TObject only needs them if it is passed to  TAnyObject, otherwise the 
compiler does not generate calls to it.

In order for TAnyObject  to work, TObject and TRefObject  need the same 
memory layout. But the memory for refcount can be allocated in front of 
the object (as it is done for strings too). Then TRefObjects hidden 
pointer, points to the same fields as TObject.
Memory (de-)allocation is done in CreateInstance/FreeInstance, which are 
both virtual, and can account for the "refcount memory header"

In this case, the only overhead for none refcounted classes, are 2 
entries in the VMT of each class.

If the Inc- and DerRefcount are not overidden by usercode, then WPO (or 
class final ?) can optimize the code, and de-virtualize them for all but 
TAnyObject.

Just my 2 cents.