date:20091001


Guys, just to summarize the discussion.

There are several ways we can tweak tcmalloc:

1) decommit everything what is free;
2) keep spans with a mixed state (some pages committed, some not,
coalescing nor commit, not decommits)---that should solve main Jim's
argument;
3) commit on coalescing, but aggressively purge (like WebKit do, once
in 5 secs unless something else has been committed, or in idle pauses.

To my knowledge performance-wise 1) is slower (how slower we should
learn), 2) is slightly faster than 3) (but it might be just a
statistical error).  Of course, my benchmark is quite special.

Memory-wise I think 2) and 3) with aggressive scavenging should be
mostly the same---we could keep higher number of committed pages than
in 1), but for short periods of time and I'm not convinced it's a bad
thing.

Overall I'm pro 2) and 3), but I am definitely biased.

What do you think?

And many thanks to Vitaly for discussion.

yours,
anton.
On Thu, Oct 1, 2009 at 3:56 AM, James Robinson jam...@google.com wrote:
 On Wed, Sep 30, 2009 at 2:28 PM, James Robinson jam...@google.com wrote:

 On Wed, Sep 30, 2009 at 11:29 AM, Anton Muhin ant...@chromium.org wrote:

 On Wed, Sep 30, 2009 at 10:27 PM, Mike Belshe mbel...@google.com wrote:
 
 
  On Wed, Sep 30, 2009 at 11:24 AM, Anton Muhin ant...@chromium.org
  wrote:
 
  On Wed, Sep 30, 2009 at 10:17 PM, Mike Belshe mbel...@google.com
  wrote:
   On Wed, Sep 30, 2009 at 11:05 AM, Anton Muhin ant...@chromium.org
   wrote:
  
   On Wed, Sep 30, 2009 at 9:58 PM, Mike Belshe mbel...@google.com
   wrote:
On Wed, Sep 30, 2009 at 10:48 AM, Anton Muhin ant...@google.com
wrote:
   
On Wed, Sep 30, 2009 at 9:39 PM, Jim Roskind j...@google.com
wrote:
 If you're not interested in TCMalloc customization for
 Chromium,
 you
 should
 stop reading now.
 This post is meant to gather some discussion on a topic before
 I
 code
 and
 land a change.
 MOTIVATION
 We believe poor memory utilization is at the heart of a lot of
 jank
 problems.  Such problems may be difficult to repro in short
 controlled
 benchmarks, but our users are telling us we have problems, so
 we
 know
 we
 have problems.  As a result, we need to be more conservative
 in
 memory
 utilization and handling.
 SUMMARY OF CHANGE
 I'm thinking of changing our TCMalloc so that when a span is
 freed
 into
 TCMalloc's free list, and it gets coalesced with an adjacent
 span
 that
 is
 already decommitted, that the coalesced span should be
 entirely
 decommitted
 (as opposed to our current customized performance of
 committing
 the
 entire
 span).
 This proposed policy was put in place previously by Mike, but
 (reportedly)
 caused a 3-5% perf regression in V8.  I believe AntonM changed
 that
 policy
 to what we have currently, where always ensure full commitment
 of
 a
 coalesced span (regaining V8 performance on a benchmark).
   
The immediate question and plea.  Question: how can we estimate
performance implications of the change?  Yes, we have some
internal
benchmarks which could be used for that (they release memory
heavily).
 Anything else?
   
Plea: please, do not regress DOM performance unless there are
really
compelling reasons.  And even in this case :)
   
Anton -
All evidence from user complaints and bug reports are that Chrome
uses
too
much memory.  If you load Chrome on a 1GB system, you can feel it
yourself.
 Unfortunately, we have yet to build a reliable swapping
benchmark.
 By
allowing tcmalloc to accumulate large chunks of unused pages, we
increase
the chance that paging will occur on the system.  But because
paging
is
a
system-wide activity, it can hit our various processes in
unpredictable
ways
- and this leads to jank.  I think the jank is worse than the
benchmark
win.
I wish we had a better way to quantify the damage caused by
paging.
 Jim
and
others are working on that.
But it's clear to me that we're just being a memory pig for what
is
really a
modest gain on a semi-obscure benchmark right now.  Using the
current
algorithms, we have literally multi-hundred megabyte memory usage
swings
in
exchange for 3% on a benchmark.  Don't you agree this is the
wrong
tradeoff?
 (DOM benchmark grows to 500+MB right now; when you switch tabs
it
drops
to
100MB).  Other pages have been witnessed which have similar
behavior
(loading the histograms page).
We may be able to put in some algorithms which are more aware of
the
current
available memory going forward, but I agree with Jim that there
will
be
a
lot of negative effects as long as we continue to have such large

[chromium-dev] Re: [Memory] in TCMalloc, more careful handling of VirtualAlloc commit via SystemAlloc

2009-10-01 Thread Vitaly Repeshko


On Thu, Oct 1, 2009 at 4:44 PM, Anton Muhin ant...@chromium.org wrote:
 Guys, just to summarize the discussion.

 There are several ways we can tweak tcmalloc:

 1) decommit everything what is free;
 2) keep spans with a mixed state (some pages committed, some not,
 coalescing nor commit, not decommits)---that should solve main Jim's
 argument;
 3) commit on coalescing, but aggressively purge (like WebKit do, once
 in 5 secs unless something else has been committed, or in idle pauses.

 To my knowledge performance-wise 1) is slower (how slower we should
 learn), 2) is slightly faster than 3) (but it might be just a
 statistical error).  Of course, my benchmark is quite special.

 Memory-wise I think 2) and 3) with aggressive scavenging should be
 mostly the same---we could keep higher number of committed pages than
 in 1), but for short periods of time and I'm not convinced it's a bad
 thing.

 Overall I'm pro 2) and 3), but I am definitely biased.

 What do you think?
[...]

I'd like to explain in what way decomitting everything (option #1
above) is slow. This hurts us most during garbage collection in V8.
When a DOM wrapper is collected the C++ DOM object that it wraps gets
deleted and we decommit memory (usually only to commit some of it
later). So we add extra low-level memory management cost to garbage
collections, which ideally should be as fast as possible to avoid
hurting interactivity of the browser. This is one of the reasons to
avoid aggressive decomitting.

So I think having something like #2 with periodic onidle decommits
like #3 should be good both for performance in bechmarks and real apps
and for memory usage.


-- Vitaly

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: [Memory] in TCMalloc, more careful handling of VirtualAlloc commit via SystemAlloc


And we pay when allocating---blocks need to be committed first.

yours,
anton.

On Thu, Oct 1, 2009 at 5:14 PM, Vitaly Repeshko vita...@chromium.org wrote:
 On Thu, Oct 1, 2009 at 4:44 PM, Anton Muhin ant...@chromium.org wrote:
 Guys, just to summarize the discussion.

 There are several ways we can tweak tcmalloc:

 1) decommit everything what is free;
 2) keep spans with a mixed state (some pages committed, some not,
 coalescing nor commit, not decommits)---that should solve main Jim's
 argument;
 3) commit on coalescing, but aggressively purge (like WebKit do, once
 in 5 secs unless something else has been committed, or in idle pauses.

 To my knowledge performance-wise 1) is slower (how slower we should
 learn), 2) is slightly faster than 3) (but it might be just a
 statistical error).  Of course, my benchmark is quite special.

 Memory-wise I think 2) and 3) with aggressive scavenging should be
 mostly the same---we could keep higher number of committed pages than
 in 1), but for short periods of time and I'm not convinced it's a bad
 thing.

 Overall I'm pro 2) and 3), but I am definitely biased.

 What do you think?
 [...]

 I'd like to explain in what way decomitting everything (option #1
 above) is slow. This hurts us most during garbage collection in V8.
 When a DOM wrapper is collected the C++ DOM object that it wraps gets
 deleted and we decommit memory (usually only to commit some of it
 later). So we add extra low-level memory management cost to garbage
 collections, which ideally should be as fast as possible to avoid
 hurting interactivity of the browser. This is one of the reasons to
 avoid aggressive decomitting.

 So I think having something like #2 with periodic onidle decommits
 like #3 should be good both for performance in bechmarks and real apps
 and for memory usage.


 -- Vitaly


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: [Memory] in TCMalloc, more careful handling of VirtualAlloc commit via SystemAlloc

2009-10-01 Thread Marc-Antoine Ruel


[uninformed question]

From a quick search, when you're talking about decommit, you seem to
always use MEM_DECOMMIT instead of MEM_RELEASE; I see no MEM_RELEASE
in tcmalloc.

You do leak the reserved pages or are they first reused? What I am
referring to is to a potential virtual address space leak. Is
VirtualAlloc bright enough to reuse the reserved pages first?

M-A

On Thu, Oct 1, 2009 at 9:18 AM, Anton Muhin ant...@chromium.org wrote:

 And we pay when allocating---blocks need to be committed first.

 yours,
 anton.

 On Thu, Oct 1, 2009 at 5:14 PM, Vitaly Repeshko vita...@chromium.org wrote:
 On Thu, Oct 1, 2009 at 4:44 PM, Anton Muhin ant...@chromium.org wrote:
 Guys, just to summarize the discussion.

 There are several ways we can tweak tcmalloc:

 1) decommit everything what is free;
 2) keep spans with a mixed state (some pages committed, some not,
 coalescing nor commit, not decommits)---that should solve main Jim's
 argument;
 3) commit on coalescing, but aggressively purge (like WebKit do, once
 in 5 secs unless something else has been committed, or in idle pauses.

 To my knowledge performance-wise 1) is slower (how slower we should
 learn), 2) is slightly faster than 3) (but it might be just a
 statistical error).  Of course, my benchmark is quite special.

 Memory-wise I think 2) and 3) with aggressive scavenging should be
 mostly the same---we could keep higher number of committed pages than
 in 1), but for short periods of time and I'm not convinced it's a bad
 thing.

 Overall I'm pro 2) and 3), but I am definitely biased.

 What do you think?
 [...]

 I'd like to explain in what way decomitting everything (option #1
 above) is slow. This hurts us most during garbage collection in V8.
 When a DOM wrapper is collected the C++ DOM object that it wraps gets
 deleted and we decommit memory (usually only to commit some of it
 later). So we add extra low-level memory management cost to garbage
 collections, which ideally should be as fast as possible to avoid
 hurting interactivity of the browser. This is one of the reasons to
 avoid aggressive decomitting.

 So I think having something like #2 with periodic onidle decommits
 like #3 should be good both for performance in bechmarks and real apps
 and for memory usage.


 -- Vitaly


 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: [Memory] low memory callback


Thanks a lot for pointing that out.

yours,
anton.

On Thu, Oct 1, 2009 at 6:20 PM, Marc-Antoine Ruel mar...@chromium.org wrote:
 If you add this functionality, you should add this to SystemMonitor in
 src/base/system_monitor.h

 On Thu, Oct 1, 2009 at 9:17 AM, Anton Muhin ant...@chromium.org wrote:

 Dear chromers!

 Do we have some notification mechanism for low memory event?

 If not, are you fine if I add it?  It would be completely optional and
 I would only implement it for tcmalloc (most probably invoking before
 TCMalloc_SystemAlloc another block).

 If you're interested in details.
 http://code.google.com/p/chromium/issues/detail?id=16821 is due to
 retaining WebKit objects due to no GC---allocation rate in V8 heaps is
 ways lower than allocation in tcmalloc heap and thus we die.  The idea
 is to use this callback to trigger callback.

 Mads says that we have something like that for Android already.

 yours,
 anton.

 



--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: XP Perf page load regression on morejs and moz page cyclers

2009-10-01 Thread Darin Fisher

Note: my change was reverted for other reasons.-Darin

On Thu, Oct 1, 2009 at 7:58 AM, Chase Phillips ch...@chromium.org wrote:

 Hey everyone,
 A performance regression has appeared on the XP Perf bot in the morejs page
 cycler.  Along with turning XP Perf red, the perf regression system notified
 me via email (forwarded below).  The page load regression is about 30ms.
  There's a similar regression in the moz page cycler.  Here's a link to the
 XP Perf dashboard to see the morejs regression:

 http://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=50

 The interesting revisions between r27704 and r27710 are:

   r27705 - darin - Move various methods from glue to 
 api.http://src.chromium.org/viewvc/chrome?view=revrevision=27705
   r27708 - jar - Set JEMalloc as the default allocator (instead of
 TCMalloc). http://src.chromium.org/viewvc/chrome?view=revrevision=27708
   r27710 - thestig - Disable CheckSvnModifiedDirectories for 
 now.http://src.chromium.org/viewvc/chrome?view=revrevision=27710

 @jar: Not meaning to pick on you, but my guess is the JEMalloc change is
 the cause.  Did you expect a page load regression from your change?

 PS If you haven't heard of this perf regression system, don't worry -- it's
 a new tool in Chromium's toolbox.  Email and docs describing it will be sent
 soon.

 Thanks,
 Chase

 -- Forwarded message --
 From: build...@chromium.org
 Date: Thu, Oct 1, 2009 at 7:15 AM
 Subject: buildbot failure in Chromium on XP Perf, revision 27719
 To: c...@google.com


  http://build.chromium.org/buildbot/waterfall/

 Perf alert on XP Perf: page_cycler_morejs

 http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414

 Revision: 27719
 Blame list: ida...@google.com

  XP Perf
 Build 
 9414http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414
 svnkill
 stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/shell/logs/stdio
   update
 scripts
 stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/shell_2/logs/stdio
 taskkill
 stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/shell_3/logs/stdio
 update
 stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/gclient/logs/stdio
   extract
 build
 stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/extract%20build/logs/stdio
   Start
 Crash Handler
 stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/Start%20Crash%20Handler/logs/stdio
 uploading
 perf_expectations.json  page_cycler_moz

 IO_b_b: 41.8k (39.7k)
 IO_b_b_extcs1: 41.8k
 IO_b_r: 6.74k (6.0k)
 IO_b_r_extcs1: 6.62k
 IO_op_b: 51.6k (51.8k)
 IO_op_b_extcs1: 55.0k
 IO_op_r: 25.3k (28.3k)
 IO_op_r_extcs1: 25.2k
 t: 1.08k (1.19k)
 t_extcs1: 1.25k
 vm_pk_b: 8.24M (17.0M)
 vm_pk_b_extcs1: 9.68M
 vm_pk_r: 83.2M (72.9M)
 vm_pk_r_extcs1: 85.6M
 ws_pk_b: 20.0M (24.8M)
 ws_pk_b_extcs1: 21.4M
 ws_pk_r: 75.3M (73.7M)
 ws_pk_r_extcs1: 80.5M

 stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/page_cycler_moz/logs/stdio
 [resultshttp://build.chromium.org/buildbot/perf/xp-release-dual-core/moz/report.html?history=150
 ]  page_cycler_morejs

 PERF_REGRESS: times/t
 IO_b_b: 19.2k (17.5k)
 IO_b_b_extcs1: 19.3k
 IO_b_r: 475 (243)
 IO_b_r_extcs1: 475
 IO_op_b: 20.3k (19.5k)
 IO_op_b_extcs1: 23.4k
 IO_op_r: 9.56k (4.17k)
 IO_op_r_extcs1: 9.56k
 t: 1.4k (1.31k)
 t_extcs1: 1.44k
 vm_pk_b: 7.06M (16.1M)
 vm_pk_b_extcs1: 8.49M
 vm_pk_r: 8.28M (18.0M)
 vm_pk_r_extcs1: 8.3M
 ws_pk_b: 19.0M (23.8M)
 ws_pk_b_extcs1: 20.4M
 ws_pk_r: 12.6M (21.6M)
 ws_pk_r_extcs1: 12.6M

 stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/page_cycler_morejs/logs/stdio
 [resultshttp://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=150
 ]

 Changed by: *ida...@google.com*
 Changed at: *Thu 01 Oct 2009 07:00:09*
 Branch: *src*
 Revision: *27719*

 Changed files:

