Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

Am 09.10.2015 19:29 schrieb "Fabrício Srdic" :
>
> Any progress to ARC implementation?

Not much feedback here... Also not every core developer agrees with the
approach I've taken and at least with a feature as fundamental as this I'd
like to have at least /some/ consens...

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Fabrício Srdic]

Any progress to ARC implementation?

Best regards
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[hinsta...@yandex.ru]

Here is the program I've been working on: https://bitbucket.org/hinst/sillychatIt was created with purpose of demonstrating how reference-counted objects could be used in a program which actually does something and now it works more or less. And it's beautifulಠ_ಠ Because there are no .Free calls, everything is released automatically. Well, almost. The program is a simple text chat; "proof-of-concept". It has client and server parts. I documented the project [briefly] in README.md file, the documentation is also displayed on the project page (link above).I have many reference-counted objects in it: server, clients, critical sections, sockets, memory blocks, buffers, threads. And they work. When I have heaptrc enabled, it reports no memory leaks. Anyone who doubts benefits of automatic reference counting is welcome to examine my code and see how it benefits from not having to release instances manually. Especially the memory streams that are being moved around and would otherwise have to be released manually. If you are not familiar with Mercurial version control system, you can download repository from project page, there should be download button on the left. 06.11.2014, 00:02, "Sven Barth" pascaldra...@googlemail.com: Am 05.11.2014 21:55 schrieb hinsta...@yandex.ru: Not bad. I confirm that both Lazarus 1.3 and variables of refcounted type declared in another unit work now. Good to know :) I wanted to assemble some prototype application with refcounted objects to see how would such feature behave in a more or less complex program; but in spite of lack of free time I am not sure how much time it will take Take your time. The branch is not going anywhere for now as I first want to finish my work on packages, generic methods and maybe some other features like extended RTTI, invoke, etc. :) Regards, Sven , ___ fpc-devel maillist  -  fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

On 19.11.2014 17:29, hinsta...@yandex.ru wrote:

Here is the program I've been working on:
https://bitbucket.org/hinst/sillychat

It was created with purpose of demonstrating how reference-counted
objects could be used in a program which actually does something and now
it works more or less.

And it's beautiful


At least someone seems to be having fun with that branch ^^

One question though: Why did you disable implicit exception handling? 
This way it's rather likely that there'll be memory leaks if an 
exception occurs inside a procedure/method that uses reference counted 
objects (or strings or arrays or interfaces for that matter...).


Regards,
Sven

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[hinstance]

I dunno. Just wanted to see if it is going to work with implicit 
exceptions turned off. I rather dance around and fix memory leaks when 
they appear than have implicit try-except block in every procedure. I 
did measurements once; found out that each try-except adds increases 
stack usage by about 60 bytes each.



19.11.2014 23:59, Sven Barth:

On 19.11.2014 17:29, hinsta...@yandex.ru wrote:

Here is the program I've been working on:
https://bitbucket.org/hinst/sillychat

It was created with purpose of demonstrating how reference-counted
objects could be used in a program which actually does something and now
it works more or less.

And it's beautiful


At least someone seems to be having fun with that branch ^^

One question though: Why did you disable implicit exception handling? 
This way it's rather likely that there'll be memory leaks if an 
exception occurs inside a procedure/method that uses reference counted 
objects (or strings or arrays or interfaces for that matter...).


Regards,
Sven

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

On 20.11.2014 00:08, hinstance wrote:

I dunno. Just wanted to see if it is going to work with implicit
exceptions turned off. I rather dance around and fix memory leaks when
they appear than have implicit try-except block in every procedure.


1. they are try-finally blocks
2. then you'll have to add try-except blocks and leave the procedure 
without error as otherwise the compiler generated decrement calls aren't 
executed



I
did measurements once; found out that each try-except adds increases
stack usage by about 60 bytes each.


That's the size of the buffer used for setjump. On Win64 in 2.7.1 this 
size is 0 and in Win32 with 2.7.1 and the compiler compiled with 
TEST_WIN32_SEH it should be smaller as well. For any other target we'll 
need another exception handling mechanism (DWARF/Itanium exception 
handling).


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[hinstance]

I think I discovered another issue. Not sure if you are already aware of it. 
Don't remember it being reported before. 

Seems like using heaptrc feature (memory leak reporting) with refc-compiler 
leads to program crashing on exit. In particular, it appears that heaptrc 
starts reporting memory leaks earlier than refcounted objects get released

Not like it is a big problem now. If desired, one can check if refcounted 
objects leak or not by keeping a global counter variable for each base class 
(call InterlockedIncrement in constructor; call InterlockedDecrement in 
destructor; then write count in finalization section of unit)

06.11.2014, 00:02, Sven Barth pascaldra...@googlemail.com:
 Am 05.11.2014 21:55 schrieb hinsta...@yandex.ru:

 Not bad. I confirm that both Lazarus 1.3 and variables of refcounted type 
 declared in another unit work now.

 Good to know :)

 I wanted to assemble some prototype application with refcounted objects to 
 see how would such feature behave in a more or less complex program; but in 
 spite of lack of free time I am not sure how much time it will take

 Take your time. The branch is not going anywhere for now as I first want to 
 finish my work on packages, generic methods and maybe some other features 
 like extended RTTI, invoke, etc. :)

 Regards,
 Sven
 ,

 ___
 fpc-devel maillist  -  fpc-devel@lists.freepascal.org
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[hinstance]

eh sorry; false alarm. You know how it is, when encountering a bug, you first 
think that it's someone else's fault)) or maybe it's just me who tends to think 
in such way((. 
It works))

10.11.2014, 18:47, hinsta...@yandex.ru hinsta...@yandex.ru:
 I think I discovered another issue. Not sure if you are already aware of it. 
 Don't remember it being reported before.

 Seems like using heaptrc feature (memory leak reporting) with refc-compiler 
 leads to program crashing on exit. In particular, it appears that heaptrc 
 starts reporting memory leaks earlier than refcounted objects get released

 Not like it is a big problem now. If desired, one can check if refcounted 
 objects leak or not by keeping a global counter variable for each base class 
 (call InterlockedIncrement in constructor; call InterlockedDecrement in 
 destructor; then write count in finalization section of unit)

 06.11.2014, 00:02, Sven Barth pascaldra...@googlemail.com:
  Am 05.11.2014 21:55 schrieb hinsta...@yandex.ru:
  Not bad. I confirm that both Lazarus 1.3 and variables of refcounted type 
 declared in another unit work now.
  Good to know :)
  I wanted to assemble some prototype application with refcounted objects to 
 see how would such feature behave in a more or less complex program; but in 
 spite of lack of free time I am not sure how much time it will take
  Take your time. The branch is not going anywhere for now as I first want to 
 finish my work on packages, generic methods and maybe some other features 
 like extended RTTI, invoke, etc. :)

  Regards,
  Sven
  ,

  ___
  fpc-devel maillist  -  fpc-devel@lists.freepascal.org
  http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

 ___
 fpc-devel maillist  -  fpc-devel@lists.freepascal.org
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[hinstance]

Not bad. I confirm that both Lazarus 1.3 and variables of refcounted type 
declared in another unit work now. 

I wanted to assemble some prototype application with refcounted objects to see 
how would such feature behave in a more or less complex program; but in spite 
of lack of free time I am not sure how much time it will take 

01.11.2014, 23:28, Sven Barth pascaldra...@googlemail.com:
 On 30.10.2014 11:00, hinsta...@yandex.ru wrote:
  Even if line numbers are slightly different, you can easily find the
  place where exception is raised: in jitforms.pp: in procedure
  GetVMTVirtualMethodOffset: raise
  Exception.Create('GetVMTVirtualMethodOffset Parent Virtual Method not
  found');
  I leave the decision if this worth investigating or not to you as I am
  myself not sure. Not that I could possibly force someone to look into it
  even if I insisted.

 This problem should now be fixed as well. I forgot to adjust a VMT
 related constant that is (thankfully) used by that LCL code. ;)

 Regards,
 Sven
 ___
 fpc-devel maillist  -  fpc-devel@lists.freepascal.org
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

Am 05.11.2014 21:55 schrieb hinsta...@yandex.ru:

 Not bad. I confirm that both Lazarus 1.3 and variables of refcounted type
declared in another unit work now.

Good to know :)

 I wanted to assemble some prototype application with refcounted objects
to see how would such feature behave in a more or less complex program; but
in spite of lack of free time I am not sure how much time it will take

Take your time. The branch is not going anywhere for now as I first want to
finish my work on packages, generic methods and maybe some other features
like extended RTTI, invoke, etc. :)

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

On 31.10.2014 15:31, Sven Barth wrote:

Am 30.10.2014 11:34 schrieb hinsta...@yandex.ru
mailto:hinsta...@yandex.ru hinsta...@yandex.ru
mailto:hinsta...@yandex.ru:
 
  okay sorry for spamming the mailing list
 
  So basically the other problem I reported before (generic +
refcounted does not work) turns out to be something different:
  Declaring variable of refcounted type in a different unit makes the
compiler stop with error 2014092205
 
  Assume in unit Aunit I have
type TSomething = class refcounted end;
 
  Then I declare a procedure:
 
  procedure Run;
  var
server: TServer;
  begin
server := TServer.Create;
  end;
 
  When procedure Run is declared in Aunit, it compiles. However, if I
declare procedure Run in some other unit, say Bunit, then the compiler
stops on line with assignment :=

That simplifies things. Thanks for the update :)


I have now fixed the problem, so you can retest, if you want. :)

Regards,
Sven

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

On 30.10.2014 11:00, hinsta...@yandex.ru wrote:

Even if line numbers are slightly different, you can easily find the
place where exception is raised: in jitforms.pp: in procedure
GetVMTVirtualMethodOffset: raise
Exception.Create('GetVMTVirtualMethodOffset Parent Virtual Method not
found');
I leave the decision if this worth investigating or not to you as I am
myself not sure. Not that I could possibly force someone to look into it
even if I insisted.


This problem should now be fixed as well. I forgot to adjust a VMT 
related constant that is (thankfully) used by that LCL code. ;)


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

