> If we go for this sort of JIT, the effort of hooking up compileClass()
> would actually end up adding work, not reducing it.
In case of the trace-based JIT approach that you describe, you could
be right. "My" JIT proposal would act more like a JNI counterpart.
However, since most time is usually spent inside loops, you might
treat those loops as "virtual" method calls to make the difference
between method compilation and trace-based compilation of loops much
smaller, thereby reducing the work. A loop would then act like a call
to, say, a "for()" or a "while()" method, and much the same machinery
as developed for compileClass() method compilation could be reused and
retargetted.
> What I mean is that I would be surprised to find many implementations
> of java.lang.Compiler.compileClass() that didn't look like this:
>
> public boolean compileClass(Class c) { return false; }
>
> including in systems that actually do perform JIT compilation.
Are you talking about implementations of the javac compiler or
implementations of the java VM (JVM)? For Android it does not matter
what the existing JVMs do with the call, because Android has its own
VM. For the Android tool chain it only matters what javac does:
whether it preserves all compileClass() call information in the .class
files or not. *If* javac replaces the compileClass() call by a stub
that just returns false, then we are indeed badly stuck, but I do not
believe that this is what happens. The stub is only implemented in the
JVMs that we need not care about.
When I compile your sample program with javac in Sun's JDK1.6.0_05, I
get a 861 byte Comp.class. When I replace your "Compiler.compileClass
(Blah.class)" by "false" (the Sun JVM evaluation of same when running
"java Comp"), I get a 721 byte Comp.class, that is 140 bytes less. Now
you are the VM expert, but without looking into the actual bytecodes
this already suggests to me that the compileClass() call info gets
preserved in the bytecode representation, and that is all you need to
identify the set of bytecodes for optional JIT compilation in the back-
end? Maybe it is even easier to apply JIT compilation for native code
generation from the Java VM bytecodes (the .class files) instead of
trying that from the Dalvik bytecodes (.dex files) that you generate
with dx from the .class files (decompiled Java classes in general look
pretty human-readable, but I do not know if that would also hold for
decompiled Dalvik dex files, so why not take the more easy route).
> So I wouldn't rely on the return value of compileClass() to tell you
> anything meaningful.
I suspect that Android dx or the Android VM currently implements that
public boolean compileClass(Class c) { return false; }
but this is correct and fine as long as there is no JIT support in
Android. Moreover, I think that Android has full control over what
compileClass() returns, because javac will - as argued above - only
encode the call information and leave the implementation to the VM,
right? The VM is in our case the Android VM, not some java VM, so if
compileClass() currently returned true I would have to file an Android
bug report.
Thank you for your insights.
On Dec 13, 12:08 am, Dan Bornstein <[email protected]> wrote:
> On Fri, Dec 12, 2008 at 12:48 PM, blindfold <[email protected]> wrote:
> > Of course I know that a modern JIT compiler does not and should not
> > require programmer intervention, but several reply postings from
> > Android Team members have indicated that they feel that it would be
> > "very non-trivial" (hackbod) to implement this for Android with its
> > "dozen or more
> > VM-containing processes sharing a single CPU and a single pool of
> > RAM" (JBQ).
>
> > Therefore I would think it makes your life easier to first design and
> > implement a JIT compiler that gets explicitly invoked by the
> > application developer using compileClass() [...]
>
> Actually, this wouldn't make anyone's life particularly easier. For a
> JIT to do its job properly, it has to know something of the context in
> which a method is being used, and it may alter its behavior depending
> on circumstance.
>
> For example, it's entirely likely that the first incarnation of a JIT
> for Android won't even operate on whole methods, rather only compiling
> the most used loop-free "traces" through methods, thereby taking less
> memory and less time (and hence use less battery) compared to doing
> whole-method compilation. Use your favorite search engine to look up
> "trace-based jit" for further details.
>
> If we go for this sort of JIT, the effort of hooking up compileClass()
> would actually end up adding work, not reducing it.
>
> > You mean that compileClass() gets ignored/stripped by Sun's javac and
> > is not mapped to JVM bytecodes that form the input for generating
> > Dalvik bytecodes? [...]
>
> What I mean is that I would be surprised to find many implementations
> of java.lang.Compiler.compileClass() that didn't look like this:
>
> public boolean compileClass(Class c) { return false; }
>
> including in systems that actually do perform JIT compilation. So I
> wouldn't rely on the return value of compileClass() to tell you
> anything meaningful.
>
> -dan
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Android Discuss" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
