[Issue 5057] std.variant.Algebraic-aware GC
http://d.puremagic.com/issues/show_bug.cgi?id=5057 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lycus.org Resolution||WONTFIX --- Comment #5 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:51:55 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: ---
[Issue 5057] std.variant.Algebraic-aware GC
http://d.puremagic.com/issues/show_bug.cgi?id=5057 --- Comment #6 from bearophile_h...@eml.cc 2012-10-09 19:28:00 PDT --- (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. 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: ---
[Issue 5057] std.variant.Algebraic-aware GC
http://d.puremagic.com/issues/show_bug.cgi?id=5057 --- Comment #7 from Alex R�nne Petersen a...@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 nfx...@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: ---
[Issue 5057] std.variant.Algebraic-aware GC
http://d.puremagic.com/issues/show_bug.cgi?id=5057 --- Comment #4 from nfx...@gmail.com 2010-10-22 05:12:09 PDT --- (In reply to comment #2) 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: ---
[Issue 5057] std.variant.Algebraic-aware GC
http://d.puremagic.com/issues/show_bug.cgi?id=5057 --- Comment #3 from bearophile_h...@eml.cc 2010-10-21 09:38:59 PDT --- 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: ---
[Issue 5057] std.variant.Algebraic-aware GC
http://d.puremagic.com/issues/show_bug.cgi?id=5057
nfx...@gmail.com changed:
What|Removed |Added
CC||nfx...@gmail.com
--- Comment #1 from nfx...@gmail.com 2010-10-15 09:04:26 PDT ---
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: ---
[Issue 5057] std.variant.Algebraic-aware GC
http://d.puremagic.com/issues/show_bug.cgi?id=5057
--- Comment #2 from bearophile_h...@eml.cc 2010-10-15 09:35:53 PDT ---
(In reply to comment #1)
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: ---
