harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject [classlib][luni] Provide a lock-free version of ReferenceQueue (HARMONY-6344)
Date Wed, 04 Nov 2009 16:12:31 GMT
On 04/Nov/2009 03:30, James Gan (JIRA) wrote:
> James Gan updated HARMONY-6344:
> -------------------------------
>     Attachment: amino_rfq.zip
> In this new version, two reference queues are provides:
> 1. ReferenceQueueNodeWrapper
>     Occupied more memory, better scalability
> 2. ReferenceQueueNoNodeWrapper
>     Occupied less memory, moderate scalability

Thanks for the update James.

As a general comment, while I appreciate the work and breadth of your
contribution, it would be easier to follow as explicit patches against
the current Harmony code, so I can see exactly what you are proposing we
change.  That said, there is clearly some interesting work in here so
I'm looking at it and thinking about how it could be used in Harmony.

I suggest that we maintain a single implementation of Reference and
ReferenceQueue for Harmony.  So let's decide early whether the Node
wrapper version, or non-Node wrapper version is the right direction to go.

Am I right to say that the Node wrapper is there to allow removal of the
'next' field from the Reference?  It seems to move the volatile field
out to the ReferenceQueue$Node type, so it is unclear to me how that
helps with the scalability overall.  Can you please explain?

As you point out, the Node wrapper version will use more memory since it
has a Node for each enqueued Reference.  It would be good to know some
stats on how References come and go from the queue in a typical
application (rather than microbenchmarks).

Good to see that the remove() goes to sleep when the queue is empty now!

[ I've not thought about it enough yet, but it seems a shame that the
enqueue call has to synchronize on the entire ReferenceQueue in order to
update the tail :-(


View raw message