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
