From: David P G. <gr...@us...> - 2002-03-21 16:08:22
|
Unfortunately we do not have a good method for doing this. The guard region is fairly big, so it usually is not a problem. You can dump the machine code for a particular set of methods and see how big their stackframes are. Avoid recursion in uninterruptible methods. If you are seeing unexplained memory corruption, you could try making the guard region bigger and see if it goes away. Another possibility is to fill the guard region of the stack frame with an unusual bit pattern (eg 0xdeadbeef) and check to make sure that the end of the guard region still has this pattern when the thread terminates. --dave |---------+--------------------------------------------------------> | | Hezi Azatchi <he...@cs...> | | | Sent by: | | | jik...@ww...uthbury.| | | usf.ibm.com | | | | | | | | | 03/16/2002 04:06 PM | | | Please respond to jikesrvm-researchers | | | | |---------+--------------------------------------------------------> >------------------------------------------------------------------------------------------| | | | To: <jik...@ww...> | | cc: | | Subject: [Jikesrvm-researchers] VM_Uninterruptable | | | | | >------------------------------------------------------------------------------------------| Hi, In the user-guide is says: "an uninterruptable method will never cause a stack overflow trap ... Furthermore, any uninterruptable method should not need more stack space than specified in VM_StackFrameLayourConstants for the stack "guard" area". My question: How can I verify this? (i.e. that a VM_Uninterruptable method won't exceed the stack space available for it). Thanks, --Hezi. _______________________________________________ Jikesrvm-researchers mailing list Jik...@ww... http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jikesrvm-researchers |