Request for reviews (XXL): 6961697: move nmethod constants section before instruction section

[Christian Thalinger]

On Wed, 2010-07-07 at 16:56 -0700, Vladimir Kozlov wrote:
> Christian,
> 
> Renaming itself is fine but I don't like putting constants at the
> beginning.
> 
> Originally nmethod::code_begin() and CodeBlob::instruction_begin()
> both point to the first instruction. Now CodeBlob::code_begin() points
> to the constants section and nmethod::insts_begin() to the first
> instruction. As result it is very confusing what to use
> nmethod::insts_begin() or 
> nmethod::code_begin() in some cases. I spent few hours looking on
> these changes and found few other case (for example, disassembler) in
> addition to your XXX where I am not sure what to use. And there are no
> checks/validation that correct method is used. Also for stubs it is
> silently assumed that 
> there are no constants.

I agree.  But the main problem here is that there was no distinction of
the code section begin and the instructions begin before, so changing
that now is very difficult.

The stubs constant section problem is really annoying.  The only
solution I can think of is to explicitly add consts and insts sections
to the CodeBlob.  Maybe even have all section "accessor" methods in
CodeBlob (code_*, consts_*, insts_*, stub_*).  Then we just have to get
the usage of code_* and insts_* correct and we're set once and for all.

> 
> Could you explain why for sparc you need the constants section before
> the instructions section? May be we could use other approach.

Because we want to use rdpc to get the base address of the constant
table.  And to keep the offsets small enough the rdpc has to be close to
the actual constant table (without using extra instructions to adjust
the table base).  Having the table after the code and the rdpc
instruction at the beginning of the method will probably make in many
cases the offsets too big.

-- Christian