[RFR] Re: jdk9 builds status

[Alex Kashchenko]

Hi Andrey and Anton,

Thanks for detailed explanation. Your change works for me with jdk8. I 
haven't yet tried it with jdk9 - I will write back into this thread if 
I'll met problems with jdk9.

On 05/26/2016 06:57 PM, Anton Kozlov wrote:
> Hi, All!
>
> As Andrey said, we reworked current_stack_pointer next way:
>
> === Patch begin ===
> diff -r 79bf1547b28d -r c4f98cfc8c40
> src/os_cpu/linux_aarch32/vm/asm_os_linux_aarch32.s
> --- /dev/null   Thu Jan 01 00:00:00 1970 +0000
> +++ b/src/os_cpu/linux_aarch32/vm/asm_os_linux_aarch32.s        Thu May
> 26 18:26:08 2016 +0300
> @@ -0,0 +1,5 @@
> +
> +.global linux_aarch32_current_frame_pointer
> +linux_aarch32_current_frame_pointer:
> +  mov r0, sp
> +  bx lr
> diff -r 79bf1547b28d -r c4f98cfc8c40
> src/os_cpu/linux_aarch32/vm/os_linux_aarch32.cpp
> --- a/src/os_cpu/linux_aarch32/vm/os_linux_aarch32.cpp  Sat May 14
> 17:34:57 2016 +0100
> +++ b/src/os_cpu/linux_aarch32/vm/os_linux_aarch32.cpp  Thu May 26
> 18:26:08 2016 +0300
> @@ -81,10 +81,12 @@
>   #define SPELL_REG_SP "sp"
>   #define SPELL_REG_FP "fp"
>
> +extern "C" {
> +  void *linux_aarch32_current_frame_pointer();
> +}
> +
>   address os::current_stack_pointer() {
> -  register void* sp __asm__ (SPELL_REG_SP);
> -  // This is a leaf method. Only rfp has been pushed.
> -  return (address) sp + BytesPerWord;
> +  return (address) linux_aarch32_current_frame_pointer();
>   }
>
>   char* os::non_memory_address_word() {
>
> === Patch end ===
>
> Current version had next issue. ARM requires stack alignment to be 8 on
> "external interfaces" (on calls to functions in another compilation
> modules, for example). This is achived by making stack pointer 8-
> aligned initialy and maintaining all stack frames to be 8-aligned.
> JVM is checking the alignement in numerous asserts around the code by
> calling os::current_stack_pointer, which is therefore required to
> return 8byte-aligned value.
> However, in current implementation, sp in the middle of
> os::current_stack_pointer is not on caught by "external enterface"
> constraint, so compiler is free to make arbitrary stack frame for the
> function, which happened to be one word frame (for fp). So we are
> forced to assume compiler's frame size and adjust sp.
>
> I suspect that after removing one-word adjustment (Alex's change) jvm
> should fail in slowdebug mode with "unaligned" message, at least it
> failed so under my system (raspberry-pi2, raspbian, raspbian compiler)
> in previous.
>
> Suggested implementation is not affected by this, compiler should
> maintain 8byte-aligned frame size before making a call to asm helper
> functon. Note, that 8-aligned frame size doesn't make jvm alignment
> checks useless, since if sp alignment broke deeper in stack, it will
> remain unaligned till the top.
>
> Thanks,
> Anton
>
> On Thu, 2016-05-26 at 12:56 +0000, Andrey Petushkov wrote:
>> Dear Alex,
>>
>> pardon for the delayed response. Actually we've reworked the the code
>> which
>> exhibits this problem, because we've found it's not robust vs
>> different
>> toolchains and compilation options. So finally we're using pure
>> assembler
>> to obtain the value of the stack pointer. We'll soon publish the
>> respective
>> changeset
>>
>> Regards,
>> Andrey
>>
>> On Wed, May 25, 2016 at 5:41 PM Alex Kashchenko <akashche at redhat.com>
>> wrote:
>>
>>>
>>> Hi,
>>>
>>> I found that jdk9 in http://hg.openjdk.java.net/aarch32-port/jdk9/
>>> is
>>> broken after the "pre C1" commit due to this discrepancy:
>>>
>>>    - jdk8u:
>>>
>>> http://hg.openjdk.java.net/aarch32-port/jdk8u/hotspot/rev/b3e996878
>>> ddf#l35.6
>>>    - jdk9:
>>> http://hg.openjdk.java.net/aarch32-port/jdk9/hotspot/rev/52d292d5c1
>>> 2f#l35.7
>>>
>>> "fp" register is zero at that point and vm crashes on startup.
>>>
>>> With the following change:
>>>
>>>    address os::current_stack_pointer()  {
>>> -  register void* fp __asm__ (SPELL_REG_FP);
>>> +  register void* sp __asm__ (SPELL_REG_SP);
>>>      // Only lr on top of fp
>>> -  return (address) fp + BytesPerWord;
>>> +  return (address) sp;
>>>    }
>>>
>>> jdk9 works and can bootstrap itself - I've built slowdebug jdk9
>>> using a
>>> fastdebug one as a boot jdk.
>>>
>>> This is just a "heads up" - I am not proposing to integrate this
>>> change,
>>> as it differs from jdk8u and initial change in that place (linked
>>> above)
>>> probably has been done for the reason.
>>>
>>> PS: additional question on aarch32-jdk9 plans: as upstream jdk9 is
>>> feature complete now, does it make sense to update aarch32-jdk9
>>> forest
>>> from it or is it better to wait for some point closer to jdk9
>>> release?
>>>
>>> --
>>> -Alex


-- 
-Alex