harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eugene Ostrovsky" <eugene.s.ostrov...@gmail.com>
Subject Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Date Thu, 23 Nov 2006 14:01:08 GMT
Yes. Method_Handle would be much more convenient for VM.
Could you also provide Method_Handle for the outer method, i.e. the method
to which the inlining was made?

VM callback could be declared (for example in.in vm/include/jit_intf.h) this
way:
VMEXPORT void compile_method_load(Method_Handle method, uint32 codeSize,
                                  void* codeAddr, uint32 mapLength,
                                  AddrLocation* addrLocationMap,
                                  void* compileInfo, Method_Handle
outer_method);

The other question is how should we declare type for addrLocationMap?
Possible solution is to place it in the same .h file.
I've attached patch
H-2145-VM-Callback-interface.patch<https://issues.apache.org/jira/secure/attachment/12345558/H-2145-VM-Callback-interface.patch>to
*HARMONY-2145 <https://issues.apache.org/jira/browse/HARMONY-2145>*.

What do you think?

On 11/22/06, George Timoshenko <george.timoshenko@gmail.com> wrote:
>
> Pavel,
>
> thanks for your answers.
>
> To 'answer 2' I'd like to add that we can easily replace 'MethodDesc*'
> by 'Method_Handle' if it is more convenient. (Especially if
> compilationInterface is not available at VM side)
>
> As for 1
>
> Zeros in size are OK (it means that the reported method is empty or was
> optimized to the empty state).
> But the large numbers there are the result of a bug.
>
> Unfortunately inlinee size computation is completely incorrect.
> It is written as there are only inlinees that fits into one basic block.
> I am working on the fix right now.
>
>
> George.
>
> Pavel Ozhdikhin wrote:
> > 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