答复: [RFR] Re: jdk9 builds status

[yangyongyong]

Hi, all, 

Has someone tried the following patch:

=== Patch begin ===
diff -r 79bf1547b28d 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	Wed Jun 01 10:08:09 2016 +0800
@@ -81,7 +81,7 @@
 #define SPELL_REG_SP "sp"
 #define SPELL_REG_FP "fp"
 
-address os::current_stack_pointer() {
+__attribute__ ((noinline)) 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;
=== Patch end ===

it fixes a crash caused by fastdebug version build with with gcc 4.7.1

All the best.

>> -----邮件原件-----
>> 发件人: aarch32-port-dev [mailto:aarch32-port-dev-bounces at openjdk.java.net] 代
>> 表 Anton Kozlov
>> 发送时间: 2016年5月27日 1:57
>> 收件人: andrey.petushkov at gmail.com; akashche at redhat.com;
>> aarch32-port-dev at openjdk.java.net
>> 主题: [RFR] Re: jdk9 builds status
>> 
>> 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
>> > >