Avoiding saving the Display bitmap in snapshots [Was Re: [squeak-dev] Too much MC stuff left in image]

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Avoiding saving the Display bitmap in snapshots [Was Re: [squeak-dev] Too much MC stuff left in image]

Eliot Miranda-2


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.
 
tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
There are two ways to write error-free programs; only the third one works.
--
best,
Eliot


Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] Avoiding saving the Display bitmap in snapshots [Was Re: [squeak-dev] Too much MC stuff left in image]

Bert Freudenberg

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.

- Bert -






smime.p7s (5K) Download Attachment