harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: Stack Overflow Error support issues
Date Wed, 28 Jun 2006 12:37:20 GMT
On 6/23/06, Pavel Afremov <pavel.n.afremov@gmail.com> wrote:
>
> ..
>

Pavel,

I think SOE in native code should be avoided. AFAIK internal JIT algorithms
use recursion a lot and for a huge control flow graph stack size could be
not enough to compile a method. The one option I see is every native
component is to be responsible to report an error before SOE happened and
not to crash the program.

So, if DRLVM would have a public method like 'get_available_stack_size' a
component could check it and call to VM helper with failure notification or
run some recovery code in case the stack size is too small to complete the
compilation.


As an example I can propose introducing the recovery mode for JIT compilers:
 to add the Jitrino.JET (lightweight compiler) as the last JIT in execution
manager (EM) configuration. If Jitrino.OPT or any other optimizing JIT fails
to compile a method due to the huge method size, it just returns failure to
the Execution Manager (EM) and EM can silently ask the next JIT in the
configuration to compile the method. The last attempt to compile will be on
the Jitrino.JET which requires significantly less resources then other JITs
and will compile a method without SOE.



Does anyone have other ideas how to handle SOE in native code?


-- 
Mikhail Fursov

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