RFC: reference counted Throwable
Andrei Alexandrescu via Digitalmars-d
digitalmars-d at puremagic.com
Fri Sep 19 08:32:38 PDT 2014
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
More information about the Digitalmars-d
mailing list