Overview | Package | Class | Tree | Deprecated | Index | Help
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: INNER | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

## jde.debugger
Class ObjectStore

    java.lang.Object
      |
      +--jde.debugger.ObjectStore

public class ObjectStore
extends java.lang.Object
implements Protocol

ObjectStore.java

The main function of this class is to keep a store of all the currently referenced objects. Any time jdebug sends an object ID across, it stores the ObjectReference itself in `objectMap`, mapped to the id that will identify this object. This id is the ObjectReference.uniqueID().

We need to do this because if we don't keep a link to the ObjectReference somewhere, it might get garbage collected, and the id used to identify it (ie the uniqueID) reused. If the user then requests info about that ID, he'll be sent information about the new object, which is obviously wrong.

When jde wants to know more about the object, it sends across the id, which is used to reference the ObjectReference in the Map

Since this is done with each object that's ever reported to jde, the list can get pretty huge, and needs to be refreshed from time to time. For this purpose, we maintain the variable `maximumLimit`.

Objects keep getting added to the list, until we reach `maximumLimit`. At this point, a notification is sent to the jde side requesting for a list of all the object references (ie, the ids) that it is currently interested in.

When this list is obtained, the `objectMap` is scanned and entries not in this list removed. `maximumLimit` is then set to 2 times the current size of the list, or the old maximumLimit, whichever is larger. This is to ensure we don't keep sending the request over and over again very frequently.

Note that we keep adding objects to the Map even after sending the notification to jde: any reducing the size of the list is only done when jde responds.

Note: Question: Should we disable garbage collection of objects in the debugee VM once we put their corresponding ObjectReference in the debugger VM in the objectstore? And maybe enable the gc once they're removed from the store? This way we'll never get the ObjectCollected exception, and we can use the object as long as its displayed on the emacs side. The only thing is, we'd need the emacs side to be pretty frequent about the list of things it is displaying so we don't encumber the debuggee VM too much with objects it's unable to collect.

Created: Thu Jul 29 10:38:06 1999

Since:
  0.1

Field Summary
`(package private) Application` | `app` my very own application!
`private long` | `maximumLimit` maximum number of objects before we send a notification to jde
`private java.util.Map` | `objectMap` maps object_id -> ObjectReference
`private boolean` | `requestPending` keep track of if our request has been met yet

Fields inherited from interface jde.debugger.Protocol
`ATTACH_SHMEM, ATTACH_SOCKET, BR, BREAK, CANCEL_TRACE_CLASSES, CANCEL_TRACE_METHODS, CANCEL_TRACE_THREADS, CLEAR, COMMAND_ERROR, COMMAND_RESULT, CONNECTED_TO_VM, DEBUG, ERROR, EVALUATE, EVENT_BREAKPOINT_HIT, EVENT_CLASS_PREPARE, EVENT_CLASS_UNLOAD, EVENT_EXCEPTION, EVENT_METHOD_ENTRY, EVENT_METHOD_EXIT, EVENT_OTHER, EVENT_STEP_COMPLETED, EVENT_THREAD_DEATH, EVENT_THREAD_START, EVENT_VM_DEATH, EVENT_VM_DISCONNECT, EVENT_VM_START, EVENT_WATCHPOINT_HIT, EVENTSET, EXIT, FINISH, GET_ARRAY, GET_LOADED_CLASSES, GET_LOCALS, GET_OBJECT, GET_OBJECT_MONITORS, GET_PATH_INFORMATION, GET_STRING, GET_THREAD, GET_THREADS, INTERRUPT, INVALID, JDE_BUG, JDE_INIT_DEBUG_SESSION, KILL_THREAD, LAUNCH, LISTEN_SHMEM, LISTEN_SOCKET, MESSAGE, QUIT, REPORT_IDS_IN_USE, RESUME, RUN, SPEC_RESOLVED, STEP, SUSPEND, TRACE_CLASSES, TRACE_EXCEPTIONS, TRACE_METHODS, TRACE_THREADS, WARNING, WATCH`

Constructor Summary
`ObjectStore(Application app)` Create a new object map for a new application

Method Summary
`com.sun.jdi.ObjectReference` | `get(java.lang.Object id)` Returns the object corresponding to the id, or null
`void` | `put(com.sun.jdi.ObjectReference ref)` Register that an object is being sent to the jde side
`void` | `trim(java.util.List objectIDs)` jde sent us a list of objects it is currently interested in.

Methods inherited from class java.lang.Object
`, clone, equals, finalize, getClass, hashCode, notify, notifyAll, registerNatives, toString, wait, wait, wait`

Field Detail

### app

    final Application app

  my very own application!

### objectMap

    private java.util.Map objectMap

  maps object_id -> ObjectReference

### maximumLimit

    private long maximumLimit

  maximum number of objects before we send a notification to jde

### requestPending

    private boolean requestPending

  keep track of if our request has been met yet

Constructor Detail

### ObjectStore

    public ObjectStore(Application app)

  Create a new object map for a new application

Method Detail

### put

    public void put(com.sun.jdi.ObjectReference ref)

  Register that an object is being sent to the jde side

### trim

    public void trim(java.util.List objectIDs)

  jde sent us a list of objects it is currently interested in. Trim objectMap based on this list

### get

    public com.sun.jdi.ObjectReference get(java.lang.Object id)

  Returns the object corresponding to the id, or null

Overview | Package | Class | Tree | Deprecated | Index | Help
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: INNER | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD