Re: [drlvm][jvmti] Profiling support - Compiled Method Load event

[Egor Pasko]

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 <[EMAIL PROTECTED]> 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 al

Re: [drlvm][jvmti] Profiling support - Compiled Method Load event

[Eugene Ostrovsky]

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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 resourc

Re: [drlvm][jvmti] Profiling support - Compiled Method Load event

[George Timoshenko]

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

* .





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

[Egor Pasko]

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 <[EMAIL PROTECTED]> 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?
> >

Re: [drlvm][jvmti] Profiling support - Compiled Method Load event

[Eugene Ostrovsky]

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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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

[Egor Pasko]

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 <[EMAIL PROTECTED]> 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

[Eugene Ostrovsky]

Opended issue  *HARMONY-2145
* .


On 11/10/06, Eugene Ostrovsky <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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

[Eugene Ostrovsky]

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 <[EMAIL PROTECTED]> 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.