Am 31.10.2014 06:05 schrieb Hans-Peter Diettrich drdiettri...@aol.com:

 Sven Barth schrieb:

 On 30.10.2014 04:14, Hans-Peter Diettrich wrote:


 I wonder how difficult it would be to implement the existing Interface
 refcounting model for TObject, so that this runtime variation could be
 tested and benchmarked as well, in addition to the current compiletime
 approach. According to the problems of the compiletime approach,
 revealed in this thread, it looks not viable to me at all.


 The code would mostly be the same as the one I already implemented. Add
virtual to the ARCDecRef, ARCIncRef and ARCRefCount methods of TObject,
adjust the RTL helper functions to not expect a refcount field at a
specific offset, remove the restrictions that reference counting is only
done for classes marked as refcounted and you're done...


 Looks quite easy :-)

 Could you introduce this feature into your branch, by conditional
compilation?

When I find the time I'll try.



 Mark just pointed me to another problem, possibly unhandled yet.
Interface refcounting must be updated, as soon as the underlying object
becomes refcounted as well. Do you already have an idea how to handle
refcounting for classes with interfaces?

Simply implement the AddRef and Release methods using ARCIncRef and
ARCDecRef and return ARCRefCount.

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

Am 30.10.2014 11:34 schrieb hinsta...@yandex.ru hinsta...@yandex.ru:

 okay sorry for spamming the mailing list

 So basically the other problem I reported before (generic + refcounted
does not work) turns out to be something different:
 Declaring variable of refcounted type in a different unit makes the
compiler stop with error 2014092205

 Assume in unit Aunit I have
   type TSomething = class refcounted end;

 Then I declare a procedure:

 procedure Run;
 var
   server: TServer;
 begin
   server := TServer.Create;
 end;

 When procedure Run is declared in Aunit, it compiles. However, if I
declare procedure Run in some other unit, say Bunit, then the compiler
stops on line with assignment :=

That simplifies things. Thanks for the update :)

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

Am 30.10.2014 11:01 schrieb hinsta...@yandex.ru hinsta...@yandex.ru:

 I managed to acquire some additional information on Lazarus 1.3 + FPC ARC
edition problem

 First of all, I tested if Lazarus 1.3 trunk compiled with FPC trunk works
correctly. It does.

 However, Lazarus 1.3 trunk with FPC ARC crashes.

 Lazarus trunk by FreePascal trunk - OK
 Lazarus trunk by FreePascal ARC edition - CRASH at startup

 here is the point where it crashes:

 D:\FPC_ARC\Llazarus.exe
 using config file D:\FPC_ARC\L\lazarus.cfg
 [FORMS.PP] ExceptionOccurred
   Sender=Exception
   Exception=GetVMTVirtualMethodOffset Parent Virtual Method not found
   Stack trace:
   $00710C16  GETVMTVIRTUALMETHODOFFSET,  line 458 of
D:/FPC_ARC/L/designer/jitforms.pp
   $00710D21  GETTCOMPONENTVALIDATERENAMEVMTOFFSET,  line 497 of
D:/FPC_ARC/L/designer/jitforms.pp
   $00714F18  JITFORMS_$$_init,  line 2094 of
D:/FPC_ARC/L/designer/jitforms.pp
   $00410F54
 TApplication.HandleException GetVMTVirtualMethodOffset Parent Virtual
Method not found
   Stack trace:
   $00710C16  GETVMTVIRTUALMETHODOFFSET,  line 458 of
D:/FPC_ARC/L/designer/jitforms.pp
   $00710D21  GETTCOMPONENTVALIDATERENAMEVMTOFFSET,  line 497 of
D:/FPC_ARC/L/designer/jitforms.pp
   $00714F18  JITFORMS_$$_init,  line 2094 of
D:/FPC_ARC/L/designer/jitforms.pp
   $00410F54
 Exception at 00710C16: Exception:
 GetVMTVirtualMethodOffset Parent Virtual Method not found.

 Even if line numbers are slightly different, you can easily find the
place where exception is raised: in jitforms.pp: in procedure
GetVMTVirtualMethodOffset: raise
Exception.Create('GetVMTVirtualMethodOffset Parent Virtual Method not
found');

 I leave the decision if this worth investigating or not to you as I am
myself not sure. Not that I could possibly force someone to look into it
even if I insisted.

The VMT has changed in my branch. Take a look at the declaration of TVmt in
rtl/inc/objpash.inc and maybe adjust the code to use the offset of the
first virtual method instead of hardcoding it...

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Hans-Peter Diettrich]

Sven Barth schrieb:

On 28.10.2014 10:15, Michael Schnell wrote:

On 10/27/2014 05:17 PM, Hans-Peter Diettrich wrote:


Something like ShortString and AnsiString?


Only that ShortStrings can easily be avoided (AFAIK, no great
performance advantage to use them) and hence are seldom used right now.


ShortStrings don't have implicit initialization/finalization, thus no 
implicit try/finally blocks, which at least with FPC's platform 
independant exception handling mechanism or SEH on i386-win32 have quite 
some performance impact even in case no error occured (SEH on 
x86_64-win64 (and in theory arm-wince) only has an impact in case of an 
error (and an impact in binary size for the exception tables)). Also 
there is no reference counting for ShortString.


So: basically the performance of reference counted objects compared to 
normal objects is more or less similar to the performance of AnsiStrings 
compared to ShortStrings (it's not completely equal, because AnsiStrings 
are allocated on the heap while ShortStrings are on the stack, but it's 
good enough...). And did anyone yet complain about the performance of 
AnsiStrings? ;)


Right, this entire discussion is somewhat fruitless without benchmarks.

I wonder how difficult it would be to implement the existing Interface 
refcounting model for TObject, so that this runtime variation could be 
tested and benchmarked as well, in addition to the current compiletime 
approach. According to the problems of the compiletime approach, 
revealed in this thread, it looks not viable to me at all.



Just an idea about type incompatibilities:
When a TArcObject cannot be assigned to a TObject variable, because a 
conversion (as between ShortString and AnsiString) is impossible, then a 
delegate could be created that turns the TArcObject into something 
compatible with TObject. I have no idea how this could be 
accomplished[1], but as long as it only affects refcounted objects, the 
overhead has to be accepted when using ARC objects at all. Some overhead 
is inevitable for ARC, and everybody should be free to decide whether 
such overhead is acceptable for his projects or targets. Not using ARC 
at all should always be an option.


[1] Perhaps the same (possibly simplified) mechanism could be used, for 
TArcObjct/TObject conversion, as for Interface/TObject conversion.


DoDi

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Hans-Peter Diettrich]

Sven Barth schrieb:

On 28.10.2014 10:19, Michael Schnell wrote:

On 10/27/2014 07:59 PM, Sven Barth wrote:


- in code that does not use ARC (modeswitch arc off - the default;
or maybe better a local directive) all instance variables are
considered weak


While I do have a vision what weak means here, can you give an exact
description ?


- no change in reference count when assigning a refcounted object 
variable to it


- no change in reference count when assigning it to a refcounted object 
variable
I suspect that this can cause premature destruction of the object, when 
either

- another value is assigned to the refcounted object variable
- all other (counted) references to the object disappear

But I don't have a solution for these problems, as long as the compiler 
inlines the refcounting code at compile time.


DoDi

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Hans-Peter Diettrich]

Sven Barth schrieb:

On 28.10.2014 09:57, Hans-Peter Diettrich wrote:



  Something like ShortString and AnsiString?



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*?


That's intentionally impossible in general. For TypInfo, a dedicated 
method (override) can be added, or an untyped parameter can be used like 
in FreeAndNil.


DoDi

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

On 30.10.2014 04:16, Hans-Peter Diettrich wrote:

Sven Barth schrieb:

On 28.10.2014 10:19, Michael Schnell wrote:

On 10/27/2014 07:59 PM, Sven Barth wrote:


- in code that does not use ARC (modeswitch arc off - the default;
or maybe better a local directive) all instance variables are
considered weak


While I do have a vision what weak means here, can you give an exact
description ?


- no change in reference count when assigning a refcounted object
variable to it



- no change in reference count when assigning it to a refcounted
object variable

I suspect that this can cause premature destruction of the object, when
either
- another value is assigned to the refcounted object variable
- all other (counted) references to the object disappear

But I don't have a solution for these problems, as long as the compiler
inlines the refcounting code at compile time.


Yes, weak reference fall into the category of from great power comes 
great responsibility.


Regards,
Sven

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

On 30.10.2014 00:28, ListMember wrote:

On 2014-10-29 14:58, Sven Barth wrote:

Delphi introduced weak variable to break up cycling, I implemented
them similary in my branch (not using the attribute syntax though) and
in Florian's suggestions all object instance variables in legacy code
would be weak for backwards compatibility.


Given that legacy code will be infinitely more in size than new code (at
least in the foreseable future), wouldn't be wiser to consider everthing
'weak' (i.e. default) and use 'strong' (or something similar) to denote
those variables of the new object type?


Variables of non-reference counted object types are always weak anyway. 
The weak keyword applies only to variables of reference counted object 
types.


Regards,
Sven

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

On 30.10.2014 04:15, Hans-Peter Diettrich wrote:

Sven Barth schrieb:

On 28.10.2014 09:57, Hans-Peter Diettrich wrote:



  Something like ShortString and AnsiString?



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*?


That's intentionally impossible in general.For TypInfo, a dedicated
method (override) can be added, or an untyped parameter can be used like
in FreeAndNil.


The only viable solution would be additional overloads, because for an 
untyped parameter you can't use TypeInfo(). It's even questionable 
whether reference counted objects should be assignable to pointers or 
untyped parameters...


But considering that I'm not a fan of this not compatible anyway, I 
personally won't think much about that :)


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

On 30.10.2014 04:14, Hans-Peter Diettrich wrote:

Sven Barth schrieb:

