VW 7.7.1 Memory Policy and Shrinking Memory Usage

> The accumulation pattern sounds similar to delays that had been observed
> in exchanging tombstones for weakly referenced objects. This had been
> found to be faster than a full GC and still effective:
>
> ObjectMemory quickGC
>
> We work around the problem by using this in "refresh" application code
> to trigger a release of objects just before making a trip to GS/S.
>
> Paul Baumann
>
> *From:*[hidden email] [mailto:[hidden email]] *On
> Behalf Of *Alan Knight
> *Sent:* Tuesday, November 09, 2010 19:08
> *To:* Andres Valloud; [hidden email]
> *Subject:* Re: [vwnc] VW 7.7.1 Memory Policy and Shrinking Memory Usage
> *Importance:* Low
>
> While I don't profess to deep understanding of what the memory policies
> are doing, when I've got images that were using a lot of memory and are
> no longer doing so, doing a full garbage collect from the launcher has
> invariable released most of it. Mostly in my case that's things like
> replications with some instrumentation that accumulates a lot of stuff,
> and then eventually getting rid of it. So I would think that the brute
> force mechanism would simply be to force a garbage collect when you know
> or suspect that you've finished with a lot of data and would like to
> shrink memory. For some applications you don't really want to be growing
> and shrinking repeatedly, but that all depends on your patterns of usage.
>
> At 05:40 PM 2010-11-09, Andres Valloud wrote:
>
> Hello,
>
> On 11/8/2010 1:32 AM, Runar Jordahl wrote:
>  > The base (commercial) VisualWorks 7.7.1 image has
>  > LargeGrainMemoryPolicy as its default memory policy. If you allocate a
>  > large amount of memory, let’s say 300 MB, and then drop the referenced
>  > objects, the memory allocated from the operating system does not drop.
>
> Keep in mind that this can also happen with the previous memory policy,
> so these assertions require special attention. Nothing guarantees that
> the compacting GC will compact objects in a way that leads to e.g.:
> large segments being empty. If a segment is not empty, then the VM will
> refuse to deallocate it.
>
>  > Even when the image is left unused for a long time, the allocation
>  > stays. Running additional allocations, which consumes less memory than
>  > the first allocation, does not free any memory allocated from the
>  > operating system. Evaluating garbage collect frees up the used memory.
>
> Right, but you do not which objects will go where after a GC.
>
>  > I wonder how I can tune the memory policy to more agressivly free OS
>  > memory when it is idle, and when it is allocating new objects. I
>  > looked at #idleLoopGCJustified (sat that to always answer true) and
>  > #favorGrowthOverReclamation (it answers false), but with no luck.
>
> You need to look at the free memory upper bound. Also, look at the
> release notes and, in the documentation, the file
> doc/TechNotes/vwMemoryMgmt.pdf. In particular, the technote has been
> essentially rewritten in 7.7.1, and contains much more information than
> the technotes previously released.
>
>  > I also have 7.7.1 images where the “Used memory” in the Memory Monitor
>  > answers 55 MB, while privates bytes allocated from Windows is over 500
>  > MB.
>
> That figure includes a number of things that are not necessarily old
> space, so you have to pay attention to that.
>
>  > Doing a garbage collect does not free any OS memory. I will
>  > address these problems later.
>
> Ok, but note I do not think there may be anything to address... look at
> the documentation and the free memory upper bound. Also, keep in mind
> that if you set the free memory upper bound to small values, then real
> applications can get into a cycle of
>
> try to allocate objects
> no space, and in the reclamation regime
> ok, GC
> still no space, grow memory
> work a little bit, some objects become garbage
> a subsequent GC cleans out garbage, and releases memory
> try to allocate objects
> no space, and in the reclamation regime
> ok, GC
> still no space, grow memory
> work a little bit, some objects become garbage
> a subsequent GC cleans out garbage, and releases memory
> try to allocate objects
> no space, and in the reclamation regime
> ok, GC
> etc...
>
> All that GC can be very painful! This is one of the possible
> performance pitfalls documented by the documentation, and by the memory
> policy tests. Did you look at the test / stress tests / tuner parcels?
>
> Andres.
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
> --
>
> Alan Knight [|], Engineering Manager, Cincom Smalltalk
>
> [hidden email]
>
> [hidden email]
>
> http://www.cincom.com/smalltalk
>
>
> ------------------------------------------------------------------------
> This message may contain confidential information and is intended for
> specific recipients unless explicitly noted otherwise. If you have
> reason to believe you are not an intended recipient of this message,
> please delete it and notify the sender. This message may not represent
> the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or
> affiliates, and does not constitute a contract or guarantee. Unencrypted
> electronic mail is not secure and the recipient of this message is
> expected to provide safeguards from viruses and pursue alternate means
> of communication where privacy or a binding message is desired.

