On 05/12/2011 05:24 PM, Holger Hans Peter Freyther wrote:
How many read-only objects do we have in a bootstrapped image? In a
typical
iliad application? Does it make sense to optimize for it? or will RO
handling
just become more easy and this is a cleanup?
I think the point is to optimize _non_ read-only objects at the cost of
making tenuring read-only objects a bit more expensive (you will have to
unprotect the page, allocate, copy, protect the page). We also win
read-only access to fixed instance variables, which GNU Smalltalk
doesn't have (only indexed instance variables are protected).
BTW, for the same reason I think that moving objects to read-only space
directly when you make them read-only (like you did for fixedspace) is a
good idea. Anyway, read-only objects are mostly literals so they are
long-living. Gwen, can you reorganize the patch along these lines?
The patch making readonly space, well, readonly should be a separate
one. For unprotection/protection around allocation you can add hooks to
alloc.c heaps, like we have after_allocating: that would be
before_freeing, after_freeing, before_allocating.
Paolo