compressing the code cache (was: Self ported to Linux)
Jecel Assumpcao Jr
jecel at merlintec.com
Fri Feb 1 00:08:42 UTC 2002
On Wednesday 30 January 2002 19:09, Ian Woollard wrote:
> I'm not sure how it would pan out, I do know that Self 4.0 on
> a sparc had the option of storing the compiled code cache to
> disk together with the snapshot- I turned it off because the
> file it generated was huge IRC.
Though the warning that comes up ("start up will be slower since no
code was saved") is true, this hasn't been a problem for me except on
really slow machines (Sparcstation 2 or similar).
> Modern disks are faster of course, and MUCH bigger.
Relative to modern processors, however, they have become slower.
> Still, it would be interesting to know if there are any clues
> that the compiler could write to disk that would help it next
> time around; that would also improve performance. Can the code
> cache be compressed in any way?
One source of bloat used to be that every "type"/source method
combination that was called got its own native code version, yet often
the code was identical for different types. I think this was eliminated
from the NIC (I read somewhere that it no longer does "customization")
but would guess that it might still be a problem for the SIC. Just
passing the code cache through gzip when saving to disk should take
care of this, however.
One interesting solution would be to throw out all the code but keep
the PICs. They typically take up only 2% of the space of the compiled
code. I have no idea what the impact of this "warm compilation" would
have on start up performance, but it might be enough to be worth the
More information about the Self-interest