Deleting a preloaded image from memory

[ivan.leben]

How can I really delete a preloaded image from memory/disk cache? Let's
say I preload an image by creating an Image object and setting its src
attribute to desired URL:

var img = new Image();
img.src = [someurl];

Then I use the image a few more times by adding it into an Array
object:

var images = new Array();
images.push(img);

I found out that just calling 'delete' on a pointer to that Image
object, doesn't free up the RAM.

delete images[0]; //RAM is not freed here!

Should I call delete on all the references to the image object? This
would be a real pain, since I have to check about 3000 lines of code
for possible references to it and make sure I 'delete' all of them...
What about the other new Image objects, that get their src attribute
set to the same url?

[Bart Van der Donck]

Richard Cornford wrote:

Remember that you responded to the suggestion that:-

| Setting a pointer to null obviously won't delete the object
| pointed to from memory, but just change the address the
| pointer is referencing (from address of the object to
| null = 0x0000000).

- was pure speculation with the rather specific assertion that "That is
no speculation - it's just how this works", and went on to detail the
precise process of assigning a value to a variable in javascript. These
were not generalisations about how computers work. Rather they were
generalisations about what javascript implementations do, and you don't
have the information necessary to be saying that these things are true
or (or even relevant to) all javascript implementations.
I'ld say it's a buffering issue then. When a variable gets a new value,
there are 2 possible ways:
(1) The memory address gets populated with new bytes; or
(2) It points to another memory address, where the original address
keeps its current content (and is not freed).
In machine code there are no pointers. 'Pointer' is a concept that may
apply to some values but that concept is in the mind of the programmer
not inherent in the machine code.
I'm not sure if there's a physical equivalent for a pointer. But no
computer can work without the concept. The bits itself do not mean
anything - together they form a byte, and the byte responds to
something in the mind of the programmer.

Binary numericals are not integers,

Above you described them as "a combination of 0's and 1's", when there
are no actual ones or zeros in the hardware. Any bit pattern can be
conceived as a representation of an integer value.

Not directly. The traditional representation of a bit pattern since
many decades is a range holding ones and zeros. It's an abstraction of
course. You could think of it as a bunch of people, where males are 0
and females 1, for example.

if that's what you mean ? And "loaded into data",
does that mean "allocated to memory addresses" ?

I mean that if you look down as far as the state of the electronic
circuits there is no inherent meaning in anything you see. No pointers,
no allocated memory, not variable and so on.

Correct, no variables. But allocating memory is certainly happening by
means of electronic circuits (which is how chipsets hold data).

Then your statement could be read as "Binary numerical values
that are allocated to memory addresses". This is indeed the
correct description of what happens then.

That is writing more in than I meant to say, which was only that at that
lowest level you have nothing but bit patterns in electronic circuits.

Yes, that is correct.

Wrong. A memory address is a physical storage method on a
microchip.

No they are not, and that was not my point anyway. Conceptually a
'block' has a magnitude in addition to a location. The address is only a
location.

No. Memory is a physically stored range of bit statusses. Say I have 2
bottles (each bottle is a bit, together they represent 1 byte). Then I
imagine that:
- 0 is the equivalent of two empty bottles
- 1 is the equivalent of a full bottle + an empty bottle
- 2 is the equivalent of an empty bottle + a full bottle
- 3 is the equivalent of two full bottles

Suppose I want to remember the value "3" for later, then I fill both
bottles. I can go eat a sandwich and come back. Then I want to recall
which value I had alloacted. I see two full bottles so the value is
three. The bottles have remembered my value, not me. This is how
memory allocation works.
| Referencing and memory allocation take place when
| the browser compiles the javascript to something
| the machine understands.

- in which "the *browser* compiles the javascript to something the
machine understands" (stress added by me) is a questionable assertion
when the browser is written in Java and the javascript complied into
bytecode. It is, as you say, the JVM that produces the actual executable
code, not the browser as you asserted.
Sure, that's correct. If you have an iron with javascript support, the
iron would compile the javascript code.
[...]

