memory utilization
How and when does Forte' free up allocated memory? Does Forte' have any
known or suspected memory leakage problems? Is there anything that you can
or should do to explicitly destroy an object when you are finished with it,
thus making sure the memory is released? We had understood that when an
object goes "out of scope" that the memory would automatically be freed, but
we have done some testing that might indicate that this is not always the case.
For example, when you delete a row from an array, are all the objects within
that row destroyed? What if those objects contain other objects? What if
they contain arrays? Will they all be destroyed? Do you need to explicitly
clear all the rows from an Array when you are finished with it? If so, why
is that not emphasized anywhere in the documentation or help files? Once
you have removed all the rows from an Array, how do you get rid of the
actual array object?
When you close a Window, are all the attributes associated with that window
freed up as well, including object attributes that are not mapped to
widgets? If you instantiate an object within a method using a local
variable name, that is defined only within that method, will the object be
automatically destroyed when the method completes?
Has anyone else experienced what would seem to be memory problems? If so,
how did you track it down, and how did you deal with it?
--Jeanne
=====================================================================
Jeanne Heslerjhesler@midwest.net
=====================================================================
[1724 byte] By [
] at [2007-11-25 5:00:58]
Forte releases memory once some thresholds are reached (see your manual for
utilization percent, expansion threshold and growth thresholds). At that
point, garbage collection occurs to throw non referenced objects. They are
NOT all automatically discarded. Roughly speaking garbage collection is a
two-way process. Transient objects that are allocated at high frequency are
tracked and quickly discarded when no longer referenced by any other
objects. Objects with a longer life span require what Forte calls a stable
generation. I don't know how stable it is but it is supposed to wipe out
your system from all residual unused objects. This second phase happen only
if not enough memory has been released.
There is also the contraction threshold and contraction decrease which allow
you to crunch your memory. It may be interested to see how the system
responds to various settings. Whatever platform you use the problem of
memory leaks will still remain independantly from Forte.
But you should not need shut the peer, should you -:)
-
From: Jeanne Hesler
To: forte-users
Subject: memory utilization
Date: Wednesday, August 28, 1996 9:43PM
How and when does Forte' free up allocated memory? Does Forte' have any
known or suspected memory leakage problems? Is there anything that you can
or should do to explicitly destroy an object when you are finished with it,
thus making sure the memory is released? We had understood that when an
object goes "out of scope" that the memory would automatically be freed, but
we have done some testing that might indicate that this is not always the
case.
For example, when you delete a row from an array, are all the objects within
that row destroyed? What if those objects contain other objects? What if
they contain arrays? Will they all be destroyed? Do you need to explicitly
clear all the rows from an Array when you are finished with it? If so, why
is that not emphasized anywhere in the documentation or help files? Once
you have removed all the rows from an Array, how do you get rid of the
actual array object?
When you close a Window, are all the attributes associated with that window
freed up as well, including object attributes that are not mapped to
widgets? If you instantiate an object within a method using a local
variable name, that is defined only within that method, will the object be
automatically destroyed when the method completes?
Has anyone else experienced what would seem to be memory problems? If so,
how did you track it down, and how did you deal with it?
--Jeanne
=====================================================================
Jeanne Heslerjhesler@midwest.net
=====================================================================
at 2007-6-29 9:19:58 >
-
> From: Bridonneau, Emmanuel <emmanuel@evolveinc.com>
> To: Jeanne Hesler <jhesler@midwest.net>
>
> There is also the contraction threshold and contraction decrease which
allow
> you to crunch your memory. It may be interested to see how the system
> responds to various settings. Whatever platform you use the problem of
> memory leaks will still remain independantly from Forte.
"Platform"? Development Environment? Language? or Hardware/Software
Platform? Forte is the first language/environment that I've worked in
which does not have an explicit destroy. It will be interesting to see how
we and others get along with memory. Memory problems in the past have been
our own problems. Once a "platform" starts taking care of half of it, the
question I have is which half? Everyone talks about the advantages of
4GL's when it comes to garbage collection. I agree that allocating and
freeing memory in C is a full time job. However, if these 4GL's, Forte
included, are not going to give up the memory fast enough or not allow
explicit freeing of memory, then how can we trust the language? The most
frustrating thing that I have found in client/server development is memory
problems. They're very difficult to trace and most often occur after you
have tested and deployed into your production environment. This is because
people use their workstations or "Clients" for other things besides running
our supposedly thin client application. Frankly, this is their
prerogative. We don't control the entire box. The more efficient and
tighter the code in our application, the more useful the entire workstation
will become.
> But you should not need shut the peer, should you -:)
>
What does this mean?
Thank you
almenke@theonramp.net
MSF&W, Springfield, IL
at 2007-6-29 9:19:58 >
Jeanne,
Answers to some of your questions.
>> Is there anything that you can or should do to explicitly destroy an
object when you are >>finished with it, thus making sure the memory is
released?
You can always NIL an object that you no longer want, but you are not required
to do so.
eg
MyObj : sometype = new; // Instatiate an object.
.
. //Use the object
.
MyObj = NIL;// Object no longer required.
>> We had understood that when an object goes "out of scope" that the memory
would >>automatically be freed, but we have done some testing that might
indicate that this is not >>always the case.
My understanding is that objects become available for garbage collection when
they are no longer referenced by any other object (don't forget any
DISTRIBUTED references.)
Garbage collection occurs automatically (Forte defined rules, not sure of the
exact details), or during development when you explicitly request Collect
Memory from the Utility menu in the Workspace Workshop.
>>Do you need to explicitly clear all the rows from an Array when you are
finished with it?
No - you can just NIL the array object. If the only references to the
individual objects making up the array are from the array itself it will
self-destructt. BUT if the objects are still referenced from elsewhere, the
array will go, but the objects still referenced will stay.
>>
>>Has anyone else experienced what would seem to be memory problems?
Only problems experienced here were developer-induced recursion problems or
trying to pass stupidly large objects as copy parameters. Tracking was not
easy, but we did not make enough use of appropriate log flags. Contact your
support people for details.
Brigette Muller
Hydro-Electric Commission Tasmania
at 2007-6-29 9:19:58 >
