RFR(M): 8166317: InterpreterCodeSize should be computed

[Volker Simonis]

Volker Simonis <volker.simonis at gmail.com> schrieb am Di. 10. Okt. 2017 um
19:17:

> 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,

can somebody please take a look at the new version of the patch?

Thanks,
Volker


> 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
>