--
Bart

[Bart Van der Donck]

Thomas 'PointedEars' Lahn wrote:

You are quick with unfounded generalizations, and completely discard the
possibility that you do not know everything, or even that you may be wrong.
It's no fun discussing with you.

I do not discard that possibility - never have, never will. Feel free
to search my usenet reputation, I'm the first to admit inaccurate
terminology or errors.

At its basic level, _any_ computer works with pointers, binary numeric
data and memory addresses.

(At a computer's basic level there are electrons or other smallest carriers
of information.) At the lowest machine code level (that is _not_ an
Assembler language!) there are no pointers; there are registers that can
hold _integer_ data (currently mostly stored as binary digits).

I wouldn't say 'mostly', but 'always'. I'm not aware of any system that
doesn't store RAM as binary digits, and I'm not sure if this is
überhaupt possible.

--
Bart

[Lasse Reichstein Nielsen]

"Bart Van der Donck" <ba**@nijlen.com> writes:

I'm not aware of any system that doesn't store RAM as binary digits,
and I'm not sure if this is überhaupt possible.

It's possible, and there were attempts in the early days of computers
to build decimal based computers. It just turned out to be too fragile.
Distinguishing between ten levels of voltage was more errorprone than
just between "on" and "off".

I believe both the Eniac and the Mark I were decimal.

It'll be interesting to see whether optical computers will be able
to be non-binary, and whether there is anything to gain from it.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[VK]

Bart Van der Donck wrote:

I'm not aware of any system that
doesn't store RAM as binary digits, and I'm not sure if this is
überhaupt possible.

If you decided to go back up to Big Bang both in time and space :-):
the very first big /electronic/ computers for statistical calculations
operated with analog electric potentials - so the result was the
resulting potential affected by input potentials (arguments we would
say now). Kind of the Old Greek "calculator gismo" made of pipes and
jars where you pull water on the top and see the solution by how and
what jars are filled at the bottom.

That is about "überhaupt possible" :-) - but naturally all modern
computers operate with discret signals based /internally/ on binary
on/off system.

But it has no relevance to the memory management in JavaScript/JScript
(nor to any other higher level language for this matter).

[Thomas 'PointedEars' Lahn]

Bart Van der Donck wrote:

Thomas 'PointedEars' Lahn wrote:

> At its basic level, _any_ computer works with pointers, binary numeric
> data and memory addresses.

(At a computer's basic level there are electrons or other smallest
carriers of information.) At the lowest machine code level (that is
_not_ an Assembler language!) there are no pointers; there are registers
that can hold _integer_ data (currently mostly stored as binary digits).

I wouldn't say 'mostly', but 'always'. I'm not aware of any system
that doesn't store RAM as binary digits, and I'm not sure if this is
überhaupt possible.

Get informed about quantum computers, for example.
PointedEars
--
In the First World War, 13 million people were killed. In the Second
World War, 40 million people were killed. I think that if a third war
takes place, nothing is going to be left on the face of earth.
-- Shakira, 2003-02-05 @ MTV.com

[Richard Cornford]

Bart Van der Donck wrote:

Richard Cornford wrote:

Remember that you responded to the suggestion that:-

| Setting a pointer to null obviously won't delete the
| object pointed to from memory, but just change the
| address the pointer is referencing (from address of
| the object to null = 0x0000000).

- was pure speculation with the rather specific assertion
that "That is no speculation - it's just how this works",
and went on to detail the precise process of assigning a
value to a variable in javascript. These were not
generalisations about how computers work. Rather they were
generalisations about what javascript implementations do,
and you don't have the information necessary to be saying
that these things are true or (or even relevant to) all
javascript implementations.
I'ld say it's a buffering issue then.

