OK, thank you Dan, your position is clear. I just hope that it will - with the current indefinite planning and no mention of JIT on the Android roadmap - not take forever before Android developers can get the JIT speed performance levels that they are used to with most Java ME based phones. If you are convinced that the relatively unknown compileClass() would only hamper development of your likely JIT implementation, then by all means drop it in favor of other (upward compatible) means to speed up the process of bridging the performance gaps. I hope that Google will not just throw it over the wall at a moment that no one is expecting it, because developers need to plan their actions too. I would dislike having to implement a temporary JNI- based solution as much as you dislike compileClass(), I suppose: effort that is largely wasted as soon as a good JIT compiler becomes available. Sharing more planning information could at least ease the developer pain here, because currently we do not have the foggiest idea when what to expect.
Regards On Dec 15, 7:25 pm, Dan Bornstein <[email protected]> wrote: > On Fri, Dec 12, 2008 at 4:01 PM, blindfold <[email protected]> wrote: > >> 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)? > > I mean implementations of the core library. You can find the Dalvik > one in the source under </dalvik/libcore/luni-kernel/>. > > > For Android it does not matter > > what the existing JVMs do with the call, because Android has its own > > VM. [...] I think that Android has full control over what > > compileClass() returns > > Yes, we control compileClass() for Android, but it still *does* > matter, because the Android effort in this area is overwhelmingly to > implement a familiar class library. Since the prevailing common > implementation leaves this method effectively unimplemented, we don't > have a compelling reason to implement it ourselves, *especially* > because implementing it would represent a significant amount of work > for no real benefit, again, because our likely JIT implementation > couldn't possibly be exercised well by using this class. > > The IBM article from 2002 that you cite in a followup talks about > using it to "prove that the JIT doesn't take any internal errors." > Given that the operation of this method in our case would be *very* > different than the usual way the JIT runs, you wouldn't actually be > able to "prove" such things in the case of Dalvik, and this would also > be true of almost every newer JIT out there. > > The Compiler class is a vestige of the early days of JIT thought, > relatively speaking, and I honestly don't know why the it hasn't been > marked officially deprecated, given that that is effectively its > status. > > -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 -~----------~----~----~----~------~----~------~--~---
