On Apr 27, 2013, at 8:01 PM, Nicolas Cellier
<nicolas.cellier.aka.n...@gmail.com> wrote:
> Right, if you embed source along with CompiledMethod (to handle the case when
> the CompiledMethod has been replaced but one of its block of code is still
> used), then you don't need Decompiler in the first place.
>
> Nonetheless, I would remove the .sources but not the .changes. The .changes
> is not only a source code repository (that feature can go away if you want),
> it's before all a change log, an insurance to retrieve some change when
> everything else failed (image crashed or worse corrupted image won't
> restart). You can make the insurance optional if you want, but please
> continue to provide an equivalent service. A change file is the most simple
> thing that could possibly work IMO. But this is another thread.
>
Yes, we have a solution for that…
the thing is that the .changes has 3 roles. In the 1978, it was very clever to
design one extremely memory efficient mechanism to kill all three:
1) keep a history of all the accepted method sources in the image (see
"versions")
2) store the code on disk efficiently with no duplications (They counted those
extremely expensive disks in the one-diget Megabytes back then).
3) have transaction log for the source code in case of image crash.
Now today, we can solve all three using three different methods:
1) we will just keep the accepted methods in memory until you commit to
monticello/git
(in case of git one can even commit all the intermediates, for MC one
would just commit the latest).
after the in-image history is pruned (like it is now eventually anyway
when you start with a fresh image).
2) We don't need to store the *current* version on disk. Compressed in memory.
Yes, that is what progress brings…
3) Disk space is so cheap it is not even funny.
-> we will just have a dedicated log. And we can even store Objects…
And then we can leverage the extreme simplicity of the resulting scheme..
simplicity is an amazing thing. (Or the
contrary: I think people understate the effects of complexity).
Marcus
