Hi Niko, hi all, there is an interesting thread going on on the jvm-languages mailing list; among the other things, I discovered that the JVM can handle the exception much faster if you override the fillInStack method to do nothing instead of building the traceback. I think that since we don't rely on jvm tracebacks for exceptions, overriding such a method in all our exception classes might lead to some speedup. Note that hotspot is smart enough to optimize well the case in which you raise a prebuilt exception, but in all cases in which you have to dynamically construct a new exception (e.g., OperationError) it can't. ciao, Anto -------- Original Message -------- Subject: [jvm-l] Re: Fan Programing Language Date: Tue, 22 Apr 2008 15:05:04 -0400 From: John Cowan <johnwcowan@gmail.com> Reply-To: jvm-languages@googlegroups.com To: jvm-languages@googlegroups.com References: <bfb6e3b0-8e81-4e38-95ea-2ce1187558fc@u69g2000hse.googlegroups.com> <200804221911.40276.jon@ffconsultancy.com> <480E31B8.5090504@gmail.com> <200804221941.11608.jon@ffconsultancy.com> On Tue, Apr 22, 2008 at 2:41 PM, Jon Harrop <jon@ffconsultancy.com> wrote:
Yes, you must. However, what makes allocating an exception expensive is the fillInStack method, which has to walk the JVM stack. If you override that in your exception class with a do-nothing method, then locally allocating exceptions is very cheap. -- GMail doesn't have rotating .sigs, but you can see mine at http://www.ccil.org/~cowan/signatures --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages@googlegroups.com To unsubscribe from this group, send email to jvm-languages-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
Charles Oliver Nutter wrote:
I tried to manually override fillInStackTrace by editing the generated .j file; the resulting pypy-jvm runs about 8% faster on richards and 14% on pystone.
And if you are just using exceptions as a message-passing or stack-unrolling mechanism, just instantiate it once per thread.
I think we already do that; all the standard exceptions are prebuilt objects, stored as public static fields. I don't know if there are other exceptions that are used inside the interpreter to unroll the stack but which are not prebuilt. ciao, anto
Hi Antonio, On Fri, Apr 25, 2008 at 11:25:17AM +0200, Antonio Cuni wrote:
I don't know if there are other exceptions that are used inside the interpreter to unroll the stack but which are not prebuilt.
We tried to avoid all non-prebuilt exceptions for control flow purposes. I think that in any performance-critical place there is only OperationError that could possibly be instantiated at run-time. A bientot, Armin.
Charles Oliver Nutter wrote:
I tried to manually override fillInStackTrace by editing the generated .j file; the resulting pypy-jvm runs about 8% faster on richards and 14% on pystone.
And if you are just using exceptions as a message-passing or stack-unrolling mechanism, just instantiate it once per thread.
I think we already do that; all the standard exceptions are prebuilt objects, stored as public static fields. I don't know if there are other exceptions that are used inside the interpreter to unroll the stack but which are not prebuilt. ciao, anto
Hi Antonio, On Fri, Apr 25, 2008 at 11:25:17AM +0200, Antonio Cuni wrote:
I don't know if there are other exceptions that are used inside the interpreter to unroll the stack but which are not prebuilt.
We tried to avoid all non-prebuilt exceptions for control flow purposes. I think that in any performance-critical place there is only OperationError that could possibly be instantiated at run-time. A bientot, Armin.
participants (5)
-
Antonio Cuni -
Armin Rigo -
Charles Oliver Nutter -
Niko Matsakis -
Paul deGrandis