Re: State of openjdk on hppa

[Tom Rodriguez <Thomas.Rodriguez@Sun.COM>]

No I didn't see it.  If it was only on the icedtea list then I wouldn't have seen it as hotspot-dev is the only one of these aliases that I'm on.  By the way, I restored the other aliases to my reply so they would get it too.  So the computation of the location of the guard pages is wrong because of the direction of growth?  For instance this line obviously won't work right:

  address low_addr = stack_base() - stack_size();

There's also some code in os_linux_zero.cpp that does math on the stack that would need to take into account the real ABI direction.  I think we probably need something like "int os::stack_direction()" to deal with this in shared code.  All the guard logic in Thread needs to check it as does is_in_stack and is_lock_owned.  There might be some logic in frame that needs to check it too but hopefully that will all be platform dependent logic.

tom

On Jan 6, 2010, at 8:53 AM, Andrew Haley wrote:

> On 01/06/2010 04:47 PM, Tom Rodriguez wrote:
>>> I'm not 100% sure what the correct value of this would be for HPPA.
>>> The ABI stack grows upwards, but the stack Zero maintains still grows
>>> downwards.  If interpreter_frame_expression_stack_direction is used
>>> for both of these stacks then something will need changing (either a
>>> separate accessor, or Zero's stack direction changing to match the
>>> ABI stack.)
>> 
>> I don't really think hotspot cares which direction the ABI stack
>> grows.  It only cares what direction the expression stack grows and
>> that's only for frame code that it was walking over the contents of
>> the expression stack..  I was assuming that the expression stack
>> would follow the ABI but I guess there's no reason it must.  It's
>> just the responsibility of the C++ intepreter to deal with that
>> properly.  It would be nice to know what exact problem led to the
>> initial conclusion that direction of stack growth was the problem.
> 
> Did you not see my reply?  The runtime write protects the guard pages
> of the stack, and this immediately causes a segfault since the stack
> being used is now unwritable,
> 
> Andrew.