You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Eugene Ostrovsky <eu...@gmail.com> on 2006/11/10 13:06:07 UTC
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Hello All.
One more "hole" in current JVMTI Profiling implementation is Compiled Method
Load event.
Current VM doesn't report this event for methods that are inlined by JIT.
Though spec requires it to be sent for every compiled method:
http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#CompiledMethodLoad
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.
I'm not sure about which approach is better.
Each of them requires additional interface function (1.- to JIT from VM; 2.
- from VM to JIT).
The second approach seems to be more complicated in terms of VM - JIT
interaction. I mean that the following scheme "VM calls JIT's function to
compile method. -> JIT's function in it's turn calls VM's function to notify
about compiled methods. -> VM's function dispatches the event to TI
agents..." introduces additional level of complexity than if "VM calls JIT's
function to compile method. VM asks JIT about inlined methods. VM dispatches
event to TI agents."
Ideas & suggestions are welcome.
Thanks,
Eugene.
On 10/24/06, Eugene Ostrovsky <eu...@gmail.com> wrote:
>
> Hi all.
>
> It seems that we have most of JVMTI implemented in drlvm. Still some of
> profiling support features is left.
> I'm going to take a look on "VM Object Allocation" event.
> I'll try to come up with design tomorrow.
>
> Thanks,
> Eugene.
>
>
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by George Timoshenko <ge...@gmail.com>.
I've attached the fix of incorrect size calculation.
Now the sizes should be ok.
The possible problem I see is:
Number of Locations sometimes is 0 while codeSize is not.
It occurs when Jitrino.OPT can not determine bc_offset of an
instruction. (OPT does not add such instructions into locationMap)
Eugene Ostrovsky 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?
>
> 3. What algorithm jit uses to inline methods? How can I create test class
> which methods will be inlined.
>
>
> On 11/13/06, George Timoshenko <ge...@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.
>>
>>
>
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by George Timoshenko <ge...@gmail.com>.
The second version of JIT-side changes was attached to JIRA.
Comments are highly appreciated.
Features of the version 2:
1. Inlinees are reported according to their inline depth starting from
'1'. (see comment by Ivan Popov in the mail-list thread)
inlineDepth == 1 - means that an inlinee is inlined by the most
outer method (which is being compiled in the current compilation session.)
'outer' argument has respective value.
2. If inlinee layout has several unsuccessive regions this inlinee is
reported several times with respective 'startAddr' and 'size' arguments.
3. If Inlinee A inlines a 2 level inlinee, say, B. Locations of B are
also reported as A locations.
So some instructions appeares in several LocationMaps. The
difference is:
in the map, reported with B (first-hand owner) this locations have
valid bcOffsets (if they are available)
in the maps of later-hand owners (A in our case) bcOffsets of such
locations are always ILLEGAL
TODO:
4. LocationMap contains _all_ instructions of a method. It should be
optimized:
Now:
addr1 - bcOffset_X
addr2 - bcOffset_X
addr3 - bcOffset_X
addr4 - bcOffset_Y
Should be:
addr1 - bcOffset_X
addr4 - bcOffset_Y
which means that all instructions in [addr1;add4) interval have bcOffset
== bcOffset_X
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x23D day of Apache Harmony Ivan Popov wrote:
> I had a talk with Java profiler developers about problems with
> reporting inlined methods. The answer was that the current JVMTI specs
> are unclear in this area and different vendors may interpret them
> differently. However, it would be better if CompiledMethodLoad reports
> the whole code of the method, but not separate chunks. This would
> facilitate post processing analysis.
>
> So the suggested solution for this problem is different:
>
> 1. Report all code for a method including all inlined code from other
> methods as a continuous range in one CompiledMethodLoad event
>
> 2. Report code of each inlined method in a separate events.
sad news :(
I do not like this solution from JIT design point of view.
Let's look carefully how RI reports these cases (if they happen). And,
that would be cool to look at how popular opensource profilers handle
the situation (what are they, btw?)
BTW, JSE 6 JVMTI specs are exactly the same in this part. Which is...
> With this approach location of a native instruction can be mapped to
> several methods concurrently. It is up to JVMTI tool how to interpret
> this multiple mapping and show it to end user. Simple tools may map
> native locations to the first found method, while advanced tools may
> handle it differently and provide end user with more detailed data
> about inlined methods.
>
> Thanks.
> Ivan
>
> On 12/11/06, Ivan Popov <iv...@gmail.com> wrote:
> > I think the approach with reporting each chunk of a method code in a
> > separate event solves most problems, though this interpretation of
> > CompiledMethodLoad event may look strange. However, as JVMTI spec
> > allows several compiled instances of the same method to be presented
> > at the same time, this should not break existing JVMTI tools like Java
> > profilers.
> >
> > I'm going to discuss this with developers of a Java profiler and write
> > here if there are some hidden problems with this approach.
> >
> > Thanks.
> > Ivan
> >
> > On 11 Dec 2006 21:02:56 +0600, Egor Pasko <eg...@gmail.com> wrote:
> > > On the 0x23C day of Apache Harmony Eugene Ostrovsky wrote:
> > > > Guys,
> > > >
> > > > As far as I understand,
> > > >
> > > > 1. it is not actually a REQUIREMENT of JVMTI spec.
> > > > Spec says that "jvmtiAddrLocationMap* map" parameter could be "...NULL if
> > > > mapping information cannot be supplied...".
> > > > I.e. spec allows VM not to provide native address to location mapping if it
> > > > isn't available.
> > > >
> > > > 2. Spec says that each entry of the map specifies "... The native address
> > > > range of each entry is from start_address to start_address-1 of the next
> > > > entry...". Thus we can't report non continuous code blocks using this data
> > > > structure.
> > > >
> > > > 3. I've made an experiment with RI VM. Here's an example of the log:
> > > > ------------
> > > > CompiledMethodLoad:
> > > > method: charAt (I)C
> > > > class: Ljava/lang/String;
> > > > code_size: 195
> > > > code_addr: 00B43767
> > > > map_length: 8
> > > > map:
> > > > start_address: 00B437E0 location: 17
> > > > start_address: 00B437E3 location: 20
> > > > start_address: 00B437E9 location: 20
> > > > start_address: 00B437FB location: 31
> > > > start_address: 00B43802 location: 31
> > > > start_address: 00B4380F location: 12
> > > > start_address: 00B4381B location: 12
> > > > start_address: 00B43825 location: 17
> > > > ------------
> > >
> > > nice! thank you! So, the location might be the same for several start
> > > addresses.
> > >
> > > > As you can see map doesn't provide location info for the addresses in the
> > > > beginning of the code block [0x00B43767, 0x00B437E0) and in the end of the
> > > > code block (0x00B43825, 0x00B43767 + 195)
> > > >
> > > > In my opinion, it is reasonable to report compiled method load event for
> > > > continuous blocks of code separately.
> > >
> > > Yes, I like that too. If we are in N non-contiguous code chunks,
> > > raise N events of CompileMethodLoad. George, what do you think?
> > >
> > > > On 12/11/06, George Timoshenko <ge...@gmail.com> wrote:
> > > > >
> > > > > Egor Pasko wrote:
> > > > > > On the 0x237 day of Apache Harmony George Timoshenko wrote:
> > > > > >> Egor Pasko wrote:
> > > > > >>> On the 0x236 day of Apache Harmony George Timoshenko wrote:
> > > > > >>>> Egor Pasko wrote:
> > > > > >>>>> On the 0x235 day of Apache Harmony George Timoshenko wrote:
> > > > > >>>>>> Eugene,
> > > > > >>>>>>
> > > > > >>>>>> I've answered in JIRA:
> > > > > >>>>>>
> > > > > >>>>>> https://issues.apache.org/jira/browse/HARMONY-2145#action_12455313
> > > > > >>>>>>
> > > > > >>>>>> (Summary: Everything is OK)
> > > > > >>>>>>
> > > > > >>>>>> For this particular testcase it is possible. But there is a general
> > > > > >>>>>> problem:
> > > > > >>>>>>
> > > > > >>>>>> Code layout may be quite unordered. (It mostly depends on hottness,
> > > > > >>>>>> not the instructions<->method relations) So a method (say A) body
> > > > > >>>>>> can be layouted at two (or more) unsuccessive regions. And the
> > > > > >>>>>> regeion between them can belong to some another method (say B). And
> > > > > >>>>>> B is _not_ inlined into A.
> > > > > >>>>> That is essential, an inlined method can be separated in
> > > > > >>>>> non-contiguous regions for performance during CFG alignment. IMHO,
> > > > > we
> > > > > >>>>> should register several code blocks for the same inlined method (if
> > > > > >>>>> the method's code was split into parts) through the
> > > > > >>>>> compiled_method_load(...) interface. This can be done completely on
> > > > > >>>>> the JIT side.
> > > > > >>>>> What do you, guys, think?
> > > > > >>>> No doubts it can be done on the JIT side, but what is the purpose of
> > > > > it?
> > > > > >>>>
> > > > > >>>> If there is only one question: "I get instruction, which method does
> > > > > >>>> it belong to?" it can be answerd easily:
> > > > > >>>>
> > > > > >>>> For each method jvmtiAddrLocationMap is reported. And each
> > > > > instruction
> > > > > >>>> (with particular codeAddress) belongs to the only one such map.
> > > > > >>>>
> > > > > >>>> I do not understand the necessity of reporting each piece (a number
> > > > > of
> > > > > >>>> instructions that goes in a row and belongs to the same method) of a
> > > > > >>>> method while we are already reporting _each_instruction_ separately.
> > > > > >>> 1. is reporting _each_instruction_ effective?
> > > > > >> It is a Spec. requirement.
> > > > > >
> > > > > > could you point the exact line of the spec, please? I cannot find it
> > > > > > :(
> > > > >
> > > > > It is mentioned in HARMONY-2145 description:
> > > > >
> > > > >
> > > > > http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#CompiledMethodLoad
> > > > >
> > > > >
> > >
> > > --
> > > Egor Pasko
> > >
> > >
> >
>
--
Egor Pasko
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Ivan Popov <iv...@gmail.com>.
I had a talk with Java profiler developers about problems with
reporting inlined methods. The answer was that the current JVMTI specs
are unclear in this area and different vendors may interpret them
differently. However, it would be better if CompiledMethodLoad reports
the whole code of the method, but not separate chunks. This would
facilitate post processing analysis.
So the suggested solution for this problem is different:
1. Report all code for a method including all inlined code from other
methods as a continuous range in one CompiledMethodLoad event
2. Report code of each inlined method in a separate events.
With this approach location of a native instruction can be mapped to
several methods concurrently. It is up to JVMTI tool how to interpret
this multiple mapping and show it to end user. Simple tools may map
native locations to the first found method, while advanced tools may
handle it differently and provide end user with more detailed data
about inlined methods.
Thanks.
Ivan
On 12/11/06, Ivan Popov <iv...@gmail.com> wrote:
> I think the approach with reporting each chunk of a method code in a
> separate event solves most problems, though this interpretation of
> CompiledMethodLoad event may look strange. However, as JVMTI spec
> allows several compiled instances of the same method to be presented
> at the same time, this should not break existing JVMTI tools like Java
> profilers.
>
> I'm going to discuss this with developers of a Java profiler and write
> here if there are some hidden problems with this approach.
>
> Thanks.
> Ivan
>
> On 11 Dec 2006 21:02:56 +0600, Egor Pasko <eg...@gmail.com> wrote:
> > On the 0x23C day of Apache Harmony Eugene Ostrovsky wrote:
> > > Guys,
> > >
> > > As far as I understand,
> > >
> > > 1. it is not actually a REQUIREMENT of JVMTI spec.
> > > Spec says that "jvmtiAddrLocationMap* map" parameter could be "...NULL if
> > > mapping information cannot be supplied...".
> > > I.e. spec allows VM not to provide native address to location mapping if it
> > > isn't available.
> > >
> > > 2. Spec says that each entry of the map specifies "... The native address
> > > range of each entry is from start_address to start_address-1 of the next
> > > entry...". Thus we can't report non continuous code blocks using this data
> > > structure.
> > >
> > > 3. I've made an experiment with RI VM. Here's an example of the log:
> > > ------------
> > > CompiledMethodLoad:
> > > method: charAt (I)C
> > > class: Ljava/lang/String;
> > > code_size: 195
> > > code_addr: 00B43767
> > > map_length: 8
> > > map:
> > > start_address: 00B437E0 location: 17
> > > start_address: 00B437E3 location: 20
> > > start_address: 00B437E9 location: 20
> > > start_address: 00B437FB location: 31
> > > start_address: 00B43802 location: 31
> > > start_address: 00B4380F location: 12
> > > start_address: 00B4381B location: 12
> > > start_address: 00B43825 location: 17
> > > ------------
> >
> > nice! thank you! So, the location might be the same for several start
> > addresses.
> >
> > > As you can see map doesn't provide location info for the addresses in the
> > > beginning of the code block [0x00B43767, 0x00B437E0) and in the end of the
> > > code block (0x00B43825, 0x00B43767 + 195)
> > >
> > > In my opinion, it is reasonable to report compiled method load event for
> > > continuous blocks of code separately.
> >
> > Yes, I like that too. If we are in N non-contiguous code chunks,
> > raise N events of CompileMethodLoad. George, what do you think?
> >
> > > On 12/11/06, George Timoshenko <ge...@gmail.com> wrote:
> > > >
> > > > Egor Pasko wrote:
> > > > > On the 0x237 day of Apache Harmony George Timoshenko wrote:
> > > > >> Egor Pasko wrote:
> > > > >>> On the 0x236 day of Apache Harmony George Timoshenko wrote:
> > > > >>>> Egor Pasko wrote:
> > > > >>>>> On the 0x235 day of Apache Harmony George Timoshenko wrote:
> > > > >>>>>> Eugene,
> > > > >>>>>>
> > > > >>>>>> I've answered in JIRA:
> > > > >>>>>>
> > > > >>>>>> https://issues.apache.org/jira/browse/HARMONY-2145#action_12455313
> > > > >>>>>>
> > > > >>>>>> (Summary: Everything is OK)
> > > > >>>>>>
> > > > >>>>>> For this particular testcase it is possible. But there is a general
> > > > >>>>>> problem:
> > > > >>>>>>
> > > > >>>>>> Code layout may be quite unordered. (It mostly depends on hottness,
> > > > >>>>>> not the instructions<->method relations) So a method (say A) body
> > > > >>>>>> can be layouted at two (or more) unsuccessive regions. And the
> > > > >>>>>> regeion between them can belong to some another method (say B). And
> > > > >>>>>> B is _not_ inlined into A.
> > > > >>>>> That is essential, an inlined method can be separated in
> > > > >>>>> non-contiguous regions for performance during CFG alignment. IMHO,
> > > > we
> > > > >>>>> should register several code blocks for the same inlined method (if
> > > > >>>>> the method's code was split into parts) through the
> > > > >>>>> compiled_method_load(...) interface. This can be done completely on
> > > > >>>>> the JIT side.
> > > > >>>>> What do you, guys, think?
> > > > >>>> No doubts it can be done on the JIT side, but what is the purpose of
> > > > it?
> > > > >>>>
> > > > >>>> If there is only one question: "I get instruction, which method does
> > > > >>>> it belong to?" it can be answerd easily:
> > > > >>>>
> > > > >>>> For each method jvmtiAddrLocationMap is reported. And each
> > > > instruction
> > > > >>>> (with particular codeAddress) belongs to the only one such map.
> > > > >>>>
> > > > >>>> I do not understand the necessity of reporting each piece (a number
> > > > of
> > > > >>>> instructions that goes in a row and belongs to the same method) of a
> > > > >>>> method while we are already reporting _each_instruction_ separately.
> > > > >>> 1. is reporting _each_instruction_ effective?
> > > > >> It is a Spec. requirement.
> > > > >
> > > > > could you point the exact line of the spec, please? I cannot find it
> > > > > :(
> > > >
> > > > It is mentioned in HARMONY-2145 description:
> > > >
> > > >
> > > > http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#CompiledMethodLoad
> > > >
> > > >
> >
> > --
> > Egor Pasko
> >
> >
>
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Ivan Popov <iv...@gmail.com>.
I think the approach with reporting each chunk of a method code in a
separate event solves most problems, though this interpretation of
CompiledMethodLoad event may look strange. However, as JVMTI spec
allows several compiled instances of the same method to be presented
at the same time, this should not break existing JVMTI tools like Java
profilers.
I'm going to discuss this with developers of a Java profiler and write
here if there are some hidden problems with this approach.
Thanks.
Ivan
On 11 Dec 2006 21:02:56 +0600, Egor Pasko <eg...@gmail.com> wrote:
> On the 0x23C day of Apache Harmony Eugene Ostrovsky wrote:
> > Guys,
> >
> > As far as I understand,
> >
> > 1. it is not actually a REQUIREMENT of JVMTI spec.
> > Spec says that "jvmtiAddrLocationMap* map" parameter could be "...NULL if
> > mapping information cannot be supplied...".
> > I.e. spec allows VM not to provide native address to location mapping if it
> > isn't available.
> >
> > 2. Spec says that each entry of the map specifies "... The native address
> > range of each entry is from start_address to start_address-1 of the next
> > entry...". Thus we can't report non continuous code blocks using this data
> > structure.
> >
> > 3. I've made an experiment with RI VM. Here's an example of the log:
> > ------------
> > CompiledMethodLoad:
> > method: charAt (I)C
> > class: Ljava/lang/String;
> > code_size: 195
> > code_addr: 00B43767
> > map_length: 8
> > map:
> > start_address: 00B437E0 location: 17
> > start_address: 00B437E3 location: 20
> > start_address: 00B437E9 location: 20
> > start_address: 00B437FB location: 31
> > start_address: 00B43802 location: 31
> > start_address: 00B4380F location: 12
> > start_address: 00B4381B location: 12
> > start_address: 00B43825 location: 17
> > ------------
>
> nice! thank you! So, the location might be the same for several start
> addresses.
>
> > As you can see map doesn't provide location info for the addresses in the
> > beginning of the code block [0x00B43767, 0x00B437E0) and in the end of the
> > code block (0x00B43825, 0x00B43767 + 195)
> >
> > In my opinion, it is reasonable to report compiled method load event for
> > continuous blocks of code separately.
>
> Yes, I like that too. If we are in N non-contiguous code chunks,
> raise N events of CompileMethodLoad. George, what do you think?
>
> > On 12/11/06, George Timoshenko <ge...@gmail.com> wrote:
> > >
> > > Egor Pasko wrote:
> > > > On the 0x237 day of Apache Harmony George Timoshenko wrote:
> > > >> Egor Pasko wrote:
> > > >>> On the 0x236 day of Apache Harmony George Timoshenko wrote:
> > > >>>> Egor Pasko wrote:
> > > >>>>> On the 0x235 day of Apache Harmony George Timoshenko wrote:
> > > >>>>>> Eugene,
> > > >>>>>>
> > > >>>>>> I've answered in JIRA:
> > > >>>>>>
> > > >>>>>> https://issues.apache.org/jira/browse/HARMONY-2145#action_12455313
> > > >>>>>>
> > > >>>>>> (Summary: Everything is OK)
> > > >>>>>>
> > > >>>>>> For this particular testcase it is possible. But there is a general
> > > >>>>>> problem:
> > > >>>>>>
> > > >>>>>> Code layout may be quite unordered. (It mostly depends on hottness,
> > > >>>>>> not the instructions<->method relations) So a method (say A) body
> > > >>>>>> can be layouted at two (or more) unsuccessive regions. And the
> > > >>>>>> regeion between them can belong to some another method (say B). And
> > > >>>>>> B is _not_ inlined into A.
> > > >>>>> That is essential, an inlined method can be separated in
> > > >>>>> non-contiguous regions for performance during CFG alignment. IMHO,
> > > we
> > > >>>>> should register several code blocks for the same inlined method (if
> > > >>>>> the method's code was split into parts) through the
> > > >>>>> compiled_method_load(...) interface. This can be done completely on
> > > >>>>> the JIT side.
> > > >>>>> What do you, guys, think?
> > > >>>> No doubts it can be done on the JIT side, but what is the purpose of
> > > it?
> > > >>>>
> > > >>>> If there is only one question: "I get instruction, which method does
> > > >>>> it belong to?" it can be answerd easily:
> > > >>>>
> > > >>>> For each method jvmtiAddrLocationMap is reported. And each
> > > instruction
> > > >>>> (with particular codeAddress) belongs to the only one such map.
> > > >>>>
> > > >>>> I do not understand the necessity of reporting each piece (a number
> > > of
> > > >>>> instructions that goes in a row and belongs to the same method) of a
> > > >>>> method while we are already reporting _each_instruction_ separately.
> > > >>> 1. is reporting _each_instruction_ effective?
> > > >> It is a Spec. requirement.
> > > >
> > > > could you point the exact line of the spec, please? I cannot find it
> > > > :(
> > >
> > > It is mentioned in HARMONY-2145 description:
> > >
> > >
> > > http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#CompiledMethodLoad
> > >
> > >
>
> --
> Egor Pasko
>
>
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Ivan Popov <iv...@gmail.com>.
Eugene,
Is it possible to use your test to find a method with inlined code of
other methods and see how RI reports this code?
Thanks.
Ivan
On 12/11/06, Eugene Ostrovsky <eu...@gmail.com> wrote:
> Guys,
>
> As far as I understand,
>
> 1. it is not actually a REQUIREMENT of JVMTI spec.
> Spec says that "jvmtiAddrLocationMap* map" parameter could be "...NULL if
> mapping information cannot be supplied...".
> I.e. spec allows VM not to provide native address to location mapping if it
> isn't available.
>
> 2. Spec says that each entry of the map specifies "... The native address
> range of each entry is from start_address to start_address-1 of the next
> entry...". Thus we can't report non continuous code blocks using this data
> structure.
>
> 3. I've made an experiment with RI VM. Here's an example of the log:
> ------------
> CompiledMethodLoad:
> method: charAt (I)C
> class: Ljava/lang/String;
> code_size: 195
> code_addr: 00B43767
> map_length: 8
> map:
> start_address: 00B437E0 location: 17
> start_address: 00B437E3 location: 20
> start_address: 00B437E9 location: 20
> start_address: 00B437FB location: 31
> start_address: 00B43802 location: 31
> start_address: 00B4380F location: 12
> start_address: 00B4381B location: 12
> start_address: 00B43825 location: 17
> ------------
>
> As you can see map doesn't provide location info for the addresses in the
> beginning of the code block [0x00B43767, 0x00B437E0) and in the end of the
> code block (0x00B43825, 0x00B43767 + 195)
>
> In my opinion, it is reasonable to report compiled method load event for
> continuous blocks of code separately.
>
> Thanks,
> Eugene.
>
> On 12/11/06, George Timoshenko <ge...@gmail.com> wrote:
> >
> > Egor Pasko wrote:
> > > On the 0x237 day of Apache Harmony George Timoshenko wrote:
> > >> Egor Pasko wrote:
> > >>> On the 0x236 day of Apache Harmony George Timoshenko wrote:
> > >>>> Egor Pasko wrote:
> > >>>>> On the 0x235 day of Apache Harmony George Timoshenko wrote:
> > >>>>>> Eugene,
> > >>>>>>
> > >>>>>> I've answered in JIRA:
> > >>>>>>
> > >>>>>> https://issues.apache.org/jira/browse/HARMONY-2145#action_12455313
> > >>>>>>
> > >>>>>> (Summary: Everything is OK)
> > >>>>>>
> > >>>>>> For this particular testcase it is possible. But there is a general
> > >>>>>> problem:
> > >>>>>>
> > >>>>>> Code layout may be quite unordered. (It mostly depends on hottness,
> > >>>>>> not the instructions<->method relations) So a method (say A) body
> > >>>>>> can be layouted at two (or more) unsuccessive regions. And the
> > >>>>>> regeion between them can belong to some another method (say B). And
> > >>>>>> B is _not_ inlined into A.
> > >>>>> That is essential, an inlined method can be separated in
> > >>>>> non-contiguous regions for performance during CFG alignment. IMHO,
> > we
> > >>>>> should register several code blocks for the same inlined method (if
> > >>>>> the method's code was split into parts) through the
> > >>>>> compiled_method_load(...) interface. This can be done completely on
> > >>>>> the JIT side.
> > >>>>> What do you, guys, think?
> > >>>> No doubts it can be done on the JIT side, but what is the purpose of
> > it?
> > >>>>
> > >>>> If there is only one question: "I get instruction, which method does
> > >>>> it belong to?" it can be answerd easily:
> > >>>>
> > >>>> For each method jvmtiAddrLocationMap is reported. And each
> > instruction
> > >>>> (with particular codeAddress) belongs to the only one such map.
> > >>>>
> > >>>> I do not understand the necessity of reporting each piece (a number
> > of
> > >>>> instructions that goes in a row and belongs to the same method) of a
> > >>>> method while we are already reporting _each_instruction_ separately.
> > >>> 1. is reporting _each_instruction_ effective?
> > >> It is a Spec. requirement.
> > >
> > > could you point the exact line of the spec, please? I cannot find it
> > > :(
> >
> > It is mentioned in HARMONY-2145 description:
> >
> >
> > http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#CompiledMethodLoad
> >
> >
>
>
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x23C day of Apache Harmony Eugene Ostrovsky wrote:
> Guys,
>
> As far as I understand,
>
> 1. it is not actually a REQUIREMENT of JVMTI spec.
> Spec says that "jvmtiAddrLocationMap* map" parameter could be "...NULL if
> mapping information cannot be supplied...".
> I.e. spec allows VM not to provide native address to location mapping if it
> isn't available.
>
> 2. Spec says that each entry of the map specifies "... The native address
> range of each entry is from start_address to start_address-1 of the next
> entry...". Thus we can't report non continuous code blocks using this data
> structure.
>
> 3. I've made an experiment with RI VM. Here's an example of the log:
> ------------
> CompiledMethodLoad:
> method: charAt (I)C
> class: Ljava/lang/String;
> code_size: 195
> code_addr: 00B43767
> map_length: 8
> map:
> start_address: 00B437E0 location: 17
> start_address: 00B437E3 location: 20
> start_address: 00B437E9 location: 20
> start_address: 00B437FB location: 31
> start_address: 00B43802 location: 31
> start_address: 00B4380F location: 12
> start_address: 00B4381B location: 12
> start_address: 00B43825 location: 17
> ------------
nice! thank you! So, the location might be the same for several start
addresses.
> As you can see map doesn't provide location info for the addresses in the
> beginning of the code block [0x00B43767, 0x00B437E0) and in the end of the
> code block (0x00B43825, 0x00B43767 + 195)
>
> In my opinion, it is reasonable to report compiled method load event for
> continuous blocks of code separately.
Yes, I like that too. If we are in N non-contiguous code chunks,
raise N events of CompileMethodLoad. George, what do you think?
> On 12/11/06, George Timoshenko <ge...@gmail.com> wrote:
> >
> > Egor Pasko wrote:
> > > On the 0x237 day of Apache Harmony George Timoshenko wrote:
> > >> Egor Pasko wrote:
> > >>> On the 0x236 day of Apache Harmony George Timoshenko wrote:
> > >>>> Egor Pasko wrote:
> > >>>>> On the 0x235 day of Apache Harmony George Timoshenko wrote:
> > >>>>>> Eugene,
> > >>>>>>
> > >>>>>> I've answered in JIRA:
> > >>>>>>
> > >>>>>> https://issues.apache.org/jira/browse/HARMONY-2145#action_12455313
> > >>>>>>
> > >>>>>> (Summary: Everything is OK)
> > >>>>>>
> > >>>>>> For this particular testcase it is possible. But there is a general
> > >>>>>> problem:
> > >>>>>>
> > >>>>>> Code layout may be quite unordered. (It mostly depends on hottness,
> > >>>>>> not the instructions<->method relations) So a method (say A) body
> > >>>>>> can be layouted at two (or more) unsuccessive regions. And the
> > >>>>>> regeion between them can belong to some another method (say B). And
> > >>>>>> B is _not_ inlined into A.
> > >>>>> That is essential, an inlined method can be separated in
> > >>>>> non-contiguous regions for performance during CFG alignment. IMHO,
> > we
> > >>>>> should register several code blocks for the same inlined method (if
> > >>>>> the method's code was split into parts) through the
> > >>>>> compiled_method_load(...) interface. This can be done completely on
> > >>>>> the JIT side.
> > >>>>> What do you, guys, think?
> > >>>> No doubts it can be done on the JIT side, but what is the purpose of
> > it?
> > >>>>
> > >>>> If there is only one question: "I get instruction, which method does
> > >>>> it belong to?" it can be answerd easily:
> > >>>>
> > >>>> For each method jvmtiAddrLocationMap is reported. And each
> > instruction
> > >>>> (with particular codeAddress) belongs to the only one such map.
> > >>>>
> > >>>> I do not understand the necessity of reporting each piece (a number
> > of
> > >>>> instructions that goes in a row and belongs to the same method) of a
> > >>>> method while we are already reporting _each_instruction_ separately.
> > >>> 1. is reporting _each_instruction_ effective?
> > >> It is a Spec. requirement.
> > >
> > > could you point the exact line of the spec, please? I cannot find it
> > > :(
> >
> > It is mentioned in HARMONY-2145 description:
> >
> >
> > http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#CompiledMethodLoad
> >
> >
--
Egor Pasko
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Eugene Ostrovsky <eu...@gmail.com>.
Guys,
As far as I understand,
1. it is not actually a REQUIREMENT of JVMTI spec.
Spec says that "jvmtiAddrLocationMap* map" parameter could be "...NULL if
mapping information cannot be supplied...".
I.e. spec allows VM not to provide native address to location mapping if it
isn't available.
2. Spec says that each entry of the map specifies "... The native address
range of each entry is from start_address to start_address-1 of the next
entry...". Thus we can't report non continuous code blocks using this data
structure.
3. I've made an experiment with RI VM. Here's an example of the log:
------------
CompiledMethodLoad:
method: charAt (I)C
class: Ljava/lang/String;
code_size: 195
code_addr: 00B43767
map_length: 8
map:
start_address: 00B437E0 location: 17
start_address: 00B437E3 location: 20
start_address: 00B437E9 location: 20
start_address: 00B437FB location: 31
start_address: 00B43802 location: 31
start_address: 00B4380F location: 12
start_address: 00B4381B location: 12
start_address: 00B43825 location: 17
------------
As you can see map doesn't provide location info for the addresses in the
beginning of the code block [0x00B43767, 0x00B437E0) and in the end of the
code block (0x00B43825, 0x00B43767 + 195)
In my opinion, it is reasonable to report compiled method load event for
continuous blocks of code separately.
Thanks,
Eugene.
On 12/11/06, George Timoshenko <ge...@gmail.com> wrote:
>
> Egor Pasko wrote:
> > On the 0x237 day of Apache Harmony George Timoshenko wrote:
> >> Egor Pasko wrote:
> >>> On the 0x236 day of Apache Harmony George Timoshenko wrote:
> >>>> Egor Pasko wrote:
> >>>>> On the 0x235 day of Apache Harmony George Timoshenko wrote:
> >>>>>> Eugene,
> >>>>>>
> >>>>>> I've answered in JIRA:
> >>>>>>
> >>>>>> https://issues.apache.org/jira/browse/HARMONY-2145#action_12455313
> >>>>>>
> >>>>>> (Summary: Everything is OK)
> >>>>>>
> >>>>>> For this particular testcase it is possible. But there is a general
> >>>>>> problem:
> >>>>>>
> >>>>>> Code layout may be quite unordered. (It mostly depends on hottness,
> >>>>>> not the instructions<->method relations) So a method (say A) body
> >>>>>> can be layouted at two (or more) unsuccessive regions. And the
> >>>>>> regeion between them can belong to some another method (say B). And
> >>>>>> B is _not_ inlined into A.
> >>>>> That is essential, an inlined method can be separated in
> >>>>> non-contiguous regions for performance during CFG alignment. IMHO,
> we
> >>>>> should register several code blocks for the same inlined method (if
> >>>>> the method's code was split into parts) through the
> >>>>> compiled_method_load(...) interface. This can be done completely on
> >>>>> the JIT side.
> >>>>> What do you, guys, think?
> >>>> No doubts it can be done on the JIT side, but what is the purpose of
> it?
> >>>>
> >>>> If there is only one question: "I get instruction, which method does
> >>>> it belong to?" it can be answerd easily:
> >>>>
> >>>> For each method jvmtiAddrLocationMap is reported. And each
> instruction
> >>>> (with particular codeAddress) belongs to the only one such map.
> >>>>
> >>>> I do not understand the necessity of reporting each piece (a number
> of
> >>>> instructions that goes in a row and belongs to the same method) of a
> >>>> method while we are already reporting _each_instruction_ separately.
> >>> 1. is reporting _each_instruction_ effective?
> >> It is a Spec. requirement.
> >
> > could you point the exact line of the spec, please? I cannot find it
> > :(
>
> It is mentioned in HARMONY-2145 description:
>
>
> http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#CompiledMethodLoad
>
>
RE: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by "Elford, Chris L" <ch...@intel.com>.
My biggest concern in this thread relates to what happens when advanced
JIT optimizations with common subexpression eliminationand code motion
are applied after the basic inlining has been applied. You may end up
with a situation where:
(a) You have to generate hundreds of CML events to describe the movement
of code from the different inlined components. Even then, the JVMTI
specification for CML is a poor vehicle to expose multilayered inlining.
(b) You end up with ambiguity where a given assembly address may
correspond to more than one of the inlined methods [e.g., common
subexpression elimination]. Having the JIT preserve full information in
the presence of optimizations will be difficult.
These complexities may be why the other VMs don't report inlining events
today even though they are called out in the spec. One option would be
to report just the outermost method like the RI using the JVMTI
interface and provide a richer JVMTI extension interface that actually
exposes the full inlining hierarchy in a single event. Standardizing
such an enhanced interface might be of value if future JCP discussions
of the profiling interface.
Changing gears a bit, as someone who has extensively consumed JVMPI and
JVMTI CML and DCG events from different VMs, I can state a few things
about consuming them on different VMs.
Different VMs have different levels of rigor which which they report
class loads & unloads, method jits and invalidations. In a well
structured environment, you would be guaranteed that before an address
was recycled by a new method that the old method would be unloaded with
an unload event. I have seen many times where this rule is violated.
As a consequence for my engineering tools, I typically check for address
overlap with previous JIT events as indicating that the previous JIT has
been unloaded without being reported rather than as an indicator that
the new jit is inlined into the old JIT. Certainly, one could special
case Harmony tools to not treat it this way.
I don't have strong feelings regarding sending multiple CML for each
disjoint portion of the method. It's a bit ambiguous in the JVMTI
specification. It will make it a bit difficult for me to provide
statistics that track how many times a given method has been JITTed
using the occurances of CML. Imagine a VM that "gos crazy" and
accidentally jit methods many many times. Imagine a VM that "goes
crazy" and JITs new versions back to back (or concurrently). Using CML
timings and counts, one can diagnose this and other types of situations.
When CMLs are sent for each disjoint region, such statistics no longer
have the same meaning and I am not 100% sure how to do that type of
analysis.
One could work around this by taking advantage of the "compile_info"
field of CML. This is VM specific mechanism to provide more details.
To be honest, I've never looked at this value but it could be a way to
report that a CML is an inline or a "partial" method... Just a
thought... I think Harmony could do something clever here...
Finally, to speak to Ivan's comment regarding the ordering of events...
If the address ranges of the CMLs do NOT overlap, I have no strong
feelings about the ordering. If we do figure a way to use the
compile_info field, the ordering should be consistent with the use of
that field. If the address ranges DO overlap [e.g., the outermost
method claiming the entire address space and the inline events claiming
interior chunks], I'd ask that the outermost method CML be sent FIRST
and treat subsequent ones as "overrides" for portions of the address
space.
Thanks,
Chris Elford
Intel SSG/Enterprise Solutions Software Division
-----Original Message-----
From: Ivan Popov [mailto:ivan.g.popov@gmail.com]
Sent: Tuesday, December 19, 2006 10:12 AM
To: dev@harmony.apache.org
Subject: Re: [drlvm][jvmti] Profiling support - Compiled Method Load
event
Since DRLVM seems the unique JVM implementation that reports inlined
methods, it was proposed to document the order in which inlined
methods are reported with COMPILED_METHOD_LOAD events - from the most
wrapping method to the most inlined ones or vise versa. This will
allow to adjust JVMTI tools for handling inlined methods correctly.
Thanks.
Ivan
On 12/18/06, Eugene Ostrovsky <eu...@gmail.com> wrote:
> Let me propose the following design:
>
> Compiled method load event. More precise specification for inlined
methods.
> 1. CML event must be sent for every method compiled by JIT.
> If compiled method code is disposed in several disconnected regions
each of
> them must be reported by separate CML event.
> Each region location is described by code_addr and code_size
parameters.
> Native addresses to bytecode location correspondence should be
described in
> map parameter if this information is available. If compiled method
code
> contains code blocks of inlined methods the addresses of those blocks
should
> be associated with the location of corresponding invoke bytecode
> instruction.
> 2. If compiled method code region was inlined within the code region
of the
> outer method it should be reported by separate CML event. Inlined
method
> code region must be enclosed within one of the outer method's code
regions.
> I.e. outer.start <= inlined.start < inlined.end <= outer.end (where
> method.start = code_addr , method.end = code_addr + code_size - 1)
> 3. According to #1 and #2 any two of reported regions (R1, R2) may by
> enclosed one by other (in case of inlining) but must not overlap (i.e.
> R1.start < R2.start <= R1.end < R2.end condition must not be true).
>
> Is it clear enough?
> What do you think?
>
> On 15 Dec 2006 18:36:22 +0600, Egor Pasko <eg...@gmail.com>
wrote:
> >
> > On the 0x240 day of Apache Harmony Eugene Ostrovsky wrote:
> > > I experimented with sun and bea vms.
> >
> > did you try HotSpot for JSE 6 (with attach anytime feature)?
> >
> > > None of them report inlined methods.
> > >
> > > Thus we need to make a decision by ourselves.
> >
> > :) yes
> >
> > > On 14 Dec 2006 16:14:49 +0600, Egor Pasko <eg...@gmail.com>
wrote:
> > > >
> > > > On the 0x23F day of Apache Harmony Eugene Ostrovsky wrote:
> > > > > I'll try to make test to investigate RI behavior.
> > > >
> > > > thank you thank you thank you
> > > >
> > > > > On 13 Dec 2006 16:34:46 +0600, Egor Pasko
<eg...@gmail.com>
> > wrote:
> > > > > >
> > > > > > On the 0x23E day of Apache Harmony George Timoshenko wrote:
> > > > > > > Egor,
> > > > > > >
> > > > > > > thanks for clear scheme.
> > > > > > >
> > > > > > > In your terms I'd do something like this:
> > > > > > >
> > > > > > > * firstly - raise event for X:
> > > > > > > CompiledMethodLoad(start=X.1.start,
> > > > > > > method_size=X.1.size + X.2.size,
> > > > > > > addr_loc_map=
> > > > > > > [X.1.start -> bcoff1,
> > > > > > > X.2.start -> bcoff2])
> > > > > > > * secondly - raise event for Y:
> > > > > > > CompiledMethodLoad(start=Y.1.start,
> > > > > > > method_size=Y.1.size,
> > > > > > > addr_loc_map=
> > > > > > > [Y.1.start -> bcoff_Y])
> > > > > >
> > > > > > good question!
> > > > > >
> > > > > > IMHO, code_addr and code_size outlines a region where method
code
> > is
> > > > > > contained. In that case VM can quickly tell which method the
IP
> > > > > > (instruction pointer) belongs to. So, I intentionally
suggested
> > > > > > code_size=(X.1.size + Y.1.size + X.2.size) instead of
(X.1.size +
> > > > > > X.2.size).
> > > > > >
> > > > > > BTW, Eugene, do you have some important observations of the
RI
> > > > > > behaviour for us?
> > > > > >
> > > > > > > > For example, we have
> > > > > > > > some chinks of methods X and Y intermixed like this:
> > > > > > > > "X.1,Y.1,X.2". To overcome we may:
> > > > > > > > * raise a single event for X:
> > > > > > > > CompiledMethodLoad(start=X.1.start,
> > > > > > > > method_size=X.1.size + Y.1.size
+
> > X.2.size
> > > > ,
> > > > > > > > addr_loc_map=
> > > > > > > > [X.1.start -> bcoff1,
> > > > > > > > Y.1.start -> 0,
> > > > > > > > X.2.start -> bcoff2])
> > > > > > > > * raise 2 events for X:
> > > > > > > > CompiledMethodLoad(start=X.1.start,
> > > > > > > > method_size=X.1.size,
> > > > > > > > addr_loc_map=
> > > > > > > > [X.1.start -> bcoff1])
> > > > > > > > CompiledMethodLoad(start=X.2.start,
> > > > > > > > method_size=X.2.size,
> > > > > > > > addr_loc_map=
> > > > > > > > [X.2.start -> bcoff2])
> > > > > > > >
> > > > > > > > I would highly appreciate if some JVMTI guru steps down
from
> > > > Olymp
> > > > > > and
> > > > > > > > tells which of two is the best, or at least says what
RI does
> > in
> > > > that
> > > > > > > > case (or, maybe, RI does not generate non-contigous
blocks?)
> > > > > > > >
> > > > > > > > I like the second approach (raise 2 events)
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Egor Pasko
> > > > > >
> > > > > >
> > > >
> > > > --
> > > > Egor Pasko
> > > >
> > > >
> >
> > --
> > Egor Pasko
> >
> >
>
>
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x245 day of Apache Harmony Ivan Popov wrote:
> Since DRLVM seems the unique JVM implementation that reports inlined
> methods, it was proposed to document the order in which inlined
> methods are reported with COMPILED_METHOD_LOAD events - from the most
> wrapping method to the most inlined ones or vise versa. This will
> allow to adjust JVMTI tools for handling inlined methods correctly.
good idea!
> Thanks.
> Ivan
>
> On 12/18/06, Eugene Ostrovsky <eu...@gmail.com> wrote:
> > Let me propose the following design:
> >
> > Compiled method load event. More precise specification for inlined methods.
> > 1. CML event must be sent for every method compiled by JIT.
> > If compiled method code is disposed in several disconnected regions each of
> > them must be reported by separate CML event.
> > Each region location is described by code_addr and code_size parameters.
> > Native addresses to bytecode location correspondence should be described in
> > map parameter if this information is available. If compiled method code
> > contains code blocks of inlined methods the addresses of those blocks should
> > be associated with the location of corresponding invoke bytecode
> > instruction.
> > 2. If compiled method code region was inlined within the code region of the
> > outer method it should be reported by separate CML event. Inlined method
> > code region must be enclosed within one of the outer method's code regions.
> > I.e. outer.start <= inlined.start < inlined.end <= outer.end (where
> > method.start = code_addr , method.end = code_addr + code_size - 1)
> > 3. According to #1 and #2 any two of reported regions (R1, R2) may by
> > enclosed one by other (in case of inlining) but must not overlap (i.e.
> > R1.start < R2.start <= R1.end < R2.end condition must not be true).
> >
> > Is it clear enough?
> > What do you think?
> >
> > On 15 Dec 2006 18:36:22 +0600, Egor Pasko <eg...@gmail.com> wrote:
> > >
> > > On the 0x240 day of Apache Harmony Eugene Ostrovsky wrote:
> > > > I experimented with sun and bea vms.
> > >
> > > did you try HotSpot for JSE 6 (with attach anytime feature)?
> > >
> > > > None of them report inlined methods.
> > > >
> > > > Thus we need to make a decision by ourselves.
> > >
> > > :) yes
> > >
> > > > On 14 Dec 2006 16:14:49 +0600, Egor Pasko <eg...@gmail.com> wrote:
> > > > >
> > > > > On the 0x23F day of Apache Harmony Eugene Ostrovsky wrote:
> > > > > > I'll try to make test to investigate RI behavior.
> > > > >
> > > > > thank you thank you thank you
> > > > >
> > > > > > On 13 Dec 2006 16:34:46 +0600, Egor Pasko <eg...@gmail.com>
> > > wrote:
> > > > > > >
> > > > > > > On the 0x23E day of Apache Harmony George Timoshenko wrote:
> > > > > > > > Egor,
> > > > > > > >
> > > > > > > > thanks for clear scheme.
> > > > > > > >
> > > > > > > > In your terms I'd do something like this:
> > > > > > > >
> > > > > > > > * firstly - raise event for X:
> > > > > > > > CompiledMethodLoad(start=X.1.start,
> > > > > > > > method_size=X.1.size + X.2.size,
> > > > > > > > addr_loc_map=
> > > > > > > > [X.1.start -> bcoff1,
> > > > > > > > X.2.start -> bcoff2])
> > > > > > > > * secondly - raise event for Y:
> > > > > > > > CompiledMethodLoad(start=Y.1.start,
> > > > > > > > method_size=Y.1.size,
> > > > > > > > addr_loc_map=
> > > > > > > > [Y.1.start -> bcoff_Y])
> > > > > > >
> > > > > > > good question!
> > > > > > >
> > > > > > > IMHO, code_addr and code_size outlines a region where method code
> > > is
> > > > > > > contained. In that case VM can quickly tell which method the IP
> > > > > > > (instruction pointer) belongs to. So, I intentionally suggested
> > > > > > > code_size=(X.1.size + Y.1.size + X.2.size) instead of (X.1.size +
> > > > > > > X.2.size).
> > > > > > >
> > > > > > > BTW, Eugene, do you have some important observations of the RI
> > > > > > > behaviour for us?
> > > > > > >
> > > > > > > > > For example, we have
> > > > > > > > > some chinks of methods X and Y intermixed like this:
> > > > > > > > > "X.1,Y.1,X.2". To overcome we may:
> > > > > > > > > * raise a single event for X:
> > > > > > > > > CompiledMethodLoad(start=X.1.start,
> > > > > > > > > method_size=X.1.size + Y.1.size +
> > > X.2.size
> > > > > ,
> > > > > > > > > addr_loc_map=
> > > > > > > > > [X.1.start -> bcoff1,
> > > > > > > > > Y.1.start -> 0,
> > > > > > > > > X.2.start -> bcoff2])
> > > > > > > > > * raise 2 events for X:
> > > > > > > > > CompiledMethodLoad(start=X.1.start,
> > > > > > > > > method_size=X.1.size,
> > > > > > > > > addr_loc_map=
> > > > > > > > > [X.1.start -> bcoff1])
> > > > > > > > > CompiledMethodLoad(start=X.2.start,
> > > > > > > > > method_size=X.2.size,
> > > > > > > > > addr_loc_map=
> > > > > > > > > [X.2.start -> bcoff2])
> > > > > > > > >
> > > > > > > > > I would highly appreciate if some JVMTI guru steps down from
> > > > > Olymp
> > > > > > > and
> > > > > > > > > tells which of two is the best, or at least says what RI does
> > > in
> > > > > that
> > > > > > > > > case (or, maybe, RI does not generate non-contigous blocks?)
> > > > > > > > >
> > > > > > > > > I like the second approach (raise 2 events)
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Egor Pasko
> > > > > > >
> > > > > > >
> > > > >
> > > > > --
> > > > > Egor Pasko
> > > > >
> > > > >
> > >
> > > --
> > > Egor Pasko
> > >
> > >
> >
> >
>
--
Egor Pasko
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Ivan Popov <iv...@gmail.com>.
Since DRLVM seems the unique JVM implementation that reports inlined
methods, it was proposed to document the order in which inlined
methods are reported with COMPILED_METHOD_LOAD events - from the most
wrapping method to the most inlined ones or vise versa. This will
allow to adjust JVMTI tools for handling inlined methods correctly.
Thanks.
Ivan
On 12/18/06, Eugene Ostrovsky <eu...@gmail.com> wrote:
> Let me propose the following design:
>
> Compiled method load event. More precise specification for inlined methods.
> 1. CML event must be sent for every method compiled by JIT.
> If compiled method code is disposed in several disconnected regions each of
> them must be reported by separate CML event.
> Each region location is described by code_addr and code_size parameters.
> Native addresses to bytecode location correspondence should be described in
> map parameter if this information is available. If compiled method code
> contains code blocks of inlined methods the addresses of those blocks should
> be associated with the location of corresponding invoke bytecode
> instruction.
> 2. If compiled method code region was inlined within the code region of the
> outer method it should be reported by separate CML event. Inlined method
> code region must be enclosed within one of the outer method's code regions.
> I.e. outer.start <= inlined.start < inlined.end <= outer.end (where
> method.start = code_addr , method.end = code_addr + code_size - 1)
> 3. According to #1 and #2 any two of reported regions (R1, R2) may by
> enclosed one by other (in case of inlining) but must not overlap (i.e.
> R1.start < R2.start <= R1.end < R2.end condition must not be true).
>
> Is it clear enough?
> What do you think?
>
> On 15 Dec 2006 18:36:22 +0600, Egor Pasko <eg...@gmail.com> wrote:
> >
> > On the 0x240 day of Apache Harmony Eugene Ostrovsky wrote:
> > > I experimented with sun and bea vms.
> >
> > did you try HotSpot for JSE 6 (with attach anytime feature)?
> >
> > > None of them report inlined methods.
> > >
> > > Thus we need to make a decision by ourselves.
> >
> > :) yes
> >
> > > On 14 Dec 2006 16:14:49 +0600, Egor Pasko <eg...@gmail.com> wrote:
> > > >
> > > > On the 0x23F day of Apache Harmony Eugene Ostrovsky wrote:
> > > > > I'll try to make test to investigate RI behavior.
> > > >
> > > > thank you thank you thank you
> > > >
> > > > > On 13 Dec 2006 16:34:46 +0600, Egor Pasko <eg...@gmail.com>
> > wrote:
> > > > > >
> > > > > > On the 0x23E day of Apache Harmony George Timoshenko wrote:
> > > > > > > Egor,
> > > > > > >
> > > > > > > thanks for clear scheme.
> > > > > > >
> > > > > > > In your terms I'd do something like this:
> > > > > > >
> > > > > > > * firstly - raise event for X:
> > > > > > > CompiledMethodLoad(start=X.1.start,
> > > > > > > method_size=X.1.size + X.2.size,
> > > > > > > addr_loc_map=
> > > > > > > [X.1.start -> bcoff1,
> > > > > > > X.2.start -> bcoff2])
> > > > > > > * secondly - raise event for Y:
> > > > > > > CompiledMethodLoad(start=Y.1.start,
> > > > > > > method_size=Y.1.size,
> > > > > > > addr_loc_map=
> > > > > > > [Y.1.start -> bcoff_Y])
> > > > > >
> > > > > > good question!
> > > > > >
> > > > > > IMHO, code_addr and code_size outlines a region where method code
> > is
> > > > > > contained. In that case VM can quickly tell which method the IP
> > > > > > (instruction pointer) belongs to. So, I intentionally suggested
> > > > > > code_size=(X.1.size + Y.1.size + X.2.size) instead of (X.1.size +
> > > > > > X.2.size).
> > > > > >
> > > > > > BTW, Eugene, do you have some important observations of the RI
> > > > > > behaviour for us?
> > > > > >
> > > > > > > > For example, we have
> > > > > > > > some chinks of methods X and Y intermixed like this:
> > > > > > > > "X.1,Y.1,X.2". To overcome we may:
> > > > > > > > * raise a single event for X:
> > > > > > > > CompiledMethodLoad(start=X.1.start,
> > > > > > > > method_size=X.1.size + Y.1.size +
> > X.2.size
> > > > ,
> > > > > > > > addr_loc_map=
> > > > > > > > [X.1.start -> bcoff1,
> > > > > > > > Y.1.start -> 0,
> > > > > > > > X.2.start -> bcoff2])
> > > > > > > > * raise 2 events for X:
> > > > > > > > CompiledMethodLoad(start=X.1.start,
> > > > > > > > method_size=X.1.size,
> > > > > > > > addr_loc_map=
> > > > > > > > [X.1.start -> bcoff1])
> > > > > > > > CompiledMethodLoad(start=X.2.start,
> > > > > > > > method_size=X.2.size,
> > > > > > > > addr_loc_map=
> > > > > > > > [X.2.start -> bcoff2])
> > > > > > > >
> > > > > > > > I would highly appreciate if some JVMTI guru steps down from
> > > > Olymp
> > > > > > and
> > > > > > > > tells which of two is the best, or at least says what RI does
> > in
> > > > that
> > > > > > > > case (or, maybe, RI does not generate non-contigous blocks?)
> > > > > > > >
> > > > > > > > I like the second approach (raise 2 events)
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Egor Pasko
> > > > > >
> > > > > >
> > > >
> > > > --
> > > > Egor Pasko
> > > >
> > > >
> >
> > --
> > Egor Pasko
> >
> >
>
>
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Eugene Ostrovsky <eu...@gmail.com>.
No. This statement is about one reported code region of the outer method
containing code region of the inlined method.
On 12/19/06, George Timoshenko <ge...@gmail.com> wrote:
>
> a question:
>
> Eugene Ostrovsky wrote:
> > I.e. outer.start <= inlined.start < inlined.end <= outer.end (where
> > method.start = code_addr , method.end = code_addr + code_size - 1)
>
> In the described situation outer method is being reported with several
> events. Do I understald correctly, that in the inequation above:
> outer.end - is a maximum of outer.end values from all outers events.
> (and outer.start - is a minimum)
> ?
>
>
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by George Timoshenko <ge...@gmail.com>.
a question:
Eugene Ostrovsky wrote:
> I.e. outer.start <= inlined.start < inlined.end <= outer.end (where
> method.start = code_addr , method.end = code_addr + code_size - 1)
In the described situation outer method is being reported with several
events. Do I understald correctly, that in the inequation above:
outer.end - is a maximum of outer.end values from all outers events.
(and outer.start - is a minimum)
?
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by George Timoshenko <ge...@gmail.com>.
Eugene,
I've updated H-2145-JIT-side-version-2.patch
There are no overlapped regions any more.
The difference is:
- POINTER_SIZE_INT methodStartAddr = methInfo->getCodeAddr();
+ POINTER_SIZE_INT methodStartAddr = litStart == litEnd ?
methInfo->getCodeAddr() : (*litStart).first;
The problem of overlapped regions was caused by quite specific case:
There was a region with method_start_pseudo_inst_instruction inside
it. The inst was _not_ the first one in this region.
I mistakenly used method_start_pseudo_inst_instruction address as the
code_start_addres for the whole region.
(*litStart).first - is the address of the first instruction in the region.
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Eugene Ostrovsky <eu...@gmail.com>.
George,
Jit sometimes reports overlapping regions for different methods. It seems to
be incorrect.
To reproduce the issue see comment in
*HARMONY-2145<http://issues.apache.org/jira/browse/HARMONY-2145>
.
*
Could you please evaluate this issue.*
*Thanks, Eugene.*
*
On 1/12/07, George Timoshenko <ge...@gmail.com> wrote:
>
> Egor Pasko wrote:
> > On the 0x25B day of Apache Harmony George Timoshenko wrote:
> >>> IMHO, we should report conscequent regions of the same method as one
> >>> region. Thus, 2 passes are better. And it is NOT slow :)
> >>>
> >> Egor,
> >>
> >> It is not possible to have 2 consequent regions. If there is no gap
> >> between them they must be _one_ region.
> >>
> >> Please, clarify, if I understand your last note incorrectly.
> >
> > xcuse me, I mixed regions and locations (and misunderstood you a bit:)
> >
> > The proposal is to unite all conscequent instructions belonging to
> > identical BCoffset into a single location. This way of reporting
> > locations better aligns with the spec. Actually, that can be done in
> > the same pass (by just omitting sonscequent instructions with the same
> > offset in your pass). Sure, one pass through insts of each method.
> >
> > George, how is that?
> >
> Egor, you are absolutely right.
>
> It is exactly the same, I've stated in JIRA issue under TODO clause:
>
> TODO:
> 4. LocationMap contains _all_ instructions of a method. It should be
> optimized:
>
> Now:
>
> addr1 - bcOffset_X
> addr2 - bcOffset_X
> addr3 - bcOffset_X
> addr4 - bcOffset_Y
>
> Should be:
> addr1 - bcOffset_X
> addr4 - bcOffset_Y
>
> which means that all instructions in [addr1;add4) interval have bcOffset
> == bcOffset_X
>
>
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by George Timoshenko <ge...@gmail.com>.
Egor Pasko wrote:
> On the 0x25B day of Apache Harmony George Timoshenko wrote:
>>> IMHO, we should report conscequent regions of the same method as one
>>> region. Thus, 2 passes are better. And it is NOT slow :)
>>>
>> Egor,
>>
>> It is not possible to have 2 consequent regions. If there is no gap
>> between them they must be _one_ region.
>>
>> Please, clarify, if I understand your last note incorrectly.
>
> xcuse me, I mixed regions and locations (and misunderstood you a bit:)
>
> The proposal is to unite all conscequent instructions belonging to
> identical BCoffset into a single location. This way of reporting
> locations better aligns with the spec. Actually, that can be done in
> the same pass (by just omitting sonscequent instructions with the same
> offset in your pass). Sure, one pass through insts of each method.
>
> George, how is that?
>
Egor, you are absolutely right.
It is exactly the same, I've stated in JIRA issue under TODO clause:
TODO:
4. LocationMap contains _all_ instructions of a method. It should be
optimized:
Now:
addr1 - bcOffset_X
addr2 - bcOffset_X
addr3 - bcOffset_X
addr4 - bcOffset_Y
Should be:
addr1 - bcOffset_X
addr4 - bcOffset_Y
which means that all instructions in [addr1;add4) interval have bcOffset
== bcOffset_X
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x25B day of Apache Harmony George Timoshenko wrote:
> > IMHO, we should report conscequent regions of the same method as one
> > region. Thus, 2 passes are better. And it is NOT slow :)
> >
>
> Egor,
>
> It is not possible to have 2 consequent regions. If there is no gap
> between them they must be _one_ region.
>
> Please, clarify, if I understand your last note incorrectly.
xcuse me, I mixed regions and locations (and misunderstood you a bit:)
The proposal is to unite all conscequent instructions belonging to
identical BCoffset into a single location. This way of reporting
locations better aligns with the spec. Actually, that can be done in
the same pass (by just omitting sonscequent instructions with the same
offset in your pass). Sure, one pass through insts of each method.
George, how is that?
--
Egor Pasko
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by George Timoshenko <ge...@gmail.com>.
> IMHO, we should report conscequent regions of the same method as one
> region. Thus, 2 passes are better. And it is NOT slow :)
>
Egor,
It is not possible to have 2 consequent regions. If there is no gap
between them they must be _one_ region.
Please, clarify, if I understand your last note incorrectly.
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x25A day of Apache Harmony George Timoshenko wrote:
> Egor Pasko wrote:
> > On the 0x243 day of Apache Harmony Eugene Ostrovsky wrote:
> >> Let me propose the following design:
> >>
> >> Compiled method load event. More precise specification for inlined methods.
> >> 1. CML event must be sent for every method compiled by JIT.
> >> If compiled method code is disposed in several disconnected regions each of
> >> them must be reported by separate CML event.
> >> Each region location is described by code_addr and code_size parameters.
> >> Native addresses to bytecode location correspondence should be described in
> >> map parameter if this information is available. If compiled method code
> >> contains code blocks of inlined methods the addresses of those blocks should
> >> be associated with the location of corresponding invoke bytecode
> >> instruction.
> >> 2. If compiled method code region was inlined within the code region of the
> >> outer method it should be reported by separate CML event. Inlined method
> >> code region must be enclosed within one of the outer method's code regions.
> >> I.e. outer.start <= inlined.start < inlined.end <= outer.end (where
> >> method.start = code_addr , method.end = code_addr + code_size - 1)
> >> 3. According to #1 and #2 any two of reported regions (R1, R2) may by
> >> enclosed one by other (in case of inlining) but must not overlap (i.e.
> >> R1.start < R2.start <= R1.end < R2.end condition must not be true).
> >>
> >> Is it clear enough?
> > sort of, thank you thank you!
> > George, could you, please, also put a short HOWTO what patches (of
> > 11)
> > in HARMONY-2145 should be applied to make the solution and in which
> > order. (then I will be able to make a more thorough review)
> >
> >> What do you think?
> > well, a couple of words about your algorithm would also have been
> > good! (in comments too)
> > also, an assert verifying the (3) would have been excellent (I cannot
> > find it in the patch)
> > please, also substitute all 'unsigned' to 'uint32' in your patch
> > (that's a sort of convention in Jitrino)
> > The last killer-question for today :)
> > you are doing:
> > sendCompiledMethodLoadEvent(...AddrLocation* addrLocationMap...)
> > before addrLocationMap is initialized completely. Is that OK?
> >
>
> As it is written in JIRA
> H-2145-JIT-side-version-2.patch spposed to be applied firstly.
> VM_side patch needs to be renewed:
> H-2145-VM-support-for-compiled-method-load-events-for-inlined-methods.patch
> (24 kb)
> (There is a problem with compile.cpp file)
>
> So the instructions is:
>
> apply patch H-2145-JIT-side-version-2.patch
> then apply
> H-2145-VM-support-for-compiled-method-load-events-for-inlined-methods.patch
> and (if it was not renewed yet) resolve the conflict in compile.cpp
> manually.
thanks!
> After this one can be able to build VM.
>
> Regarding the last question:
> don't you find the solution is rather elegant?
> addrLocationMap is not supposed to be always filled completely before
> sending thne event.
OK, now I see, thanks!
> At the beginning of the reporting we know the whole size but have no
> the information about it's continuity.
> I see 2 ways: perform 2 passes: the first - to get the sizes of each
> continuous region, the second - to report regions.
that makes sense!
> Or report all regions by one pass but using the 'hack' with addrLocationMap.
IMHO, we should report conscequent regions of the same method as one
region. Thus, 2 passes are better. And it is NOT slow :)
--
Egor Pasko
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by George Timoshenko <ge...@gmail.com>.
Egor Pasko wrote:
> On the 0x243 day of Apache Harmony Eugene Ostrovsky wrote:
>> Let me propose the following design:
>>
>> Compiled method load event. More precise specification for inlined methods.
>> 1. CML event must be sent for every method compiled by JIT.
>> If compiled method code is disposed in several disconnected regions each of
>> them must be reported by separate CML event.
>> Each region location is described by code_addr and code_size parameters.
>> Native addresses to bytecode location correspondence should be described in
>> map parameter if this information is available. If compiled method code
>> contains code blocks of inlined methods the addresses of those blocks should
>> be associated with the location of corresponding invoke bytecode
>> instruction.
>> 2. If compiled method code region was inlined within the code region of the
>> outer method it should be reported by separate CML event. Inlined method
>> code region must be enclosed within one of the outer method's code regions.
>> I.e. outer.start <= inlined.start < inlined.end <= outer.end (where
>> method.start = code_addr , method.end = code_addr + code_size - 1)
>> 3. According to #1 and #2 any two of reported regions (R1, R2) may by
>> enclosed one by other (in case of inlining) but must not overlap (i.e.
>> R1.start < R2.start <= R1.end < R2.end condition must not be true).
>>
>> Is it clear enough?
>
> sort of, thank you thank you!
>
> George, could you, please, also put a short HOWTO what patches (of 11)
> in HARMONY-2145 should be applied to make the solution and in which
> order. (then I will be able to make a more thorough review)
>
>> What do you think?
>
> well, a couple of words about your algorithm would also have been
> good! (in comments too)
>
> also, an assert verifying the (3) would have been excellent (I cannot
> find it in the patch)
>
> please, also substitute all 'unsigned' to 'uint32' in your patch
> (that's a sort of convention in Jitrino)
>
> The last killer-question for today :)
>
> you are doing:
> sendCompiledMethodLoadEvent(...AddrLocation* addrLocationMap...)
> before addrLocationMap is initialized completely. Is that OK?
>
As it is written in JIRA
H-2145-JIT-side-version-2.patch spposed to be applied firstly.
VM_side patch needs to be renewed:
H-2145-VM-support-for-compiled-method-load-events-for-inlined-methods.patch
(24 kb)
(There is a problem with compile.cpp file)
So the instructions is:
apply patch H-2145-JIT-side-version-2.patch
then apply
H-2145-VM-support-for-compiled-method-load-events-for-inlined-methods.patch
and (if it was not renewed yet) resolve the conflict in compile.cpp
manually.
After this one can be able to build VM.
Regarding the last question:
don't you find the solution is rather elegant?
addrLocationMap is not supposed to be always filled completely before
sending the event.
At the beginning of the reporting we know the whole size but have no the
information about it's continuity.
I see 2 ways: perform 2 passes: the first - to get the sizes of each
continuous region, the second - to report regions.
Or report all regions by one pass but using the 'hack' with addrLocationMap.
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x243 day of Apache Harmony Eugene Ostrovsky wrote:
> Let me propose the following design:
>
> Compiled method load event. More precise specification for inlined methods.
> 1. CML event must be sent for every method compiled by JIT.
> If compiled method code is disposed in several disconnected regions each of
> them must be reported by separate CML event.
> Each region location is described by code_addr and code_size parameters.
> Native addresses to bytecode location correspondence should be described in
> map parameter if this information is available. If compiled method code
> contains code blocks of inlined methods the addresses of those blocks should
> be associated with the location of corresponding invoke bytecode
> instruction.
> 2. If compiled method code region was inlined within the code region of the
> outer method it should be reported by separate CML event. Inlined method
> code region must be enclosed within one of the outer method's code regions.
> I.e. outer.start <= inlined.start < inlined.end <= outer.end (where
> method.start = code_addr , method.end = code_addr + code_size - 1)
> 3. According to #1 and #2 any two of reported regions (R1, R2) may by
> enclosed one by other (in case of inlining) but must not overlap (i.e.
> R1.start < R2.start <= R1.end < R2.end condition must not be true).
>
> Is it clear enough?
sort of, thank you thank you!
George, could you, please, also put a short HOWTO what patches (of 11)
in HARMONY-2145 should be applied to make the solution and in which
order. (then I will be able to make a more thorough review)
> What do you think?
well, a couple of words about your algorithm would also have been
good! (in comments too)
also, an assert verifying the (3) would have been excellent (I cannot
find it in the patch)
please, also substitute all 'unsigned' to 'uint32' in your patch
(that's a sort of convention in Jitrino)
The last killer-question for today :)
you are doing:
sendCompiledMethodLoadEvent(...AddrLocation* addrLocationMap...)
before addrLocationMap is initialized completely. Is that OK?
--
Egor Pasko
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Eugene Ostrovsky <eu...@gmail.com>.
Let me propose the following design:
Compiled method load event. More precise specification for inlined methods.
1. CML event must be sent for every method compiled by JIT.
If compiled method code is disposed in several disconnected regions each of
them must be reported by separate CML event.
Each region location is described by code_addr and code_size parameters.
Native addresses to bytecode location correspondence should be described in
map parameter if this information is available. If compiled method code
contains code blocks of inlined methods the addresses of those blocks should
be associated with the location of corresponding invoke bytecode
instruction.
2. If compiled method code region was inlined within the code region of the
outer method it should be reported by separate CML event. Inlined method
code region must be enclosed within one of the outer method's code regions.
I.e. outer.start <= inlined.start < inlined.end <= outer.end (where
method.start = code_addr , method.end = code_addr + code_size - 1)
3. According to #1 and #2 any two of reported regions (R1, R2) may by
enclosed one by other (in case of inlining) but must not overlap (i.e.
R1.start < R2.start <= R1.end < R2.end condition must not be true).
Is it clear enough?
What do you think?
On 15 Dec 2006 18:36:22 +0600, Egor Pasko <eg...@gmail.com> wrote:
>
> On the 0x240 day of Apache Harmony Eugene Ostrovsky wrote:
> > I experimented with sun and bea vms.
>
> did you try HotSpot for JSE 6 (with attach anytime feature)?
>
> > None of them report inlined methods.
> >
> > Thus we need to make a decision by ourselves.
>
> :) yes
>
> > On 14 Dec 2006 16:14:49 +0600, Egor Pasko <eg...@gmail.com> wrote:
> > >
> > > On the 0x23F day of Apache Harmony Eugene Ostrovsky wrote:
> > > > I'll try to make test to investigate RI behavior.
> > >
> > > thank you thank you thank you
> > >
> > > > On 13 Dec 2006 16:34:46 +0600, Egor Pasko <eg...@gmail.com>
> wrote:
> > > > >
> > > > > On the 0x23E day of Apache Harmony George Timoshenko wrote:
> > > > > > Egor,
> > > > > >
> > > > > > thanks for clear scheme.
> > > > > >
> > > > > > In your terms I'd do something like this:
> > > > > >
> > > > > > * firstly - raise event for X:
> > > > > > CompiledMethodLoad(start=X.1.start,
> > > > > > method_size=X.1.size + X.2.size,
> > > > > > addr_loc_map=
> > > > > > [X.1.start -> bcoff1,
> > > > > > X.2.start -> bcoff2])
> > > > > > * secondly - raise event for Y:
> > > > > > CompiledMethodLoad(start=Y.1.start,
> > > > > > method_size=Y.1.size,
> > > > > > addr_loc_map=
> > > > > > [Y.1.start -> bcoff_Y])
> > > > >
> > > > > good question!
> > > > >
> > > > > IMHO, code_addr and code_size outlines a region where method code
> is
> > > > > contained. In that case VM can quickly tell which method the IP
> > > > > (instruction pointer) belongs to. So, I intentionally suggested
> > > > > code_size=(X.1.size + Y.1.size + X.2.size) instead of (X.1.size +
> > > > > X.2.size).
> > > > >
> > > > > BTW, Eugene, do you have some important observations of the RI
> > > > > behaviour for us?
> > > > >
> > > > > > > For example, we have
> > > > > > > some chinks of methods X and Y intermixed like this:
> > > > > > > "X.1,Y.1,X.2". To overcome we may:
> > > > > > > * raise a single event for X:
> > > > > > > CompiledMethodLoad(start=X.1.start,
> > > > > > > method_size=X.1.size + Y.1.size +
> X.2.size
> > > ,
> > > > > > > addr_loc_map=
> > > > > > > [X.1.start -> bcoff1,
> > > > > > > Y.1.start -> 0,
> > > > > > > X.2.start -> bcoff2])
> > > > > > > * raise 2 events for X:
> > > > > > > CompiledMethodLoad(start=X.1.start,
> > > > > > > method_size=X.1.size,
> > > > > > > addr_loc_map=
> > > > > > > [X.1.start -> bcoff1])
> > > > > > > CompiledMethodLoad(start=X.2.start,
> > > > > > > method_size=X.2.size,
> > > > > > > addr_loc_map=
> > > > > > > [X.2.start -> bcoff2])
> > > > > > >
> > > > > > > I would highly appreciate if some JVMTI guru steps down from
> > > Olymp
> > > > > and
> > > > > > > tells which of two is the best, or at least says what RI does
> in
> > > that
> > > > > > > case (or, maybe, RI does not generate non-contigous blocks?)
> > > > > > >
> > > > > > > I like the second approach (raise 2 events)
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Egor Pasko
> > > > >
> > > > >
> > >
> > > --
> > > Egor Pasko
> > >
> > >
>
> --
> Egor Pasko
>
>
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x240 day of Apache Harmony Eugene Ostrovsky wrote:
> I experimented with sun and bea vms.
did you try HotSpot for JSE 6 (with attach anytime feature)?
> None of them report inlined methods.
>
> Thus we need to make a decision by ourselves.
:) yes
> On 14 Dec 2006 16:14:49 +0600, Egor Pasko <eg...@gmail.com> wrote:
> >
> > On the 0x23F day of Apache Harmony Eugene Ostrovsky wrote:
> > > I'll try to make test to investigate RI behavior.
> >
> > thank you thank you thank you
> >
> > > On 13 Dec 2006 16:34:46 +0600, Egor Pasko <eg...@gmail.com> wrote:
> > > >
> > > > On the 0x23E day of Apache Harmony George Timoshenko wrote:
> > > > > Egor,
> > > > >
> > > > > thanks for clear scheme.
> > > > >
> > > > > In your terms I'd do something like this:
> > > > >
> > > > > * firstly - raise event for X:
> > > > > CompiledMethodLoad(start=X.1.start,
> > > > > method_size=X.1.size + X.2.size,
> > > > > addr_loc_map=
> > > > > [X.1.start -> bcoff1,
> > > > > X.2.start -> bcoff2])
> > > > > * secondly - raise event for Y:
> > > > > CompiledMethodLoad(start=Y.1.start,
> > > > > method_size=Y.1.size,
> > > > > addr_loc_map=
> > > > > [Y.1.start -> bcoff_Y])
> > > >
> > > > good question!
> > > >
> > > > IMHO, code_addr and code_size outlines a region where method code is
> > > > contained. In that case VM can quickly tell which method the IP
> > > > (instruction pointer) belongs to. So, I intentionally suggested
> > > > code_size=(X.1.size + Y.1.size + X.2.size) instead of (X.1.size +
> > > > X.2.size).
> > > >
> > > > BTW, Eugene, do you have some important observations of the RI
> > > > behaviour for us?
> > > >
> > > > > > For example, we have
> > > > > > some chinks of methods X and Y intermixed like this:
> > > > > > "X.1,Y.1,X.2". To overcome we may:
> > > > > > * raise a single event for X:
> > > > > > CompiledMethodLoad(start=X.1.start,
> > > > > > method_size=X.1.size + Y.1.size + X.2.size
> > ,
> > > > > > addr_loc_map=
> > > > > > [X.1.start -> bcoff1,
> > > > > > Y.1.start -> 0,
> > > > > > X.2.start -> bcoff2])
> > > > > > * raise 2 events for X:
> > > > > > CompiledMethodLoad(start=X.1.start,
> > > > > > method_size=X.1.size,
> > > > > > addr_loc_map=
> > > > > > [X.1.start -> bcoff1])
> > > > > > CompiledMethodLoad(start=X.2.start,
> > > > > > method_size=X.2.size,
> > > > > > addr_loc_map=
> > > > > > [X.2.start -> bcoff2])
> > > > > >
> > > > > > I would highly appreciate if some JVMTI guru steps down from
> > Olymp
> > > > and
> > > > > > tells which of two is the best, or at least says what RI does in
> > that
> > > > > > case (or, maybe, RI does not generate non-contigous blocks?)
> > > > > >
> > > > > > I like the second approach (raise 2 events)
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > Egor Pasko
> > > >
> > > >
> >
> > --
> > Egor Pasko
> >
> >
--
Egor Pasko
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Eugene Ostrovsky <eu...@gmail.com>.
I experimented with sun and bea vms.
None of them report inlined methods.
Thus we need to make a decision by ourselves.
On 14 Dec 2006 16:14:49 +0600, Egor Pasko <eg...@gmail.com> wrote:
>
> On the 0x23F day of Apache Harmony Eugene Ostrovsky wrote:
> > I'll try to make test to investigate RI behavior.
>
> thank you thank you thank you
>
> > On 13 Dec 2006 16:34:46 +0600, Egor Pasko <eg...@gmail.com> wrote:
> > >
> > > On the 0x23E day of Apache Harmony George Timoshenko wrote:
> > > > Egor,
> > > >
> > > > thanks for clear scheme.
> > > >
> > > > In your terms I'd do something like this:
> > > >
> > > > * firstly - raise event for X:
> > > > CompiledMethodLoad(start=X.1.start,
> > > > method_size=X.1.size + X.2.size,
> > > > addr_loc_map=
> > > > [X.1.start -> bcoff1,
> > > > X.2.start -> bcoff2])
> > > > * secondly - raise event for Y:
> > > > CompiledMethodLoad(start=Y.1.start,
> > > > method_size=Y.1.size,
> > > > addr_loc_map=
> > > > [Y.1.start -> bcoff_Y])
> > >
> > > good question!
> > >
> > > IMHO, code_addr and code_size outlines a region where method code is
> > > contained. In that case VM can quickly tell which method the IP
> > > (instruction pointer) belongs to. So, I intentionally suggested
> > > code_size=(X.1.size + Y.1.size + X.2.size) instead of (X.1.size +
> > > X.2.size).
> > >
> > > BTW, Eugene, do you have some important observations of the RI
> > > behaviour for us?
> > >
> > > > > For example, we have
> > > > > some chinks of methods X and Y intermixed like this:
> > > > > "X.1,Y.1,X.2". To overcome we may:
> > > > > * raise a single event for X:
> > > > > CompiledMethodLoad(start=X.1.start,
> > > > > method_size=X.1.size + Y.1.size + X.2.size
> ,
> > > > > addr_loc_map=
> > > > > [X.1.start -> bcoff1,
> > > > > Y.1.start -> 0,
> > > > > X.2.start -> bcoff2])
> > > > > * raise 2 events for X:
> > > > > CompiledMethodLoad(start=X.1.start,
> > > > > method_size=X.1.size,
> > > > > addr_loc_map=
> > > > > [X.1.start -> bcoff1])
> > > > > CompiledMethodLoad(start=X.2.start,
> > > > > method_size=X.2.size,
> > > > > addr_loc_map=
> > > > > [X.2.start -> bcoff2])
> > > > >
> > > > > I would highly appreciate if some JVMTI guru steps down from
> Olymp
> > > and
> > > > > tells which of two is the best, or at least says what RI does in
> that
> > > > > case (or, maybe, RI does not generate non-contigous blocks?)
> > > > >
> > > > > I like the second approach (raise 2 events)
> > > > >
> > > >
> > > >
> > > >
> > >
> > > --
> > > Egor Pasko
> > >
> > >
>
> --
> Egor Pasko
>
>
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x23F day of Apache Harmony Eugene Ostrovsky wrote:
> I'll try to make test to investigate RI behavior.
thank you thank you thank you
> On 13 Dec 2006 16:34:46 +0600, Egor Pasko <eg...@gmail.com> wrote:
> >
> > On the 0x23E day of Apache Harmony George Timoshenko wrote:
> > > Egor,
> > >
> > > thanks for clear scheme.
> > >
> > > In your terms I'd do something like this:
> > >
> > > * firstly - raise event for X:
> > > CompiledMethodLoad(start=X.1.start,
> > > method_size=X.1.size + X.2.size,
> > > addr_loc_map=
> > > [X.1.start -> bcoff1,
> > > X.2.start -> bcoff2])
> > > * secondly - raise event for Y:
> > > CompiledMethodLoad(start=Y.1.start,
> > > method_size=Y.1.size,
> > > addr_loc_map=
> > > [Y.1.start -> bcoff_Y])
> >
> > good question!
> >
> > IMHO, code_addr and code_size outlines a region where method code is
> > contained. In that case VM can quickly tell which method the IP
> > (instruction pointer) belongs to. So, I intentionally suggested
> > code_size=(X.1.size + Y.1.size + X.2.size) instead of (X.1.size +
> > X.2.size).
> >
> > BTW, Eugene, do you have some important observations of the RI
> > behaviour for us?
> >
> > > > For example, we have
> > > > some chinks of methods X and Y intermixed like this:
> > > > "X.1,Y.1,X.2". To overcome we may:
> > > > * raise a single event for X:
> > > > CompiledMethodLoad(start=X.1.start,
> > > > method_size=X.1.size + Y.1.size + X.2.size,
> > > > addr_loc_map=
> > > > [X.1.start -> bcoff1,
> > > > Y.1.start -> 0,
> > > > X.2.start -> bcoff2])
> > > > * raise 2 events for X:
> > > > CompiledMethodLoad(start=X.1.start,
> > > > method_size=X.1.size,
> > > > addr_loc_map=
> > > > [X.1.start -> bcoff1])
> > > > CompiledMethodLoad(start=X.2.start,
> > > > method_size=X.2.size,
> > > > addr_loc_map=
> > > > [X.2.start -> bcoff2])
> > > >
> > > > I would highly appreciate if some JVMTI guru steps down from Olymp
> > and
> > > > tells which of two is the best, or at least says what RI does in that
> > > > case (or, maybe, RI does not generate non-contigous blocks?)
> > > >
> > > > I like the second approach (raise 2 events)
> > > >
> > >
> > >
> > >
> >
> > --
> > Egor Pasko
> >
> >
--
Egor Pasko
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Eugene Ostrovsky <eu...@gmail.com>.
I'll try to make test to investigate RI behavior.
On 13 Dec 2006 16:34:46 +0600, Egor Pasko <eg...@gmail.com> wrote:
>
> On the 0x23E day of Apache Harmony George Timoshenko wrote:
> > Egor,
> >
> > thanks for clear scheme.
> >
> > In your terms I'd do something like this:
> >
> > * firstly - raise event for X:
> > CompiledMethodLoad(start=X.1.start,
> > method_size=X.1.size + X.2.size,
> > addr_loc_map=
> > [X.1.start -> bcoff1,
> > X.2.start -> bcoff2])
> > * secondly - raise event for Y:
> > CompiledMethodLoad(start=Y.1.start,
> > method_size=Y.1.size,
> > addr_loc_map=
> > [Y.1.start -> bcoff_Y])
>
> good question!
>
> IMHO, code_addr and code_size outlines a region where method code is
> contained. In that case VM can quickly tell which method the IP
> (instruction pointer) belongs to. So, I intentionally suggested
> code_size=(X.1.size + Y.1.size + X.2.size) instead of (X.1.size +
> X.2.size).
>
> BTW, Eugene, do you have some important observations of the RI
> behaviour for us?
>
> > > For example, we have
> > > some chinks of methods X and Y intermixed like this:
> > > "X.1,Y.1,X.2". To overcome we may:
> > > * raise a single event for X:
> > > CompiledMethodLoad(start=X.1.start,
> > > method_size=X.1.size + Y.1.size + X.2.size,
> > > addr_loc_map=
> > > [X.1.start -> bcoff1,
> > > Y.1.start -> 0,
> > > X.2.start -> bcoff2])
> > > * raise 2 events for X:
> > > CompiledMethodLoad(start=X.1.start,
> > > method_size=X.1.size,
> > > addr_loc_map=
> > > [X.1.start -> bcoff1])
> > > CompiledMethodLoad(start=X.2.start,
> > > method_size=X.2.size,
> > > addr_loc_map=
> > > [X.2.start -> bcoff2])
> > >
> > > I would highly appreciate if some JVMTI guru steps down from Olymp
> and
> > > tells which of two is the best, or at least says what RI does in that
> > > case (or, maybe, RI does not generate non-contigous blocks?)
> > >
> > > I like the second approach (raise 2 events)
> > >
> >
> >
> >
>
> --
> Egor Pasko
>
>
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by George Timoshenko <ge...@gmail.com>.
Egor, thanks for clear scheme.
In your terms I'd do something like this:
* firstly - raise event for X:
CompiledMethodLoad(start=X.1.start,
method_size=X.1.size + X.2.size,
addr_loc_map=
[X.1.start -> bcoff1,
X.2.start -> bcoff2])
* secondly - raise event for Y:
CompiledMethodLoad(start=Y.1.start,
method_size=Y.1.size,
addr_loc_map=
[Y.1.start -> bcoff_Y])
> For example, we have
> some chinks of methods X and Y intermixed like this:
> "X.1,Y.1,X.2". To overcome we may:
> * raise a single event for X:
> CompiledMethodLoad(start=X.1.start,
> method_size=X.1.size + Y.1.size + X.2.size,
> addr_loc_map=
> [X.1.start -> bcoff1,
> Y.1.start -> 0,
> X.2.start -> bcoff2])
> * raise 2 events for X:
> CompiledMethodLoad(start=X.1.start,
> method_size=X.1.size,
> addr_loc_map=
> [X.1.start -> bcoff1])
> CompiledMethodLoad(start=X.2.start,
> method_size=X.2.size,
> addr_loc_map=
> [X.2.start -> bcoff2])
>
> I would highly appreciate if some JVMTI guru steps down from Olymp and
> tells which of two is the best, or at least says what RI does in that
> case (or, maybe, RI does not generate non-contigous blocks?)
>
> I like the second approach (raise 2 events)
>
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x23E day of Apache Harmony George Timoshenko wrote:
> Egor,
>
> thanks for clear scheme.
>
> In your terms I'd do something like this:
>
> * firstly - raise event for X:
> CompiledMethodLoad(start=X.1.start,
> method_size=X.1.size + X.2.size,
> addr_loc_map=
> [X.1.start -> bcoff1,
> X.2.start -> bcoff2])
> * secondly - raise event for Y:
> CompiledMethodLoad(start=Y.1.start,
> method_size=Y.1.size,
> addr_loc_map=
> [Y.1.start -> bcoff_Y])
good question!
IMHO, code_addr and code_size outlines a region where method code is
contained. In that case VM can quickly tell which method the IP
(instruction pointer) belongs to. So, I intentionally suggested
code_size=(X.1.size + Y.1.size + X.2.size) instead of (X.1.size +
X.2.size).
BTW, Eugene, do you have some important observations of the RI
behaviour for us?
> > For example, we have
> > some chinks of methods X and Y intermixed like this:
> > "X.1,Y.1,X.2". To overcome we may:
> > * raise a single event for X:
> > CompiledMethodLoad(start=X.1.start,
> > method_size=X.1.size + Y.1.size + X.2.size,
> > addr_loc_map=
> > [X.1.start -> bcoff1,
> > Y.1.start -> 0,
> > X.2.start -> bcoff2])
> > * raise 2 events for X:
> > CompiledMethodLoad(start=X.1.start,
> > method_size=X.1.size,
> > addr_loc_map=
> > [X.1.start -> bcoff1])
> > CompiledMethodLoad(start=X.2.start,
> > method_size=X.2.size,
> > addr_loc_map=
> > [X.2.start -> bcoff2])
> >
> > I would highly appreciate if some JVMTI guru steps down from Olymp and
> > tells which of two is the best, or at least says what RI does in that
> > case (or, maybe, RI does not generate non-contigous blocks?)
> >
> > I like the second approach (raise 2 events)
> >
>
>
>
--
Egor Pasko
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by George Timoshenko <ge...@gmail.com>.
Egor,
thanks for clear scheme.
In your terms I'd do something like this:
* firstly - raise event for X:
CompiledMethodLoad(start=X.1.start,
method_size=X.1.size + X.2.size,
addr_loc_map=
[X.1.start -> bcoff1,
X.2.start -> bcoff2])
* secondly - raise event for Y:
CompiledMethodLoad(start=Y.1.start,
method_size=Y.1.size,
addr_loc_map=
[Y.1.start -> bcoff_Y])
> For example, we have
> some chinks of methods X and Y intermixed like this:
> "X.1,Y.1,X.2". To overcome we may:
> * raise a single event for X:
> CompiledMethodLoad(start=X.1.start,
> method_size=X.1.size + Y.1.size + X.2.size,
> addr_loc_map=
> [X.1.start -> bcoff1,
> Y.1.start -> 0,
> X.2.start -> bcoff2])
> * raise 2 events for X:
> CompiledMethodLoad(start=X.1.start,
> method_size=X.1.size,
> addr_loc_map=
> [X.1.start -> bcoff1])
> CompiledMethodLoad(start=X.2.start,
> method_size=X.2.size,
> addr_loc_map=
> [X.2.start -> bcoff2])
>
> I would highly appreciate if some JVMTI guru steps down from Olymp and
> tells which of two is the best, or at least says what RI does in that
> case (or, maybe, RI does not generate non-contigous blocks?)
>
> I like the second approach (raise 2 events)
>
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x23C day of Apache Harmony George Timoshenko wrote:
> Egor Pasko wrote:
> > On the 0x237 day of Apache Harmony George Timoshenko wrote:
> >> Egor Pasko wrote:
> >>> On the 0x236 day of Apache Harmony George Timoshenko wrote:
> >>>> Egor Pasko wrote:
> >>>>> On the 0x235 day of Apache Harmony George Timoshenko wrote:
> >>>>>> Eugene,
> >>>>>>
> >>>>>> I've answered in JIRA:
> >>>>>>
> >>>>>> https://issues.apache.org/jira/browse/HARMONY-2145#action_12455313
> >>>>>>
> >>>>>> (Summary: Everything is OK)
> >>>>>>
> >>>>>> For this particular testcase it is possible. But there is a general
> >>>>>> problem:
> >>>>>>
> >>>>>> Code layout may be quite unordered. (It mostly depends on hottness,
> >>>>>> not the instructions<->method relations) So a method (say A) body
> >>>>>> can be layouted at two (or more) unsuccessive regions. And the
> >>>>>> regeion between them can belong to some another method (say B). And
> >>>>>> B is _not_ inlined into A.
> >>>>> That is essential, an inlined method can be separated in
> >>>>> non-contiguous regions for performance during CFG alignment. IMHO, we
> >>>>> should register several code blocks for the same inlined method (if
> >>>>> the method's code was split into parts) through the
> >>>>> compiled_method_load(...) interface. This can be done completely on
> >>>>> the JIT side.
> >>>>> What do you, guys, think?
> >>>> No doubts it can be done on the JIT side, but what is the purpose of it?
> >>>>
> >>>> If there is only one question: "I get instruction, which method does
> >>>> it belong to?" it can be answerd easily:
> >>>>
> >>>> For each method jvmtiAddrLocationMap is reported. And each instruction
> >>>> (with particular codeAddress) belongs to the only one such map.
> >>>>
> >>>> I do not understand the necessity of reporting each piece (a number of
> >>>> instructions that goes in a row and belongs to the same method) of a
> >>>> method while we are already reporting _each_instruction_ separately.
> >>> 1. is reporting _each_instruction_ effective?
> >> It is a Spec. requirement.
> > could you point the exact line of the spec, please? I cannot find it
> > :(
>
> It is mentioned in HARMONY-2145 description:
>
> http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#CompiledMethodLoad
thanx! Now I read it more carefully. Event that we are sending from
JIT (CompiledMethodLoad) gives the following info on *each*
compilation for our interest:
* the method
* method size
* compiled code start address
* map: [addr -> "location"], where
* "location" is a start address of some memory chunk,
* each whole "location" corresponds to *only one* bytecode offset,
* all reported locations have to be _adjacent_.
// if a bytecode offset is not known (example: native code), we can
// report something different or even 0, which is "no info".
Thoughts:
* in Jitrino.OPT we guarantee that each machine instruction
corresponds to only _one_ original bytecode offset. Thus, each
instruction might be safely represented as a "location"
* but we can join several adjacent instructions with identical
bytecode offset into _a single_ location. Seems like more natural
and easy to perform fast. I guess, RI does that.
* with inlining and trace scheduling compiled code for a single method
can be split into several non-contigous blocks. For example, we have
some chinks of methods X and Y intermixed like this:
"X.1,Y.1,X.2". To overcome we may:
* raise a single event for X:
CompiledMethodLoad(start=X.1.start,
method_size=X.1.size + Y.1.size + X.2.size,
addr_loc_map=
[X.1.start -> bcoff1,
Y.1.start -> 0,
X.2.start -> bcoff2])
* raise 2 events for X:
CompiledMethodLoad(start=X.1.start,
method_size=X.1.size,
addr_loc_map=
[X.1.start -> bcoff1])
CompiledMethodLoad(start=X.2.start,
method_size=X.2.size,
addr_loc_map=
[X.2.start -> bcoff2])
I would highly appreciate if some JVMTI guru steps down from Olymp and
tells which of two is the best, or at least says what RI does in that
case (or, maybe, RI does not generate non-contigous blocks?)
I like the second approach (raise 2 events)
--
Egor Pasko
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by George Timoshenko <ge...@gmail.com>.
Egor Pasko wrote:
> On the 0x237 day of Apache Harmony George Timoshenko wrote:
>> Egor Pasko wrote:
>>> On the 0x236 day of Apache Harmony George Timoshenko wrote:
>>>> Egor Pasko wrote:
>>>>> On the 0x235 day of Apache Harmony George Timoshenko wrote:
>>>>>> Eugene,
>>>>>>
>>>>>> I've answered in JIRA:
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/HARMONY-2145#action_12455313
>>>>>>
>>>>>> (Summary: Everything is OK)
>>>>>>
>>>>>> For this particular testcase it is possible. But there is a general
>>>>>> problem:
>>>>>>
>>>>>> Code layout may be quite unordered. (It mostly depends on hottness,
>>>>>> not the instructions<->method relations) So a method (say A) body
>>>>>> can be layouted at two (or more) unsuccessive regions. And the
>>>>>> regeion between them can belong to some another method (say B). And
>>>>>> B is _not_ inlined into A.
>>>>> That is essential, an inlined method can be separated in
>>>>> non-contiguous regions for performance during CFG alignment. IMHO, we
>>>>> should register several code blocks for the same inlined method (if
>>>>> the method's code was split into parts) through the
>>>>> compiled_method_load(...) interface. This can be done completely on
>>>>> the JIT side.
>>>>> What do you, guys, think?
>>>> No doubts it can be done on the JIT side, but what is the purpose of it?
>>>>
>>>> If there is only one question: "I get instruction, which method does
>>>> it belong to?" it can be answerd easily:
>>>>
>>>> For each method jvmtiAddrLocationMap is reported. And each instruction
>>>> (with particular codeAddress) belongs to the only one such map.
>>>>
>>>> I do not understand the necessity of reporting each piece (a number of
>>>> instructions that goes in a row and belongs to the same method) of a
>>>> method while we are already reporting _each_instruction_ separately.
>>> 1. is reporting _each_instruction_ effective?
>> It is a Spec. requirement.
>
> could you point the exact line of the spec, please? I cannot find it
> :(
It is mentioned in HARMONY-2145 description:
http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#CompiledMethodLoad
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x237 day of Apache Harmony George Timoshenko wrote:
> Egor Pasko wrote:
> > On the 0x236 day of Apache Harmony George Timoshenko wrote:
> >> Egor Pasko wrote:
> >>> On the 0x235 day of Apache Harmony George Timoshenko wrote:
> >>>> Eugene,
> >>>>
> >>>> I've answered in JIRA:
> >>>>
> >>>> https://issues.apache.org/jira/browse/HARMONY-2145#action_12455313
> >>>>
> >>>> (Summary: Everything is OK)
> >>>>
> >>>> For this particular testcase it is possible. But there is a general
> >>>> problem:
> >>>>
> >>>> Code layout may be quite unordered. (It mostly depends on hottness,
> >>>> not the instructions<->method relations) So a method (say A) body
> >>>> can be layouted at two (or more) unsuccessive regions. And the
> >>>> regeion between them can belong to some another method (say B). And
> >>>> B is _not_ inlined into A.
> >>> That is essential, an inlined method can be separated in
> >>> non-contiguous regions for performance during CFG alignment. IMHO, we
> >>> should register several code blocks for the same inlined method (if
> >>> the method's code was split into parts) through the
> >>> compiled_method_load(...) interface. This can be done completely on
> >>> the JIT side.
> >>> What do you, guys, think?
> >> No doubts it can be done on the JIT side, but what is the purpose of it?
> >>
> >> If there is only one question: "I get instruction, which method does
> >> it belong to?" it can be answerd easily:
> >>
> >> For each method jvmtiAddrLocationMap is reported. And each instruction
> >> (with particular codeAddress) belongs to the only one such map.
> >>
> >> I do not understand the necessity of reporting each piece (a number of
> >> instructions that goes in a row and belongs to the same method) of a
> >> method while we are already reporting _each_instruction_ separately.
> > 1. is reporting _each_instruction_ effective?
>
> It is a Spec. requirement.
could you point the exact line of the spec, please? I cannot find it
:(
> > 2. VM may want to restore the whole inline tree. How would you do that
> > with per-instruction notifications?
> > 3. Guys, did you try RI and look how it behaves? Does it report each
> > instruction separately? I doubt so. Let's make it as close to RI as
> > possible (for compatibility reasons). I should not be difficult.
> >
>
>
--
Egor Pasko
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by George Timoshenko <ge...@gmail.com>.
Egor Pasko wrote:
> On the 0x236 day of Apache Harmony George Timoshenko wrote:
>> Egor Pasko wrote:
>>> On the 0x235 day of Apache Harmony George Timoshenko wrote:
>>>> Eugene,
>>>>
>>>> I've answered in JIRA:
>>>>
>>>> https://issues.apache.org/jira/browse/HARMONY-2145#action_12455313
>>>>
>>>> (Summary: Everything is OK)
>>>>
>>>> For this particular testcase it is possible. But there is a general
>>>> problem:
>>>>
>>>> Code layout may be quite unordered. (It mostly depends on hottness,
>>>> not the instructions<->method relations) So a method (say A) body
>>>> can be layouted at two (or more) unsuccessive regions. And the
>>>> regeion between them can belong to some another method (say B). And
>>>> B is _not_ inlined into A.
>>> That is essential, an inlined method can be separated in
>>> non-contiguous regions for performance during CFG alignment. IMHO, we
>>> should register several code blocks for the same inlined method (if
>>> the method's code was split into parts) through the
>>> compiled_method_load(...) interface. This can be done completely on
>>> the JIT side.
>>> What do you, guys, think?
>> No doubts it can be done on the JIT side, but what is the purpose of it?
>>
>> If there is only one question: "I get instruction, which method does
>> it belong to?" it can be answerd easily:
>>
>> For each method jvmtiAddrLocationMap is reported. And each instruction
>> (with particular codeAddress) belongs to the only one such map.
>>
>> I do not understand the necessity of reporting each piece (a number of
>> instructions that goes in a row and belongs to the same method) of a
>> method while we are already reporting _each_instruction_ separately.
>
> 1. is reporting _each_instruction_ effective?
It is a Spec. requirement.
> 2. VM may want to restore the whole inline tree. How would you do that
> with per-instruction notifications?
> 3. Guys, did you try RI and look how it behaves? Does it report each
> instruction separately? I doubt so. Let's make it as close to RI as
> possible (for compatibility reasons). I should not be difficult.
>
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x236 day of Apache Harmony George Timoshenko wrote:
> Egor Pasko wrote:
> > On the 0x235 day of Apache Harmony George Timoshenko wrote:
> >> Eugene,
> >>
> >> I've answered in JIRA:
> >>
> >> https://issues.apache.org/jira/browse/HARMONY-2145#action_12455313
> >>
> >> (Summary: Everything is OK)
> >>
> >> For this particular testcase it is possible. But there is a general
> >> problem:
> >>
> >> Code layout may be quite unordered. (It mostly depends on hottness,
> >> not the instructions<->method relations) So a method (say A) body
> >> can be layouted at two (or more) unsuccessive regions. And the
> >> regeion between them can belong to some another method (say B). And
> >> B is _not_ inlined into A.
> > That is essential, an inlined method can be separated in
> > non-contiguous regions for performance during CFG alignment. IMHO, we
> > should register several code blocks for the same inlined method (if
> > the method's code was split into parts) through the
> > compiled_method_load(...) interface. This can be done completely on
> > the JIT side.
> > What do you, guys, think?
>
> No doubts it can be done on the JIT side, but what is the purpose of it?
>
> If there is only one question: "I get instruction, which method does
> it belong to?" it can be answerd easily:
>
> For each method jvmtiAddrLocationMap is reported. And each instruction
> (with particular codeAddress) belongs to the only one such map.
>
> I do not understand the necessity of reporting each piece (a number of
> instructions that goes in a row and belongs to the same method) of a
> method while we are already reporting _each_instruction_ separately.
1. is reporting _each_instruction_ effective?
2. VM may want to restore the whole inline tree. How would you do that
with per-instruction notifications?
3. Guys, did you try RI and look how it behaves? Does it report each
instruction separately? I doubt so. Let's make it as close to RI as
possible (for compatibility reasons). I should not be difficult.
--
Egor Pasko
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by George Timoshenko <ge...@gmail.com>.
Egor Pasko wrote:
> On the 0x235 day of Apache Harmony George Timoshenko wrote:
>> Eugene,
>>
>> I've answered in JIRA:
>>
>> https://issues.apache.org/jira/browse/HARMONY-2145#action_12455313
>>
>> (Summary: Everything is OK)
>>
>> For this particular testcase it is possible. But there is a general
>> problem:
>>
>> Code layout may be quite unordered. (It mostly depends on hottness,
>> not the instructions<->method relations) So a method (say A) body
>> can be layouted at two (or more) unsuccessive regions. And the
>> regeion between them can belong to some another method (say B). And
>> B is _not_ inlined into A.
>
> That is essential, an inlined method can be separated in
> non-contiguous regions for performance during CFG alignment. IMHO, we
> should register several code blocks for the same inlined method (if
> the method's code was split into parts) through the
> compiled_method_load(...) interface. This can be done completely on
> the JIT side.
>
> What do you, guys, think?
No doubts it can be done on the JIT side, but what is the purpose of it?
If there is only one question: "I get instruction, which method does it
belong to?" it can be answerd easily:
For each method jvmtiAddrLocationMap is reported. And each instruction
(with particular codeAddress) belongs to the only one such map.
I do not understand the necessity of reporting each piece (a number of
instructions that goes in a row and belongs to the same method) of a
method while we are already reporting _each_instruction_ separately.
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x235 day of Apache Harmony George Timoshenko wrote:
> Eugene,
>
> I've answered in JIRA:
>
> https://issues.apache.org/jira/browse/HARMONY-2145#action_12455313
>
> (Summary: Everything is OK)
>
> For this particular testcase it is possible. But there is a general
> problem:
>
> Code layout may be quite unordered. (It mostly depends on hottness,
> not the instructions<->method relations) So a method (say A) body
> can be layouted at two (or more) unsuccessive regions. And the
> regeion between them can belong to some another method (say B). And
> B is _not_ inlined into A.
That is essential, an inlined method can be separated in
non-contiguous regions for performance during CFG alignment. IMHO, we
should register several code blocks for the same inlined method (if
the method's code was split into parts) through the
compiled_method_load(...) interface. This can be done completely on
the JIT side.
What do you, guys, think?
--
Egor Pasko
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by George Timoshenko <ge...@gmail.com>.
Eugene,
I've answered in JIRA:
https://issues.apache.org/jira/browse/HARMONY-2145#action_12455313
(Summary: Everything is OK)
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Eugene Ostrovsky <eu...@gmail.com>.
I've added instructions to reproduce to
*HARMONY-2145<http://issues.apache.org/jira/browse/HARMONY-2145>
* .
On 11/29/06, Eugene Ostrovsky <eu...@gmail.com> wrote:
>
> Guys,
>
> Could you please explain if it is ok that JIT reports inlined methods in
> intersecting regions?
> Executing VM with -Xem:opt option I've got the following log:
>
> --------------- BEGIN -----------------
> ..........
> Compiling
> java/lang/Thread.<init>(Ljava/lang/ThreadGroup;Ljava/lang/String;JJIZ)V
> ..........
> Adding Inlined method: java/lang/StringBuilder.append
> (J)Ljava/lang/StringBuilder;
> address: 01356D14 [69] mapLength: 1
> Adding Inlined method: java/lang/Long.toString (J)Ljava/lang/String;
> address: 01356D30 [63] mapLength: 1
> ..........
> --------------- END -----------------
>
> I.e. while compiling j.l.Thread constructor JIT inlined
> StringBuilder.append() & Long.toString() methods to the following regions:
> [ 0x01356D14 , 0x01356D14 + 69 )
> [ 0x01356D30 , 0x01356D30 + 63 )
>
> These regions overlap. Is it ok?
>
> Thanks,
> Eugene.
>
>
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Eugene Ostrovsky <eu...@gmail.com>.
Guys,
Could you please explain if it is ok that JIT reports inlined methods in
intersecting regions?
Executing VM with -Xem:opt option I've got the following log:
--------------- BEGIN -----------------
..........
Compiling
java/lang/Thread.<init>(Ljava/lang/ThreadGroup;Ljava/lang/String;JJIZ)V
..........
Adding Inlined method: java/lang/StringBuilder.append
(J)Ljava/lang/StringBuilder;
address: 01356D14 [69] mapLength: 1
Adding Inlined method: java/lang/Long.toString (J)Ljava/lang/String;
address: 01356D30 [63] mapLength: 1
..........
--------------- END -----------------
I.e. while compiling j.l.Thread constructor JIT inlined StringBuilder.append()
& Long.toString() methods to the following regions:
[ 0x01356D14 , 0x01356D14 + 69 )
[ 0x01356D30 , 0x01356D30 + 63 )
These regions overlap. Is it ok?
Thanks,
Eugene.
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by George Timoshenko <ge...@gmail.com>.
Eugene Ostrovsky wrote:
>> What should be the outer_method for methodC (A or B)?
>
> I meant the outmost method (A).
> Thanks.
Great! The patch is already in the issue
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Eugene Ostrovsky <eu...@gmail.com>.
> What should be the outer_method for methodC (A or B)?
I meant the outmost method (A).
Thanks.
On 11/24/06, George Timoshenko <ge...@gmail.com> wrote:
>
> 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 <ge...@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 <eu...@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 <ge...@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.
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >
> >>
> >>
> >
>
>
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by George Timoshenko <ge...@gmail.com>.
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 <ge...@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 <eu...@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 <ge...@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.
>> >> >
>> >> >
>> >>
>> >>
>> >
>>
>>
>
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Eugene Ostrovsky <eu...@gmail.com>.
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 <ge...@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 <eu...@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 <ge...@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.
> >> >
> >> >
> >>
> >>
> >
>
>
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by George Timoshenko <ge...@gmail.com>.
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 <eu...@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 <ge...@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.
>> >
>> >
>>
>>
>
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Pavel Ozhdikhin <pa...@gmail.com>.
Eugene,
I can answer 2 and 3. Please see inlined.
Thanks,
Pavel
On 11/21/06, Eugene Ostrovsky <eu...@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 <ge...@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.
> >
> >
>
>
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Eugene Ostrovsky <eu...@gmail.com>.
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?
3. What algorithm jit uses to inline methods? How can I create test class
which methods will be inlined.
On 11/13/06, George Timoshenko <ge...@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.
>
>
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by George Timoshenko <ge...@gmail.com>.
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.
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Eugene Ostrovsky <eu...@gmail.com>.
Opended issue *HARMONY-2145<https://issues.apache.org/jira/browse/HARMONY-2145>
* .
On 11/10/06, Eugene Ostrovsky <eu...@gmail.com> wrote:
>
> Hello All.
>
> One more "hole" in current JVMTI Profiling implementation is Compiled
> Method Load event.
>
> Current VM doesn't report this event for methods that are inlined by JIT.
> Though spec requires it to be sent for every compiled method:
> http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#CompiledMethodLoad
>
>
> 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.
>
> I'm not sure about which approach is better.
> Each of them requires additional interface function (1.- to JIT from VM;
> 2. - from VM to JIT).
>
> The second approach seems to be more complicated in terms of VM - JIT
> interaction. I mean that the following scheme "VM calls JIT's function to
> compile method. -> JIT's function in it's turn calls VM's function to notify
> about compiled methods. -> VM's function dispatches the event to TI
> agents..." introduces additional level of complexity than if "VM calls JIT's
> function to compile method. VM asks JIT about inlined methods. VM dispatches
> event to TI agents."
>
> Ideas & suggestions are welcome.
>
> Thanks,
> Eugene.
>
> On 10/24/06, Eugene Ostrovsky < eugene.s.ostrovsky@gmail.com> wrote:
> >
> > Hi all.
> >
> > It seems that we have most of JVMTI implemented in drlvm. Still some of
> > profiling support features is left.
> > I'm going to take a look on "VM Object Allocation" event.
> > I'll try to come up with design tomorrow.
> >
> > Thanks,
> > Eugene.
> >
> >
>
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Eugene Ostrovsky <eu...@gmail.com>.
Great.
That's what I was dreaming of. :)
There's one more issue related to HARMONY-2769 subject.
I guess that inlined method code region may be equal to it's caller method
region.
E.g. method a() is called from method b() which does nothing except calling
a(). b() in it's turn is called from method c().
Method a() could be inlined to b(), and b() could be inlined to c().
Thus code regions for a() and b() are the same, since b() has no it's own
instructions but only those inlined from a().
In this case VM using only region information couldn't determine which of
a() and b() is caller and which is callee.
It seems that to solve this problem we need JIT to report for the method not
the most outer method in inline chain (as it does in
H-2145-JIT-side.patch<http://issues.apache.org/jira/secure/attachment/12345590/H-2145-JIT-side.patch>)
but the first-hand caller method.
Is it possible for JIT?
On 18 Dec 2006 18:09:45 +0600, Egor Pasko <eg...@gmail.com> wrote:
>
> FYI:
> Just to track things right I filed a new JIRA with proposal to
> InlineInfo unification:
>
> HARMONY-2769 [drlvm][jit] use per-region InlineInfo from global
> storage in VM to report stack frames of inlined methods
>
> depends on HARMONY-2145, as expected. Feel free to vote :)
>
> On the 0x223 day of Apache Harmony Egor Pasko wrote:
> > On the 0x222 day of Apache Harmony Eugene Ostrovsky wrote:
> > > Do I understand correctly that per-call-inline-info is a list of
> inline
> > > chains for every call instruction offset within a code chunk?
> >
> > yes
> >
> > > If so, think we may replace per-call-inline-info with
> > > per-region-inline-info. Why can't we use per-region-inline-info for
> stack
> > > tracing.
> >
> > Relying on per-region-inline-info introduces some constraints for JIT
> > design. Specifically, it becomes not easy to move instruction regions
> > across method boundaries.
> >
> > On the other hand, we do not move calls today (and I doubt we will
> > since it is easier to inline than prove that side effects allows
> > swapping two calls). JIT guys, comment here if you have other opinions!
> >
> > So, frankly, I do not see any strong reasons to stick with
> > per-call-inline-info. The reasons to use them might be:
> > * less memory consuming than region-based (that's an open question,
> > though), in non-JVMTI mode we can fall down to call-based with
> > region-based=OFF
> > * more precise (JIT mechanisms guarantee that this info won't be lost)
> >
> > Although, there is a disadvantage of per-call-inline-info:
> > * we cannot afford reporting stack frames on exceptions (because there
> > are a lot fo potentially exceptional instructions and storing inline
> > chains for all of them would be ineffective) see HARMONY-2114
> >
> > > The other question is: which component should collect and process
> > > inline-info?
> > > The current approach is that JIT collects the data and provides
> interface
> > > for VM to extract useful information from it.
> > > The other possible approach could be in using JIT to VM notifications
> about
> > > compiled method (as George proposed). VM can store the inline info by
> itself
> > > and process it on demand without disturbing JIT.
> >
> > I like this idea! Just a reminder: in this approach VM should not forget
> to:
> > * free associated resources, when code chunks are freed
> > * keep the inline tree to report stack traces properly
> >
> > currently, you have all tools to implement this proposal on the VM
> > side. per-call-inline-info is used in st_print_stack(...) and in some
> > other tricky places. To completely eliminate per-call-inline-info you
> > will need to retarget those places at using per-region-inline-info.
> >
> > Anyway, it is worth a try. We can then measure how much space we saved
> > in JVMTI mode and in default mode. That would be interesting.
> >
> > > What do you think about these proposals?
> >
> > Using *one inline-info* approach is better than using two. So, I support
> > your unification proposal. AFAIR, Eclipse is sensitive to reporting
> > stack precisely, so, there is something to check the prototype on.
> >
> > > On 10 Nov 2006 20:27:45 +0600, Egor Pasko <eg...@gmail.com>
> wrote:
> > > >
> > > > On the 0x21D day of Apache Harmony Eugene Ostrovsky wrote:
> > > > > >BTW, I am curious, is it OK for TI when a method is compiled
> several
> > > > times
> > > > > and put on different addrs?
> > > > >
> > > > > Yes, it's ok. All compiled forms of the method must be reported.
> > > > > Moreover when compiled form of the method is unloaded from memory
> it
> > > > must be
> > > > > reported with Compiled Method Unload event.
> > > > > We should to think about this also.
> > > > > It seems to me that most natural way to implement CMU
> > > > event is to iterate
> > > > > over all methods of class being unloaded and all theirs inlined
> methods.
> > > >
> > > > yes, sure, so we need to store the inlining data from JIT until
> unloading
> > > >
> > > > > The similar problem is with GenerateEvents function (
> > > > >
> > > >
> http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#GenerateEvents
> > > > ).
> > > > > It should report all already compiled methods at any the time, on
> > > > agent's
> > > > > request.
> > > > > It can be done also by iterating over all loaded class -> their
> methods
> > > > ->
> > > > > their inlined methods.
> > > > >
> > > > > What do you think?
> > > >
> > > > The question is where to store this info. AFAIK, there is a special
> > > > CodeChunkInfo->_jit_info_block which is OK for that. Some info is
> > > > stored there already, i. e. mapping of call instructions into
> "inline
> > > > chain" they are in (so called per-call-inline-info). That's for
> > > > precise stack traces (which is a necessity).
> > > >
> > > > Here we have a "region"-inline-info. Which is for TI. We can store
> it
> > > > in the CodeChunkInfo->_jit_info_block, but, unfortunately, it is not
> > > > typed, and is just a memory block. JIT is responsible for
> > > > serializing/deserializing to/from it. What I am dreaming of is a
> > > > tagged _jit_info_block. So "jit info" be a list of mem blocks, each
> > > > marked with it's tag, so appropriate info can be found more
> naturally
> > > > (not deserializing all big code block)
> > > >
> > > > Do you have alternative proposals where to store region-inline-info?
> > > >
> > > > There is one more issue, of course. Why not we unify both
> inline-infos
> > > > (per-call and region-based)? IMHO, region-based inline-info is less
> > > > precise (because of possible code motion in JIT), TI would not
> suffer
> > > > much of this (I hope), but precise stack traces can suffer. So, I am
> > > > for leaving both approaches as-is for now.
> > > >
> > > > It is also interesting how much memory would, for example, Eclipse
> eat
> > > > for region-based inline-info and for per-call-inline-info when
> > > > started? I cannot predict what is more compact.
> > > >
> > > > > Thanks,
> > > > > Eugene.
> > > > >
> > > > > On 10 Nov 2006 18:48:43 +0600, Egor Pasko <eg...@gmail.com>
> wrote:
> > > > > >
> > > > > > On the 0x21D day of Apache Harmony Eugene Ostrovsky wrote:
> > > > > > > Hello All.
> > > > > > >
> > > > > > > One more "hole" in current JVMTI Profiling implementation is
> > > > Compiled
> > > > > > Method
> > > > > > > Load event.
> > > > > > >
> > > > > > > Current VM doesn't report this event for methods that are
> inlined by
> > > > > > JIT.
> > > > > > > Though spec requires it to be sent for every compiled method:
> > > > > > >
> > > > > >
> > > >
> http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#CompiledMethodLoad
> > > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > > > I'm not sure about which approach is better.
> > > > > > > Each of them requires additional interface function (1.- to
> JIT from
> > > > VM;
> > > > > > 2.
> > > > > > > - from VM to JIT).
> > > > > > >
> > > > > > > The second approach seems to be more complicated in terms of
> VM -
> > > > JIT
> > > > > > > interaction. I mean that the following scheme "VM calls JIT's
> > > > function
> > > > > > to
> > > > > > > compile method. -> JIT's function in it's turn calls VM's
> function
> > > > to
> > > > > > notify
> > > > > > > about compiled methods. -> VM's function dispatches the event
> to TI
> > > > > > > agents..." introduces additional level of complexity than if
> "VM
> > > > calls
> > > > > > JIT's
> > > > > > > function to compile method. VM asks JIT about inlined methods.
> VM
> > > > > > dispatches
> > > > > > > event to TI agents."
> > > > > >
> > > > > > Correct me if I am wrong, I see the picture as:
> > > > > > (1):
> > > > > > 1.1. VM -call-> JIT (compile a method for me, please)
> > > > > > 1.2. VM -call-> JIT (gimme the list of addresses/functions)
> > > > > > 1.3. VM -call-> JIT (please, free your resources allocated for
> these
> > > > > > addrs)
> > > > > >
> > > > > > (2):
> > > > > > 2.1. VM -call-> JIT (compile a method for me, please)
> > > > > > 2.2. JIT -call-> VM (I generated code from addr X to addr Y,
> look at
> > > > this
> > > > > > one)
> > > > > > 2.3. VM -call-> TI (here is the code for you)
> > > > > >
> > > > > > (1) has a disadvantage in case one JIT instance compiles
> different
> > > > > > methods in parallel. And we should have a synchronized method
> addr
> > > > > > repository, which is not easy to wipe out in the right way.
> > > > > >
> > > > > > (2) seems more straightforward from the JIT side because JIT can
> > > > > > report method boundary addresses as soon as it determines them
> on
> > > > > > emitting. That simplifies JIT impl (no allocating/freeng/synch).
> > > > > >
> > > > > > BTW, I am curious, is it OK for TI when a method is compiled
> several
> > > > > > times and put on different addrs?
> > > > > >
> > > > > > > Ideas & suggestions are welcome.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Eugene.
> > > > > > >
> > > > > > > On 10/24/06, Eugene Ostrovsky <eu...@gmail.com>
> wrote:
> > > > > > > >
> > > > > > > > Hi all.
> > > > > > > >
> > > > > > > > It seems that we have most of JVMTI implemented in drlvm.
> Still
> > > > some
> > > > > > of
> > > > > > > > profiling support features is left.
> > > > > > > > I'm going to take a look on "VM Object Allocation" event.
> > > > > > > > I'll try to come up with design tomorrow.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Eugene.
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > > --
> > > > > > Egor Pasko
> > > > > >
> > > > > >
> > > >
> > > > --
> > > > Egor Pasko
> > > >
> > > >
> >
> > --
> > Egor Pasko
> >
> >
>
> --
> Egor Pasko
>
>
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Egor Pasko <eg...@gmail.com>.
FYI:
Just to track things right I filed a new JIRA with proposal to
InlineInfo unification:
HARMONY-2769 [drlvm][jit] use per-region InlineInfo from global
storage in VM to report stack frames of inlined methods
depends on HARMONY-2145, as expected. Feel free to vote :)
On the 0x223 day of Apache Harmony Egor Pasko wrote:
> On the 0x222 day of Apache Harmony Eugene Ostrovsky wrote:
> > Do I understand correctly that per-call-inline-info is a list of inline
> > chains for every call instruction offset within a code chunk?
>
> yes
>
> > If so, think we may replace per-call-inline-info with
> > per-region-inline-info. Why can't we use per-region-inline-info for stack
> > tracing.
>
> Relying on per-region-inline-info introduces some constraints for JIT
> design. Specifically, it becomes not easy to move instruction regions
> across method boundaries.
>
> On the other hand, we do not move calls today (and I doubt we will
> since it is easier to inline than prove that side effects allows
> swapping two calls). JIT guys, comment here if you have other opinions!
>
> So, frankly, I do not see any strong reasons to stick with
> per-call-inline-info. The reasons to use them might be:
> * less memory consuming than region-based (that's an open question,
> though), in non-JVMTI mode we can fall down to call-based with
> region-based=OFF
> * more precise (JIT mechanisms guarantee that this info won't be lost)
>
> Although, there is a disadvantage of per-call-inline-info:
> * we cannot afford reporting stack frames on exceptions (because there
> are a lot fo potentially exceptional instructions and storing inline
> chains for all of them would be ineffective) see HARMONY-2114
>
> > The other question is: which component should collect and process
> > inline-info?
> > The current approach is that JIT collects the data and provides interface
> > for VM to extract useful information from it.
> > The other possible approach could be in using JIT to VM notifications about
> > compiled method (as George proposed). VM can store the inline info by itself
> > and process it on demand without disturbing JIT.
>
> I like this idea! Just a reminder: in this approach VM should not forget to:
> * free associated resources, when code chunks are freed
> * keep the inline tree to report stack traces properly
>
> currently, you have all tools to implement this proposal on the VM
> side. per-call-inline-info is used in st_print_stack(...) and in some
> other tricky places. To completely eliminate per-call-inline-info you
> will need to retarget those places at using per-region-inline-info.
>
> Anyway, it is worth a try. We can then measure how much space we saved
> in JVMTI mode and in default mode. That would be interesting.
>
> > What do you think about these proposals?
>
> Using *one inline-info* approach is better than using two. So, I support
> your unification proposal. AFAIR, Eclipse is sensitive to reporting
> stack precisely, so, there is something to check the prototype on.
>
> > On 10 Nov 2006 20:27:45 +0600, Egor Pasko <eg...@gmail.com> wrote:
> > >
> > > On the 0x21D day of Apache Harmony Eugene Ostrovsky wrote:
> > > > >BTW, I am curious, is it OK for TI when a method is compiled several
> > > times
> > > > and put on different addrs?
> > > >
> > > > Yes, it's ok. All compiled forms of the method must be reported.
> > > > Moreover when compiled form of the method is unloaded from memory it
> > > must be
> > > > reported with Compiled Method Unload event.
> > > > We should to think about this also.
> > > > It seems to me that most natural way to implement CMU
> > > event is to iterate
> > > > over all methods of class being unloaded and all theirs inlined methods.
> > >
> > > yes, sure, so we need to store the inlining data from JIT until unloading
> > >
> > > > The similar problem is with GenerateEvents function (
> > > >
> > > http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#GenerateEvents
> > > ).
> > > > It should report all already compiled methods at any the time, on
> > > agent's
> > > > request.
> > > > It can be done also by iterating over all loaded class -> their methods
> > > ->
> > > > their inlined methods.
> > > >
> > > > What do you think?
> > >
> > > The question is where to store this info. AFAIK, there is a special
> > > CodeChunkInfo->_jit_info_block which is OK for that. Some info is
> > > stored there already, i. e. mapping of call instructions into "inline
> > > chain" they are in (so called per-call-inline-info). That's for
> > > precise stack traces (which is a necessity).
> > >
> > > Here we have a "region"-inline-info. Which is for TI. We can store it
> > > in the CodeChunkInfo->_jit_info_block, but, unfortunately, it is not
> > > typed, and is just a memory block. JIT is responsible for
> > > serializing/deserializing to/from it. What I am dreaming of is a
> > > tagged _jit_info_block. So "jit info" be a list of mem blocks, each
> > > marked with it's tag, so appropriate info can be found more naturally
> > > (not deserializing all big code block)
> > >
> > > Do you have alternative proposals where to store region-inline-info?
> > >
> > > There is one more issue, of course. Why not we unify both inline-infos
> > > (per-call and region-based)? IMHO, region-based inline-info is less
> > > precise (because of possible code motion in JIT), TI would not suffer
> > > much of this (I hope), but precise stack traces can suffer. So, I am
> > > for leaving both approaches as-is for now.
> > >
> > > It is also interesting how much memory would, for example, Eclipse eat
> > > for region-based inline-info and for per-call-inline-info when
> > > started? I cannot predict what is more compact.
> > >
> > > > Thanks,
> > > > Eugene.
> > > >
> > > > On 10 Nov 2006 18:48:43 +0600, Egor Pasko <eg...@gmail.com> wrote:
> > > > >
> > > > > On the 0x21D day of Apache Harmony Eugene Ostrovsky wrote:
> > > > > > Hello All.
> > > > > >
> > > > > > One more "hole" in current JVMTI Profiling implementation is
> > > Compiled
> > > > > Method
> > > > > > Load event.
> > > > > >
> > > > > > Current VM doesn't report this event for methods that are inlined by
> > > > > JIT.
> > > > > > Though spec requires it to be sent for every compiled method:
> > > > > >
> > > > >
> > > http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#CompiledMethodLoad
> > > > > >
> > > > > > 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.
> > > > > >
> > > > > > I'm not sure about which approach is better.
> > > > > > Each of them requires additional interface function (1.- to JIT from
> > > VM;
> > > > > 2.
> > > > > > - from VM to JIT).
> > > > > >
> > > > > > The second approach seems to be more complicated in terms of VM -
> > > JIT
> > > > > > interaction. I mean that the following scheme "VM calls JIT's
> > > function
> > > > > to
> > > > > > compile method. -> JIT's function in it's turn calls VM's function
> > > to
> > > > > notify
> > > > > > about compiled methods. -> VM's function dispatches the event to TI
> > > > > > agents..." introduces additional level of complexity than if "VM
> > > calls
> > > > > JIT's
> > > > > > function to compile method. VM asks JIT about inlined methods. VM
> > > > > dispatches
> > > > > > event to TI agents."
> > > > >
> > > > > Correct me if I am wrong, I see the picture as:
> > > > > (1):
> > > > > 1.1. VM -call-> JIT (compile a method for me, please)
> > > > > 1.2. VM -call-> JIT (gimme the list of addresses/functions)
> > > > > 1.3. VM -call-> JIT (please, free your resources allocated for these
> > > > > addrs)
> > > > >
> > > > > (2):
> > > > > 2.1. VM -call-> JIT (compile a method for me, please)
> > > > > 2.2. JIT -call-> VM (I generated code from addr X to addr Y, look at
> > > this
> > > > > one)
> > > > > 2.3. VM -call-> TI (here is the code for you)
> > > > >
> > > > > (1) has a disadvantage in case one JIT instance compiles different
> > > > > methods in parallel. And we should have a synchronized method addr
> > > > > repository, which is not easy to wipe out in the right way.
> > > > >
> > > > > (2) seems more straightforward from the JIT side because JIT can
> > > > > report method boundary addresses as soon as it determines them on
> > > > > emitting. That simplifies JIT impl (no allocating/freeng/synch).
> > > > >
> > > > > BTW, I am curious, is it OK for TI when a method is compiled several
> > > > > times and put on different addrs?
> > > > >
> > > > > > Ideas & suggestions are welcome.
> > > > > >
> > > > > > Thanks,
> > > > > > Eugene.
> > > > > >
> > > > > > On 10/24/06, Eugene Ostrovsky <eu...@gmail.com> wrote:
> > > > > > >
> > > > > > > Hi all.
> > > > > > >
> > > > > > > It seems that we have most of JVMTI implemented in drlvm. Still
> > > some
> > > > > of
> > > > > > > profiling support features is left.
> > > > > > > I'm going to take a look on "VM Object Allocation" event.
> > > > > > > I'll try to come up with design tomorrow.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Eugene.
> > > > > > >
> > > > > > >
> > > > >
> > > > > --
> > > > > Egor Pasko
> > > > >
> > > > >
> > >
> > > --
> > > Egor Pasko
> > >
> > >
>
> --
> Egor Pasko
>
>
--
Egor Pasko
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x222 day of Apache Harmony Eugene Ostrovsky wrote:
> Do I understand correctly that per-call-inline-info is a list of inline
> chains for every call instruction offset within a code chunk?
yes
> If so, think we may replace per-call-inline-info with
> per-region-inline-info. Why can't we use per-region-inline-info for stack
> tracing.
Relying on per-region-inline-info introduces some constraints for JIT
design. Specifically, it becomes not easy to move instruction regions
across method boundaries.
On the other hand, we do not move calls today (and I doubt we will
since it is easier to inline than prove that side effects allows
swapping two calls). JIT guys, comment here if you have other opinions!
So, frankly, I do not see any strong reasons to stick with
per-call-inline-info. The reasons to use them might be:
* less memory consuming than region-based (that's an open question,
though), in non-JVMTI mode we can fall down to call-based with
region-based=OFF
* more precise (JIT mechanisms guarantee that this info won't be lost)
Although, there is a disadvantage of per-call-inline-info:
* we cannot afford reporting stack frames on exceptions (because there
are a lot fo potentially exceptional instructions and storing inline
chains for all of them would be ineffective) see HARMONY-2114
> The other question is: which component should collect and process
> inline-info?
> The current approach is that JIT collects the data and provides interface
> for VM to extract useful information from it.
> The other possible approach could be in using JIT to VM notifications about
> compiled method (as George proposed). VM can store the inline info by itself
> and process it on demand without disturbing JIT.
I like this idea! Just a reminder: in this approach VM should not forget to:
* free associated resources, when code chunks are freed
* keep the inline tree to report stack traces properly
currently, you have all tools to implement this proposal on the VM
side. per-call-inline-info is used in st_print_stack(...) and in some
other tricky places. To completely eliminate per-call-inline-info you
will need to retarget those places at using per-region-inline-info.
Anyway, it is worth a try. We can then measure how much space we saved
in JVMTI mode and in default mode. That would be interesting.
> What do you think about these proposals?
Using *one inline-info* approach is better than using two. So, I support
your unification proposal. AFAIR, Eclipse is sensitive to reporting
stack precisely, so, there is something to check the prototype on.
> On 10 Nov 2006 20:27:45 +0600, Egor Pasko <eg...@gmail.com> wrote:
> >
> > On the 0x21D day of Apache Harmony Eugene Ostrovsky wrote:
> > > >BTW, I am curious, is it OK for TI when a method is compiled several
> > times
> > > and put on different addrs?
> > >
> > > Yes, it's ok. All compiled forms of the method must be reported.
> > > Moreover when compiled form of the method is unloaded from memory it
> > must be
> > > reported with Compiled Method Unload event.
> > > We should to think about this also.
> > > It seems to me that most natural way to implement CMU
> > event is to iterate
> > > over all methods of class being unloaded and all theirs inlined methods.
> >
> > yes, sure, so we need to store the inlining data from JIT until unloading
> >
> > > The similar problem is with GenerateEvents function (
> > >
> > http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#GenerateEvents
> > ).
> > > It should report all already compiled methods at any the time, on
> > agent's
> > > request.
> > > It can be done also by iterating over all loaded class -> their methods
> > ->
> > > their inlined methods.
> > >
> > > What do you think?
> >
> > The question is where to store this info. AFAIK, there is a special
> > CodeChunkInfo->_jit_info_block which is OK for that. Some info is
> > stored there already, i. e. mapping of call instructions into "inline
> > chain" they are in (so called per-call-inline-info). That's for
> > precise stack traces (which is a necessity).
> >
> > Here we have a "region"-inline-info. Which is for TI. We can store it
> > in the CodeChunkInfo->_jit_info_block, but, unfortunately, it is not
> > typed, and is just a memory block. JIT is responsible for
> > serializing/deserializing to/from it. What I am dreaming of is a
> > tagged _jit_info_block. So "jit info" be a list of mem blocks, each
> > marked with it's tag, so appropriate info can be found more naturally
> > (not deserializing all big code block)
> >
> > Do you have alternative proposals where to store region-inline-info?
> >
> > There is one more issue, of course. Why not we unify both inline-infos
> > (per-call and region-based)? IMHO, region-based inline-info is less
> > precise (because of possible code motion in JIT), TI would not suffer
> > much of this (I hope), but precise stack traces can suffer. So, I am
> > for leaving both approaches as-is for now.
> >
> > It is also interesting how much memory would, for example, Eclipse eat
> > for region-based inline-info and for per-call-inline-info when
> > started? I cannot predict what is more compact.
> >
> > > Thanks,
> > > Eugene.
> > >
> > > On 10 Nov 2006 18:48:43 +0600, Egor Pasko <eg...@gmail.com> wrote:
> > > >
> > > > On the 0x21D day of Apache Harmony Eugene Ostrovsky wrote:
> > > > > Hello All.
> > > > >
> > > > > One more "hole" in current JVMTI Profiling implementation is
> > Compiled
> > > > Method
> > > > > Load event.
> > > > >
> > > > > Current VM doesn't report this event for methods that are inlined by
> > > > JIT.
> > > > > Though spec requires it to be sent for every compiled method:
> > > > >
> > > >
> > http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#CompiledMethodLoad
> > > > >
> > > > > 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.
> > > > >
> > > > > I'm not sure about which approach is better.
> > > > > Each of them requires additional interface function (1.- to JIT from
> > VM;
> > > > 2.
> > > > > - from VM to JIT).
> > > > >
> > > > > The second approach seems to be more complicated in terms of VM -
> > JIT
> > > > > interaction. I mean that the following scheme "VM calls JIT's
> > function
> > > > to
> > > > > compile method. -> JIT's function in it's turn calls VM's function
> > to
> > > > notify
> > > > > about compiled methods. -> VM's function dispatches the event to TI
> > > > > agents..." introduces additional level of complexity than if "VM
> > calls
> > > > JIT's
> > > > > function to compile method. VM asks JIT about inlined methods. VM
> > > > dispatches
> > > > > event to TI agents."
> > > >
> > > > Correct me if I am wrong, I see the picture as:
> > > > (1):
> > > > 1.1. VM -call-> JIT (compile a method for me, please)
> > > > 1.2. VM -call-> JIT (gimme the list of addresses/functions)
> > > > 1.3. VM -call-> JIT (please, free your resources allocated for these
> > > > addrs)
> > > >
> > > > (2):
> > > > 2.1. VM -call-> JIT (compile a method for me, please)
> > > > 2.2. JIT -call-> VM (I generated code from addr X to addr Y, look at
> > this
> > > > one)
> > > > 2.3. VM -call-> TI (here is the code for you)
> > > >
> > > > (1) has a disadvantage in case one JIT instance compiles different
> > > > methods in parallel. And we should have a synchronized method addr
> > > > repository, which is not easy to wipe out in the right way.
> > > >
> > > > (2) seems more straightforward from the JIT side because JIT can
> > > > report method boundary addresses as soon as it determines them on
> > > > emitting. That simplifies JIT impl (no allocating/freeng/synch).
> > > >
> > > > BTW, I am curious, is it OK for TI when a method is compiled several
> > > > times and put on different addrs?
> > > >
> > > > > Ideas & suggestions are welcome.
> > > > >
> > > > > Thanks,
> > > > > Eugene.
> > > > >
> > > > > On 10/24/06, Eugene Ostrovsky <eu...@gmail.com> wrote:
> > > > > >
> > > > > > Hi all.
> > > > > >
> > > > > > It seems that we have most of JVMTI implemented in drlvm. Still
> > some
> > > > of
> > > > > > profiling support features is left.
> > > > > > I'm going to take a look on "VM Object Allocation" event.
> > > > > > I'll try to come up with design tomorrow.
> > > > > >
> > > > > > Thanks,
> > > > > > Eugene.
> > > > > >
> > > > > >
> > > >
> > > > --
> > > > Egor Pasko
> > > >
> > > >
> >
> > --
> > Egor Pasko
> >
> >
--
Egor Pasko
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Eugene Ostrovsky <eu...@gmail.com>.
Do I understand correctly that per-call-inline-info is a list of inline
chains for every call instruction offset within a code chunk?
If so, think we may replace per-call-inline-info with
per-region-inline-info. Why can't we use per-region-inline-info for stack
tracing.
The other question is: which component should collect and process
inline-info?
The current approach is that JIT collects the data and provides interface
for VM to extract useful information from it.
The other possible approach could be in using JIT to VM notifications about
compiled method (as George proposed). VM can store the inline info by itself
and process it on demand without disturbing JIT.
What do you think about these proposals?
On 10 Nov 2006 20:27:45 +0600, Egor Pasko <eg...@gmail.com> wrote:
>
> On the 0x21D day of Apache Harmony Eugene Ostrovsky wrote:
> > >BTW, I am curious, is it OK for TI when a method is compiled several
> times
> > and put on different addrs?
> >
> > Yes, it's ok. All compiled forms of the method must be reported.
> > Moreover when compiled form of the method is unloaded from memory it
> must be
> > reported with Compiled Method Unload event.
> > We should to think about this also.
> > It seems to me that most natural way to implement CMU
> event is to iterate
> > over all methods of class being unloaded and all theirs inlined methods.
>
> yes, sure, so we need to store the inlining data from JIT until unloading
>
> > The similar problem is with GenerateEvents function (
> >
> http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#GenerateEvents
> ).
> > It should report all already compiled methods at any the time, on
> agent's
> > request.
> > It can be done also by iterating over all loaded class -> their methods
> ->
> > their inlined methods.
> >
> > What do you think?
>
> The question is where to store this info. AFAIK, there is a special
> CodeChunkInfo->_jit_info_block which is OK for that. Some info is
> stored there already, i. e. mapping of call instructions into "inline
> chain" they are in (so called per-call-inline-info). That's for
> precise stack traces (which is a necessity).
>
> Here we have a "region"-inline-info. Which is for TI. We can store it
> in the CodeChunkInfo->_jit_info_block, but, unfortunately, it is not
> typed, and is just a memory block. JIT is responsible for
> serializing/deserializing to/from it. What I am dreaming of is a
> tagged _jit_info_block. So "jit info" be a list of mem blocks, each
> marked with it's tag, so appropriate info can be found more naturally
> (not deserializing all big code block)
>
> Do you have alternative proposals where to store region-inline-info?
>
> There is one more issue, of course. Why not we unify both inline-infos
> (per-call and region-based)? IMHO, region-based inline-info is less
> precise (because of possible code motion in JIT), TI would not suffer
> much of this (I hope), but precise stack traces can suffer. So, I am
> for leaving both approaches as-is for now.
>
> It is also interesting how much memory would, for example, Eclipse eat
> for region-based inline-info and for per-call-inline-info when
> started? I cannot predict what is more compact.
>
> > Thanks,
> > Eugene.
> >
> > On 10 Nov 2006 18:48:43 +0600, Egor Pasko <eg...@gmail.com> wrote:
> > >
> > > On the 0x21D day of Apache Harmony Eugene Ostrovsky wrote:
> > > > Hello All.
> > > >
> > > > One more "hole" in current JVMTI Profiling implementation is
> Compiled
> > > Method
> > > > Load event.
> > > >
> > > > Current VM doesn't report this event for methods that are inlined by
> > > JIT.
> > > > Though spec requires it to be sent for every compiled method:
> > > >
> > >
> http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#CompiledMethodLoad
> > > >
> > > > 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.
> > > >
> > > > I'm not sure about which approach is better.
> > > > Each of them requires additional interface function (1.- to JIT from
> VM;
> > > 2.
> > > > - from VM to JIT).
> > > >
> > > > The second approach seems to be more complicated in terms of VM -
> JIT
> > > > interaction. I mean that the following scheme "VM calls JIT's
> function
> > > to
> > > > compile method. -> JIT's function in it's turn calls VM's function
> to
> > > notify
> > > > about compiled methods. -> VM's function dispatches the event to TI
> > > > agents..." introduces additional level of complexity than if "VM
> calls
> > > JIT's
> > > > function to compile method. VM asks JIT about inlined methods. VM
> > > dispatches
> > > > event to TI agents."
> > >
> > > Correct me if I am wrong, I see the picture as:
> > > (1):
> > > 1.1. VM -call-> JIT (compile a method for me, please)
> > > 1.2. VM -call-> JIT (gimme the list of addresses/functions)
> > > 1.3. VM -call-> JIT (please, free your resources allocated for these
> > > addrs)
> > >
> > > (2):
> > > 2.1. VM -call-> JIT (compile a method for me, please)
> > > 2.2. JIT -call-> VM (I generated code from addr X to addr Y, look at
> this
> > > one)
> > > 2.3. VM -call-> TI (here is the code for you)
> > >
> > > (1) has a disadvantage in case one JIT instance compiles different
> > > methods in parallel. And we should have a synchronized method addr
> > > repository, which is not easy to wipe out in the right way.
> > >
> > > (2) seems more straightforward from the JIT side because JIT can
> > > report method boundary addresses as soon as it determines them on
> > > emitting. That simplifies JIT impl (no allocating/freeng/synch).
> > >
> > > BTW, I am curious, is it OK for TI when a method is compiled several
> > > times and put on different addrs?
> > >
> > > > Ideas & suggestions are welcome.
> > > >
> > > > Thanks,
> > > > Eugene.
> > > >
> > > > On 10/24/06, Eugene Ostrovsky <eu...@gmail.com> wrote:
> > > > >
> > > > > Hi all.
> > > > >
> > > > > It seems that we have most of JVMTI implemented in drlvm. Still
> some
> > > of
> > > > > profiling support features is left.
> > > > > I'm going to take a look on "VM Object Allocation" event.
> > > > > I'll try to come up with design tomorrow.
> > > > >
> > > > > Thanks,
> > > > > Eugene.
> > > > >
> > > > >
> > >
> > > --
> > > Egor Pasko
> > >
> > >
>
> --
> Egor Pasko
>
>
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x21D day of Apache Harmony Eugene Ostrovsky wrote:
> >BTW, I am curious, is it OK for TI when a method is compiled several times
> and put on different addrs?
>
> Yes, it's ok. All compiled forms of the method must be reported.
> Moreover when compiled form of the method is unloaded from memory it must be
> reported with Compiled Method Unload event.
> We should to think about this also.
> It seems to me that most natural way to implement CMU event is to iterate
> over all methods of class being unloaded and all theirs inlined methods.
yes, sure, so we need to store the inlining data from JIT until unloading
> The similar problem is with GenerateEvents function (
> http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#GenerateEvents).
> It should report all already compiled methods at any the time, on agent's
> request.
> It can be done also by iterating over all loaded class -> their methods ->
> their inlined methods.
>
> What do you think?
The question is where to store this info. AFAIK, there is a special
CodeChunkInfo->_jit_info_block which is OK for that. Some info is
stored there already, i. e. mapping of call instructions into "inline
chain" they are in (so called per-call-inline-info). That's for
precise stack traces (which is a necessity).
Here we have a "region"-inline-info. Which is for TI. We can store it
in the CodeChunkInfo->_jit_info_block, but, unfortunately, it is not
typed, and is just a memory block. JIT is responsible for
serializing/deserializing to/from it. What I am dreaming of is a
tagged _jit_info_block. So "jit info" be a list of mem blocks, each
marked with it's tag, so appropriate info can be found more naturally
(not deserializing all big code block)
Do you have alternative proposals where to store region-inline-info?
There is one more issue, of course. Why not we unify both inline-infos
(per-call and region-based)? IMHO, region-based inline-info is less
precise (because of possible code motion in JIT), TI would not suffer
much of this (I hope), but precise stack traces can suffer. So, I am
for leaving both approaches as-is for now.
It is also interesting how much memory would, for example, Eclipse eat
for region-based inline-info and for per-call-inline-info when
started? I cannot predict what is more compact.
> Thanks,
> Eugene.
>
> On 10 Nov 2006 18:48:43 +0600, Egor Pasko <eg...@gmail.com> wrote:
> >
> > On the 0x21D day of Apache Harmony Eugene Ostrovsky wrote:
> > > Hello All.
> > >
> > > One more "hole" in current JVMTI Profiling implementation is Compiled
> > Method
> > > Load event.
> > >
> > > Current VM doesn't report this event for methods that are inlined by
> > JIT.
> > > Though spec requires it to be sent for every compiled method:
> > >
> > http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#CompiledMethodLoad
> > >
> > > 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.
> > >
> > > I'm not sure about which approach is better.
> > > Each of them requires additional interface function (1.- to JIT from VM;
> > 2.
> > > - from VM to JIT).
> > >
> > > The second approach seems to be more complicated in terms of VM - JIT
> > > interaction. I mean that the following scheme "VM calls JIT's function
> > to
> > > compile method. -> JIT's function in it's turn calls VM's function to
> > notify
> > > about compiled methods. -> VM's function dispatches the event to TI
> > > agents..." introduces additional level of complexity than if "VM calls
> > JIT's
> > > function to compile method. VM asks JIT about inlined methods. VM
> > dispatches
> > > event to TI agents."
> >
> > Correct me if I am wrong, I see the picture as:
> > (1):
> > 1.1. VM -call-> JIT (compile a method for me, please)
> > 1.2. VM -call-> JIT (gimme the list of addresses/functions)
> > 1.3. VM -call-> JIT (please, free your resources allocated for these
> > addrs)
> >
> > (2):
> > 2.1. VM -call-> JIT (compile a method for me, please)
> > 2.2. JIT -call-> VM (I generated code from addr X to addr Y, look at this
> > one)
> > 2.3. VM -call-> TI (here is the code for you)
> >
> > (1) has a disadvantage in case one JIT instance compiles different
> > methods in parallel. And we should have a synchronized method addr
> > repository, which is not easy to wipe out in the right way.
> >
> > (2) seems more straightforward from the JIT side because JIT can
> > report method boundary addresses as soon as it determines them on
> > emitting. That simplifies JIT impl (no allocating/freeng/synch).
> >
> > BTW, I am curious, is it OK for TI when a method is compiled several
> > times and put on different addrs?
> >
> > > Ideas & suggestions are welcome.
> > >
> > > Thanks,
> > > Eugene.
> > >
> > > On 10/24/06, Eugene Ostrovsky <eu...@gmail.com> wrote:
> > > >
> > > > Hi all.
> > > >
> > > > It seems that we have most of JVMTI implemented in drlvm. Still some
> > of
> > > > profiling support features is left.
> > > > I'm going to take a look on "VM Object Allocation" event.
> > > > I'll try to come up with design tomorrow.
> > > >
> > > > Thanks,
> > > > Eugene.
> > > >
> > > >
> >
> > --
> > Egor Pasko
> >
> >
--
Egor Pasko
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Eugene Ostrovsky <eu...@gmail.com>.
>BTW, I am curious, is it OK for TI when a method is compiled several times
and put on different addrs?
Yes, it's ok. All compiled forms of the method must be reported.
Moreover when compiled form of the method is unloaded from memory it must be
reported with Compiled Method Unload event.
We should to think about this also.
It seems to me that most natural way to implement CMU event is to iterate
over all methods of class being unloaded and all theirs inlined methods.
The similar problem is with GenerateEvents function (
http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#GenerateEvents).
It should report all already compiled methods at any the time, on agent's
request.
It can be done also by iterating over all loaded class -> their methods ->
their inlined methods.
What do you think?
Thanks,
Eugene.
On 10 Nov 2006 18:48:43 +0600, Egor Pasko <eg...@gmail.com> wrote:
>
> On the 0x21D day of Apache Harmony Eugene Ostrovsky wrote:
> > Hello All.
> >
> > One more "hole" in current JVMTI Profiling implementation is Compiled
> Method
> > Load event.
> >
> > Current VM doesn't report this event for methods that are inlined by
> JIT.
> > Though spec requires it to be sent for every compiled method:
> >
> http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#CompiledMethodLoad
> >
> > 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.
> >
> > I'm not sure about which approach is better.
> > Each of them requires additional interface function (1.- to JIT from VM;
> 2.
> > - from VM to JIT).
> >
> > The second approach seems to be more complicated in terms of VM - JIT
> > interaction. I mean that the following scheme "VM calls JIT's function
> to
> > compile method. -> JIT's function in it's turn calls VM's function to
> notify
> > about compiled methods. -> VM's function dispatches the event to TI
> > agents..." introduces additional level of complexity than if "VM calls
> JIT's
> > function to compile method. VM asks JIT about inlined methods. VM
> dispatches
> > event to TI agents."
>
> Correct me if I am wrong, I see the picture as:
> (1):
> 1.1. VM -call-> JIT (compile a method for me, please)
> 1.2. VM -call-> JIT (gimme the list of addresses/functions)
> 1.3. VM -call-> JIT (please, free your resources allocated for these
> addrs)
>
> (2):
> 2.1. VM -call-> JIT (compile a method for me, please)
> 2.2. JIT -call-> VM (I generated code from addr X to addr Y, look at this
> one)
> 2.3. VM -call-> TI (here is the code for you)
>
> (1) has a disadvantage in case one JIT instance compiles different
> methods in parallel. And we should have a synchronized method addr
> repository, which is not easy to wipe out in the right way.
>
> (2) seems more straightforward from the JIT side because JIT can
> report method boundary addresses as soon as it determines them on
> emitting. That simplifies JIT impl (no allocating/freeng/synch).
>
> BTW, I am curious, is it OK for TI when a method is compiled several
> times and put on different addrs?
>
> > Ideas & suggestions are welcome.
> >
> > Thanks,
> > Eugene.
> >
> > On 10/24/06, Eugene Ostrovsky <eu...@gmail.com> wrote:
> > >
> > > Hi all.
> > >
> > > It seems that we have most of JVMTI implemented in drlvm. Still some
> of
> > > profiling support features is left.
> > > I'm going to take a look on "VM Object Allocation" event.
> > > I'll try to come up with design tomorrow.
> > >
> > > Thanks,
> > > Eugene.
> > >
> > >
>
> --
> Egor Pasko
>
>
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x21D day of Apache Harmony Eugene Ostrovsky wrote:
> Hello All.
>
> One more "hole" in current JVMTI Profiling implementation is Compiled Method
> Load event.
>
> Current VM doesn't report this event for methods that are inlined by JIT.
> Though spec requires it to be sent for every compiled method:
> http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#CompiledMethodLoad
>
> 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.
>
> I'm not sure about which approach is better.
> Each of them requires additional interface function (1.- to JIT from VM; 2.
> - from VM to JIT).
>
> The second approach seems to be more complicated in terms of VM - JIT
> interaction. I mean that the following scheme "VM calls JIT's function to
> compile method. -> JIT's function in it's turn calls VM's function to notify
> about compiled methods. -> VM's function dispatches the event to TI
> agents..." introduces additional level of complexity than if "VM calls JIT's
> function to compile method. VM asks JIT about inlined methods. VM dispatches
> event to TI agents."
Correct me if I am wrong, I see the picture as:
(1):
1.1. VM -call-> JIT (compile a method for me, please)
1.2. VM -call-> JIT (gimme the list of addresses/functions)
1.3. VM -call-> JIT (please, free your resources allocated for these addrs)
(2):
2.1. VM -call-> JIT (compile a method for me, please)
2.2. JIT -call-> VM (I generated code from addr X to addr Y, look at this one)
2.3. VM -call-> TI (here is the code for you)
(1) has a disadvantage in case one JIT instance compiles different
methods in parallel. And we should have a synchronized method addr
repository, which is not easy to wipe out in the right way.
(2) seems more straightforward from the JIT side because JIT can
report method boundary addresses as soon as it determines them on
emitting. That simplifies JIT impl (no allocating/freeng/synch).
BTW, I am curious, is it OK for TI when a method is compiled several
times and put on different addrs?
> Ideas & suggestions are welcome.
>
> Thanks,
> Eugene.
>
> On 10/24/06, Eugene Ostrovsky <eu...@gmail.com> wrote:
> >
> > Hi all.
> >
> > It seems that we have most of JVMTI implemented in drlvm. Still some of
> > profiling support features is left.
> > I'm going to take a look on "VM Object Allocation" event.
> > I'll try to come up with design tomorrow.
> >
> > Thanks,
> > Eugene.
> >
> >
--
Egor Pasko