On 28.10.2014 10:15, Michael Schnell wrote:

On 10/27/2014 05:17 PM, Hans-Peter Diettrich wrote:


Something like ShortString and AnsiString?


Only that ShortStrings can easily be avoided (AFAIK, no great
performance advantage to use them) and hence are seldom used right now.


ShortStrings don't have implicit initialization/finalization, thus no
implicit try/finally blocks, which at least with FPC's platform
independant exception handling mechanism or SEH on i386-win32 have
quite some performance impact even in case no error occured (SEH on
x86_64-win64 (and in theory arm-wince) only has an impact in case of
an error (and an impact in binary size for the exception tables)).
Also there is no reference counting for ShortString.

So: basically the performance of reference counted objects compared to
normal objects is more or less similar to the performance of
AnsiStrings compared to ShortStrings (it's not completely equal,
because AnsiStrings are allocated on the heap while ShortStrings are
on the stack, but it's good enough...). And did anyone yet complain
about the performance of AnsiStrings? ;)


Right, this entire discussion is somewhat fruitless without benchmarks.

I wonder how difficult it would be to implement the existing Interface
refcounting model for TObject, so that this runtime variation could be
tested and benchmarked as well, in addition to the current compiletime
approach. According to the problems of the compiletime approach,
revealed in this thread, it looks not viable to me at all.


The code would mostly be the same as the one I already implemented. Add 
virtual to the ARCDecRef, ARCIncRef and ARCRefCount methods of 
TObject, adjust the RTL helper functions to not expect a refcount field 
at a specific offset, remove the restrictions that reference counting is 
only done for classes marked as refcounted and you're done...


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[hinsta...@yandex.ru]

I managed to acquire some additional information on Lazarus 1.3 + FPC ARC edition problemFirst of all, I tested if Lazarus 1.3 trunk compiled with FPC trunk works correctly. It does.However, Lazarus 1.3 trunk with FPC ARC crashes.Lazarus trunk by FreePascal trunk - OKLazarus trunk by FreePascal ARC edition - CRASH at startuphere is the point where it crashes:D:\FPC_ARC\Llazarus.exeusing config file D:\FPC_ARC\L\lazarus.cfg[FORMS.PP] ExceptionOccurred  Sender=Exception  Exception=GetVMTVirtualMethodOffset Parent Virtual Method not found  Stack trace:  $00710C16  GETVMTVIRTUALMETHODOFFSET,  line 458 of D:/FPC_ARC/L/designer/jitforms.pp  $00710D21  GETTCOMPONENTVALIDATERENAMEVMTOFFSET,  line 497 of D:/FPC_ARC/L/designer/jitforms.pp  $00714F18  JITFORMS_$$_init,  line 2094 of D:/FPC_ARC/L/designer/jitforms.pp  $00410F54TApplication.HandleException GetVMTVirtualMethodOffset Parent Virtual Method not found  Stack trace:  $00710C16  GETVMTVIRTUALMETHODOFFSET,  line 458 of D:/FPC_ARC/L/designer/jitforms.pp  $00710D21  GETTCOMPONENTVALIDATERENAMEVMTOFFSET,  line 497 of D:/FPC_ARC/L/designer/jitforms.pp  $00714F18  JITFORMS_$$_init,  line 2094 of D:/FPC_ARC/L/designer/jitforms.pp  $00410F54Exception at 00710C16: Exception:GetVMTVirtualMethodOffset Parent Virtual Method not found.Even if line numbers are slightly different, you can easily find the place where exception is raised: in jitforms.pp: in procedure GetVMTVirtualMethodOffset: raise Exception.Create('GetVMTVirtualMethodOffset Parent Virtual Method not found'); I leave the decision if this worth investigating or not to you as I am myself not sure. Not that I could possibly force someone to look into it even if I insisted.___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[hinsta...@yandex.ru]

okay sorry for spamming the mailing list So basically the other problem I reported before (generic + refcounted does not work) turns out to be something different:Declaring variable of refcounted type in a different unit makes the compiler stop with error 2014092205 Assume in unit Aunit I have  type TSomething = class refcounted end; Then I declare a procedure: procedure Run;var  server: TServer;begin  server := TServer.Create;end;When procedure Run is declared in Aunit, it compiles. However, if I declare procedure Run in some other unit, say Bunit, then the compiler stops on line with assignment :=
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[silvioprog]

Very good initiative Sven!

Can you create a branch on Github (https://github.com/graemeg/freepascal)?

Thank you very much!

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Hans-Peter Diettrich]

Sven Barth schrieb:

On 30.10.2014 04:14, Hans-Peter Diettrich wrote:



I wonder how difficult it would be to implement the existing Interface
refcounting model for TObject, so that this runtime variation could be
tested and benchmarked as well, in addition to the current compiletime
approach. According to the problems of the compiletime approach,
revealed in this thread, it looks not viable to me at all.


The code would mostly be the same as the one I already implemented. Add 
virtual to the ARCDecRef, ARCIncRef and ARCRefCount methods of 
TObject, adjust the RTL helper functions to not expect a refcount field 
at a specific offset, remove the restrictions that reference counting is 
only done for classes marked as refcounted and you're done...


Looks quite easy :-)

Could you introduce this feature into your branch, by conditional 
compilation?



Mark just pointed me to another problem, possibly unhandled yet. 
Interface refcounting must be updated, as soon as the underlying object 
becomes refcounted as well. Do you already have an idea how to handle 
refcounting for classes with interfaces?


DoDi

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Michael Schnell]

Considering the multiple discussions recently here done on the New 
Strings, that also introduce multiple compiler-relevant brands of a 
single type, IMHO there are some restrictions to be payed attention to, 
if the user is enable to use both ref-counted and not ref-counted 
Objects. Otherwise we will be facing some dangerous ambiguity.


One way to avoid the ambiguity is to only provide a single brand TObject 
type i.e. the choice would be completely dynamic by a property 
IsRefCounted to TObject.


If the runtime overhead for this is considered to be too big, two 
TObject Types (or brands of the TObject type) could be provided.



But here additional considerations are necessary:

The two brands need to be incompatible. A simple assignment of one to 
the other needs to be forbidden


If such assignment is supported by the compiler, some kind of automatic 
conversion needs to be implemented (see New Strings encoding conversions)


To decently support lists of such objects (TList), there are some 
alternatives:

(1) different incompatible lists types are provided for either brand
(2) TList is provided with only one brand and auto-conversion is forced 
(This is how NewStings work with TStrings in Delphi, IMHO inappropriately)
(3) An additional type is provided that is fully dynamic and hence 
supports all brands (This is how I would prefer NewStings to work with 
TString)

(4) My favorite here: The ref-counted type is compatible meaning that
...(a) you can assign a not ref counted object to a variable of the ref 
counted type brand. Here (e.g.) the ref count is set to -1 meaning not 
ref counted
...(b) you can't assign a ref counted object to a variable of the not 
ref counted type brand
...(c) TList is provided only for ref counted TObjects. Auto-conversion 
is done (setting the ref-count to -1) when moving a not ref-counted 
object into the list.


-Michael



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Michael Schnell]

On 10/29/2014 01:27 PM, Michael Schnell wrote:

I forgot:
...(b1) you can't assign a ref counted object to a variable of the not 
ref counted type brand: this will result in a runtime error (as the ref 
counted TObject type can hold not ref-counted objects by ref-count = -1)
...(b2) you can assign a ref counted object to a variable of the not ref 
counted type brand, if the source  has ref-count = -1.


-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

On 28.10.2014 10:19, Michael Schnell wrote:

On 10/27/2014 07:59 PM, Sven Barth wrote:


- in code that does not use ARC (modeswitch arc off - the default;
or maybe better a local directive) all instance variables are
considered weak


While I do have a vision what weak means here, can you give an exact
description ?


- no change in reference count when assigning a refcounted object 
variable to it
- no change in reference count when assigning it to a refcounted object 
variable

- no change in reference conut when assigning between weak variables

Delphi introduced weak variable to break up cycling, I implemented them 
similary in my branch (not using the attribute syntax though) and in 
Florian's suggestions all object instance variables in legacy code would 
be weak for backwards compatibility.


Regards,
Sven

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

On 28.10.2014 09:57, Hans-Peter Diettrich wrote:

Sven Barth schrieb:

Am 27.10.2014 21:00, schrieb Hans-Peter Diettrich:

Sven Barth schrieb:

Am 27.10.2014 17:20 schrieb Hans-Peter Diettrich
drdiettri...@aol.com mailto:drdiettri...@aol.com:



  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.


Where would this matter? When TObject and TManagedObject are
different (base) types, a direct assignment of references is impossible.

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*?



IMO Delphi versions don't offer backwards compatibility for good
reasons, instead a purchased licencse allows to *also* use all older
versions, down to D7. What I'm missing here are bugfixes, because the
development of older versions is almost stopped as soon as a new version
is distributed. Known bugs are mostly fixed only in newer versions,
which introduce new bugs and features at the same time - good for sales
but bad for the customers. Since FPC/Lazarus are open source, user
groups may offer continued support for their preferred version(s), by
backporting bugfixes into these versions.


We are not Embarcadero. We don't get money for providing FPC, we do it 
for free. And we aren't a big team like Mozilla (who get paid anyway, so 
back to square one). So it's natural that we're going to choose the 
route with the least maintenance burden, but the most compatibility (and 
providing long term supported releases *is* a burden). It's not easy to 
find this compromise, but we're trying...


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

On 28.10.2014 10:15, Michael Schnell wrote:

On 10/27/2014 05:17 PM, Hans-Peter Diettrich wrote:


Something like ShortString and AnsiString?


Only that ShortStrings can easily be avoided (AFAIK, no great
performance advantage to use them) and hence are seldom used right now.


ShortStrings don't have implicit initialization/finalization, thus no 
implicit try/finally blocks, which at least with FPC's platform 
independant exception handling mechanism or SEH on i386-win32 have quite 
some performance impact even in case no error occured (SEH on 
x86_64-win64 (and in theory arm-wince) only has an impact in case of an 
error (and an impact in binary size for the exception tables)). Also 
there is no reference counting for ShortString.


