3 ms·

Neither will Java assuming the next stage of this project goes as planned. The overhead for them will only be allocated on demand for those objects that need th

• titzer 4y ago
  I get that monitors are inflated dynamically, but from my reading of the linked JEP, Compressed Object Headers have something like 24 bits allocated for the hashcode in the 64 bit word?
  • pron 4y ago
    Right, but that's the first phase. In the next, I believe the goal is to attempt to reduce the header to 32 bits, and then the header overhead (for all objects) for both monitors and hashcodes will be ~3 bits, basically just to indicate whether or not they're used. For objects where they're used, they will be stored outside the header.
    • titzer 4y ago
      That's pretty cool. These things are super tricky and are hard to get into a high-performance production system, so I respect the journey :-) For Wasm GC, I think we need programmable metaobjects to be able to combine language-level metadata with the engine-level metadata. I have only a prototype in my head for Virgil and plan to explore this in Wizard soon.
  • nicktelford 4y ago
    Towards the bottom of the JEP, they mention that the ultimate goal is 32 bit object headers, which would necessitate object monitors be tracked on-demand in a side table. That's what the parent was getting at.