RFC: reference counted Throwable

deadalnix via Digitalmars-d digitalmars-d at puremagic.com
Sat Sep 20 17:36:03 PDT 2014


On Friday, 19 September 2014 at 15:32:38 UTC, Andrei Alexandrescu
wrote:
> As discussed, having exception objects being GC-allocated is 
> clearly a large liability that we need to address. They prevent 
> otherwise careful functions from being @nogc so they affect 
> even apps that otherwise would be okay with a little litter 
> here and there.
>
> The Throwable hierarchy is somewhat separate from everything 
> else, which makes it a great starting point for investigating 
> an automated reference count approach. Here's what I'm thinking.
>
> First, there must be some compiler flag -nogc or something, 
> which triggers the RC exceptions. All modules of an application 
> must be compiled with this flag if it is to work (such that one 
> module can throw an exception caught by the other). Of course a 
> lot of refinement needs to be added here (what happens if one 
> tries to link modules built with and without -nogc, allowing 
> people to detect the flag programmatically by using 
> version(nogc) etc).
>
> If -nogc is passed, the compiler severs the inheritance 
> relationship between Throwable and Object, making it impossible 
> to convert a Throwable to an Object. From then henceforth, 
> Throwable and Object form a two-rooted forest. (In all 
> likelihood we'll later add an RCObject root that Throwable 
> inherits.)
>
> Whenever a reference to a Throwable is copied about, passed to 
> functions, the compiler inserts appropriately calls to e.g. 
> incRef and decRef. (Compiler may assume they cancel each other 
> for optimization purposes.) Implementation of these is up to 
> the runtime library. Null checking may be left to either the 
> compiler or the library (in the latter case, the functions must 
> be nonmember). However it seems the compiler may have an 
> advantage because it can elide some of these checks.
>
> Once we get this going, we should accumulate good experience 
> that we can later apply to generalizing this approach to more 
> objects. Also, if things go well we may as well define _always_ 
> (whether GC or not) Throwable to be reference counted; seems 
> like a good fit for all programs.
>
> Please chime in with thoughts.
>
>
> Andrei

I guess it is time to put isolated back on the table.

You can throw only isolated. When isolated goes out of scope
without being consumed, the island is blasted out of existence.


More information about the Digitalmars-d mailing list