FX 的隐藏 mark 层越来越高了……

==============================================================================
TOPIC: Using TryCatch::ReThrow
http://groups.google.com/group/v8-users/t/85e18d3b7ae3f2f5?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Nov 3 2009 2:29 am
From: Christian Plesner Hansen


Hello v8 users
If you ever throw an exception through v8's C++ api that has already
been caught by a v8::TryCatch you may want to change your code to
using the TryCatch::ReThrow method that was added in bleeding_edge
revision 3201.  The problem with not using this function is the
following.  If you want to know if an exception is thrown but still
let it propagate out you might do something like this:

v8::TryCatch try_catch;
/* ... do something that might throw ... */
if (try_catch.HasCaught()) {
   return v8::ThrowException(try_catch.Exception());
}
/* ... no exception, continue ... */

We had code like this in several places in chromium.  The problem is
that the TryCatch is still in effect when throwing the exception again
so it will actually be caught immediately and won't be propagated any
further.  That can have some unexpected consequences.  The correct way
to handle this situation is to use the new TryCatch::ReThrow method:

v8::TryCatch try_catch;
/* ... */
if (try_catch.HasCaught()) {
   return try_catch.ReThrow();
}

This will cause the exception to be thrown "around" the try_catch so
it will be propagated correctly into the next exception handler in
line -- what you expect, basically.  If this situation looks familiar
to you, you may want to check your code to see if it needs to be
rewritten to use this.


-- Christian

  Document.Write(2 < 3 > 4 < 1) 

Changeset Id: 1296901
Date: 12/1/2009 10:45:16 AM

Improves performance of code which is purely interpreted. Also has some small benefits for startup perf.

The interpreter perf improvements mostly come out of not using our optimized call sites which perform really badly in the interpreter. The reason they perform so badly is that we spend a lot of time accessing fields which is very very slow compared to doing it when compiled. So instead we have some intermediate expressions which lazily create dynamic sites and hold onto them directly. I’ve also added an instruction provider which gets our code context which just gets the optimized value.

I’ve also gone ahead and moved hot methods into IInstructionProvider implementations. So now for hot methods like getting our code context from a function object this will run faster.

I’ve also implemented some more fast bindings – most of these are for more binary operations, but I’ve also added a few for calls which are hot.

The end result of this is running interpreted (-X:CompilationThreshold 999999) our Pystones go from 18080.8 to 54864.4 (200% improvement).

Big imports (no ngen) goes from 5.44 seconds to 5.16.
Big imports (ngen) goes from 3.11 seconds to 2.69. Working set goes from to 64,088k to 60,164k. This seems to all be a saving in shared pages (private working set is effectively unchanged).

The following code appears to misbehave in MacRuby. It defines a class
hierarchy Alpha > Beta > Gamma, with methods to set and get instance
variables.

{{{
class Alpha
end

class Beta < Alpha
    def setAnotherVar
       @another_var = "Assigned to another_var in Beta"
    end
end

class Alpha
    def setVar=(var)
       @var = var
    end
    def var
       @var
    end
end

class Gamma < Beta
    def setAnotherVar
       @another_var = "Assigned to another_var in Gamma"
    end
end

a = Gamma.new
a.setVar = "Assigned to var"
puts a.var
a.setAnotherVar
puts a.var
}}}

Ruby 1.8.7 prints:

Assigned to var[[BR]]
Assigned to var

Whereas MacRuby prints:

Assigned to var[[BR]]
Assigned to another_var in Gamma

Ruby 1.8.7 would appear to be the correct behaviour. MacRuby is getting
confused about instance variables. Setting the "another_var" instance
variable wrongly changes the "var" instance variable.

Declaring the classes strictly in the order of the hierarchy (i.e Alpha
then Beta then Gamma) fixes the problem, but in a large project where
classes are autoloaded, that may not happen.