RFR(M): 8166317: InterpreterCodeSize should be computed

[Volker Simonis]

On Tue, Oct 10, 2017 at 9:42 AM, Andrew Haley <aph at redhat.com> wrote:
> On 09/10/17 20:24, Volker Simonis wrote:
>> Unfortunately we can't easily generate these stubs during
>> 'stubRoutines_init1()' because
>> 'generate_dirty_card_log_enqueue_if_necessary()' needs the byte map
>> base address which is only initialized in
>> 'CardTableModRefBS::initialize()' during 'univers_init()' which
>> happens after 'stubRoutines_init1()'.
>
> Yes you can, you can do something like we do for narrow_ptrs_base:
>
>     if (Universe::is_fully_initialized()) {
>       mov(rheapbase, Universe::narrow_ptrs_base());
>     } else {
>       lea(rheapbase, ExternalAddress((address)Universe::narrow_ptrs_base_addr()));
>       ldr(rheapbase, Address(rheapbase));
>     }
>

Hi Andrew,

thanks for your suggestion. Yes, I could do that, but that would
replace a constant load in the barrier with a constant load plus a
load from memory, because during stubRoutines_init1() heap won't be
initialized. Not sure about this, but I think we want to avoid this
overhead in the barriers.

Also, Christian proposed in a previous mail to replace the G1 barrier
stubs on SPARC with simple runtime calls like on other platforms.
While I think that it is probably worthwhile thinking about such a
change, I don't know the exact history of these stubs and probably
some GC experts should decide if that's really a good idea. I'd be
happy to open an extra issue for following up on that path.

But for the moments I've simply added a new initialization step
"g1_barrier_stubs_init()" between 'univers_init()' and
interpreter_init() which is empty on all platforms except SPARC where
it generates the corresponding stubs:

http://cr.openjdk.java.net/~simonis/webrevs/2017/8166317.v3/

I've built and smoke-tested the new change on Windows, MacOS,
Solaris/SPARC, AIX, Linux/x86_64/ppc64/ppc64le/s390. Unfortunately I
don't have access to ARM machines so I couldn't check arm,arm64 and
aarch64 although I don't expect any problems there (actually I've just
added an empty method there). But it would be great if somebody could
check that for any case.

@Vladimir: I've also rebased the change for "8187091:
ReturnBlobToWrongHeapTest fails because of problems in
CodeHeap::contains_blob()":

http://cr.openjdk.java.net/~simonis/webrevs/2017/8187091.v2/

Because it changes the same files like 8166317 it should be applied
and pushed only after 8166317 was pushed.

Thank you and best regards,
Volker

> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671