Memory problem

[Denis Kudriashov]

Is it automatic process? I have my image work after test finish duriing one
day (holidays). And memory will not cleanup.

Maybe I should turn on this mechanizm manualy or explicitly perform some
method after my transactions?

2010/10/11 Igor Stasenko <siguctua at gmail.com>

> On 11 October 2010 13:46, Denis Kudriashov <dionisiydk at gmail.com> wrote:
> > Hello.
> >
> > I run some test in pharo1.1 and magma installed from configuration. I
> insert
> > 100000 objects to local Magma db.
> > I use MargaCollection for this.
> >
> > And after test I have grow memory size. Before I have 90 mb. After I have
> > 140 mb.
> >
> > My code for test is:
> >
> > session commit: [entitiesGroup entities add: payment].
> > session stubOut: entitiesGroup.
> > session finalizeOids.
> > Smalltalk garbageCollect
> >
> > entitiesGroup entities is MagmaCollection.
> >
> > During test I see that "payment class allInstances size" don't changed.
> Its
> > ok. I do stub/finalize stuff for this.
> > But memory usage grow. Its bad.
> >
> > At the end of test I watch in MaWeakValueDictionary allInstances. And I
> > found that some instance has 141000 items. And 140000 items is nil.
> > (self select: [:each | each isNil] a MaWeakValueDictionary(size 140064)).
> >
> > This is my problem
> > What I do wrong?
> >
> >
>
> If i remember correctly, there are a mechanism, which should clean it
> up periodically.
> But not too often , to prevent too much processing.
>
> >
> >
> >
> >
> > _______________________________________________
> > Magma mailing list
> > Magma at lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/mailman/listinfo/magma
> >
> >
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
> _______________________________________________
> Magma mailing list
> Magma at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/magma
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/magma/attachments/20101011/fd7d2ef3/attachment.htm