[squeak-dev] Serious garbage/storage leak issue with MCInfoProxy

Bob Arning arning315 at comcast.net
Tue Feb 20 16:59:00 UTC 2018


If...

- SystemWindows are holding lots of drop shadows

- the shadow is only shown for the frontmost window

- recreating the shadow only takes around 20ms

Then SystemWindow>>#passivate seems like a nice place to keep things 
tidy. Works fine for me.


On 2/20/18 11:21 AM, Marcel Taeumel wrote:
> Hi Eliot,
>
> okay. I added the clean-up to project switching and save-and/or-quit. 
> All changes are in MorphicProject. See Morphic-mt.1397.
>
> Best,
> Marcel
>
>> Am 20.02.2018 14:14:01 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
>>
>> Hi Marcel,
>>
>>
>> On Feb 20, 2018, at 5:00 AM, Marcel Taeumel <marcel.taeumel at hpi.de 
>> <mailto:marcel.taeumel at hpi.de>> wrote:
>>
>>> Hmm... I do not see value in cleaning up projects (to free memory) 
>>> when the user just switches between them back and forth. Especially 
>>> in the light of worlds-in-worlds or background projects, this seems 
>>> like an unreasonable path to follow. We should not make too much 
>>> assumptions about application code or user needs at this point. 
>>> There could always be a "Oh, please render that background project 
>>> into this file. Oh, why is it so slow at the moment..."
>>
>> Well one might want to make the drop shadow caches responsive to some 
>> overall memory budget because, as I've observed, the overhead of the 
>> drop shadows can be many megabytes.  I saw an overhead that 
>> approached 1Gb!!
>>
>>> Cleaning up resources for save-and-quit, however, seems reasonable 
>>> because it is at the environment's boundary and not some arbitrary 
>>> in-image boundary.
>>>
>>> Best,
>>> Marcel
>>>>
>>>> Am 20.02.2018 13:58:38 schrieb David T. Lewis <lewis at mail.msen.com 
>>>> <mailto:lewis at mail.msen.com>>:
>>>>
>>>> This might also justify adding one new method to Project:
>>>>
>>>> Project>>cleanUpForExit
>>>>
>>>> Default implementation would be do nothing, and for MorphicProject it
>>>> would clean up the drop morphs. This would be called from 
>>>> #finalExitActions:
>>>> for ongoing cleanup, and when saving the image you would do this:
>>>>
>>>> Project current cleanupForExit
>>>>
>>>> Dave
>>>>
>>>>
>>>> On Tue, Feb 20, 2018 at 07:50:57AM -0500, David T. Lewis wrote:
>>>> > To handle all of the morphic projects, it would be better to do the
>>>> > cleanup when exiting the projects:
>>>> >
>>>> > MorphicProject>>finalExitActions: enteringProject
>>>> > world allMorphsDo: [:ea | ea removeProperty: #dropShadow].
>>>> > ...
>>>> >
>>>> > That will leave only the current project to worry about when saving
>>>> > the image. Of course, you do not want to to cleam up the morphs if
>>>> > the current world is a ControlManager, so it might look something
>>>> > like this:
>>>> >
>>>> > | world |
>>>> > (world := Project current world) isMorph
>>>> > ifTrue: [world allMorphsDo: [:ea | ea removeProperty: #dropShadow]]
>>>> >
>>>> > Dave
>>>> >
>>>> > On Tue, Feb 20, 2018 at 11:26:19AM +0100, Marcel Taeumel wrote:
>>>> > > We have to consider all open projects:
>>>> > >
>>>> > > Project allMorphicProjects do: [:project |
>>>> > > ?? ??project world allMorphsDo: [:morph |
>>>> > > ?? ?? ?? morph removeProperty: #dropShadow]].
>>>> > >
>>>> > > Yet, there can be hidden morphs. If we want to ignore those, we 
>>>> can stick with only cleaning up top-level morphs, which are usually 
>>>> the system windows:
>>>> > >
>>>> > > Project allMorphicProjects do: [:project |
>>>> > > ?? ??project world submorphsDo: [:morph |
>>>> > > ?? ?? ?? morph removeProperty: #dropShadow]].
>>>> > >
>>>> > > Best,
>>>> > > Marcel
>>>> > > Am 20.02.2018 10:57:08 schrieb Bob Arning :
>>>> > > Probably good enough might be
>>>> > > World allMorphsDo: [:ea | ea removeProperty: #dropShadow]
>>>> > > takes 0 ms for me
>>>> > >
>>>> > >
>>>> > > On 2/20/18 2:46 AM, Marcel Taeumel wrote:
>>>> > >
>>>> > > Hi Eliot,
>>>> > >
>>>> > > sure. Removing the potential drop shadow of all kinds of morphs 
>>>> takes time:
>>>> > >
>>>> > > Morph allSubInstancesDo: [:ea |??ea removeProperty: #dropShadow].
>>>> > >
>>>> > > About 3 seconds here in a quite clean image.
>>>> > >
>>>> > > SystemWindow allSubInstancesDo: [:ea |??ea removeProperty: 
>>>> #dropShadow].
>>>> > >
>>>> > > Works at 100 milliseconds.
>>>> > >
>>>> > > What has the biggest effect in your image?
>>>> > >
>>>> > > Best,
>>>> > > Marcel
>>>> > > Am 20.02.2018 02:51:06 schrieb Eliot Miranda 
>>>> [mailto:eliot.miranda at gmail.com]:
>>>> > > Hi Marcel,
>>>> > >
>>>> > > ?? ?? I've finally worked out that the space overhead here 
>>>> comes from the dropShadow cache system in Morphs (in 
>>>> otherProperties in MorphExtensions).?? Would it be possible to 
>>>> arrange to flush all drop shadows in the current project when:
>>>> > > - exiting a project
>>>> > > - snapshotting
>>>> > > ?
>>>> > >
>>>> > > On Thu, Jan 18, 2018 at 3:24 PM, Eliot Miranda wrote:
>>>> > >
>>>> > > Hi All,
>>>> > >
>>>> > > ?? ?? I've been experiencing image save slowdowns recently and 
>>>> finally my work image reached 1.%Gb and I thought I better take a look:
>>>> > >
>>>> > > Sisyphus.Cog$ ls -lh SpurWork64.* save/SpurWork64-*
>>>> > > -rw-r--r--@ 1 eliot ??staff ?? ??28M Jan 18 12:47 
>>>> SpurWork64.changes
>>>> > > -rw-r--r--@ 1 eliot ??staff ?? 1.6G Jan 18 12:48 SpurWork64.image
>>>> > > -rw-r--r--@ 1 eliot ??staff ?? ??28M Jan 18 12:03 
>>>> save/SpurWork64-2018-01-18.changes
>>>> > > -rw-r--r--@ 1 eliot ??staff ?? 1.5G Jan 18 12:03 
>>>> save/SpurWork64-2018-01-18.image
>>>> > >
>>>> > > I ran a space analysis and found that Bitmap and ByteArray were 
>>>> the top two, so I looked for large Bitmaps.?? I found three that 
>>>> fit this criterion:
>>>> > >
>>>> > >
>>>> > > ?? ?? Bitmap allInstances select: [:bm| bm size >= 1000000 and: 
>>>> [bm ~~ Display bits]]
>>>> > >
>>>> > > I inspected the three and did a chase pointers on one of 
>>>> them.?? As I did that suddenly
>>>> > > a) the inspector on the Array became empty (still an array but 
>>>> zero elements)
>>>> > > b) the progress bar for Downloading FlexibleVocabularies-who.NN 
>>>> appeared
>>>> > >
>>>> > > I interrupted this and did a very cursory stack examination. 
>>>> Some object had not understood isLiteral and from there what looked 
>>>> like an attempt to turn this stub into a real object caused 
>>>> FlexibleVocabularies-who.NN to start to download.
>>>> > >
>>>> > > I threw away the debugger, ran the GC and suddenly all my free 
>>>> space was back.?? So now on disc I have
>>>> > >
>>>> > > Sisyphus.Cog$ ls -lh SpurWork64.* save/SpurWork64-*
>>>> > > -rw-r--r--@ 1 eliot ??staff ?? ??28M Jan 18 15:17 
>>>> SpurWork64.changes
>>>> > > -rw-r--r--@ 1 eliot ??staff ?? ??57M Jan 18 15:17 SpurWork64.image
>>>> > > -rw-r--r--@ 1 eliot ??staff ?? ??28M Jan 18 12:03 
>>>> save/SpurWork64-2018-01-18.changes
>>>> > > -rw-r--r--@ 1 eliot ??staff ?? 1.5G Jan 18 12:03 
>>>> save/SpurWork64-2018-01-18.image
>>>> > >
>>>> > > What is going on here??? There seems to be a very bad storage 
>>>> leak.?? Can we please discuss this??? This doesn't seem like 
>>>> healthy behaviour at all :-)
>>>> > >
>>>> > > _,,,^..^,,,_
>>>> > >
>>>> > > best,??Eliot
>>>> > >
>>>> > >
>>>> > >
>>>> > > --
>>>> > >
>>>> > > _,,,^..^,,,_
>>>> > >
>>>> > > best,??Eliot
>>>> > >
>>>> > >
>>>> >
>>>> > >
>>>> >
>>>> >
>>>>
>>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180220/063ca945/attachment.html>


More information about the Squeak-dev mailing list