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

[David Holmes]

Keith McGuigan said the following on 02/02/11 10:26:
> 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.

You are completely missing the point. My reference to vm_ops was for 
their self-linking nature not where they themselves are allocated. 
Likewise where the events themselves are allocated is not relevant 
either - we are not changing that. What I am simply saying is that by 
dynamically allocating QueueNodes on the C-Heap this change introduces a 
new fatal error condition in the VM. If the events can self-link, as 
vm-operations do, then you don't need QueueNodes, you don't need dynamic 
C-Heap allocation and so no new failure mode is introduced.

David