About the class preloading in the zygote

[jhc]

Hi,

I have some questions about the preloading.

From what I know, this is for reducing the launch time of apps such as
the browser.
And why its done in the zygote is to share between app processes.

But the time to do preload take about 10~12 seconds, which is a long
time.

I'm wondering is there any way we can make this process quicker.

Right now I'm trying to fork a thread in zygote to do this,
but it seems to be not allowed in the framework. Is there any document
about this?

Or we can create a service to do this in the background?

Any suggestions?

Thanks

[Jean-Baptiste Queru]

I'm not quite familiar with that part of the startup sequence, but I'm
not quite sure about what can happen in parallel with class
preloading, and class preloading must complete before zygote can fork
into a persistent process (or that'll negate some of the benefits).

JBQ

--
Jean-Baptiste M. "JBQ" Queru
Android Engineer, Google.

Questions sent directly to me that have no reason for being private
will likely get ignored or forwarded to a public forum with no further
warning.

[Dianne Hackborn]

Yeah you absolutely can  not create any threads in zygote, since it will be forking (without exec) from itself, and threads+fork == yucky mess.

Anyway, a large number of the classes it is loading will need to be loaded by the system process and some of the apps as they start during boot, so I'm not sure how much it would actually ultimately save you to not pre-load them.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

[jhc]

Thanks for the reply.

Looks like the only safe way is to cut some classes.

After removing most of the classes in the file (only leave about 14x),
the
boot up time reduces about 6 seconds. So there is still some
improvements.

Now the question is which class to cut and at what cost.

Take browser for example, if I cut the classes of ssl connection,
browser
have to load it when access https pages. But how about other apps
which use
WebView? Do they also have to load ssl related classes again?

And about another idea, because Linux shared libraries (.so) are
shared
among processes, if the loading time of a class is to initialize
shared libs
maybe we can have a separate process to trigger library initialization
instead.

Please correct me if I'm wrong.

Thanks.

of Linux share libraries, maybe it's possible

On Jul 16, 4:03 pm, Dianne Hackborn <hack...@android.com> wrote:
> Yeah you absolutely can  not create any threads in zygote, since it will be
> forking (without exec) from itself, and threads+fork == yucky mess.
>
> Anyway, a large number of the classes it is loading will need to be loaded
> by the system process and some of the apps as they start during boot, so I'm
> not sure how much it would actually ultimately save you to not pre-load
> them.
>
> On Wed, Jul 15, 2009 at 7:59 PM, Jean-Baptiste Queru <j...@android.com>wrote:
>
>
>
>
>
> > I'm not quite familiar with that part of the startup sequence, but I'm
> > not quite sure about what can happen in parallel with class
> > preloading, and class preloading must complete before zygote can fork
> > into a persistent process (or that'll negate some of the benefits).
>
> > JBQ
>

> > On Wed, Jul 15, 2009 at 7:48 PM, jhc<chenjen...@gmail.com> wrote:
>
> > > Hi,
>
> > > I have some questions about the preloading.
>
> > > From what I know, this is for reducing the launch time of apps such as
> > > the browser.
> > > And why its done in the zygote is to share between app processes.
>
> > > But the time to do preload take about 10~12 seconds, which is a long
> > > time.
>
> > > I'm wondering is there any way we can make this process quicker.
>
> > > Right now I'm trying to fork a thread in zygote to do this,
> > > but it seems to be not allowed in the framework. Is there any document
> > > about this?
>
> > > Or we can create a service to do this in the background?
>
> > > Any suggestions?
>
> > > Thanks
>
> > --
> > Jean-Baptiste M. "JBQ" Queru
> > Android Engineer, Google.
>
> > Questions sent directly to me that have no reason for being private
> > will likely get ignored or forwarded to a public forum with no further
> > warning.
>
> --
> Dianne Hackborn
> Android framework engineer

> hack...@android.com

[Jean-Baptiste Queru]

The code for the classes is already shared by virtue of being
memory-mapped. The reason behind zygote is to share as much as
possible of the common class objects and whatever is allocated by the
static initializers for those classes.

Be careful that cutting down on preloading classes doesn't speed up
the end-to-end boot process if you cut remove classes that are used
during the boot sequence. It doesn't cut on memory costs for any class
that is used by a permanent process (and it tends to slow download
launching new process and to use more memory if you're failing to
preload classes that should be).

I don't expect that we'll accept a contribution that simply removes
90+% of the list of preloaded classes, so you're probably wasting your
time (and everybody else's) on this list. Alternative scripts to
determine which classes to preload would be considered. Optimizations
in the preloading code itself would as well, but that code looks so
simple that I'd be surprised if there were many options there.

JBQ

Software Engineer, Android Open-Source Project, Google.

[Dianne Hackborn]

I'll be a little stronger -- I can't imagine us ever in the world accepting a patch that just removes a significant number of preloaded classes.  The current list was very laboriously created, using both tools that analyze class use across applications, as well as a significant amount of hand tuning, to optimize as much as possible both the startup time of apps and the per-process overhead of them.  Boot time of the system is a much lower priority than those two things (in fact often there is trade-off to be made just between process start and memory use, so juggling two tings is bad enough), and we have no interest in anything that negatively impacts those priorities for a faster boot.

So as far as you modifying the list yourself...  certainly, you are free to do so, but unless you are running hardware that has both a faster CPU and more RAM than the Dream or Sapphire devices, I would very strongly recommend against it -- those are our current minimal configurations, and being able to run well on that hardware is very closely tied to zygote doing what it does with that list.

For your extreme example, what you are going to end up doing is making app launch time significantly slower (certainly noticeable by a person), AND cause the processes to use so much more memory that few if any can be kept running in the background.  Each of these on their own is not a good thing, together they are pretty terrible.

hac...@android.com

[fadden]

Simple experiment:

Start with the original list. Boot the system and launch the
browser. Time how long this takes, and check the amount of memory
used with "procrank" (which may require a rooted device?).

You should see something like:

PID Vss Rss Pss Uss cmdline
83 34488K 25696K 11957K 10304K system_server
400 22900K 21400K 7765K 6360K com.android.browser

Note in particular the "Uss" column -- this is the amount of memory
associated with the app that is not shared with anything else. "Rss"
is the total physical memory used by the process, including shared
pages. "Pss" is a hybrid -- it's essentially Uss plus (Rss /
sharing), where "sharing" is a measure of how many things on the
system are sharing it. If a 4K page is shared by four processes, it
counts as 4K toward Rss, 1K toward Pss, and 0K toward Uss in each.

Now strip the class list down to almost nothing and repeat the
experiment.

[human android]

The memory analysis parameters seem similar to http://www.selenic.com/smem/
which is also for virtual memory system.

I wanted to know if the preloaded-classes get loaded into the zygote
COW heap? (Since Jean mentioned class objects, which reside in the
heap space as per my knowledge) In that case what is considered to be
"live" core libraries which is also shared betn zygote and other
apps.

On Jul 17, 11:19 am, fadden <fad...@android.com> wrote:
> Simple experiment:
>
> Start with the original list.  Boot the system and launch the
> browser.  Time how long this takes, and check the amount of memory
> used with "procrank" (which may require a rooted device?).
>
> You should see something like:
>
>   PID      Vss      Rss      Pss      Uss  cmdline
>    83   34488K   25696K   11957K   10304K  system_server
>   400   22900K   21400K    7765K    6360K  com.android.browser
>
> Note in particular the "Uss" column -- this is the amount of memory
> associated with the app that is not shared with anything else.  "Rss"
> is the total physical memory used by the process, including shared

> pages.  "Pss" is a hybrid -- it's essentially Uss plus (Rss /sharing), where "sharing" is a measure of how many things on the
> system aresharingit.  If a 4K page is shared by four processes, it

[fadden]

On Aug 7, 2:56 pm, human android <vanquisher.sin...@gmail.com> wrote:
> I wanted to know if the preloaded-classes get loaded into the zygote
> COW heap? (Since Jean mentioned class objects, which reside in the
> heap space as per my knowledge) In that case what is considered to be
> "live" core libraries which is also shared betn zygote and other
> apps.

Pre-loaded Class objects do live in the Zygote heap.

[vanquisher sinner]

If thats in the heap what goes in live core libraries?