How to get address of a Java object?

[Naresh Agarwal]

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

 

[Robert Klemme]

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

 

[jan V]

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++.

 

[Roedy Green]

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/mckinney_grills_rumsfeld.htm

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

 

[John Currier]

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

 

[Chris Uppal]

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

 

[Oliver Wong]

(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

 

[Chris Uppal]

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

 

[Jeff Schwab]

Oliver Wong wrote:




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]

When I first started using C...

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

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

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

 

[Tor Iver Wilhelmsen]

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

From the JVM spec:

3.7 Representation of Objects
The Java virtual machine does not mandate any particular internal
structure for objects.

So it's conceivable they could; using 32-bit words makes the
addressable memory four times as large as when using 8-bit words. (I
am talking about J2SE here, J2ME and JavaCard implementations would be
different.)

On the stack frame, a local variable is a 32-bit word. "long" or
"double" values occupy two local variables (JVMS §3.6.1).