RFR(M): 8166317: InterpreterCodeSize should be computed

Volker Simonis volker.simonis at gmail.com
Tue Oct 24 07:35:37 UTC 2017


Thanks,
Volker

On Mon, Oct 23, 2017 at 10:00 PM, Vladimir Kozlov
<vladimir.kozlov at oracle.com> wrote:
> 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