On the 0x552 day of Apache Harmony Alexey Varlamov wrote: > 2009/2/6 Egor Pasko <[email protected]>: >> 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
