Topic
IC4NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
3 replies Latest Post - ‏2012-09-01T15:44:24Z by EliotMoss
EliotMoss
EliotMoss
17 Posts
ACCEPTED ANSWER

Pinned topic String.intern() and JVMTI FollowReferences

‏2012-08-27T01:44:40Z |
I am seeing a curious behavior and seek an explanation (or perhaps
it is a bug). In a JVMTI tool I am working on, we periodically do
FollowReferences over the whole heap (i.e., no filtering out based
on object tagging or class, and with a starting point of NULL, meaning
all heap roots). We include call backs for heap_reference_callback,
string_primitive_value_callback, and array_primitive_value_callback.
This should get us every reachable object in the heap.

What I am seeing is that some Strings returned by String.intern()
are apparently not reported by FollowReferences, though the objects
turn up again -- with the same JVMTI object tag as before -- as
involved in various calls, etc.

I have some evidence that at least some of these String objects are
names of classes.

This may require someone on the development team to answer since it
may involve deep internals ...

Regards -- Eliot Moss
Updated on 2012-09-01T15:44:24Z at 2012-09-01T15:44:24Z by EliotMoss
  • EliotMoss
    EliotMoss
    17 Posts
    ACCEPTED ANSWER

    Re: String.intern() and JVMTI FollowReferences

    ‏2012-08-27T16:37:51Z  in response to EliotMoss
    Some additional information:

    If I substitute ForceGarbageCollection followed by IterateThroughHeap,
    I do not end up with skipped existing objects. This is not surprising,
    I suppose.

    It further occurred to me that the objects in question might be only
    weakly reachable (or at least not strongly reachable), yet not actually
    garbage collected. If they are searched for again via the intern table,
    then a strong reference to the less-than-strongly-reachable object might
    be created, keeping the same object around.

    So, I wonder if FollowReferences is returning objects that are reachable
    but not strongly reachable ... Omitting such objects would require more
    work, so I suspect that FollowReferences is returning the contents of
    the referent field of Reference objects (weak objects).

    So, I continue to suspect that it is something special about either the
    String intern table or about class names in particular.

    Regards -- Eliot Moss
    • EliotMoss
      EliotMoss
      17 Posts
      ACCEPTED ANSWER

      Re: JVMTI FollowReferences ... and IterateThroughHeap

      ‏2012-08-28T17:06:46Z  in response to EliotMoss
      I now have evidence that the referent of a SoftReference is
      not being reported via IterateThroughHeap though it is still
      reachable via the SoftReference. This referent is an array
      of java/lang/Object, so is not related to String interning.
      (Of course String interning may use some flavor of Reference
      objects, so the behaviors I am seeing may be related in an
      underlying way.)

      I may be able to work around this by explicitly looking
      in the referent field of each object that inherits from
      java/lang/Reference, though that would not be "fun".

      Regards -- Eliot Moss
      • EliotMoss
        EliotMoss
        17 Posts
        ACCEPTED ANSWER

        Re: JVMTI FollowReferences ... and IterateThroughHeap

        ‏2012-09-01T15:44:24Z  in response to EliotMoss
        In my last post, I claimed that IterateThroughHeap does not
        always report every live object. Upon rather more extensive
        testing, I find that claim NOT to be supported. IterateThroughHeap
        does seem to report all the objects -- which makes perfect sense
        considering the reasonable ways to implement it.

        I will now test FollowReferences more carefully in a similar way.

        Regards -- Eliot Moss