[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 <[email protected]> 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 <[email protected]> wrote: >> On Thu, Oct 1, 2009 at 4:44 PM, Anton Muhin <[email protected]> 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: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
