6 ms·
How come a whole pointer is required for class pointer? Can't it be a small offset into a class table? Do many Java applications often require millions of class
by kichik 4y ago
How come a whole pointer is required for class pointer? Can't it be a small offset into a class table? Do many Java applications often require millions of classes?
- deleted 4y ago[deleted]
- exabrial 4y agoIt’s uncommon for millions in an average program unless you’ve got a special use case. Typical usage would be a couple thousand.
- remram 4y agoYou mean add a level of indirection to every class access? Also there is already compression for that pointer, making it 32 instead of 64 bits.
- saagarjha 4y agoTurning a pointer loading into an addition and then a pointer load is not that much overhead.
- remram 4y agoThat's how the current compression works, I guess I don't understand what you propose.
- saagarjha 4y agoI guess I am confused as to what the extra indirection is.
- chrisseaton 4y agoThe current compression scheme doesn’t involve reading any memory. Indirection through a lookup table would. But who cares? 99% of the time you just need class identity, not values from it.
- saagarjha 4y agoIf you need identity you can just compare indices instead of pointers, no?
- chrisseaton 4y agoWhat's what I just said? > 99% of the time you just need class identity, not values from it. So no need to deference the class pointer, or the table index.
- saagarjha 4y agoOk taking a step back I just realized you aren't 'remram :P But anyways my point was that in the old scheme if you wanted to know where the class was you would do some arithmetic on the compressed pointer to get a full pointer and now you can do a comparison, or if you want to read something do a dereference. Assuming the new layout is an array of classes you have a similar scheme where you have an index and you can compare those directly, and if you want data in the class you deref.
- chrisseaton 4y ago> in the old scheme if you wanted to know where the class was you would do some arithmetic on the compressed pointer to get a full pointer and now you can do a comparison Well also you didn't actually need to decompress the pointer first - compressed pointers are unique as well of course.
- saagarjha 4y agoAh, yes, true.
- dexwiz 4y agoDefinitely have seen a few enterprise stacks that reach this size. It’s not common, but it happens.
- paulirwin 4y agoI think I'm understanding correctly, but please correct me if I'm wrong... the class pointer is a pointer to the type (class) the object implements. So that would mean to exceed even an unsigned 32-bit pointer size, there would need to be more than 4 billion types in the program to exceed that, not objects. I can't imagine there are (m)any programs that hit that. And it definitely doesn't need to be a native 64-bit pointer. As pointed out in the proposal: "It may be possible to compress class pointers to less than 32 bits, at the expense of smaller addressable class space."
- maxfurman 4y agoAs other comments have mentioned, in the JVM every lambda creates a new type. So there are way, way more "types" created in Java than in a comparable program in another language.
- symaxian 4y agoIt does seem like some additional compression could be performed, if they wanted to keep it a pointer to avoid a table lookup I wonder if they could do something like ensure that all class definitions must exist in the certain contiguous chunk of memory that has a fixed size of 1-4 gigabytes which would let them shrink the pointer size down.
- layer8 4y agoApplication servers can run an arbitrary number of applications in parallel within the same JVM. Also, every lambda expression currently creates a new class. The interface-proxy mechanism also creates new classes at runtime. Classes are not expected to be a limited resource in JVM-land.