On Jul 6, 2009, at 11:49 AM, Per Bothner wrote: > It's really embarassing > in this day and age that we're still using such a lame classfile > format.
Java's not perfect, but anything that supports such an impressive ecosystem isn't exactly lame either. But sure, there are imperfections (or equivalently, opportunities for improvement). The major question from my point of view is not "how do we fix them" but (a) "where's the code?" and (b) "where's the JSR?" Supplying either (and both are necessary) is a big job, probably requiring experience in JVM implementation. And the implementors are really, really busy. (I hope the Da Vinci Project will continue to help grow some new ones to help the rest of us out!) For small integers serialized into the class format, I suggest using Pack's UNSIGNED5 format, which scales cleanly from 1 to 5 bytes, is monotonic and continuous throughout the 32-bit range, and has efficient (bit-twiddling) encoders and decoders. BTW, the HotSpot JVM uses this internally for serialized data, so there are already encoders and decoders written for it in both C++ and Java. > More tricky is the actual Code attribute. It's preferable > for it "adaptive": Rather than a global flag that switch > between 16-bit and 32-bit offsets, perhaps it would be > better to have an extension of the wide opcode could be used > to indicate 32-bit offsets, since that makes it generate > code on-the-fly without having to know in advance if we > need a long-mode method. I agree, but I think we would need a new prefix 'wide4', since 'wide' already means "change 1 byte field to 2 bytes", where it has meaning (local load/store/inc, ret). Or maybe a 'wide' prefix could be duplicated for extra effect, where it already means "2 bytes", as with C's "long long" type? Or maybe we just leave the limitation in of 2**16 locals, and have it mean "2 bytes" or "4 bytes" in an ad hoc manner. BTW, I'm expecting we'll use a prefix for encoding tailcall and tuple references also, not that it has to be the historical "wide" opcode. -- John --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
