Hacker News Reader

Comment by kichik | Hacker News Reader

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?

View on HN

Definitely have seen a few enterprise stacks that reach this size. It’s not common, but it happens.

I 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."

As 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.

It 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.

Application 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.

It’s uncommon for millions in an average program unless you’ve got a special use case. Typical usage would be a couple thousand.

You 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.

Turning a pointer loading into an addition and then a pointer load is not that much overhead.

That's how the current compression works, I guess I don't understand what you propose.

I guess I am confused as to what the extra indirection is.

The 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.

If you need identity you can just compare indices instead of pointers, no?

What'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.

Ok 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.

Also, i believe that 'classes' aren't fixed size, because they contain the class's vtable [1]. As such, you couldn't keep them in an indexable array anyway.

[1] in HotSpot they are instances of InstanceKlass: https://github.com/openjdk/jdk/blob/master/src/hotspot/share...

I think they mean keep references to them in an indexable array.

That is the extra indirection I was talking about.

> 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.

Ah, yes, true.

Reply on news.ycombinator.com