Here's the reply form engineering:
> Instances of GsStackBuffer are used to store the Smalltalk stack frames
> when a GsProcess is moved out of interpreter stack memory and into object
> memory. So a continuation or other committed GsProcess will reference
> an instance of GsStackBuffer and the GsStackBuffer will probably be
> much larger
> than the instance of GsProcess .I would think an MFC would get rid of
> them if you then allow reclaim to finish
> (SystemRepository markForCollection ; reclaimAll ) .
Dale
On 12/9/15 2:49 PM, Paul DeBruicker via Glass wrote:
> I had a bug in a loop that was saving a continuation to the ObjectLog each
> time it hit to debug it later, and the GsStackBuffers are part of what is
> saved.
>
> Fixing my bug has stopped the accumulation of the instances of the
> GsStackBuffer
>
>
>
> GLASS mailing list wrote
>> Hi -
>>
>> Prior to the full backup and restore I just ran instances of GsStackBuffer
>> occupied 70% of the space in my 3.2.4 repository. After the full backup
>> and restore its not really in the stone to speak of. Searches for it in
>> the sys admin guide and the programming guide come up empty. If I search
>> for references to the class in the stone the list is also empty.
>>
>> What is it used for and how can I get rid of instances of it without going
>> through the full backup & restore repository compaction routine?
>>
>> Thanks
>>
>> Paul
>> _______________________________________________
>> Glass mailing list
>> Glass@.gemtalksystems
>>
http://lists.gemtalksystems.com/mailman/listinfo/glass>
>
>
>
> --
> View this message in context:
http://forum.world.st/GsStackBuffer-tp4866439p4866448.html> Sent from the GLASS mailing list archive at Nabble.com.
> _______________________________________________
> Glass mailing list
>
[hidden email]
>
http://lists.gemtalksystems.com/mailman/listinfo/glass_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Locked
