On Thu, Aug 8, 2013 at 10:41 AM, Jonathan S. Shapiro <[email protected]>wrote:
> I think I'm missing the problem you are trying to solve that is prompting
> you to want to save the stack.
>
I don't want to save the stack. I'm explaining that I *believe* existing
runtimes (JVM, CLR) have slow-throw specifically because they save the
stack, to assure they can provide stack-backtraces.
> Bennie, all I want is a fast structured error handling mechanism which
>> includes assignment analysis. I don't much care is there is another slow
>> one. I'm happy to ignore it.
>>
> Can you say what you mean by "assignment analysis" here?
>
I mean that returnable products of a function should be known by the
compiler not to contain predictable values in the case of an error return
(whether by structured error return, or structured exception handling)...
Currently we only get this behavior when using slow exceptions. Here is an
example..
SomeType a, b;
try {
a = doSomething(out b);
print(a);
} catch {
// invalid to use a or b here, because the compiler knows they were not
assigned..
}
bool failureReturn = doSomething(out a, out b);
// using a return value for error has screwed up the compiler assignment
analysis
// it thinks a and b are valid here even if if we returned true (failure)
> The issue I have with slow exception handling is that it generally
>> forces me into choosing between fast less-safe code with no assignment
>> analysis; or slow safer code with exceptions. That's a bad deal in my book.
>>
> Fair enough. But you're asserting very general conclusions about exception
> handling performance on the basis of the poor performance of a single,
> questionable implementation (CLR).
>
I'm not at all. I'm simply saying my ideal system's runtime would have only
one **fast and structured** error handling mechanism. My position is...
make it fast or take it out. I don't care if it's fast stack unroll or fast
structured return values.
I'm expressing a preference to end slow exception mechanisms, because when
systems have slow exception mechanisms, they become a geometric expansion
factor in APIs. This happens as programmers effectively have to support
both mechanisms.
I think there are a great many situations where runtime-stack-backtraces
are useful. To this end, it might be reasonable to strike a compromise
where we can, at run-time, decide globally between ultra-fast throw with no
stack-preservation, and pretty-fast throw with stack preservation.
(assuming there is no magic way to have ultra-fast throw and
stack-preservation, which would be even better)
> I think there's another question to ask here. Is the CLR's approach to
> exception handling the real culprit here, or is the real problem the fact
> that dynamic introspection exists in CLR?
>
To understand the cause of CLR's incredibly slow exceptions, we need a real
source of truth. Absent some digging, I think it's partially related to
stack-backtrace-preservation (which is only slightly related to
introspection), and partially related to the stack-walk based security
model. I could be completely wrong though.
As for a more broad view of introspection... (a) some amount of type
information for public types is required for robust late-binding... though
even granular data could be hashes or GUIDs if it isn't already. (b) I
would much prefer to have a robust and *language-supported* bind-time or
compile-time introspection and code-generation or macro facility. I really
dislike having to build IDL-parser/code-generators and then further, to
deal with integrating them into cross-platform build systems.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