Then I would say that you are being irrelevant.
When a variable gets a new value,
This would be a javascript variable? Something that is specified as a
property added to a dynamic object and, by implication, has both value
and type. That may make a javascript variable a structure attached in
some way to another structure, where both the structures and the nature
of their attachment are no more than possibilities that may be manifest
in the implementation, may have almost any arbitrary form and will be
influenced by the implementation language.
there are 2 possible ways:
No there are not. There is a very wide spectrum of possibilities in
implementing javascript variables.
(1) The memory address gets populated with new bytes; or
"The memory address"? In practice hundreds of memory addresses may have
new values written to them during the creation of a javascript variable.
(2) It points to another memory address, where the original
address keeps its current content (and is not freed).
If you are going to think about it on this level there is only one
possibility; The creation of a javascript variable results in values
being written into bytes at memory addresses. There is absolutely no
point in saying so, because that is both obvious and trivial.

In machine code there are no pointers. 'Pointer' is a concept
that may apply to some values but that concept is in the mind
of the programmer not inherent in the machine code.

I'm not sure if there's a physical equivalent for a
pointer.

A program counter, as a register that is intended to only hold a
reference to a memory location, is probably as close as hardware gets to
having a 'pointer' (and, unlike address registers, you would come
unstuck pretty quickly if you attempted to store data in a program
counter).
But no computer can work without the concept.
Computers are machines, they work quite successfully without perception
or conception.

While computers must interpret some bit patterns as memory addresses the
bit pattern is only a memory address at the point when it is used as a
memory address. In machine code there are no 'pointers', only the act of
addressing memory.
The bits itself do not mean anything - together they
form a byte, and the byte responds to
something in the mind of the programmer.
I assume that was supposed to be 'the byte _corresponds_ to ...'.

Which makes my point, at the very lowest level there is no meaning, and
at the javascript level the lowest level has been hidden behind a
spectrum of (largely unimportant) implementation details. Picking some
arbitrary level in-between and trying to make generalisations about
javascript is not a viable (or valuable) practice.

Binary numericals are not integers,

Above you described them as "a combination of 0's and 1's",
when there are no actual ones or zeros in the hardware. Any
bit pattern can be conceived as a representation of an integer
value.

Not directly. The traditional representation of a bit pattern
since many decades is a range holding ones and zeros.

Are you saying that ones and zeros are not intergers?
It's an abstraction of course.
Yes, as is thinking about bit patterns as integers, or hex numbers. I
would say that hex was the most traditional representation of a bit
pattern.
You could think of it as a bunch of people, where males
are 0 and females 1, for example.
Why on earth would I want to do that?

if that's what you mean ? And "loaded into data",
does that mean "allocated to memory addresses" ?

I mean that if you look down as far as the state of the
electronic circuits there is no inherent meaning in anything
you see. No pointers, no allocated memory, not variable and
so on.

Correct, no variables.

Nor any other meaningful concepts.
But allocating memory is certainly happening by means
of electronic circuits (which is how chipsets hold data).
Electronic circuits acting under the direction of a program. The meaning
of what those circuits are doing comes from the programmer. If the
programmer has programmed memory allocation the circuits are not aware
that memory allocation is what they are doing, and you could not validly
deduce that memory allocation was the concept in the mind of the
programmer by observing the actions of the circuits (even if you could
assert a strong probability to making that conclusion form some
observations).

Then your statement could be read as "Binary numerical
values that are allocated to memory addresses". This is
indeed the correct description of what happens then.

That is writing more in than I meant to say, which was only
that at that lowest level you have nothing but bit patterns
in electronic circuits.

Yes, that is correct.

Wrong. A memory address is a physical storage method on a
microchip.

No they are not, and that was not my point anyway. Conceptually
a 'block' has a magnitude in addition to a location. The address
is only a location.

No. Memory is a physically stored range of bit statusses.

