|
|||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
SUMMARY: INNER | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
java.lang.Object | +--jde.debugger.ObjectStore
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 #m_objectMap
, mapped to the id that
will identify this object. This id is the ObjectReference.uniqueID().
XXX - I am not really sure if the below argumentation is really correct. The store is definitely needed to look up what object corresponds to a given unique id. And having a reference to the object stored there means it will not be garbage collected. But why make such a fuss about it? Something to think about, I could be missing something. / Petter
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
XXX The below stuff is another aspect of the ObjectStore that
appears to be unnecessarily complicated. It is currently not
active, since there is no call to the method trim(java.util.List)
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 #m_maximumLimit
.
Objects keep getting added to the list, until we
reach #m_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 #m_objectMap
is scanned and entries
not in this list removed. #m_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
Constructor Summary | |
ObjectStore(Debugger debugger)
Create a new object map for a new process. |
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 an object. |
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, toString, wait, wait, wait |
Constructor Detail |
public ObjectStore(Debugger debugger)
Method Detail |
public void put(com.sun.jdi.ObjectReference ref)
public void trim(java.util.List objectIDs)
XXX - this method is never called, currently! Also, I would say it's unnecessary, since a debugging session is usually pretty short and involves less than a couple of hundred commands from Emacs. And that in term means that there won't be more than a couple of thousand objects or so in the map, which should be OK. / Petter
public com.sun.jdi.ObjectReference get(java.lang.Object id)
|
|||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
SUMMARY: INNER | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |