#37 Monitor Handles

open
nobody
None
5
2003-06-11
2003-06-11
Joe Rybacki
No

I've looked around on the internet, but haven't been
able to find tool for monitoring Handles. Handle leaks
are prevalent when there are memory leaks, Thread
leaks, JNI calls, etc. It would be nice if Handle Counts
could be traced to the method that allocated them.

Discussion

  • Logged In: YES
    user_id=333751

    Sorry, I don't understand. What is "handle" in Java?

     
  • Joe Rybacki
    Joe Rybacki
    2003-06-12

    Logged In: YES
    user_id=792994

    Handles are references to OS objects, sockets, threads,
    Registry Items, DLL's etc. Every time sockets are opened
    they have to be closed properly otherwise the reference is
    dangling and the OS can't clean them up. Java doesn't have
    a cleaning mechanism for these handles b/c java is not
    responsible for them. Native calls are made, whether through
    JVM Implementations, or external JNI/JDBC calls. The problem
    is that pinpointing handle allocations is difficult and therefore
    insuring clean code is hard. A handle leak is not always fatal
    for an application, but it can cause system instability,
    performance degradation, and slight losses of memory outside
    of the JVM. The handles are ultimately freed by a JVM
    restart, but other than that, it's up to the API Client to free
    the References, ie. Socket.close() not mysocket=null; Hope
    this helps, let me know if you have any more questions.

     
  • Joe Rybacki
    Joe Rybacki
    2003-06-12

    Logged In: YES
    user_id=792994

    Handles are references to OS objects, sockets, threads,
    Registry Items, DLL's etc. Every time sockets are opened
    they have to be closed properly otherwise the reference is
    dangling and the OS can't clean them up. Java doesn't have
    a cleaning mechanism for these handles b/c java is not
    responsible for them. Native calls are made, whether through
    JVM Implementations, or external JNI/JDBC calls. The problem
    is that pinpointing handle allocations is difficult and therefore
    insuring clean code is hard. A handle leak is not always fatal
    for an application, but it can cause system instability,
    performance degradation, and slight losses of memory outside
    of the JVM. The handles are ultimately freed by a JVM
    restart, but other than that, it's up to the API Client to free
    the References, ie. Socket.close() not mysocket=null; Hope
    this helps, let me know if you have any more questions.

     
  • Logged In: YES
    user_id=333751

    Ok, I understand. Look as really usefull feature.
    Yes, I have questions.
    Do you know, how to implement this? ;-)

    It seems, that this is already not Java profiler task, but OS leak detector. And of course this requires big amount of system dependent code. I can try to implement this feature for Win32, but this is low priority task.

    I think, that I will implement only sockets and files tracking. If you see, that I missed some usefull system object type, describe which and why.

     
  • Joe Rybacki
    Joe Rybacki
    2003-06-16

    Logged In: YES
    user_id=792994

    Yeah, a big piece of this is JNI System object handles. I'm
    not so sure how to monitor these, except if the profiler
    provides some hooks to the JNI Interface. Even if you can't
    grab specific places, maybe doing a system handle delta
    across a method call could split it down, eg.
    //handle count=0
    myFunction();
    //handle count=4
    //I lost 4 handles in that method
    if handle deltas could be tracked down to the method call this
    would be infinitely useful. The most detail possible is of
    course the best. But this could at least pinpoint handle loss
    outside of sockets/files. Unfortunately, I don't know how to
    monitor these types of problems, I only know how to resolve
    them once I find them :)