Do you mean we can't have multiple versions of compiled code for the same method?  I don't think that's true or should be required.  nmethod freeing is very lazy and there's no guarantee that we will have completed unloading of an nmethod before we've created a new variation of it.  It would also be completely ok for a JVM to have multiple versions of the compiled code for a method.  Obviously the load and unload for a particular nmethod must be properly ordered.   
That last sentence is what I meant; load and unload for a specific
compiled version of foo (nmethod) must be in order.

Dan



              which is going to mean coordination between the mechanisms for posting of both CompiledMethodLoad and CompiledMethodUnload events.         ">

(original) (raw)

On 1/26/2011 2:52 PM, Tom Rodriguez wrote: 
On Jan 26, 2011, at 1:39 PM, Daniel D. Daugherty wrote:  
 
It also looks like there must be order between the load and unload events:


 CompiledMethodLoad for foo
 CompiledMethodUnload for foo
 CompiledMethodLoad for foo (again)
 



Do you mean we can't have multiple versions of compiled code for the same method? I don't think that's true or should be required. nmethod freeing is very lazy and there's no guarantee that we will have completed unloading of an nmethod before we've created a new variation of it. It would also be completely ok for a JVM to have multiple versions of the compiled code for a method. Obviously the load and unload for a particular nmethod must be properly ordered.


That last sentence is what I meant; load and unload for a specific
compiled version of foo (nmethod) must be in order.

Dan



  
 
which is going to mean coordination between the mechanisms for posting  
of both CompiledMethodLoad and CompiledMethodUnload events.