[Issue 5057] std.variant.Algebraic-aware GC

d-bugmail at puremagic.com d-bugmail at puremagic.com
Tue Oct 9 19:57:59 PDT 2012


http://d.puremagic.com/issues/show_bug.cgi?id=5057



--- Comment #7 from Alex Rønne Petersen <alex at lycus.org> 2012-10-10 04:33:54 CEST ---
(In reply to comment #6)
> (In reply to comment #5)
> > Let us revisit this if it ever becomes a problem in practice; I very much doubt
> > it. At any rate, special-casing it in the GC is the wrong kind of design.
> > 
> > I'll also add that I'm against adding GC heap allocation to Variant/Algebraic
> > as this would severely slow down code that uses many instances of these types
> > for no good reason.
> 
> I agree that special casing for Algebraic is probably too much.
> 
> But GC precision is a problem, especially on 32 bit system. 

Absolutely.

> 
> And here I was not discussing about allocating an Algebraic on the heap, but
> the problems caused by putting references to heap-allocated things inside an
> Algebraic. So it's a problem shared by all unions. The idea of "onScan" is
> general, it's not a special case for Algebraic, it's usable to help the GC for
> all unions (but it's especially useful for Algebraic because it has a tag).

My comments about heap allocations were not directed at you, but at
nfxjfg at gmail.com.

One very trivial way that Algebraic can be made more GC friendly is by making
it inspect all types that it can represent - if none of them are
references/pointers, signal this to the GC accordingly.

It doesn't handle the case where a variant can have both non-GC'd and GC'd
types, but I think that this is very rare compared to variants with exclusively
GC'd types and variants with exclusively non-GC'd types.

> 
> Maybe I will open an enhancement request about all unions...

I imagine unions in general will be a pain for the new precise GC. But let's
wait and see how it handles this problem before we open another issue.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list