Aleksey, Thanks for the answers, please see inline.
On 10/26/06, Aleksey Ignatenko <[EMAIL PROTECTED]> wrote:
>Rana, >- One example is Eclipse, when you build something with ant. E.g. building >kernel classes with ant in Eclipse will create separate class loader every >time developer performs build operation, so it means that sources rebuilding >will initiate VM native memory accumulation (memory leaks: class related >data, JIT code and so on) on Eclipse.
This sounds like an Eclipse bug or strange design to me that they don't maintain state.
Also I think that drlvm >would not be able to pass some cyclic many days scenarios which use separate >class loader for every step, e.g. some reliability testing.
That was my point. That we are trying to do an invasive optimization for a problem that does not exist yet. We don't have these cyclic scenarios on memory constrained systems.
>Every object is described with VTable object, but VTable object is also a >full Java object, it means it is to have its own VTable object. But there 1 >little specifics that prevents us from infinite sequence of VTables. VTable >describing object has variable size according to the objects class specifics >(number of methods). Lets name VTable of object as VT. Now VT should have >own VTable, name it VTable_for_VT. This VTable_for_VT describes VT (e.g. >size of VT as it's different for different classes), but in its turn >VTable_for_VT has always the same size (as VT is specific and has no methods >in its class). Therefore all VTable_for_VT objects could be described with >only one last VTable object, name it VTable_for_VTable.
Yes, I understand that you break the recursion by creating a self referential structure when the vtables stop being unique. Thanks. That was why I asked if the Vtable class is a special class.
>-Yes. To avoid heap fragmentation GC should allocate pinned objects via >special malloc like function like gc_pinned_alloc (see >issues.apache.org/jira/browse/HARMONY-1935).
Let's wait to hear from other GC developers as well, what do you think? Eg., one solution can be to allocate pinned objects at the edge, or outside the main Java heap, but these have several implications on performance or on the success of your proposed method.
>- Heap pressure is to be measured when unloading is done, but I feel >optimistic on that because number of VTable object is small comparing to the >total number of objects on heap. Adding j.l.Class reference to every object >will lead to great memory footprint increase. This about object overhead. >Right now it is 8 bytes for every object (IA32, Compressed mode). Adding >additional reference to the object header will increase object overhead on 4 >bytes (IA32). Lets consider some application having about 1 million of >objects, them memory footprint will increase on 4Mb. I'm not familiar what >is the number of objects on Eclipse launch. Does anyone have this data?
I agree with the overall statement that adding a reference to each object as opposed to each class( vtable ) would possibly create more heap pressure. I can't do more theoritical analysis than that. But java vtables have other issues, as discussed on this thread...an impact to devirtualization, need for pinning, etc. The question is whether we need this optimization, and all the associated changes now. And if this is the best way to implement it. Thanks, Rana
