RFC: reference counted Throwable
Dmitry Olshansky via Digitalmars-d
digitalmars-d at puremagic.com
Sat Sep 20 01:06:52 PDT 2014
19-Sep-2014 19:32, Andrei Alexandrescu пишет:
> 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.
>
All good, it wasn't a good idea to have GC-ed exceptions in the first
place (It's a truly rare thing to have cycles of exceptions). It doesn'
t matter GC or @nogc - this must go.
Speaking of RC-ed Throwable - why adding a switch? Just make a
transition in 2 steps - all exceptions inherit from RCObject (but stay
essentially GC-ed), then hack compiler to perform ARC on RCObject
descendants (maybe even with GC.malloc/GC.free for starters, i.e. the
same heap). Then we can mess with custom allocation of these.
I can understand a transitory switch, say -exception-ongc for the
minority of folks that indeed DO rely on exceptions being GC and not
counted.
--
Dmitry Olshansky
More information about the Digitalmars-d
mailing list