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.)
If you took just one rule of thumb from it, let it be this: if you want speed with garbage collected languages, be sure to use at most 1/6 of the overall system memory.
Freeing is not an issue, you don't pay for garbage in a proper GC, as the GC only scans living objects, and never frees.
The problem is allocation, as a scan is triggered when a certain number of bytes has been allocated. Go allows you to skip allocating on the heap (thus the GC), since you can define what is allocated on the stack or heap.
You potentially could do as you propose, by inserting "free" at certain points where you could prove the variable was safe to throw away. Free would basically just then say "you can now postpone allocation, you have more free memory". But this has it's own drawbacks. For one you a minimal amount more to do (calling 'free'), but more importantly you will increase time spent in allocation objects, because you have to scan the heap for available space instead of just bumping a pointer.
The most important thing is allowing the programmer a way to avoid the managed heap, which Go does, and C# to some degree does through structs.
In other words, completely subverting the GC altogether.
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?
Object pools at the language level would be an alternative. (I.e. every object is allocated in a "pool", including pools. When a pool falls out of scope the entire pool is "freed". You can copy objects between pools as necessary.)
This might be called "memory regions" in the literature, or at least the work on using this memory management scheme in an ML (ML Kit).
Yes, they'll eliminate the need for collection, by moving the overhead from a single collection to ever construction/destruction.
This may be worth it to get a constant framerate, but the overhead doesn't disappear. If anything, it could be greater: allocating from the heap usually costs more than an object allocation done by any sane VM.
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?
Wrong. Counterexample: https://mail-archives.apache.org/mod_mbox/subversion-users/2... (Obtained by a quick search of "garbage collector double-free bug" - there are many others out there)
> Have you ever looked into ParaSail, Rust, ATS?
ParaSail and Rust don't have a GC, period, AFAIK. ATS is too strict for my liking. (I want a programming language that will refuse to compile if it can find a "counterexample" that will assert, but will compile something (with a warning and inserted runtime checks unless explicitly marked otherwise) even if it cannot prove something is correct.)
Yeah, a bug.
I'd rather worry about double free being the case of a GC bug -- in a shared core code that can be fixed and the problem will vanish for everyone -- than in anywhere I have to free memory myself.
I don't touch Perl since 2004. Back then it used reference counting, not a GC.
Second, the post reads like a problem in the C code.
> ParaSail and Rust don't have a GC, period, AFAIK. ATS is too strict for my liking.
I was replying about GC alternatives for automatic memory management.
Exactly. All GC does is push down the code that can cause problems like double-frees into the language implementation. It doesn't magically make problems like double-free bugs impossible, like so many people say.
> I was replying about GC alternatives for automatic memory management.
Then why did you respond to and quote something that was talking about something entirely different?
That's like saying moving the likelihood of an event from 1/100 to 1/10000000, and only under very specific pre-conditions that are easily detactable, doesn't make it impossible.
That is, you are technically correct, which is the worst kind of correct.
The difference between double-free bugs in stuff "pushed down in the language implementation" and double-free bugs in programmer's own code is so huge, it's a total game changer.
The difference being the compiler vendor vs all the developers using the language.
> Then why did you respond to and quote something that was talking about something entirely different?
Maybe my bad English could not decipher "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".
It feels like it takes a lot longer to load... And once it finally does load, you still end up having to wait a reasonable amount of time for Hangouts.
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.
You know, I think I recall being able to run quite nicely featured GUI mail clients and IRC clients simultaneously on a Pentium 90 with 16 megs of RAM. And, I expect those clients had an order of magnitude less developer effort put into them compared to the GMail client-side code. Meanwhile, I'm quite confident that Gmail team is composed of very, very smart developers. So, what am I missing? Why does GMail require two orders of magnitude more resources?
I have around 80.000 messages in my inbox, most of them with attachments around 10MB, and I can browse and search them instantly.
Then again, I mostly use Gmail's backend, my preferred interface is Mail.app
There's also the fact that it runs in the browser, which can make it more difficult to control or understand how many resources will be used.
Unrelated: Why haven't Google implemented a Google.com-quality-level search for email?
Your email corpus is private and specific to you. If Google (or any other company) generated a high-quality search index for it, they'd spend a lot of CPU hours on it and only amortize that across a single user: you.
The question I have is why the Google Voice iPhone app does not have a search function AT ALL.
I could care a bit less about the colors and animation strategy Google is using, but why they don't just put a search bar at the top of every product of theirs is a mystery I'm afraid I'll have to live with for quite some time. Even the Google+ app (at least) has terrible search and takes too many clicks - I believe Facebook has actually caught up on this.
It's one of the reasons I only use its backend. It baffles me that a company known for search can't do it.
Afaik,what MS does is,as much as possible,do things server side instead of client side.For instance,online excel calculations are done server side then the resulting cells are just HTML fragments sent to the ajax callback.
It makes client apps consume way less memory,since less data is stored on the client.
I have a crappy Android phone (2.x) and onedrive html app doesnt feel slow on it.On the other hand,I just cant use gmail(ajax versions) or google drive html apps.They are just not responsive.