www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 5057] New: std.variant.Algebraic-aware GC

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5057

           Summary: std.variant.Algebraic-aware GC
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: druntime
        AssignedTo: sean invisibleduck.org
        ReportedBy: bearophile_hugs eml.cc



D has unions, and sometimes normal C-style unions are useful. But in many
situations when you have a union you also keep a tag that represents the type.
So in many of those situations you may use the tagged union of Phobos,
std.variant.Algebraic.

If std.variant.Algebraic implementation is good enough (currently it's
unfinished and not good enough yet) and its usage becomes a common D idiom when
a simple tagged union is necessary, then the D GC may be aware of it, and it
may read and use the tag of the Algebraic to know at runtime what the type is.
This may improves the GC precision a little.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 15 2010
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5057


nfxjfg gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nfxjfg gmail.com



The simplest way to implement this is not using that union trick and store all
data in a templated class like this:

class VariantStorage(T) {
  T data;
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 15 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5057






 The simplest way to implement this is not using that union trick and store all
 data in a templated class like this:
 
 class VariantStorage(T) {
   T data;
 }


I don't see how a class may replace an union.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 15 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5057




A more general solution it to add to D an optional standard method, that may be
named "onScan" or something else, that the garbage collection calls if present,
and returns information that the GC uses at runtime to know what contents to
follow, etc.

So a user-defined union may define such onScan(), that reads the instance tag
to say the GC what to do.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 21 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5057






 I don't see how a class may replace an union.


Variant/Algebraic has to store its data somewhere. Currently it uses some
horrible hack to store it inline of the struct. All problems would be solved
immediately by allocating a VariantStorage object on the heap instead to store
the data.

D2 already relies that much on heap allocation that this shouldn't be a
problem. Think of hidden memory allocation of closures, or consider bug 4397.

On the other hand, adding an onScan hook to the current GC would probably be a
big deal. Just think about recursive data structures: you have to honor nested
structs, static arrays, dynamic arrays. How would this be efficiently
implemented?

On the other hand, one could just agree to always store a TypeInfo which each
memory block, and let the compiler generate an optional noScan method.
Depending on the implementation details, this could be reasonably efficient,
but would take its toll on the common case; see discussion in issue 3463.

Anyway, this is probably a non-issue, because nobody would seriously consider
to use "Algebraic" for the same purpose as algebraic types usually are used in
functional programming languages. For that it just sucks too much. It would be
different if D would actually support such data types natively.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 22 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5057


Alex Rønne Petersen <alex lycus.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |alex lycus.org
         Resolution|                            |WONTFIX



CEST ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 09 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5057






 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. 

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).

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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 09 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5057




CEST ---




 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 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: -------
Oct 09 2012