Review Request: JDK-8185148: [MVT] Class.java's isValueClass causes all non-MVT enabled JVM executions to have an InstanceKlass created for __Value reference
maurizio.cimadamore at oracle.com
Fri Jul 28 17:14:03 UTC 2017
On 28/07/17 17:44, Karen Kinnear wrote:
> Can you clarify for me where we ended up?
> __Value is not checked at the java level if neither EnableMVT or EnableValhalla flag -> system property is set.
> Does __Value contain ;Q syntax?
yes, __Value contains mangled ClassInfo names. But it doesn't really use
those in any meaningful way - it's this_class, mostly.
> Do bytecodes that refer to it need ;Q syntax? Or did we end up with a workaround here?
> I just want to be sure I understand what is generated when we do enable either valhalla version for other folks
> generating bytecodes.
Well, __value is there and present in the same way, regardless of
whether you enable MVT or not. It's a class in java.base (for now) and
one that uses mangled ClassInfo. So, any attempt to refer to it will
result in failures.
While we got rid of accidental failures (indirect usages through
reflection and MH API), if the user is really determined, he can always
find ways to refer to this class when MVT suppor is disabled, hence
causing a problem.
>> On Jul 28, 2017, at 10:45 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>> 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.
>>>> On Jul 28, 2017, at 5:28 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>>>> Looks great - thanks!
>>>> 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  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.
>>>>>  http://mail.openjdk.java.net/pipermail/valhalla-dev/2017-July/003007.html
More information about the valhalla-dev