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 svn/tags/versi
On Wed, Sep 23, 2009 at 7:02 PM, Jens Alfke 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
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 Thu, Aug 20, 2009 at 7:17 PM, Marshall
Greenblatt 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
are currently working o
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, Evan
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 gc(
uot;DedicatedWorkerContext"));
>> return desc;
>> }
>> So it appears that we *do* 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 direct
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.
Che
op v8 context from the stack, eg the
>> context of the currently executing code
>> GetBottomContext() // Returns the bottom v8 context from the stack,
>> eg the context where execution entered v8
>>
>> - a
>>
>> On Thu, Jul 9, 2009 at 1:34 PM, Mads Sig Ager w
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 Ager wrote:
> Drew,
>
> quick answer: When you use V8 you have to enter a context before
> giving V8 some code to execute.
Drew,
quick answer: When you use V8 you have to enter a context before
giving V8 some code to execute. GetEntered() returns the last context
that you entered using the API. When you call JavaScript functions,
the JavaScript engine enters the context in which that function was
defined. When ca
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 obj
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 wrote:
>
> Hi,
>
> In V8 compilation cache code v8/src/compilation-cache.cc, it create a
> histogram.
>
> StatsTable::CreateHistogram
>
>
Perfect! Thanks Patrick!
On Tue, Mar 31, 2009 at 9:21 PM, Patrick Johnson wrote:
> SunSpider and V8 Benchmark Suite performance is now tracked on the Chromium
> Buildbot.
> Graphs are available on the performance overview page at:
> http://build.chromium.org/buildbot/perf/dashboard/overview.h
I think the Mac expected result fallback is currently wrong, it
>> >> >> doesn't seem to look in chromium-win correctly. This is probably
>> >> >> causing a lot of failures.
>> >> >>
>> >> >> 2) We should move c
It seems that when running layout tests on linux, if there are no
special expected results for linux in chromium-linux, we fallback to
the special expected results for windows in chromium-win. This is not
the case on mac if there are no results in chromium-mac, we take the
expectations that are n
16 matches
Mail list logo
