Menu
▾
▴
dynapi-dev
|
From: Pascal <pb...@oi...> - 2001-02-21 14:25:09
|
so: myLayer = new DynLayer delete myLayer destroys it completely? (or do we have to delete every object created within the dynlayer object ?) Pascal Bestebroer (pb...@oi...) Software ontwikkelaar Oberon Informatiesystemen b.v. http://www.oibv.com > -----Oorspronkelijk bericht----- > Van: dyn...@li... > [mailto:dyn...@li...]Namens Eytan > Heidingsfeld > Verzonden: woensdag 21 februari 2001 14:20 > Aan: Dynapi-Dev > Onderwerp: [Dynapi-Dev] Continuing Freeing memory > > > Amazing news flash: > Thanx to Bradford Maness and the delete command in JS I found > that if you > delete objects(repeating objects not elements) in IE memory is freed. > > 8an > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > |
|
From: Pascal <pb...@oi...> - 2001-02-21 14:52:06
|
> "Note that delete affects only property values, not objects > referred to by those > properties" > >From this can we establish that we cannot rely on delete to > free memory reliably ??? > Does this also mean that we'd have to iterate through > sub-objects deleting them? Perhaps > some kind of destroy() method ??? hmm, it would then be possible to atleast delete all objects created within the DynLayer (simple for loop can be used) problematic thing are all objects with objects them selves.. the deletefromparent method could do this for us, take care of deletion of all objects referred to. I'll see if I can come up with anything.. and if it actually frees any memory at all. Pascal Bestebroer (pb...@oi...) Software ontwikkelaar Oberon Informatiesystemen b.v. http://www.oibv.com |
|
From: Eytan H. <ey...@tr...> - 2001-02-21 14:58:48
|
The problem is not mainly with that but with freeing memory of the element. BTW Why don't we use removeChild for removing layers in NN6? 8an |
|
From: Raymond S. <dst...@or...> - 2001-02-21 15:23:22
|
Maybe deleting it marks it for garbage collection. You would think there is some definitive guide as to what "flag" an item for "gc"... ----- Original Message ----- From: "Eytan Heidingsfeld" <ey...@tr...> To: <dyn...@li...> Sent: Wednesday, February 21, 2001 6:58 AM Subject: RE: [Dynapi-Dev] Continuing Freeing memory > The problem is not mainly with that but with freeing memory of the element. > BTW > Why don't we use removeChild for removing layers in NN6? > 8an > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > |
|
From: Raymond S. <dst...@or...> - 2001-02-21 15:36:28
|
Something I found...
11.7 Garbage Collection
In any programming language in which you can dynamically create new objects
(such as with the new operator in JavaScript) there must be some form of
"garbage collection"--a way of reclaiming the memory occupied by objects
that are no longer in use. In C and C++, garbage collection is manual--the
programmer explicitly decides when to free memory for reuse. In Java, on the
other hand, garbage collection is handled automatically--the system can
detect when objects are no longer in use and free them appropriately.
JavaScript also supports automatic garbage collection. In Internet Explorer
3.0, garbage collection is implemented in a technically sound way and you
don't have to understand any of its details--it is enough to know that when
your objects are no longer in use, the memory they occupy will automatically
be reclaimed by the system. Navigator 4.0 will also have a perfectly
transparent garbage collection scheme like this. Unfortunately, garbage
collection in earlier versions of Navigator is less than perfect. In
Navigator 3.0, it is pretty good, but requires you to be aware of a couple
of issues. In Navigator 2.0, garbage collection is seriously flawed, and you
must take a number of steps to avoid crashing the browser! The following
subsections provide the details.
Reference Counting in Navigator 3.0
In Navigator 3.0, garbage collection is performed by reference counting.
This means that every object (whether a user object created by JavaScript
code, or a built-in HTML object created by the browser) keeps track of the
number of references there are to it. Recall that objects are assigned by
reference in JavaScript, rather than having their complete value copied.
When an object is created and a reference to it is stored in a variable, the
object's reference count is 1. When the reference to the object is copied
and stored in another variable, the reference count is incremented to 2.
When one of the two variables that holds these references is overwritten
with some new value, the object's reference count is decremented back to 1.
If the reference count reaches zero, then there are no more references to
the object, and since there are no references to copy, there can never again
be a reference to the object in the program. Therefore, JavaScript knows
that it is safe to destroy the object and "garbage collect" the memory
associated with it.
This reference-counting scheme has some important implications. (These
implications are also true of the Internet Explorer garbage collector, but,
as we'll see, they are not true of the garbage collection scheme in
Navigator 2.0.) If JavaScript code running in a window creates an object,
and a reference to that object is stored in a variable of another window,
then that object will continue to exist even after the window that created
it is closed, or loads in a different page. The original reference to the
object is lost, but since a reference still exists from another window, the
object will not be garbage collected.
Perhaps a more surprising implication is that a top-level browser window may
be closed by the user or by JavaScript code, but the Window object
associated with it may continue to exist. This occurs when a variable in one
window contains a reference to the window that is closed. Since there is
still a reference to the Window object, that object cannot be garbage
collected. Note, however, that many of the methods and properties of a
Window object that is closed cannot be meaningfully used. In Navigator 3.0,
you should be sure to check the closed property (a Boolean value) of any
Window object before using its properties or methods, if there is any chance
that it could have been closed.
Shortcomings of Garbage Collection by Reference Counting
As you may already be aware, there are some shortcomings to using reference
counting as a garbage collection scheme. In fact, some people don't even
consider reference counting to be true garbage collection, and reserve that
term for algorithms such as "mark-and-sweep" garbage collection. The
computer science literature on garbage collection is large and technical,
and we won't get into it here. For our purposes it is enough to know that
reference counting is a very simple form of garbage collection to implement,
and it works fine in many situations. There are situations, however, in
which reference counting cannot correctly detect and collect all "garbage",
and you need to be aware of these.
The basic flaw with reference counting has to do with cyclical references.
If object A contains a reference to object B and object B contains a
reference to object A, then a cycle of references exists. A cycle would also
exist, for example, if A referred to B, B referred to C, and C referred back
to A. In cycles such as these, there is always a reference from within the
cycle to every element in the cycle. Thus, even if none of the elements of
the cycle has any remaining references, their reference count will never
drop below one, and they can never be garbage collected. The entire cycle
may be garbage, because there is no way to refer to any of these objects
from a program, but because they all refer to each other, a
reference-counting garbage collector will not be able to detect and free
this unused memory.
This problem with cycles is the price that must be paid for a simple,
lightweight, portable garbage collection scheme. The only way to prevent
this problem is by manual intervention. If you create code in which A refers
to B, B refers to C, and C refers to A, then you must be able to recognize
that you've created a cycle, and take steps to force the cycle to be garbage
collected when it is no longer needed.
When you know that the objects in your cycle are no longer in use, you can
force them to be garbage collected by breaking the cycle. You can do this by
picking one of the objects in the cycle and setting the property of it that
refers to the next object to null. For example, suppose that A, B, and C are
objects that each have a next property, and the value of this property is
set so that these objects refer to each other and form a cycle. When these
objects are no longer in use, you can break the cycle by setting A.next to
null. This means that object B no longer has a reference from A, so its
reference count can drop to zero and it can be garbage collected. Once it
has been garbage collected, then it will no longer refer to C, so its
reference count can drop to zero and it can be garbage collected. Once C is
garbage collected, A can be garbage collected.
Note, of course, that none of this can happen if A, B, and C are stored in
global variables in a window that is still open, because those variables A,
B, and C still refer to the objects. If these were local variables in a
function, and you broke their cycle before the function returned, then they
could be garbage collected. But if they are stored in global variables, they
will remain referenced until the window that contains them closes. In this
case, if you want to force them to be garbage collected you must break the
cycle and set the variables to null:
A.next = null; // break the cycle
A = B = C = null; // remove the last remaining external references
Per-Page Memory Management in Navigator 2.0
The garbage collection scheme in Navigator 2.0 is much simpler than that in
Navigator 3.0, and, unfortunately, it is inadequate for the needs of
JavaScript programs that use multiple windows and frames. In Navigator 2.0,
all objects created by JavaScript code running in any particular window
allocate memory from a pool of memory owned by the window. Then, when the
window is destroyed, or when the document (containing the JavaScript
program) displayed in the window is unloaded, the entire pool of memory is
freed at once. No memory is freed until then.
With this garbage collection scheme, all memory allocated by the JavaScript
running in a window can be freed in a single stroke. It is a simple and
efficient scheme to implement. Unfortunately, it suffers from two major
drawbacks.
First, if an object is created in one window, and then a reference to that
object is stored in a variable in a second window, that object will be
destroyed when the first window moves on to a new page, despite the fact
that there is still an active reference to it from the other window. If this
other window attempts to use this reference to the destroyed object, an
error will result, possibly crashing the browser! This is an especially
pernicious problem, because doing something as simple as assigning a string
can cause this problem. Consider the following code:
newwin = window.open("", "temp_window");
newwin.defaultStatus = "temporary browser window".
The defaultStatus property is set to a string "owned" by the original
window. If that window is closed, the string will be destroyed and the next
reference to defaultStatus will go looking for a non-existing string.
The second problem with this scheme is that if a window never unloads, the
memory associated with it will never be freed. For a page that runs some
JavaScript once and then is static, this is not a problem. But consider a
page that performs a status-bar animation, for example. If it updates the
status bar several times a second for a long time, the memory consumed by
that page will grow and grow. Another example occurs with the use of frames.
One frame might serve as a navigation window, with controls that allow a
user to easily browse a large site in other frames or other windows. These
other frames and windows may load and unload pages frequently, freeing
memory. But the navigation frame itself remains the same, and the memory
associated with it is not freed. Depending on how the event handlers are
written, there is a good chance that each time the user interacts with the
navigation controls some new string or object will be created, and no memory
will ever be freed. Eventually, the browser will run out of memory, and may
well crash.
Workarounds for Navigator 2.0
It is possible to compensate, somewhat, for these memory management problems
in Navigator 2.0. For the problem of memory not being released until the
page is unloaded, the solution is simply to be careful about how much memory
your scripts consume. If your page loops a lot or does a repetitive
animation, look very carefully at the code that is executed over and over,
and minimize the number of objects created on each iteration. Similarly, if
you write a script that the user may use frequently without ever unloading,
be sure to keep careful tabs on your memory usage.
Note that string manipulation is a big memory sink--each time you call a
method on a string object, a new string object is generally created for the
result. The same is true for string concatenation with the + operator.
For the problem of dangling references from one window to destroyed objects
that were owned by another, one solution is to avoid programs that rely on
inter-window references. Another solution is to be sure to make copies of
all strings and other objects that are passed from one window to another.
Suppose that in window 1, you want to set the defaultStatus property of
window 2, as we saw earlier. If you do this directly with code in window 1,
then window 2 will contain a reference to an object owned by window 1. But,
if you call a function in window 2 to do the assignment, and make sure that
the function makes a copy of the object, then the object assigned in window
2 will be owned by window 2. You could, for example, ensure that window 2
contains a definition of the following function:
function set_string_property(name, value)
{
// Assign a property to this window, using associative array notation.
// We add the empty string to the value to force JavaScript to make
// a copy. If this function is called from another window, we won't
// own the value string, but by making a copy, we do own the result.
self[name] = value + "";
}
With this function defined, you could then set the property from window 1
with a line like the following:
window2.set_string_property("defaultStatus", "temporary browser window");
|
|
From: Raymond S. <dst...@or...> - 2001-02-21 15:43:55
|
Sounds like we need a "null cycle killer". Damn sure circular references a playing a big roll in our leak... > This problem with cycles is the price that must be paid for a simple, lightweight, portable garbage collection scheme. The only way to prevent this problem is by manual intervention. If you create code in which A refers to B, B refers to C, and C refers to A, then you must be able to recognize that you've created a cycle, and take steps to force the cycle to be garbage collected when it is no longer needed. When you know that the objects in your cycle are no longer in use, you can force them to be garbage collected by breaking the cycle. You can do this by picking one of the objects in the cycle and setting the property of it that refers to the next object to null. For example, suppose that A, B, and C are objects that each have a next property, and the value of this property is set so that these objects refer to each other and form a cycle. When these objects are no longer in use, you can break the cycle by setting A.next to null. This means that object B no longer has a reference from A, so its reference count can drop to zero and it can be garbage collected. Once it has been garbage collected, then it will no longer refer to C, so its reference count can drop to zero and it can be garbage collected. Once C is garbage collected, A can be garbage collected. Note, of course, that none of this can happen if A, B, and C are stored in global variables in a window that is still open, because those variables A, B, and C still refer to the objects. If these were local variables in a function, and you broke their cycle before the function returned, then they could be garbage collected. But if they are stored in global variables, they will remain referenced until the window that contains them closes. In this case, if you want to force them to be garbage collected you must break the cycle and set the variables to null: A.next = null; // break the cycle A = B = C = null; // remove the last remaining external references |
|
From: Raymond S. <dst...@or...> - 2001-02-21 15:58:25
|
More morning mind food (at least where I am)... The new operator allocates memory for objects. How is this memory deallocated? If you have ever programmed in C++, you might wonder why JavaScript does not have a delete operator to match the new operator. The reason for this is simple: It's not necessary! In JavaScript, memory for objects is automatically reclaimed whenever there is no longer need for the object. The JavaScript interpreter tracks references to objects and deletes them when variables no longer refer to them. For example, consider the following JavaScript code: d = new Array (50); d = null; The first statement allocates memory for an Array object large enough to hold 50 elements, and then records the fact that the new object is referenced by a variable named d. The next statement, however, changes d so that instead of referring to the Array object, it instead contains the special value null. Since there is no longer any way to access the Array object, the JavaScript interpreter destroys it by reclaiming the memory that was allocated to it. Reclaiming memory allocated for objects which can no longer be accessed is called garbage collection. Allocated objects which are no longer accessible by variables are called orphan objects. This next example shows how to modify the above code to prevent the destruction of the Array object: d = new Array (50); e = d; // make e refer to the same object as d d = null; // disassociate d from the Array object Since the Array object is referenced by e at the moment it is abandoned by d, the Array object remains intact. In conclusion, there is no need to worry about destroying objects in JavaScript. Garbage collection is performed automatically by the interpreter whenever objects are no longer useful or documents are unloaded. If you want to explicitly destroy an object, you can do so by abandoning it -- that is, by making sure there are no variables that refer to it. (Setting the variables to null works pretty well for this.) |
|
From: Doug M. <do...@cr...> - 2001-02-21 21:21:08
|
eh? there IS a delete operator in JS. and saying "the specs say that mem is autoatically cleaned" is silly considering that we KNOW that it is not ----- Original Message ----- From: "Raymond Smith" <dst...@or...> To: <dyn...@li...> Sent: Wednesday, February 21, 2001 7:57 AM Subject: Re: [Dynapi-Dev] Continuing Freeing memory > More morning mind food (at least where I am)... > > > The new operator allocates memory for objects. How is this memory > deallocated? > > If you have ever programmed in C++, you might wonder why JavaScript does not > have a delete operator to match the new operator. The reason for this is > simple: It's not necessary! > In JavaScript, memory for objects is automatically reclaimed whenever there > is no longer need for the object. The JavaScript interpreter tracks > references to objects and deletes them when variables no longer refer to > them. > > For example, consider the following JavaScript code: > > d = new Array (50); > d = null; > > The first statement allocates memory for an Array object large enough to > hold 50 elements, and then records the fact that the new object is > referenced by a variable named d. > The next statement, however, changes d so that instead of referring to the > Array object, it instead contains the special value null. Since there is no > longer any way to access the Array object, the JavaScript interpreter > destroys it by reclaiming the memory that was allocated to it. > > Reclaiming memory allocated for objects which can no longer be accessed is > called garbage collection. Allocated objects which are no longer accessible > by variables are called orphan objects. > > This next example shows how to modify the above code to prevent the > destruction of the Array object: > > d = new Array (50); > e = d; // make e refer to the same object as d > d = null; // disassociate d from the Array object > Since the Array object is referenced by e at the moment it is abandoned by > d, the Array object remains intact. > In conclusion, there is no need to worry about destroying objects in > JavaScript. Garbage collection is performed automatically by the interpreter > whenever objects are no longer useful or documents are unloaded. If you want > to explicitly destroy an object, you can do so by abandoning it -- that is, > by making sure there are no variables that refer to it. (Setting the > variables to null works pretty well for this.) > > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev --- Outgoing mail is certified Virus Free by AVG Free Edition Download at: http://www.grisoft.com/html/us_index.cfm Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01 |
|
From: Richard E. <emb...@co...> - 2001-02-21 16:01:14
|
Raymond Smith wrote: > Sounds like we need a "null cycle killer". Damn sure circular references a > playing a big roll in our leak... > A good, modern gc collects cycles. The Boehm gc does and so does java's. I assume M$ uses similar technology. Don't know what NS does. All memory allocated is kept track of. Starting from a set of "well known objects" (top level objects) one sweeps marking all reachable objects (and not traversing objects more than once). Then all objects that have not been marked are collected. Cycles are NOT a problem. Richard Emberson |
|
From: Raymond S. <dst...@or...> - 2001-02-21 16:06:24
|
My post was a quote from O'Rielly's. Also, I am gathering all the data I can find that might be pertinent to finding what works. ----- Original Message ----- From: "Richard Emberson" <emb...@co...> To: <dyn...@li...> Sent: Wednesday, February 21, 2001 9:10 AM Subject: Re: [Dynapi-Dev] Continuing Freeing memory > Raymond Smith wrote: > > > Sounds like we need a "null cycle killer". Damn sure circular references a > > playing a big roll in our leak... > > > > A good, modern gc collects cycles. The Boehm gc does and so does java's. I > assume > M$ uses similar technology. Don't know what NS does. All > memory allocated is kept track of. Starting from a set of "well known objects" > (top > level objects) one sweeps marking all reachable objects (and not traversing > objects > more than once). Then all objects that have not been marked are collected. > Cycles are NOT a problem. > > Richard Emberson > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > |
|
From: Raymond S. <dst...@or...> - 2001-02-21 16:02:42
|
JavaScript-1.5 Reference JS_GC Function Summary Performs garbage collection in the JS memory pool. Syntax void JS_GC(JSContext *cx); Description JS_GC performs garbage collection, if necessary, of JS objects, doubles, and strings that are no longer needed by a script executing in a specified JSContext, cx. Garbage collection frees space in the memory pool so that it can be reused by the JS engine. When you use JS_malloc and JS_realloc to allocate memory for executable script contexts, these routines automatically invoke the garbage collection routine. When your scripts create many objects, you may want to call JS_GC directly in your code, particularly when request ends or a script terminates. To run garbage collection only when a certain amount of memory has been allocated, you can call JS_MaybeGC instead of JS_GC. JS_malloc Function Summary Allocates a region of memory for use. Syntax void * JS_malloc(JSContext *cx, size_t nbytes); Name Type Description cx JSContext * Pointer to a JS context from which to derive runtime information. nbytes size_t Amount of space, in bytes, to allocate. Description JS_malloc allocates a region of memory nbytes in size. If the allocation is successful, JS_malloc returns a pointer to the beginning of the region. If the memory cannot be allocated, JS_malloc passes cx to JS_ReportOutOfMemory to report the error, and returns a null pointer. As with a standard C call to malloc, the region of memory allocated by this call is uninitialized and should be assumed to contain meaningless information. Notes Currently JS_malloc is a wrapper on the standard C malloc call. Do not make assumptions based on this underlying reliance. Future versions of JS_malloc may be implemented in a different manner. JS_realloc Function Summary Reallocates a region of memory. Syntax void * JS_realloc(JSContext *cx, void *p, size_t nbytes); Name Type Description cx JSContext * Pointer to a JS context from which to derive runtime information. p void * Pointer to the previously allocated memory nbytes size_t Amount of space, in bytes, to reallocate. Description JS_realloc reallocates a region of memory, while preserving its contents. Typically you call JS_realloc because you need to allocate more memory than orginally allocated with a call to JS_malloc, but it can also be called to decrease the amount of allocated memory, and even to deallocate the memory region entirely. p is a pointer to the previously allocated memory region, and nbytes is the size, in bytes, of the region to allocate. Notes Currently JS_realloc is a wrapper on the standard C realloc call. Do not make assumptions based on this underlying reliance. Future versions of JS_realloc may be implemented in a different manner. If p is null, then JS_realloc behaves like JS_malloc. If p is not null, and nbytes is 0, JS_realloc returns null and the region is deallocated. As with JS_malloc, new space is not initialized and should be regarded to contain meaningless information. If a reallocation request fails, JS_realloc passes cx to JS_ReportOutOfMemory to report the error. Whenever the pointer returned by JS_realloc differs from p, the old region of memory is deallocated and should not be used. JS_MaybeGC Function Summary Invokes conditional garbage collection on the JS memory pool. Syntax void JS_MaybeGC(JSContext *cx); Description JS_MaybeGC performs a conditional garbage collection of JS objects, doubles, and strings that are no longer needed by a script executing in a specified JSContext, cx. This function checks that about 75% of available space has already been allocated to objects before peforming garbage collection. To force garbage collection regardless of the amount of allocated space, call JS_GC instead of JS_MaybeGC. |
|
From: Doug M. <do...@cr...> - 2001-02-21 21:22:18
|
my hero!! good score old chap.. too bad it's JS 1.5 ----- Original Message ----- From: "Raymond Smith" <dst...@or...> To: <dyn...@li...> Sent: Wednesday, February 21, 2001 8:01 AM Subject: Re: [Dynapi-Dev] Continuing Freeing memory > JavaScript-1.5 Reference > JS_GC Function > > Summary > Performs garbage collection in the JS memory pool. > Syntax > void JS_GC(JSContext *cx); > > > Description > JS_GC performs garbage collection, if necessary, of JS objects, doubles, and > strings that are no longer needed by a script executing in a specified > JSContext, cx. Garbage collection frees space in the memory pool so that it > can be reused by the JS engine. > When you use JS_malloc and JS_realloc to allocate memory for executable > script contexts, these routines automatically invoke the garbage collection > routine. > > When your scripts create many objects, you may want to call JS_GC directly > in your code, particularly when request ends or a script terminates. To run > garbage collection only when a certain amount of memory has been allocated, > you can call JS_MaybeGC instead of JS_GC. > > JS_malloc Function > > Summary > Allocates a region of memory for use. > Syntax > void * JS_malloc(JSContext *cx, size_t nbytes); > > Name Type Description > cx JSContext * Pointer to a JS context from which to derive runtime > information. > > nbytes size_t Amount of space, in bytes, to allocate. > > > Description > JS_malloc allocates a region of memory nbytes in size. If the allocation is > successful, JS_malloc returns a pointer to the beginning of the region. > If the memory cannot be allocated, JS_malloc passes cx to > JS_ReportOutOfMemory to report the error, and returns a null pointer. > > As with a standard C call to malloc, the region of memory allocated by this > call is uninitialized and should be assumed to contain meaningless > information. > > > Notes > Currently JS_malloc is a wrapper on the standard C malloc call. Do not make > assumptions based on this underlying reliance. Future versions of JS_malloc > may be implemented in a different manner. > > JS_realloc Function > > Summary > Reallocates a region of memory. > Syntax > void * JS_realloc(JSContext *cx, void *p, size_t nbytes); > > Name Type Description > cx JSContext * Pointer to a JS context from which to derive runtime > information. > > p void * Pointer to the previously allocated memory > > nbytes size_t Amount of space, in bytes, to reallocate. > > > Description > JS_realloc reallocates a region of memory, while preserving its contents. > Typically you call JS_realloc because you need to allocate more memory than > orginally allocated with a call to JS_malloc, but it can also be called to > decrease the amount of allocated memory, and even to deallocate the memory > region entirely. p is a pointer to the previously allocated memory region, > and nbytes is the size, in bytes, of the region to allocate. > > Notes > Currently JS_realloc is a wrapper on the standard C realloc call. Do not > make assumptions based on this underlying reliance. Future versions of > JS_realloc may be implemented in a different manner. > If p is null, then JS_realloc behaves like JS_malloc. If p is not null, and > nbytes is 0, JS_realloc returns null and the region is deallocated. As with > JS_malloc, new space is not initialized and should be regarded to contain > meaningless information. > > If a reallocation request fails, JS_realloc passes cx to > JS_ReportOutOfMemory to report the error. > > Whenever the pointer returned by JS_realloc differs from p, the old region > of memory is deallocated and should not be used. > > JS_MaybeGC Function > > Summary > Invokes conditional garbage collection on the JS memory pool. > Syntax > void JS_MaybeGC(JSContext *cx); > > > Description > JS_MaybeGC performs a conditional garbage collection of JS objects, doubles, > and strings that are no longer needed by a script executing in a specified > JSContext, cx. This function checks that about 75% of available space has > already been allocated to objects before peforming garbage collection. To > force garbage collection regardless of the amount of allocated space, call > JS_GC instead of JS_MaybeGC. > > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev --- Outgoing mail is certified Virus Free by AVG Free Edition Download at: http://www.grisoft.com/html/us_index.cfm Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01 |
|
From: Jared N. <ja...@aa...> - 2001-02-21 22:26:04
|
Not sure if my tests are reliable, but I tried the following, and it showed little difference: www.aavex.com/asl/memtests jaredn :: http://webfx.eae.net |
|
From: Jordi - I. - M. <jmi...@or...> - 2001-02-21 20:17:05
|
Oh my this is going to be fun Raymond Smith wrote: > Sounds like we need a "null cycle killer". Damn sure circular references a > playing a big roll in our leak... > > > > > This problem with cycles is the price that must be paid for a simple, > lightweight, portable garbage collection scheme. The only way to prevent > this problem is by manual intervention. If you create code in which A refers > to B, B refers to C, and C refers to A, then you must be able to recognize > that you've created a cycle, and take steps to force the cycle to be garbage > collected when it is no longer needed. > > When you know that the objects in your cycle are no longer in use, you can > force them to be garbage collected by breaking the cycle. You can do this by > picking one of the objects in the cycle and setting the property of it that > refers to the next object to null. For example, suppose that A, B, and C are > objects that each have a next property, and the value of this property is > set so that these objects refer to each other and form a cycle. When these > objects are no longer in use, you can break the cycle by setting A.next to > null. This means that object B no longer has a reference from A, so its > reference count can drop to zero and it can be garbage collected. Once it > has been garbage collected, then it will no longer refer to C, so its > reference count can drop to zero and it can be garbage collected. Once C is > garbage collected, A can be garbage collected. > > Note, of course, that none of this can happen if A, B, and C are stored in > global variables in a window that is still open, because those variables A, > B, and C still refer to the objects. If these were local variables in a > function, and you broke their cycle before the function returned, then they > could be garbage collected. But if they are stored in global variables, they > will remain referenced until the window that contains them closes. In this > case, if you want to force them to be garbage collected you must break the > cycle and set the variables to null: > > A.next = null; // break the cycle > A = B = C = null; // remove the last remaining external references > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev |
|
From: Jared N. <ja...@aa...> - 2001-02-21 15:49:32
|
Just so you know, removeChild also works in IE5.5, in case you're interested. To get at all the children's children you could just recursively call the memFree() method (or whatever you choose to call it). Also, while the intrerpreter does rely on automatic garbage collection, this delete idea will at least 'tag' it for collection immediately. |
|
From: Jared N. <ja...@aa...> - 2001-02-21 15:53:29
|
BTW, last post is speculation, but I'm fairly sure...also I said get, when I meant delete :) |
|
From: Raymond S. <dst...@or...> - 2001-02-21 16:55:04
|
The "11.7 Garbage Collection" section on gc was found on a .ru site that had illegally posted the entire JavaScript: The Definitive Guide book by O'Reilly online. Since I have the book I checked. It on pages 192-197 of the 3rd Edition |
|
From: Joachim L. <lu...@ho...> - 2001-02-21 18:11:10
|
I did a search about memory leaks in IE in Microsoft's knowledgebase. These are the issues that seemed relevant or could shed a light on this dark matter :-) Complex DHTML Pages Cause Memory Usage to Increase Beyond Bounds http://support.microsoft.com/support/kb/articles/q248/6/30.asp Status: Fixed in 5.01 Memory Leak in Internet Explorer When Background Image Is Resized http://support.microsoft.com/support/kb/articles/q254/6/37.asp Status: Not relevant to DynAPI, but fixed in 5.01 SP1 Memory Leak in Internet Explorer Default Download Behavior http://support.microsoft.com/support/kb/articles/q259/3/65.asp Status: Not relevant to DynAPI, but fixed in 5.5 SP1 Memory Leak in JScript Array.toString and Array.toLocaleString Methods http://support.microsoft.com/support/kb/articles/q281/1/48.asp Workaround: Use Array.join(",") instead of the Array.toString method. Status: Bug exists in JScript 5.5, not in earlier versions COM Objects Created in JScript Not Released Immediately http://support.microsoft.com/support/kb/articles/q164/4/94.asp Status: Not a bug, and not relevant to DynAPI The Array.toString method was the only "live" bug I found, but I don't know if it's used anywhere in the code, but there is a workaround. There must be other issues because I use the workaround in my own code, and I still have the memory problem. Personally I'm suspecting the first one hasn't _really_ been fixed. /Lunna |
|
From: Doug M. <do...@cr...> - 2001-02-21 21:17:01
|
> > "Note that delete affects only property values, not objects
> > referred to by those
> > properties"
>
> > >From this can we establish that we cannot rely on delete to
> > free memory reliably ???
> > Does this also mean that we'd have to iterate through
> > sub-objects deleting them? Perhaps
> > some kind of destroy() method ???
>
> hmm, it would then be possible to atleast delete all objects created
within
> the DynLayer (simple for loop can be used) problematic thing are all
> objects with objects them selves..
>
> the deletefromparent method could do this for us, take care of deletion of
> all objects referred to. I'll see if I can come up with anything.. and if
it
> actually frees any memory at all.
a recursive funtion maybe?
'psudo code'
function delete_children(obj){
for each child in obj.children[] {
delete_children(child)
}
delete obj
}
this would delete all children of all children of all children.. ect
---
Outgoing mail is certified Virus Free by AVG Free Edition
Download at: http://www.grisoft.com/html/us_index.cfm
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01
|
|
From: Pascal <pb...@oi...> - 2001-02-21 15:35:23
|
One of the main changes to DynAPI would then be making the DynDocument's child objects of the DynAPI.. then you can destroy the complete DynAPI tree using: destroy(DynAPI) add that to the onunload handler (can it be all that easy!?) Pascal Bestebroer (pb...@oi...) Software ontwikkelaar Oberon Informatiesystemen b.v. http://www.oibv.com > -----Oorspronkelijk bericht----- > Van: dyn...@li... > [mailto:dyn...@li...]Namens Jordi - > IlMaestro > - Ministral > Verzonden: woensdag 21 februari 2001 16:15 > Aan: dyn...@li... > Onderwerp: Re: [Dynapi-Dev] Continuing Freeing memory > > > We could easily have a destroy function > > function destroy(object) { > for(var i in object) destroy(i) > delete object > } > > This would appy to any object, not only DynLayers. Maybe > DynAPI.destroy() or even > destroy(window) and see what happens. > > Richard Emberson wrote: > > > ECMAScript Language Specification > > http://www.ecma.ch/ecma1/stand/ecma-262.htm > > > > ECMAScript Components Specification > > http://www.ecma.ch/ecma1/stand/ecma-290.htm > > > > >From the spec for javascript (Ecma-262): > > > > 8.6.2.5 [[Delete]] (P) > > When the [[Delete]] method of O is called with property > name P, the following > > steps are taken: 1. If O doesn t have a property with name > P, return true. > > 2. If the property has the DontDelete attribute, return false. > > 3. Remove the property with name P from O. > > 4. Return true. > > > > 11.4.1 The delete Operator > > The production UnaryExpression : delete UnaryExpression is > evaluated as > > follows: > > 1. Evaluate UnaryExpression. > > 2. If Type(Result(1)) is not Reference, return true. > > 3. Call GetBase(Result(1)). > > 4. Call GetPropertyName(Result(1)). > > 5. Call the [[Delete]] method on Result(3), providing > Result(4) as the property > > name to delete. > > 6. Return Result(5). > > > > Implimentations of course can vary. > > > > When I wrote my javascript interpreter/compiler 4 years ago > I helped (in a very > > small way) > > in debugging the spec. > > > > Richard Emberson > > > > Pascal wrote: > > > > > so: > > > > > > myLayer = new DynLayer > > > > > > delete myLayer > > > > > > destroys it completely? (or do we have to delete every > object created within > > > the dynlayer object ?) > > > > > > Pascal Bestebroer (pb...@oi...) > > > Software ontwikkelaar > > > Oberon Informatiesystemen b.v. > > > http://www.oibv.com > > > > > > > -----Oorspronkelijk bericht----- > > > > Van: dyn...@li... > > > > [mailto:dyn...@li...]Namens Eytan > > > > Heidingsfeld > > > > Verzonden: woensdag 21 februari 2001 14:20 > > > > Aan: Dynapi-Dev > > > > Onderwerp: [Dynapi-Dev] Continuing Freeing memory > > > > > > > > > > > > Amazing news flash: > > > > Thanx to Bradford Maness and the delete command in JS I found > > > > that if you > > > > delete objects(repeating objects not elements) in IE > memory is freed. > > > > > > > > 8an > > > > > > > > > > > > _______________________________________________ > > > > Dynapi-Dev mailing list > > > > Dyn...@li... > > > > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > > > > > > > > > > _______________________________________________ > > > Dynapi-Dev mailing list > > > Dyn...@li... > > > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > > > > _______________________________________________ > > Dynapi-Dev mailing list > > Dyn...@li... > > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > |
|
From: Doug M. <do...@cr...> - 2001-02-21 21:19:10
|
> One of the main changes to DynAPI would then be making the DynDocument's > child objects of the DynAPI.. then you can destroy the complete DynAPI tree > using: > > destroy(DynAPI) > > add that to the onunload handler (can it be all that easy!?) > assuming our assumtions about the delete operator (and it's implementation in IE and NS) are correct, it would indeed be that easy --- Outgoing mail is certified Virus Free by AVG Free Edition Download at: http://www.grisoft.com/html/us_index.cfm Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01 |
|
From: Mark P. <mar...@hi...> - 2001-02-21 14:35:52
|
From "Javascript : The Definitive Guide - 3rd Edition, Flannagan - O'Reilly" "Note that delete affects only property values, not objects referred to by those properties" also "If you are a C++ programmer, note that the delete operator in JS in nothing like the delete operator in C++. In JS, memory deallocation is handled automatically by garbage collection, and you never have to worry about explicitly freeing up memory." From this can we establish that we cannot rely on delete to free memory reliably ??? Does this also mean that we'd have to iterate through sub-objects deleting them? Perhaps some kind of destroy() method ??? Pascal wrote: > so: > > myLayer = new DynLayer > > delete myLayer > > destroys it completely? (or do we have to delete every object created within > the dynlayer object ?) > > Pascal Bestebroer (pb...@oi...) > Software ontwikkelaar > Oberon Informatiesystemen b.v. > http://www.oibv.com > > > -----Oorspronkelijk bericht----- > > Van: dyn...@li... > > [mailto:dyn...@li...]Namens Eytan > > Heidingsfeld > > Verzonden: woensdag 21 februari 2001 14:20 > > Aan: Dynapi-Dev > > Onderwerp: [Dynapi-Dev] Continuing Freeing memory > > > > > > Amazing news flash: > > Thanx to Bradford Maness and the delete command in JS I found > > that if you > > delete objects(repeating objects not elements) in IE memory is freed. > > > > 8an > > > > > > _______________________________________________ > > Dynapi-Dev mailing list > > Dyn...@li... > > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev |
|
From: Richard E. <emb...@co...> - 2001-02-21 15:02:15
|
ECMAScript Language Specification http://www.ecma.ch/ecma1/stand/ecma-262.htm ECMAScript Components Specification http://www.ecma.ch/ecma1/stand/ecma-290.htm From the spec for javascript (Ecma-262): 8.6.2.5 [[Delete]] (P) When the [[Delete]] method of O is called with property name P, the following steps are taken: 1. If O doesn t have a property with name P, return true. 2. If the property has the DontDelete attribute, return false. 3. Remove the property with name P from O. 4. Return true. 11.4.1 The delete Operator The production UnaryExpression : delete UnaryExpression is evaluated as follows: 1. Evaluate UnaryExpression. 2. If Type(Result(1)) is not Reference, return true. 3. Call GetBase(Result(1)). 4. Call GetPropertyName(Result(1)). 5. Call the [[Delete]] method on Result(3), providing Result(4) as the property name to delete. 6. Return Result(5). Implimentations of course can vary. When I wrote my javascript interpreter/compiler 4 years ago I helped (in a very small way) in debugging the spec. Richard Emberson Pascal wrote: > so: > > myLayer = new DynLayer > > delete myLayer > > destroys it completely? (or do we have to delete every object created within > the dynlayer object ?) > > Pascal Bestebroer (pb...@oi...) > Software ontwikkelaar > Oberon Informatiesystemen b.v. > http://www.oibv.com > > > -----Oorspronkelijk bericht----- > > Van: dyn...@li... > > [mailto:dyn...@li...]Namens Eytan > > Heidingsfeld > > Verzonden: woensdag 21 februari 2001 14:20 > > Aan: Dynapi-Dev > > Onderwerp: [Dynapi-Dev] Continuing Freeing memory > > > > > > Amazing news flash: > > Thanx to Bradford Maness and the delete command in JS I found > > that if you > > delete objects(repeating objects not elements) in IE memory is freed. > > > > 8an > > > > > > _______________________________________________ > > Dynapi-Dev mailing list > > Dyn...@li... > > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev |
|
From: Jordi - I. - M. <jmi...@or...> - 2001-02-21 15:20:40
|
We could easily have a destroy function
function destroy(object) {
for(var i in object) destroy(i)
delete object
}
This would appy to any object, not only DynLayers. Maybe DynAPI.destroy() or even
destroy(window) and see what happens.
Richard Emberson wrote:
> ECMAScript Language Specification
> http://www.ecma.ch/ecma1/stand/ecma-262.htm
>
> ECMAScript Components Specification
> http://www.ecma.ch/ecma1/stand/ecma-290.htm
>
> >From the spec for javascript (Ecma-262):
>
> 8.6.2.5 [[Delete]] (P)
> When the [[Delete]] method of O is called with property name P, the following
> steps are taken: 1. If O doesn t have a property with name P, return true.
> 2. If the property has the DontDelete attribute, return false.
> 3. Remove the property with name P from O.
> 4. Return true.
>
> 11.4.1 The delete Operator
> The production UnaryExpression : delete UnaryExpression is evaluated as
> follows:
> 1. Evaluate UnaryExpression.
> 2. If Type(Result(1)) is not Reference, return true.
> 3. Call GetBase(Result(1)).
> 4. Call GetPropertyName(Result(1)).
> 5. Call the [[Delete]] method on Result(3), providing Result(4) as the property
> name to delete.
> 6. Return Result(5).
>
> Implimentations of course can vary.
>
> When I wrote my javascript interpreter/compiler 4 years ago I helped (in a very
> small way)
> in debugging the spec.
>
> Richard Emberson
>
> Pascal wrote:
>
> > so:
> >
> > myLayer = new DynLayer
> >
> > delete myLayer
> >
> > destroys it completely? (or do we have to delete every object created within
> > the dynlayer object ?)
> >
> > Pascal Bestebroer (pb...@oi...)
> > Software ontwikkelaar
> > Oberon Informatiesystemen b.v.
> > http://www.oibv.com
> >
> > > -----Oorspronkelijk bericht-----
> > > Van: dyn...@li...
> > > [mailto:dyn...@li...]Namens Eytan
> > > Heidingsfeld
> > > Verzonden: woensdag 21 februari 2001 14:20
> > > Aan: Dynapi-Dev
> > > Onderwerp: [Dynapi-Dev] Continuing Freeing memory
> > >
> > >
> > > Amazing news flash:
> > > Thanx to Bradford Maness and the delete command in JS I found
> > > that if you
> > > delete objects(repeating objects not elements) in IE memory is freed.
> > >
> > > 8an
> > >
> > >
> > > _______________________________________________
> > > Dynapi-Dev mailing list
> > > Dyn...@li...
> > > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> > >
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
|
|
From: Doug M. <do...@cr...> - 2001-02-21 21:18:06
|
DOH.
Someone beet me to it..
(the recursive function I mean
----- Original Message -----
From: "Jordi - IlMaestro - Ministral" <jmi...@or...>
To: <dyn...@li...>
Sent: Wednesday, February 21, 2001 7:14 AM
Subject: Re: [Dynapi-Dev] Continuing Freeing memory
> We could easily have a destroy function
>
> function destroy(object) {
> for(var i in object) destroy(i)
> delete object
> }
>
> This would appy to any object, not only DynLayers. Maybe DynAPI.destroy()
or even
> destroy(window) and see what happens.
>
> Richard Emberson wrote:
>
> > ECMAScript Language Specification
> > http://www.ecma.ch/ecma1/stand/ecma-262.htm
> >
> > ECMAScript Components Specification
> > http://www.ecma.ch/ecma1/stand/ecma-290.htm
> >
> > >From the spec for javascript (Ecma-262):
> >
> > 8.6.2.5 [[Delete]] (P)
> > When the [[Delete]] method of O is called with property name P, the
following
> > steps are taken: 1. If O doesn t have a property with name P, return
true.
> > 2. If the property has the DontDelete attribute, return false.
> > 3. Remove the property with name P from O.
> > 4. Return true.
> >
> > 11.4.1 The delete Operator
> > The production UnaryExpression : delete UnaryExpression is evaluated as
> > follows:
> > 1. Evaluate UnaryExpression.
> > 2. If Type(Result(1)) is not Reference, return true.
> > 3. Call GetBase(Result(1)).
> > 4. Call GetPropertyName(Result(1)).
> > 5. Call the [[Delete]] method on Result(3), providing Result(4) as the
property
> > name to delete.
> > 6. Return Result(5).
> >
> > Implimentations of course can vary.
> >
> > When I wrote my javascript interpreter/compiler 4 years ago I helped (in
a very
> > small way)
> > in debugging the spec.
> >
> > Richard Emberson
> >
> > Pascal wrote:
> >
> > > so:
> > >
> > > myLayer = new DynLayer
> > >
> > > delete myLayer
> > >
> > > destroys it completely? (or do we have to delete every object created
within
> > > the dynlayer object ?)
> > >
> > > Pascal Bestebroer (pb...@oi...)
> > > Software ontwikkelaar
> > > Oberon Informatiesystemen b.v.
> > > http://www.oibv.com
> > >
> > > > -----Oorspronkelijk bericht-----
> > > > Van: dyn...@li...
> > > > [mailto:dyn...@li...]Namens Eytan
> > > > Heidingsfeld
> > > > Verzonden: woensdag 21 februari 2001 14:20
> > > > Aan: Dynapi-Dev
> > > > Onderwerp: [Dynapi-Dev] Continuing Freeing memory
> > > >
> > > >
> > > > Amazing news flash:
> > > > Thanx to Bradford Maness and the delete command in JS I found
> > > > that if you
> > > > delete objects(repeating objects not elements) in IE memory is
freed.
> > > >
> > > > 8an
> > > >
> > > >
> > > > _______________________________________________
> > > > Dynapi-Dev mailing list
> > > > Dyn...@li...
> > > > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> > > >
> > >
> > > _______________________________________________
> > > Dynapi-Dev mailing list
> > > Dyn...@li...
> > > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
---
Outgoing mail is certified Virus Free by AVG Free Edition
Download at: http://www.grisoft.com/html/us_index.cfm
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X