- *chrome/browser/privacy_blacklist/blocked_response.cc*
- *chrome/browser/privacy_blacklist/blocked_response.h*
- *chrome/browser/resources/privacy_blacklist_block.html*
- *chrome/browser/renderer_host/resource_dispatcher_host.cc*
- *chrome/browser/renderer_host/resource_dispatcher_host.h*

 Comments:

 Privacy Blacklist Unblock

 Summary
 ---

 Mostly implemented the unblocking for visual resources for the Privacy 
 Blacklist.
 Merging now before I leave. Eveything here only has effect if the 
 --privacy-blacklist
 flag specifies a Privacy Blacklist.

 Detailed Changes
 

 [chrome/browser/resources/privacy_blacklist.html]

 - Replaced the about:blank place-holder with variable to set the unblock link.

 - Open the Privacy Blacklist provider page in a new tab. This works around an
   issue where such request for a full-page (rather than a

[chromium-dev] Re: XP Perf page load regression on morejs and moz page cyclers

Probably caused by jemalloc.  Jim was experimenting with the idea of getting
some dev-channel data from using jemalloc as opposed to tcmalloc.  I'm not
surprised there was a perf delta, but I am surprised by how much.  The DOM
benchmark in this test dropped by 8%.  Several other benchmarks took similar
hits.
http://build.chromium.org/buildbot/perf/vista-release-dual-core/dom_perf/report.html?history=150

http://build.chromium.org/buildbot/perf/xp-release-single-core/bloat-http/report.html?history=150

But the memory test does use about 10% less RAM with jemalloc (as
predicted):

http://build.chromium.org/buildbot/perf/vista-release-dual-core/memory/report.html?history=150
And almost all memory tests got better:

http://build.chromium.org/buildbot/perf/dashboard/overview.html?graph=vm_peak_b

So:  tcmalloc == faster; jemalloc == smaller.  We knew this.

I think we should probably back out jemalloc - the perf hit is non-trivial,
and the memory we can improve with other, upcoming tcmalloc work.  Jim - how
badly do you want jemalloc dev-channel data?  I'm not sure it will buy us a
lot other than what we already know.

Mike


On Thu, Oct 1, 2009 at 8:29 AM, Darin Fisher da...@chromium.org wrote:

 Note: my change was reverted for other reasons.-Darin

 On Thu, Oct 1, 2009 at 7:58 AM, Chase Phillips ch...@chromium.org wrote:

 Hey everyone,
 A performance regression has appeared on the XP Perf bot in the morejs
 page cycler.  Along with turning XP Perf red, the perf regression system
 notified me via email (forwarded below).  The page load regression is about
 30ms.  There's a similar regression in the moz page cycler.  Here's a link
 to the XP Perf dashboard to see the morejs regression:

 http://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=50

 The interesting revisions between r27704 and r27710 are:

   r27705 - darin - Move various methods from glue to 
 api.http://src.chromium.org/viewvc/chrome?view=revrevision=27705
   r27708 - jar - Set JEMalloc as the default allocator (instead of
 TCMalloc).http://src.chromium.org/viewvc/chrome?view=revrevision=27708
   r27710 - thestig - Disable CheckSvnModifiedDirectories for 
 now.http://src.chromium.org/viewvc/chrome?view=revrevision=27710

 @jar: Not meaning to pick on you, but my guess is the JEMalloc change is
 the cause.  Did you expect a page load regression from your change?

 PS If you haven't heard of this perf regression system, don't worry --
 it's a new tool in Chromium's toolbox.  Email and docs describing it will be
 sent soon.

 Thanks,
 Chase

 -- Forwarded message --
 From: build...@chromium.org
 Date: Thu, Oct 1, 2009 at 7:15 AM
 Subject: buildbot failure in Chromium on XP Perf, revision 27719
 To: c...@google.com


  http://build.chromium.org/buildbot/waterfall/

 Perf alert on XP Perf: page_cycler_morejs


 http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414

 Revision: 27719
 Blame list: ida...@google.com

  XP Perf
 Build 
 9414http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414
 svnkill
 stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/shell/logs/stdio
   update
 scripts
 stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/shell_2/logs/stdio
 taskkill
 stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/shell_3/logs/stdio
 update
 stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/gclient/logs/stdio
   extract
 build
 stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/extract%20build/logs/stdio
   Start
 Crash Handler
 stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/Start%20Crash%20Handler/logs/stdio
 uploading
 perf_expectations.json  page_cycler_moz

 IO_b_b: 41.8k (39.7k)
 IO_b_b_extcs1: 41.8k
 IO_b_r: 6.74k (6.0k)
 IO_b_r_extcs1: 6.62k
 IO_op_b: 51.6k (51.8k)
 IO_op_b_extcs1: 55.0k
 IO_op_r: 25.3k (28.3k)
 IO_op_r_extcs1: 25.2k
 t: 1.08k (1.19k)
 t_extcs1: 1.25k
 vm_pk_b: 8.24M (17.0M)
 vm_pk_b_extcs1: 9.68M
 vm_pk_r: 83.2M (72.9M)
 vm_pk_r_extcs1: 85.6M
 ws_pk_b: 20.0M (24.8M)
 ws_pk_b_extcs1: 21.4M
 ws_pk_r: 75.3M (73.7M)
 ws_pk_r_extcs1: 80.5M

 stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/page_cycler_moz/logs/stdio
 [resultshttp://build.chromium.org/buildbot/perf/xp-release-dual-core/moz/report.html?history=150
 ]  page_cycler_morejs

 PERF_REGRESS: times/t
 IO_b_b: 19.2k (17.5k)
 IO_b_b_extcs1: 19.3k
 IO_b_r: 475 (243)
 IO_b_r_extcs1: 475
 IO_op_b: 20.3k (19.5k)
 IO_op_b_extcs1: 23.4k
 IO_op_r: 9.56k (4.17k)
 IO_op_r_extcs1: 9.56k
 t: 1.4k (1.31k)
 t_extcs1: 1.44k
 vm_pk_b: 7.06M (16.1M)
 vm_pk_b_extcs1: 8.49M
 vm_pk_r: 8.28M (18.0M)
 vm_pk_r_extcs1: 8.3M
 ws_pk_b: 19.0M (23.8M)
 ws_pk_b_extcs1: 20.4M
 ws_pk_r: 12.6M (21.6M)
 ws_pk_r_extcs1: 12.6M

[chromium-dev] Re: [Memory] in TCMalloc, more careful handling of VirtualAlloc commit via SystemAlloc

see about:tcmalloc (credit to sgk) - which dumps the *browser* stats.  We
need to plumb other processes.
Mike


On Thu, Oct 1, 2009 at 8:42 AM, Erik Kay erik...@chromium.org wrote:

 On Wed, Sep 30, 2009 at 11:22 AM, James Robinson jam...@google.com
 wrote:
 
  I agree completely that this seems to be an issue Here's what
 about:tcmalloc
  says about my browser process right now (which is at around 267MB
 according
  to the app's Task Manager):
 
  MALLOC:207097856 (  197.5 MB) Heap size
  MALLOC: 12494760 (   11.9 MB) Bytes in use by application
  MALLOC:188563456 (  179.8 MB) Bytes free in page heap

 This is pretty eye-popping data.

 How expensive is it to compute this data?  Is it something we can
 report back in histograms?  Is it something we can add to some of our
 page cycler tests as perf data so we can track improvements and
 regressions?

 Erik


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: [Memory] in TCMalloc, more careful handling of VirtualAlloc commit via SystemAlloc

I think we have a new constraint which we previously were ignoring.
Spikes in memory usage of 500MB (which could be released) are no longer
tolerable, ever.  (I'd like to get agreement on how to define this - some
amount of cached memory is okay, of course, but 500MB is not).

Some of the algorithms listed have these spikes, others do not.  It is true
that algorithms which are more stable (less spikiness) will generally have
some performance tradeoff.

Mike


On Thu, Oct 1, 2009 at 6:14 AM, Vitaly Repeshko vita...@chromium.orgwrote:

 On Thu, Oct 1, 2009 at 4:44 PM, Anton Muhin ant...@chromium.org wrote:
  Guys, just to summarize the discussion.
 
  There are several ways we can tweak tcmalloc:
 
  1) decommit everything what is free;
  2) keep spans with a mixed state (some pages committed, some not,
  coalescing nor commit, not decommits)---that should solve main Jim's
  argument;
  3) commit on coalescing, but aggressively purge (like WebKit do, once
  in 5 secs unless something else has been committed, or in idle pauses.
 
  To my knowledge performance-wise 1) is slower (how slower we should
  learn), 2) is slightly faster than 3) (but it might be just a
  statistical error).  Of course, my benchmark is quite special.
 
  Memory-wise I think 2) and 3) with aggressive scavenging should be
  mostly the same---we could keep higher number of committed pages than
  in 1), but for short periods of time and I'm not convinced it's a bad
  thing.
 
  Overall I'm pro 2) and 3), but I am definitely biased.
 
  What do you think?
 [...]

 I'd like to explain in what way decomitting everything (option #1
 above) is slow. This hurts us most during garbage collection in V8.
 When a DOM wrapper is collected the C++ DOM object that it wraps gets
 deleted and we decommit memory (usually only to commit some of it
 later). So we add extra low-level memory management cost to garbage
 collections, which ideally should be as fast as possible to avoid
 hurting interactivity of the browser. This is one of the reasons to
 avoid aggressive decomitting.

 So I think having something like #2 with periodic onidle decommits
 like #3 should be good both for performance in bechmarks and real apps
 and for memory usage.


 -- Vitaly


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: [Memory] low memory callback

Sounds good to me - does windows have a good low-memory notification api?

On Thu, Oct 1, 2009 at 7:22 AM, Anton Muhin ant...@chromium.org wrote:


 Thanks a lot for pointing that out.

 yours,
 anton.

 On Thu, Oct 1, 2009 at 6:20 PM, Marc-Antoine Ruel mar...@chromium.org
 wrote:
  If you add this functionality, you should add this to SystemMonitor in
  src/base/system_monitor.h
 
  On Thu, Oct 1, 2009 at 9:17 AM, Anton Muhin ant...@chromium.org wrote:
 
  Dear chromers!
 
  Do we have some notification mechanism for low memory event?
 
  If not, are you fine if I add it?  It would be completely optional and
  I would only implement it for tcmalloc (most probably invoking before
  TCMalloc_SystemAlloc another block).
 
  If you're interested in details.
  http://code.google.com/p/chromium/issues/detail?id=16821 is due to
  retaining WebKit objects due to no GC---allocation rate in V8 heaps is
  ways lower than allocation in tcmalloc heap and thus we die.  The idea
  is to use this callback to trigger callback.
 
  Mads says that we have something like that for Android already.
 
  yours,
  anton.
 
  
 
 

 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: [Memory] low memory callback

2009-10-01 Thread Adam Langley


On Thu, Oct 1, 2009 at 9:06 AM, Mike Belshe mbel...@google.com wrote:
 Sounds good to me - does windows have a good low-memory notification api?

http://msdn.microsoft.com/en-us/library/aa366541(VS.85,loband).aspx


AGL

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: [Memory] in TCMalloc, more careful handling of VirtualAlloc commit via SystemAlloc

2009-10-01 Thread Erik Kay


On Thu, Oct 1, 2009 at 8:49 AM, Mike Belshe mbel...@google.com wrote:
 see about:tcmalloc (credit to sgk) - which dumps the *browser* stats.  We
 need to plumb other processes.

This is really cool.  My question of cost to compute was whether it
makes sense to get this into end-user histograms, or if we can measure
this periodically over a page cycler run.

As you say, getting it into the other processes seems like the higher priority.

Erik


 Mike

 On Thu, Oct 1, 2009 at 8:42 AM, Erik Kay erik...@chromium.org wrote:

 On Wed, Sep 30, 2009 at 11:22 AM, James Robinson jam...@google.com
 wrote:
 
  I agree completely that this seems to be an issue Here's what
  about:tcmalloc
  says about my browser process right now (which is at around 267MB
  according
  to the app's Task Manager):
 
  MALLOC:    207097856 (  197.5 MB) Heap size
  MALLOC:     12494760 (   11.9 MB) Bytes in use by application
  MALLOC:    188563456 (  179.8 MB) Bytes free in page heap

 This is pretty eye-popping data.

 How expensive is it to compute this data?  Is it something we can
 report back in histograms?  Is it something we can add to some of our
 page cycler tests as perf data so we can track improvements and
 regressions?

 Erik



--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: gclient fails to update gyp files

2009-10-01 Thread Dominic Mazzoni


Thanks, this works for me too!

Is there a change needed so that either (1) native_client is not
required, or (2) the tarball doesn't exclude native client?

- Dominic

On Tue, Sep 29, 2009 at 12:45 PM, Nicolas Sylvain nsylv...@chromium.org wrote:
 you need to edit your .gclient and remove the line that says:
  src/native_client: None
 Is native_client really required? Why? We don't want to build this by
 default, do we?
 it's too big and it does not fit in the tarball, so it has been excluded
 there.
 Nicolas


 On Tue, Sep 29, 2009 at 12:40 PM, Thomas Van Lenten thoma...@chromium.org
 wrote:

 It's not in src.chromium.org, it comes in via DEPS:
   src/native_client:
     http://nativeclient.googlecode.com/svn/trunk/src/native_cli...@797;,
 TVL

 On Tue, Sep 29, 2009 at 3:32 PM, Nebojša Ćirić c...@chromium.org wrote:

 Hi Nick,
  As Chris said, src/native_client is missing from the trunk (and I don't
 have it in my client).
 Cira

 On Tue, Sep 29, 2009 at 12:28 PM, Nick Carter n...@chromium.org wrote:

 FWIW, on my (healthy) client, svn info inside of the native_client dir
 looks like:
 ncarter /cygdrive/d/src/crgit/src/native_client/src
 $ svn info
 Path: .
 URL: http://nativeclient.googlecode.com/svn/trunk/src/native_client/src
 Repository Root: http://nativeclient.googlecode.com/svn
 Repository UUID: fcba33aa-ac0c-11dd-b9e7-8d5594d729c2
 Revision: 730
 Node Kind: directory
 Schedule: normal
 Last Changed Author: kschi...@google.com
 Last Changed Rev: 728
 Last Changed Date: 2009-09-16 14:58:52 -0700 (Wed, 16 Sep 2009)
 How does that compare with your checkout?
  - nick
 On Tue, Sep 29, 2009 at 12:23 PM, Nebojša Ćirić c...@chromium.org
 wrote:

 Still the same message (after gclient sync --force).

 On Tue, Sep 29, 2009 at 10:53 AM, Mark Mentovai m...@chromium.org
 wrote:

 gclient may have gotten confused in a previous run.  Try gclient sync
 --force and let us know if you still have a problem with that.

 Mark










 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Native Client in Cross Compile

2009-10-01 Thread Daniel


I'm trying to cross compile chromium to ARM, but I'm getting errors in
the native client code.

./native_client/src/include/elf.h:68:3: error: #error
NACL_TARGET_SUBARCH must be defined to be 32 or 64

It looks like I have to have the same build and target architectures
in order to work properly. Is there a way to turn off native client?
I've cross-compiled earlier versions without a problem, but it looks
like a change occurred in some of the files. Any way to get around
this problem?

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] buildbot tips: applying a patch to all of your builders' source trees

