How to get address of a Java object?

Discussion in 'Java' started by Naresh Agarwal, Aug 10, 2005.

  1. 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, Aug 10, 2005
    #1
    1. Advertising

  2. 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
     
    Robert Klemme, Aug 10, 2005
    #2
    1. Advertising

  3. Naresh Agarwal

    jan V Guest

    > 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++.
     
    jan V, Aug 10, 2005
    #3
  4. Naresh Agarwal

    Roedy Green Guest

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

    Canadian Mind Products, Roedy Green.
    See http://mindprod.com/iraq.html photos of Bush's war crimes
     
    Roedy Green, Aug 10, 2005
    #4
  5. Naresh Agarwal

    John Currier Guest

    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, Aug 11, 2005
    #5
  6. Naresh Agarwal

    Chris Uppal Guest

    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, Aug 11, 2005
    #6
  7. Naresh Agarwal

    Oliver Wong Guest

    "Chris Uppal" <-THIS.org> 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, Aug 12, 2005
    #7
  8. Naresh Agarwal

    Chris Uppal Guest

    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, Aug 13, 2005
    #8
  9. Naresh Agarwal

    Jeff Schwab Guest

    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, Aug 13, 2005
    #9
  10. Naresh Agarwal

    Jeff Schwab Guest

    Jeff Schwab wrote:

    > When I first started using C...


    > struct S {

    /* ... */
    > };


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

    typedef struct { /* ... */ } S;
     
    Jeff Schwab, Aug 13, 2005
    #10
  11. Jeff Schwab <> writes:

    > 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).
     
    Tor Iver Wilhelmsen, Aug 14, 2005
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    3
    Views:
    324
    Grizlyk
    Feb 10, 2007
  2. bob the builder
    Replies:
    15
    Views:
    467
    Richard Herring
    Jan 24, 2008
  3. Replies:
    5
    Views:
    341
    James Mills
    Oct 24, 2008
  4. blackbiscuit
    Replies:
    12
    Views:
    1,370
    blackbiscuit
    May 13, 2009
  5. xeon123 mailinglist

    get object by hexadecimal address in jstack

    xeon123 mailinglist, Aug 10, 2011, in forum: Java
    Replies:
    0
    Views:
    248
    xeon123 mailinglist
    Aug 10, 2011
Loading...

Share This Page