[lworld] VerifyError: Bad type on operand stack, limitation in javac for value type constructors

[Srikanth]

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.
>> Given:
>>
>>     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 
use dup_x2.)

Thanks!
Srikanth