2009-10-01 Thread Chase Phillips

Hello everyone, if you haven't set up your own Chromium Buildbot before or
don't plan to, you can stop reading now.
I've added a Buildbot tips page to the Chromium dev site:
http://sites.google.com/a/chromium.org/dev/developers/testing/chromium-build-infrastructure/tips

The first tip describes how to rig your Buildbot to apply a patch to all of
your builders' source trees.  I hope in time that other useful Buildbot tips
get noted here.  Feel free to add your own or let me know so I can add them.

Thanks,
Chase

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: gclient fails to update gyp files

2009-10-01 Thread Chris Guillory

Dominic and I starting running into this today also. We both don't have the
src/native_client directory. And I don't see it listed in the directory list
at http://src.chromium.org/svn/trunk/src/.
On Tue, Sep 29, 2009 at 10:53 AM, Mark Mentovai m...@chromium.org wrote:


 gclient may have gotten confused in a previous run.  Try gclient sync
 --force and let us know if you still have a problem with that.

 Mark

 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Extracting Webkit Test Shell and its dependencies

2009-10-01 Thread plafayette


Is there a good, and less painful, way to extract test_shell into its
own project? I'm going to be tweaking the Webkit rendering engine and
a stripped down browser is exactly what I need for testing.

Thanks.
Pierre.

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: gclient fails to update gyp files


I got the same error. The solution is to edit the .gclient file and
comment out the line containing the native_client module:

 #src/native_client: None,


On Sep 29, 9:56 am, Thomas Van Lenten thoma...@chromium.org wrote:
 Did you get any errors in the gclient sync?  There is an entry for that dir
 within the DEPs file.
 TVL



 On Tue, Sep 29, 2009 at 12:52 PM, Nebojša Ćirić c...@chromium.org wrote:
  This is a (read-only) client that synced without problems 4 days ago. Today
  gclient sync failed with:

   running '/usr/bin/python src/build/gyp_chromium' in
  '/home/nebojsa/chromium'
  Updating projects from gyp files...
  Traceback (most recent call last):
    File src/build/gyp_chromium, line 78, in module
      sys.exit(gyp.main(args))
    File src/tools/gyp/pylib/gyp/__init__.py, line 406, in main
      params, options.check)
    File src/tools/gyp/pylib/gyp/__init__.py, line 76, in Load
      depth, generator_input_info, check)
    File src/tools/gyp/pylib/gyp/input.py, line 1844, in Load
      depth, check)
    File src/tools/gyp/pylib/gyp/input.py, line 342, in LoadTargetBuildFile
      includes, depth, check)
    File src/tools/gyp/pylib/gyp/input.py, line 342, in LoadTargetBuildFile
      includes, depth, check)
    File src/tools/gyp/pylib/gyp/input.py, line 278, in LoadTargetBuildFile
      includes, True, check)
    File src/tools/gyp/pylib/gyp/input.py, line 170, in LoadOneBuildFile
      raise Exception(%s not found (cwd: %s) % (build_file_path,
  os.getcwd()))
  Exception:
  /home/nebojsa/chromium/src/native_client/src/trusted/plugin/plugin_chrome.g 
  yp
  not found (cwd: /home/nebojsa/chromium) while loading dependencies of
  /home/nebojsa/chromium/src/chrome/chrome.gyp while loading dependencies of
  /home/nebojsa/chromium/src/build/all.gyp while trying to load
  src/build/all.gyp
  failed to run command: /usr/bin/python src/build/gyp_chromium

  I am on amd64 machine, Ubuntu 9.04.

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Extracting Webkit Test Shell and its dependencies

2009-10-01 Thread Peter Kasting

On Wed, Sep 30, 2009 at 4:06 AM, plafayette pierre.lafaye...@gmail.comwrote:

 Is there a good, and less painful, way to extract test_shell into its
 own project?


I don't understand.  test_shell already is its own project (.vcproj).

PK

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Server full?

2009-10-01 Thread Daniel


I can't seem to even do a gclient config with getting the error:
svn: Can't find a temporary directory: Internal error

Googling around seems to indicate that the server disk space is full.
Is there an issue on the server? Or is there something I can do on my
end?

Daniel

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: XP Perf page load regression on morejs and moz page cyclers

2009-10-01 Thread Jim Roskind

I'm quite sure it is jemalloc. I failed miserably by not over-communicating
this checkin. My apologies to all that I have inconvenience.
We have just this week identified a number of misteps in our use of
TCMalloc. I think that we can eventually reach an excellent result with
TCMalloc... and we had a few fixes... but we also wanted to be able to talk
more precisely about how things contrast with jemalloc (as folks ask us why
we're looking so intently at tcmalloc).

If folks are cool with it, it might be interesting to push the dev build
with this in place. JEMalloc appears to be very conservative in its memory
usage, but doesn't get the speed we've seen with TCMalloc. We can already
see some specific areas where the current (checked in) incarnation of
TCMalloc stumbles (example: today, TCMalloc never decommits memory in the
browser process... yeah... that's just a bug... but I was wondering how much
it hurt... and a switch to jemalloc would instantly provide a temporary
fix). It may be interesting to see the response on the dev channel to this
temporary change.

Side benefits include some feedback on crashers, as each allocator
illuminates a different set of corruption problems (if we have any :-) ).

Do other folks agree it would be interesting to see a dev build go out with
this in place??

Thanks,

Jim

On Thu, Oct 1, 2009 at 8:46 AM, Mike Belshe mbel...@google.com wrote:

Probably caused by jemalloc. Jim was experimenting with the idea of
getting some dev-channel data from using jemalloc as opposed to tcmalloc.
I'm not surprised there was a perf delta, but I am surprised by how much.
The DOM benchmark in this test dropped by 8%. Several other benchmarks
took similar hits.
http://build.chromium.org/buildbot/perf/vista-release-dual-core/dom_perf/report.html?history=150

http://build.chromium.org/buildbot/perf/xp-release-single-core/bloat-http/report.html?history=150

But the memory test does use about 10% less RAM with jemalloc (as
predicted):

http://build.chromium.org/buildbot/perf/vista-release-dual-core/memory/report.html?history=150
And almost all memory tests got better:

http://build.chromium.org/buildbot/perf/dashboard/overview.html?graph=vm_peak_b

So: tcmalloc == faster; jemalloc == smaller. We knew this.

I think we should probably back out jemalloc - the perf hit is non-trivial,
and the memory we can improve with other, upcoming tcmalloc work. Jim - how
badly do you want jemalloc dev-channel data? I'm not sure it will buy us a
lot other than what we already know.

Mike

On Thu, Oct 1, 2009 at 8:29 AM, Darin Fisher da...@chromium.org wrote:

Note: my change was reverted for other reasons.-Darin

On Thu, Oct 1, 2009 at 7:58 AM, Chase Phillips ch...@chromium.orgwrote:

Hey everyone,
A performance regression has appeared on the XP Perf bot in the morejs
page cycler. Along with turning XP Perf red, the perf regression system
notified me via email (forwarded below). The page load regression is about
30ms. There's a similar regression in the moz page cycler. Here's a link
to the XP Perf dashboard to see the morejs regression:

http://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=50

The interesting revisions between r27704 and r27710 are:

r27705 - darin - Move various methods from glue to
api.http://src.chromium.org/viewvc/chrome?view=revrevision=27705
r27708 - jar - Set JEMalloc as the default allocator (instead of
TCMalloc).http://src.chromium.org/viewvc/chrome?view=revrevision=27708
r27710 - thestig - Disable CheckSvnModifiedDirectories for
now.http://src.chromium.org/viewvc/chrome?view=revrevision=27710

@jar: Not meaning to pick on you, but my guess is the JEMalloc change is
the cause. Did you expect a page load regression from your change?

PS If you haven't heard of this perf regression system, don't worry --
it's a new tool in Chromium's toolbox. Email and docs describing it will be
sent soon.

Thanks,
Chase

-- Forwarded message --
From: build...@chromium.org
Date: Thu, Oct 1, 2009 at 7:15 AM
Subject: buildbot failure in Chromium on XP Perf, revision 27719
To: c...@google.com

http://build.chromium.org/buildbot/waterfall/

Perf alert on XP Perf: page_cycler_morejs

http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414

Revision: 27719
Blame list: ida...@google.com

XP Perf
Build
9414http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414
svnkill
stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/shell/logs/stdio
update
scripts
stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/shell_2/logs/stdio
taskkill
stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/shell_3/logs/stdio
update
stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/gclient/logs/stdio

[chromium-dev] Re: gclient fails to update gyp files

2009-10-01 Thread Nicolas Sylvain

On Tue, Sep 29, 2009 at 11:37 AM, Chris Guillory ctg...@google.com wrote:

 Dominic and I starting running into this today also. We both don't have the
 src/native_client directory. And I don't see it listed in the directory list
 at http://src.chromium.org/svn/trunk/src/.

gclient update will fetch it since it's in the DEPS file.

If you downloaded the tarball, we had the .gclient file set up to explicitly
ignore this dependency.

This should now be fixed for people who are downloading the tarball today.

Nicolas





 On Tue, Sep 29, 2009 at 10:53 AM, Mark Mentovai m...@chromium.org wrote:


 gclient may have gotten confused in a previous run.  Try gclient sync
 --force and let us know if you still have a problem with that.

 Mark




 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: [Memory] low memory callback

2009-10-01 Thread Peter Kasting

On Thu, Oct 1, 2009 at 6:17 AM, Anton Muhin ant...@chromium.org wrote:

 Dear chromers!

 Do we have some notification mechanism for low memory event?

 If not, are you fine if I add it?  It would be completely optional and
 I would only implement it for tcmalloc (most probably invoking before
 TCMalloc_SystemAlloc another block).


You should track the work I'm about to do with MemoryPurger, a class that
is designed to dump memory from everywhere possible.  I am initially going
to implement it to do this when the system is about to sleep.  Doing part of
this on low memory, or after long idle, or after background renderers get
paged out, is also a useful area of investigation.

The CL to add the initial, do-nothing framework will go up for review
shortly.

PK

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] XP Perf page load regression on morejs and moz page cyclers

2009-10-01 Thread Chase Phillips

Hey everyone,
A performance regression has appeared on the XP Perf bot in the morejs page
cycler.  Along with turning XP Perf red, the perf regression system notified
me via email (forwarded below).  The page load regression is about 30ms.
 There's a similar regression in the moz page cycler.  Here's a link to the
XP Perf dashboard to see the morejs regression:
http://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=50

The interesting revisions between r27704 and r27710 are:

  r27705 - darin - Move various methods from glue to
api.http://src.chromium.org/viewvc/chrome?view=revrevision=27705
  r27708 - jar - Set JEMalloc as the default allocator (instead of
TCMalloc). http://src.chromium.org/viewvc/chrome?view=revrevision=27708
  r27710 - thestig - Disable CheckSvnModifiedDirectories for
now.http://src.chromium.org/viewvc/chrome?view=revrevision=27710

@jar: Not meaning to pick on you, but my guess is the JEMalloc change is the
cause.  Did you expect a page load regression from your change?

PS If you haven't heard of this perf regression system, don't worry -- it's
a new tool in Chromium's toolbox.  Email and docs describing it will be sent
soon.

Thanks,
Chase

-- Forwarded message --
From: build...@chromium.org
Date: Thu, Oct 1, 2009 at 7:15 AM
Subject: buildbot failure in Chromium on XP Perf, revision 27719
To: c...@google.com


 http://build.chromium.org/buildbot/waterfall/

Perf alert on XP Perf: page_cycler_morejs

http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414

Revision: 27719
Blame list: ida...@google.com

 XP Perf
Build 
9414http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414
svnkill
stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/shell/logs/stdio
 update
scripts
stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/shell_2/logs/stdio
taskkill
stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/shell_3/logs/stdio
update
stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/gclient/logs/stdio
 extract
build
stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/extract%20build/logs/stdio
 Start
Crash Handler
stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/Start%20Crash%20Handler/logs/stdio
uploading
perf_expectations.json  page_cycler_moz

IO_b_b: 41.8k (39.7k)
IO_b_b_extcs1: 41.8k
IO_b_r: 6.74k (6.0k)
IO_b_r_extcs1: 6.62k
IO_op_b: 51.6k (51.8k)
IO_op_b_extcs1: 55.0k
IO_op_r: 25.3k (28.3k)
IO_op_r_extcs1: 25.2k
t: 1.08k (1.19k)
t_extcs1: 1.25k
vm_pk_b: 8.24M (17.0M)
vm_pk_b_extcs1: 9.68M
vm_pk_r: 83.2M (72.9M)
vm_pk_r_extcs1: 85.6M
ws_pk_b: 20.0M (24.8M)
ws_pk_b_extcs1: 21.4M
ws_pk_r: 75.3M (73.7M)
ws_pk_r_extcs1: 80.5M

stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/page_cycler_moz/logs/stdio
[resultshttp://build.chromium.org/buildbot/perf/xp-release-dual-core/moz/report.html?history=150
]  page_cycler_morejs

PERF_REGRESS: times/t
IO_b_b: 19.2k (17.5k)
IO_b_b_extcs1: 19.3k
IO_b_r: 475 (243)
IO_b_r_extcs1: 475
IO_op_b: 20.3k (19.5k)
IO_op_b_extcs1: 23.4k
IO_op_r: 9.56k (4.17k)
IO_op_r_extcs1: 9.56k
t: 1.4k (1.31k)
t_extcs1: 1.44k
vm_pk_b: 7.06M (16.1M)
vm_pk_b_extcs1: 8.49M
vm_pk_r: 8.28M (18.0M)
vm_pk_r_extcs1: 8.3M
ws_pk_b: 19.0M (23.8M)
ws_pk_b_extcs1: 20.4M
ws_pk_r: 12.6M (21.6M)
ws_pk_r_extcs1: 12.6M

stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/page_cycler_morejs/logs/stdio
[resultshttp://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=150
]

Changed by: *ida...@google.com*
Changed at: *Thu 01 Oct 2009 07:00:09*
Branch: *src*
Revision: *27719*

Changed files:

   - *chrome/browser/privacy_blacklist/blocked_response.cc*
   - *chrome/browser/privacy_blacklist/blocked_response.h*
   - *chrome/browser/resources/privacy_blacklist_block.html*
   - *chrome/browser/renderer_host/resource_dispatcher_host.cc*
   - *chrome/browser/renderer_host/resource_dispatcher_host.h*

Comments:

Privacy Blacklist Unblock

Summary
---

Mostly implemented the unblocking for visual resources for the Privacy
Blacklist.
Merging now before I leave. Eveything here only has effect if the
--privacy-blacklist
flag specifies a Privacy Blacklist.

Detailed Changes


[chrome/browser/resources/privacy_blacklist.html]

- Replaced the about:blank place-holder with variable to set the unblock link.

- Open the Privacy Blacklist provider page in a new tab. This works around an
  issue where such request for a full-page (rather than a sub-resource) gets
  blocked indefinitely.

[chrome/browser/render_host/resource_dispatcher_host.h]

- Added a BlockedResponse member which is now a class rather than a namespace,
  see below for more information.

[chromium-dev] dev.chromium.org problems

2009-10-01 Thread Ian Fette


In preparation for a re-organization, I added a second mapping for the
google sites page that dev.chromium.org points to. Somehow, this seems
to have broken the first mapping of dev.chromium.org. I am reaching
out to the team, in the meantime if dev.chromium.org gives you errors,
all of the content is accessible at
http://sites.google.com/a/chromium.org/dev/

Thanks,
Ian

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: [Memory] in TCMalloc, more careful handling of VirtualAlloc commit via SystemAlloc

2009-10-01 Thread cpu


Did somebody answer Marc-Antoine question?

I don't see us ever releasing pages. I can fathom that we are not
doing that so I must be reading the code wrong.


On Oct 1, 10:11 am, Erik Kay erik...@chromium.org wrote:
 On Thu, Oct 1, 2009 at 8:49 AM, Mike Belshe mbel...@google.com wrote:
  see about:tcmalloc (credit to sgk) - which dumps the *browser* stats.  We
  need to plumb other processes.

 This is really cool.  My question of cost to compute was whether it
 makes sense to get this into end-user histograms, or if we can measure
 this periodically over a page cycler run.

 As you say, getting it into the other processes seems like the higher 
 priority.

 Erik



  Mike

  On Thu, Oct 1, 2009 at 8:42 AM, Erik Kay erik...@chromium.org wrote:

  On Wed, Sep 30, 2009 at 11:22 AM, James Robinson jam...@google.com
  wrote:

   I agree completely that this seems to be an issue Here's what
   about:tcmalloc
   says about my browser process right now (which is at around 267MB
   according
   to the app's Task Manager):

   MALLOC:    207097856 (  197.5 MB) Heap size
   MALLOC:     12494760 (   11.9 MB) Bytes in use by application
   MALLOC:    188563456 (  179.8 MB) Bytes free in page heap

  This is pretty eye-popping data.

  How expensive is it to compute this data?  Is it something we can
  report back in histograms?  Is it something we can add to some of our
  page cycler tests as perf data so we can track improvements and
  regressions?

  Erik
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: [Memory] in TCMalloc, more careful handling of VirtualAlloc commit via SystemAlloc


On Thu, Oct 1, 2009 at 10:18 PM, cpu c...@chromium.org wrote:

 Did somebody answer Marc-Antoine question?

 I don't see us ever releasing pages. I can fathom that we are not
 doing that so I must be reading the code wrong.

What to you mean by release?  decommitting or releasing reserved pages?

If releasing reserved pages, we don't do that, but I never saw
problems with it and if page is only reserved, it has no performance
implications---page is not swapped out/in.

yours,
anton.



 On Oct 1, 10:11 am, Erik Kay erik...@chromium.org wrote:
 On Thu, Oct 1, 2009 at 8:49 AM, Mike Belshe mbel...@google.com wrote:
  see about:tcmalloc (credit to sgk) - which dumps the *browser* stats.  We
  need to plumb other processes.

 This is really cool.  My question of cost to compute was whether it
 makes sense to get this into end-user histograms, or if we can measure
 this periodically over a page cycler run.

 As you say, getting it into the other processes seems like the higher 
 priority.

 Erik



  Mike

  On Thu, Oct 1, 2009 at 8:42 AM, Erik Kay erik...@chromium.org wrote:

  On Wed, Sep 30, 2009 at 11:22 AM, James Robinson jam...@google.com
  wrote:

   I agree completely that this seems to be an issue Here's what
   about:tcmalloc
   says about my browser process right now (which is at around 267MB
   according
   to the app's Task Manager):

   MALLOC:    207097856 (  197.5 MB) Heap size
   MALLOC:     12494760 (   11.9 MB) Bytes in use by application
   MALLOC:    188563456 (  179.8 MB) Bytes free in page heap

  This is pretty eye-popping data.

  How expensive is it to compute this data?  Is it something we can
  report back in histograms?  Is it something we can add to some of our
  page cycler tests as perf data so we can track improvements and
  regressions?

  Erik
 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: XP Perf page load regression on morejs and moz page cyclers

2009-10-01 Thread Scott Hess

I think we should be willing to take a temporary performance hit on the dev
channel in the interests of generating data which will eventually improve
stability.
Could we set jemalloc on selected renderer processes? I realize that
wouldn't necessarily only impact the target domains, but it might be better
than making the change global.

-scott

On Thu, Oct 1, 2009 at 10:47 AM, Jim Roskind j...@chromium.org wrote:

I'm quite sure it is jemalloc. I failed miserably by not
over-communicating this checkin. My apologies to all that I have
inconvenience.
We have just this week identified a number of misteps in our use of
TCMalloc. I think that we can eventually reach an excellent result with
TCMalloc... and we had a few fixes... but we also wanted to be able to talk
more precisely about how things contrast with jemalloc (as folks ask us why
we're looking so intently at tcmalloc).

Side benefits include some feedback on crashers, as each allocator
illuminates a different set of corruption problems (if we have any :-) ).

Do other folks agree it would be interesting to see a dev build go out with
this in place??

Thanks,

Jim

On Thu, Oct 1, 2009 at 8:46 AM, Mike Belshe mbel...@google.com wrote:

http://build.chromium.org/buildbot/perf/xp-release-single-core/bloat-http/report.html?history=150

But the memory test does use about 10% less RAM with jemalloc (as
predicted):

http://build.chromium.org/buildbot/perf/vista-release-dual-core/memory/report.html?history=150
And almost all memory tests got better:

http://build.chromium.org/buildbot/perf/dashboard/overview.html?graph=vm_peak_b

So: tcmalloc == faster; jemalloc == smaller. We knew this.

I think we should probably back out jemalloc - the perf hit is
non-trivial, and the memory we can improve with other, upcoming tcmalloc
work. Jim - how badly do you want jemalloc dev-channel data? I'm not sure
it will buy us a lot other than what we already know.

Mike

On Thu, Oct 1, 2009 at 8:29 AM, Darin Fisher da...@chromium.org wrote:

Note: my change was reverted for other reasons.-Darin

On Thu, Oct 1, 2009 at 7:58 AM, Chase Phillips ch...@chromium.orgwrote:

http://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=50

The interesting revisions between r27704 and r27710 are:

@jar: Not meaning to pick on you, but my guess is the JEMalloc change is
the cause. Did you expect a page load regression from your change?

PS If you haven't heard of this perf regression system, don't worry --
it's a new tool in Chromium's toolbox. Email and docs describing it will
be
sent soon.

Thanks,
Chase

-- Forwarded message --
From: build...@chromium.org
Date: Thu, Oct 1, 2009 at 7:15 AM
Subject: buildbot failure in Chromium on XP Perf, revision 27719
To: c...@google.com

http://build.chromium.org/buildbot/waterfall/

Perf alert on XP Perf: page_cycler_morejs

http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414

Revision: 27719
Blame list: ida...@google.com

XP Perf
Build
9414http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414
svnkill

[chromium-dev] Re: XP Perf page load regression on morejs and moz page cyclers

On Thu, Oct 1, 2009 at 11:27 AM, Scott Hess sh...@chromium.org wrote:

It can be set by a per-process environment variable. So... yes, this could
be done. Mix-and-match allocators might be a little strange for anything
other than debugging/testing.

Mike

-scott

On Thu, Oct 1, 2009 at 10:47 AM, Jim Roskind j...@chromium.org wrote:

I'm quite sure it is jemalloc. I failed miserably by not
over-communicating this checkin. My apologies to all that I have
inconvenience.
We have just this week identified a number of misteps in our use of
TCMalloc. I think that we can eventually reach an excellent result with
TCMalloc... and we had a few fixes... but we also wanted to be able to talk
more precisely about how things contrast with jemalloc (as folks ask us why
we're looking so intently at tcmalloc).

Side benefits include some feedback on crashers, as each allocator
illuminates a different set of corruption problems (if we have any :-) ).

Do other folks agree it would be interesting to see a dev build go out
with this in place??

Thanks,

Jim

On Thu, Oct 1, 2009 at 8:46 AM, Mike Belshe mbel...@google.com wrote:

http://build.chromium.org/buildbot/perf/xp-release-single-core/bloat-http/report.html?history=150

But the memory test does use about 10% less RAM with jemalloc (as
predicted):

http://build.chromium.org/buildbot/perf/vista-release-dual-core/memory/report.html?history=150
And almost all memory tests got better:

http://build.chromium.org/buildbot/perf/dashboard/overview.html?graph=vm_peak_b

So: tcmalloc == faster; jemalloc == smaller. We knew this.

I think we should probably back out jemalloc - the perf hit is
non-trivial, and the memory we can improve with other, upcoming tcmalloc
work. Jim - how badly do you want jemalloc dev-channel data? I'm not sure
it will buy us a lot other than what we already know.

Mike

On Thu, Oct 1, 2009 at 8:29 AM, Darin Fisher da...@chromium.org wrote:

Note: my change was reverted for other reasons.-Darin

On Thu, Oct 1, 2009 at 7:58 AM, Chase Phillips ch...@chromium.orgwrote:

Hey everyone,
A performance regression has appeared on the XP Perf bot in the morejs
page cycler. Along with turning XP Perf red, the perf regression system
notified me via email (forwarded below). The page load regression is
about
30ms. There's a similar regression in the moz page cycler. Here's a link
to the XP Perf dashboard to see the morejs regression:

http://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=50

The interesting revisions between r27704 and r27710 are:

@jar: Not meaning to pick on you, but my guess is the JEMalloc change
is the cause. Did you expect a page load regression from your change?

PS If you haven't heard of this perf regression system, don't worry --
it's a new tool in Chromium's toolbox. Email and docs describing it will
be
sent soon.

Thanks,
Chase

-- Forwarded message --
From: build...@chromium.org
Date: Thu, Oct 1, 2009 at 7:15 AM
Subject: buildbot failure in Chromium on XP Perf, revision 27719
To: c...@google.com

http://build.chromium.org/buildbot/waterfall/

Perf alert on XP Perf:

[chromium-dev] Re: Shouldn't the Mac ignore the platform/win tests?

2009-10-01 Thread Ojan Vafai

They are marked WONTFIX. We run them to ensure they don't crash. This looks
like a bug in run_webkit_tests to me. For tests that are WONTFIX, we
shouldn't care if the expected results are missing.
Seems a bit silly to me that we run them at all though. I would be a fan of
just skipping the platform tests that don't apply to the current platform.
In practice, running them adds maintenance cost and cycle time (although,
very little) but doesn't really catch crashes.
Ojan

On Thu, Oct 1, 2009 at 11:20 AM, Avi Drissman a...@google.com wrote:

 The output of a test run of the Mac pixel tests is at:


 http://build.chromium.org/buildbot/try-server/builders/layout_mac/builds/85/steps/webkit_tests/logs/stdio

 What's weird is the line:

 Missing expected results (2):
   LayoutTests/fast/forms/menulist-style-color.html
   *LayoutTests/platform/win/accessibility/scroll-to-anchor.html*

 Why is it running a platform/win test? That's where the outputs are, and
 not even the ones for the correct platform...

 Avi


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: [Memory] in TCMalloc, more careful handling of VirtualAlloc commit via SystemAlloc

We've been talking about this; Jim is actively researching.
tcmalloc doesn't fully release yet, but it will.  This is second priority to
getting the decommit strategy correct.

Mike


On Thu, Oct 1, 2009 at 11:24 AM, Marc-Antoine Ruel mar...@chromium.orgwrote:


 On Thu, Oct 1, 2009 at 2:22 PM, Anton Muhin ant...@chromium.org wrote:
 
  On Thu, Oct 1, 2009 at 10:18 PM, cpu c...@chromium.org wrote:
 
  Did somebody answer Marc-Antoine question?
 
  I don't see us ever releasing pages. I can fathom that we are not
  doing that so I must be reading the code wrong.
 
  What to you mean by release?  decommitting or releasing reserved pages?
 
  If releasing reserved pages, we don't do that, but I never saw
  problems with it and if page is only reserved, it has no performance
  implications---page is not swapped out/in.
 
  yours,
  anton.

 AFAIK, VAS fragmentation is an issue in the browser. This shouldn't be
 overlooked.

 M-A

  On Oct 1, 10:11 am, Erik Kay erik...@chromium.org wrote:
  On Thu, Oct 1, 2009 at 8:49 AM, Mike Belshe mbel...@google.com
 wrote:
   see about:tcmalloc (credit to sgk) - which dumps the *browser* stats.
  We
   need to plumb other processes.
 
  This is really cool.  My question of cost to compute was whether it
  makes sense to get this into end-user histograms, or if we can measure
  this periodically over a page cycler run.
 
  As you say, getting it into the other processes seems like the higher
 priority.
 
  Erik
 
 
 
   Mike
 
   On Thu, Oct 1, 2009 at 8:42 AM, Erik Kay erik...@chromium.org
 wrote:
 
   On Wed, Sep 30, 2009 at 11:22 AM, James Robinson jam...@google.com
 
   wrote:
 
I agree completely that this seems to be an issue Here's what
about:tcmalloc
says about my browser process right now (which is at around 267MB
according
to the app's Task Manager):
 
MALLOC:207097856 (  197.5 MB) Heap size
MALLOC: 12494760 (   11.9 MB) Bytes in use by application
MALLOC:188563456 (  179.8 MB) Bytes free in page heap
 
   This is pretty eye-popping data.
 
   How expensive is it to compute this data?  Is it something we can
   report back in histograms?  Is it something we can add to some of
 our
   page cycler tests as perf data so we can track improvements and
   regressions?
 
   Erik
  
 
 
  
 

 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Shouldn't the Mac ignore the platform/win tests?

2009-10-01 Thread Avi Drissman

Right now I want to land so I'll file a bug...

Avi

On Thu, Oct 1, 2009 at 2:34 PM, Ojan Vafai o...@chromium.org wrote:

 They are marked WONTFIX. We run them to ensure they don't crash. This looks
 like a bug in run_webkit_tests to me. For tests that are WONTFIX, we
 shouldn't care if the expected results are missing.
 Seems a bit silly to me that we run them at all though. I would be a fan of
 just skipping the platform tests that don't apply to the current platform.
 In practice, running them adds maintenance cost and cycle time (although,
 very little) but doesn't really catch crashes.
 Ojan


 On Thu, Oct 1, 2009 at 11:20 AM, Avi Drissman a...@google.com wrote:

 The output of a test run of the Mac pixel tests is at:


 http://build.chromium.org/buildbot/try-server/builders/layout_mac/builds/85/steps/webkit_tests/logs/stdio

 What's weird is the line:

 Missing expected results (2):
   LayoutTests/fast/forms/menulist-style-color.html
   *LayoutTests/platform/win/accessibility/scroll-to-anchor.html*

 Why is it running a platform/win test? That's where the outputs are, and
 not even the ones for the correct platform...

 Avi




--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: dev.chromium.org problems

2009-10-01 Thread Ian Fette


With help from the Google Sites team, this is now fixed. Sorry for the
inconvenience.

-Ian

2009/10/1 Ian Fette i...@chromium.org:
 In preparation for a re-organization, I added a second mapping for the
 google sites page that dev.chromium.org points to. Somehow, this seems
 to have broken the first mapping of dev.chromium.org. I am reaching
 out to the team, in the meantime if dev.chromium.org gives you errors,
 all of the content is accessible at
 http://sites.google.com/a/chromium.org/dev/

 Thanks,
 Ian


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Shouldn't the Mac ignore the platform/win tests?

2009-10-01 Thread Dirk Pranke

Ojan,

As you know, run_webkit_tests doesn't have the concept of it's okay
that there are no expected results.

Several other people have also mentioned to me that it would be nice
if it did, but I don't feel strongly about it one way or another. I
don't know that I would consider tests marked WONTFIX special in this
regard; tests that are marked FAIL seem like they could also qualify
under some reasoning. If people agree that some form of this would be
a useful feature, I'll be happy to add it.

In the mean time, I agree that marking platform/X as SKIP for all
platforms != X is a very reasonable thing to do.

-- Dirk

On Thu, Oct 1, 2009 at 11:34 AM, Ojan Vafai o...@chromium.org wrote:
They are marked WONTFIX. We run them to ensure they don't crash. This looks
like a bug in run_webkit_tests to me. For tests that are WONTFIX, we
shouldn't care if the expected results are missing.
Seems a bit silly to me that we run them at all though. I would be a fan of
just skipping the platform tests that don't apply to the current platform.
In practice, running them adds maintenance cost and cycle time (although,
very little) but doesn't really catch crashes.
Ojan

On Thu, Oct 1, 2009 at 11:20 AM, Avi Drissman a...@google.com wrote:

The output of a test run of the Mac pixel tests is at:

http://build.chromium.org/buildbot/try-server/builders/layout_mac/builds/85/steps/webkit_tests/logs/stdio

What's weird is the line:

Missing expected results (2):
LayoutTests/fast/forms/menulist-style-color.html
LayoutTests/platform/win/accessibility/scroll-to-anchor.html

Why is it running a platform/win test? That's where the outputs are, and
not even the ones for the correct platform...

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: [Memory] in TCMalloc, more careful handling of VirtualAlloc commit via SystemAlloc

2009-10-01 Thread James Robinson

On Thu, Oct 1, 2009 at 10:11 AM, Erik Kay erik...@chromium.org wrote:


 On Thu, Oct 1, 2009 at 8:49 AM, Mike Belshe mbel...@google.com wrote:
  see about:tcmalloc (credit to sgk) - which dumps the *browser* stats.  We
  need to plumb other processes.

 This is really cool.  My question of cost to compute was whether it
 makes sense to get this into end-user histograms, or if we can measure
 this periodically over a page cycler run.


Ideally yes.  I think the best way forward at this point is to define a set
of clear, measurable criteria and then try out different allocator schemes
to see what makes sense.  I'd propose the following as a starting point:

1.) Minimal performance impact
2.) Amount of committed memory never exceeds memory used by the application
by more than X% for more than Y seconds
3.) Peak memory usage on benchmark never exceeds Z MB

