harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Ozhdikhin" <pavel.ozhdik...@gmail.com>
Subject Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Date Wed, 22 Nov 2006 05:21:33 GMT
Eugene,

I can answer 2 and 3. Please see inlined.

Thanks,
Pavel


On 11/21/06, Eugene Ostrovsky <eugene.s.ostrovsky@gmail.com> wrote:
>
> George,
> I've got some problems using
> DrlVMCompilationInterface::sendCompiledMethodLoadEvent().
> Could you please clarify the following points:
> 1. This function receives very large of zero values as codeSize argument.
> I've attached test to
> *HARMONY-2145<https://issues.apache.org/jira/browse/HARMONY-2145>.
> *Could you explain what's going on?
>
> 2. How can I obtain Method_Handle from the MethodDesc*  value?


compilationInterface->getRuntimeMethodHandle(methodDesc)

3. What algorithm jit uses to inline methods? How can I create test class
> which methods will be inlined.


The inlining algorithm uses many heuristics depending on the method hotness,
code size, types etc. In brief, all often executed invocations of short
methods are inlined by Jitrino.OPT until the size of a root method exceeds a
threshold.
A simple example can be HelloWorld application where the whole sequence of
println() calls should be inlined in '-Xem:opt' mode.

On 11/13/06, George Timoshenko <george.timoshenko@gmail.com> wrote:
> >
> > There is one more "PRO" for the second approach.
> > There is already some implementation of required functionality in svn.
> > It is being controlled by exe_notify_compile_method_load flag.
> >
> > The patch with this flag attached to the JIRA issue.
> > It appends exe_notify_compile_method_load flag into the
> > OpenMethodExecutionParam struct (FALSE by default).
> >
> > When the flag is turned on code emitter runs sendCompiledMethodLoadEvent
> > for each method that was compiled during current compilation session.
> >
> > Here is the current implementation of sendCompiledMethodLoadEvent (in
> > DrlVMInterface.cpp):
> >
> > void DrlVMCompilationInterface::sendCompiledMethodLoadEvent(MethodDesc *
> > methodDesc,
> >          uint32 codeSize, void* codeAddr, uint32 mapLength,
> >          AddrLocation* addrLocationMap, void* compileInfo) {
> >
> >      // VM-JIT interface function should be called here instead of
> logging
> >      if (Log::isEnabled()) {
> >          Log::out() << "   ** Inlined method: "
> >                  << methodDesc->getName() << std::endl;
> >          Log::out() << "   ** Number of locations:" << mapLength
> >                  << std::endl;
> >      }
> > }
> >
> > sendCompiledMethodLoadEvent 's signature AFAIU is exactly the same as
> > the one from SPEC.
> >
> > So all we need IMO is to insert into sendCompiledMethodLoadEvent a call
> > to VM that raises necessary event. (as it was supposed in the comment in
> > sendCompiledMethodLoadEvent)
> >
> > Is the extension of the OpenMethodExecutionParam struct appropriate?
> >
> > Which call should be inserted into sendCompiledMethodLoadEvent at place
> > of logging?
> >
> >
> >
> >
> >
> > Eugene Ostrovsky wrote:
> > > Opended issue
> > > *HARMONY-2145<https://issues.apache.org/jira/browse/HARMONY-2145>
> > > * .
> > >
> > >
> > ....
> > >> To support the feature VM need to know about those inlined methods.
> > Right
> > >> now I can see two possible approaches:
> > >>
> > >> 1. When VM initiates method compilation, it can ask the jit about
> > methods
> > >> that were inlined to compiled method and report all of them.
> > >> 2. JIT itself can notify VM about every compiled method by calling
> some
> > >> special interface function after the method compilation.
> >
> >
>
>

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