Memory is not "a memory address", which is what your statement above is
about.
Say I have 2
bottles (each bottle is a bit, together they represent 1 byte).
Then I imagine that:
- 0 is the equivalent of two empty bottles
- 1 is the equivalent of a full bottle + an empty bottle
- 2 is the equivalent of an empty bottle + a full bottle
- 3 is the equivalent of two full bottles

Suppose I want to remember the value "3" ...

<snip>

I thought you didn't want to be patronising? For future reference; I
know enough about electronics to build a working computer out of valves,
relays or transistors for myself (in the very unlikely event that doing
so become necessary, given the wide availability of microchips in
general).

| Referencing and memory allocation take place when
| the browser compiles the javascript to something
| the machine understands.

- in which "the *browser* compiles the javascript to something the
machine understands" (stress added by me) is a questionable assertion
when the browser is written in Java and the javascript complied into
bytecode. It is, as you say, the JVM that produces the actual
executable code, not the browser as you asserted.

Sure, that's correct. If you have an iron with javascript
support, the iron would compile the javascript code.

Which is as worthless as a statement as saying that a computer will
compile the javascript code that is executed on it. You original stamens
related to the behaviour and actions of browsers and the javascript
implementations that they contain.

Richard.

[Bart Van der Donck]

Richard Cornford wrote:

Bart Van der Donck wrote:

Richard Cornford wrote:

Remember that you responded to the suggestion that:-

| Setting a pointer to null obviously won't delete the
| object pointed to from memory, but just change the
| address the pointer is referencing (from address of
| the object to null = 0x0000000).

- was pure speculation with the rather specific assertion
that "That is no speculation - it's just how this works",
and went on to detail the precise process of assigning a
value to a variable in javascript. These were not
generalisations about how computers work. Rather they were
generalisations about what javascript implementations do,
and you don't have the information necessary to be saying
that these things are true or (or even relevant to) all
javascript implementations.
I'ld say it's a buffering issue then.

Then I would say that you are being irrelevant.

Yes, that is irrelevant to this group.

When a variable gets a new value,

This would be a javascript variable? Something that is specified as a
property added to a dynamic object and, by implication, has both value
and type. That may make a javascript variable a structure attached in
some way to another structure, where both the structures and the nature
of their attachment are no more than possibilities that may be manifest
in the implementation, may have almost any arbitrary form and will be
influenced by the implementation language.

there are 2 possible ways:

No there are not. There is a very wide spectrum of possibilities in
implementing javascript variables.

In javascript variables, yes. Not in traditional, computer-scientific
variables. I repeatedly said I am not talking about javascript
authoring.

(1) The memory address gets populated with new bytes; or

"The memory address"? In practice hundreds of memory addresses may have
new values written to them during the creation of a javascript variable.

Yes that is almost certain, considering the generation of languages
javascript belongs to.
[...]
Computers are machines, they work quite successfully without perception
or conception.
That's correct for the machine itself (hardware). Once you leave the
byte-level, everything hangs together with conceptions and perceptions
(software).
While computers must interpret some bit patterns as memory addresses the
bit pattern is only a memory address at the point when it is used as a
memory address. In machine code there are no 'pointers', only the act of
addressing memory.
Computers do not interpret anything. They only read and write to memory
addresses (allocate/reallocate), where each bit pattern represents 1
byte, whatever that byte may further represent to the programmer.

The bits itself do not mean anything - together they
form a byte, and the byte responds to
something in the mind of the programmer.

I assume that was supposed to be 'the byte _corresponds_ to ...'.

Yes.
Which makes my point, at the very lowest level there is no meaning, and
at the javascript level the lowest level has been hidden behind a
spectrum of (largely unimportant) implementation details. Picking some
arbitrary level in-between and trying to make generalisations about
javascript is not a viable (or valuable) practice.
I am not picking out an arbitrary level, I am dealing with the lowest
level. I do not want to claim anything about any javascript
implementation, though I made an example in javascript syntax which
might have confused (where I talked about aVar = 5). I described how
the principle behaves at its lowest level, not how it might be
implemented in javascript (how could I know this ? for which javascript
implemenation would I speak then ? how would I know which other
technologies would be used inside that one specific implementation ?
which intermediary levels are still between that implemenation and the
machine ? etc.)

