Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-other / 2014-10

Use of ARC

4 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Hans-Peter Diettrich

Let me start just another thread, to remove noise from fpc-devel. These are my opinions about the requirement and use of ARC in FPC:

1) ARC has been introduced in Delphi for *mobile* platforms (only), so a discussion of its impact on such (small) targets is useless. I'm not sure which requirements of such platforms make ARC inevitable or desireable, but I suspect that it's not only Delphi compatibility that suggests such a feature. We should know more about the Delphi rationale for adding ARC!

2) I'm not sure whether ARC will really simplify things, as opposed to traditional coding techniques. As long as Delphi restricts ARC to specific targets, I see no real pressure to implement ARC in FPC for *all* ) I don't think that ARC can be safely implemented at compiletime only. Every chance for zombies or premature destruction is a show stopper for every ARC implementation, or for ) Instead I'd vote for a dynamic implementation, as with Interfaces, by adding a refcount field and (virtual?) counting methods to TObject. This overhead should be acceptable, just like for other managed types (dynamic strings, arrays...). Then the compiler inserts calls to these methods whenever required, the rest is up to the actual instances.

3b) The counter field may be evitable, when the counting methods become virtual. Virtual methods require less memory, burdening the VMT only, than counter fields in every instance.

4) The real memory and runtime overhead, caused by virtual methods or other ARC requirements, should be benchmarked before continuing according discussions. There exists more overhead (implicit try-finally blocks...) related to managed objects.

5) I'd appreciate every chance to make ARC optional, be per installation, target or for specific projects. This will eliminate most overhead discussions, when nobody is *forced* to accept ARC related overhead; this suggests to me an according installation option, so that no copies of specialized libraries are ever required.

6) ARC can require slightly different code, like the use of DisposeOf instead of Free. That's why I'd keep ARC based code (and libraries) strictly separate from non-ARC code, in order to prevent possible problems from mixing code sources (shared and private libraries...).

6a) Library code (container classes...) should be checked for such possibly required differences. The need for duplicate libraries (RTL...) should be avoided as far as possible.

6b) Threads also should be checked for possible problems.

6c) Lazarus should be considerd as well!

7) Circular references are a known problem with ARC. Weak references and other constructs should be provided, in order to reduce the amount of code required to break such cycles.

42) I don't plan to implement my favored model myself (see #3). But I'm willing to assist with such an implementation, provided that some compiler gure spots the places where the compiler code must be updated. I'd assume that Sven's implementation already touched all these places, so that the rest should be doable with little assistance and efforts :-)

Just my 0.02€
DoDi

Reply by email

Mark Morgan Lloyd
to Hans-Peter Diettrich
Hans-Peter Diettrich wrote 5 lines
3a) Instead I'd vote for a dynamic implementation, as with Interfaces, by adding a refcount field and (virtual?) counting methods to TObject. This overhead should be acceptable, just like for other managed types (dynamic strings, arrays...). Then the compiler inserts calls to these methods whenever required, the rest is up to the actual instances.

Are you suggesting that no opportunity should be spared to review the existing implementation of e.g. strings and dynamic arrays and to unify them with a single underlying structure provided that can be done efficiently?

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

Reply by email

Hans-Peter Diettrich
to Mark Morgan Lloyd
Show quoted text 12 lines
Hans-Peter Diettrich wrote: > 3a) Instead I'd vote for a dynamic implementation, as with Interfaces, > by adding a refcount field and (virtual?) counting methods to TObject. > This overhead should be acceptable, just like for other managed types > (dynamic strings, arrays...). Then the compiler inserts calls to these > methods whenever required, the rest is up to the actual instances. Are you suggesting that no opportunity should be spared to review the existing implementation of e.g. strings and dynamic arrays and to unify them with a single underlying structure provided that can be done efficiently?

The implementation of the simple managed types is fine. But the implementation of refcounting for both TObject and Interfaces has different topics (polymorphism...), so that I'd assume that these can be handled in a very similar way. In detail the Interface refcounting *must* be modified when the underlaying objects become refcounted themselves, to prevent duplicate counting. Thanks for revealing this trouble source :-)

DoDi

Reply by email

Marco van de Voort
to Hans-Peter Diettrich: Let me start just another thread, to remove noise from fpc-devel. These are my opinions…

In our previous episode, Hans-Peter Diettrich said:

Show quoted text 12 lines
1) ARC has been introduced in Delphi for *mobile* platforms (only), so a discussion of its impact on such (small) targets is useless. I'm not sure which requirements of such platforms make ARC inevitable or desireable, but I suspect that it's not only Delphi compatibility that suggests such a feature. We should know more about the Delphi rationale for adding ARC! 2) I'm not sure whether ARC will really simplify things, as opposed to traditional coding techniques. As long as Delphi restricts ARC to specific targets, I see no real pressure to implement ARC in FPC for *all* think ARC is mostly driven by the Mac side of things, keep in mind that

Delphi mobile started as iOS only. I wouldn't start moving in that direction till there are clear signes that Embarcadero wishes to lift this to the general suite.

Show quoted text 8 lines
3) I don't think that ARC can be safely implemented at compiletime only. Every chance for zombies or premature destruction is a show stopper for every ARC implementation, or for ARC at all. 3a) Instead I'd vote for a dynamic implementation, as with Interfaces, by adding a refcount field and (virtual?) counting methods to TObject. This overhead should be acceptable, just like for other managed types (dynamic strings, arrays...).

Adding dynamic strings and arrays did not make older (short-) strings and static arrays obsolete or slower, so IMHO this is strange analogy.

Because that is the problem with integrating it deeply, there is no escape anymore from the overhead.

Personally if we must go that direction (which I'm definitely against, since I fail to see the point, both wrt direct benefits and delphi compatibility), it should be IFDEFed in the RTL, and work with a two RTL system and compiler switch.

IOW do it delphi compatible and have two independent versions :-)

Reply by email