Comment #0 by leandro.lucarella — 2010-08-15T16:56:49Z
Now the GC scans all the static data of the program, since it uses the libc variables __data_start and _end to get its limits.
There is a lot of stuff in the static data that doesn't need to be scanned, most notably the TypeInfos[*], which is a great portion of the static data. C libraries static data, for example, would be scanned too, when it makes no sense to do so.
I experience a 20% increment in the total static data of a small program[1] by just adding about 5 more types to the GC implementation, which translate to a appreciable loss in performance because of the extra scanning and probably the extra false pointers.
It would be nice if the compiler could group all the static that must really be scanned (programs static variables) together and make its limits available to the GC. It would be even nicer to leave static variables that have no pointers out of that group, and even much more nicer to create a pointer map like the one in the patch from bug 3463 to allow precise heap scanning. That way the only memory in the program that would have to be scanned conservatively will be the stack.
[*] This is not entirely true, since IIRC the TypeInfo store the .init property, which can be overwritten by the user, storing a pointer to the GC heap there, but I think is a rare enough case to be considered, I think imposing that limitation would be a problem in real life programs.
[1] http://codepad.org/xGDCS3KO
Comment #1 by leandro.lucarella — 2010-08-15T17:30:32Z
I think you can omit the [*] entirely, I think .init being writable was, fortunately, just a product of my imagination...
Comment #2 by nfxjfg — 2010-08-15T18:56:24Z
Generally the GC should only scan data for which at least hasPointers() returns true, and that isn't logically constant (e.g. TypeInfo instances, even though they can contain pointers/references).
Maybe implementation would be simplest by adding a a pointer range to ModuleInfo, that tells the GC what exactly should be scanned. Ideally, static variables for which hasPointers() is false would not be included in this range. This should drastically reduce the amount of data needed to be scanned by the GC, because the C data segment is not included.
An extended implementation could accompany the pointer range with a precise pointer map.
Comment #3 by r.sagitario — 2015-02-07T11:23:10Z
There is a minimal support for this for ELF object files: strings and some floating point constants are emitted to the .text segment.
Comment #7 by leandro.lucarella — 2015-02-23T19:40:49Z
(In reply to github-bugzilla from comment #6)
> Commit pushed to https://github.com/D-Programming-Language/dmd
>
> https://github.com/D-Programming-Language/dmd/commit/
> e649c64e0e8215ee322458d8ae67e37c114d7d66
> Merge pull request #4390 from rainers/const_section
Nice, so this is just moving strings/floats to a section that is not scanned at all? Or is it really grouping all the static data too?
Comment #8 by r.sagitario — 2015-02-23T23:19:15Z
> Nice, so this is just moving strings/floats to a section that is not scanned at > all? Or is it really grouping all the static data too?
It's currently just strings and floats. I hope other const/immutable data can be moved, too.
what is the status of this with the recent pulls? Still valid, fixed?
Comment #13 by r.sagitario — 2015-06-30T05:42:10Z
>what is the status of this with the recent pulls? Still valid, fixed?
More work needs to be done to move immutable data into the CONST segment (or similar areas that are not scanned). It is currently limited to float values and strings, not user defined data.
Comment #14 by github-bugzilla — 2017-07-19T17:41:14Z