Java Performance Tuning
By Jack Shirazi

Unconfirmed error reports are from readers. They have not yet been 
approved or disproved by the author or editor and represent solely
the opinion of the reader.


This page was updated June 18, 2002 


Here's a key to the markup:

        [page-number]: serious technical mistake
        {page-number}: minor technical mistake
        <page-number>: important language/formatting problem
        (page-number): language change or minor formatting problem
        ?page-number?: reader question or request for clarification


UNCONFIRMED errors and suggestions from readers:


[109]  "Reference Objects" box;
The changes you made to the softref/weakref discussion in the 1/01 reprint only partially fix the error here.  Lines 3-4 are now co
rrect in the reprint -- Weak refs are cleared before SoftRefs. 

However, lines 8-9 are now wrong, and the following rationale (which wasn't changed) is also incorrect.

Weak refs are intended for canonical mappings, and Soft refs are intended for memory sensitive caches, as stated in the first print
ing.

The actual behaviour is that weak refs are cleared as soon as there are no outstanding strong refs to the referent, while soft refs
 can stick around as long as the VM can afford to let them -- they are only guaranteed to be cleared when failing to do so would ca
use an OutOfMemoryError.

This means that WeakRefs are useful for canonical mappings, because they'll be valid as long as the referent is referred to elsewhe
re in the heap, but will clear (and thus let you free whatever other objects you were using the canonical mapping to refer to) as s
oon as no other strong refs are outstanding.  Soft refs are useful for caches, since they'll stick around as long as the VM doesn't
 have a more urgent need for the memory space they're occupying, but will clear as soon as the space is needed to avoid an OOMError

[276]  last line;
Author claims that variables that are atomically assigned are then thread-safe. This
is inaccurate. True, the variable will not risk a corrupt assigment due to being
operated on simultaneously by two threads but due to issues of visiblity w.r.t the
Java Memory Model one thread will not necessarily immediately see changes made by
another (to its own working copy of the variable). The variable could be stale and
thus two threads in the same process can be working as if the variable was set to two
separate values. That's not thread-safe.