Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Effectively Managing Memory at Gmail Scale

html5rocks.com

Post reply on HN
Print view View original

11–20 of 50 posts

Re: Effectively Managing Memory at Gmail Scale

#11

Post by TheLoneWolfling »

> Game developers, take note: to ensure a 16ms frame time (required to achieve 60 frames per second), your application must make zero allocations, because a single young generation collection will eat up most of the frame time.

And this is why GC isn't the be-all and end-all solution to memory management.

(As as for people that are screaming "pauseless GC" - it has throughput issues [generally due to fine grained locking / other synchronization], and also often has a performance hit on your main thread [due to locking or read barriers, generally])

Now, if someone combined a pauseless GC with proper cleanup (i.e. skipping GC altogether) of variables where the compiler could determine when they can be thrown away, matters would be different. (So, in other words, the compiler inserts `malloc` (or whatever) calls, and ensures that every variable created is either `free`d exactly once after it becomes unreachable or is added to the set tracked by the GC (or is a constant - especially pertinent with strings). With (hidden) local variables to track control flow when different branches cause different allocations.)

Re: Effectively Managing Memory at Gmail Scale

#13

Post by potench »

TheLoneWolfling wrote: post #11

> Game developers, take note: to ensure a 16ms frame time (required to achieve 60 frames per second), your application must make zero allocations, because a single young generation collection will eat up most of the frame time. And this is why GC isn't the be-all and end-all solution to memory management. (As as for people that are screaming "pauseless GC" - it has throughput issues [generally due to fine grained loc…

I'm not sure I understand how to make zero allocations? Does this mean you create your variables outside of a requestAnimationFrame (rAF) and update their values inside the rAF?

Re: Effectively Managing Memory at Gmail Scale

#14

Post by TheLoneWolfling »

potench wrote: post #13
TheLoneWolfling wrote: post #11

> Game developers, take note: to ensure a 16ms frame time (required to achieve 60 frames per second), your application must make zero allocations, because a single young generation collection will eat up most of the frame time. And this is why GC isn't the be-all and end-all solution to memory management. (As as for people that are screaming "pauseless GC" - it has throughput issues [generally due to fine grained loc…

I'm not sure I understand how to make zero allocations? Does this mean you create your variables outside of a requestAnimationFrame (rAF) and update their values inside the rAF?

That's what it means, yep. Making object pools, etc. This can be harder than it sounds, to put it mildly.

In other words, completely subverting the GC altogether.

Re: Effectively Managing Memory at Gmail Scale

#15

Post by mccr8 »

This is a cool article (from last year, FWIW). In particular, I like how Google uses Chrome browser improvements (the performance.memory API) to fix bugs in Gmail, and then in turn are able to reflect this back to use Gmail to notice bugs in Chrome.

This sort of vertical integration that Google is able to do is really powerful (they were also able to take advantage of this to drive the development of SPDY), but a little concerning for anybody that has a browser but not a popular website, or vice versa. Although in this particular case, I don't think anybody else implements performance.memory, so there would be no easy way for Gmail to track memory usage in other browsers.

Disclaimer: I work on Firefox and am speaking for myself, etc.

Re: Effectively Managing Memory at Gmail Scale

#16

Post by trjordan »

rokhayakebe wrote: post #5

Gmail still slow. Unrelated: Why haven't Google implemented a Google.com-quality-level search for email?

The new Inbox has "Top Hits", which is a more relevance-based search for email. It seems to work quite nicely, for me. I like that it gives you a couple highly-relevant emails, and the rest are still time-sorted for combing through all results.

Re: Effectively Managing Memory at Gmail Scale

#17

Post by aikah »

TheLoneWolfling wrote: post #11

> Game developers, take note: to ensure a 16ms frame time (required to achieve 60 frames per second), your application must make zero allocations, because a single young generation collection will eat up most of the frame time. And this is why GC isn't the be-all and end-all solution to memory management. (As as for people that are screaming "pauseless GC" - it has throughput issues [generally due to fine grained loc…

So basically one needs to re-implement smart pointers in Javascript, right ?

What are the alternative to js style GC,for a language that wouldnt want to the developper to use manual memory allocation.I've heard about ARC.Are there other known architectures?

Re: Effectively Managing Memory at Gmail Scale

#18

Post by ColinCera »

rokhayakebe wrote: post #5

Gmail still slow. Unrelated: Why haven't Google implemented a Google.com-quality-level search for email?

I believe they're attacking the challenge from the opposite direction: Gmail search can be described as "okay" and Google works tirelessly to make the main Google.com search experience worse and worse -- eventually they will succeed in degrading it from its former excellence to a point where its quality matches Gmail's.

Re: Effectively Managing Memory at Gmail Scale

#20

Post by pjmlp »

TheLoneWolfling wrote: post #11

> Game developers, take note: to ensure a 16ms frame time (required to achieve 60 frames per second), your application must make zero allocations, because a single young generation collection will eat up most of the frame time. And this is why GC isn't the be-all and end-all solution to memory management. (As as for people that are screaming "pauseless GC" - it has throughput issues [generally due to fine grained loc…

> And this is why GC isn't the be-all and end-all solution to memory management.

At least a GC knows where your memory blocks are and doesn't double free them.

> Now, if someone combined a pauseless GC with proper cleanup (i.e. skipping GC altogether) of variables where the compiler could determine when they can be thrown away,

Have you ever looked into ParaSail, Rust, ATS?

Post reply on HN