From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,19140af19dfa6e01 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-09-15 06:25:41 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.vmunix.org!fu-berlin.de!uni-berlin.de!tar-alcarin.cbb-automation.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: Ada 0Y plans for garbage collection? Date: Mon, 15 Sep 2003 15:33:30 +0200 Message-ID: References: <1127954.kcBZz6amlf@linux1.krischik.com> <3F60E747.40805@attbi.com> <3F62004D.6080704@attbi.com> NNTP-Posting-Host: tar-alcarin.cbb-automation.de (212.79.194.111) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 1063632340 26505598 212.79.194.111 (16 [77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:42520 Date: 2003-09-15T15:33:30+02:00 List-Id: On Fri, 12 Sep 2003 17:20:27 GMT, "Robert I. Eachus" wrote: >Dmitry A. Kazakov wrote: > >> But reference counting could be made much more easy and attractive if >> smart pointers have more light-weighted implementation than controlled >> types in generic packages. There are too many problems with that... > >Agreed, which is why you want to use a reference counted storage pool. >That way the count is stored with the object, and you only incur the >overhead when you create a new counted access value. Sounds great, really! It also solves nasty problems when a GC object is allocated on the stack, or with [unsupported] MI (:-)), because the reference count is no more a part of the object. But I suppose that this would require massive compiler support. If so, then why not to make access types to counted storage pool more transparent. At least when: 1. passing to a subprogram expecting the designated object. 2. dispatching. Named access types do not dispatch and define no primitive operations. I mean, to finally kick GC off, access types to reference counted objects should fully mimic the designated types. I.e. ".all" dropped, "null" is not a valid value etc. AFAIK access types with no "null" are planned (?), so dropping ".all" would be a logical consequence. Assignment should then just copy the reference. BUT, what about cloning [non-limited] objects when they are modified through a counted access, while the reference count is greater than 1? This is not so easy. >I've done this to create a pool of fixed sized objects. I keep >intending to rewrite it to support variable sized objects, but it is >always easier to create a fixed-sized reference-counted object with an >access value into the normal heap, and do explicit deallocation of that >object when the reference count reaches zero. > >Anyone want to work with me on a "standard" reference counted storage >pool for Ada 200Y? The storage pool will only be a couple of pages of >code. The real effort is in documenting it and providing examples of use. If I can help... >Or did you mean that the fact that the storage pool was a controlled >type was a problem? No. The problem was that the reference type has to be controlled. > I don't see that. Typically a program will create >a storage pool once and then just use it. The controlled overhead >really only comes into play if the storage pool is located inside a >nested procedure. --- Regards, Dmitry Kazakov www.dmitry-kazakov.de