dotgnu-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[DotGNU]Null check elimination & other stuff


From: Thong (Tum) Nguyen
Subject: [DotGNU]Null check elimination & other stuff
Date: Wed, 16 Jun 2004 00:55:49 +1200

Hi guys,

I've just checked in support for null check elimination from PNET.  PNET
will still use the classical check for null references using an if/else
statement on unsupported platforms but now there is infrastructure to allow
it to not bother checking on supported platforms.  It does this by trapping
and responding to segmentation faults that occur while the engine is
executing managed code.  Most of the implementation is in support/interrupt*
and is platform & CPU specific (because registers need to be saved &
restored after the CVM recovers) but has been sufficiently (IMHO) abstracted
to keep PNET portable.  I've added implementations for POSIX & WIN32 systems
though full POSIX support is only enabled for Linux until I can find other
systems to test on (see support/interrupt.h).

A quick benchmark shows that with the null check elimination, PNET can do
393081761 field read/writes per second compared to 302571860 without.
That's a 30% speed gain and it goes nicely with the simple method inlining I
commited a few weeks ago :-).

On Windows/x86 and Linux/x86 I can save/restore registers (using
win32/RegisterUnhandledExceptionFilter & posix/sigaction) so there is no
overhead in other areas like enter_try or call.  On POSIX systems with
support for signal() but not sigaction(), there will be a slight overhead
inside entry_try and call which can't be avoided (unless you turn off null
check elimination).  It's all #defined anyway so you can choose what's the
most appropriate for yourself (do u perform lots of method calls or lots of
object dereferences?).

I've also checked in a new safe Thread.Suspend support.  Threads won't be
suspended while in unmanaged code (as this could deadlock the whole
process). 

Lastly, I've made it so that threads will automatically release all mutexes
they own before they exit.  This is a very obscure feature of managed
mutexes which we (and mono) missed but it's fixed in PNET now anyway.

As usual, tests on lots of systems would be helpful and bug reports are
always welcome.

I'm not going to commit myself to implementing anything new for a while so
it'll only be bug fixes for me now.

All the best,

^Tum



reply via email to

[Prev in Thread] Current Thread [Next in Thread]