Download Reference Manual
The Developer's Library for D
About Wiki Forums Source Search Contact

Ticket #1971 (closed defect: fixed)

Opened 9 years ago

Last modified 9 years ago

_d_arrayappend*() doesn't set the block attributes appropriately when allocating for the first time

Reported by: llucax Assigned to: community
Priority: major Milestone: 1.0
Component: Runtime Version: 0.99.9 Kai
Keywords: gc, array, append Cc: llucax

Description

This programs allocates the array without the NO_SCAN attribute:

void main()
{
    int[] a;
    a ~= 1;
}

So from that on, no matter how big the array gets, the GC will scan it on each collection.

The problem is _d_arrayappend*() functions are using attributes from the results of gc_query(), no matter if gc_query() didn't find the block (because, for example, the pointer was null because it was the first array allocation).

Attached is a patch for 0.99.9, but I guess it should apply to trunk too. In 0.99.9 LDC is the only compiler that is not affected because it doesn't use those functions (they are commented out). Looking at the trunk, it seems like one of them is uncommented, but the patch includes the commented code, so it should fix that too.

Attachments

arrayappend.patch (4.6 kB) - added by llucax on 08/12/10 01:07:08.
Patch agains Tango 0.99.9

Change History

08/12/10 01:07:08 changed by llucax

  • attachment arrayappend.patch added.

Patch agains Tango 0.99.9

08/12/10 01:08:05 changed by llucax

BTW, the patch is **not** tested using LDC nor GDC, but it's tested in DMD.

08/12/10 01:41:49 changed by llucax

These are some results comparing how many memory is marked as NO_SCAN before and after the bugfix:

Dil (http://code.google.com/p/dil/) generating Tango docs:

--- /tmp/pre.dil.txt    2010-08-11 22:34:46.700000101 -0300
+++ /tmp/post.dil.txt   2010-08-11 22:34:46.701000103 -0300
@@ -1,3 +1,3 @@
-Total requested: 7,374,661 objecs, 323,987,547 bytes [308.98MiB]
-       Scanned: 7,310,642 (99.13%) objecs, 317,016,671 bytes [302.33MiB] (97.85%)
-       Not scanned: 64,019 (0.87%) objecs, 6,970,876 bytes [6.65MiB] (2.15%)
+Total requested: 7,307,686 objecs, 322,411,081 bytes [307.48MiB]
+       Scanned: 6,675,124 (91.34%) objecs, 227,950,157 bytes [217.39MiB] (70.7%)
+       Not scanned: 632,562 (8.66%) objecs, 94,460,924 bytes [90.08MiB] (29.3%)

A test that basically append integers (http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=103563):

--- /tmp/pre.mcore.txt  2010-08-11 22:34:46.766000103 -0300
+++ /tmp/post.mcore.txt 2010-08-11 22:34:46.767000104 -0300
@@ -1,3 +1,3 @@
-Total requested: 379 objecs, 322,732,934 bytes [307.78MiB]
-       Scanned: 379 (100%) objecs, 322,732,934 bytes [307.78MiB] (100%)
-       Not scanned: 0 (0%) objecs, 0 bytes (0%)
+Total requested: 367 objecs, 320,666,378 bytes [305.81MiB]
+       Scanned: 8 (2.18%) objecs, 2,019 bytes [1.97KiB] (0%)
+       Not scanned: 359 (97.82%) objecs, 320,664,359 bytes [305.81MiB] (100%)

Other micro benchmarks (Dil is the only real-life program I have to test) have no changes.

(follow-up: ↓ 4 ) 08/14/10 10:46:51 changed by mwarning

Can you make a patch for tango trunk? I did the simple test for ldc and it seems to work (arrays get collected).

(in reply to: ↑ 3 ) 08/17/10 03:27:29 changed by llucax

Replying to mwarning:

Can you make a patch for tango trunk? I did the simple test for ldc and it seems to work (arrays get collected).

I think wm4 has done it: http://paste.dprogramming.com/dpxiz1qx (taken from the IRC channel).

But notice that the problems is that data is no marked as NO_SCAN, not that is not collected. It just will make the GC work more than necessary.

08/19/10 16:54:58 changed by mwarning

  • status changed from new to closed.
  • resolution set to fixed.

(In [5526]) fixes #1971 :: _d_arrayappend*() doesn't set the block attributes appropriately when allocating for the first time; thanks llucax