[concurrency-interest] Reference Collections

Peter Firmstone peter.firmstone at zeus.net.au
Thu Jan 5 00:08:33 EST 2012


I think there's a case for sharing a ReferenceQueue and cleanup thread
between collections too, as Nathan suggested, to economise on memory and
avoid creating too many threads.

The ReferenceQueuingFactory is an interface for encapsulating the
functionality, it'll take some refactoring to add option 2 below.

Providing users with three choices:

     1. Making calling threads responsible for reference removal, for
        minimal number of threads / load.
     2. Sharing a ReferenceQueuingFactory among collections.
     3. One ReferenceQueuingFactory per collection.

There is just one catch, to share a ReferenceQueuingFactory, the
referents must be of the same type.

Option 2, also exposes some more of the internal api, in order to share
a thread and queue, the ReferenceQueuingFactory would need to be passed
in at construction, in addition, the Reference would need to contain a
copy of the collection it will be removed from.

Alternatively how reliable (depending on the platform) is it to minimise
the stack size of of the garbage collection thread, say to 128k reducing
memory consumption?  The javadoc says it can be ignored completely.

Using the following Thread constructor option (copied from javadoc):

Thread
public Thread(ThreadGroup group,
              Runnable target,
              String name,
              long stackSize)
Allocates a new Thread object so that it has target as its run object,
has the specified name as its name, belongs to the thread group referred
to by group, and has the specified stack size.
This constructor is identical to Thread(ThreadGroup,Runnable,String)
with the exception of the fact that it allows the thread stack size to
be specified. The stack size is the approximate number of bytes of
address space that the virtual machine is to allocate for this thread's
stack. The effect of the stackSize parameter, if any, is highly platform
dependent.
On some platforms, specifying a higher value for the stackSize parameter
may allow a thread to achieve greater recursion depth before throwing a
StackOverflowError. Similarly, specifying a lower value may allow a
greater number of threads to exist concurrently without throwing an
OutOfMemoryError (or other internal error). The details of the
relationship between the value of the stackSize parameter and the
maximum recursion depth and concurrency level are platform-dependent. On
some platforms, the value of the stackSize parameter may have no effect
whatsoever.
The virtual machine is free to treat the stackSize parameter as a
suggestion. If the specified value is unreasonably low for the platform,
the virtual machine may instead use some platform-specific minimum
value; if the specified value is unreasonably high, the virtual machine
may instead use some platform-specific maximum. Likewise, the virtual
machine is free to round the specified value up or down as it sees fit
(or to ignore it completely).
Specifying a value of zero for the stackSize parameter will cause this
constructor to behave exactly like the Thread(ThreadGroup, Runnable,
String) constructor.
Due to the platform-dependent nature of the behavior of this
constructor, extreme care should be exercised in its use. The thread
stack size necessary to perform a given computation will likely vary
from one JRE implementation to another. In light of this variation,
careful tuning of the stack size parameter may be required, and the
tuning may need to be repeated for each JRE implementation on which an
application is to run.
Implementation note: Java platform implementers are encouraged to
document their implementation's behavior with respect to the stackSize
parameter.




More information about the Concurrency-interest mailing list