We don't have code currently to measure 2 and 3 exactly right now, so that's
the first priority.  After that it's a matter of picking X, Y, and Z for the
benchmarks we care about.  Any suggestions?

- James


 As you say, getting it into the other processes seems like the higher
 priority.

 Erik


  Mike
 
  On Thu, Oct 1, 2009 at 8:42 AM, Erik Kay erik...@chromium.org wrote:
 
  On Wed, Sep 30, 2009 at 11:22 AM, James Robinson jam...@google.com
  wrote:
  
   I agree completely that this seems to be an issue Here's what
   about:tcmalloc
   says about my browser process right now (which is at around 267MB
   according
   to the app's Task Manager):
  
   MALLOC:207097856 (  197.5 MB) Heap size
   MALLOC: 12494760 (   11.9 MB) Bytes in use by application
   MALLOC:188563456 (  179.8 MB) Bytes free in page heap
 
  This is pretty eye-popping data.
 
  How expensive is it to compute this data?  Is it something we can
  report back in histograms?  Is it something we can add to some of our
  page cycler tests as perf data so we can track improvements and
  regressions?
 
  Erik
 
 

 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: XP Perf page load regression on morejs and moz page cyclers

2009-10-01 Thread Scott Hess


On Thu, Oct 1, 2009 at 11:32 AM, Mike Belshe mbel...@google.com wrote:
 On Thu, Oct 1, 2009 at 11:27 AM, Scott Hess sh...@chromium.org wrote:
 Could we set jemalloc on selected renderer processes?  I realize that
 wouldn't necessarily only impact the target domains, but it might be
 better than making the change global.

 It can be set by a per-process environment variable.  So... yes, this could
 be done.  Mix-and-match allocators might be a little strange for anything
 other than debugging/testing.

I was thinking enabling for the gmail renderer (and whoever gets stuck
in that process) might be more useful than enabling for everyone - but
obviously we'd need ways to identify the source of any uploaded data.

That said, being able to enable alternate malloc libraries in the
browser process might have relatively low performance costs compared
to the value of the data generated.  I don't mean to imply that
browser-process performance is not important, but rather that race
conditions and double-frees and the like are much more dangerous
there.  Also, interpreting the data would probably be easier (renderer
data and browser results would be internally consistent).

-scott

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: XP Perf page load regression on morejs and moz page cyclers

2009-10-01 Thread Jeremy Orlow

On Thu, Oct 1, 2009 at 12:38 PM, Scott Hess sh...@chromium.org wrote:


 On Thu, Oct 1, 2009 at 11:32 AM, Mike Belshe mbel...@google.com wrote:
  On Thu, Oct 1, 2009 at 11:27 AM, Scott Hess sh...@chromium.org wrote:
  Could we set jemalloc on selected renderer processes?  I realize that
  wouldn't necessarily only impact the target domains, but it might be
  better than making the change global.
 
  It can be set by a per-process environment variable.  So... yes, this
 could
  be done.  Mix-and-match allocators might be a little strange for anything
  other than debugging/testing.

 I was thinking enabling for the gmail renderer (and whoever gets stuck
 in that process) might be more useful than enabling for everyone - but
 obviously we'd need ways to identify the source of any uploaded data.

 That said, being able to enable alternate malloc libraries in the
 browser process might have relatively low performance costs compared
 to the value of the data generated.  I don't mean to imply that
 browser-process performance is not important, but rather that race
 conditions and double-frees and the like are much more dangerous
 there.  Also, interpreting the data would probably be easier (renderer
 data and browser results would be internally consistent).


Both of these points seem like big wins to me, for what it's worth.

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Access to a DOM Handle within an Extension API

2009-10-01 Thread Erik Kay


+chromium-dev
-chromium-extensions
(This is more of a question of hacking on the chromium code than in
writing extensions.)

On Thu, Oct 1, 2009 at 10:51 AM, Jeff Timanus jeff.tima...@gmail.com wrote:
 Hi Erik  Extension Developers
 I'm attempting to add some of the pop-up API functions that take a
 dom-object as an argument, but I'm having some trouble figuring out the best
 means to do it.
 I've added the following code to the API json file
 (chrome\common\extensions\api\extension_api.json), but I don't think it's
 correct (nor does it work):
         name: popup,
         type: function,
         description: Display a (!?) pop-up.,
         parameters: [
           {type: object, name: domElement},
           {type: integer, name: width},
           {type: integer, name: height}
         ]

Yeah, this won't work.  Parameters of type object have to have their
schema defined as well.  Also, even if you could define all of the
properties, this still wouldn't do what you wanted.

 I've looked through all of the existing APIs, and it seems that all of the
 objects that are in-parameters are dictionary objects constructed by the
 javascript code, as opposed to handles to native DOM objects.  Is there a
 trick here of which I'm not aware?

What would you expect this to mean?  Remember that this function call
is being sent to the browser (in another process).  What is a
reference to a DOM element supposed to mean in this context?  Ignoring
the API that you want the caller to use, what API would you expect the
browser to take?

My memory is that you need this DOM element so that you know where to
attach the popup.  I think given this, you're going to need to
implement some custom code rather than just using the default
pass-through behavior.

 An alternative that I'm currently exploring is to add a javascript handler
 (in extension_process_bindings.js) to extract the relevant properties of the
 DOM object before calling a native function with those arguments packaged in
 primitive objects.  Is this the sanctioned approach?

Yes.  When you need to do client-side transformations or other
client-side behavior, then you need to add the function directly into
extension_process_bindings.js.

Erik

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Has anyone built successfully on Win7 64bit? I am getting bash.exe errors


Detailed error message:

1-- Build started: Project: js2c, Configuration: Debug Win32
--
1js2c
2-- Build started: Project: cygwin, Configuration: Debug Win32
--
2setup_mount
1 30 [main] bash 8980 _cygtls::handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
1   3645 [main] bash 8980 open_stackdumpfile: Dumping stack trace to
bash.exe.stackdump
2The operation completed successfully.
2The operation completed successfully.
1Project : error PRJ0002 : Error result 35584 returned from 'C:
\Windows\SysWow64\cmd.exe'.

Content of bash.exe.stackdump:

E:\chromium\home\chrome-svn\tarball\chromium\src\chromemore
bash.exe.stackdump
Exception: STATUS_ACCESS_VIOLATION at eip=0043AE30
eax= ebx= ecx=61106EC8 edx= esi=611021A0
edi=0045A3E0
ebp=0028CBC8 esp=0028C58C program=e:\chromium\home\chrome-svn\tarball
\chromium\s
rc\third_party\cygwin\bin\bash.exe, pid 8296, thread main
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame Function  Args
0028CBC8  0043AE30  (0003, 02361C00, 02360090, 772F)
0028CD68  610060D8  (, 0028CDA0, 61005450, 0028CDA0)
61005450  61004416  (009C, A02404C7, E8611021, FF48)
 431390 [main] bash 8296 _cygtls::handle_exceptions: Exception:
STATUS_ACCESS_VI
OLATION
 509897 [main] bash 8296 _cygtls::handle_exceptions: Error while
dumping state (
probably corrupted stack)
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API

2009-10-01 Thread Nick Baum

I've never done this, but I'm happy to learn. I got an intro to how to do it
a few weeks back re:some extensions APIs.
Where do I send the email? I'll send out a draft here beforehand.

-Nick

On Thu, Oct 1, 2009 at 2:41 PM, Brad Green (大面包) b...@google.com wrote:

 
   API: How does the page know it's registered?
 
  If Gmail notices you have Chrome and this isn't set, it might put a big
  promo on your inbox page. However, if it's already set, if would of
 course
  want to hide this.

 I understand your point now.  It is something that should be brought
 up in whatwg and discussed.


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Label changes on the issue tracker

2009-10-01 Thread Anthony LaForge

A bit of fall cleaning.  In order to clean-up the issue tracker labels a bit
and make some of the feature areas a bit more clear, I've made the following
changes:

   - Type-Task, Type-Review, and Type-Other have been removed
   - Mstone-1.0 and Mstone-2.0 have been retired
   - Area-Compat has been split into Area-Compat-System and Area-Compat-Web
   (application versus site compat issues)
  - AppCompat was removed
   - Bloat has been removed (in favor of using the memory label)
   - Docs has been removed
   - 15 specific focus area features have been addedFeature-Autofill =
   Issues related to autofill for forms
   -
  - Feature-Bookmarks= Issues related to bookmarks
  - Feature-Downloads= Issues related to downloads
  - Feature-FindInPage   = Issues related to find in page
  - Feature-FirstRun = Issues related to the first run flow
  - Feature-History  = Issues related to browser history
  - Feature-Import   = Issues related to importing data from other
  browsers
  - Feature-NewTabPage   = Issues related to the New Tab Page
  - Feature-Omnibox  = Issues related to Omnibox (e.g. search,
  autocomplete)
  - Feature-Options  = Issues related to the options dialog
  - Feature-Passwords= Issues related to password saving/filling
  - Feature-Printing = Issues related to printing
  - Feature-SavePage = Issues related to saving pages
  - Feature-Sessions = Issues realted to session state
  - Feature-Spellcheck   = Issues related to spell check
  - Feature-TabStrip = Issues related to the tab strip
  - Feature-Themes   = Issues related to theme
   - Added GreenTreeTaskForce
   - Removed Icebox (duplicates how we treat Mstone-X)
   - Removed Maintainability (we retained Type-Cleanup for this purpose)
   - Removed NewHTTP - Since this work is largely complete
   - Removed ReleaseNotes - Since no one used this
   - Removed Sizes - This methodology was under-used and does not fit into
   our current planning practices


Kind Regards,

Anthony Laforge
Technical Program Manager
Mountain View, CA

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API

2009-10-01 Thread Brian Rakowski

You should talk with the open web leads (darin, ifette, dglazkov,
slightlyoff) for help on floating this out there.

On Thu, Oct 1, 2009 at 1:12 PM, Nick Baum nickb...@chromium.org wrote:

 I've never done this, but I'm happy to learn. I got an intro to how to do
 it a few weeks back re:some extensions APIs.
 Where do I send the email? I'll send out a draft here beforehand.

 -Nick


 On Thu, Oct 1, 2009 at 2:41 PM, Brad Green (大面包) b...@google.com wrote:

 
   API: How does the page know it's registered?
 
  If Gmail notices you have Chrome and this isn't set, it might put a big
  promo on your inbox page. However, if it's already set, if would of
 course
  want to hide this.

 I understand your point now.  It is something that should be brought
 up in whatwg and discussed.




--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Label changes on the issue tracker

2009-10-01 Thread Andrew Scherkus

On Thu, Oct 1, 2009 at 1:22 PM, Anthony LaForge lafo...@google.com wrote:

 A bit of fall cleaning.  In order to clean-up the issue tracker labels a
 bit and make some of the feature areas a bit more clear, I've made the
 following changes:

- Type-Task, Type-Review, and Type-Other have been removed
- Mstone-1.0 and Mstone-2.0 have been retired
- Area-Compat has been split into Area-Compat-System
and Area-Compat-Web (application versus site compat issues)
   - AppCompat was removed
- Bloat has been removed (in favor of using the memory label)
- Docs has been removed
- 15 specific focus area features have been addedFeature-Autofill =
Issues related to autofill for forms
-
   - Feature-Bookmarks= Issues related to bookmarks
   - Feature-Downloads= Issues related to downloads
   - Feature-FindInPage   = Issues related to find in page
   - Feature-FirstRun = Issues related to the first run flow
   - Feature-History  = Issues related to browser history
   - Feature-Import   = Issues related to importing data from other
   browsers
   - Feature-NewTabPage   = Issues related to the New Tab Page
   - Feature-Omnibox  = Issues related to Omnibox (e.g. search,
   autocomplete)
   - Feature-Options  = Issues related to the options dialog
   - Feature-Passwords= Issues related to password saving/filling
   - Feature-Printing = Issues related to printing
   - Feature-SavePage = Issues related to saving pages
   - Feature-Sessions = Issues realted to session state
   - Feature-Spellcheck   = Issues related to spell check
   - Feature-TabStrip = Issues related to the tab strip
   - Feature-Themes   = Issues related to theme
- Added GreenTreeTaskForce
- Removed Icebox (duplicates how we treat Mstone-X)
- Removed Maintainability (we retained Type-Cleanup for this purpose)
- Removed NewHTTP - Since this work is largely complete
- Removed ReleaseNotes - Since no one used this
- Removed Sizes - This methodology was under-used and does not fit into
our current planning practices

 Can we remove Size-Medium from the bug template?



-


 Kind Regards,

 Anthony Laforge
 Technical Program Manager
 Mountain View, CA

 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: script for converting sln and vcproj to gyp

2009-10-01 Thread Marshall Greenblatt

On Tue, Sep 29, 2009 at 7:58 PM, Bradley Nelson bradnel...@google.comwrote:

 Sadly to my knowledge no-one has such a script.


I've written a script for converting (basic, un-complicated) .sln and
.vcproj files to .gyp:

http://code.google.com/p/gyp/issues/detail?id=82


 -BradN

 On Mon, Sep 28, 2009 at 11:25 AM, Marshall Greenblatt 
 magreenbl...@gmail.com wrote:

 Hi All,

 Does anyone happen to have a script for generating more-or-less complete
 .gyp configurations given an .sln or .vcproj input?

 Thanks,
 Marshall

 



--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Bug tracker: Cross-project bug linking

2009-10-01 Thread Mark Larson (Google)

You can use the form issue project:bugid in bug descriptions to
autolink to bugs in other code.google.com projects like v8, skia, googleurl,
etc.
As of today, this form is supported for Duplicate and Blocked on. So, for
example, I marked V8's http://code.google.com/p/v8/issues/detail?id=19 as a
Duplicate of chromium:671 (just as a test).

When you make a cross-project annotation like this, it only updates the
current bug because the author might not have permissions to edit bugs in
the other project. It does create a convenient link in the bug that you can
follow to get more info about the duplicate or blocking bug.

--Mark

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Has anyone built successfully on Win7 64bit? I am getting bash.exe errors

2009-10-01 Thread Mohamed Mansour

Windows 7 64bit works fine here (using the default settings from
dev.chromium.org)  Make sure you have access to the folder your writing to.
Some folders require admin mode.
 -Mohamed


On Thu, Oct 1, 2009 at 4:10 PM, vha14 vuh...@gmail.com wrote:


 Detailed error message:

 1-- Build started: Project: js2c, Configuration: Debug Win32
 --
 1js2c
 2-- Build started: Project: cygwin, Configuration: Debug Win32
 --
 2setup_mount
 1 30 [main] bash 8980 _cygtls::handle_exceptions: Exception:
 STATUS_ACCESS_VIOLATION
 1   3645 [main] bash 8980 open_stackdumpfile: Dumping stack trace to
 bash.exe.stackdump
 2The operation completed successfully.
 2The operation completed successfully.
 1Project : error PRJ0002 : Error result 35584 returned from 'C:
 \Windows\SysWow64\cmd.exe'.

 Content of bash.exe.stackdump:

 E:\chromium\home\chrome-svn\tarball\chromium\src\chromemore
 bash.exe.stackdump
 Exception: STATUS_ACCESS_VIOLATION at eip=0043AE30
 eax= ebx= ecx=61106EC8 edx= esi=611021A0
 edi=0045A3E0
 ebp=0028CBC8 esp=0028C58C program=e:\chromium\home\chrome-svn\tarball
 \chromium\s
 rc\third_party\cygwin\bin\bash.exe, pid 8296, thread main
 cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
 Stack trace:
 Frame Function  Args
 0028CBC8  0043AE30  (0003, 02361C00, 02360090, 772F)
 0028CD68  610060D8  (, 0028CDA0, 61005450, 0028CDA0)
 61005450  61004416  (009C, A02404C7, E8611021, FF48)
  431390 [main] bash 8296 _cygtls::handle_exceptions: Exception:
 STATUS_ACCESS_VI
 OLATION
  509897 [main] bash 8296 _cygtls::handle_exceptions: Error while
 dumping state (
 probably corrupted stack)
 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Has anyone built successfully on Win7 64bit? I am getting bash.exe errors


Hi Mohamed, can you run bash.exe from cmd? I get the following error:

E:\chromium\home\chrome-svn\tarball\chromium\src\third_party\cygwin
\binbash
  9 [main] bash 8384 _cygtls::handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
   9964 [main] bash 8384 open_stackdumpfile: Dumping stack trace to
bash.exe.stackdump
 211065 [main] bash 8384 _cygtls::handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
 229623 [main] bash 8384 _cygtls::handle_exceptions: Error while
dumping state (probably corrupted stack)


On Oct 1, 2:17 pm, Mohamed Mansour m...@chromium.org wrote:
 Windows 7 64bit works fine here (using the default settings from
 dev.chromium.org)  Make sure you have access to the folder your writing to.
 Some folders require admin mode.
  -Mohamed



 On Thu, Oct 1, 2009 at 4:10 PM, vha14 vuh...@gmail.com wrote:

  Detailed error message:

  1-- Build started: Project: js2c, Configuration: Debug Win32
  --
  1js2c
  2-- Build started: Project: cygwin, Configuration: Debug Win32
  --
  2setup_mount
  1     30 [main] bash 8980 _cygtls::handle_exceptions: Exception:
  STATUS_ACCESS_VIOLATION
  1   3645 [main] bash 8980 open_stackdumpfile: Dumping stack trace to
  bash.exe.stackdump
  2The operation completed successfully.
  2The operation completed successfully.
  1Project : error PRJ0002 : Error result 35584 returned from 'C:
  \Windows\SysWow64\cmd.exe'.

  Content of bash.exe.stackdump:

  E:\chromium\home\chrome-svn\tarball\chromium\src\chromemore
  bash.exe.stackdump
  Exception: STATUS_ACCESS_VIOLATION at eip=0043AE30
  eax= ebx= ecx=61106EC8 edx= esi=611021A0
  edi=0045A3E0
  ebp=0028CBC8 esp=0028C58C program=e:\chromium\home\chrome-svn\tarball
  \chromium\s
  rc\third_party\cygwin\bin\bash.exe, pid 8296, thread main
  cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
  Stack trace:
  Frame     Function  Args
  0028CBC8  0043AE30  (0003, 02361C00, 02360090, 772F)
  0028CD68  610060D8  (, 0028CDA0, 61005450, 0028CDA0)
  61005450  61004416  (009C, A02404C7, E8611021, FF48)
   431390 [main] bash 8296 _cygtls::handle_exceptions: Exception:
  STATUS_ACCESS_VI
  OLATION
   509897 [main] bash 8296 _cygtls::handle_exceptions: Error while
  dumping state (
  probably corrupted stack)
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] library targets with no sources fail to build on OS X

