GC Initialized on First Alloc #2057

somzzz · 2018-01-24T10:52:43Z

This PR removes the requirement of having the GC initialized at startup. Instead, gc_init is called when the GC is first invoked.

dlang-bot · 2018-01-24T10:52:44Z

Thanks for your pull request and interest in making D better, @somzzz! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

My PR is fully covered with tests (you can see the annotated coverage diff directly on GitHub with CodeCov's browser extension
My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
I have provided a detailed rationale explaining my changes
New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

somzzz · 2018-01-24T16:53:26Z

Fail seems unrelated #2048
@andralex

marler8997 · 2018-01-24T18:44:21Z

src/gc/proxy.d

 }

+alias GCInitNoThrow = void function() nothrow @nogc;


this appears to be unused

marler8997 · 2018-01-24T18:49:03Z

src/gc/proxy.d

+        {
+            instanceLock.lock();
+            scope(exit) instanceLock.unlock();
+            {


unnecessary extra scope?

marler8997 · 2018-01-24T18:50:06Z

src/gc/proxy.d


-            fprintf(stderr, "No GC was initialized, please recheck the name of the selected GC ('%.*s').\n", cast(int)config.gc.length, config.gc.ptr);
-            exit(1);
+        if (atomicLoad(*pinstance) is null)


whenever I do double-checked locking, I like to put a comment :)
// using double-checked locking

marler8997 · 2018-01-24T18:53:30Z

src/gc/proxy.d

+                        exit(1);
+                    }
+
+                    atomicStore(*pinstance, cast(shared GC)auxInstance);


Race condition? setting instance to "not null" should be the last thing done correct? Otherwise another thread could come in, see that instance is not null and then continue before thread_init has finished. However, my comment is assuming that thread_init should be finished before another thread can start using the GC, is this assumption correct?

Depends on the startup, there could be multiple external "C" threads calling thread_attachThis concurrently.

@MartinNowak so what's the right course of action here?

The mutual dependency between gc_init and thread_init isn't properly resolved.

