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 :-( ] Regards, Tim
