[lworld] VerifyError: Bad type on operand stack, limitation in javac for value type constructors
srikanth.adayapalam at oracle.com
Tue Jul 17 01:22:22 UTC 2018
On Tuesday 17 July 2018 01:12 AM, John Rose wrote:
> On Jul 16, 2018, at 9:53 AM, Srikanth <srikanth.adayapalam at oracle.com
> <mailto:srikanth.adayapalam at oracle.com>> wrote:
>> There was both a lowering problem and a code generation problem.
>> x = y = 1234;
>> Earlier it was being lowered to:
>> $value = __WithField($value.x, $value = __WithField($value.y, 1234));
>> which is bogus.
>> Now we lower the above chained assignment to:
>> $value = __WithField($value.x, ($value = __WithField($value.y, 1234)).y);
>> Now the lowering is good, but it complicates code generation due to
>> side effects peculiar to values:
> This lowered expression would do the job in the right order, correct?
> $value = __WithField(($value = __WithField($value.y, 1234)).x, $value.y);
Very likely yes. However the canonical recursive descent visitation
would not yield that tree without some amount of contortion.
In http://hg.openjdk.java.net/valhalla/valhalla/rev/fa4241b022ea, I have
pushed a fix for a more optimal byte code sequence (that eliminates a
pop instruction per withfield) for category 1 computational type.
(The pop is still required when the value involved is of category 1
computational type. This is because swap does not work with ...
long/double ValueInstance on top of operand stack (why?) and I have to
More information about the valhalla-dev