4 ms·

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

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.

saagarjha 4y ago
If you need identity you can just compare indices instead of pointers, no?
- chrisseaton 4y ago
  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.
  - saagarjha 4y ago
    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.
    - 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 ago
        Ah, yes, true.
    - twic 4y ago
      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/oops/instanceKlass.hpp#L47 https://github.com/openjdk/jdk/blob/master/src/hotspot/share...
      - chrisseaton 4y ago
        I think they mean keep references to them in an indexable array.
        remram 4y ago
        That is the extra indirection I was talking about.

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.

saagarjha 4y ago

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

chrisseaton 4y ago
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.
- saagarjha 4y ago
  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.
  - 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 ago
      Ah, yes, true.
  - twic 4y ago
    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/oops/instanceKlass.hpp#L47 https://github.com/openjdk/jdk/blob/master/src/hotspot/share...
    - chrisseaton 4y ago
      I think they mean keep references to them in an indexable array.
      - remram 4y ago
        That is the extra indirection I was talking about.