In my opinion, the core of this discussion is a different level where
you keep repeating how things work in javascript, and I keep repeating
how it works in computer core. What's in between those two, can only be
guessed at, or it's work for a bunch of experts that are only
specialised in their own application fields.

Above you described them as "a combination of 0's and 1's",
when there are no actual ones or zeros in the hardware. Any
bit pattern can be conceived as a representation of an integer
value.

Not directly. The traditional representation of a bit pattern
since many decades is a range holding ones and zeros.

Are you saying that ones and zeros are not intergers?

Depends how you look at them. If you consider them part of the whole
numbers (positive, negative, or zero), than the answer is yes. In
binary numerals, zeros and ones are digits, *not* integers.

It's an abstraction of course.

Yes, as is thinking about bit patterns as integers, or hex numbers. I
would say that hex was the most traditional representation of a bit
pattern.

Thinking about bit patterns in non-binary terms is one step away from
their essence. Any representation that follows the "bi-al" concept,
suits. Hexadecimals or integers are next-level representations in the
mind of the programmer.

You could think of it as a bunch of people, where males
are 0 and females 1, for example.

Why on earth would I want to do that?

Because that representation is (for example) suitable to describe the
working of bits in a byte at its most elementary level. The "bunch of
people" is a byte. Hex or integers (or whatever other non-binary
representations) originate from a higher level.
[...]
I thought you didn't want to be patronising? For future reference; I
know enough about electronics to build a working computer out of valves,
relays or transistors for myself

Depends what you define as a computer, of course :-) I don't have your
electronic background, but it's quite some claim that you could build
your own computer that way (worthy that name).

Sure, that's correct. If you have an iron with javascript
support, the iron would compile the javascript code.

Which is as worthless as a statement as saying that a computer will
compile the javascript code that is executed on it. You original stamens
related to the behaviour and actions of browsers and the javascript
implementations that they contain.

You're nitt-picking, but you're right of course. An iron can't compile,
it needs at least an OS for that. I just assumed any device supporting
javascript would have an OS.

--
Bart

[Thomas 'PointedEars' Lahn]

Bart Van der Donck wrote:

Richard Cornford wrote:

Bart Van der Donck wrote:

> Richard Cornford wrote:
>> Remember that you responded to the suggestion that:-
>>| Setting a pointer to null obviously won't delete the
>>| object pointed to from memory, but just change the
>>| address the pointer is referencing (from address of
>>| the object to null = 0x0000000).
>> - was pure speculation with the rather specific assertion
>> that "That is no speculation - it's just how this works",
>> and went on to detail the precise process of assigning a
>> value to a variable in javascript. These were not
>> generalisations about how computers work. Rather they were
>> generalisations about what javascript implementations do,
>> and you don't have the information necessary to be saying
>> that these things are true or (or even relevant to) all
>> javascript implementations.
> I'ld say it's a buffering issue then. Then I would say that you are being irrelevant.

Yes, that is irrelevant to this group.

If you can agree with that, why do you not just stop posting off topic?

> When a variable gets a new value,

This would be a javascript variable? Something that is specified as a
property added to a dynamic object and, by implication, has both value
and type. That may make a javascript variable a structure attached in
some way to another structure, where both the structures and the nature
of their attachment are no more than possibilities that may be manifest
in the implementation, may have almost any arbitrary form and will be
influenced by the implementation language.

> there are 2 possible ways:

No there are not. There is a very wide spectrum of possibilities in
implementing javascript variables.

In javascript variables, yes.

You miss the point. Richard is talking about the possibilities of the
_implementation of_ "javascript" variables (in another programming
language). (Which IMHO is *still* on-topic here.)
Not in traditional, computer-scientific variables.

