RFR(M): 8166317: InterpreterCodeSize should be computed
Vladimir Kozlov
vladimir.kozlov at oracle.com
Mon Oct 23 20:00:17 UTC 2017
Looks good. I start new testing.
Thanks,
Vladimir
On 10/23/17 10:15 AM, Volker Simonis wrote:
> Hi Vladimir,
>
> that's a good suggestion! I've did so and prepared a new webrev:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2017/8166317.v4/
>
> I've also verified that:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2017/8187091.v2/
>
> still applies after 8166317.v4
>
> Thank you and best regards,
> Volker
>
>
> On Tue, Oct 17, 2017 at 7:49 PM, Vladimir Kozlov
> <vladimir.kozlov at oracle.com> wrote:
>> Hi, Volker
>>
>> You can do a trick with NOT_SPARC() macro to avoid defining empty method on
>> all platforms:
>>
>> +#if INCLUDE_ALL_GCS
>> +void g1_barrier_stubs_init() NOT_SPARC( {} ); // depends on universe_init,
>> must be before interpreter_init
>> +#endif
>>
>> I thought we pushed 8187091 already. I will keep it in mind.
>>
>> Thanks,
>> Vladimir
>>
>>
>> On 10/10/17 10:17 AM, Volker Simonis wrote:
>>>
>>> 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
More information about the hotspot-dev
mailing list