[llvm-bugs] [Bug 43253] New: More aggressive garbage-collection
llvm-bugs at lists.llvm.org
Mon Sep 9 02:23:47 PDT 2019
Bug ID: 43253
Summary: More aggressive garbage-collection
Component: All Bugs
Assignee: unassignedbugs at nondot.org
Reporter: ruiu at google.com
CC: llvm-bugs at lists.llvm.org, peter.smith at linaro.org
There seems to be room for improving -gc-sections so that the garbage collector
reclaims more sections that it does now. Let me describe the idea in this bug.
`-gc-sections` is a linker option to make the linker to do mark-sweep garbage
collection on input file sections. It is perhaps not very wrong to think that
adding a new unrelated (unused) object file to the command line as well as
`-gc-sections` flag doesn't increase the resulting executable size at all
because the new file is garbage-collected.
Unfortunately that naive understanding is not correct. If an object file
contains a global variable that has a nontrivial constructor, that initializer
must run before `main()`, so the linker handles global initializers as GC root
objects. Garbage-collecting such global variable changes program's semantics
even if the variable is not used at all, because a constructor may have a side
effect. For example, you can print out "Hello world" from a constructor, and
removing a global variable from the program changes the program's behavior.
But I'd think it is probably OK to garbage-collect global variables and their
ctors if they are read from archive files.
Object files in archive files are not guaranteed to be linked. They are linked
only when there are undefined symbols that cannot be resolved from them. So, we
can garbage-collect a whole object file if that is not reachable, maybe?
Another view of this proposal: if we run a mark-sweep garbage collector after
reading all object files and before reading any archive files, no file will be
read from archives if they would be dead after GC.
There's of course a risk of changing the existing programs behaviors, but I
think it's worth trying.
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-bugs