compressing the code cache (was: Self ported to Linux)

[Jecel Assumpcao Jr]

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 
trouble.

-- Jecel