harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: discussion for H5022
Date Sun, 08 Feb 2009 21:26:52 GMT
On the 0x552 day of Apache Harmony Alexey Varlamov wrote:
> 2009/2/6 Egor Pasko <egor.pasko@gmail.com>:
>> On the 0x550 day of Apache Harmony xiaoming gu wrote:
>>> In latest version, I couldn't see the code mentioned in this JIRA.
>>
>> me too :(
> Appears, those pieces where fixed by Mike Fursov at r597601. Maybe he
> considered the fix incomplete thus the issue is still open.

is it easy to find him? I mean .. physically :)

>>> And the only operations about heap base in HIR2LIR pass are for
>>> zeroForComparison, ldnull, simpleLdInd, simpleStInd and
>>> ldRef. Thanks.
>>
>> so, to sum up the compressed mode operation: zeroForComparison,
>> simpleLdInd and simpleStInd all make a copy of heap base imm operand
>> via mov (heapBaseOpnd() does that). Seems to be right.
>>
>> But ldnull does not do that. I understand that add/sub to ldnull imm
>> operand will never happen on the code selection stage. But what about
>> cmp? Suppose cmp accepts this 64 bit imm operand (heap base), then
>> bang, it is truncated by encoder.
> Right, this hole in encoder [1] is a real problem. With a bit of bad
> luck, even if code selection is 100% correct, those intermediate MOVs
> can be optimized out and see, you've got bang! again :)
> Though formally this is the separately tracked issue (HARMONY-5037).
>
> [1] https://issues.apache.org/jira/browse/HARMONY-5037
>
>> Thinking of a possible reproducer in java: "if (obj != null) { ... }",
>> seems like too common to be working incorrectly :) Still I do not
>> understand what happens in this case. Xiaoming, do you have a clue?
>
> I believe such simple test will be generated correctly. Probably
> fastest way to obtain valid reproducer would be adding appropriate
> assertions (e.g. check in emitter if opcode really matches actual
> operands) and catch when it fires on various workloads.
> Getting a real runtime misbehavior (or even crash) is way harder,
> seems even incorrectly generated code would run smoothly in most
> conditions and I suppose that's why such hole remained ignored for
> ages.

Thanks, Alexey!! very valuable comments! (And glad to see you)

so I am +4 (all hands and legs) to put this assertion in.

-- 
Egor Pasko


Mime
View raw message