Dear Doron:
_If_ one actually SCANNED the old space, and if final fields dominated
enough to make a performance difference, then perhaps one could save
something (irrespective of details of the memory model). In practice we use
write barriers to avoid scanning. Since the actual assignment to a final
field can be arbitrarily separated from the allocation of the object
containing the field, there is no guarantee (in the general case) that the
object has not been promoted to an older generation. Thus it is hard to
eliminate the write barrier completely, even on final fields -- and the
scanning also cannot be avoided, because there can be a cross-generational
pointer there.
The one thing I have thought might sometimes help is this. If more object
initializations were as in Modula-3, where one tends to compute initial
field values in advance and provide them to an allocator that initializes
the fields right away, then, for a given class, you might be able to show
(via compiler analysis) that some or all fields were always initialized
immediately after allocation, before promotion could occur. Any such
initializing stores can have their write barrier elided -- but in addition,
if a given field were always initialized that way, and were final, then one
might have a static proof that the referent could be no younger than the
object containing the field, and thus avoid scanning.
But if one is using a write barrier based mechanism, and if it is based on
remembering individual fields that are updated (rather than objects or
cards), then most of the savings would be write barriers elided from
initializing stores.
In sum, this is probably more for the GC list than for the memory model
list.
-- EM
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:09 EDT