Re: [cp-patches] [RFA/JDWP] IdManager
On Mon, 2005-06-20 at 13:48 -0500, Archie Cobbs wrote: Uniquely identifies a reference type in the target VM. It should not be assumed that for a particular class, the classObjectID and the referenceTypeID are the same. A particular reference type will be identified by exactly one ID in JDWP commands and replies throughout its lifetime A referenceTypeID is not reused to identify a different reference type, regardless of whether the referenced class has been unloaded. This seems to only imply that whoever is creating ReferenceTypeID's must create a new and unique one every time, not that you need to cache them after the associated class has been unloaded... ? So if a class is unloaded and then consequently reloaded, you read the above to mean that it would still get a new ID (not the old one)? I guess our interpretation of lifetime is a little different. For me, lifetime was considered the lifetime of the type within the application. For you, it's the lifetime of the class as it exists in the VM. So when it is unloaded, it's ID goes stale. I can buy that, especially given this tidbit: In any case, how is a class ever going to be unloaded if your Hashtable is referencing it? :-) TRUE! So now that mens that I'd have to use a similar strategy to what is done for objects, which we're discussing somewhere else, I think... Keith ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] [RFA/JDWP] IdManager
On Tue, 2005-06-21 at 14:08 -0500, Archie Cobbs wrote: You're definition of type then is the static (compile time type). But in Java Class objects are associated with runtime types, not compile time types. I've been confused about this before and went so far as to document it so I wouldn't get confused again: http://jcvm.sourceforge.net/share/jc/doc/jc.html#Classes%20and%20Types Aaaahhh.. Well, I did warn people that I was a relative newbie to Java! Thanks for that explanation: things make more sense now. (And hopefully I can use this new distinction to clarify what I really mean to say in future communications.) Keith ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] [RFA/JDWP] IdManager
On Mon, 2005-06-20 at 10:22 -0500, Archie Cobbs wrote: Keith Seitz wrote: + /* Mapping of class (Class) to IDs (ReferenceTypeId) for reference + types. Unlike other types, reference id types are NEVER released. */ + private Hashtable _classTable; Another question born from my own ignorance... :-) What if a class(loader)s are garbage collected? Would this hash table then become a memory leak?gets Yes, but unfortunately, JDWP specifically says that reference type IDs are never reused, even if the classes are gc'd or unloaded. The same ID is valid for any reference type for the entirety of the debugging session. Or at least that's how I interpret this explanation of referenceTypeId: Uniquely identifies a reference type in the target VM. It should not be assumed that for a particular class, the classObjectID and the referenceTypeID are the same. A particular reference type will be identified by exactly one ID in JDWP commands and replies throughout its lifetime A referenceTypeID is not reused to identify a different reference type, regardless of whether the referenced class has been unloaded. ? Keith ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] [RFA/JDWP] IdManager
Keith Seitz wrote: + /* Mapping of class (Class) to IDs (ReferenceTypeId) for reference + types. Unlike other types, reference id types are NEVER released. */ + private Hashtable _classTable; What if a class(loader)s are garbage collected? Would this hash table then become a memory leak?gets Yes, but unfortunately, JDWP specifically says that reference type IDs are never reused, even if the classes are gc'd or unloaded. The same ID is valid for any reference type for the entirety of the debugging session. Or at least that's how I interpret this explanation of referenceTypeId: Uniquely identifies a reference type in the target VM. It should not be assumed that for a particular class, the classObjectID and the referenceTypeID are the same. A particular reference type will be identified by exactly one ID in JDWP commands and replies throughout its lifetime A referenceTypeID is not reused to identify a different reference type, regardless of whether the referenced class has been unloaded. This seems to only imply that whoever is creating ReferenceTypeID's must create a new and unique one every time, not that you need to cache them after the associated class has been unloaded... ? In any case, how is a class ever going to be unloaded if your Hashtable is referencing it? :-) -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
