My apologies to Keith, I was completely missing the fact that the
QueueNode class has to hold a copy of the event object due to the
limited lifetime of the event objects themselves.
Sorry.
David
David Holmes said the following on 02/02/11 10:30:
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
