harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Ignatenko" <aleksey.ignate...@gmail.com>
Subject Re: [drlvm][kernel]j.l.Compiler functionality is not implemeted - bug in Harmony?
Date Fri, 25 May 2007 12:07:15 GMT
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

Is it sufficient argument for j.l.Compiler support?

Best regards,

On 5/25/07, Alexey Varlamov <alexey.v.varlamov@gmail.com> 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 <aleksey.ignatenko@gmail.com>:
> > 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.
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message