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



--- Comment #30 from Sean Kelly <sean@invisibleduck.org> 2010-07-21 07:21:06 PDT ---
Hm... I'd love to get this into D2, but the diffs are a bit large to apply by hand.  I don't suppose you'd be inclined to provide a D2 patch as well?  It should be pretty similar to the Tango patch.

-- 
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 #31 from Leandro Lucarella <llucax@gmail.com> 2010-07-21 08:38:06 PDT ---
(In reply to comment #30)
> Hm... I'd love to get this into D2, but the diffs are a bit large to apply by hand.  I don't suppose you'd be inclined to provide a D2 patch as well?  It should be pretty similar to the Tango patch.

I would be nice to split the patch in smaller changes too, because there are a couple of extra optimizations not related to the precise scanning (for example, making findPool() use a binary search, I was just about to implement the same optimization in my GC :). There are a few changes of structure not related to the patch too, which improves the code, but makes harder to port the patch to other GCs.

Thanks!

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


nfxjfg@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #689 is|0                           |1
           obsolete|                            |


--- Comment #32 from nfxjfg@gmail.com 2010-07-21 11:49:11 PDT ---
Created an attachment (id=692)
D1 - patch for dmd for creating pointer bitmasks

- don't use the dmd provided bit array type anymore to make the patch more 64
bit friendly
- slightly change PointerMap format

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


nfxjfg@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #681 is|0                           |1
           obsolete|                            |


--- Comment #33 from nfxjfg@gmail.com 2010-07-21 11:51:13 PDT ---
Created an attachment (id=693)
D1 - patch for Tango's runtime to enable precise GC scanning

-removed the unrelated optimization stuff such as doing a binary search for
pools (all that was backported from D2 to Tango to bring gcx.d on the same
level; original author was probably Walter)
- add some helper methods for manually building PointerMaps (unused/untested;
originally intended to deal with associative arrays)

-- 
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 #34 from nfxjfg@gmail.com 2010-07-21 11:57:02 PDT ---
I don't really use D2 (all my code is in D1). Porting it to D2 will require dealing with the recently added array append stuff. Not sure how hard that would be, but currently I have no intention doing the port myself.

Also note that the GC mark code is unoptimized. I'm not sure how much optimization potential there is, but my own attempts have been unsuccessful so far.

About the 64 bit issue: to me it looked like dmd can never cross compile, and if you want to compile it as 64 bit app, it must generate 64 bit code. Or is that wrong?

-- 
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 #35 from Leandro Lucarella <llucax@gmail.com> 2010-07-21 11:59:40 PDT ---
(In reply to comment #34)
> I don't really use D2 (all my code is in D1). Porting it to D2 will require dealing with the recently added array append stuff. Not sure how hard that would be, but currently I have no intention doing the port myself.
> 
> Also note that the GC mark code is unoptimized. I'm not sure how much optimization potential there is, but my own attempts have been unsuccessful so far.
> 
> About the 64 bit issue: to me it looked like dmd can never cross compile, and if you want to compile it as 64 bit app, it must generate 64 bit code. Or is that wrong?

I don't know how it should finally be, but right now, even if you compile DMD as a 64 bits app, it generates 32 bits code (I didn't even find any options to make it generate 64 bits code :).

-- 
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 #36 from nfxjfg@gmail.com 2010-07-21 12:05:08 PDT ---
I guess we will have to see how Walter's 64 bit port will look like.

-- 
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 #37 from Leandro Lucarella <llucax@gmail.com> 2010-07-22 17:54:38 PDT ---
BTW, I just realized that this type information scheme doesn't enable the GC to move data around (i.e. it doesn't open the door to moving collectors) since the distinction between *is* a pointer and *may be* a pointer is not present.

This difference is necessary for knowing when you can move things around, since a block pointed to by a *may be* a pointer should be pinned, because you can't update the word suspected to be a pointer (because in case is not, you are corrupting user's memory). Only block pointed to by *is* a pointer words are candidates for moving.

Maybe considering that this involves a change in the compiler, it would be a good opportunity to finally open the door to moving collectors. Unfortunately this means more type information is necessary. Maybe 2 bitmasks can be used, a "scan" mask (that can take over the NO_SCAN attribute) and a "pointer" mask. A word marked as "scan" (i.e. "scan" bit == 1) should be scanned but might be a pointer or not (like the current bitmask proposed in this patch); a word marked "pointer (i.e. "pointer bit == 1) is guaranteed to be a pointer and the GC is allowed to update it if the pointed to block is moved.

So a real pointer should have both scan and pointer set to 1 (yeah, scan is redundant, but I can't think of a better representation), and an union should have only scan set to 1. I don't know what to do with void* though, since is very common to use it as a "safe-buffer" instead of a real pointer array. The safe bet is to keep it only with the "scan" bit, I guess.

I didn't think a lot if this organization of the information is the best for the GC implementator, but it's simple and opens the door to experimentation, so I think it's better to have a possibility even when is not the better solution than not having anything; the interface can be refined in the future.

Since you are already playing with the compiler, do you think it's possible to change the compiler to provide this information?

-- 
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 #38 from Leandro Lucarella <llucax@gmail.com> 2010-07-22 19:26:36 PDT ---
If I'm understanding the patch right, I think I found a bug. At the end of
reallocNoSync():

+            if (psize < size ||             // if new size is bigger
+                psize > size * 2)           // or less than half
+            {
+                p2 = mallocNoSync(size, bits, bitMask);
+
+                psize -= bitMaskSize;
+                size -= bitMaskSize;


Shouldn't size and psize be updated before mallocNoSync() is called? Otherwise a block a word larger than needed would be allocated.

-- 
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 #39 from Leandro Lucarella <llucax@gmail.com> 2010-07-22 19:27:29 PDT ---
(In reply to comment #38)
> If I'm understanding the patch right, I think I found a bug. At the end of
> reallocNoSync():
> 
> +            if (psize < size ||             // if new size is bigger
> +                psize > size * 2)           // or less than half
> +            {
> +                p2 = mallocNoSync(size, bits, bitMask);
> +
> +                psize -= bitMaskSize;
> +                size -= bitMaskSize;
> 
> 
> Shouldn't size and psize be updated before mallocNoSync() is called? Otherwise a block a word larger than needed would be allocated.

Same for the code inside version (SENTINEL).

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