6 ms·
GC traverses graph, linker traverses graph. GC = linker. I disagree. Also if that's the description of a "smart linker", what is a "dumb linker" then?
by juloo 5y ago
GC traverses graph, linker traverses graph. GC = linker. I disagree.
Also if that's the description of a "smart linker", what is a "dumb linker" then?
- megameter 5y agoThe kind where the user has to chase dependencies.
- yzombinator 5y agoThe parent comment is actually quite insightful and your comment is quite dismissive without actually bringing anything new to the discussion. I had a ligh bulb moment while reading the parent comment since it made perfect sense. I felt enough rage about your comment to add my reply. Be like the parent comment.
- chrisseaton 5y ago> I felt enough rage about your comment This isn't a normal response to a comment on the internet.
- yzombinator 5y agoThe pandemic changed us all.
- barrkel 5y agoNot just traversing a graph, but determining the location of blobs of data, and adjusting offsets inside those blobs of data to point at the relocated blobs of data. If your GC is simple, there's almost a 1:1 correspondence with every write to memory. Smart linker relates to eliminating dead code. Depending on how symbols are packaged, or how well the compiler is integrated with the linker, there's a risk of including private (i.e. non-exported) code/data in the final executable which is never referenced but is simply co-located with code or data which is linked in. But it's not really a technical term, it's a marketing term from Delphi.
- chrisseaton 5y ago> But it's not really a technical term, it's a marketing term from Delphi. Like 'optimising compiler' - are there really any non-niche compilers that do not optimise? Maybe some first-tier JITs.
- barrkel 5y agoWell, if the linker is very dumb, and just wholesale includes everything in an object file if there's any reference to it, the optimizing compiler can try and work around that by producing itty bitty object files, one for every symbol. Linkers have more scope for smartness. The size of a block of code can be quite sensitive to the addressing mode (near vs far for e.g. 16-bit x86, relative offsets of various widths vs absolute etc.) used for each reference. An intelligent linker can adjust the code depending on where the target ends up, altering the addressing mode. The scope for optimization here depends on the ordering in the final executable, density of references and so on.
- Joker_vD 5y agoBut doesn't this "smartness" require accurate information about internal symbol usage? For exmaple: static int foo(void) { return 4; } int bar(void) { return 42 + foo(); } The compiler, I believe, may emit no symbol entry for foo() and use a relative call inside bar() to call it, so if you only include "used" symbols in your resulting object file, bar() will end up calling into who knows where. That's why there are special flags for enabling "function-level linking" and all that jazz, right?
- barrkel 5y agoAnd this is where Delphi's smart linker is smart: it's always using function-level linking. (I can't answer your question in detail because it's been a long time since I've been poking around in object files and I don't know what C/C++ compilers and linkers have been doing with them recently. I was a compiler engineer at Borland for more than 5 years, but it was years ago.)