[lworld] Dropping jdk.incubator.mvt and MVT change in MethodHandle and reflection
karen.kinnear at oracle.com
Tue Feb 27 18:14:45 UTC 2018
> On Feb 27, 2018, at 12:33 PM, mandy chung <mandy.chung at oracle.com> wrote:
> Hi Karen,
> On 2/27/18 9:20 AM, Karen Kinnear wrote:
>> Many thanks for doing these changes!
>> I had a couple of questions on the source changes:
>> 1) java/lang/invoke/MethodType.java
>> The way we are modeling this, a value type is a reference. It sometimes requires
>> special handling - like arrays or interfaces do - but it is still a subtype of java.lang.Object, so still a reference.
>> I am not sure of the uses of leadingReferenceParameter - but I would expect it to
>> only throw an exception for primitives.
> This patch is the first pass to clean up lworld branch. leadingReferenceParameter change is simply reverting back to the default branch version. I will have to look into how MethodHandle and VarHandles work with values in the next pass. I did change core reflection to throw IAE when setting fields in values as they are immutable. Basically I try to do this in a few patches.
Totally makes sense to do this in multiple steps.
I think the leadingReferenceParameter change is not just a reversion - I think you added a
|| type.isValue() - which I think is incorrect.
>> 2) java/lang/invoke/MethodHandles.java
>> There should be no constructor for value types.
>> I believe Srikanth is ensuring that in javac, and the jvm will be ensuring that at runtime.
>> So maybe that means that no constructor will be found.
>> Would it make sense for findConstructor to check for isValue and throw NoSuchMethodException
>> directly? Or does that fall out of the ResolveOrFail call?
Thank you to John for the correction - my bad - value types have no <init>, they do have constructors.
So ignore my comment here.
> I leave MethodHandle support in the next iteration. Sorry I should have made this clear in my message. Are you okay with dropping MVT first and handle MHs and tests subsequently?
Absolutely - doing this incrementally is a good way to go.
>> It would be good to have an explicit test for this if you are collecting test cases.
>>> On Feb 23, 2018, at 11:45 AM, mandy chung <mandy.chung at oracle.com> <mailto:mandy.chung at oracle.com> wrote:
>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/lworld-drop-mvt <http://cr.openjdk.java.net/~mchung/valhalla/webrevs/lworld-drop-mvt>
>>> This is the first pass to remove jdk.incubator.mvt module and
>>> MVT support in MethodHandle and reflection. I have also added
>>> Class::isValue method to determine if it's a value class. Fields
>>> of a value class are immutable and Field::setXXX methods will
>>> throw IAE if the declaring class is a value class.
More information about the valhalla-dev