2009-10-01 Thread brymcq


I'm working on some code that uses the gyp build system. I find that
there are cases where I want to aggregate several libraries into a
single library target so other clients can depend on one public
library target instead of having to reference a bunch of individual
library targets. For instance I might have:

'targets': [
{
  'target_name': 'foo',
  'dependencies': [
some deps here
  ],
  'sources': [
some sources here
  ]
},
{
  'target_name': 'bar',
  'dependencies': [
some deps here
  ],
  'sources': [
some sources here
  ]
},
{
  'target_name': 'public',
  'dependencies': [
'foo',
'bar',
  ],
},
]

I then have consumers of my library depend on the 'public' target
rather than depending on 'foo' and 'bar'

This actually works fine on Linux and Windows builds, but on OS X
using xcodebuild, my builds fail with:

libpublic.a: No such file or directory

Is there some way to get the xcodebuilds to properly build these stub
libraries that don't have any source files? Does the gyp-xcode
generation code need to change to support this?

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Build problems on Windows: native client missing headers

2009-10-01 Thread Jói Sigurðsson


This has been fixed (not by me), the NaCl build files will now find
Python from third_party.

I have a pending change to fix the same issue in chrome_frame/chrome_frame.gyp.

Cheers,
Jói


On Thu, Oct 1, 2009 at 1:46 AM, Roland Steiner rolandstei...@google.com wrote:
 FWIW, I had similar troubles with NaCl auto-generated headers, but in my
 case the underlying problem was VS not finding Python. Adding the
 depot_tools path to the Windows system path fixed this problem for me.
 - Roland

 On Thu, Oct 1, 2009 at 6:43 AM, Jay Campan jcam...@chromium.org wrote:

 If you get build errors on Windows about some native client generated
 header file missing, make sure to run the sync command from cmd.exe,
 not from cygwin bash.
 (or just run gclient runhook --force from cmd.exe)

 There is a bug
 (http://code.google.com/p/nativeclient/issues/detail?id=105)
 when generating the vcproj from cygwin's bash.

 Jay




 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: XP Perf page load regression on morejs and moz page cyclers

2009-10-01 Thread Chase Phillips

Thanks Darin, Mike, and Jim for the quick response.  Sounds like we'll have
this in the trunk for a couple days at least if not longer, so I updated the
XP perf expectation.  The builder should stay green for now.

On Thu, Oct 1, 2009 at 7:58 AM, Chase Phillips ch...@chromium.org wrote:

 Hey everyone,
 A performance regression has appeared on the XP Perf bot in the morejs page
 cycler.  Along with turning XP Perf red, the perf regression system notified
 me via email (forwarded below).  The page load regression is about 30ms.
  There's a similar regression in the moz page cycler.  Here's a link to the
 XP Perf dashboard to see the morejs regression:

 http://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=50

 The interesting revisions between r27704 and r27710 are:

   r27705 - darin - Move various methods from glue to 
 api.http://src.chromium.org/viewvc/chrome?view=revrevision=27705
   r27708 - jar - Set JEMalloc as the default allocator (instead of
 TCMalloc). http://src.chromium.org/viewvc/chrome?view=revrevision=27708
   r27710 - thestig - Disable CheckSvnModifiedDirectories for 
 now.http://src.chromium.org/viewvc/chrome?view=revrevision=27710

 @jar: Not meaning to pick on you, but my guess is the JEMalloc change is
 the cause.  Did you expect a page load regression from your change?

 PS If you haven't heard of this perf regression system, don't worry -- it's
 a new tool in Chromium's toolbox.  Email and docs describing it will be sent
 soon.

 Thanks,
 Chase

 -- Forwarded message --
 From: build...@chromium.org
 Date: Thu, Oct 1, 2009 at 7:15 AM
 Subject: buildbot failure in Chromium on XP Perf, revision 27719
 To: c...@google.com


  http://build.chromium.org/buildbot/waterfall/

 Perf alert on XP Perf: page_cycler_morejs

 http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414

 Revision: 27719
 Blame list: ida...@google.com

  XP Perf
 Build 
 9414http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414
 svnkill
 stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/shell/logs/stdio
   update
 scripts
 stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/shell_2/logs/stdio
 taskkill
 stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/shell_3/logs/stdio
 update
 stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/gclient/logs/stdio
   extract
 build
 stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/extract%20build/logs/stdio
   Start
 Crash Handler
 stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/Start%20Crash%20Handler/logs/stdio
 uploading
 perf_expectations.json  page_cycler_moz

 IO_b_b: 41.8k (39.7k)
 IO_b_b_extcs1: 41.8k
 IO_b_r: 6.74k (6.0k)
 IO_b_r_extcs1: 6.62k
 IO_op_b: 51.6k (51.8k)
 IO_op_b_extcs1: 55.0k
 IO_op_r: 25.3k (28.3k)
 IO_op_r_extcs1: 25.2k
 t: 1.08k (1.19k)
 t_extcs1: 1.25k
 vm_pk_b: 8.24M (17.0M)
 vm_pk_b_extcs1: 9.68M
 vm_pk_r: 83.2M (72.9M)
 vm_pk_r_extcs1: 85.6M
 ws_pk_b: 20.0M (24.8M)
 ws_pk_b_extcs1: 21.4M
 ws_pk_r: 75.3M (73.7M)
 ws_pk_r_extcs1: 80.5M

 stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/page_cycler_moz/logs/stdio
 [resultshttp://build.chromium.org/buildbot/perf/xp-release-dual-core/moz/report.html?history=150
 ]  page_cycler_morejs

 PERF_REGRESS: times/t
 IO_b_b: 19.2k (17.5k)
 IO_b_b_extcs1: 19.3k
 IO_b_r: 475 (243)
 IO_b_r_extcs1: 475
 IO_op_b: 20.3k (19.5k)
 IO_op_b_extcs1: 23.4k
 IO_op_r: 9.56k (4.17k)
 IO_op_r_extcs1: 9.56k
 t: 1.4k (1.31k)
 t_extcs1: 1.44k
 vm_pk_b: 7.06M (16.1M)
 vm_pk_b_extcs1: 8.49M
 vm_pk_r: 8.28M (18.0M)
 vm_pk_r_extcs1: 8.3M
 ws_pk_b: 19.0M (23.8M)
 ws_pk_b_extcs1: 20.4M
 ws_pk_r: 12.6M (21.6M)
 ws_pk_r_extcs1: 12.6M

 stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/page_cycler_morejs/logs/stdio
 [resultshttp://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=150
 ]

 Changed by: *ida...@google.com*
 Changed at: *Thu 01 Oct 2009 07:00:09*
 Branch: *src*
 Revision: *27719*

 Changed files:

- *chrome/browser/privacy_blacklist/blocked_response.cc*
- *chrome/browser/privacy_blacklist/blocked_response.h*
- *chrome/browser/resources/privacy_blacklist_block.html*
- *chrome/browser/renderer_host/resource_dispatcher_host.cc*
- *chrome/browser/renderer_host/resource_dispatcher_host.h*

 Comments:

 Privacy Blacklist Unblock

 Summary
 ---

 Mostly implemented the unblocking for visual resources for the Privacy 
 Blacklist.
 Merging now before I leave. Eveything here only has effect if the 
 --privacy-blacklist
 flag specifies a Privacy Blacklist.

 Detailed Changes
 

 [chrome/browser/resources/privacy_blacklist.html]

 - Replaced the about:blank place-holder with variable to set

[chromium-dev] Re: Has anyone built successfully on Win7 64bit? I am getting bash.exe errors

2009-10-01 Thread Mohamed Mansour

I run Cygwin Bash Shell not from Command Prompt:

moha...@mohamed-pc ~$ bash


 -Mohamed


On Thu, Oct 1, 2009 at 5:32 PM, vha14 vuh...@gmail.com wrote:


 Hi Mohamed, can you run bash.exe from cmd? I get the following error:

 E:\chromium\home\chrome-svn\tarball\chromium\src\third_party\cygwin
 \binbash
  9 [main] bash 8384 _cygtls::handle_exceptions: Exception:
 STATUS_ACCESS_VIOLATION
   9964 [main] bash 8384 open_stackdumpfile: Dumping stack trace to
 bash.exe.stackdump
  211065 [main] bash 8384 _cygtls::handle_exceptions: Exception:
 STATUS_ACCESS_VIOLATION
  229623 [main] bash 8384 _cygtls::handle_exceptions: Error while
 dumping state (probably corrupted stack)


 On Oct 1, 2:17 pm, Mohamed Mansour m...@chromium.org wrote:
  Windows 7 64bit works fine here (using the default settings from
  dev.chromium.org)  Make sure you have access to the folder your writing
 to.
  Some folders require admin mode.
   -Mohamed
 
 
 
  On Thu, Oct 1, 2009 at 4:10 PM, vha14 vuh...@gmail.com wrote:
 
   Detailed error message:
 
   1-- Build started: Project: js2c, Configuration: Debug Win32
   --
   1js2c
   2-- Build started: Project: cygwin, Configuration: Debug Win32
   --
   2setup_mount
   1 30 [main] bash 8980 _cygtls::handle_exceptions: Exception:
   STATUS_ACCESS_VIOLATION
   1   3645 [main] bash 8980 open_stackdumpfile: Dumping stack trace to
   bash.exe.stackdump
   2The operation completed successfully.
   2The operation completed successfully.
   1Project : error PRJ0002 : Error result 35584 returned from 'C:
   \Windows\SysWow64\cmd.exe'.
 
   Content of bash.exe.stackdump:
 
   E:\chromium\home\chrome-svn\tarball\chromium\src\chromemore
   bash.exe.stackdump
   Exception: STATUS_ACCESS_VIOLATION at eip=0043AE30
   eax= ebx= ecx=61106EC8 edx= esi=611021A0
   edi=0045A3E0
   ebp=0028CBC8 esp=0028C58C program=e:\chromium\home\chrome-svn\tarball
   \chromium\s
   rc\third_party\cygwin\bin\bash.exe, pid 8296, thread main
   cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
   Stack trace:
   Frame Function  Args
   0028CBC8  0043AE30  (0003, 02361C00, 02360090, 772F)
   0028CD68  610060D8  (, 0028CDA0, 61005450, 0028CDA0)
   61005450  61004416  (009C, A02404C7, E8611021, FF48)
431390 [main] bash 8296 _cygtls::handle_exceptions: Exception:
   STATUS_ACCESS_VI
   OLATION
509897 [main] bash 8296 _cygtls::handle_exceptions: Error while
   dumping state (
   probably corrupted stack)
 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Native Client in Cross Compile

2009-10-01 Thread Antoine Labour

On Tue, Sep 29, 2009 at 12:44 PM, Daniel mpc...@gmail.com wrote:


 I'm trying to cross compile chromium to ARM, but I'm getting errors in
 the native client code.

 ./native_client/src/include/elf.h:68:3: error: #error
 NACL_TARGET_SUBARCH must be defined to be 32 or 64

 It looks like I have to have the same build and target architectures
 in order to work properly. Is there a way to turn off native client?
 I've cross-compiled earlier versions without a problem, but it looks
 like a change occurred in some of the files. Any way to get around
 this problem?


I'm running into the issue as well.
I'm looking into adding a gyp option to disable nacl.

Antoine

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Has anyone built successfully on Win7 64bit? I am getting bash.exe errors


So it looks like I need to install Cygwin separately before I can
build Chrome? If so this should be added to the Windows build
instruction page.

On Oct 1, 2:59 pm, Mohamed Mansour m...@chromium.org wrote:
 I run Cygwin Bash Shell not from Command Prompt:

 moha...@mohamed-pc ~$ bash

  -Mohamed



 On Thu, Oct 1, 2009 at 5:32 PM, vha14 vuh...@gmail.com wrote:

  Hi Mohamed, can you run bash.exe from cmd? I get the following error:

  E:\chromium\home\chrome-svn\tarball\chromium\src\third_party\cygwin
  \binbash
       9 [main] bash 8384 _cygtls::handle_exceptions: Exception:
  STATUS_ACCESS_VIOLATION
    9964 [main] bash 8384 open_stackdumpfile: Dumping stack trace to
  bash.exe.stackdump
   211065 [main] bash 8384 _cygtls::handle_exceptions: Exception:
  STATUS_ACCESS_VIOLATION
   229623 [main] bash 8384 _cygtls::handle_exceptions: Error while
  dumping state (probably corrupted stack)

  On Oct 1, 2:17 pm, Mohamed Mansour m...@chromium.org wrote:
   Windows 7 64bit works fine here (using the default settings from
   dev.chromium.org)  Make sure you have access to the folder your writing
  to.
   Some folders require admin mode.
    -Mohamed

   On Thu, Oct 1, 2009 at 4:10 PM, vha14 vuh...@gmail.com wrote:

Detailed error message:

1-- Build started: Project: js2c, Configuration: Debug Win32
--
1js2c
2-- Build started: Project: cygwin, Configuration: Debug Win32
--
2setup_mount
1     30 [main] bash 8980 _cygtls::handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
1   3645 [main] bash 8980 open_stackdumpfile: Dumping stack trace to
bash.exe.stackdump
2The operation completed successfully.
2The operation completed successfully.
1Project : error PRJ0002 : Error result 35584 returned from 'C:
\Windows\SysWow64\cmd.exe'.

Content of bash.exe.stackdump:

E:\chromium\home\chrome-svn\tarball\chromium\src\chromemore
bash.exe.stackdump
Exception: STATUS_ACCESS_VIOLATION at eip=0043AE30
eax= ebx= ecx=61106EC8 edx= esi=611021A0
edi=0045A3E0
ebp=0028CBC8 esp=0028C58C program=e:\chromium\home\chrome-svn\tarball
\chromium\s
rc\third_party\cygwin\bin\bash.exe, pid 8296, thread main
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame     Function  Args
0028CBC8  0043AE30  (0003, 02361C00, 02360090, 772F)
0028CD68  610060D8  (, 0028CDA0, 61005450, 0028CDA0)
61005450  61004416  (009C, A02404C7, E8611021, FF48)
 431390 [main] bash 8296 _cygtls::handle_exceptions: Exception:
STATUS_ACCESS_VI
OLATION
 509897 [main] bash 8296 _cygtls::handle_exceptions: Error while
dumping state (
probably corrupted stack)
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Has anyone built successfully on Win7 64bit? I am getting bash.exe errors

2009-10-01 Thread Dan Kegel


It's not supposed to be that way... maybe we need to check in a new cygwin.

On Thu, Oct 1, 2009 at 4:03 PM, vha14 vuh...@gmail.com wrote:

 So it looks like I need to install Cygwin separately before I can
 build Chrome? If so this should be added to the Windows build
 instruction page.

 On Oct 1, 2:59 pm, Mohamed Mansour m...@chromium.org wrote:
 I run Cygwin Bash Shell not from Command Prompt:

 moha...@mohamed-pc ~$ bash

  -Mohamed



 On Thu, Oct 1, 2009 at 5:32 PM, vha14 vuh...@gmail.com wrote:

  Hi Mohamed, can you run bash.exe from cmd? I get the following error:

  E:\chromium\home\chrome-svn\tarball\chromium\src\third_party\cygwin
  \binbash
       9 [main] bash 8384 _cygtls::handle_exceptions: Exception:
  STATUS_ACCESS_VIOLATION
    9964 [main] bash 8384 open_stackdumpfile: Dumping stack trace to
  bash.exe.stackdump
   211065 [main] bash 8384 _cygtls::handle_exceptions: Exception:
  STATUS_ACCESS_VIOLATION
   229623 [main] bash 8384 _cygtls::handle_exceptions: Error while
  dumping state (probably corrupted stack)

  On Oct 1, 2:17 pm, Mohamed Mansour m...@chromium.org wrote:
   Windows 7 64bit works fine here (using the default settings from
   dev.chromium.org)  Make sure you have access to the folder your writing
  to.
   Some folders require admin mode.
    -Mohamed

   On Thu, Oct 1, 2009 at 4:10 PM, vha14 vuh...@gmail.com wrote:

Detailed error message:

1-- Build started: Project: js2c, Configuration: Debug Win32
--
1js2c
2-- Build started: Project: cygwin, Configuration: Debug Win32
--
2setup_mount
1     30 [main] bash 8980 _cygtls::handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
1   3645 [main] bash 8980 open_stackdumpfile: Dumping stack trace to
bash.exe.stackdump
2The operation completed successfully.
2The operation completed successfully.
1Project : error PRJ0002 : Error result 35584 returned from 'C:
\Windows\SysWow64\cmd.exe'.

Content of bash.exe.stackdump:

E:\chromium\home\chrome-svn\tarball\chromium\src\chromemore
bash.exe.stackdump
Exception: STATUS_ACCESS_VIOLATION at eip=0043AE30
eax= ebx= ecx=61106EC8 edx= esi=611021A0
edi=0045A3E0
ebp=0028CBC8 esp=0028C58C program=e:\chromium\home\chrome-svn\tarball
\chromium\s
rc\third_party\cygwin\bin\bash.exe, pid 8296, thread main
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame     Function  Args
0028CBC8  0043AE30  (0003, 02361C00, 02360090, 772F)
0028CD68  610060D8  (, 0028CDA0, 61005450, 0028CDA0)
61005450  61004416  (009C, A02404C7, E8611021, FF48)
 431390 [main] bash 8296 _cygtls::handle_exceptions: Exception:
STATUS_ACCESS_VI
OLATION
 509897 [main] bash 8296 _cygtls::handle_exceptions: Error while
dumping state (
probably corrupted stack)
 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Has anyone built successfully on Win7 64bit? I am getting bash.exe errors

2009-10-01 Thread John Abd-El-Malek

I built using the instructions on Windows 7 64 bit without installing
another cygwin.

On Thu, Oct 1, 2009 at 4:03 PM, vha14 vuh...@gmail.com wrote:


 So it looks like I need to install Cygwin separately before I can
 build Chrome? If so this should be added to the Windows build
 instruction page.

 On Oct 1, 2:59 pm, Mohamed Mansour m...@chromium.org wrote:
  I run Cygwin Bash Shell not from Command Prompt:
 
  moha...@mohamed-pc ~$ bash
 
   -Mohamed
 
 
 
  On Thu, Oct 1, 2009 at 5:32 PM, vha14 vuh...@gmail.com wrote:
 
   Hi Mohamed, can you run bash.exe from cmd? I get the following error:
 
   E:\chromium\home\chrome-svn\tarball\chromium\src\third_party\cygwin
   \binbash
9 [main] bash 8384 _cygtls::handle_exceptions: Exception:
   STATUS_ACCESS_VIOLATION
 9964 [main] bash 8384 open_stackdumpfile: Dumping stack trace to
   bash.exe.stackdump
211065 [main] bash 8384 _cygtls::handle_exceptions: Exception:
   STATUS_ACCESS_VIOLATION
229623 [main] bash 8384 _cygtls::handle_exceptions: Error while
   dumping state (probably corrupted stack)
 
   On Oct 1, 2:17 pm, Mohamed Mansour m...@chromium.org wrote:
Windows 7 64bit works fine here (using the default settings from
dev.chromium.org)  Make sure you have access to the folder your
 writing
   to.
Some folders require admin mode.
 -Mohamed
 
On Thu, Oct 1, 2009 at 4:10 PM, vha14 vuh...@gmail.com wrote:
 
 Detailed error message:
 
 1-- Build started: Project: js2c, Configuration: Debug Win32
 --
 1js2c
 2-- Build started: Project: cygwin, Configuration: Debug Win32
 --
 2setup_mount
 1 30 [main] bash 8980 _cygtls::handle_exceptions: Exception:
 STATUS_ACCESS_VIOLATION
 1   3645 [main] bash 8980 open_stackdumpfile: Dumping stack trace
 to
 bash.exe.stackdump
 2The operation completed successfully.
 2The operation completed successfully.
 1Project : error PRJ0002 : Error result 35584 returned from 'C:
 \Windows\SysWow64\cmd.exe'.
 
 Content of bash.exe.stackdump:
 
 E:\chromium\home\chrome-svn\tarball\chromium\src\chromemore
 bash.exe.stackdump
 Exception: STATUS_ACCESS_VIOLATION at eip=0043AE30
 eax= ebx= ecx=61106EC8 edx= esi=611021A0
 edi=0045A3E0
 ebp=0028CBC8 esp=0028C58C
 program=e:\chromium\home\chrome-svn\tarball
 \chromium\s
 rc\third_party\cygwin\bin\bash.exe, pid 8296, thread main
 cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
 Stack trace:
 Frame Function  Args
 0028CBC8  0043AE30  (0003, 02361C00, 02360090, 772F)
 0028CD68  610060D8  (, 0028CDA0, 61005450, 0028CDA0)
 61005450  61004416  (009C, A02404C7, E8611021, FF48)
  431390 [main] bash 8296 _cygtls::handle_exceptions: Exception:
 STATUS_ACCESS_VI
 OLATION
  509897 [main] bash 8296 _cygtls::handle_exceptions: Error while
 dumping state (
 probably corrupted stack)
 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Has anyone built successfully on Win7 64bit? I am getting bash.exe errors


Ok, got this one fixed. The problem is that in my enlistment, sh.exe
and bash.exe both crashed. I installed cygwin (1.5.25-15) and then
copied these shells from the cygwin installation over to src
\third_party\cygwin\bin. So maybe it's a good idea to check in this
version of cygwin.

On Oct 1, 4:05 pm, Dan Kegel d...@kegel.com wrote:
 It's not supposed to be that way... maybe we need to check in a new cygwin.



 On Thu, Oct 1, 2009 at 4:03 PM, vha14 vuh...@gmail.com wrote:

  So it looks like I need to install Cygwin separately before I can
  build Chrome? If so this should be added to the Windows build
  instruction page.

  On Oct 1, 2:59 pm, Mohamed Mansour m...@chromium.org wrote:
  I run Cygwin Bash Shell not from Command Prompt:

  moha...@mohamed-pc ~$ bash

   -Mohamed

  On Thu, Oct 1, 2009 at 5:32 PM, vha14 vuh...@gmail.com wrote:

   Hi Mohamed, can you run bash.exe from cmd? I get the following error:

   E:\chromium\home\chrome-svn\tarball\chromium\src\third_party\cygwin
   \binbash
        9 [main] bash 8384 _cygtls::handle_exceptions: Exception:
   STATUS_ACCESS_VIOLATION
     9964 [main] bash 8384 open_stackdumpfile: Dumping stack trace to
   bash.exe.stackdump
    211065 [main] bash 8384 _cygtls::handle_exceptions: Exception:
   STATUS_ACCESS_VIOLATION
    229623 [main] bash 8384 _cygtls::handle_exceptions: Error while
   dumping state (probably corrupted stack)

   On Oct 1, 2:17 pm, Mohamed Mansour m...@chromium.org wrote:
Windows 7 64bit works fine here (using the default settings from
dev.chromium.org)  Make sure you have access to the folder your writing
   to.
Some folders require admin mode.
 -Mohamed

On Thu, Oct 1, 2009 at 4:10 PM, vha14 vuh...@gmail.com wrote:

 Detailed error message:

 1-- Build started: Project: js2c, Configuration: Debug Win32
 --
 1js2c
 2-- Build started: Project: cygwin, Configuration: Debug Win32
 --
 2setup_mount
 1     30 [main] bash 8980 _cygtls::handle_exceptions: Exception:
 STATUS_ACCESS_VIOLATION
 1   3645 [main] bash 8980 open_stackdumpfile: Dumping stack trace to
 bash.exe.stackdump
 2The operation completed successfully.
 2The operation completed successfully.
 1Project : error PRJ0002 : Error result 35584 returned from 'C:
 \Windows\SysWow64\cmd.exe'.

 Content of bash.exe.stackdump:

 E:\chromium\home\chrome-svn\tarball\chromium\src\chromemore
 bash.exe.stackdump
 Exception: STATUS_ACCESS_VIOLATION at eip=0043AE30
 eax= ebx= ecx=61106EC8 edx= esi=611021A0
 edi=0045A3E0
 ebp=0028CBC8 esp=0028C58C program=e:\chromium\home\chrome-svn\tarball
 \chromium\s
 rc\third_party\cygwin\bin\bash.exe, pid 8296, thread main
 cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
 Stack trace:
 Frame     Function  Args
 0028CBC8  0043AE30  (0003, 02361C00, 02360090, 772F)
 0028CD68  610060D8  (, 0028CDA0, 61005450, 0028CDA0)
 61005450  61004416  (009C, A02404C7, E8611021, FF48)
  431390 [main] bash 8296 _cygtls::handle_exceptions: Exception:
 STATUS_ACCESS_VI
 OLATION
  509897 [main] bash 8296 _cygtls::handle_exceptions: Error while
 dumping state (
 probably corrupted stack)
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Has anyone built successfully on Win7 64bit? I am getting bash.exe errors

2009-10-01 Thread vuha14

Ok, I fixed the problem by installing Cygwin (1.5.25-15), copying sh.exe  
and bash.exe over to src\third_party\cygwin\bin.

So it may be a good idea to check in this Cygwin version.

On Oct 1, 2009 4:43pm, John Abd-El-Malek j...@chromium.org wrote:
 I built using the instructions on Windows 7 64 bit without installing  
 another cygwin.

 On Thu, Oct 1, 2009 at 4:03 PM, vha14 vuh...@gmail.com wrote:



 So it looks like I need to install Cygwin separately before I can

 build Chrome? If so this should be added to the Windows build

 instruction page.



 On Oct 1, 2:59 pm, Mohamed Mansour m...@chromium.org wrote:

  I run Cygwin Bash Shell not from Command Prompt:

 

  moha...@mohamed-pc ~$ bash

 

  -Mohamed

 

 

 



  On Thu, Oct 1, 2009 at 5:32 PM, vha14 vuh...@gmail.com wrote:

 

   Hi Mohamed, can you run bash.exe from cmd? I get the following error:

 

   E:\chromium\home\chrome-svn\tarball\chromium\src\third_party\cygwin

   \binbash

   9 [main] bash 8384 _cygtls::handle_exceptions: Exception:

   STATUS_ACCESS_VIOLATION

   9964 [main] bash 8384 open_stackdumpfile: Dumping stack trace to

   bash.exe.stackdump

   211065 [main] bash 8384 _cygtls::handle_exceptions: Exception:

   STATUS_ACCESS_VIOLATION

   229623 [main] bash 8384 _cygtls::handle_exceptions: Error while

   dumping state (probably corrupted stack)

 

   On Oct 1, 2:17 pm, Mohamed Mansour m...@chromium.org wrote:

Windows 7 64bit works fine here (using the default settings from

dev.chromium.org) Make sure you have access to the folder your  
 writing

   to.

Some folders require admin mode.

-Mohamed

 

On Thu, Oct 1, 2009 at 4:10 PM, vha14 vuh...@gmail.com wrote:

 

 Detailed error message:

 

 1-- Build started: Project: js2c, Configuration: Debug Win32

 --

 1js2c

 2-- Build started: Project: cygwin, Configuration: Debug  
 Win32

 --

 2setup_mount

 1 30 [main] bash 8980 _cygtls::handle_exceptions: Exception:

 STATUS_ACCESS_VIOLATION

 1 3645 [main] bash 8980 open_stackdumpfile: Dumping stack trace  
 to

 bash.exe.stackdump

 2The operation completed successfully.

 2The operation completed successfully.

 1Project : error PRJ0002 : Error result 35584 returned from 'C:

 \Windows\SysWow64\cmd.exe'.

 

 Content of bash.exe.stackdump:

 

 E:\chromium\home\chrome-svn\tarball\chromium\src\chromemore

 bash.exe.stackdump

 Exception: STATUS_ACCESS_VIOLATION at eip=0043AE30

 eax= ebx= ecx=61106EC8 edx= esi=611021A0

 edi=0045A3E0

 ebp=0028CBC8 esp=0028C58C  
 program=e:\chromium\home\chrome-svn\tarball

 \chromium\s

 rc\third_party\cygwin\bin\bash.exe, pid 8296, thread main

 cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B

 Stack trace:

 Frame Function Args

 0028CBC8 0043AE30 (0003, 02361C00, 02360090, 772F)

 0028CD68 610060D8 (, 0028CDA0, 61005450, 0028CDA0)

 61005450 61004416 (009C, A02404C7, E8611021, FF48)

 431390 [main] bash 8296 _cygtls::handle_exceptions: Exception:

 STATUS_ACCESS_VI

 OLATION

 509897 [main] bash 8296 _cygtls::handle_exceptions: Error while

 dumping state (

 probably corrupted stack)

 








--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] url request failing on unix with os_error = -7