So: basically the performance of reference counted objects compared to 
normal objects is more or less similar to the performance of AnsiStrings 
compared to ShortStrings (it's not completely equal, because AnsiStrings 
are allocated on the heap while ShortStrings are on the stack, but it's 
good enough...). And did anyone yet complain about the performance of 
AnsiStrings? ;)


Regards,
Sven

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

On 28.10.2014 11:20, hinsta...@yandex.ru wrote:

I attached a very small sample project which can not be compiled with
FreePascal ARC edition.


Thanks, I can reproduce it with that example.


+ one more thing I noticed: Lazarus 1.3 (trunk) compiled with FreePascal
ARC edition refuses to start. Perhaps it's nothing to be surprised of.
Haven't investigated this further yet; it just fails silently; should
compile it with console output enabled later


Considering that Lazarus does not make use of my experimental feature 
there /should/ be no problems with existing code...


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Jonas Maebe]

On 27 Oct 2014, at 19:59, Sven Barth wrote:

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.


There's still the problem if you create an instance in ARC code, then  
pass it as a (e.g. const) parameter to a routine from a unit that does  
not use ARC and which stores it in a linked list or a local field, and  
later the instance goes out of scope in the ARC code (so it gets  
freed)...


Apple also supports mixing ARC and non-ARC code in Objective-C, but  
the only way this works is by requiring the programmer to manually  
perform the reference counting in non-ARC code. I don't think there's  
any quick hack possible that allows you to mix them transparently  
without a lot of pitfalls.



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [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.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[hinsta...@yandex.ru]

I believe you overcomplicate itVariable type should define if variable is reference-counted or not.class refcounted = refcountedclass descendant from class refcounted = refcountednormal class = not refcountedpass refcounted instance as TObject = not refcounted at all...Consider existing COM interface implementation. Variable of interface type is a pointer. Consider having var face: IUnknown;then you pass it as pointer:hash := CalculateHash(Pointer(face));this should work correctlyAll functions which do not store pointers will work correctly with interface variables as pointersAll functions which do not store TObject will work correctly with refcounted descendant of TObjectWith lists it's worse. If you store pointers to interface variables, they become invalid the moment you don't have any "managed" variables left in scope.Same is true for refcounted objects: if you store them in good old TObjectList, it will hold invalid pointers.However this all is just something to keep in mind. I don't see the need of overcomplicating it on compiler level.Interface variable is a pointer.Reference-counted object IS TObject. TObject IS pointer. Reference-counted object IS pointer. These should be compatible. If some programmer stores refcounted object as TObject, then his refcounted variable goes out of scope, and then he wonders why he gets Access Violation, it should be his problem of not understanding how stuff works29.10.2014, 16:48, "Martin Frb" laza...@mfriebe.de: 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. ___ fpc-devel maillist  -  fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Michael Schnell]

On 10/29/2014 01:58 PM, Sven Barth wrote:


- no change in reference count when assigning a refcounted object 
variable to it
- no change in reference count when assigning it to a refcounted 
object variable

- no change in reference conut when assigning between weak variables

Thanks for the explanation.


Delphi introduced weak variable ...


Continuing their abusing of well defined keyword from other languages.

In C weak means
 - for externals: if the linker does not find the reference it writes a 
NULL instzead of aborting the link process with an error message.
 - for globals: if the linker finds another global of this name it does 
not use the weak ones. It aborts when it finds duplicates that are both 
non-weak.


not similar at all :-(

-Michael

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Michael Schnell]

On 10/29/2014 03:09 PM, hinsta...@yandex.ru wrote:


I believe you overcomplicate it

No. We are going to run into the same mess with incompatible brands of 
the same types as with New Strings :-(


-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[hinstance]

I believe that whoever came up with new strings overcomplicated it
Consider Java and C# : they do not store encoding in string variables

29.10.2014, 17:30, Michael Schnell mschn...@lumino.de:
 On 10/29/2014 03:09 PM, hinsta...@yandex.ru wrote:
  I believe you overcomplicate it

 No. We are going to run into the same mess with incompatible brands of
 the same types as with New Strings :-(

 -Michael
 ___
 fpc-devel maillist  -  fpc-devel@lists.freepascal.org
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Dmitry Boyarintsev]

On Wed, Oct 29, 2014 at 10:38 AM, Dmitry Boyarintsev 
skalogryz.li...@gmail.com wrote:

 ... about Delphi compatibility.

 That's the number two (and some times number one) reason, why FPC has to
deal with the new features as ref-counting, anonymous functions, strings
...etc.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[hinstance]

Whatever; I disagree
refcounted descendants of non-refcounted objects should be assignable to any 
variable of parent type; just like any variable is assignable to a variable of 
parent type

type
  TRefc = class refcounted(TObject) 
  end;

var
  thing: TObject;
  refThing: TRefc;
begin
  ...
  thing := refThing;  // fine because TRefc is TObject
  refThing := thing;  // compiler refuses because thing is not necessarily 
refThing
  refThing := TRefc(thing); // fine; explicit casting

and that is my vision of how this should work

however mandatory explicit casting is also a viable option:

thing := TObject(refThing);  // okay, compiler, I know what I'm doing, now do 
your thing, cast this for me


29.10.2014, 17:46, Jonas Maebe jonas.ma...@elis.ugent.be:
 On 29 Oct 2014, at 15:09, hinsta...@yandex.ru wrote:
  With lists it's worse. If you store pointers to interface variables,
  they become invalid the moment you don't have any managed
  variables left in scope.

  Same is true for refcounted objects: if you store them in good old
  TObjectList, it will hold invalid pointers.

  However this all is just something to keep in mind. I don't see the
  need of overcomplicating it on compiler level

 It's not just something to keep in mind, because if you include
 automatic conversion from ref-counted to non-refcounted classes, this
 is guaranteed to lead to very hard to debug problems. One of Pascal's
 foundations is that it has strong type checking and does not allow you
 to assign anything to anything just because it happens to have the
 same size in bits and somewhat similar functionality. You cannot
 assign an interface to a class instance without explicitly using as
 either.

 Jonas

 ___
 fpc-devel maillist  -  fpc-devel@lists.freepascal.org
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Michael Schnell]

On 10/29/2014 03:33 PM, hinsta...@yandex.ru wrote:

I believe that whoever came up with new strings overcomplicated it
Consider Java and C# : they do not store encoding in string variables


Yep.

dynamically encoded Strings are a nice feature if done appropriately. 
But I don't think they are strictly necessary.


-Michael

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Michael Schnell]

On 10/29/2014 03:56 PM, hinsta...@yandex.ru wrote:

Whatever; I disagree
refcounted descendants of non-refcounted objects should be assignable to any 
variable of parent type; just like any variable is assignable to a variable of 
parent type

And what about TLIst ? If TList is done for not ref-counted objects you 
loose the ref counting when storing and retrieving them or you simply 
don't know whet you get out. If TList is done for ref-counted objects, 
you need an appropriate conversion when storing, as you might pull them 
to a ref-counted variable..


-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[hinstance]

I suggest leaving TList from FPC RTL as is. It works with pointers, so leave it 
be.

For refcounted objects we would use generic list like TFPGList from fgl unit. 
However, currently existing TFPGList implementation would be unable to deal 
with refcounted objects correctly because TFPGLists uses TFPSList (u can 
examine source file if interested), and TFPSList moves items like memory 
blocks. So TFPGList can not store refcounted objects just like it can not store 
interface vars.

A generic class capable of storing interfaces and refc-objects correctly will 
need to use dynamic arrays under the hood because with dynamic arrays you don't 
loose type information

29.10.2014, 18:10, Michael Schnell mschn...@lumino.de:
 On 10/29/2014 03:56 PM, hinsta...@yandex.ru wrote:
  Whatever; I disagree
  refcounted descendants of non-refcounted objects should be assignable to 
 any variable of parent type; just like any variable is assignable to a 
 variable of parent type

 And what about TLIst ? If TList is done for not ref-counted objects you
 loose the ref counting when storing and retrieving them or you simply
 don't know whet you get out. If TList is done for ref-counted objects,
 you need an appropriate conversion when storing, as you might pull them
 to a ref-counted variable..

 -Michael
 ___
 fpc-devel maillist  -  fpc-devel@lists.freepascal.org
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

On 29.10.2014 14:23, Jonas Maebe wrote:


On 27 Oct 2014, at 19:59, Sven Barth wrote:


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.


There's still the problem if you create an instance in ARC code, then
pass it as a (e.g. const) parameter to a routine from a unit that does
not use ARC and which stores it in a linked list or a local field, and
later the instance goes out of scope in the ARC code (so it gets freed)...


Hmm... yes, that would indeed be a problem.


Apple also supports mixing ARC and non-ARC code in Objective-C, but the
only way this works is by requiring the programmer to manually perform
the reference counting in non-ARC code. I don't think there's any quick
hack possible that allows you to mix them transparently without a lot of
pitfalls.


We can of course also provide means to manually do reference counting 
(will e.g. be necessary for TStringList if one has code that abuses 
Objects[]...). Nevertheless if one mixes refcounting and non-refcounting 
code with care (maybe we can add optional warnings/hints when passing 
instances between ARC and non-ARC code) it should work.


Regards.
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

On 29.10.2014 15:33, hinsta...@yandex.ru wrote:

I believe that whoever came up with new strings overcomplicated it
Consider Java and C# : they do not store encoding in string variables


Because in C# and Java they are UTF-16. Keep in mind that Delphi also 
changed to UTF-16 based strings (UnicodeString) and introduced the code 
page aware AnsiString for easy access to single byte strings (reading 
files, etc.).


Regards,
Sven

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

On 29.10.2014 16:17, hinsta...@yandex.ru wrote:

I suggest leaving TList from FPC RTL as is. It works with pointers, so leave it 
be.

