Review Request: JDK-8185148: [MVT]'s isValueClass causes all non-MVT enabled JVM executions to have an InstanceKlass created for __Value reference

Maurizio Cimadamore maurizio.cimadamore at
Fri Jul 28 14:45:40 UTC 2017

On 28/07/17 15:26, Mandy Chung wrote:
> One thing to mention:
> LambdaType.BasicType Q_TYPE:
>     Q_TYPE('Q', MinimalValueTypes_1_0.getValueClass(), Wrapper.OBJECT),
> If value type is not enabled, Q_TYPE would have a null basic type Class.
> I expect Q_TYPE should not be used in that case.  Do you see any issue?
I think that should be OK. I already too care of making sure that 
there's no eager initialization of Q-based lambda forms at startup, as 
this was creating issues in case value type support is disabled. So, 
yes, only way to have Q-typed lambda forms is to have MVT enabled (or at 
least that's how it should be). Of course, I can always make a mess, and 
try to do something like this:


And that will likely blow up - but I think the core issue here is that 
__Value should NOT be part of java.base (or at least should not be part 
of an exported package), or there will always be escape hatches to get 
into troubles again.

> Mandy
>> On Jul 28, 2017, at 5:28 AM, Maurizio Cimadamore <maurizio.cimadamore at> wrote:
>> Looks great - thanks!
>> Maurizio
>> On 28/07/17 05:56, Mandy Chung wrote:
>>> A class referencing java.lang.__Value would fail verification when value type is not enabled.  Class::isValueType and MinimalValueTypes_1_0::getValueType both references java.lang.__Value but they may be loaded when value type is not enabled.  VerifyError that Tobias has ran into [1] is related to this issue.
>>> A simple fix is to refactor the reference to java.lang.__Value in a separate class that will only be loaded when -XX:+EnableMVT and —XX:+EnableValhalla is set.  We may look into a cleaner fix in the future.
>>> Webrev:
>>> Mandy
>>> [1]

More information about the valhalla-dev mailing list