WWDC2017 Session 413

Transcript

>> Hello everybody.
[ Applause ]
Thanks for coming out this
morning.
I'm Louis Gerbarg.
I work on the dyld Team, and
today we're going to talk about
App Startup, Past, Present and
Future.
So we got a lot to go through,
so I'm just going to get into
it.
So first off I want to do an
overview of what we're going to
be talking about today.
So first we're going to review
some advice we gave from last
year.
Then I want to talk about some
new tooling we've developed to
make finding certain types of
app startup time problems
easier.
After that I want to take a side
tour into a brief history of
dyld on our platforms, and then
I want to discuss the all new
dyld that we're going to be
shipping in macOS High Sierra
and iOS 11.
And then finally, I want to talk
about best practices for this
new dyld.
So before that I just want to do
a little bit of bookkeeping.
So first off, we want your
feedback.
So if you have anything you want
to tell us, please file bugs
with the title DYLD USAGE, and
hopefully they will get back to
us.
And now I want to talk about
some terminology that I'm going
to use in the rest of this talk.
So first off, what does startup
time mean?
And startup time for the
purposes of this talk means time
spent before main.
Now, if you are writing an app,
you have to do more than that.
After that happens, there will
be nib loading and other things
like that and you have codes to
run after you -- in UI
application delegates and what
not, but you have more
visibility into that and there
are many other talks about that.
Today we just want to talk about
what happens before your main
executes and how you can speed
that up.
Additionally, I want to define a
launch closure, and this is a
new term.
And a launch closure is all of
the information necessary to
launch your application.
So what dylibs it uses, what the
offsets in them are for various
symbols, where their code
signatures are.
And with that, let's go into the
main body of the talk.
So last year I said do less, and
I'm going to say that again this
year and I'm always going to say
that because the less you do,
the faster we can launch.
And no matter how much we speed
things up, if we have less work,
it's going to go faster.
And the advice is basically the
same.
You should use fewer dylibs, if
you can, you should embed fewer
dylibs.
System ones are better in
certain ways from a time
perspective, and we'll go into
that.
You should declare fewer classes
and methods and you should run
fewer initializers.
Finally, I'm going to tell you
you can do a little bit more of
something.
You can use more Swift, and the
reason is Swift is designed in
such a way that it avoids a lot
of pitfalls that C, C++ and
Objective-C allow you to do.
Swift does not have
initializers.
Swift does not allow certain
types of misaligned data
structures that cost us time in
launch.
So, in general, moving to Swift
will make it easier for you to
get very responsive app startup.
So also, there are the Swift
size improvements and smaller is
better, so please move to this
new Swift that we've shipped
this year with the size
improvements and that's going to
help you out.
So now let me talk about some
new tooling we have.
So new in iOS 11 and macOS High
Sierra, we've added Static
Initializer Tracing to
Instruments.
So, yes, this is pretty exciting
stuff because initializers are
code that have to run before
main to set up objects for you,
and you haven't had much
visibility into what happens
before main.
So they're available through
Instruments and they provide
precise timing for each static
initializer.
So with that, I'd like to go to
a demo right now.
So over here I have an
application, and as most
applications at WWDC are, it's a
way of sharing cute pictures of
animals.
So here, let me launch it.
And, you know, it's taking a
little while here, but it's
still taking a while and it gets
up and we can see some
chinchillas and some cats.
And so let's take a look at why
it took that time.
So I'm going to go and I'm going
to rerun it under Instruments.
So we'll stop the execution of
the current one and run it.
And now if we go in, I'm going
to start with a blank template
and we can add the new Static
Initializer tool, which is right
there.
And while we're at it, I'm also
going to add a Time Profiler
because it's always kind of nice
to see what's going on.
There we go.
Okay. So now that we have those,
let's start running our
application.
So we're getting in our trace
data, and it's still not up, but
it just came up and as you can
see in the background there, we
had something fill in there.
So I'm going to just zoom in so
you can get a look, and I have a
function there called
waitForNetworkDebugger, and
that's right, because I was
loading these off of an adjacent
feed that we had up on our site.
I was trying to debug that.
So let's go and -- I just want
to actually take a quick look
here in the CPU Usage tool.
So you can see that that
initializer's roughly the same
length as my CPU usage.
So if I go down there, I can
actually drill down into dyld,
and if I do that, we're actually
going to see what was taking all
that time, and that time is 9.5
seconds, 9.5 seconds into the
initializer.
It's pretty deep.
You don't usually have to do
this, but I want to show you
what's going on.
And down in here I can finally
see waitForNetworkDebugger,
which is what we saw up in the
initializer call, but now it's
very easy for you to find that.
So now that we've done that, I'm
going to go back over into Xcode
and, oh, yeah, that's the
waitForNetworkDebugger call that
I implemented.
I implemented it in C because
Swift won't even let you do
something like this, which is
because this is a bad idea, but
I created a constructor there.
So if I go back to my source
code -- if I go back to my
source code, I can just delete
that function because it was
just for debugging anyway.
If I run it, my app's going to
come up almost instantly.
So we just saw how to quickly
find what stack initializers are
causing you slowdowns.
This will work across multiple
dylibs, including system dylibs
that may be taking a long time
because of inputs you've given
them, such as complicated nibs.
It depends on new infrastructure
in High Sierra and iOS 11's
kernel and dyld, so you need to
be running the new builds to see
this.
And it catches most initializers
now and there's some edge cases
we're still working on adding,
but we think this is going to
allow you to quickly find out
what is taking time during your
app launch so that you get
quicker, more responsive
application launches that will
make your users happy.
Thank you.
[ Applause ]
Okay. So now I said we'd do a
brief history of dyld.
So Dynamic Linking Through the
Ages.
So originally we shipped the
first dyld -- these didn't have
version numbers, but
retroactively we're giving them
them.
And this was dyld 1 and it
shipped as part of NeXTStep 3.3
back in 1996.
Before that, NeXT used static
binaries.
And it's worth noting this
predates the POSIX dlopen calls
being standardized.
Now, dlopen did exist on some
Unix.
They were proprietary extensions
that later people adopted.
And NeXTStep had different
proprietary extensions, so
people wrote third-party
wrappers on the early versions
of macOS 10 to support standard
Unix software.
The problem was they didn't
quite support the same
semantics.
There were some weird edge cases
where it didn't work, and
ultimately they were kind of
slow.
It also was written before most
systems used large C++ dynamic
libraries, and this is
important.
C++ has a number of features,
such as how its initializer
ordering works.
And one definition rule; they
work well in a static
environment, but are actually
fairly hard to do, at least with
good performance, in a dynamic
environment.
So large C++ code bases cause
the dynamic linker to have to do
a lot of work and it was quite
slow.
We also added one other feature
before we shipped macOS 10.0,
Cheetah, and that's called
prebinding.
And for those of you in the
audience who know what
prebinding is, I know it was
kind of painful; and for the
rest of you, prebinding was a
technology where we would try to
find fixed addresses for every
dylib in the system and for your
application, and the dynamic
loader would try to load
everything at those addresses
and if it succeeded, it would
edit all of those binaries to
have those precalculated
addresses in it, and then the
next time when it put them in
the same addresses, it didn't
have to do any additional work.
And that sped up launch a lot,
but it meant that we were
editing your binaries on every
launch, and that's not great for
all sorts of reasons, not the
least of which is security.
So then came dyld 2, and we
shipped that as part of macOS
Tiger.
And dyld 2 was a complete
rewrite of dyld.
It had correct support for C++
initializer semantics, so we
slightly extended the mach-o
format and we updated dyld so
that we could get efficient C++
library support.
It also has a full native dlopen
and dlsym implementation with
correct semantics, at which
point we deprecated the Legacy
API's.
They are still on macOS.
They have never shipped on any
of our other platforms.
It was designed for speed and
because it was designed for
speed, it had limited sanity
checking.
We did not have the malware
environment we have today.
It also has security issues
because of that, that we had to
go back and retrofit in a number
of features to make it safer on
today's platforms.
Finally, because it was so much
faster we could reduce the
amount of prebinding.
Rather than editing your
applications, we just edited the
system libraries and we could do
that just at software update
times.
And if you've ever seen the
phrase optimizing system
performance appear in your
software update, that was added
to the installer to be displayed
during the time we were updating
prebinding.
Nowadays it is used for all the
optimizations, but that was the
impetus.
So we shipped dyld 2 back then
and we've done a number of
improvements over the years,
significant improvements.
First off, we've added a ton of
more architectures and
platforms.
Since dyld 2 shipped on PowerPC,
we've added x86, x86 64 arm,
arm64, and a number of
subvariants of those.
We've also shipped iOS, tvOS,
and watchOS, all of which
required significant new work in
dyld.
We've improved security in a
number of ways.
We added codesigning support, we
added some for ASLR, which is a
technology Address Space Layout
Randomization, which means that
every time you loaded the
libraries it may be at a
different address.
If you want more details on
that, last year's talk where
Nick went into extreme detail on
how we launch an app, goes into
that.
And finally, we added a
significant bounds checking to a
number of things in the mach-o
header so that you couldn't do
certain types of attach with
malformed binaries.
Finally, we improved
performance, and because we
improved performance, we could
get rid of prebinding and
replace it with something called
the shared cache.
So what is the shared cache?
Well, it was introduced in iOS
3.1 and macOS Snow Leopard, and
it completely replaced
prebinding.
It's a single file containing
most of the system dylibs.
And because we merged them into
a single file, we can do certain
types of optimizations.
We can rearrange all of their
text segments and all of their
data segments and rewrite their
entire symbol tables to reduce
the size and to make it so we
need to mount fewer regions in
each process.
It also allows us to pack binary
segments and save a lot of RAM.
It effectively is a prelinker
for the dylibs.
And while I'm not going to go
into any particular
optimizations here, the RAM
savings are substantial.
On an average iOS system, this
is the difference in about 500
megs to a gigabyte of RAM at
runtime.
It also prebuilds data
structures that dyld and Ob-C
are going to use at runtime so
that we don't have to do it on
launch.
And again, that saves more RAM
and a lot of time.
It's built locally on macOS, so
when you see optimizing system
performance, we are running
update dyld shared cache, among
things that happen, but on all
of our other platforms we
actually build it at Apple and
ship it to you.
So now that I've talked about
the shared cache, I want to move
into dyld 3.
dyld 3 is a brand-new dynamic
linker, and we're announcing it
today.
It's a complete rethink of how
we do dynamic linking and it's
going to be on by default for
most macOS system apps in this
week's seed, and it will be on
by default for all system apps
on 2017 Apple OS platforms.
We will completely replace dyld
2 in future Apple OS platforms
for all third-party apps as
well.
So why did we rewrite the
dynamic linker again?
Well, first off, performance.
In case that's not a recurring
theme, we want every ounce of
launch speed we can get.
Additionally, we thought what is
the minimum, what is the
theoretical minimum that we
could do to get an app up and
running and how could we achieve
that.
Security. So as I said, we
retrofitted a number of security
features into dyld 2, but it's
really hard to add that kind of
stuff after the fact.
I think we've done a good job
with it in recent years, but
it's really, really difficult to
do that.
And so can we have more
aggressive security checking and
be designed for security up
front?
Finally, testability and
reliability.
Can we make dyld easier to test?
So Apple ships a ton of great
testing frameworks, like XCTest,
that you should be using, and we
should be using, but they depend
on low level features of dynamic
linker to insert those libraries
into processes, so they
fundamentally cannot be used for
testing the existing dyld code,
and that also makes it harder
for us to test security and
performance features.
And so how did we do that?
Well, we've moved most of dyld
out of process.
It's now mostly just a regular
daemon and we can test that just
like everybody else does with
standard testing tools, which is
going to allow us to move even
faster in the future in
improving this.
It also lets the bit of dyld
that stays in process be as
small as possible and that
reduces the attack surface in
your applications.
It also speeds up launch because
the fastest code is code you
never write, followed closely by
code you almost never execute.
So to tell you how we did this
I'm going to briefly show how
dyld 2 launches an app.
And again, we went into this in
much more detail in last year's
talk, Optimizing App Startup
Time, so if you want to pause,
if you're watching this on
video, and go watch that, that
might be a good idea.
Or if you just want to follow
along here, I'm going to go
through it briefly.
So first off we have dyld 2 and
your app starts launching.
So we have to parse your mach-o,
and as we parse your mach-o we
find what libraries you need,
and then they may have other
libraries that they need, and we
do that recursively until we
have a complete graph of all
your dylibs, and for an average
graph of application on iOS
that's between 3- and 600
dylibs, so it's a lot of them
and a lot of work.
We then map in all the mach-o
files so we get them into your
address space.
We then perform symbol lookups,
so we actually look and say if
your application uses printf, we
go and look and see that printf
is in lib system, and we find
the address of it and we
basically copy that into a
function pointer in your
application.
Then we do what's called binding
and rebasing, which is where we
copy those pointers in and we
also -- because you're at a
random address all of your
pointers have to have that base
address added to them.
And then finally, we can run all
of your initializers, which is
what I showed the tooling for
earlier, and at that point we're
ready to call your main in
launch, and that's a lot of
work.
So how can we make this faster
and how can we move it out of
process?
Well, first off we identify the
security sensitive components.
And from our perspective the
biggest ones of those are
parsing mach-o headers and
finding dependencies because
malformed mach-o headers allow
people to do certain attacks and
your applications may use
@rpaths, which are search paths,
and by malforming those or
inserting libraries in the right
places, people can subvert
applications.
So we do all of that out of
process in the daemon, and then
we identify the expensive parts
of it, which are cache-able, and
those are the symbol lookups.
Because in a given library,
unless you perform the software
update or change the library on
disk, the symbols will always be
at the same offset in that
library.
So we've identified these.
Let me show you how they look in
dyld 3.
So we moved those all up front,
at which point we write a
closure to disk.
So as I said earlier, a launch
closure is everything you need
to launch the app.
And then we move it -- we can
use that in process later.
So dyld 3 is three components.
It's an out-of-process mach-o
parser and compiler.
It's an in-process engine that
runs launch closures, and it's a
launch closer caching service.
Most launches use the cache and
never have to invoke the
out-of-process mach-o parser or
compiler.
And launch closures are much
simpler than mach-o.
They are memory map files we
don't have to parse in any
complicated way.
We can validate them simply.
They are built for speed.
And so let's talk about each one
of those parts a little bit
more.
So dyld 3 is an out-of-process
mach-o parser.
So what does that do?
It resolves all the search
paths, all the rpaths, all the
environment variables that can
affect your launch.
Then it parses the mach-o
binaries and it performs all of
those symbol lookups.
Finally, it creates the closure
with the results, and it's that
normal daemon so that we can get
that improved testing
infrastructure.
dyld is a small in-process
engine as well, and this is the
part that will be in your
process and this is what you
will mostly see.
So all it does is it validates
that the launch closure is
correct and then it just maps in
the dylibs and jumps to main.
And one of the things you may
notice is it never needs to pars
a mach-o header or perform a
symbol lookup.
We don't have to do those to
launch your app anymore.
And since that's where we're
spending most of our time, it's
going to result in much faster
app launches for you.
Finally, dyld 3 is a launch
closure caching service.
So what does that mean?
Well, system app closures we're
just building directly into the
shared cache.
We already have this tool that
runs and analyzes every mach-o
in the system.
We can just put them directly
into the shared cache, so it's
mapped in with all the dylibs to
start with.
We don't even need to open
another file.
For third-party apps we're going
to build your closure during app
install or system updates
because at that point the system
library has changed.
So by default these will all be
prebuilt for you on iOS and tvOS
and watchOS before you even run.
On macOS, because you can side
load applications, the
in-process engine can RPC out to
the daemon if necessary on first
launch, and then after that it
will be able to use a cached
closure just like everything
else.
But like I said, that is not
necessary on any of our other
platforms.
So now that I've talked about
this dynamic linker that we'll
be using for system apps this
year and for your apps in the
future, I want to talk to you
about some potential issues you
might see with it so that you
can start updating your apps for
it now.
So first off, it is fully
compatible with dyld 2.x. So
some existing API's will cause
you to run slower or use
fallback modes in dyld 3 though,
so we'd like you to avoid those,
and we'll go into those in a
second.
Also, some existing
optimizations that you are doing
may not be necessary anymore, so
you don't have to rip them out
but, you know, it may not be
worth putting in a lot of
effort.
The other thing I want to talk
about is that we're going to
have stricter linking semantics.
So what do I mean by that?
Well, there's a lot of things
that maybe work most of the
time, but aren't actually
correct even today and so we've
identified a lot of those.
As we've been putting the new
dynamic linker in, that tends to
find all these edge cases.
So what we've been doing is
we've been putting in
workarounds for old binaries,
but we do not intend to carry
those forward.
We will do linked on or after
checks to see what SDK you were
built with and we will disable
those workarounds for new
binaries so that you move to
these improved -- you fix these
issues.
So new binaries will cause
linker issues.
So, first off, I want to talk
about unaligned pointers in your
data segments.
So what do I mean by this?
Well, when you have a global
structure that points to a
function or another global
structure, that's a pointer that
we have to fix up before you
launch, and pointers must be
naturally aligned on our system
for best performance.
And fixing up unaligned pointers
is much more complex.
They can span multiple pages,
which can cause more page faults
and other issues, and they can
have atomicity issues related to
multiprocessors.
The static linker already emits
a warning for this, ld warning,
pointer not aligned at address,
and that's an address, often
your data segments.
And if you're fixing all
warnings, you should --
hopefully you've already taken
care of this.
The seeds that we have out this
week have some issues with Swift
keypaths, but they will be fixed
so you can ignore those, but
other than that, please go and
fix these issues.
So for those of you who are
asking how would you get
something like this, I'm going
to just show you real quick.
If you don't know how, it takes
a lot of work.
You can't do it in Swift.
So again, use more Swift.
This code here will do it, so
let me show you what's going on.
First off, I have attributes
forcing specific alignment.
So by default the compiler's
going to align it correctly for
you.
But sometimes you may need
special alignments and this case
I've said change whatever the
default alignment rules are to
one, and I've done that in two
different ways just to be
really, really bad, so you have
to fix both of these.
Then I constructed a global
variable.
That global variable sets a
pointer in with the structures
and that's going to force the
dynamic linker to fix up that
pointer on launch.
So if you see code like this,
you can just remove the
alignments.
You could rearrange the
structure so that the pointer
goes first, because that's a
better alignment thing.
And there's plenty of guides
online about C structure
alignment if you want to get
into the nitty-gritty, but
hopefully you don't have to deal
with this, and if you write
Swift, you definitely don't have
to.
So next off, eager symbol
resolution.
So what do I mean by this?
So dyld 2 performs what we call
lazy symbol resolution.
So I said up front that dyld has
to load all those symbols and
that's something expensive that
we want to cache.
It's actually too expensive to
run up front on existing
applications.
It would take too long.
So instead, we use a mechanism
we call lazy symbol resolution,
where, by default, the function
pointer in your binary for,
let's say, printf, doesn't point
to printf.
By default it points to a
function in dyld that returns a
function pointer to printf.
And so when we launch, you'll
call printf, it goes into dyld,
we return what we call the
printf and call it on your
behalf the first time and then
on the second time you go
straight to printf.
But since we are caching and
calculating all these symbols up
front now, there's no additional
cost at app launch time to find
them all up front, so we are
going to do that.
Now, having said that, missing
symbols behave differently when
you do this.
On existing lazy systems, if you
are missing a symbol, the first
call -- you'll launch correctly
and the first time you call that
symbol, you'll crash.
With eager symbols you'll crash
up front.
So we do have a compatibility
mode for this, and the way we're
going to do that is that we are
going to just have a symbol
inside dyld 3 that automatically
crashes, and if we can't find
your symbol, we will bind that
symbol, so on first call you
will crash.
But again, that's how it works
on today's SDK.
If future SDK's we are going to
force all symbol resolution to
be up front.
So if you are missing a symbol,
you will crash, and that should
hopefully result in you
discovering crashes during
development instead of your
users discovering them at
runtime.
And you can simulate that
behavior now today.
There's a special linker flag
which is dyld bind at load, so
if you add this to your debug
build, as I said, it's much
slower, so please only put it in
your debug builds, but add this
to your debug builds and you'll
get more reliable behavior today
and it will get you ready for
what we're going to be doing in
dyld 3.
Again, only use that in your
test builds.
Dlopen, dlsym and dladdr.
So last year I got up here and
said please don't use them
unless you have to, but we
understand that you may have to,
and that's the same thing I'm
saying this year.
They have some problematic
semantics, but they are still
necessary in some cases.
Particularly, symbols found with
dlsym, we need to find it at
runtime.
We don't know ahead of time what
they are.
We can't do all that prefetching
and presearching.
So as soon as you use dlopen or
dlsym, we're going and we're
reading in all the pages for
your symbol table that we didn't
have to touch before.
So it's going to be a lot more
expensive.
Additionally, we might have to
RPC out to the daemon, depending
on how complicated it is.
So we're working on some better
alternatives.
We don't have those yet.
But we also need to hear about
your use cases to make sure
we're designing something that
will work for you.
So please, again, they're not
going away, but they will be
slower and we want your
feedback.
I want to take a second to talk
about dlclose specifically.
And so dlclose is a bit of a
misnomer.
It's a Unix API, so that's the
name, but on our system, if we
had been writing it, it probably
would be called dlrelease
because it doesn't actually
close the dylib.
It decrements a refcount and if
the refcount hits zero, it
closes it.
And why is that important?
Well, it's not appropriate for
resource management.
If you have a library that
attaches to a piece of hardware,
you shouldn't shut down the
hardware in response to a
dlclose because some other code
in your app may have opened it
behind your back and so now your
hardware's not shutting down.
You should have explicit
resource management.
There are also a number of
features on our platforms that
prevent dylibs from unloading,
and I'd like to go through a few
of those because maybe you do
them.
You can have Objective-C classes
in your dylib.
That will make it not
unloadable.
You could have Swift classes.
That will also make it not
unloadable.
And you can have C under bar
thread or C++ thread local
variables, all of which make it
impossible to unload a dylib.
So on macOS, where there's a
number of existing Unix apps,
obviously we will keep this
working, but because almost
every dylib on all of our other
platforms does one of these
things, effectively it hasn't
really worked on any of them
ever.
So we are considering making it
just a straight up no-op, that
will not do anything on any of
those platforms.
If there's a reason why that's a
problem, please, we want to hear
about it.
Finally, I want to talk about
the dyld all image infos.
So this is an interface for
introspecting dylibs in a
process, and it comes from the
original dyld 1.
But it's just a struct in
memory, it's not an API, and
that was okay when we had five,
ten dylibs.
But as we've gotten to 300, 400,
500 dylibs, the way it's
designed wastes a lot of memory,
and we want that memory back.
We always want our performance
and we always want our memory.
So we're going to take it away
in future releases, but we will
be providing replacement API's
for it.
And so it's very rarely used,
but if you're using it, again, I
want to know why you're using it
and how you're using it and make
sure we design API's that fit
your use case.
There are a number of bits of it
that are vestigial and don't
quite do what you expect or work
anyway today, so if you aren't
using those, they may just go
away and we need to hear about
that.
So please let us know how you
use it.
So finally, let's talk about
best practices.
First, make sure you launch your
app with bind at load in your LD
FLAGS for debug builds only.
Fix any unaligned pointers in
your data segments.
Again, this warning is there.
You should try to be fixing all
of your warnings.
If you see it with the new Swift
keypath feature, you can ignore
that because we'll fix that.
You can make sure you are not
depending on any terminators
running when you call dlclose.
And we want you to let us know
why you're using dlopen, dlsym,
dladdr, and the all image info
structures to make sure that our
replacements are going to suit
your needs.
In the case of the ones that are
part of POSIX, they will stay
around, they will just be lower
performance.
In the case of all image infos,
it is going to go away to save
that memory.
Please file bug reports using
DYLD USAGE in their titles so
that they get to us so that we
can find out all of your usage
cases that we need to support.
And for more information, you
can go to this URL.
Related sessions.
So last year we did Optimizing
App Startup Time, so you may
want to go and watch that for a
refresher on how traditional
dynamic linking works.
It goes into much more detail
than I did here since I was
trying to discuss all the new
stuff we're doing.
So thank you everybody for
coming.
I hope you've had a great WWDC.
[ Applause ]