> The accumulation pattern sounds similar to delays that had been observed
> in exchanging tombstones for weakly referenced objects. This had been
> found to be faster than a full GC and still effective:
>
> ObjectMemory quickGC
>
> We work around the problem by using this in "refresh" application code
> to trigger a release of objects just before making a trip to GS/S.
>
> Paul Baumann
>
> *From:*[hidden email] [mailto:[hidden email]] *On
> Behalf Of *Alan Knight
> *Sent:* Tuesday, November 09, 2010 19:08
> *To:* Andres Valloud; [hidden email]
> *Subject:* Re: [vwnc] VW 7.7.1 Memory Policy and Shrinking Memory Usage
> *Importance:* Low
>
> While I don't profess to deep understanding of what the memory policies
> are doing, when I've got images that were using a lot of memory and are
> no longer doing so, doing a full garbage collect from the launcher has
> invariable released most of it. Mostly in my case that's things like
> replications with some instrumentation that accumulates a lot of stuff,
> and then eventually getting rid of it. So I would think that the brute
> force mechanism would simply be to force a garbage collect when you know
> or suspect that you've finished with a lot of data and would like to
> shrink memory. For some applications you don't really want to be growing
> and shrinking repeatedly, but that all depends on your patterns of usage.
>
> At 05:40 PM 2010-11-09, Andres Valloud wrote:
>
> Hello,
>
> On 11/8/2010 1:32 AM, Runar Jordahl wrote:
>  > The base (commercial) VisualWorks 7.7.1 image has
>  > LargeGrainMemoryPolicy as its default memory policy. If you allocate a
>  > large amount of memory, let's say 300 MB, and then drop the referenced
>  > objects, the memory allocated from the operating system does not drop.
>
> Keep in mind that this can also happen with the previous memory policy,
> so these assertions require special attention. Nothing guarantees that
> the compacting GC will compact objects in a way that leads to e.g.:
> large segments being empty. If a segment is not empty, then the VM will
> refuse to deallocate it.
>
>  > Even when the image is left unused for a long time, the allocation
>  > stays. Running additional allocations, which consumes less memory than
>  > the first allocation, does not free any memory allocated from the
>  > operating system. Evaluating garbage collect frees up the used memory.
>
> Right, but you do not which objects will go where after a GC.
>
>  > I wonder how I can tune the memory policy to more agressivly free OS
>  > memory when it is idle, and when it is allocating new objects. I
>  > looked at #idleLoopGCJustified (sat that to always answer true) and
>  > #favorGrowthOverReclamation (it answers false), but with no luck.
>
> You need to look at the free memory upper bound. Also, look at the
> release notes and, in the documentation, the file
> doc/TechNotes/vwMemoryMgmt.pdf. In particular, the technote has been
> essentially rewritten in 7.7.1, and contains much more information than
> the technotes previously released.
>
>  > I also have 7.7.1 images where the "Used memory" in the Memory Monitor
>  > answers 55 MB, while privates bytes allocated from Windows is over 500
>  > MB.
>
> That figure includes a number of things that are not necessarily old
> space, so you have to pay attention to that.
>
>  > Doing a garbage collect does not free any OS memory. I will
>  > address these problems later.
>
> Ok, but note I do not think there may be anything to address... look at
> the documentation and the free memory upper bound. Also, keep in mind
> that if you set the free memory upper bound to small values, then real
> applications can get into a cycle of
>
> try to allocate objects
> no space, and in the reclamation regime
> ok, GC
> still no space, grow memory
> work a little bit, some objects become garbage
> a subsequent GC cleans out garbage, and releases memory
> try to allocate objects
> no space, and in the reclamation regime
> ok, GC
> still no space, grow memory
> work a little bit, some objects become garbage
> a subsequent GC cleans out garbage, and releases memory
> try to allocate objects
> no space, and in the reclamation regime
> ok, GC
> etc...
>
> All that GC can be very painful! This is one of the possible
> performance pitfalls documented by the documentation, and by the memory
> policy tests. Did you look at the test / stress tests / tuner parcels?
>
> Andres.
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
> --
>
> Alan Knight [|], Engineering Manager, Cincom Smalltalk
>
> [hidden email]
>
> [hidden email]
>
> http://www.cincom.com/smalltalk
>
>
> ------------------------------------------------------------------------
> This message may contain confidential information and is intended for
> specific recipients unless explicitly noted otherwise. If you have
> reason to believe you are not an intended recipient of this message,
> please delete it and notify the sender. This message may not represent
> the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or
> affiliates, and does not constitute a contract or guarantee. Unencrypted
> electronic mail is not secure and the recipient of this message is
> expected to provide safeguards from viruses and pursue alternate means
> of communication where privacy or a binding message is desired.

