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

dean.long at oracle.com dean.long at oracle.com
Tue Jun 14 19:28:20 UTC 2016


These changes look good to me.

dl


On 6/14/16 9:07 AM, Coleen Phillimore wrote:
>
> Hi, I haven't had a chance to look at this latest change but I will 
> sponsor it.
>
> thanks,
> Coleen
>
> On 6/14/16 7:51 AM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> i found vm_default_page_size() on linux/aix is unused now,
>> and stack_page_size on aix was never used. I removed this
>> dead coding and updated the webrev in-place.
>>
>> Incremental, non-aix diff:
>> http://cr.openjdk.java.net/~goetz/wr16/8159335-stkOvrflw/webrev.01/src/os/linux/vm/os_linux.hpp.udiff.html 
>>
>>
>> Best regards,
>>   Goetz.
>>
>>> -----Original Message-----
>>> From: Lindenmaier, Goetz
>>> Sent: Montag, 13. Juni 2016 13:33
>>> To: hotspot-runtime-dev at openjdk.java.net
>>> Subject: RFR(M): 8159335: Fix problems with stack overflow handling.
>>>
>>> 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.
>>>
>>>
>



More information about the hotspot-runtime-dev mailing list