Experiment with thread_local globals for I/O dispatch

[alexcrichton]

Right now the main reason that all rust binaries are a minimum of 1MB is that all of the runtime's I/O is included in all binaries. The reason that all I/O is included is that LLVM can't eliminate the top-level I/O functions. The functions are included in a vtable which is then included in the local Task and it's pretty much impossible from there to be able to tell whether the vtable can be shrunk.

In theory we could do some optimizations at a frontend level to detect when I/O isn't used, but it'd also be nice if LLVM did this for us.

One idea I had tonight is that all I/O dispatch functions will not use a trait, but rather a set of thread_local globals (initialized when threads boot). From what I can tell, LLVM can eliminate a global if there are only writes to it (no reads), and in this world if you didn't use the networking I/O, you'd never read the networking I/O global, so all of that code could get eliminated.

Some points about this approach

• I'm not sure it would work at all on platforms with no support for thread_local, currently android and windows (and osx 10.6)
• This would slow down native task spawn times as they would always have to initialize these globals. I would naively assume that the slowdown is nothing compared to a syscall.
• We'd need a nicer interface to thread_local because there would be dozens of these I/O functions
• bare-bones usage of libnative (rust not bootstrapped from main) would not have these globals initialized. This I believe can be lumped into "you gotta call something::start first".

Despite these limitations, it's an incredibly frequent question raised on IRC about why rustc can't create a binary less than 1MB in size. This optimization would only apply to LTO'd programs, but it would at least work somewhere.

It's always been nagging at the back of my mind that we can't remove this I/O code, and this is the first idea I've had to get rid of this code, but I'm not sure how it will work out. I'm saddened that there would be more TLS globals, but the payoff may be worth it!

[alexcrichton]

Upon some more discussion, I don't think that this is the fix that we want.

This would indeed allow us to cut down the size of executables, but the key point is that it only helps LTO executables. At some point, we get to the area of diminishing returns and this is breaching into that territory. The main complaint is that the default executable is large, not that LTO executables are too large.

I don't think there's enough bang for our buck with this solution, it simply requires too many workarounds to get this working and I don't believe that the benefit is that great.

[alexcrichton]

Reopening, I chatted more on IRC about this, and I was convinced that it's useful to have some way to get rid of all this extra code. This would only be useful for those running LTO, but perhaps that's "good enough" for now.

I don't think this is high priority, but perhaps useful to have open.

[thestinger]

#17325 means this is no longer relevant to the standard libraries - the dynamic I/O dispatch won't exist