Another great reference. To my VM-tuned ears, it sounds like a job for "class splitting".
I.e., the JVM currently has a one-to-one relation between bytecoded classes and the klass IDs which are stored in object headers. This need not be the case. I know of several possible reasons to split classes: - saving parameters from erasure - distinguishing between instances with different creation paths (constructors, etc.) - distinguishing between optimized and general-case instances (short & long number formats, etc.) - distinguishing between immediate and ordinary objects - adding instance-specific methods (Ruby, etc.) - other behavioral customizations on well-known instances like enums The cost tradeoffs are the usual balance between copying hot information and indirecting to shared information. Sharing vtables requires some sort of extra check on method call. In the extreme case of immediate (non-oop) pseudo-pointers, the processing of object references is somewhat complicated by detecting non-oop tag bits. (E.g., if a subrange of Integer were encoded into an immediate pointer, a corresponding klass split from Integer would make sure never to indirect the 'this' pointer and instead decode the 'value' field from a bitfield therein.) These design questions need to be explored in a VM-centric way. By that I mean what low-level general purpose API will allow applications (or optimization packages) to organize split classes, in such a way that use cases like the above are well-served. -- John P.S. "oop" comes from Smalltalk, means "ordinary object pointer", as opposed to a primitive value bit-encoded into a pseudo-pointer. In HotSpot, all oops have 2 or 3 low zero bits, so it's a relatively simple matter to set one of those bits to distinguish pseudo-pointers. On 64-bit systems the possibilities are impressive. On Oct 15, 2007, at 11:57 AM, Rémi Forax wrote: > > John Rose a écrit : >> On Oct 13, 2007, at 10:46 AM, Rémi Forax wrote: >> >>> and reified generics (generics at runtime) [11] >>> >>> [11] >>> http://www.weiqigao.com/blog/2007/01/20/ >>> java_generics_let_the_other_shoe_drop.html >> >> Absolutely. That's about where I gave up lengthening the list, >> because I didn't have a reference handy, and I'm not sure what >> the cost will be, and the list seemed long enough for starters. > about the cost and how to implement that, this paper give some > insights: > http://portal.acm.org/citation.cfm?id=1244286 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
