Mark Shannon wrote:> Andrew Haley wrote:>> Let's go back a bit. Your claim is that there is no need to unwind >> frame-by-frame, an unwind simply needs to make a single jump to an >> invoke instruction and restore the context (which in x86 is just 6 >> registers). (This is, more or less, what longjmp() does.) Duncan Sands >> explained to you why that wouldn't work, saying "if you throw an >> exception using your proposed unwind implementation, then it wouldn't >> be caught by dwarf catch/cleanup regions". > > If you can make your point without any references to any C/C++ specific > features it might be more convincing ;)Well, you seemed to be claiming that cleanups were due to stack-allocated objects in C++. I have shown that is not the case.>> He's right. You can't just jump to the invoke instruction, you must >> also pop any cleanups. This is nothing to do with C++, and it has >> nothing to do with whether a language has stack-allocated objects. > > What cleanups?The ones pushed by pthread_cleanup_push().> If the C++ front end leaves all these dead objects on the stack and > insists they are cleaned up promptly, then it its responsibility to > clean them up. > It shouldn't burden other front-ends.Like I said, it's nothing to do with C++, or with the C++ front end.> In a purely heap allocated language without finalizers, say ML or > haskell, there is nothing to clean-up and a simple jump will suffice. > > For languages with finalizers such as Python or Java, a special > finalizer thread can do the cleaning up lazily once the GC has collected > the dead objects.[Aside: That's not quite true for Java, where unwinding releases locks. This could be done by registering a handler at every site where a lock is acquired, but I don't think that's how it generally works.] Maybe there does exist a programming language that never calls (or is called by) programs in other programming languages and never runs in an environment where one of its threads may be terminated. In that case, interoperability of generated code doesn't matter. In the heterogeneous world of the contemporary OS I'm not sure if that's a common case. Andrew.
On Mon, Jul 20, 2009 at 9:41 AM, Andrew Haley<aph at redhat.com> wrote:> Maybe there does exist a programming language that never calls (or is > called by) programs in other programming languages and never runs in > an environment where one of its threads may be terminated. In that > case, interoperability of generated code doesn't matter. In the > heterogeneous world of the contemporary OS I'm not sure if that's a > common case.I believe both Java and .NET tend to assume that code running outside their respective runtimes isn't killing any of their threads. Also, Java makes no attempt to allow exceptions to propagate across JNI bounaries... incoming C++ exceptions just kill the process, and outgoing Java exceptions have to be explicitly checked for in C++ code.
Andrew Haley wrote:> Mark Shannon wrote: >> Andrew Haley wrote: > >>> Let's go back a bit. Your claim is that there is no need to unwind >>> frame-by-frame, an unwind simply needs to make a single jump to an >>> invoke instruction and restore the context (which in x86 is just 6 >>> registers). (This is, more or less, what longjmp() does.) Duncan Sands >>> explained to you why that wouldn't work, saying "if you throw an >>> exception using your proposed unwind implementation, then it wouldn't >>> be caught by dwarf catch/cleanup regions". >> If you can make your point without any references to any C/C++ specific >> features it might be more convincing ;) > > Well, you seemed to be claiming that cleanups were due to stack-allocated > objects in C++. I have shown that is not the case.You have shown no such thing.> >>> He's right. You can't just jump to the invoke instruction, you must >>> also pop any cleanups. This is nothing to do with C++, and it has >>> nothing to do with whether a language has stack-allocated objects. >> What cleanups? > > The ones pushed by pthread_cleanup_push().pthread_cleanup_push() only exists in C/C++. It is a C library function declared in "pthreads.h" a C header file There are other languages than C/C++. And some of them are easier to use :)> >> If the C++ front end leaves all these dead objects on the stack and >> insists they are cleaned up promptly, then it its responsibility to >> clean them up. >> It shouldn't burden other front-ends. > > Like I said, it's nothing to do with C++, or with the C++ front end.So give me an example than is not related to C/C++.> >> In a purely heap allocated language without finalizers, say ML or >> haskell, there is nothing to clean-up and a simple jump will suffice. >> >> For languages with finalizers such as Python or Java, a special >> finalizer thread can do the cleaning up lazily once the GC has collected >> the dead objects. > > [Aside: That's not quite true for Java, where unwinding releases > locks. This could be done by registering a handler at every site > where a lock is acquired, but I don't think that's how it generally > works.]But llvm doesn't support that, so a Java front-end must insert code to do the unlocking. Its separate from unwinding. Why can't the C++ front-end insert code to do its language-specific cleanups.> > Maybe there does exist a programming language that never calls (or is > called by) programs in other programming languages and never runs in > an environment where one of its threads may be terminated. In that > case, interoperability of generated code doesn't matter. In the > heterogeneous world of the contemporary OS I'm not sure if that's a > common case.The level of inter-language interoperability you are talking about is frankly next to impossible. Java doesn't allow threads to be terminated precisely because of the sort of problems it causes.> > Andrew. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Hi,> Maybe there does exist a programming language that never calls (or is > > called by) programs in other programming languages and never runs in > > an environment where one of its threads may be terminated. In that > > case, interoperability of generated code doesn't matter. In the > > heterogeneous world of the contemporary OS I'm not sure if that's a > > common case. > The level of inter-language interoperability you are talking about is > frankly next to impossible. > Java doesn't allow threads to be terminated precisely because of the > sort of problems it causes. >I am happy with the LLVM design choices here. You do not seem to be. If _you_ wan't different semantics why not contribute optional support for your semantics without taking away what is there now? I doubt that any one would object to optional support for an additional way to deal with invoke if you were to supply one appropriately. Maurice> > > > > Andrew. > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090720/ee609155/attachment.html>