Will,
The current method of using soft_calls was nothing more than a hack
I put in to avoid our constantly getting bitten by undetected stack
overflows causing memory corruption. Due to a design/implementation
flaw in the awt, such overflows can be caused by some applications
making use of awt facilities in an unforeseen way. Other applications
(pizza) also make careless use of recursion.
As Tim pointed out, he performs faster inlined stack checking in the
custom version with certain architecture-specific instruction
templates for the JIT. I would like to see this in the public version.
For architectures for which those templates aren't provided we must fall
back to the slower soft call method.
As for hardware checking, first I agree with Tim that we it can't
be the only possible way since not all archs have or use an MMU.
This doesn't mean that software checking should be the only possible
way. If someone implements hardware checking for the architectures
that support it, that would be nice. We can enable one of the other
depending on the architecture, like we already do for NullPointerExceptions.
>From my limited understanding of signal facilities, I believe it
would be rather tricky to implement. What is easy is to set up a
guard zone and take a fault when it's hit. However, Java requires
you to safely recover from a stack overflow via StackOverflowErrors.
This will at least require using an alternate signal stack; plus you
need to have an OS/libc that doesn't freak out when you run and/or
longjmp out of a signal handler with SA_ONSTACK set. It's one of these
things where there is no reason that it shouldn't work, but (at least
my personal) experience indicates that it can be hard and a timesink
to get it working. If you get it working, I'd definitely be happy to
add it.
- Godmar
