[lworld] Dropping jdk.incubator.mvt and MVT change in MethodHandle and reflection (original) (raw)
Karen Kinnear karen.kinnear at oracle.com
Tue Feb 27 18:14:45 UTC 2018
- Previous message (by thread): [lworld] Dropping jdk.incubator.mvt and MVT change in MethodHandle and reflection
- Next message (by thread): [lworld] Dropping jdk.incubator.mvt and MVT change in MethodHandle and reflection
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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: Mandy,
Many thanks for doing these changes! I had a couple of questions on the source changes: 1) java/lang/invoke/MethodType.java leadingReferenceParameter() 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 , 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.
thanks, Karen
Mandy It would be good to have an explicit test for this if you are collecting test cases.
thanks, Karen
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. Mandy
- Previous message (by thread): [lworld] Dropping jdk.incubator.mvt and MVT change in MethodHandle and reflection
- Next message (by thread): [lworld] Dropping jdk.incubator.mvt and MVT change in MethodHandle and reflection
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]