harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: Stack Overflow Error support issues
Date Wed, 26 Jul 2006 16:05:04 GMT
   Thanks for the clarifications. Please see below...

On 7/26/06, Pavel Afremov <pavel.n.afremov@gmail.com> wrote:
> >The main issue  is that new object can't be created in suspend disabled
> >mode. DRL VM is in this state during "GC unsafe" operation, when GC have
> not
> >been started. New SOE can't be created in this mode. But all information
> >about exception can be stored in thread local storage. When Vm return
> >control to managed code, function rethrow_current_thread_exception is
> >called, and this function can decide to create exception (it's possible
> >here) or throw it lazy.
>  This is the same problem as long unwindable stretches in the Jit.
> rethrow_curr_thread_exception_if_pending()  can be invoked when one comes
> out of the GC suspension state. Functionally, this is the same as the Jit
> proactively checking for an exception object on the thread periodically.
> lazy exceptions are not the solution here, it is an optimization to the
> raising mechanism. At best, it allows us not to precreate the exception
> object as we are doing now at start time.
> >Now "lazy exception" supported for MANAGED code only, Alexey propose
> extend
> >it for VM code. This technique should fix the most case when exception
> >should be raised in suspend disabled mode.

There is no reason why the lazy exception optimization cannot be implemented
for VM code( it may be easier to do this than in jitted code ), but I don't
think that we should do it as a fix to SOE.

In general, I am not too keen to implement a feature to mitigate a bug. I
also think that we need some real usage based test cases for SOE failure (
not our dev tests for unbounded recursion which force it to happen )
to understand how serious the problem is in usage scenarios. Most server
environments eg., web servers, recycle host processes, so I have some doubts
on how often this kind of resource scarcity problem really occurs. Thread
stacks are also not shared resources, even on clients. Anyway, we may want
to wait till Harmony identifies some signature apps or benchmarks and we see
failures due to SOE. In the meantime, my suggestion/vote would be to
proactively check for exception state in unwindable code sections in the
jit, or when returning from suspension state in the VM. That would be my 2


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message