Guys, I'm just curious - anybody know how probable is the chance to hit stack overflow during compilation vs managed code execution and vs native code execution? Shouldn't we care (even more) about kernel/classlib natives? I guess there are enough places lacking guard checks like " if (ExceptionOccured()) return 0;"
BTW, the SOE machinery seems to be incomplete for this case, see HARMONY-971 issue. -- Alexey Varlamov 2006/7/25, Rana Dasgupta <[EMAIL PROTECTED]>:
As I understand it, the value added by a broad check like this before the compile starts may not be very high. At best, it can try to avoid SOE in native code with a clean failure when it is certain that the stack state will not permit completion of the compile. So something like 1/100 of the stack as Mikhail mentions sounds reasonable, and the VM could do this. This is something like a tuning activity and some experiments may also help. It is also true that to offer real guarantees that overflow will not occur, the JIT will need to consider this bound before making optimization decisions or to limit recursion depth in algo selection. But this is a lot to do proactively in the Jit, just to try to avoid SOE. My suggestion is that we can consider doing these defensive checks in the Jit only if we want to offer and honor some published reliability guarantees. This is a broader topic and would need to include not only SOE, but several other failures like ThreadAbort etc. that the user does not usually anticipate and are not user code failures. Basically these are guarantees that if the user follows some reasonable guidelines, certain portions of his code cannot fail. How those guarantees can be exposed etc. ( eg., a method attributed with an attribute "Reliable" that the Jit and VM support, or some command line flags etc. ) is a matter of design. We should defer this work unless SOE becomes an issue with our apps of choice or this type of "reliable managed code" is a design requirement in Harmony. For now, it may be better to periodically check for the exception state on the thread in line with Pavel's original design. Thanks, Rana On 7/24/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote: > > No, I think that VM can do this check but use lower border: e.g. 1/100 of > initial. > JIT must do this check more accurate: use knowledge of algorithms it uses. > > The requirement to avoid SOE during a compilation can affect any algorithm > in JIT that uses recursion. Jitrino.OPT has a lot of such algorithms: > node, > insts, opnd based . So I'm not sure that JIT can construct a heuristic or > a > profile to refuse to compile a method in the beginning of the compilation. > The another option is to check available stack size before any recursion > based algorithm and limit the algorithm up to N steps in recursion (N is > recomputed in runtime) . If N steps is not enough algorithm will fail and > JIT will not not perform the optimization or compilation at all. > Quite a lot of changes in JIT though. Any other ideas? > > > > > On 7/24/06, Pavel Afremov <[EMAIL PROTECTED]> wrote: > > > > Hi > > > > On 7/22/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote: > > > > > I think this must be a JIT heuristics because even a small method can > > lead > > > to inlining of whole classlib API :) > > > > > > Are You think this check should be removed from VM and puted into JIT > > only? > > > > BR > > Pavel Afremov. > > > > > > > -- > Mikhail Fursov > >
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
