Request for review, 6766644: Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread"

[Keith McGuigan]

On Feb 1, 2011, at 6:38 PM, David Holmes wrote:
> The point is to avoid the need to dynamically allocate the  
> QueueNodes. If the elements to be queued are self-linking then you  
> don't need the extra wrapper objects. Take a look at VM_Operations  
> as an example of self-linking objects.
>
> It also makes it easy to return a list of events for batch  
> processing, if you chose - ala VM_Operations again.

VM_Operations are allocated on the caller's stack and the caller waits  
and thus his frame exists for the duration of the operation.  We can't  
do that in this situation since the caller of enqueue() does not wait  
for the event to be dequeued or posted before continuing, thus the  
caller's frame may be popped and/or reused before the event is picked  
up by the other (service) thread.  So the event needs to live outside  
of the caller's stack (the caller of enqueue()).  The only reasonable  
place for it to go is into the C-heap.  It doesn't matter where the  
'next' link lives (internal to or external to JvmtiDeferredEvent), we  
still going to need to dynamically allocate C-heap memory to store the  
event.

--
- Keith