Avoiding saving the Display bitmap in snapshots [Was Re: [squeak-dev] Too much MC stuff left in image]
On Fri, Nov 14, 2014 at 10:58 AM, tim Rowledge <[hidden email]> wrote:
On 14-11-2014, at 10:44 AM, tim Rowledge <[hidden email]> wrote:
>
> I wonder where 10Mb of Bitmaps is being used…
Well, duh, a 1700@1300 Display will do that, mostly. When did screens get so frakkin huge? Why, when I was a lad we had 640@400 monochrome and liked it!
It would be cool if Spur could some how handle not saving the display bitmap to the snapshot, given that it'll be repainted anyway. But I want to avoid that old Smalltalk-80 behaviour of the screen visibly shrinking when the tracer is run. Let me throw this out as whitewash. Spur has a segmented memory and can and does avoid writing empty segments (segments that only contain free space) and trailing free space in segments. So if the Display bitmap were in a segment on its won (likely if it is reallocated on every snapshot launch) then with a little bit of finagling it might be simple to avoid writing it to the snapshot. There are obviously tricky details here such as what object it actually writes to the snapshot file. Anyway, something to think about when producing deployment images for the cloud.
Re: [Vm-dev] Avoiding saving the Display bitmap in snapshots [Was Re: [squeak-dev] Too much MC stuff left in image]
On 14.11.2014, at 20:14, Eliot Miranda <[hidden email]> wrote:
On Fri, Nov 14, 2014 at 10:58 AM, tim Rowledge <[hidden email]> wrote:
On 14-11-2014, at 10:44 AM, tim Rowledge <[hidden email]> wrote:
>
> I wonder where 10Mb of Bitmaps is being used…
Well, duh, a 1700@1300 Display will do that, mostly. When did screens get so frakkin huge? Why, when I was a lad we had 640@400 monochrome and liked it!
It would be cool if Spur could some how handle not saving the display bitmap to the snapshot, given that it'll be repainted anyway. But I want to avoid that old Smalltalk-80 behaviour of the screen visibly shrinking when the tracer is run. Let me throw this out as whitewash. Spur has a segmented memory and can and does avoid writing empty segments (segments that only contain free space) and trailing free space in segments. So if the Display bitmap were in a segment on its won (likely if it is reallocated on every snapshot launch) then with a little bit of finagling it might be simple to avoid writing it to the snapshot. There are obviously tricky details here such as what object it actually writes to the snapshot file. Anyway, something to think about when producing deployment images for the cloud.
Why would the VM have to worry about this? The image should release the display bitmap (just the bits, not the form) and allocate it again right after the snapshot.