harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George Timoshenko <george.timoshe...@gmail.com>
Subject Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Date Fri, 24 Nov 2006 04:16:31 GMT
Eugene,

Is outer_method so important, and how precise this info should be?

I mean, if there is:

methodA
   .
   .
   -> call methodB
             .
             .
             -> call methodC

and both methodB and methodC are inlined into methodA:

methodA
   .
   .
   // methodB begin
   .
   .
   // methofdC begin
   .
   .
   .
   // methodC end
   .
   .
   // methodB end
   .
   .
// methodA end

What should be the outer_method for methodC (A or B)?

(there is no problem to report it as methodA.
But it is not so easy to answer precisely that outer_method(methodC) == 
methodB in this case.)



Eugene Ostrovsky wrote:
> 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
View raw message