> The accumulation pattern sounds similar to delays that had been observed
> in exchanging tombstones for weakly referenced objects. This had been
> found to be faster than a full GC and still effective:
>
> ObjectMemory quickGC
>
> We work around the problem by using this in "refresh" application code
> to trigger a release of objects just before making a trip to GS/S.
>
> Paul Baumann
>
> *From:*[hidden email] [mailto:[hidden email]] *On
> Behalf Of *Alan Knight
> *Sent:* Tuesday, November 09, 2010 19:08
> *To:* Andres Valloud; [hidden email]
> *Subject:* Re: [vwnc] VW 7.7.1 Memory Policy and Shrinking Memory Usage
> *Importance:* Low
>
> While I don't profess to deep understanding of what the memory policies
> are doing, when I've got images that were using a lot of memory and are
> no longer doing so, doing a full garbage collect from the launcher has
> invariable released most of it. Mostly in my case that's things like
> replications with some instrumentation that accumulates a lot of stuff,
> and then eventually getting rid of it. So I would think that the brute
> force mechanism would simply be to force a garbage collect when you know
> or suspect that you've finished with a lot of data and would like to
> shrink memory. For some applications you don't really want to be growing
> and shrinking repeatedly, but that all depends on your patterns of usage.
>
> At 05:40 PM 2010-11-09, Andres Valloud wrote:
>
> Hello,
>
> On 11/8/2010 1:32 AM, Runar Jordahl wrote:
>  > The base (commercial) VisualWorks 7.7.1 image has
>  > LargeGrainMemoryPolicy as its default memory policy. If you allocate a
>  > large amount of memory, let’s say 300 MB, and then drop the referenced
>  > objects, the memory allocated from the operating system does not drop.
>
> Keep in mind that this can also happen with the previous memory policy,
> so these assertions require special attention. Nothing guarantees that
> the compacting GC will compact objects in a way that leads to e.g.:
> large segments being empty. If a segment is not empty, then the VM will
> refuse to deallocate it.
>
>  > Even when the image is left unused for a long time, the allocation
>  > stays. Running additional allocations, which consumes less memory than
>  > the first allocation, does not free any memory allocated from the
>  > operating system. Evaluating garbage collect frees up the used memory.
>
> Right, but you do not which objects will go where after a GC.
>
>  > I wonder how I can tune the memory policy to more agressivly free OS
>  > memory when it is idle, and when it is allocating new objects. I
>  > looked at #idleLoopGCJustified (sat that to always answer true) and
>  > #favorGrowthOverReclamation (it answers false), but with no luck.
>
> You need to look at the free memory upper bound. Also, look at the
> release notes and, in the documentation, the file
> doc/TechNotes/vwMemoryMgmt.pdf. In particular, the technote has been
> essentially rewritten in 7.7.1, and contains much more information than
> the technotes previously released.
>
>  > I also have 7.7.1 images where the “Used memory” in the Memory Monitor
>  > answers 55 MB, while privates bytes allocated from Windows is over 500
>  > MB.
>
> That figure includes a number of things that are not necessarily old
> space, so you have to pay attention to that.
>
>  > Doing a garbage collect does not free any OS memory. I will
>  > address these problems later.
>
> Ok, but note I do not think there may be anything to address... look at
> the documentation and the free memory upper bound. Also, keep in mind
> that if you set the free memory upper bound to small values, then real
> applications can get into a cycle of
>
> try to allocate objects
> no space, and in the reclamation regime
> ok, GC
> still no space, grow memory
> work a little bit, some objects become garbage
> a subsequent GC cleans out garbage, and releases memory
> try to allocate objects
> no space, and in the reclamation regime
> ok, GC
> still no space, grow memory
> work a little bit, some objects become garbage
> a subsequent GC cleans out garbage, and releases memory
> try to allocate objects
> no space, and in the reclamation regime
> ok, GC
> etc...
>
> All that GC can be very painful! This is one of the possible
> performance pitfalls documented by the documentation, and by the memory
> policy tests. Did you look at the test / stress tests / tuner parcels?
>
> Andres.
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
> --
>
> Alan Knight [|], Engineering Manager, Cincom Smalltalk
>
> [hidden email]
>
> [hidden email]
>
> http://www.cincom.com/smalltalk
>
>
> ------------------------------------------------------------------------
> This message may contain confidential information and is intended for
> specific recipients unless explicitly noted otherwise. If you have
> reason to believe you are not an intended recipient of this message,
> please delete it and notify the sender. This message may not represent
> the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or
> affiliates, and does not constitute a contract or guarantee. Unencrypted
> electronic mail is not secure and the recipient of this message is
> expected to provide safeguards from viruses and pursue alternate means
> of communication where privacy or a binding message is desired.