RFR: 8189088: Add intrusive doubly-linked list utility

[David Holmes]

Hi Kim,

I get the gist of this but am not going to pretend I can follow all the 
details. :)

So what actually gets expanded into the target type to support this. Is 
it just a next/prev pointer or is there additional infrastructure needed?

Thanks,
David

On 10/10/2017 6:29 PM, Kim Barrett wrote:
> RFR: 8189088: Add intrusive doubly-linked list utility
> 
> Please review this new facility, providing a general mechanism for
> intrusive doubly-linked lists. A class supports inclusion in a list by
> having an IntrusiveListLink member, and providing structured
> information about how to access that member. A class supports
> inclusion in multiple lists by having multiple IntrusiveListLink
> members, with different lists specified to use different members.
> 
> The IntrusiveList class template provides the list management. It is
> modelled on bidirectional containers such as std::list and
> boost::intrusive::list, providing many of the expected member types
> and functions. (Note that the member types use the Standard's naming
> conventions.) (Not all standard container requirements are met; some
> operations are not presently supported because they haven't been
> needed yet.) This includes iteration support using (mostly)
> standard-conforming iterator types (they are presently missing
> iterator_category member types, pending being able to include
> <iterator> so we can use std::bidirectional_iterator_tag).
> 
> This change only provides the new facility, and doesn't include any
> uses of it, though there is a suite of unit tests for it. I've
> extracted it from some in-progress work, as a useful tool in it's own
> right.
> 
> I've converted a couple existing list implementations to use
> IntrusiveList, and will be submitting those changes once this
> infrastructure is in place. One place I haven't yet touched that I
> think will benefit is G1's region handling. There are various places
> where G1 iterates over all regions in order to do something with those
> which satisfy some property (humongous regions, regions in the
> collection set, &etc). If it were trivial to create new region
> sublists (and this facility makes that easy), some of these could be
> turned into direct iteration over only the regions of interest.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8189088
> 
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8189088
> 
> Testing:
> JPRT to build and run unit tests on supported platforms.
> 
>