[RFR] Re: jdk9 builds status

[Alex Kashchenko]

Hi,

On 05/27/2016 02:48 PM, Alex Kashchenko wrote:
> 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.

I've done some more testing, this change works fine with GCC 6 (gcc 
(GCC) 6.1.1 20160510 (Red Hat 6.1.1-2)) but breaks for me with GCC 5 
(gcc (Ubuntu/Linaro 5.3.1-14ubuntu2) 5.3.1 20160413). With GCC 5 it 
steps from os::current_stack_pointer into 
linux_aarch32_current_frame_pointer but refuses to return on "bx lr" - 
keeps going through memory and crashes soon.

As I understand, this is somehow related to asm-defined symbol type. 
After I marked asm function with ".type %function" - it works correctly 
with GCC 5. The full asm code that worked for me with slowdebug builds 
of jdk8u and jdk9:

.global linux_aarch32_current_frame_pointer
.type linux_aarch32_current_frame_pointer,%function
linux_aarch32_current_frame_pointer:
   mov r0, sp
   bx lr

Currently doing full rebuild of jdk8 on GCC 6 and jdk9 on GCC 5 - will 
report back if I'll find any problems.

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