Hi,
If my memory serves me right, in one of the threads some months back I remember jverd telling "No, reference variables are not pointer" and _uj remarking "You are a real smartie!" in reply. If thats true how can a reference variable not be a pointer, shudn't it be holding the heap address of the Object?
Thank you,
Amnesiac.
> If my memory serves me right, in one of the threads some months
> back I remember jverd telling "No, reference variables are not pointer"
> and _uj remarking "You are a real smartie!" in reply. If thats true how
> can a reference variable not be a pointer, shudn't it be holding the
> heap address of the Object?
It *could* be a pointer to the real object value in the heap. It could also
be a pointer/index in a pool of pointers pointing to values on the heap.
They're definitely *not* the objects themselves and because nothing
else is said about those thingies Java prefers to call them references.
kind regards,
Jos (< prefers to call them pointers too ;-)
> shudn't it be holding the heap address of the Object?
Not necessarily. There may be other indirections between the content of a reference variable and the object's physical address. The VM spec refers to these values as "handles".
Also, the term "pointer" is overloaded. The JLS and VM spec speak of reference values as "pointers", but some definitions I've seen of "pointer" require the ability to perform pointer arithmetic, which isn't available in Java.
Also... at this level of a technical discussion it's probably necessary to point out that a variable isn't a pointer in Java. A variable is a location that stores a value. The value may be a pointer, but the variable is just a storage space.
~
The VM spec does not define how references are to be implemented. A reference could, in principle, be implemented as a simple pointer to the object. I would expect that it's usually more complicated than that.
For instance, I know that some recent Sun VM (1.5, I think) implements it as a pointer to a structure that holds two pointers--one to the class and one to the object. Or something to that effect.
In most contexts, however, you can view a reference as simply "a pointer to the object."
As for wnat embla/uj says, you can ignore most of it. She used to be helpful, but these days is primarily interested in insulting people, trying to appear clever, and stroking her fragile, overblown ego.
> I guess the common answer is that it is not truly a
> pointer because it does not allow pointer arithmatic.
> You can two things with references in java: assign
> to them, and dereference them.
I am not talking about reference variables as we can use it in a Java program. I thought jverd was talking about reference variables under the hood, if that is the case how can a reference variable be implemented without it being a native pointer? Just a plain variable having the heap address of the object? In that case wudn't that variable qualify to be a pointer, though pointer arithmetic may not be used underneath?
Thank you very much,
Amnesiac.
> > shudn't it be holding the heap address of the
> Object?
>
> Not necessarily. There may be other indirections
> between the content of a reference variable and the
> object's physical address. The VM spec refers to
> these values as "handles".
>
> Also, the term "pointer" is overloaded. The JLS and
> VM spec speak of reference values as "pointers", but
> some definitions I've seen of "pointer" require the
> ability to perform pointer arithmetic, which isn't
> available in Java.
>
> Also... at this level of a technical discussion it's
> probably necessary to point out that a variable isn't
> a pointer in Java. A variable is a location that
> stores a value. The value may be a pointer, but the
> variable is just a storage space.
oh yeah! thats right the JVM could be using handles, but still the reference variable wud be holding the address of the Handle?
Thanks,
Vinay.
> if that is the case how can a reference variable be implemented
> without it being a native pointer?
Under the hood, a reference variable is a storage location. The value it contains may be implemented as a native pointer, but that is not required.
> In that case wudn't that variable qualify to be a
> pointer, though pointer arithmetic may not be used
> underneath?
Depends on your definition of "pointer". The JLS would say yes; others (those whom require p-arithmetic as an integral part of the definition) would be inclined to say no.
Pick your camp.
~
> oh yeah! thats right the JVM could be using handles,
> but still the reference variable wud be holding the
> address of the Handle?
Not necessarily. That level of detail is not defined by the VM spec. It's an implementation detail that is largely irrelevant.
~
> I am not talking about reference variables as we can
> use it in a Java program. I thought jverd was talking
> about reference variables under the hood, if that is
> the case how can a reference variable be implemented
> without it being a native pointer? Just a plain
> variable having the heap address of the object? In
> that case wudn't that variable qualify to be a
> pointer, though pointer arithmetic may not be used
> underneath?
Could be, but take a look at what Jos, Jverd, and Yawmark have said about the possibility of other indirection that could be involved. It could, in fact, be an object, or struct, or record, or whatever (depending on the language the jvm is implemented in) that contains what you would consider a pointer.
> > I guess the common answer is that it is not truly
> a
> > pointer because it does not allow pointer
> arithmatic.
> > You can two things with references in java:
> assign
>to them, and dereference them.
>
> > - Adam
>
> And compare them for equality.
And make them point to null(NULL in C). But apparently NULL prints the pointer address as 0.
> oh yeah! thats right the JVM could be using handles,
> but still the reference variable wud be holding the
> address of the Handle?
The reference variable could be holding any number of things:
* The memory address of the object.
* The adress of some other structure as I desribed above.
* The index into a table of some sort.
* An offset from some base address.
* The address of the address of the address of something that holds the memory address of the object.
* A file hande to a disk file that stores the current state of the object.
* Any number of other things.
Note that, while not all of those make sense, the point is that we don't care. All that matters--as per the spec--is that the reference hold *some* value that can be used to uniquely identify that object to the VM. How the VM interprets that value is completely unspecified.
> For instance, I know that some recent Sun VM (1.5, I
> think) implements it as a pointer to a structure that
> holds two pointers--one to the class and one to the
> object. Or something to that effect.
I thought that was a pretty old stratergy. If I am right that pointer to the class data eases referencing the method tables.
Thanks,
Amnesiac.
> > > I guess the common answer is that it is not
> truly
> > a
> > > pointer because it does not allow pointer
> > arithmatic.
> > > You can two things with references in java:
> > assign
> >to them, and dereference them.
> >
> > > - Adam
> >
> > And compare them for equality.
>
> And make them point to null(NULL in C). But
> apparently NULL prints the pointer address as 0.
Assigning null to them comes under "assigning" as originally mentioned. They don't "point to" null. Null is a special value that the reference *holds*. It may very well be zero in a given VM, but its value is not part of the spec. Different VMs can implement null differently.
> > > > I guess the common answer is that it is not
> > truly
> > > a
> > > > pointer because it does not allow pointer
> > > arithmatic.
> > > > You can two things with references in java:
> > > assign
> > >to them, and dereference them.
> > >
> > > > - Adam
> > >
> > > And compare them for equality.
> >
> > And make them point to null(NULL in C). But
> > apparently NULL prints the pointer address as 0.
>
> Assigning null to them comes under "assigning" as
> originally mentioned. They don't "point to" null.
> Null is a special value that the reference *holds*.
> It may very well be zero in a given VM, but its value
> is not part of the spec. Different VMs can implement
> null differently.
There you go, you stole the words from my mouth.
Thanks,
Amnesiac.
> > And make them point to null (NULL in C).
>
> Not quite. The null reference points no object. There
> is no "pointing to null". A reference variable may
> contain the null reference.
>
> ~
What i intended to say there was that i feel there can be no analogy set when it comes to setting a pointer to null value in c and setting a reference to null, as even assigning a pointer to NULL makes it point to 0 in c.
> > I thought that was a pretty old stratergy.
>
> If you knew that already, then I'm confused why you
> asked, "shudn't it be holding the heap address of the
> Object?"
The word 'handle' made me remember some things which I had forgotten, if you dont beleive me my nick should be convincing enough.
Thanks,
Vinay.
>
> * Any number of other things.
>
A mangled thingy that holds some sort of address/index and some bits that represent something else (one has to mask the bits to use the address/index.)
In 1.4 Sun VM that was exactly what it was. Hard to say what the address/index was (type) or even what it pointed to. By the time I tracked it to that point my interest level had gone down signficantly.
> What i intended to say there was that i feel there
> can be no analogy set when it comes to setting a
> pointer to null value in c and setting a reference to
> null, as even assigning a pointer to NULL makes it
> point to 0 in c.
Assigning the null reference to a reference variable in Java stores a value in that variable. I don't see why you can't draw such an analogy with C, aside from the fact that we typically don't know (and don't have any need to know) what that value for a particular VM is.
~
> > What i intended to say there was that i feel
> there
> > can be no analogy set when it comes to setting a
> > pointer to null value in c and setting a reference
> to
> > null, as even assigning a pointer to NULL makes it
> > point to 0 in c.
>
> Assigning the null reference to a reference variable
> in Java stores a value in that variable. I don't see
> why you can't draw such an analogy with C, aside from
> the fact that we typically don't know (and don't have
> any need to know) what that value for a particular VM
> is.
>
> ~
I sure haven't read anywhere what that null value actually is!
> > I sure haven't read anywhere what that null value
> > actually is!
>
> I vaguely remember the JLS or the JVm spec saying
> that '0' can be one of its posible values, as jverd
> pointed out earlier.
>
> Amnesiac.
As in C! Possible is somewhat vague
> I sure haven't read anywhere what that null value actually is!
...
> I vaguely remember the JLS or the JVm spec saying that '0' can be one of its posible values, as jverd pointed out earlier.
The value of null is not specified by Java.
[url=http://java.sun.com/docs/books/jvms/second_edition/html/Overview.doc.html#15127]The VM Spec, 3.4[/url]
The Java virtual machine specification does not mandate a concrete value encoding null.
~
> > > I sure haven't read anywhere what that null
> value
> > > actually is!
> >
> > I vaguely remember the JLS or the JVm spec saying
> > that '0' can be one of its posible values, as
> jverd
> > pointed out earlier.
> >
> > Amnesiac.
>
> As in C! Possible is somewhat vague
Yup, I concur. The value could be anything, '0' is just one of them. Are you trying to say that the 'null' does not have any value at all?
Amnesiac.
> > > I guess the common answer is that it is not
> truly
> > a
> > > pointer because it does not allow pointer
> > arithmatic.
> > > You can two things with references in java:
> > assign
> >to them, and dereference them.
> >
> > > - Adam
> >
> > And compare them for equality.
>
> And make them point to null(NULL in C). But
> apparently NULL prints the pointer address as 0.
Isn't that the same as assignment?
> > > And make them point to null (NULL in C).
> >
> > Not quite. The null reference points no object.
> There
> > is no "pointing to null". A reference variable may
> > contain the null reference.
> >
> > ~
>
> What i intended to say there was that i feel there
> can be no analogy set when it comes to setting a
> pointer to null value in c and setting a reference to
> null, as even assigning a pointer to NULL makes it
> point to 0 in c.
I'm not expert in c, but I thought that the exactly value of null was technically unspecified in c, and that 0 is simply the common convention?
In C, the NULL pointer is defined to be exactly 0:
http://c-faq.com/null/index.html
Especially
http://c-faq.com/null/macsochange.html
Even if the underlying OS or architecture has a different value for an
invalid pointer (let's say 0xCFF), then the C compiler has to generate
code that maps 0 to 0xCFF.
So in C, NULL *is* 0. Even if the hardware uses a bit value that is not all "off" bit.
> I have no idea what I did to draw the ire of embla...
Failure to pledge fealty and preach "Teh Gospel of Ulrika", apparently. Don't lose any sleep over it. She's an annoyance, albeit enough of one to make this forum worth visiting only on occasion for me. Be prepared for lots of stalking.
~
> > What i intended to say there was that i feel
> there
> > can be no analogy set when it comes to setting a
> > pointer to null value in c and setting a reference
> to
> > null, as even assigning a pointer to NULL makes it
> > point to 0 in c.
>
> Assigning the null reference to a reference variable
> in Java stores a value in that variable. I don't see
> why you can't draw such an analogy with C, aside from
> the fact that we typically don't know (and don't have
> any need to know) what that value for a particular VM
> is.
>
> ~
And that, as far as I know, the C language doesn't prohibit 0 being a valid address. Most hardware architectures do though, I think.
But in terms of how it's used--as a value to indicate that this pointer or reference doesn't point to anything--I would say that Java's null is quite analogous to C's. (I don't even recall if "null" is a part of the C language or just usually #defined to 0.)
> Hi yawmark. I have no idea what I did to draw the ire
> of embla, but it's really rather insulting.
I know what you mean. I'd *hate* to be compared to yawmark. His predilection for goats dressed up as donkeys is almost as disturbing as his unwillingness to blindly accept everything embla says as gospel truth.
;-P
> > I have no idea what I did to draw the ire of embla...
>
> Failure to pledge fealty and preach "Teh Gospel of Ulrika",
> apparently. Don't lose any sleep over it. She's an annoyance, albeit
> enough of one to make this forum worth visiting only on occasion for
> me. Be prepared for lots of stalking.
Perhaps she has more in store than just stalking?
http://www.tarotforum.net/showthread.php?t=61412
> In C, the NULL pointer is defined to be exactly 0:
> http://c-faq.com/null/index.html
> Especially
> http://c-faq.com/null/macsochange.html
>
> Even if the underlying OS or architecture has a
> different value for an
> invalid pointer (let's say 0xCFF), then the C
> compiler has to generate
> code that maps 0 to 0xCFF.
> So in C, NULL *is* 0. Even if the hardware uses a bit
> value that is not all "off" bit.
This is stated in a confusing manner although the link makes it clearer.
A 'null' (lower case) pointer is zero. And one can use an expression with "0" (zero) value to create a null pointer value.
However 'NULL' (upper case) does not have to be "0". The link specifically notes that it can be "((void *)0)". This would be because NULL is a macro.
> This is stated in a confusing manner although the
> link makes it clearer.
> ...
> However 'NULL' (upper case) does not have to be "0".
> The link specifically notes that it can be "((void *)0)"
Yes, I was not clear enough.
I meant that the value is guaranteed to not be 1, 2, or any other value.
That the numeric value is exactly 0.
But it can certainly be ((void*)0).
