I've searched both the android-framework archives and Google and have
found surprisingly little information about Just in time support for
dalvik. Does Android currently have such support or is JIT planned to
be implemented in the future. After some thought I decided it might be
preferable to add an Ahead Of Time Compiler to Android, this would
increase Application installation time, but decrease application
start-up time. Is anything like this planned?

Any response is appreciated, Thank you.

--
Android Enthusiast

On Jun 27, 11:28 pm, Brian Cloutier <brian.studios.andr...@gmail.com>
wrote:

We do plan to include JIT and/or AOT compilation in a future release.

Could you elaborate on why one would implement a JIT instead of an AOT
compiler? I've wracked my brains and can't think of any situation,
ever, in which it makes sense to try and compile a statically typed
program on the fly when deadlines are strict rather than at install
time, when it's OK to take a few extra seconds to really optimize
deeply.

On Jun 29, 2:39 pm, Mike Hearn <mh.in.engl...@gmail.com> wrote:

You have to store the compiled output somewhere.  If you do a "df" on
a G1 you'll see that we're up against the wall on /system and, if you
have a modest number of apps installed, you probably don't have a lot
of free space in /data.  The bytecode expands by a factor of N, where
the exact value of N depends on how good your compiler is and whether
you're optimizing for speed or space (3-4x is somewhere in the
ballpark).  It also equates to a larger memory footprint at execution
time, which means more paging overhead or fewer apps running
concurrently.

The net result is that we only want to compile the stuff that really
needs to be compiled.  With a JIT that's easy to figure out.  For AOT
you need profiling results from a "typical" run, where determining a
typical run can be non-obvious.  You're doing essentially the same
work to get the profiling measurements for AOT and JIT, and need
similar code for the compiler, so it just turns out to be easier to
start with a JIT.

For some of the core library stuff we can make a very good guess at
what will get used a lot and what won't, so AOT is a good choice, but
the potential speed bottlenecks in the framework are largely written
in native code anyway.

OK, good point, but I thought this was really a problem with the G1
hardware only and future Android phones (like the Magic) would have a
lot more internal storage?

I suppose the RAM is a bigger problem. A 3-4x blowup in working set
would indeed hurt.

I read that the Sun JVM needs to keep a lot of bookkeeping data around
in RAM because it has to be able to "uncompile" code at any time
thanks to dynamic code loading. Being able to load classes generally
removes a lot of optimization potential, will Dalvik have a way to opt
out (or preferably opt in) for this feature to get tighter code?

Thank you for your responses

--
Android Enthusiast

On Jul 1, 4:24 am, Mike Hearn <mh.in.engl...@gmail.com> wrote:

Software expands to fill all available space. :-)

The RAM and "disk" storage on future devices will be different from
what we have now.  We picked a starting point based on the constraints
of current systems and near-future devices, but the starting point is
not the ending point.