«

Hi

Is there a way to get address of a Java object?
I believe hashCode function in Object class do gives the object
reference, but this is specific to JVM implementation.

thanks,
Naresh Agarwal

Naresh Agarwal wrote:
> Hi
>
> Is there a way to get address of a Java object?
> I believe hashCode function in Object class do gives the object
> reference, but this is specific to JVM implementation.

What do you need that for? In Java, the reference is all you get - and
all you need. Note that physical memory locations might change due to GC
activity.

Regards

robert

> Is there a way to get address of a Java object?

No. Java's designers have quite consciously abstracted machine addresses out
of the picture to eliminate a whole class of pointer-related errors which
were/are common in C++.

On 10 Aug 2005 04:47:53 -0700, "Naresh Agarwal"
<> wrote or quoted :

>Is there a way to get address of a Java object?

toString sometimes gives it to you.
I'd look in the debugging stuff. For normal Java, the address is
supposed to be irrelevant.

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/...s_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

Roedy Green wrote:
> On 10 Aug 2005 04:47:53 -0700, "Naresh Agarwal"
> <> wrote or quoted :
>
> >Is there a way to get address of a Java object?
>
> toString sometimes gives it to you.

I'm surprised to hear you say that Roedy. If nobody's overloaded
toString() then the implementation in Object will dump the object's
hash code. It does have an @ in the generated string that could
possibly imply an address, but there's nothing that says it's an
address...especially when you consider Robert Kelmme's comment about
the object potentially being moved by the garbage collector.

Some of the debugging stuff that you mentioned probably would make the
addresses available. Another option would be to make some funky JNI
calls that give you the object's address, but then it can always move
unless you lock it down or do some interesting callbacks.

John
http://schemaspy.sourceforge.net

John Currier wrote:

> Another option would be to make some funky JNI
> calls that give you the object's address, but then it can always move
> unless you lock it down or do some interesting callbacks.

Not even via JNI. JNI doesn't hand out objects' addresses, only "handles" that
can be used to refer to them.

Incidentally, besides the possibility of objects moving in memory, another
reason not to hand out their addresses ever (through /any/ interface) is that
the concept of "the address" is not well-defined. It assumes that objects are
stored in contiguous storage, and that is by no means guaranteed. (I can think
of at least two good reason why a VM designer might decide to "split" objects,
although as far as I'm aware, the major JVM providers have, in fact, chosen to
use a contiguous representation.)

-- chris

"Chris Uppal" <> wrote in message
news:42fb058b$0$38040$.. .
> (I can think
> of at least two good reason why a VM designer might decide to "split"
> objects,
> although as far as I'm aware, the major JVM providers have, in fact,
> chosen to
> use a contiguous representation.)

Out of curiosity, can you state these reasons? All I can think of is
issues with RMI.

- Oliver

Oliver Wong wrote:

> > (I can think
> > of at least two good reason why a VM designer might decide to "split"
> > objects,
> > although as far as I'm aware, the major JVM providers have, in fact,
> > chosen to
> > use a contiguous representation.)
>
> Out of curiosity, can you state these reasons? All I can think of is
> issues with RMI.

What I had in mind:

Some GC-ed languages use an object representation where the "object" is split
into a header of, say, 8 to 16 bytes, which itself contains a pointer to the
body, where the object's non-static fields, etc, are stored. This permits
easier implementation of moving GC, and has other benefits for languages with
less crippled semantics than Java (e.g. dynamic resizing of objects, or
Smalltalk's #become: operation).

There has been some research on the benefits of splitting objects so that their
frequently used fields are stored separately from their less frequently used
ones. That has the benefit that more of the /useful/ data will fit into the
data caches (on-chip, or wherever) so the program on the whole may run faster
(at the cost that infrequently used fields take longer to access).

It may be worth splitting large arrays into "pages"; memory fragmentation can
be avoided by ensuring that there is a single, fixed, maximum size of any
allocation.

Incidentally, any/all the above might have greater benefit on a JVM designed to
make best use of a loosely-coupled multi-CPU architecture. (Though whether it
would be actually /worth/ the effort of creating a special implementation for
such an application is a different question). You point about RMI may reflect
the same thinking -- if you can split an object so that you don't have to copy
/all/ of the object's state in order to use /any/ of its state, then you may
see a nett gain.

-- chris

Chris Uppal wrote:
> Oliver Wong wrote:
>
>
>>>(I can think
>>>of at least two good reason why a VM designer might decide to "split"
>>>objects,
>>>although as far as I'm aware, the major JVM providers have, in fact,
>>>chosen to
>>>use a contiguous representation.)
>>
>> Out of curiosity, can you state these reasons? All I can think of is
>>issues with RMI.
>
>
> What I had in mind:
>
> Some GC-ed languages use an object representation where the "object" is split
> into a header of, say, 8 to 16 bytes, which itself contains a pointer to the
> body, where the object's non-static fields, etc, are stored. This permits
> easier implementation of moving GC, and has other benefits for languages with
> less crippled semantics than Java (e.g. dynamic resizing of objects, or
> Smalltalk's #become: operation).
>
> There has been some research on the benefits of splitting objects so that their
> frequently used fields are stored separately from their less frequently used
> ones. That has the benefit that more of the /useful/ data will fit into the
> data caches (on-chip, or wherever) so the program on the whole may run faster
> (at the cost that infrequently used fields take longer to access).
>
> It may be worth splitting large arrays into "pages"; memory fragmentation can
> be avoided by ensuring that there is a single, fixed, maximum size of any
> allocation.
>
> Incidentally, any/all the above might have greater benefit on a JVM designed to
> make best use of a loosely-coupled multi-CPU architecture. (Though whether it
> would be actually /worth/ the effort of creating a special implementation for
> such an application is a different question). You point about RMI may reflect
> the same thinking -- if you can split an object so that you don't have to copy
> /all/ of the object's state in order to use /any/ of its state, then you may
> see a nett gain.

When I first started using C, it was not uncommon to group data
according to type so one wouldn't waste "padding" bytes necessary for
alignment. For example:

struct S {
char c; /* OK, arbitrary address. */

/* Often three bytes of padding required
* here to provide for proper alignment of int.
*/

int i; /* Requires special alignment. */
};

An array of 1000 such structs might waste 3KB. It seemed more efficient
to break the data into two arrays: One of 1000 chars, and another of
1000 ints. Each "struct" was then retrieved by a single index that
related locations in the multiple arrays.

I don't know whether this technique is ever used by Java implementations.

Jeff Schwab wrote:

> When I first started using C...

> struct S {
/* ... */
> };

Whoops! Too much C++. Should have said:

typedef struct { /* ... */ } S;