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
