Although there can be issues with that as well. We ran into cases where if the same piece of code was entered for both exceptional and non-exceptional reasons, many JVMs could not (would not? did not?) optimize it, and a couple actually crashed (certain Hotspot C1 revisions). It turns out there are fewer degrees of freedom to stray from what javac outputs than one might expect.
At any rate, it sounds like this difference is not particularly interesting, and I won't worry myself about it. Rémi Forax wrote: > In my opinion, having one exit point is important only inside a try/finally > block in order to avoid to duplicate the inlined finally block at all > exit sites. > > Rémi > > John Rose a écrit : >> As far as HotSpot is concerned, it doesn't matter. C2 makes up the >> same SSA graph (except for deopt info.) for both cases. >> >> This indifference is almost certainly true for any JVM, since each >> JVM has to accept the output of any bytecode generator. >> >> -- John >> >> On Oct 13, 2008, at 2:26 AM, Charles Oliver Nutter wrote: >> >> >>> I was examining the bytecode output of Duby this morning, comparing it >>> to javac output, and noticed that for fib() there's only one small >>> difference: javac inserts an extra branch in order to have a single >>> return instruction. >>> >>> Is this useful? Necessary? Anyone know why javac does this, since it >>> increases the bytecode size for this simple case? >>> >>> > > > > --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
