Request for review, 6766644: Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread"
David Holmes
David.Holmes at oracle.com
Tue Feb 1 16:30:45 PST 2011
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
More information about the serviceability-dev
mailing list