September 30, 2018 Most Effective way of developing a new GC for D | ||||
---|---|---|---|---|
| ||||
I'm gonna play around with creating a GC that alleviates some of the uses described in https://olshansky.me/gc/runtime/dlang/2017/06/14/inside-d-gc.html What's the most effective way of incrementally developing a new pluggable GC for druntime with regards to prevention of really-hard-to-find-bugs? I'm aware of the run-time flag added in 2.072: https://dlang.org/changelog/2.072.0.html#gc-runtimeswitch-added Is it inevitable to rebuild druntime everytime I make an update to a new GC? Is so what's the preferred way of selecting a modified druntime in a standard installation of dmd on a Linux system (Ubuntu 18.04 in my case). Will Digger makes things easier? |
September 30, 2018 Re: Most Effective way of developing a new GC for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Per Nordlöw | On Sunday, 30 September 2018 at 09:40:10 UTC, Per Nordlöw wrote: > I'm gonna play around with creating a GC that alleviates some of the uses described in > > https://olshansky.me/gc/runtime/dlang/2017/06/14/inside-d-gc.html > > What's the most effective way of incrementally developing a new pluggable GC for druntime with regards to prevention of really-hard-to-find-bugs? > > I'm aware of the run-time flag added in 2.072: > > https://dlang.org/changelog/2.072.0.html#gc-runtimeswitch-added > > Is it inevitable to rebuild druntime everytime I make an update to a new GC? No. > Is so what's the preferred way of selecting a modified druntime in a standard installation of dmd on a Linux system (Ubuntu 18.04 in my case). Will Digger makes things easier? The immediate idea (and maybe naive too) is to link once against a new GC that follows the interface but has assignable handlers. Once DMD build, you can just do dmd -unittest temp_gc_handlers.d && ./temp_gc_handlers At each iteration. temp_gc_handlers.d would have a static module ctor that assigns its content to the GC handler. Once good you put the handler code in the real GC. I think that it would be possible that a few runtime stuff leak until the devel be almost complete but that doesn't matter if stuff are checked, let's say, from a checkpoint that says "from here this amount of leak is normal, it should disappear automatically in the real GC". But again, this method is very hypothetical. |
Copyright © 1999-2021 by the D Language Foundation