I think something else is going on here as well. The changes you are
talking about making sounds great though, so please do!
The increased number of issues with V8 updates was caused by the V8
team and I should have sent an email about it. We changed the DEPS
file to pull V8 from
Jens,
another thing you should be aware of is that DOM nodes are only
collected on full garbage collections. In order to see what is
actually live at the end of a test, you have to force a number of GCs.
If you run in the test shell with the --js-flags=--expose-gc flag,
you can force gc's by
On Wed, Sep 23, 2009 at 7:02 PM, Jens Alfke s...@google.com wrote:
On Sep 23, 2009, at 12:32 AM, Mads Sig Ager wrote:
another thing you should be aware of is that DOM nodes are only
collected on full garbage collections. In order to see what is
actually live at the end of a test, you have
We have focused on making the 64-bit version complete, so there is
still some performance tuning to be done. Currently, the performance
of the 64-bit version is pretty close to the performance of the 32-bit
version when Chrome 2 stable was released.
-- Mads
On Thu, Aug 20, 2009 at 7:26 PM,
On Thu, Aug 20, 2009 at 7:17 PM, Marshall
Greenblattmagreenbl...@gmail.com wrote:
Out of curiosity, what work remains to support a 64bit build on Windows?
V8 does not yet compile in 64-bit mode on Windows. We have focused on
making the 64-bit version of V8 work on Linux and Mac at first. We
By default, it is not possible to trigger at V8 GC programatically.
Use of such an API is tricky and most of the time you will end up
slowing down instead of helping. For that reason, we have avoided
exposing GC through the API.
We do have a flag in V8 called expose-gc that adds a JavaScript
* need to define the base type in this case, and
in general we need to be able to generate a template for every item in the
class hierarchy, even if that class should not be directly instantiable.
Is this correct, or am I missing something?
-atw
On Tue, Jul 21, 2009 at 10:42 PM, Mads Sig Ager
If you don't need the base 'type' in the binding layer code, you don't
have to specify it in the V8Index file. Prototype chains and
instanceof operations are all handled by V8 based on the code
generated from the IDL files and it is independent of the 'type'
declarations in the V8Index file.
For an example of what this means, you can look at
v8/test/cctest/test-api.cc and look for GetCallingContext.
-- Mads
On Thu, Jul 9, 2009 at 1:34 PM, Mads Sig Agera...@chromium.org wrote:
Drew,
quick answer: When you use V8 you have to enter a context before
giving V8 some code to execute.
To me dynamic and lexical makes no sense, so I don't think we should
go there. Since you 'enter' a context through the API and you alway
have a current context when executing code, I find the current
terminology consistent with what is going on and consistent with the
naming in the rest of the
Hi Nathan,
I understand chromium V8 engine compiling JS files into native code
and then have native os executes the generated code.
1. Is there a lot of over head in writing the generated code to a file
and have native os executes it?
the code is put in the JavaScript heap in a code object.
It is purely for gathering statistics on our use of the cache and has
no influence on the generated code.
-- Mads
On Fri, May 29, 2009 at 3:32 PM, Lucius Fox lucius.fo...@gmail.com wrote:
Hi,
In V8 compilation cache code v8/src/compilation-cache.cc, it create a
histogram.
Perfect! Thanks Patrick!
On Tue, Mar 31, 2009 at 9:21 PM, Patrick Johnson patr...@chromium.org wrote:
SunSpider and V8 Benchmark Suite performance is now tracked on the Chromium
Buildbot.
Graphs are available on the performance overview page at:
be more
confusing to manage, but it's also less confusing to understand that
everything should / can fallback to the Windows expectations.
On Thu, Jan 29, 2009 at 2:49 PM, Mads Sig Ager a...@chromium.org
wrote:
It seems that when running layout tests on linux
14 matches
Mail list logo
