Hi all, just to write my current state of thinking somewhere, I see 3 ways to implement value based class which all have their pros and cons
- the value based class bit, a value based class is tagged with ACC_VALUE_BASED, which means that they have no identity. It's not a value class so instances of a value based class are not flattened for fields and arrays but the JIT can flattened them and re-materialize them. - the interface trick, a nullable value type is like an interface that contains a value class. The idea is to change the semantics of invokevirtual to be able to call methods of an interface. This way we can swap the implementation of the value based classes to use interfaces instead. Like the previous proposal it means that because it's an interface there is no flattening for fields and array but the JIT is able to remove allocation on stack because the interface implementation is a value type. - nullable value type, as decribed before on this list, the developer that create a value based class indicate a field which if is zero encodes null. A nullable value type is flattened for fields and arrays. The main drawback of this approach is that non nullable value type pay the cost of the possibility to having nullable value type on operation like acmp. This model is also far more complex to implement because it introduce another kind of world, the N-world. To summarize, the first two proposals allow a value based class to be null with the cost of not having their values being flattened if not on stack the last proposal allow value based class to be fully flattened with the cost of making the VM more complex and slowing Object operations because it introduce a new world. Given that we want to support value based class only for retrofitting purpose, my money is on 2 actually :) Rémi
