Bart said:
Richard said:
[...]
Browsers are not the only software that executes javascript
code, and you don't know how it is done in 'a browser', or
anywhere else, in general. You can only examine how it is
done in specific implementations, and cannot validly
generalise beyond that. When you are thinking about this
remember that there is at least one javascript
implementation written in javascript.
It doesn't matter where, when, how, at what time, by whatever
intermediary applications, by what compiler, by who, by what
language, on which computer, etc. the compilation was done.
The result on _any_ computer is _always_ the storage of the
data as a combination of 0's and 1's into memory addresses.
That _can_ be generalized.
And the result is so general that it is utterly trivial. Hardly worth
saying at all.
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.
This is totally wrong. At its basic level, _any_ computer works
with pointers, binary numeric data and memory addresses.
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.
What's that, "integers loaded into data" ?
Data registers, as in data registers and address reregisters, etc.
(where etc. may be, for example, the program counter).
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.
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.
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.
that is what happens, but there is little point stating it.
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.
And what is that next step then ? -> Something the machine
understands!
)
The intermediate steps (eg JVM) are not important,
You said:-
| 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.
And preceding that with "memory allocation take place when ..." is also
questionable as memory allocation may not happen at that point, or not
entirely happen at that point, some of it may be happening later, when
the JVM creates the executable code, or when that code is actually
executed. The language that the browser and javascript interpreter are
written in can make a great deal of difference to where and when memory
allocation may happen. You just don't have the information to generalise
about what a browser may do internally, or when it may do it.
in the end javascript will always be compiled to
machine code.
That is not necessarily true. The most that can be said is that
executing javascript involves executing machine code, but that is also
too trivial to be worth saying.
You can't execute
javascript without a computer, right ?
That is precisely why the above is trivial.
In analogy, you can't use
memory if you have no physical place to store it.
err?
That might be the javascript way of presenting 'null'.
If you are assigning null in javascript it is what null is in javascript
(and what it is not) that is significant.
But, after compilation, 'null' certainly refers to an
existing memory address.
Null does not have to be implemented as the sort of thing that refers at
all.
How else could a machine know what 'null' is ?
The machine doesn't have to care, only the implementation software needs
to have an attitude about how null is implemented.
It's just a numeric reference. It has no further
importance here.
I see. It might be the javascript presentation of 'null'.
Your mistake here is assuming that null must necessarily have s specific
concrete manifestation. Javascript only requires that null be an
implemented concept, and so it can have any manifestation that the
implementers likes.
Wrong. Memory allocation always happens, independent of
any OS.
Machine code is capable of addressing any location made available in the
hardware, at any time. The concept of reserving, allocating and freeing
areas in memory needs to be implemented by a programmer, it is not
inherent in machine code.
An OS instructs the memory allocation, yes. But it's the
machine that keeps the data available for future reference.
But the hardware does not prevent any machine code from writing to any
memory at any time. That level of control of memory access is something
that is programmed as a layer above the hardware, and usually that
program is a fundamental aspect of the OS.
No OS or application can keep
data for you.
The OS can, and usually does, impose the control over which software
uses which memory, when and how.
C'mon Richard, you're a smart guy. We're just talking
about different levels here, that's all.
We are supposed to e talking about javascript here, so your
generalisations about the behaviour of javascript interprets and web
browsers pitched at a level below the javascript implementation, are
inappropriate, irrelevant, and probably wrong due to the freedom
allotted to the implementers to achieve the required behaviour in any
way the want.
I'ld say you are thinking "from the top level" (looking
down from javascript to memory) and I am thinking from the
other direction.
Looking down it is possible to see that the possible permutations
multiply so rapidly at the implementation level that it cannot be
possible to declare a single outcome at the lowest level without that
outcome being so trivial that it has no relevance to the actual writing
of javascript code. That also makes it obvious that starting at the
lowest level with any specific scheme cannot lead back up to any
generalisations about javascript.
The bottom line is that it doesn't matter what null may actually be,
just that assigning null to a variable that previously was the only
reference to an object will result in there being no accessible
references to the object remaining in the system. So that object then
becomes available for automated garbage collection, which may happen at
any subsequent point but should result in resources consumed by the
object becoming available again (in some sense).
Richard.