Teach the android toolchain to group code called on startup

Assigned to



7 years ago
6 years ago


(Reporter: (dormant account), Assigned: espindola)



Firefox Tracking Flags

(Not tracked)




7 years ago
PGO spits out gcov files. Those should contain enough information such that the linker[and gcc] can put active functions together in the binary to reduce the number of hard page faults on startup


7 years ago
Keywords: perf


7 years ago
Blocks: 686805
I was looking at the linker scripts for elf (ld/scripttempl/elf.sc) and it does group .text.hot and .text.cold.  I don't recall exactly what was said in the meeting this morning about this arrangement; it is not sufficient for our purposes because some other measure than "we executed this code during startup and therefore it is hot" is used?  Is that right?

Is there work to be done on the GCC side (other than possibly modifying its idea of hot code as abvoe) here?  Seems like you'd just compile with -ffunction-sections and let the linker sort things out.

Rafael, you mentioned doing this with a linker plugin; would you mind sketching out how that would work?
The problem with gcov output is that it is most likely not going to mark as hot a lot of stuff running during startup because it's only being run once (all the initialization stuff), but for better startup, we do need these to be grouped as well.

When looking at the gcov generation code in gcc, I found that it should be quite easy to hook something when entering a function that would spit out the function name if it wasn't seen already, which effectively would give us the startup order.

OTOH, for something completely different, I actually ended up doing something that with some more work would be able to do that as well, using -finstrument-functions.

Now, something else that could be interesting is to know what we're running exactly once and will never run again. If there's a lot of that, and we group it, there is opportunity to free that memory once we're done using it.
> Rafael, you mentioned doing this with a linker plugin; would you mind
> sketching out how that would work?

My idea was reading the profile information. That way no changes to gcc (the compiler) should be necessary. We might still change the driver to make it easy to use.

The interface needed was added in http://sourceware.org/git/?p=binutils.git;a=commitdiff;h=317e1e07b77cd74c44ba866ac8a7ea0692e5bd9e;hp=89b2a2b111055f5f38a3d8efe57be59cecd229ec
Assignee: nobody → respindola
You need to log in before you can comment on or make changes to this bug.