Yes, there is. As I stated long before in this thread, special values in
a programming language can be implemented (usually in another, lower-level
programming language) using /any/ value or combination of values in that
implementation language that is not used otherwise for the implementation
of the other language. Implementing ECMAScript's primitive `null' value
as a NULL pointer (0x0000) in C, for example, is a possibility, not a
necessity (and it is an impossibility if the implementation is written
e.g. in Java instead of C, as Java has no concept of pointers itself).

You do not look very smart ignoring this very simple fact repeatedly, while
rambling and patronizing knowledgeable people about quite irrelevant
possible implementations of data storage in hardware. Nuff said.
PointedEars
--
Bill Gates isn't the devil -- Satan made sure hell
_worked_ before he opened it to the damned ...

[Bart Van der Donck]

Thomas 'PointedEars' Lahn wrote:

[...]
You do not look very smart ignoring this very simple fact repeatedly, while
rambling and patronizing knowledgeable people about quite irrelevant
possible implementations of data storage in hardware. Nuff said.

Play the ball, not the person, Thomas.

As a gentleman I'm offering the final word to you, Richard. If you're a
gentleman too, pls don't abuse this gesture then.

--
Bart

[Randy Webb]

Bart Van der Donck said the following on 5/26/2006 1:54 PM:

Thomas 'PointedEars' Lahn wrote:

[...]
You do not look very smart ignoring this very simple fact repeatedly, while
rambling and patronizing knowledgeable people about quite irrelevant
possible implementations of data storage in hardware. Nuff said.

Play the ball, not the person, Thomas.

That is the problem, and Thomas has shown it repeatedly. When he can't
play the ball, he turns to the person and he very seldom plays the ball.

I have been plonked and un-plonked by him so many times I call myself
the President of the "Thomas called me a Troll" club.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Matt Kruse]

Randy Webb wrote:

I have been plonked and un-plonked by him so many times I call myself
the President of the "Thomas called me a Troll" club.

If you would just read ECMA Specification version 15.43.24.5 section 5,
paragraph 4, you would know why.

Score adjusted

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[John W. Kennedy]

Lasse Reichstein Nielsen wrote:

"Bart Van der Donck" <ba**@nijlen.com> writes:

I'm not aware of any system that doesn't store RAM as binary digits,
and I'm not sure if this is überhaupt possible.

It's possible, and there were attempts in the early days of computers
to build decimal based computers. It just turned out to be too fragile.
Distinguishing between ten levels of voltage was more errorprone than
just between "on" and "off".

I believe both the Eniac and the Mark I were decimal.

The ASSC ("Mark I") was electromechanical, and used odometer-like wheels.

IBM, at least, never made a decimal computer based on voltage
differences. All IBM decimal computers used binary encodings, including:

BCD: 0000 through 1001.
Excess-3: 0011 through 1100
Biquinary: five bits, only one 1, plus two bits, only one 1
Three-of-five: five bits, three 1, and two 0

IBM mainframes still normally use decimal arithmetic for financial
calculations, although binary is used for addressing and scientific
number crunching.

One Russian computer of the 50's used ternary (base-3).

--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"

[Thomas 'PointedEars' Lahn]

Bart Van der Donck wrote:

Thomas 'PointedEars' Lahn wrote:

[...]
You do not look very smart ignoring this very simple fact repeatedly,
while rambling and patronizing knowledgeable people about quite
irrelevant possible implementations of data storage in hardware.
Nuff said.

Play the ball, not the person, Thomas.

I am playing the ball. I am criticizing (your) evading behavior in
discussions that can be perceived as trolling, as it tries to keep
off-topic discussions alive by posting irrelevant facts and later
stating them as irrelevant repeatedly, while ignoring the real facts
presented, and not having the potential to provide a noticeable gain
to anyone (learning about what is troll behavior aside).
PointedEars
--
When the power of love overcomes the love
of power, the world will know peace.
-- Jimi Hendrix