Hi,

The failure is in a unittest and only fails like this on linux.  The windows
trybot is happy.  The test uses HTTPTestServer (which talks to
testserver.py).

Can someone tell me what os_error of -7 means on linux?

Thanks,
Jenn

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Has anyone built successfully on Win7 64bit? I am getting bash.exe errors

2009-10-01 Thread John Abd-El-Malek

Chrome's cygwin installation is hermetic.  It works for a number of Google
devs on Windows 7/64 bit so I don't think it's a simple case of the cygwin
installation being broken.  What do you mean the binaries crash, did they
not resolve any dependent dlls?  Are you sure your gclient sync finished
successfully?  If you can move your working binaries off to another
directory, sync again, and try to repro this and get this data, it would be
helpful in determining how we can fix this.
Thanks

On Thu, Oct 1, 2009 at 4:46 PM, vuh...@gmail.com wrote:

 Ok, I fixed the problem by installing Cygwin (1.5.25-15), copying sh.exe
 and bash.exe over to src\third_party\cygwin\bin.

 So it may be a good idea to check in this Cygwin version.

 On Oct 1, 2009 4:43pm, John Abd-El-Malek j...@chromium.org wrote:
  I built using the instructions on Windows 7 64 bit without installing
 another cygwin.
 
  On Thu, Oct 1, 2009 at 4:03 PM, vha14 vuh...@gmail.com wrote:
 
 
 
  So it looks like I need to install Cygwin separately before I can
 
  build Chrome? If so this should be added to the Windows build
 
  instruction page.
 
 
 
  On Oct 1, 2:59 pm, Mohamed Mansour m...@chromium.org wrote:
 
   I run Cygwin Bash Shell not from Command Prompt:
 
  
 
   moha...@mohamed-pc ~$ bash
 
  
 