if (atomicLoad(*pinstance) is null)) { instanceLock.lock(); scope (exit) instanceLock.unlock(); if (atomicLoad(*pinstance) is null)) { // init // ... atomicStore(*pinstance, cast(shared GC)auxInstance); // thread_init <- should be moved before storing pInstance or some other thread could start to use the GC before thread_init finishes } }

The problem is that thread_init depends on the GC, but any GC usage depends on thread_init (for suspending).
Let's figure out whether we can avoid the GC for Thread.getThis, if not then pass auxInstance directly to thread_init.

And BTW, use weaker (and much cheaper) orderings.

if (atomicLoad!(MemoryOrder.acq)(*pInstance) is null) { // lock... if (atomicLoad!(MemoryOrder.acq)(*pInstance) is null) { // init... atomicStore!(MemoryOrder.rel)(*pInstance, auxInstance); } }

@MartinNowak let's make it most conservative and optimize in a subsequent step thx

This is nastier than it looks.
thread_init calls thread_attachThis which calls GC.disable and GC.enable.
https://github.com/dlang/druntime/blob/master/src/core/thread.d#L2138

While gc_init has not yet finished, the spinlock is still locked. Calling disable will redirect to gc_init (with the instance still null because store hasn't been done yet) -> deadlock.

Yes, just directly pass the newly created GC instance to thread_init, so that thread_attachThis can directly access the GC interface instead of calling the global gc_disable/gc_enable functions.

That works for gc_disable/gc_enable.
However, the code then creates an object new Thread which will become a call to _d_newclass in lifetime.d.
https://github.com/dlang/druntime/blob/master/src/rt/lifetime.d#L93

This function calls GC.malloc. I can't pass the instance there and the code hangs on the spinlock (as GC.malloc tries to call gc_init).

A slightly ugly workaround is to create a static tlsInstance for the thread doing the initialization and use this one, if available, in gc_enable, gc_disable and gc_malloc.

_d_newclass should forward to a function that accepts a gc instance, and then instead of calling new Thread, call the function directly (with the auxInstance of course).

marler8997 · 2018-01-24T18:55:05Z

src/gc/proxy.d

+                        import core.stdc.stdlib : exit;
+
+                        fprintf(stderr, "No GC was initialized, please recheck the name of the selected GC ('%.*s').\n", cast(int)config.gc.length, config.gc.ptr);
+                        instanceLock.unlock();


You've unlocked twice! (scope(exit) instanceLock.unlock(); above)

yes please delete

For some reason, if unlock is not called before exit(1), this test hangs: druntime/test/exceptions/src/unknown_gc.d

uh oh, that may be a bug with D's scope(exit) implementation (anyone correct me if I'm wrong). Given this, I would suggest not using scope(exit) here and instead insert instancelock.unlock() at every "exit point". There should just be 2, just before calling exit and at the end of the block.

FWIW we have a nice language feature for exactly this:

synchronized (instanceLock) { // code here }

If scope(exit) doesn't work with the exit function, my guess is that this might suffer from the same bug. @somzzz can you try this out and confirm?

Wait, exit() doesn't return, so it can't exit the scope. This seems like the code is correct to me...

scope(exit) only works if the scope is exited, via stack unwinding or normal execution. Calling exit function is neither.

keep scope(exit) and also unlock explicitly before calling exit thx

marler8997 · 2018-01-24T18:57:25Z

src/gc/proxy.d

+            instanceLock.lock();
+            scope(exit) instanceLock.unlock();
+            {
+                if (atomicLoad(*pinstance) is null)


I don't think atomicLoad is necessary once inside the lock, since the value is guaranteed not to be modified while a thread is inside the lock.

I wonder whether you have tried the following trick of using a variable to cache and thus providing as fast, hot-path for the default case:

__gshared gcHasBeenInitialized; if (!gcHasBeenInitialized) { // do your normal locking here gcHasBeenInitialized = true; }

TLS variables could be faster, but you could benchmark this for dynamic modules too.

That's what that is, I believe, only fixed to be correct.

(A TLS cache can be made thread-safe without atomics, of course.)

Would love to see a performance comparison on TLS vs atomic double-checked locking.

I'd expect that to be hard to do as a microbenchmark on x86 in a sensible fashion, since it depends a lot on non-local considerations. If there is no contention on the cache line, I'd expect double checked locking to be at least as fast (acq loads are just simple movs).

Double-checked locking should be faster, TLS reads go through an extra indirection and can be very slow if TLS is emulated. Just reading a shared variable by multiple threads doesn't cost much (except maybe for the non-inlined atomicRead!acq overhead with dmd).

@somzzz let's conservatively leave atomicLoad here and review it in a future pass thx

Yep, precisely. On x86_64 TLS can pretty much only be faster if the indirection is cheap (i.e. static TLS model) and the other variant is burdened down by concurrent writes to other data on the same cache line (hence my above comment). I wouldn't worry about it.

marler8997 · 2018-01-24T18:59:14Z

src/gc/proxy.d

-        thread_init();
+    void gc_init_nothrow() nothrow
+    {
+        try


gc_init_throw is going to be called often. Rather than incurring the overhead of a try/catch for every gc_init_nothrow, this should probably go inside the double checked lock. That way you only have to pay the price of a try/catch once, when you initialize the GC.

Indeed, use sth. similar to initOnce.
Instead of a separate flag variable, you could directly load/store the shared instance variable. Also seems like the spinLock would be fine to be used as mutex.

I think the purpose here was just to trick nothrow.
A short idiom for that is the following.

void foo() nothrow { scope (failure) assert(0, "unexpected exception"); stmt; // not yet nothrow annotated }

Calling abort is cleaner as it prints a better error message, so you might just want to stick with the current code. In that case please add a comment that gc_init should be annotated nothrow instead.

From what I understand, try/catch and scope(failure) incur some amount of overhead. By moving this inside the lock we only have to incur it once. I still recommend doing so.

Based on @MartinNowak's suggestions, initOnce looks like it could work here so long as you use a mutex and wrap the init argument in a tryCatch.

initOnce is in Phobos, which is the reason I didn't suggest it earlier. We cut put something like it in druntime, of course, for internal use.

dmd is fairly bad at optimizing initOnce, so doing it manually seems fine here.

marler8997 · 2018-01-24T19:02:00Z

src/gc/proxy.d

@@ -68,132 +103,159 @@ extern (C)
        // NOTE: Due to popular demand, this has been re-enabled.  It still has
        //       the problems mentioned above though, so I guess we'll see.

-        instance.collectNoStack(); // not really a 'collect all' -- still scans
-                                    // static data area, roots, and ranges.
+        if (instance !is null)


I'm not familiar with who calls gc_term. Would it be better to make this synchronized like you have done in gc_init? Or is this only going to be called by a single thread?

gc_term is called in dmain2.d->rt_term after thread_joinAll.
https://github.com/dlang/druntime/blob/master/src/rt/dmain2.d#L223

marler8997 · 2018-01-24T19:04:11Z

Thanks for making this change. I like the idea.

quickfur · 2018-01-24T19:10:28Z

src/gc/proxy.d

        instance.enable();
    }

    void gc_disable()
    {
+        assert(instance !is null);
        instance.disable();


Will this break code that calls GC.disable at the beginning of the program? Sometimes it's useful to do this and schedule your own calls to GC.collect; I've done this before to optimize GC performance.

Would it be better to also initialize the GC in gc_enable / gc_disable, in addition to doing it upon the first memory allocation? IOW, initialize the GC the first time it's used in some way, whether it's a memory allocation or enable/disable, etc..

If there is a use case for it, then yes - it should be initialized.
Which of these methods do you think should initialize the GC?

Definitely GC.disable as it's fairly common. Don't think anyone has explicitly called GC.enable yet. Even better if we could memorize GC.disable and lazily initialize and disable the GC if it's used later on. It would be weird to initialize a GC just to disable it.
Don't make things too complicated though, when in doubt just initialize the GC on any access.

Hm... just had a weird idea.

What if the instance is initialized with a GC that when first used, figures out what GC to allocate, sets the 'instance' to the new one, and calls the appropriate function on it. Then we can handle things like a bool to track the disabling without having to initialize until someone tries to call malloc, etc.

Then once the real instance is in place, there is no longer any checking for initialization.

You'd still need to atomically load the instance every time you use it, unfortunately.

I like this idea.

What are the methods requiring that behavior disable, addRoot, removeRoot, rootIter, addRange, removeRange, rangeIter? Sounds like a reasonable approach for lazy initialization.

BTW, that just requires an atomicLoad!(MemoryOrder.acq), and that's free on strongly-ordered CPUs.

I would initialize a full GC on anything that requires storing an array of things to do, because that involves allocation. Just having a global bool is OK to cache until you need the whole GC.

that's free on strongly-ordered CPUs

Right, x86 doesn't have issues with loads of a word, so those will be fine. It's the other architectures I don't know enough about how the performance might be. I would leave that decision/discussion to those who know more :)

I would initialize a full GC on anything that requires storing an array of things to do

Hm... I guess if you need to allocate using the C heap you can, as long as the behavior matches what the GC would actually do. You might even pass those into the GC initializer, and it would just take over ownership of the arrays.

BTW, that just requires an atomicLoad!(MemoryOrder.acq), and that's free on strongly-ordered CPUs.

Please KISS (Keep It Simple and conServative) for now. Then we'll take a separate PR with loads and stores tightened. If we ever have trouble with those we'll be able to track that easily. Thanks!

marler8997 · 2018-01-24T19:11:39Z

src/gc/proxy.d

-            import core.stdc.stdlib : exit;
+        import core.atomic : atomicLoad, atomicStore;
+
+        auto pinstance = cast(shared(GC)*) &instance;


Note that if you remove the second atomicLoad (see comment below). I believe you could just do
if (atomicLoad(instance))
and you don't need the pinstance variable.

@marler8997 I think that won't work because atomicLoad expects a ref to a shared object

MartinNowak

Good idea, the ugly startup order has long been lingering around. I guess we want to add a test to druntime/test/ that checks that a @nogc main can be run without initializing the GC.
There is already unknown_gc which should now require a GC allocation to pass, but you can adopt it to check that no GC is ever initialized.

MartinNowak · 2018-01-24T19:13:28Z

src/gc/proxy.d

+
+                    // NOTE: The GC must initialize the thread library
+                    //       before its first collection.
+                    thread_init();


What do you indent to do about Thread.getThis? It is currently a GC allocated instance that is eagerly created in thread_init.

That may be why *pinstance had to be set just above! Seems fragile. Perhaps we can not use the GC for getThis?

You can currently retain a Thread object longer than the threads lives, e.g. there is even a Thread.join methods, so there isn't a clear owner of that instance. Not too easy to avoid the GC here.

MartinNowak · 2018-01-24T19:18:04Z

src/gc/proxy.d

-        thread_init();
+    void gc_init_nothrow() nothrow
+    {
+        try


Indeed, use sth. similar to initOnce.
Instead of a separate flag variable, you could directly load/store the shared instance variable. Also seems like the spinLock would be fine to be used as mutex.

MartinNowak · 2018-01-24T19:19:52Z

src/gc/proxy.d

+                        exit(1);
+                    }
+
+                    atomicStore(*pinstance, cast(shared GC)auxInstance);


Depends on the startup, there could be multiple external "C" threads calling thread_attachThis concurrently.

rainers · 2018-01-24T20:05:54Z

This is pretty performance sensitive code, please benchmark the GC suite with benchmark/runbench
We have removed null-checks for the instance not too long ago (though they have been used for a different purpose). Adding them back with atomics is probably not so great. An alternative would be to implement the GCInterface with an object that switches the instance global to the standard GC if necessary.
all the assert(instance !is null) can probably do/return something sensible knowing that no GC memory has been allocated.
I also suspect that this change will probably not have an immediate effect because other init functions are likely to access the GC, e.g. initStaticDataGC calls GC.addRange.

andralex · 2018-01-24T18:40:06Z

src/gc/proxy.d

 }

+alias GCInitNoThrow = void function() nothrow @nogc;


make it private

andralex · 2018-01-24T21:25:14Z

src/gc/proxy.d

-            import core.stdc.stdlib : exit;
+        import core.atomic : atomicLoad, atomicStore;
+
+        auto pinstance = cast(shared(GC)*) &instance;


@marler8997 I think that won't work because atomicLoad expects a ref to a shared object

andralex · 2018-01-24T21:52:31Z

src/gc/proxy.d

+                        import core.stdc.stdlib : exit;
+
+                        fprintf(stderr, "No GC was initialized, please recheck the name of the selected GC ('%.*s').\n", cast(int)config.gc.length, config.gc.ptr);
+                        instanceLock.unlock();


yes please delete

andralex · 2018-01-24T21:54:11Z

src/gc/proxy.d

+                        exit(1);
+                    }
+
+                    atomicStore(*pinstance, cast(shared GC)auxInstance);


@MartinNowak so what's the right course of action here?

andralex · 2018-01-24T21:55:13Z

src/gc/proxy.d

+
+                    // NOTE: The GC must initialize the thread library
+                    //       before its first collection.
+                    thread_init();


That may be why *pinstance had to be set just above! Seems fragile. Perhaps we can not use the GC for getThis?

MartinNowak · 2018-01-25T17:15:37Z

That's the main blocker to make this work https://github.com/dlang/druntime/pull/2057/files#r163907886.

schveiguy · 2018-01-25T19:58:09Z

This may have been lost in the noise, so I'll link to it here:

#2057 (comment)

Might be a viable option that eliminates some of the possible performance drawbacks.

marler8997 · 2018-01-25T20:01:37Z

@schveiguy I'm actually working an an alternative that explores your idea. Will make a PR soon if it turns out well.

schveiguy · 2018-01-25T20:16:06Z

src/gc/proxy.d

+
+                        fprintf(stderr, "No GC was initialized, please recheck the name of the selected GC ('%.*s').\n", cast(int)config.gc.length, config.gc.ptr);
+                        instanceLock.unlock();
+                        exit(1);


You should add an assert(0); here to note that exit(1) shouldn't return.

andralex · 2018-01-25T21:39:15Z

src/gc/proxy.d

+            instanceLock.lock();
+            scope(exit) instanceLock.unlock();
+            {
+                if (atomicLoad(*pinstance) is null)


@somzzz let's conservatively leave atomicLoad here and review it in a future pass thx

andralex · 2018-01-25T21:40:49Z

src/gc/proxy.d

+                        import core.stdc.stdlib : exit;
+
+                        fprintf(stderr, "No GC was initialized, please recheck the name of the selected GC ('%.*s').\n", cast(int)config.gc.length, config.gc.ptr);
+                        instanceLock.unlock();


keep scope(exit) and also unlock explicitly before calling exit thx

andralex · 2018-01-25T21:45:02Z

src/gc/proxy.d

+                        exit(1);
+                    }
+
+                    atomicStore(*pinstance, cast(shared GC)auxInstance);


@MartinNowak let's make it most conservative and optimize in a subsequent step thx

andralex · 2018-01-25T21:47:58Z

src/gc/proxy.d

        instance.enable();
    }

    void gc_disable()
    {
+        assert(instance !is null);
        instance.disable();


Don't make things too complicated though, when in doubt just initialize the GC on any access.

let's do that now, refine later

rainers · 2018-01-26T08:18:08Z

Possible @rainers had the same thought, I just didn't see it

Thanks for noticing ;-) I think with the switching proxy object no atomics are needed to access the instance pointer in the general case if pointer writes cannot appear as partial operations in other threads (which should cover ost architectures). The synchronization is only needed in the switching proxy, i.e. it is a one time operation and doesn't need to be very fast.

The disable state of the GC can be saved to gc.config.disable before atually initializing the GC.

BTW: how about not allocating any pool during GC initialization. That would have almost the same effect as not initializing it, but a few tiny allocations.

andralex · 2018-02-13T17:16:23Z

There are 2 simple acceptance criteria, the overhead of lazy GC must be negligible, and we must not initialize and allocate OS resources when the GC is not used (lazy initialization). The latter one still isn't met, but very simple to achieve.

I realized I omitted a discussion I've had with @somzzz. Next on her list to move the code that adds roots in _Dmain from src/rt/sections_elf_shared.d. The roots will be added lazily during the initialization. That eliminates the internal use of addRoot/addRange. I do agree that if one of the first things _Dmain does is to call addRoot/addRange, then this PR doesn't help a lot.

So please let's get this in without more features. Accumulating addRoot/addRange calls in an array is not trivial - where do you allocate the array? There's no GC. So then we need to use malloc/free, an additional complication. And once we remove addRoot/addRange from _Dmain, the clientele of that complication will be virtually nobody.

MartinNowak · 2018-02-13T17:20:03Z

src/gc/impl/proto/gc.d

+class ProtoGC : GC
+{
+    __gshared Array!Root roots;
+    __gshared Array!Range ranges;


Do those really need to be __gshared?

MartinNowak · 2018-02-13T17:22:49Z

So please let's get this in without more features. Accumulating addRoot/addRange calls in an array is not trivial - where do you allocate the array? There's no GC.

As said earlier, we have @nogc containers in druntime for those purposes.
In fact they are already added (https://github.com/dlang/druntime/pull/2057/files#diff-254a9fe518c0b5c278aeec1838d7adf8R34), but not used.

andralex · 2018-02-13T17:24:02Z

@MartinNowak in wake of the upcoming removal of addRange from _Dmain, what would be the usefulness of your proposed added feature?

MartinNowak · 2018-02-13T17:26:48Z

I realized I omitted a discussion I've had with @somzzz. Next on her list to move the code that adds roots in _Dmain from src/rt/sections_elf_shared.d. The roots will be added lazily during the initialization. That eliminates the internal use of addRoot/addRange. I do agree that if one of the first things _Dmain does is to call addRoot/addRange, then this PR doesn't help a lot.

That sounds nice in theory, but you're likely underestimating the complexity in that area, because GC roots are dynamically added/removed when loading/unloading shared libraries. So instead of conflating a complex with another complex, let's just go for the straightforward solution and cache roots/ranges until lazily initializing the GC.
In fact we've prolly spent 2x more time discussing this, than would be necessary to do the change.

andralex · 2018-02-13T17:27:18Z

@MartinNowak meet on slack?

andralex · 2018-02-13T17:37:30Z

After discussing, the shared lib example is quite compelling. @somzzz will implement the changes with this PR.

MartinNowak

Thanks, looks great.

MartinNowak · 2018-02-14T08:59:41Z

Another nice thing that comes with this PR, once #1924 is implemented, applications wouldn't even need to link against any GC.

andralex · 2018-02-14T12:57:34Z

Congrats @somzzz and many thanks to all reviewers!

MartinNowak · 2018-02-14T17:57:41Z

Congrats @somzzz and many thanks to all reviewers!

Yes, thanks for this important step towards a no-GC language, and thanks @schveiguy for the nice ProtoGC idea.
The amount of feedback was a bit overwhelming, but this is certainly due to the interest in the topic.

schveiguy · 2018-02-15T13:53:29Z

thanks @schveiguy for the nice ProtoGC idea

Thanks for the credit, I also have to mention that @rainers had the same idea (before I did), but just expressed it in a different way here: #2057 (comment).

dnadlinger · 2018-02-14T18:26:28Z

src/gc/impl/proto/gc.d

+    size_t reserve(size_t size) nothrow
+    {
+        gc_init_nothrow();
+        return reserve(size);


What does this call?

oops! It should have been gc_reserve

dnadlinger · 2018-02-17T03:07:43Z

src/gc/impl/proto/gc.d

+
+    void addRange(void* p, size_t sz, const TypeInfo ti = null) nothrow @nogc
+    {
+        ranges.insertBack(Range(p, p + sz, cast() ti));


This doesn't seem thread-safe – are we sure there can never be a situation where ProtoGC sticks around long enough to be racy (e.g. after improving druntime thread startup to be nogc and using statically allocated Thread instances, or when attaching to multiple C threads)?

Has this been thoroughly thought through for race conditions in general, especially considering architectures where loading the global instance doesn't automatically have acquire semantics?

It's a good point. Likely you need to take the lock. I'm wondering if adding/removing ranges or roots should simply initialize the GC at that point.

I thought the instance should be atomically loaded, see Martin's suggestion here. But that doesn't help if you need atomic array appending.

dnadlinger · 2018-02-18T16:20:19Z

Ping @somzzz, @andralex – I don't have the bandwidth to look into this myself right now, but someone should (or make sure it isn't actually an issue).

dnadlinger · 2018-02-28T22:39:30Z

Ping @somzzz, @andralex – still waiting for a response.

andralex · 2018-03-01T13:37:13Z

@klickverbot thanks for the reminder. @somzzz is off to a scholarship in Singapore so she's off the project. The concern about addRange seems legit. Can you please create a bugzilla issue? Thanks!

dnadlinger · 2018-03-01T15:57:42Z

I've created an "umbrella" issue – no time to delve into the code right now to figure out what exactly is broken right now.

ghost · 2018-06-18T07:11:47Z

This change causes a regression in phobos Array container. gc_init should be made public now. see bugzilla

schveiguy · 2018-06-18T13:08:12Z

gc_init should be made public now.

No, the point of ProtoGC is to initialize properly when needed, we should not need to make gc_init public (nor should we require calling it).

The problem causing the issue is that removeRoot and removeRange do not behave correctly. I'll file a PR to fix this.

schveiguy · 2018-06-18T13:54:08Z

Fixing PR: #2220

somzzz requested review from andralex and DmitryOlshansky as code owners January 24, 2018 10:52

somzzz requested review from MartinNowak, rainers and wilzbach as code owners January 24, 2018 10:52

somzzz force-pushed the moving_gc_init branch 2 times, most recently from 159895e to 9f42a62 Compare January 24, 2018 13:46

marler8997 reviewed Jan 24, 2018

View reviewed changes

quickfur reviewed Jan 24, 2018

View reviewed changes

marler8997 reviewed Jan 24, 2018

View reviewed changes

MartinNowak reviewed Jan 24, 2018

View reviewed changes

andralex suggested changes Jan 24, 2018

View reviewed changes

schveiguy reviewed Jan 25, 2018

View reviewed changes

andralex suggested changes Jan 25, 2018

View reviewed changes

wilzbach mentioned this pull request Jan 26, 2018

Work On Issue 10828 - Add output range versions of toString functions to std.datetime.TimeOfDay dlang/phobos#6071

Merged

MartinNowak reviewed Feb 13, 2018

View reviewed changes

MartinNowak added this to the 2.079.0 milestone Feb 13, 2018

somzzz force-pushed the moving_gc_init branch from e451159 to b99629e Compare February 13, 2018 22:12

addRange/addRoot lazy init

6d7fefd

somzzz force-pushed the moving_gc_init branch from b99629e to 6d7fefd Compare February 13, 2018 22:16

MartinNowak approved these changes Feb 14, 2018

View reviewed changes

add changelog for lazy gc init

c025466

MartinNowak added the auto-merge label Feb 14, 2018

dlang-bot merged commit fb17fe9 into dlang:master Feb 14, 2018

dnadlinger reviewed Feb 17, 2018

View reviewed changes

wilzbach mentioned this pull request Feb 18, 2018

Use upper-casing for the GC init changelog entry #2097

Merged

schveiguy mentioned this pull request Feb 20, 2018

Fix recursive reserve call in ProtoGC #2101

Merged

JohanEngelen added a commit to weka/ldc that referenced this pull request Jan 9, 2019

Revert lazy GC initialization. dlang/druntime#2057

05aad1c

GC Initialized on First Alloc #2057

GC Initialized on First Alloc #2057

Conversation

somzzz commented Jan 24, 2018

dlang-bot commented Jan 24, 2018 • edited

Bugzilla references

somzzz commented Jan 24, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

marler8997 Jan 24, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

schveiguy Jan 25, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

marler8997 Jan 24, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

marler8997 Jan 24, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MartinNowak Jan 24, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

marler8997 commented Jan 24, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MartinNowak Jan 25, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andralex Jan 26, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MartinNowak left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rainers commented Jan 24, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dlang-bot commented Jan 24, 2018 •

edited

marler8997 Jan 24, 2018 •

edited

schveiguy Jan 25, 2018 •

edited

marler8997 Jan 24, 2018 •

edited

marler8997 Jan 24, 2018 •

edited

MartinNowak Jan 24, 2018 •

edited

MartinNowak Jan 25, 2018 •

edited

andralex Jan 26, 2018 •

edited

rainers commented Jan 24, 2018 •

edited