harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Evgueni Brevnov" <evgueni.brev...@gmail.com>
Subject Re: [drlvm] Redesign of hardware exceptions/signals handling
Date Mon, 27 Nov 2006 08:40:17 GMT
Hi guys,

Do I get it correctly that HARMONY-2320 contains all suggested
changes? I'm asking this because it differs from what was posted to
another thread "[drlvm][classlib unit tests] iterative runs".

Thanks
Evgueni

On 11/25/06, Gregory Shimansky <gshimansky@gmail.com> wrote:
> On Friday 24 November 2006 18:44 Salikh Zakirov wrote:
> > However, these patches somewhat regress in functionality:
> > I still haven't figured out how to piggy-back on exception throw
> > to call JVMTI callback and to restore stack guard page.
> > (the commented out block at the end of nt_exception_filter.cpp was doing it
> > before fix).
> >
> > Any ideas appreciated.
>
> I decided this deserves a separate topic. I think signals on unix deserve
> redesign along with NT exceptions since platform dependent part is actually
> quite small, and benefit is quite bit if we do this.
>
> I've reviewed the patch in HARMONY-2320, the changes are going in the right
> direction except for 2 things.
>
> 1. The function vm_identify_eip seems to be called twice now, first in
> vectored_exception_handler_internal, second time in c_exception_handler. The
> function is quite a heavy lookup and it would be better to have it called
> only once. Probably it will require passing one more argument to
> c_exception_handler. Maybe it is better to create a separate place for all
> this stuff in TLS, I mean exception class pointer, registers and in_java
> flag. This would save you from ESP manipulation and make the code more
> portable (any ideas how do these ESP manipulations on IPF? ;) ).
>
> 2. JVMTI functionality is going to be broken with this patch. The
> exception_catch handling callback should be changed to accept registers in
> TLS instead of an assembly stub (makes it more portable too). I think JVMTI
> breakpoints handler could be integrated with the new functionality and called
> from inside of c_exception_handler.
>
> I am very glad you've started to change this stuff (especially that you
> comment your code at every significant step). I would really like to help you
> because I've gone through doing a partial fix only for JVMTI, but now that it
> seems like all the rest has to be changed too I can share my experience.
>
> Isn't it better to use conventional DIE instead of assert(!"...")?
>
> --
> Gregory
>

Mime
View raw message