Request for reviews (XXL): 6961697: move nmethod constants section before instruction section
Vladimir Kozlov
vladimir.kozlov at oracle.com
Thu Jul 8 10:20:58 PDT 2010
Christian Thalinger wrote:
>> 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.
Yes, I think it is only solution here. You still can treat insts and stub as one code section. We only need the offset to instructions.
>
>> 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.
I assume you want to initialize register with base value at the beginning of compiled code. But you have to deal with large offset (>4k) anyway for methods with a lot constants.
Note: with compressed oops only 2 instructions are used to construct const narrow oop. Which leaves only polling and card table addresses to optimize. And we trade constant construction with load which may not give improvement.
Did you do an experiment to find how much performance improvement it will buy us? I think we need to proceed with this huge changes only if we have benefits from it. Right?
Thanks,
Vladimir
>
> -- Christian
>
More information about the hotspot-compiler-dev
mailing list