For refcounted objects we would use generic list like TFPGList from fgl unit. 
However, currently existing TFPGList implementation would be unable to deal 
with refcounted objects correctly because TFPGLists uses TFPSList (u can 
examine source file if interested), and TFPSList moves items like memory 
blocks. So TFPGList can not store refcounted objects just like it can not store 
interface vars.

A generic class capable of storing interfaces and refc-objects correctly will 
need to use dynamic arrays under the hood because with dynamic arrays you don't 
loose type information


You are wrong. TFPGList works correctly with reference counted types, 
because it overrides the necessary functions of TFPSList (mainly 
CopyItem). Afterall TFPGListAnsiString works without problems ;)


Regards,
Sven

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

On 29.10.2014 15:56, hinsta...@yandex.ru wrote:

however mandatory explicit casting is also a viable option:

thing := TObject(refThing);  // okay, compiler, I know what I'm doing, now do 
your thing, cast this for me


Mandatory explicit typecasts would indeed be an option. This way one 
would (hopefully) know that this assignment might influence the 
reference count and that one should do the necessary precautions (e.g. 
manually increasing the reference count) beforehand. Of course depending 
on the usage of the object it might still lead to memory leaks, because 
that additional reference never gets released...


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Jonas Maebe]

On 29 Oct 2014, at 16:30, Sven Barth wrote:


On 29.10.2014 14:23, Jonas Maebe wrote:


Apple also supports mixing ARC and non-ARC code in Objective-C, but  
the
only way this works is by requiring the programmer to manually  
perform
the reference counting in non-ARC code. I don't think there's any  
quick
hack possible that allows you to mix them transparently without a  
lot of

pitfalls.


We can of course also provide means to manually do reference  
counting (will e.g. be necessary for TStringList if one has code  
that abuses Objects[]...).


That's indeed only useful if you then also require that all code not  
written in non-ARC mode performs manual reference counting (like Apple  
does). Having it as a possibility does not solve the problem of  
unpredictability.


Nevertheless if one mixes refcounting and non-refcounting code with  
care (maybe we can add optional warnings/hints when passing  
instances between ARC and non-ARC code) it should work.


Then you have to give a hint/warning for every inherited call inside a  
refcounted class that inherits from a non-reference-counted class,  
because it passes the refcounted instance self to non-ARC code. It  
completely destroys the concept of encapsulation that you shouldn't  
have to know, and in some cases even can't know, what methods do with  
their parameters or with self. Your code may work with one version of  
the parent class and suddenly break with the next version. Being  
careful is simply impossible with this way of working.



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Michael Schnell]

On 10/29/2014 04:17 PM, hinsta...@yandex.ru wrote:

I suggest leaving TList from FPC RTL as is. It works with pointers, so leave it 
be.


OK. Repeating the argument for TObjectList.



-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

On 29.10.2014 16:59, Michael Schnell wrote:

On 10/29/2014 04:17 PM, hinsta...@yandex.ru wrote:

I suggest leaving TList from FPC RTL as is. It works with pointers, so
leave it be.


OK. Repeating the argument for TObjectList.


TObjectList could (and IMHO should) be extended with support for manual 
reference counting if we decide to use an approach where reference 
counted and non-reference counted object variables are assignable to 
each other. In fact the methods I added to TObject for this (mainly 
ARCIsRefCounted, ARCIncRef and ARCDecRef) would already allow for this.


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

On 29.10.2014 16:45, Jonas Maebe wrote:


On 29 Oct 2014, at 16:30, Sven Barth wrote:


On 29.10.2014 14:23, Jonas Maebe wrote:


Apple also supports mixing ARC and non-ARC code in Objective-C, but the
only way this works is by requiring the programmer to manually perform
the reference counting in non-ARC code. I don't think there's any quick
hack possible that allows you to mix them transparently without a lot of
pitfalls.


We can of course also provide means to manually do reference counting
(will e.g. be necessary for TStringList if one has code that abuses
Objects[]...).


That's indeed only useful if you then also require that all code not
written in non-ARC mode performs manual reference counting (like Apple
does). Having it as a possibility does not solve the problem of
unpredictability.


And how does Apple enforce this?


Nevertheless if one mixes refcounting and non-refcounting code with
care (maybe we can add optional warnings/hints when passing instances
between ARC and non-ARC code) it should work.


Then you have to give a hint/warning for every inherited call inside a
refcounted class that inherits from a non-reference-counted class,
because it passes the refcounted instance self to non-ARC code. It
completely destroys the concept of encapsulation that you shouldn't have
to know, and in some cases even can't know, what methods do with their
parameters or with self. Your code may work with one version of the
parent class and suddenly break with the next version. Being careful is
simply impossible with this way of working.


Self is weak anyway, thus not reference counted. Problems should thus 
only surface when passing Self to other code.
Note: currently in the branch Self is completely weak (remember the mail 
in which I commented regarding this?), but in the end the reference 
count should be changed if it is passed to a reference counted variable...


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Jonas Maebe]

On 29/10/14 17:50, Sven Barth wrote:
 On 29.10.2014 16:45, Jonas Maebe wrote:

 That's indeed only useful if you then also require that all code not
 written in non-ARC mode performs manual reference counting (like Apple
 does). Having it as a possibility does not solve the problem of
 unpredictability.
 
 And how does Apple enforce this?

Objective-C classes were reference counted from the start. Initially
they only supported manual reference counting. As a result, all existing
code already contained all reference counting operations. Later on they
added support for a garbage collected mode (in which the manual
reference counting operations became no-ops), and then they deprecated
it and moved to ARC (since garbage collection also required annotations
such as weak, this did not really require big if any source code
changes in that case; code with manual reference counting can still be
compiled without ARC).

It's different for us, where we have a very large existing code base
that does not use reference counting at all nor was written with
reference counting in mind.

 Self is weak anyway, thus not reference counted.

True, I forgot about it.

 Problems should thus
 only surface when passing Self to other code.

And in case a routine has class instance parameters and passes them on
to an inherited call.

 Note: currently in the branch Self is completely weak (remember the mail
 in which I commented regarding this?), but in the end the reference
 count should be changed if it is passed to a reference counted variable...

Indeed.


Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

Am 27.10.2014 23:41 schrieb Boian Mitov mi...@mitov.com:

 Well... we may differ on this one. I absolutely love attributes, but I
guess that is just me :-D .
 I think attributes are the greatest thing that has happened to Delphi
ever, I just wish they ware not so limited. Attributes allowed us to cut
3/4 of our code base. You can't beat that easily.

Let me clarify: I have nothing against the concept of attributes, I just
dislike the syntax and the introduction of attributes that influence
compiler behavior.

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Michael Schnell]

On 10/27/2014 10:44 PM, Boian Mitov wrote:
In general the C/C++ notion of doing as little in the language as 
possible, and as much in library has worked very well for it over the 
years.
Yes, pluggable languages concept has existed at least since C ;-) . I 
agree, and as I said has worked well.
I just took a look at C++ Threading Building Blocks (TBB - 
http://en.wikipedia.org/wiki/Threading_Building_Blocks) that seemingly 
woks along these lines and provides MultiThread / MultiCore support 
stuff like parallel for. Something like this would be great for fpc, 
as well but of course is not due to be discussed right here.


-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Michael Schnell]

On 10/27/2014 05:17 PM, Hans-Peter Diettrich wrote:


Something like ShortString and AnsiString?

Only that ShortStrings can easily be avoided (AFAIK, no great 
performance advantage to use them) and hence are seldom used right now.


-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Michael Schnell]

On 10/27/2014 07:59 PM, Sven Barth wrote:


- in code that does not use ARC (modeswitch arc off - the default; 
or maybe better a local directive) all instance variables are 
considered weak


While I do have a vision what weak means here, can you give an exact 
description ?


-Michael

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Hans-Peter Diettrich]

Sven Barth schrieb:

Am 27.10.2014 21:00, schrieb Hans-Peter Diettrich:

Sven Barth schrieb:
Am 27.10.2014 17:20 schrieb Hans-Peter Diettrich 
drdiettri...@aol.com mailto:drdiettri...@aol.com:



  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.


Where would this matter? When TObject and TManagedObject are different 
(base) types, a direct assignment of references is impossible.
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.


Or all those classes (TStrings, TObjectList, TComponent, etc.) 
that somewhere take a TObject as parameter.


IMO containers play a different role in managed and unmanaged 
environments. E.g. an TObjectList.OwnsObjects property is useless with 
managed objects, and the circular owner/child and parent/child 
references in several persistent classes deserve special attention and 
handling, when used with managed objects. Similar considerations apply 
to strings - should TStrings contain AnsiStrings or UnicodeStrings, 
where despite their assignment compatibility the implicit conversions 
between both can consume much runtime.


For such reasons I'd prefer a separate environment (RTL...) for only 
managed and unmanaged objects, just like for AnsiString and 
UnicodeString. But in combination such options would end up in many 
different library versions, so that I do not really suggest such an 
implementation. My dream are distinct FPC/Lazarus versions, designed for 
compatibility with D7, D2009, Unicode, Mobile and whatever versions may 
show up in the future. Then it should be possible to freeze the old 
versions with all bugs fixed, and new features will be added only to 
newer versions; this would eliminate all beforementioned problems, 
resulting from mixing features of different Delphi versions.


IMO Delphi versions don't offer backwards compatibility for good 
reasons, instead a purchased licencse allows to *also* use all older 
versions, down to D7. What I'm missing here are bugfixes, because the 
development of older versions is almost stopped as soon as a new version 
is distributed. Known bugs are mostly fixed only in newer versions, 
which introduce new bugs and features at the same time - good for sales 
but bad for the customers. Since FPC/Lazarus are open source, user 
groups may offer continued support for their preferred version(s), by 
backporting bugfixes into these versions.




What do you mean with virtual counting methods?


Overriding these methods can enable/disable refcounting for a class, 
and all classes derived from it. The default then can be to do nothing 
(no counting).
But then it's the same reference counting as the COM one, because 
without the COM reference counting those virtual methods would not be 
called.


