You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Aleksey Ignatenko <al...@gmail.com> on 2007/05/25 13:20:33 UTC
[drlvm][kernel]j.l.Compiler functionality is not implemeted - bug in Harmony?
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.
Re: [drlvm][kernel]j.l.Compiler functionality is not implemeted - bug in Harmony?
Posted by Aleksey Ignatenko <al...@gmail.com>.
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 <al...@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 <al...@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.
> >
>
Re: [drlvm][kernel]j.l.Compiler functionality is not implemeted - bug in Harmony?
Posted by Alexey Varlamov <al...@gmail.com>.
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 <al...@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.
>