(original) (raw)

On Feb 23, 2014, at 11:02 PM, Igor Veresov <igor.veresov@oracle.com> wrote:

May I please have a second review of this?
Webrev: http://cr.openjdk.java.net/\~iveresov/8035283/webrev.01/

I don't understand the force of the assert; it seems to be true mostly by accident.

Maybe you want an assert that 'last\_may\_be\_short\_branch\_adr' does not fall between (br\_offs - prev\_block\_loop\_pad)+1 and br\_offs, inclusive?

It took me a long time to convince myself that moving the goalpost for the comparison to 'last\_may\_be\_short\_branch\_adr' was safe.  Really, the argument hinges on the fact that all layout info. is relative to a pessimistic assumption that the maximum possible padding (block->code\_alignment() - relocInfo::addr\_unit()) is always inserted.

I suggest making the linkage to that assumption clearer, by hoisting the crucial expression 'block->code\_alignment() - relocInfo::addr\_unit()' as follows:

  uint\*      worst\_case\_pad  = NEW\_RESOURCE\_ARRAY(uint,nblocks);
...

  worst\_case\_pad\[i\] = block->code\_alignment() - relocInfo::addr\_unit();

Then use the array reference directly instead of the now-linked uses of code\_alignment etc.

This is delicate code!

� John