• Dan Olson (14/14) Nov 10 2012 So far I am having fun gradually pushing D into apple ios sim (it runs
• Johannes Pfau (25/33) Nov 10 2012 Yes. The GC needs special runtime / compiler support to scan TLS
• Dan Olson (8/12) Nov 10 2012 I used your test, but had to make a bunch of objects to get collection

Dan Olson <zans.is.for.cans yahoo.com> writes:

So far I am having fun gradually pushing D into apple ios sim (it runs
i386 not arm).  I am curious though about thread local storage and GC.
I saw older posts about it being an issue and have not seen anything
more on it.  Is it still an issue?  I am doing all this with latest D
git and gcc-4.8-20121028 snapshot.

What I gather is that D TLS vars are not monitored by the collector so
memory can be prematurely collected.  Is that right?

Anyway, so far it is fun to see D code being linked into an ios app
(i386 sim again) and running, making phobos calls.  I build .o or .a
files outside of xcode then drag them in along with libgphobos2.  I
figure if you can call writeln() and see it come out on the xcode gdb
console, then that is progress.  Well, to me anyway.

-- 
dano

Johannes Pfau <nospam example.com> writes:

Am Sat, 10 Nov 2012 09:12:55 -0800
schrieb Dan Olson <zans.is.for.cans yahoo.com>:

 So far I am having fun gradually pushing D into apple ios sim (it runs
 i386 not arm).  I am curious though about thread local storage and GC.
 I saw older posts about it being an issue and have not seen anything
 more on it.  Is it still an issue?  I am doing all this with latest D
 git and gcc-4.8-20121028 snapshot.
 
 What I gather is that D TLS vars are not monitored by the collector so
 memory can be prematurely collected.  Is that right?

Yes. The GC needs special runtime / compiler support to scan TLS
variables and this code has traditionally been buggy / difficult to
implement.

You can use a simple test to detect the most obvious errors:
------------------------------------------------------------
import std.stdio;
import core.memory;

class A
{
    string str;
    void a()
    {
        writeln(this.str);
    }
}

A var; //TLS variable

void main()
{
    var = new A();
    var.str = "Hello World";
    GC.collect(); //Force collection
    var.a();
}

Dan Olson <zans.is.for.cans yahoo.com> writes:

Johannes Pfau <nospam example.com> writes:
 Yes. The GC needs special runtime / compiler support to scan TLS
 variables and this code has traditionally been buggy / difficult to
 implement.

 You can use a simple test to detect the most obvious errors:

I used your test, but had to make a bunch of objects to get collection
to happen.  GC *is* reclaiming objects still referenced by TLS and no-TLS
(shared).  So I will need to look into that some more.

Note: this is on osx and I tweaked some of the druntime code to get it
to build, so some of this might be my doing.

So I guess as a follow up, should I expect the GC to be aware of shared
globals, or are there issues there too like thread local?