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



--- Comment #100 from Andrei Alexandrescu <andrei@metalanguage.com> 2011-04-14 14:03:26 PDT ---
(In reply to comment #99)
> (In reply to comment #98)
> > The work on improving introspection should be done anyway.
> 
> The trouble with using runtime introspection for this is it'll be slow, and the scanning of data needs to be really fast.

I understand. That still means (and please correct me if I'm wrong) that the right place for specialized code should be at TypeInfo level. Also, I wonder if there's a need for a DSL. Wouldn't automatically-generated Typeinfo methods suffice?

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

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



--- Comment #101 from Walter Bright <bugzilla@digitalmars.com> 2011-04-14 14:46:52 PDT ---
(In reply to comment #96)
> Anyway, this problem is taking care of in the implementation by nfxjfg,

His bitmap implementation consists of two bitmaps, one for all pointers and the other for the subset that are ambiguous. There is one bit for each PTRSIZE bytes.

Although that works, the difficulty with it is the potentially large amount of static data this requires:

1. ambiguous pointers are pretty rare, so the second bitmap will be largely 0
2. non-pointer fields still consume space in the bitmaps
3. static arrays are fully fleshed out, so a large static array will have a
correspondingly large bitmap
4. large static arrays embedded in a struct with another pointer in them will
be fully fleshed out, even if there are no pointers in the array
5. there's no provision for reusing bitmaps for types embedded in aggregate
types, everything is repeated

This also applies at compile time, where one byte per pointer size for every type is allocated.

I think the static size is important - take a look at the .map file of a typical D app, and there's a lot of space consumed by the typeinfo data.

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

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



--- Comment #102 from Walter Bright <bugzilla@digitalmars.com> 2011-04-14 14:49:49 PDT ---
(In reply to comment #100)
> (In reply to comment #99)
> > (In reply to comment #98)
> > > The work on improving introspection should be done anyway.
> > 
> > The trouble with using runtime introspection for this is it'll be slow, and the scanning of data needs to be really fast.
> I understand. That still means (and please correct me if I'm wrong) that the right place for specialized code should be at TypeInfo level. Also, I wonder if there's a need for a DSL. Wouldn't automatically-generated Typeinfo methods suffice?

I don't really understand your comment. Are you saying the TypeInfo should do introspection at runtime to generate specialized data tables for the gc (obviously caching it so it is done only once per type)? This is certainly a possible approach.

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

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



--- Comment #103 from Andrei Alexandrescu <andrei@metalanguage.com> 2011-04-14 15:08:15 PDT ---
(In reply to comment #102)
> (In reply to comment #100)
> > (In reply to comment #99)
> > > (In reply to comment #98)
> > > > The work on improving introspection should be done anyway.
> > > 
> > > The trouble with using runtime introspection for this is it'll be slow, and the scanning of data needs to be really fast.
> > I understand. That still means (and please correct me if I'm wrong) that the right place for specialized code should be at TypeInfo level. Also, I wonder if there's a need for a DSL. Wouldn't automatically-generated Typeinfo methods suffice?
> 
> I don't really understand your comment. Are you saying the TypeInfo should do introspection at runtime to generate specialized data tables for the gc (obviously caching it so it is done only once per type)? This is certainly a possible approach.

I was thinking that the compiler could generate D code that does the scanning instead of us defining a DSL for that.

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

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



--- Comment #104 from Walter Bright <bugzilla@digitalmars.com> 2011-04-14 15:47:25 PDT ---
(In reply to comment #103)
> I was thinking that the compiler could generate D code that does the scanning instead of us defining a DSL for that.

That's a fascinating idea.

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

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



--- Comment #105 from Andrei Alexandrescu <andrei@metalanguage.com> 2011-04-14 16:00:24 PDT ---
(In reply to comment #104)
> (In reply to comment #103)
> > I was thinking that the compiler could generate D code that does the scanning instead of us defining a DSL for that.
> 
> That's a fascinating idea.

I think it's just a simple idea. You do generate code for constructors etc. already...

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

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



--- Comment #106 from Walter Bright <bugzilla@digitalmars.com> 2011-04-14 16:25:11 PDT ---
(In reply to comment #105)
> I think it's just a simple idea. You do generate code for constructors etc. already...

The main challenge would be finding the fastest interface for it with the gc.

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

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


Vladimir <thecybershadow@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thecybershadow@gmail.com


--- Comment #107 from Vladimir <thecybershadow@gmail.com> 2011-04-14 16:36:48 PDT ---
Am I the only one who is concerned with the performance implications of complicating the garbage collector any further, especially considering that precise heap scanning will not completely solve any problems?

> As far as the (small) drop in mean performance, I say "who cares?"

*I* care. I already have solutions for false pointer problems. If I'm going to write an action video game in D, I sure as hell don't want the GC taking its sweet time while the player gets fragged due to "screen lag".

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

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



--- Comment #108 from David Simcha <dsimcha@yahoo.com> 2011-04-14 17:08:48 PDT ---
(In reply to comment #107)
> Am I the only one who is concerned with the performance implications of complicating the garbage collector any further, especially considering that precise heap scanning will not completely solve any problems?
> 
> > As far as the (small) drop in mean performance, I say "who cares?"
> 
> *I* care. I already have solutions for false pointer problems. If I'm going to write an action video game in D, I sure as hell don't want the GC taking its sweet time while the player gets fragged due to "screen lag".

That's why heap allocations in real-time code are a bad idea.  This patch won't change that.

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

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



--- Comment #109 from Vladimir <thecybershadow@gmail.com> 2011-04-14 17:11:02 PDT ---
(In reply to comment #108)
> That's why heap allocations in real-time code are a bad idea.  This patch won't change that.

Um, no, the GC is currently fast enough to scan a small heap within the timeframe of a video frame.

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