On Jan 12, 2011, at 12:17 PM, Rémi Forax wrote: > On 01/12/2011 10:40 AM, Christian Thalinger wrote: >> On Jan 11, 2011, at 10:13 PM, John Rose wrote: >>> On Jan 11, 2011, at 7:30 AM, Christian Thalinger wrote: >>>> On Nov 12, 2010, at 2:42 PM, Christian Thalinger wrote: >>>>> On Nov 12, 2010, at 2:35 PM, Rémi Forax wrote: >>>>>> Le 12/11/2010 12:26, Christian Thalinger a écrit : >>>>>>> As I have already said, I'm not expert here but these changes let all >>>>>>> tests of this testcase pass: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~twisti/6998541/webrev.00/test/compiler/6998541/Test6998541.java.html >>>>>>> >>>>>>> I'm not sure if the assumption is correct that every non-zero >>>>>>> primitive value is a boolean true. >>> Values of subword types (short, char, byte, boolean) are assumed to be >>> confined to their ranges. For boolean, that range is [0,1]. The verifier >>> does not enforce this, however. >>> >>>>>>> John, Remi, I'd like your opinion on that. >>>>>>> >>>>>>> -- Christian >>>>>> Christian, >>>>>> methods unboxRaw call unbox versions, so you have also changed >>>>>> the semantics of all methods unboxRaw which seems a bad idea. >>>>> >>>>> Yeah, I'm also a bit worried about that. I think I leave that up to >>>>> John to fix it properly. >>> The "raw" retype transforms are not directly accessible to users. They are >>> used by trusted code, which promises that any value will continue to be >>> valid in its new type, after the raw retype. >>> >>> In the case of booleans, this means that a raw retype operation from int to >>> boolean will always operate on a normalized value that was either (int)1 or >>> (int)0. >>> >>>> John, is that actually a bug? -- Christian >>> I don't see a bug here. >> Should it be possible to change the return type from e.g. int to short with >> something like: >> >> MethodHandle mh1 = MethodHandles.identity(int.class); >> MethodHandle mh2 = MethodHandles.convertArguments(mh1, >> MethodType.methodType(short.class, int.class)); >> short s = (short) mh2.invokeExact(123); >> >> Because what I get here is: >> >> Exception in thread "main" java.lang.ClassCastException: java.lang.Integer >> cannot be cast to java.lang.Short >> at sun.dyn.util.ValueConversions.unboxShort(ValueConversions.java:66) >> at >> sun.dyn.util.ValueConversions.unboxShortRaw(ValueConversions.java:102) >> at sun.dyn.ToGeneric$Adapter.return_I(ToGeneric.java:393) >> at sun.dyn.ToGeneric$A1.invoke_I(ToGeneric.java:643) >> at Test.main(Test.java:7) > > The spec says that convertArguments only allow lossless primitive > conversions i.e it allows > widening primitive conversions but not narrowing primitive conversions. > So the implementation is Ok here. > > If you want to convert an int to a short, you can use explicitCastArguments. > > MethodHandle mh1 = MethodHandles.identity(int.class); > MethodHandle mh2 = MethodHandles.explicitCastArguments(mh1, > MethodType.methodType(short.class, int.class)); > short s = (short) mh2.invokeExact(123);
No, that also results in the same exception (with b124). -- Christian _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
