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



--- Comment #70 from nfxjfg@gmail.com 2010-08-24 01:40:52 PDT ---
Created an attachment (id=738)
experiment: use ClassInfo to get bitmask for object allocations

objbitmask.patch is a patch on top of tango_precise_gc.patch, which makes storing the pointer bitmap inline unnecessary. Instead, it assumes that all memory blocks flagged with BlkAttr.FINALIZE are D objects, and uses their ClassInfo to get the bitmask. Seems to be slightly slower, but also reduces space overhead.

-- 
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 #700 is|0                           |1
           obsolete|                            |


--- Comment #71 from nfxjfg@gmail.com 2010-08-24 06:26:56 PDT ---
Created an attachment (id=739)
D1 - patch for dmd for creating pointer bitmasks

don't emit pointer maps for NO_SCAN types (breaks the test program pm.d
included in the other post)

-- 
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 #739 is|0                           |1
           obsolete|                            |


--- Comment #72 from nfxjfg@gmail.com 2010-09-09 06:36:26 PDT ---
Created an attachment (id=751)
D1 - patch for dmd for creating pointer bitmasks

-- 
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 #737 is|0                           |1
           obsolete|                            |


--- Comment #73 from nfxjfg@gmail.com 2010-09-09 06:37:13 PDT ---
Created an attachment (id=752)
D1 - patch for Tango's runtime to enable precise GC scanning

-- 
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 #74 from nfxjfg@gmail.com 2010-09-09 06:41:46 PDT ---
Created an attachment (id=753)
dmd: enable precise scanning for AAs

AAs are special because they use some runtime mechanism. dmd didn't allow precise scanning because not all type information was available (usually only the key).

This patch completely changes the runtime interface for AAs in order to allow precise scanning. It also does much much more. (For example I didn't like that dmd's runtime interface was so incredibly whacky, such as passing values of arbitrary runtime type per vararg, and expecting the value next to the argument before on the stack. Walter probably has to change this anyway for the dmd 64 bit port...)

The patched dmd is backwards compatible and compiles Tango svn just fine. The patched Tango tells dmd to use the new ABI by declaring a magical member variable somewhere in object.di.

-- 
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 #75 from nfxjfg@gmail.com 2010-09-09 06:43:43 PDT ---
Created an attachment (id=754)
tango: enable precise scanning for AAs

This is the Tango patch that goes with the dmd patch (attachment 753). The AA implementation is duplicated because the Tango patch is as well compatible with an unpatched dmd. An unpatched dmd will compile the "old" AA implementation instead of the new one.

-- 
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 #488 is|0                           |1
           obsolete|                            |


--- Comment #76 from nfxjfg@gmail.com 2010-09-09 06:45:13 PDT ---
(From update of attachment 488)
marking dsimcha's patches as obsolete because there are way too many
attachments already, and it seems it's not going to be used (even less than my
patches anyway)

-- 
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 #77 from nfxjfg@gmail.com 2010-09-15 02:22:03 PDT ---
There's a small bug in the memory clearing in mallocNoSync(), that could cause
memory leaks. Will post patch on request (nobody is using this anyway, right?).

Also, I found out that that SENTINEL is dead code. Uncommenting the "debug = SENTINEL;" line on start of gcx.d will not include the code in "version(SENTINEL)" blocks, because "debug" identifiers and "version" identifiers live in different namespaces. Makes me wonder, does anyone ever use the SENTINEL stuff for testing? Or just thought he'd be using it? Btw. someone said 16 bytes is the minimum alignment on OSX, so SENTINEL is broken there anyway.

-- 
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 #78 from Leandro Lucarella <llucax@gmail.com> 2010-09-15 05:51:08 PDT ---
(In reply to comment #77)
> There's a small bug in the memory clearing in mallocNoSync(), that could cause
> memory leaks. Will post patch on request (nobody is using this anyway, right?).

I ported it to my GC, so I'm interested in knowing what the bug is about to check if I have it too.

> Also, I found out that that SENTINEL is dead code. Uncommenting the "debug = SENTINEL;" line on start of gcx.d will not include the code in "version(SENTINEL)" blocks, because "debug" identifiers and "version" identifiers live in different namespaces. Makes me wonder, does anyone ever use the SENTINEL stuff for testing? Or just thought he'd be using it? Btw. someone said 16 bytes is the minimum alignment on OSX, so SENTINEL is broken there anyway.

Yeah, I think most of the versioned code is dead or close to it, because I doubt anybody test it. In my GC, which makes SENTINEL and MEMSTOMP run-time configurations, SENTINEL is broken and I didn't had the time to fix it yet. MEMSTOMP seems to work though.

-- 
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 #79 from nfxjfg@gmail.com 2010-09-15 06:33:39 PDT ---
Incremental patch:

diff --git a/tango/core/rt/gc/basic/gcx.d b/tango/core/rt/gc/basic/gcx.d index 93c8078..0f049d7 100644
--- a/tango/core/rt/gc/basic/gcx.d
+++ b/tango/core/rt/gc/basic/gcx.d
@@ -589,9 +589,9 @@ class GC
             // Return next item from free list
             gcx.bucket[bin] = (cast(List*)p).next;
             if( !(bits & BlkAttr.NO_SCAN) )
-                cstring.memset(p + size, 0, binsize[bin] - size);
+                cstring.memset(p + request_size, 0, capacity - request_size);
             //debug(PRINTF) printf("\tmalloc => %x\n", p);
-            debug (MEMSTOMP) cstring.memset(p, 0xF0, size);
+            debug (MEMSTOMP) cstring.memset(p, 0xF0, request_size);
         }
         else
         {

request_size is the size the user requested, while size is request_size + the pointermap's size. But size can be much smaller than memory block's real size (= capacity), so you really want to start clearing the memory right after the user data.

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