So you prefer to inline these methods?
Now I understand why you want refcounting fully handled at compile time...

DoDi

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Hans-Peter Diettrich]

Boian Mitov schrieb:
In general the C/C++ notion of doing as little in the language as 
possible, and as much in library has worked very well for it over the 
years.
Yes, pluggable languages concept has existed at least since C ;-) . I 
agree, and as I said has worked well.


AFAIR such languages lack compatibility with themselves, as soon as 
projects start using their private extensions. Then no project can 
borrow parts (libraries...) from other projects, in the worst case.


DoDi

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Hans-Peter Diettrich]

Sven Barth schrieb:
Am 27.10.2014 23:41 schrieb Boian Mitov mi...@mitov.com 
mailto:mi...@mitov.com:

 
  Well... we may differ on this one. I absolutely love attributes, but 
I guess that is just me :-D .
  I think attributes are the greatest thing that has happened to Delphi 
ever, I just wish they ware not so limited. Attributes allowed us to cut 
3/4 of our code base. You can't beat that easily.


Let me clarify: I have nothing against the concept of attributes, I just 
dislike the syntax and the introduction of attributes that influence 
compiler behavior.


+1

DoDi

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Boian Mitov]

Hmm... it never happened to C/C++.
It seems to work well there.
C# also seems to be doing well...

With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Hans-Peter Diettrich 
Sent: Tuesday, October 28, 2014 2:08 AM 
To: FPC developers' list 
Subject: Re: [fpc-devel] Proof of Concept ARC implementation 

AFAIR such languages lack compatibility with themselves, as soon as 
projects start using their private extensions. Then no project can 
borrow parts (libraries...) from other projects, in the worst case.


DoDi

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[ListMember]

On 2014-10-27 00:00, Sven Barth wrote:

On 26.10.2014 12:17, Kostas Michalopoulos wrote:

On Sun, Oct 26, 2014 at 8:32 AM, Sven Barth pascaldra...@googlemail.com
mailto:pascaldra...@googlemail.com wrote:

Definitely not. We are in Pascal and there such directives are
placed afterwards.

how about these:

1) 'record' --- '*packed* *record*'
2) AVariable: Integer *absolute**AnotherVariable*.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Michael Van Canneyt]

On Mon, 27 Oct 2014, ListMember wrote:


On 2014-10-27 00:00, Sven Barth wrote:
  On 26.10.2014 12:17, Kostas Michalopoulos wrote:
On Sun, Oct 26, 2014 at 8:32 AM, Sven Barth 
pascaldra...@googlemail.com
mailto:pascaldra...@googlemail.com wrote:

    Definitely not. We are in Pascal and there such directives are
    placed afterwards.

how about these:

1) 'record' --- 'packed record'
2) AVariable: Integer absolute AnotherVariable.


Weak is a modifier, just as static, cdecl, external etc.

In Pascal, modifiers are placed after the thing they modify.

'absolute' modifies AVariable. That just confirms the above rule.

Michael.___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[ListMember]

On 2014-10-27 09:39, Michael Van Canneyt wrote:



On Mon, 27 Oct 2014, ListMember wrote:


On 2014-10-27 00:00, Sven Barth wrote:
  On 26.10.2014 12:17, Kostas Michalopoulos wrote:
On Sun, Oct 26, 2014 at 8:32 AM, Sven Barth 
pascaldra...@googlemail.com

mailto:pascaldra...@googlemail.com wrote:

Definitely not. We are in Pascal and there such 
directives are

placed afterwards.

how about these:

1) 'record' --- 'packed record'
2) AVariable: Integer absolute AnotherVariable.


Weak is a modifier, just as static, cdecl, external etc.

In Pascal, modifiers are placed after the thing they modify.

'absolute' modifies AVariable. That just confirms the above rule.


To me, 'weak' is modifying the type rather than the variable itself 
(much like 'packed record').


So, it would make more sense to me if we wrote it like

FVariable: weak TSometype;


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Michael Van Canneyt]

On Mon, 27 Oct 2014, ListMember wrote:


On 2014-10-27 09:39, Michael Van Canneyt wrote:



On Mon, 27 Oct 2014, ListMember wrote:


On 2014-10-27 00:00, Sven Barth wrote:
  On 26.10.2014 12:17, Kostas Michalopoulos wrote:
On Sun, Oct 26, 2014 at 8:32 AM, Sven Barth 
pascaldra...@googlemail.com

mailto:pascaldra...@googlemail.com wrote:

Definitely not. We are in Pascal and there such directives 
are

placed afterwards.

how about these:

1) 'record' --- 'packed record'
2) AVariable: Integer absolute AnotherVariable.


Weak is a modifier, just as static, cdecl, external etc.

In Pascal, modifiers are placed after the thing they modify.

'absolute' modifies AVariable. That just confirms the above rule.


To me, 'weak' is modifying the type rather than the variable itself (much 
like 'packed record').


That is a wrong way of thinking, because the type itself is not modified at all.
The behaviour of the variable is modified.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Nikolai Zhubr]

Hello Sven!

25.10.2014 0:23, Sven Barth:

Hello together!

I've now finished my Proof of Concept ARC implementation which is based
on the RFC I published a few weeks back:

[...]

Could you please elaborate a bit on what will happen to cyclic 
references? Is there autodetection in place already? And then, will it 
be usable for managing of e.g. 100M-long 2-way linked list?


Thanks.
Nikolai
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

On 27.10.2014 11:12, Nikolai Zhubr wrote:

Hello Sven!

25.10.2014 0:23, Sven Barth:

Hello together!

I've now finished my Proof of Concept ARC implementation which is based
on the RFC I published a few weeks back:

[...]

Could you please elaborate a bit on what will happen to cyclic
references? Is there autodetection in place already? And then, will it
be usable for managing of e.g. 100M-long 2-way linked list?


Cycles need to be manually handled currently by declaring some 
participants of the cycle as weak.
Another possiblity would be DoDi's suggestion to implement a finalizer 
(e.g. Delphi's DisposeOf) which would force the instance to destroy 
itself, though that would come with its own set of problems...
A third possiblity would be to implement a cycle detector in the 
decrement helper, but I haven't come around that for now as I wanted to 
get a first rough implementation out to you all ;)


Yours,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[hinstance]

In my opinion, such thing as cycle detector would be an unnecessary 
complication; however I have not studied the subject in depth therefore not sure

27.10.2014, 13:10, Sven Barth pascaldra...@googlemail.com:
 On 27.10.2014 11:12, Nikolai Zhubr wrote:
  Hello Sven!

  25.10.2014 0:23, Sven Barth:
  Hello together!

  I've now finished my Proof of Concept ARC implementation which is based
  on the RFC I published a few weeks back:
  [...]

  Could you please elaborate a bit on what will happen to cyclic
  references? Is there autodetection in place already? And then, will it
  be usable for managing of e.g. 100M-long 2-way linked list?

 Cycles need to be manually handled currently by declaring some
 participants of the cycle as weak.
 Another possiblity would be DoDi's suggestion to implement a finalizer
 (e.g. Delphi's DisposeOf) which would force the instance to destroy
 itself, though that would come with its own set of problems...
 A third possiblity would be to implement a cycle detector in the
 decrement helper, but I haven't come around that for now as I wanted to
 get a first rough implementation out to you all ;)

 Yours,
 Sven
 ___
 fpc-devel maillist  -  fpc-devel@lists.freepascal.org
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Jonas Maebe]

On 27 Oct 2014, at 11:10, Sven Barth wrote:

A third possiblity would be to implement a cycle detector in the  
decrement helper, but I haven't come around that for now as I wanted  
to get a first rough implementation out to you all ;)


I think that a cycle detector should be an independent component, just  
like heaptrc is an independent add-on to detect memory problems in  
regular programs.


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.


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).



Jonas

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Michael Schnell]

On 10/27/2014 11:26 AM, Jonas Maebe wrote:



I think that a cycle detector should be an independent component, just 
like heaptrc is an independent add-on to detect memory problems in 
regular programs.


So you suggest cyclic references should be forbidden (erroneous 
programming technique). Are they ?




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.


So there simply would be a ref-counted variant of TObject you can 
inherit from use as an option ?


-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Michael Schnell]

On 10/27/2014 11:26 AM, Jonas Maebe wrote:

 (e.g. suppose that inherited method inserts self into a linked list).

Or using TList with it ?

Would we need an alternate TList for ref-counted objects ?

-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[hinstance]

I think we should just roll out this feature to FPC trunk and let people test 
it; so those who are interested in it would test it and detect potential 
problems in practice rather than in thought experiments

27.10.2014, 13:35, Michael Schnell mschn...@lumino.de:
 On 10/27/2014 11:26 AM, Jonas Maebe wrote:
   (e.g. suppose that inherited method inserts self into a linked list).

 Or using TList with it ?

 Would we need an alternate TList for ref-counted objects ?

 -Michael
 ___
 fpc-devel maillist  -  fpc-devel@lists.freepascal.org
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Kostas Michalopoulos]

On Mon, Oct 27, 2014 at 11:32 AM, Michael Schnell mschn...@lumino.de
wrote:


 So you suggest cyclic references should be forbidden (erroneous
 programming technique). Are they ?


IMO if a program takes care to avoid cyclic references (with a heaptrc-like
unit to find such cases), it shouldn't pay for the overhead that a detector
would have. Of course i'd make that a compiler directive (or some global
flag) since others may not care.

@Sven:
TBH i don't feel that strongly (heh) about the syntax. It just looks weird
to me compared to other keyword usage in Free Pascal. If at least there was
a semicolon after the type it may look more consistent (after all, cdecl,
extern, etc are placed after a semicolon). F.e.

Foo: TFoo; weak;

But that probably wont work well with function arguments. After all there
aren't cdecl, extern, static, etc function arguments.

Is there any other such use of a keyword? I think it is a bad idea to
introduce a new keyword placement if there isn't already one since it
breaks consistency (all those other keywords are placed in front of the
type name whereas this special one is placed after).
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Marco van de Voort]

