[fpc-devel] Proof of Concept ARC implementation

Sven Barth pascaldragon at googlemail.com
Mon Oct 27 19:59:40 CET 2014


Am 27.10.2014 19:24, schrieb Michael Van Canneyt:
>
>
> On Mon, 27 Oct 2014, Sven Barth wrote:
>
>>
>> Am 27.10.2014 17:20 schrieb "Hans-Peter Diettrich" 
>> <DrDiettrich1 at aol.com>:
>> >
>> > Jonas Maebe schrieb:
>> >
>> >
>> >> Additionally, as mentioned before, I still believe it's a very bad 
>> idea to be able to inherited from a regular class and turn it into a 
>> reference counted class. Reference
>> counted and non-reference-counted
>> >> classes are different language entities with different behaviour 
>> and different code generation requirements, and hence should be 
>> completely unrelated.
>> >
>> >
>> > Something like ShortString and AnsiString?
>>
>> With the difference that Short- and AnsiString are assignable to 
>> eachother while Jonas does not want that for reference counted and 
>> ordinary classes.
>>
>> >> Even if you completely forbid typecasting a reference counted 
>> class into a non-reference-counted parent class, simply calling an 
>> inherited method from a
>> non-reference-counted parent class can easily completely mess up the 
>> reference counting (e.g. suppose that inherited method inserts "self" 
>> into a linked list).
>> >
>> >
>> > ACK. The only way out; I can see; is adding the *possibility* of 
>> refcounting to TObject, meaning Add/ReleaseRef methods and a RefCount 
>> field. Then the compiler can safely
>> generate refcounting code for *all* objects and non-weak references, 
>> and the counting methods take care of required operations. Delphi 
>> offers two means for specialized
>> refcounting, the virtual counting methods, and the (COM compatible?) 
>> refcount value of -1 for unmanaged objects.
>>
>> What do you mean with "virtual counting methods"?
>> The main reason I decided not to introduce reference counting for 
>> every class was that some people feared the performance impact of the 
>> reference counting.
>
> There *will* be a performance impact, and there *are* circular 
> references.
>
> You cannot simply minimize either of these facts away:
>
> Reference counting of all objects is not some nice-to-have "feature". 
> It is a complete shift in paradigm at the very root of the language.
>
> You would need to write a different RTL entirely which is aware of 
> this paradigm. If you have reference counted objects, you can make 
> strings into real objects etc.
>
> No problem with all that, interesting ideas even, but not with the 
> current codebase and RTL.
Florian has written me an idea two weeks ago regarding the "backwards 
compatibility" aspect (I won't argue the performance impact one ;) ):
- TObject and all descendants are reference counted (please no size and 
performance discussion here)
- in code that does not use ARC ("modeswitch arc off" - the default; or 
maybe better a local directive) all instance variables are considered "weak"
- constructors of code that does not use ARC return with reference count 
= 1, otherwise reference count is initially 0 (like for interfaces and 
currently in my branch)
- destructors also take care of this additional "pseudo" reference upon 
being called; thus the object is freed after the last ARC reference is 
gone AND (for legacy code) Free/Destroy has been called (thus when the 
reference count really reaches 0)

With this approach there would be no change for legacy code (except for 
the additional refcount field per instance), as reference counting would 
only happen with enabled ARC directive/modeswitch (thus there could 
still be memory leaks for such classes). New code could take ARC into 
account and could be written accordingly with "weak" modifiers, etc.

Regards,
Sven



More information about the fpc-devel mailing list