-Mohamed
 
  
 
  
 
  
 
 
 
   On Thu, Oct 1, 2009 at 5:32 PM, vha14 vuh...@gmail.com wrote:
 
  
 
Hi Mohamed, can you run bash.exe from cmd? I get the following error:
 
  
 
E:\chromium\home\chrome-svn\tarball\chromium\src\third_party\cygwin
 
\binbash
 
 9 [main] bash 8384 _cygtls::handle_exceptions: Exception:
 
STATUS_ACCESS_VIOLATION
 
  9964 [main] bash 8384 open_stackdumpfile: Dumping stack trace to
 
bash.exe.stackdump
 
 211065 [main] bash 8384 _cygtls::handle_exceptions: Exception:
 
STATUS_ACCESS_VIOLATION
 
 229623 [main] bash 8384 _cygtls::handle_exceptions: Error while
 
dumping state (probably corrupted stack)
 
  
 
On Oct 1, 2:17 pm, Mohamed Mansour m...@chromium.org wrote:
 
 Windows 7 64bit works fine here (using the default settings from
 
 dev.chromium.org)  Make sure you have access to the folder your
 writing
 
to.
 
 Some folders require admin mode.
 
  -Mohamed
 
  
 
 On Thu, Oct 1, 2009 at 4:10 PM, vha14 vuh...@gmail.com wrote:
 
  
 
  Detailed error message:
 
  
 
  1-- Build started: Project: js2c, Configuration: Debug Win32
 
  --
 
  1js2c
 
  2-- Build started: Project: cygwin, Configuration: Debug
 Win32
 
  --
 
  2setup_mount
 
  1 30 [main] bash 8980 _cygtls::handle_exceptions: Exception:
 
  STATUS_ACCESS_VIOLATION
 
  1   3645 [main] bash 8980 open_stackdumpfile: Dumping stack
 trace to
 
  bash.exe.stackdump
 
  2The operation completed successfully.
 
  2The operation completed successfully.
 
  1Project : error PRJ0002 : Error result 35584 returned from 'C:
 
  \Windows\SysWow64\cmd.exe'.
 
  
 
  Content of bash.exe.stackdump:
 
  
 
  E:\chromium\home\chrome-svn\tarball\chromium\src\chromemore
 
  bash.exe.stackdump
 
  Exception: STATUS_ACCESS_VIOLATION at eip=0043AE30
 
  eax= ebx= ecx=61106EC8 edx= esi=611021A0
 
  edi=0045A3E0
 
  ebp=0028CBC8 esp=0028C58C
 program=e:\chromium\home\chrome-svn\tarball
 
  \chromium\s
 
  rc\third_party\cygwin\bin\bash.exe, pid 8296, thread main
 
  cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
 
  Stack trace:
 
  Frame Function  Args
 
  0028CBC8  0043AE30  (0003, 02361C00, 02360090, 772F)
 
  0028CD68  610060D8  (, 0028CDA0, 61005450, 0028CDA0)
 
  61005450  61004416  (009C, A02404C7, E8611021, FF48)
 
   431390 [main] bash 8296 _cygtls::handle_exceptions: Exception:
 
  STATUS_ACCESS_VI
 
  OLATION
 
   509897 [main] bash 8296 _cygtls::handle_exceptions: Error while
 
  dumping state (
 
  probably corrupted stack)
 
   
 
 
 
 
 
 
 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: url request failing on unix with os_error = -7

I get the same behavior on the mac trybot too.  Anyone seen this before?


On Thu, Oct 1, 2009 at 4:58 PM, Jenn Braithwaite (胡慧鋒) je...@google.comwrote:

 Hi,

 The failure is in a unittest and only fails like this on linux.  The
 windows trybot is happy.  The test uses HTTPTestServer (which talks to
 testserver.py).

 Can someone tell me what os_error of -7 means on linux?

 Thanks,
 Jenn


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: url request failing on unix with os_error = -7

Yes, my unittests fail consistently on both linux and mac trybots.  The CL
link is:

http://codereview.chromium.org/201070

Here's a link to one of the linux try job failures:

http://build.chromium.org/buildbot/try-server/builders/linux/builds/1309

Given that this happens consistently on both mac and linux, I doubt it is a
try slave failure... ?

Jenn



On Thu, Oct 1, 2009 at 5:32 PM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote:

 Does it fail consistently? If so, could you post a link to your CL?

 On Thu, Oct 1, 2009 at 17:30, Jenn Braithwaite (胡慧鋒) je...@google.comwrote:

 I get the same behavior on the mac trybot too.  Anyone seen this before?



 On Thu, Oct 1, 2009 at 4:58 PM, Jenn Braithwaite (胡慧鋒) 
 je...@google.comwrote:

 Hi,

 The failure is in a unittest and only fails like this on linux.  The
 windows trybot is happy.  The test uses HTTPTestServer (which talks to
 testserver.py).

 Can someone tell me what os_error of -7 means on linux?

 Thanks,
 Jenn



 



--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: url request failing on unix with os_error = -7

2009-10-01 Thread Tim Steele

I think those are defined in net_error_list.h and that means timed out?

I would have said maybe it was a zombie python process from the test server
was lingering around and causing it to fail on subsequent runs, I've seen
that happen before. But you have several machines failing with this now...
Still possible, I guess.

On Thu, Oct 1, 2009 at 4:58 PM, Jenn Braithwaite (胡慧鋒) je...@google.comwrote:

 Hi,

 The failure is in a unittest and only fails like this on linux.  The
 windows trybot is happy.  The test uses HTTPTestServer (which talks to
 testserver.py).

 Can someone tell me what os_error of -7 means on linux?

 Thanks,
 Jenn

 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: url request failing on unix with os_error = -7