[erlang-questions] HiPE for Windows?

[David Hopwood]

Mikael Pettersson wrote:
> On Fri, 28 Dec 2007 09:45:25 +1100, Benjamin Tolputt wrote:
>> Mikael Pettersson wrote:
>>> There are no plans for a Win32 version of HiPE, due to a
>>> combination of technical issues and lack of interest.
>>> HiPE works fine on Linux, Solaris, and at least some of the *BSDs.
>> Do you know what these problems are and/or where people (such as myself)
>> can look at them? I've played with (the code of) JIT compilers on
>> Windows and haven't come across show-stoppers before.
> 
> Asynchronously called functions on the current ESP/RSP stack.
> 
> Unix signal handlers are by default invoked on the thread's
> current stack, but they can be redirected to a separate stack
> using SA_ONSTACK and sigaltstack().
> 
> It's my understanding, from reading papers on various systems
> ported to or developed for Win32, that Win32 (a) will call
> functions asynchronously on the current stack, and (b) does
> not provide an altstack-like mechanism.

Windows will only run code asynchronously on the current stack as a
result of a VEH/SEH exception. So, a possible solution is to make
sure that the handler for these exceptions uses a sufficiently small
amount of stack space, that we can reasonably reserve that much space
(which could be only a few bytes) for each Erlang process.

On Windows XP and later [*], the first-chance VEH handler, which
runs before any other exception handlers, can be set using
AddVectoredExceptionHandler(TRUE, ...) -- see
<http://msdn.microsoft.com/msdnmag/issues/01/09/hood/>, or the
MSDN API docs.

I don't think it's possible for a VEH handler to actually switch the
stack and then continue normal exception processing (because it must
return on the same stack in order to do that). However, there are at
least two possible workarounds:

1. Use only VEH to replace signals. In that case the vectored handler
   can switch the stack and then call the "signal handler" itself,
   bypassing Structured Exception Handling entirely. I think that
   Sun's Hotspot JVM on Win64-Itanium, and Apache's Harmony JVM, use
   this approach.

   Note that this prevents the Erlang emulator itself from using SEH.
   I don't know whether that is a problem or not. Linked-in drivers can
   still use SEH, because they run with a larger stack (I assume, since
   they will not have the stack checks inserted by HiPE), and the VEH
   handler can detect this case and continue normal exception processing.

2. Save the stack area that could be trashed by the signal handler,
   and have the signal handler restore it just before resuming. For the
   multi-threaded emulator, it would also be necessary to stop all other
   threads (or make sure that they will not access the area that could be
   trashed).

This assumes that you don't have any other native libaries installing
their own vectored exception handlers. Few libraries do that, but in any
case it can be prevented (causing a guaranteed crash rather than possible
memory corruption) by setting a breakpoint at the start of
RtlAddVectoredExceptionHandler.

When writing VEH handlers in C, remember to work around this bug:
<http://blogs.msdn.com/oldnewthing/pages/407234.aspx#3072622>.


[*] The mechanism existed on Windows before XP, but was not supported
    by documented APIs. I assume that it's unnecessary to support HiPE
    for earlier versions of Windows.

-- 
David Hopwood