Pavel, Thanks for the clarifications. Please see below...
On 7/26/06, Pavel Afremov <[EMAIL PROTECTED]> 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 cents. Thanks, Rana
