Alexey, thanks, for the complete answer. I can present the only one example of such need: put jitrino.dll into java.compiler property and you'll get unlimited possibility to compile any loaded class w/o direct call to it. It will allow to significantly improve JIT testing. E.g. it will be possible to compile all classes from any accessible JRE, applets and so on. Direct calls to unknown methods is not a good idea because of hangs and probably security issues.
Is it sufficient argument for j.l.Compiler support? Best regards, Aleksey. On 5/25/07, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
Hi Alexey, I believe the current implementation for "java.compiler" follows specification for j.l.System.getProperties() which mandates this property. And there is a bug against documentation [1], which in particular says: "As far as I know, the "java.compiler" property was only meaningful in our earlier JDK releases (pre-1.4) which included the Classic VM (now EOL'd); it could be used to specify a JIT compiler that works with the Classic VM. However, when we switched to the HotSpot VM, this property was being maintained just for compatibility reasons; the HotSpot VM simply ignores it." Your assert about java.lang.Compiler seems valid, feel free to file a JIRA. Yet, there is a suggestion to deprecate it [2], and probably it should fall into "non-bug difference" category. So until we have real-life necessity for the java.lang.Compiler API, I don't think it will be fixed. [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5043991 [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4285505 -- thanks, Alexey 2007/5/25, Aleksey Ignatenko <[EMAIL PROTECTED]>: > Hi all, I want to ask about future of j.l.Compiler class in Harmony. > > I see in drlvm kernel classes that most j.l.Compiler functions are > implemented with minimum spec requirements and do not provide any JIT > related functionality. > My question is if drlvm needs to support alternative JIT compiler using > j.l.Compiler functionality in future. The only way to effect JIT I know is > options like -Xem:opt, -Xem:jet and so on. > > Also I found that property java.compiler is set to "client" value by > default in Harmony (but not set in RI). Spec says that it is assumed to be > the name of a JIT library which is to be loaded by JVM with loadLibrary > method. After it was loaded java_lang_Compiler_start() is called to start > JIT. Can we consider this to be a bug in Harmony and file JIRA? > > Thanks, > Aleksey Ignatenko. >