In our previous episode, Kostas Michalopoulos said:
  I think it is a bad idea to
 introduce a new keyword placement if there isn't already one since it
 breaks consistency (all those other keywords are placed in front of the
 type name whereas this special one is placed after).

There are multiple existing ones already see  e.g. 
http://www.freepascal.org/docs-html/ref/refse21.html
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Michael Van Canneyt]

On Mon, 27 Oct 2014, Kostas Michalopoulos wrote:



On Mon, Oct 27, 2014 at 11:32 AM, Michael Schnell mschn...@lumino.de wrote:

  So you suggest cyclic references should be forbidden (erroneous 
programming technique). Are they ?


IMO if a program takes care to avoid cyclic references (with a heaptrc-like 
unit to find such cases), it shouldn't pay for the overhead that a detector 
would have. Of course i'd
make that a compiler directive (or some global flag) since others may not care.

@Sven:
TBH i don't feel that strongly (heh) about the syntax. It just looks weird to 
me compared to other keyword usage in Free Pascal. If at least there was a 
semicolon after the type
it may look more consistent (after all, cdecl, extern, etc are placed after a 
semicolon). F.e.

Foo: TFoo; weak;

But that probably wont work well with function arguments. After all there aren't cdecl, 
extern, static, etc function arguments.

Is there any other such use of a keyword? I think it is a bad idea to introduce 
a new keyword placement if there isn't already one since it breaks consistency 
(all those other
keywords are placed in front of the type name whereas this special one is 
placed after).


as far as I can see, the proposal of Sven is perfectly in line with existing 
constructs and does not break consistency.

var
  a : something deprecated ; cdecl; external 'x';

Fields in classes:

  aa : integer implementation; static;

etc. Modifiers are always placed after the thing they modify.

Reference counting behaviour for function arguments is already controlled through const, var and out, 
so I don't think a new keyword needs to be used for them.


Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Michael Van Canneyt]

On Mon, 27 Oct 2014, Michael Van Canneyt wrote:




On Mon, 27 Oct 2014, Kostas Michalopoulos wrote:



On Mon, Oct 27, 2014 at 11:32 AM, Michael Schnell mschn...@lumino.de 
wrote:


  So you suggest cyclic references should be forbidden (erroneous 
programming technique). Are they ?



IMO if a program takes care to avoid cyclic references (with a heaptrc-like 
unit to find such cases), it shouldn't pay for the overhead that a detector 
would have. Of course i'd
make that a compiler directive (or some global flag) since others may not 
care.


@Sven:
TBH i don't feel that strongly (heh) about the syntax. It just looks weird 
to me compared to other keyword usage in Free Pascal. If at least there was 
a semicolon after the type
it may look more consistent (after all, cdecl, extern, etc are placed after 
a semicolon). F.e.


Foo: TFoo; weak;

But that probably wont work well with function arguments. After all there 
aren't cdecl, extern, static, etc function arguments.


Is there any other such use of a keyword? I think it is a bad idea to 
introduce a new keyword placement if there isn't already one since it 
breaks consistency (all those other
keywords are placed in front of the type name whereas this special one is 
placed after).


as far as I can see, the proposal of Sven is perfectly in line with existing 
constructs and does not break consistency.


var
 a : something deprecated ; cdecl; external 'x';

Fields in classes:

 aa : integer implementation; static;


That should have been
  aa : integer unimplemented; static;

Anyway, see e.g.
http://www.freepascal.org/docs-html/ref/refse5.html#x17-160001.5

So Sven is not deviating from existing practices.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Michael Schnell]

On 10/27/2014 11:37 AM, hinsta...@yandex.ru wrote:

I think we should just roll out this feature to FPC trunk and let people test 
it; so those who are interested in it would test it and detect potential 
problems in practice rather than in thought experiments


Hmm.

The potential TList problem to me seems a little bit similar to what 
Embarcadero (IMHO frivolously) did with the new Strings.


The List Classes (TStrings siblings) force a certain encoding. You can 
use them to store differently encoded strings but this will force very 
expensive conversions.  You of course could use (i.e. do)  TStrings work 
alikes for  different encoding, (separately for all might need), but the 
multiple brands of the String type introduce a huge PITA.


And fpc seems to be forced to blindly follow.

Here we might get two incompatible brands of the TObject class.

This might ask for some thinking about the consequences.

-Michael




___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

Am 27.10.2014 11:26 schrieb Jonas Maebe jonas.ma...@elis.ugent.be:


 On 27 Oct 2014, at 11:10, Sven Barth wrote:

 A third possiblity would be to implement a cycle detector in the
decrement helper, but I haven't come around that for now as I wanted to get
a first rough implementation out to you all ;)


 I think that a cycle detector should be an independent component, just
like heaptrc is an independent add-on to detect memory problems in regular
programs.

My plan was to add this as a callback. Thus way one could use a collector
in a different thread or a synchronous one :)


 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.

 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).

That's why I implemented it like this for now so we could check on real
code whether there would be any problems instead of theorizing about it. :)
Afterall I said it's experimental and nowhere near final.

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[hinsta...@yandex.ru]

I tested it a bit; thoughts so far:1. generic and refcounted do not work well together: no matter how I arrange it, a class can't be both generic and refcounted, it causes the compiler to produce some internal error 2014092205.2. Lazarus CodeTools parser hates refcounted keyword, but can be fooled into ignoring it with if-defs27.10.2014, 16:15, "Sven Barth" pascaldra...@googlemail.com: Am 27.10.2014 11:37 schrieb hinsta...@yandex.ru: I think we should just roll out this feature to FPC trunk and let people test it; so those who are interested in it would test it and detect potential problems in practice rather than in thought experiments Then just checkout the branch I mentioned in my initial mail. It's implemented there and is not a thought experiment. I'm not going to commit this any time soon to trunk, because 1) there are too many open points and 2) trunk is preparing for release branching thus no new big features and especially not as critized ones as this. Regards, Sven , ___ fpc-devel maillist  -  fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

Am 27.10.2014 14:54 schrieb hinsta...@yandex.ru hinsta...@yandex.ru:

 I tested it a bit; thoughts so far:
 1. generic and refcounted do not work well together: no matter how I
arrange it, a class can't be both generic and refcounted, it causes the
compiler to produce some internal error 2014092205.

Oh, good to know. I'll take a look at that when I find the time :) (and
that internal error is one I added for that feature, so that's a good
sign as well ;) )

 2. Lazarus CodeTools parser hates refcounted keyword, but can be fooled
into ignoring it with if-defs

That's expected. It's a new (and experimental) feature after all ;)

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Kostas Michalopoulos]

On Mon, Oct 27, 2014 at 11:50 AM, Marco van de Voort mar...@stack.nl
wrote:

 There are multiple existing ones already see  e.g.
 http://www.freepascal.org/docs-html/ref/refse21.html


But all of those (and absolute that Sven mentioned) are not used in
function parameters (something that i already mentioned). However if this
isn't needed for function parameters, then IMO it is fine. However i'd
rather have it with a semicolon like in cdecl, external, etc. IMO it
inconsistent when some use a semicolon and others do not.

In any case, as i said, this isn't really an important aspect.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Hans-Peter Diettrich]

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?

I agree that a *compiler-based* implementation, of a single TObject base 
class, would require two sets of libraries, starting with the RTL, else 
a mix of units with different object types cannot be avoided in an 
executable. And it would almost disallow to use DLLs, of a possibly 
different model.


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.


DoDi

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Kostas Michalopoulos]

On Mon, Oct 27, 2014 at 5:17 PM, Hans-Peter Diettrich drdiettri...@aol.com
wrote:

 Then the compiler can safely generate refcounting code for *all* objects
 and non-weak references, and the counting methods take care of required
 operations


Wouldn't that cause all objects to pay (both in terms of performance and
memory) for something that they don't use? IMO it is better to fully
disallow subclasses from introducing reference counting than force
functionality on objects that they don't need to use.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

Am 27.10.2014 17:19 schrieb Kostas Michalopoulos badsectorac...@gmail.com
:

 On Mon, Oct 27, 2014 at 11:50 AM, Marco van de Voort mar...@stack.nl
wrote:

 There are multiple existing ones already see  e.g.
http://www.freepascal.org/docs-html/ref/refse21.html


 But all of those (and absolute that Sven mentioned) are not used in
function parameters (something that i already mentioned). However if this
isn't needed for function parameters, then IMO it is fine. However i'd
rather have it with a semicolon like in cdecl, external, etc. IMO it
inconsistent when some use a semicolon and others do not.

A semicolon has the problem that you need to distinguish between it being a
modifier and a normal following identifier as not every keyword is a
keyword in every context (like for example read and write for
properties).

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

Am 27.10.2014 17:20 schrieb Hans-Peter Diettrich drdiettri...@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. Though Florian said that it shouldn't be that bad on today's
CPUs...
That said: if someone wants to test it one could add refcounted to
TObject (my code should(!) handle that correctly) and see what happens...
(of course there will be problems with circular references then)

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Michael Van Canneyt]

On Mon, 27 Oct 2014, Sven Barth wrote:



Am 27.10.2014 17:20 schrieb Hans-Peter Diettrich drdiettri...@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.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

Am 27.10.2014 16:23, schrieb Sven Barth:


Am 27.10.2014 14:54 schrieb hinsta...@yandex.ru 
mailto:hinsta...@yandex.ru hinsta...@yandex.ru 
mailto:hinsta...@yandex.ru:


 I tested it a bit; thoughts so far:
 1. generic and refcounted do not work well together: no matter how I 
arrange it, a class can't be both generic and refcounted, it causes 
the compiler to produce some internal error 2014092205.


Oh, good to know. I'll take a look at that when I find the time :) 
(and that internal error is one I added for that feature, so that's a 
good sign as well ;) )



Do you have an example? I tried this and it works:

=== code begin ===

program trefcounted;

{$mode objfpc}

type
  generic TTestT = class refcounted
  end;

  TTestLongInt = specialize TTestLongInt;

