[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
|