RFR(M): 8159335: Fix problems with stack overflow handling.

[Lindenmaier, Goetz]

Hi,

During porting JEP 270 to ppc I detected a row of bugs in the stack overflow coding.
This change fixes these.
Please review these changes. I please need a sponsor.
http://cr.openjdk.java.net/~goetz/wr16/8159335-stkOvrflw/webrev.01/index.html

javaCalls.cpp:
Windows calls map_stack_shadow_pages() after doing os::stack_shadow_pages_available().
Both functions read the stack pointer, but this might result in
different sp's. In consequence, map_stack_shadow_pages() can hit
a guard page although the previous check succeeded.
So I pass in the sp so we can assure we use the same in both. Also,
I optimized the map_stack_shadow_pages() on windows, we saw bad
assembly for it.

os_<os>.cpp:
fix bug & Streamline computation of min_stack_allowed.
- In some OS'es it was forgotten to consider the reserved pages.
- OS'es use different multiplicators (aix: 8K, bsd: system page size,
   linux: 8K, solaris: system page size (often 8K), win: system page size)
   --> Use 8K everywhere, but I noted it down with *4K as zone
       sizes are also given in 4K units.
- min_stack_allowed should be page aligned, else the warning is
   misleading.

templateTable_ppc_64.cpp:
Fix bug on ppc: in monitorenter() the wrong stack bang mechanism
was used.

globals_<cpu>.hpp:
Streamline ppc stack guard sizes. The current ppc sizes are not
adapted to openJdk. There SocketOutputStream.socketWrite0()
uses a large buffer, so shadow pages have to be increased.
This makes no big difference as many ppc systems have 64K
pages, and the zone sizes are adapted to page sizes.
Because zone sizes are calculated based on 4K pages now,
the shadow zone on sparc has to be increased, too.
Sparc uses 8K pages per default (as far as I konw),
which was the old multiplier (wrong since 8139864).

zone sizes:
      red  yellow res  shadow
aarch  1     2    0     4+5
ppc    1     6    1     6+2  --> 1 / 2 / 1 / 20+2
sparc  1     2    1    10+1  --> 1 / 2 / 1 / 20+2
spac32 1     2    1     3+1  --> 1 / 2 / 1 /  6+2
x86_64 1     2    1    20+2
x86_32 1     2    1     4+5

win
x86_64 1     3    0     6+2
x86_32 1     3    0     4+5

templateInterpreterGeneratore_<cpu>.cpp:
Simplify checking whether the new frame fits on the stack.
Use JavaThread->_stack_overflow_limit on all cpus. This
saves several instructions.

I also have to increase the stack sizes of some tests. They fail because
systems with 64K pages require five of them for the shadow/guard area.

I ran this in our night build for a few days, so it's tested on linuxx86_64,
Ppc aix, linux and linux-le, sparc and darwinintel.  Among others, all hotspot
Jtreg tests and a lot of jck tests have been executed.

Best regards,
  Goetz.