var
  t: TTestLongInt;
begin
  t := TTestLongInt.Create;
end.

=== code end ===

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

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 
drdiettri...@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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Boian Mitov]

 Hi Sven,

Great work!
I think it will be better if the weak is attribute as done in Delphi.
Attributes eliminate the need for introducing new keywords, to the already 
crowded OP keywords space.
Indeed week is a real attribute of a variable, and it makes more sense to be 
in attribute form. I am sure there will be even more attributes needed over 
time, and we should consider using the attribute form when it makes sense as 
in this case IMHO.


With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Sven Barth

Sent: Friday, October 24, 2014 2:23 PM
To: FPC developers' list
Subject: [fpc-devel] Proof of Concept ARC implementation

Hello together!

I've now finished my Proof of Concept ARC implementation which is based
on the RFC I published a few weeks back:
http://lists.freepascal.org/fpc-devel/2014-September/034263.html

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Marco van de Voort]

In our previous episode, Sven Barth said:
 Florian has written me an idea two weeks ago regarding the backwards 
 compatibility aspect (I won't argue the performance impact one ;) ):

Let's not christen this a step forward. So talking about backwards is
premature :-)

 - TObject and all descendants are reference counted (please no size and 
 performance discussion here)

No they are not. Of course they are not. That would be stupid.

 - in code that does not use ARC (modeswitch arc off - the default; or 
 maybe better a local directive) all instance variables are considered weak

But Tobject becomes bigger yet again. This is a *ROOT* class, the D2009
additions are already painful enough without voluntarily adding to it.

 With this approach there would be no change for legacy code 

So now this is the way to go forward by default. Hell no!
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Boian Mitov]

I second that. This is definitely a variable not a type modifier. The 
variable is the one that is weak.


With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Michael Van Canneyt

Sent: Monday, October 27, 2014 1:53 AM
To: FPC developers' list
Subject: Re: [fpc-devel] Proof of Concept ARC implementation



On Mon, 27 Oct 2014, ListMember wrote:



To me, 'weak' is modifying the type rather than the variable itself (much 
like 'packed record').


That is a wrong way of thinking, because the type itself is not modified at 
all.

The behaviour of the variable is modified.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel 


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Boian Mitov]

I second this. I would surely love to test drive it. I am also sure we will 
gather valuable experience from testing it.


With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: hinsta...@yandex.ru

Sent: Monday, October 27, 2014 3:37 AM
To: FPC developers' list
Subject: Re: [fpc-devel] Proof of Concept ARC implementation

I think we should just roll out this feature to FPC trunk and let people 
test it; so those who are interested in it would test it and detect 
potential problems in practice rather than in thought experiments


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Boian Mitov]

I think that we should start considering using attributes instead of 
introducing new keywords.
This should reduce the compatibility issues due to the new keywords, keep 
the language cleaner IMHO .
There are other benefits of doing it with attributes, but they are subject 
of another discussion ;-) .


With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Marco van de Voort

Sent: Monday, October 27, 2014 3:50 AM
To: FPC developers' list
Subject: Re: [fpc-devel] Proof of Concept ARC implementation

In our previous episode, Kostas Michalopoulos said:

 I think it is a bad idea to
introduce a new keyword placement if there isn't already one since it
breaks consistency (all those other keywords are placed in front of the
type name whereas this special one is placed after).


There are multiple existing ones already see  e.g. 
http://www.freepascal.org/docs-html/ref/refse21.html

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel 


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Marco van de Voort]

In our previous episode, Boian Mitov said:
 I think that we should start considering using attributes instead of 
 introducing new keywords.
 This should reduce the compatibility issues due to the new keywords, keep 
 the language cleaner IMHO.

No, they just move the potential conflicts from modifiers to attributes
namespace IMHO.  Nothing fundamental solved.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Boian Mitov]

Except attributes can't be confused with variables ;-).
And the other benefit I did not mentioned earlier, a lot of the attributes 
(if not all) can actually be implemented as compiler extending libraries ;-) 
.


With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Marco van de Voort

Sent: Monday, October 27, 2014 1:17 PM
To: FPC developers' list
Subject: Re: [fpc-devel] Proof of Concept ARC implementation

In our previous episode, Boian Mitov said:

I think that we should start considering using attributes instead of
introducing new keywords.
This should reduce the compatibility issues due to the new keywords, keep
the language cleaner IMHO.


No, they just move the potential conflicts from modifiers to attributes
namespace IMHO.  Nothing fundamental solved.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel 


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Boian Mitov]

As for 2. this is example where attribute could have helped ;-) . Just another 
argument in favor of attributes vs. new keywords ;-) .

With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---

From: hinsta...@yandex.ru 
Sent: Monday, October 27, 2014 6:48 AM
To: FPC developers' list 
Subject: Re: [fpc-devel] Proof of Concept ARC implementation

I tested it a bit; thoughts so far:
1. generic and refcounted do not work well together: no matter how I arrange 
it, a class can't be both generic and refcounted, it causes the compiler to 
produce some internal error 2014092205.
2. Lazarus CodeTools parser hates refcounted keyword, but can be fooled into 
ignoring it with if-defs


27.10.2014, 16:15, Sven Barth pascaldra...@googlemail.com:

  Am 27.10.2014 11:37 schrieb hinsta...@yandex.ru:

I think we should just roll out this feature to FPC trunk and let people 
test it; so those who are interested in it would test it and detect potential 
problems in practice rather than in thought experiments
  Then just checkout the branch I mentioned in my initial mail. It's 
implemented there and is not a thought experiment. I'm not going to commit this 
any time soon to trunk, because 1) there are too many open points and 2) trunk 
is preparing for release branching thus no new big features and especially not 
as critized ones as this.

  Regards,
  Sven
  ,

  ___
  fpc-devel maillist  -  fpc-devel@lists.freepascal.org
   http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Marco van de Voort]

In our previous episode, Boian Mitov said:
 Except attributes can't be confused with variables ;-).

The variables can't be confused with attributes.

Attributes are only useful in addition to an established languages, and as
extensions/implementation specific parts (so that the simpler parsers can
afford to ignore them).

As soon as you have two equal implementations like Delphi and FPC adding to
them independently, you are back to square one.

 And the other benefit I did not mentioned earlier, a lot of the attributes 
 (if not all) can actually be implemented as compiler extending libraries ;-) 

The only advantage of attributes is that you can skip unknown ones at the
expense of terser syntax.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Hans-Peter Diettrich]

Sven Barth schrieb:
Am 27.10.2014 17:20 schrieb Hans-Peter Diettrich drdiettri...@aol.com 
mailto:drdiettri...@aol.com:



  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.


Where would this matter? When TObject and TManagedObject are different 
(base) types, a direct assignment of references is impossible.




What do you mean with virtual counting methods?


Overriding these methods can enable/disable refcounting for a class, and 
all classes derived from it. The default then can be to do nothing (no 
counting).


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. Though Florian said that it shouldn't be that bad on 
today's CPUs...


Did you ever benchmark your model?

That said: if someone wants to test it one could add refcounted to 
TObject (my code should(!) handle that correctly) and see what 
happens... (of course there will be problems with circular references then)


Fine :-)

DoDi

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Hans-Peter Diettrich]

Kostas Michalopoulos schrieb:
On Mon, Oct 27, 2014 at 5:17 PM, Hans-Peter Diettrich 
drdiettri...@aol.com mailto:drdiettri...@aol.com wrote:


Then the compiler can safely generate refcounting code for *all*
objects and non-weak references, and the counting methods take care
of required operations


Wouldn't that cause all objects to pay (both in terms of performance 
and memory) for something that they don't use?


Right, that's why I suggest to keep both models separate. But the real 
runtime impact has to be benchmarked - it may be as low as with other 
managed types (AnsiString...), where nobody has complaints. Memory usage 
(4 bytes per object) should not matter, Delphi accepts it just for 
mobile devices!


IMO it is better to fully 
disallow subclasses from introducing reference counting than force 
functionality on objects that they don't need to use.


It *looks* better, but has several issues.

DoDi

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Hans-Peter Diettrich]

Sven Barth schrieb:

A semicolon has the problem that you need to distinguish between it 
being a modifier and a normal following identifier as not every keyword 
is a keyword in every context (like for example read and write for 
properties).


In this discussion I almost miss the elementary distinction between 
keywords (reserved words) and directives. Unlike keywords, directives 
are context sensitive and can be used as identifiers in all other 
places. That's why directives should *follow* identifiers, never precede 
them.


The semicolon usage is not well designed in Delphi, additional 
(intermediate) semicolons are not required and should be banned. Then 
the parser can continue to search for directives until the end of an 
applicable construct (declaration...) is found, which may be a semicolon 
or something else (comma, parenthesis...), depending on the construct 
syntax.


DoDi

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Boian Mitov]

Well... since attributes can be implemented in compiler extending library, 
then attributes can be enabled/disabled just by adding a unit ;-) .

That can't be said for new keywords.
I think library extension of the compiler is a better option that having a 
bunch of switch directives.

This also allows users easily to customize the compiler for their needs.
Now I know the concept for compiler being expanded/modified via library is 
probably a new one, but .NET already has introduced elements of this years 
ago, and seems to work well for them ;-) .


With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Marco van de Voort

Sent: Monday, October 27, 2014 1:42 PM
To: FPC developers' list
Subject: Re: [fpc-devel] Proof of Concept ARC implementation

In our previous episode, Boian Mitov said:

Except attributes can't be confused with variables ;-).


The variables can't be confused with attributes.

Attributes are only useful in addition to an established languages, and as
extensions/implementation specific parts (so that the simpler parsers can
afford to ignore them).

As soon as you have two equal implementations like Delphi and FPC adding to
them independently, you are back to square one.


And the other benefit I did not mentioned earlier, a lot of the attributes
(if not all) can actually be implemented as compiler extending libraries 
;-)


The only advantage of attributes is that you can skip unknown ones at the
expense of terser syntax.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel 


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel