[RFR] Re: jdk9 builds status

[Anton Kozlov]

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