| |||||||||||||
McGrath: Proposal for a new Fedora projectMcGrath: Proposal for a new Fedora projectPosted Oct 1, 2010 20:11 UTC (Fri) by oak (subscriber, #2786)In reply to: McGrath: Proposal for a new Fedora project by flammon Parent article: McGrath: Proposal for a new Fedora project
> Save memory. Instead of loading GTK, QT and Gecko just load Gecko.
Apparently you have no clue about how much these use memory. If you have your "web-apps" as separate processes, they are way heavier RAM-wise than Gtk or Qt. For starters, normal UI toolkits don't run virtual machines or use JIT...
> The write once run anywhere promise is much closer to reality. Even I9 is stepping up and putting in an effort to follow the standard.
Hm. I'm still getting a Java Déjà vu.
(Log in to post comments)
McGrath: Proposal for a new Fedora project Posted Oct 1, 2010 21:30 UTC (Fri) by cmccabe (guest, #60281) [Link]
> Hm. I'm still getting a Java Déjà vu.
By the way, when Java was still under development, one of the codenames it went by was "Oak."
McGrath: Proposal for a new Fedora project Posted Oct 2, 2010 22:54 UTC (Sat) by flammon (guest, #807) [Link]
Alright, memory usage is not a good point when you're the running the jit/renderer in separate processes today and that is the trend so I'll take point back for now. I do however believe that memory sharing optimizations have not been completely explored. We've seen huge performance jumps in the JavaScript in recent years and I think memory sharing and usage optimization is next and a few ideas will be borrowed from the hypervisor guys.
Write once run everywhere is much more real today than it ever was. HTML5 and ECMAScript are public standards that are not controlled by any individual company, unlike Java and .NET.
McGrath: Proposal for a new Fedora project Posted Oct 3, 2010 19:41 UTC (Sun) by oak (subscriber, #2786) [Link]
> Alright, memory usage is not a good point when you're the running the jit/renderer in separate processes today and that is the trend so I'll take point back for now.
And if they were in the same process, one can of course do the same with native code to save memory too...
> I think memory sharing and usage optimization is next and a few ideas will be borrowed from the hypervisor guys.
In that case there's same code (or data) bin all these VM instances which can be shared.
If user is surfing a single site, s/he may have multiple pages open for it. If code on those pages share common JS "library/ies", the JITed code for those could be shared. If user has open pages for different sites, I doubt them to share much code as JavaScript isn't well known for having established libraries that are shared by everybody on the net...
Data is mainly images I think. Except for things like site backgrounds and smaller images, images are probably page specific (I would assume browser to already share & cache images that are commonly used). In native applications images come for common widget & icon theme that is shared by all the applications using the same widget set. I don't see that happening for web apps.
And lastly you have the memory overhead that comes just from having a VM & GC. That's always going to eat memory than native non-GC code unless that has leaks (which may be easier to avoid with higher level language & GC).
> HTML5 and ECMAScript are public standards that are not controlled by any individual company, unlike Java and .NET.
I'm not so sure that the backend code for these HTML5 applications is written in ECMAScript. Java or .NET sounds more likely for that...
McGrath: Proposal for a new Fedora project Posted Oct 9, 2010 21:20 UTC (Sat) by nix (subscriber, #2304) [Link]
The memory overhead that comes with GC is nearly nil these days, even by the standards of mobile devices.
See this?
RSS VSZ STIME TIME COMMAND
That little bugger is making several hundred GCed allocations a second, incrementally GCing as it goes (using the Lua 5.1.4 collector), and has been doing that for a couple of weeks now. Memory usage attributable to GC and heap fragmentation (overhead with respect to memory usage of GCless implementation at startup), across all that time: perhaps 1-2Mb.
McGrath: Proposal for a new Fedora project Posted Oct 9, 2010 21:33 UTC (Sat) by oak (subscriber, #2786) [Link]
This particular comment "thread" is about memory overhead of interpreted languages using both GC and JIT (which is needed for interpreted languages, particularly JavaScript here, to have decent speed). And the overhead of all these together.
If your example was of native code using GC and not having JIT, 1-2MB overhead sounds on the largish side for that sized program, but it of course depends completely on how dynamic your program's memory usage is.
Whether the program does lots and very differently sized allocs and how good its allocation patterns are. Heap works like stack so one should in general alloc last things you're going to free first if you want to minimize fragmentation. The allocator you use may utilize buckets for smaller alloc sizes which can affect this or not.
GC and interpreted languages of course have other advantages, but the topic was memory overhead. :-)
McGrath: Proposal for a new Fedora project Posted Oct 10, 2010 0:57 UTC (Sun) by nix (subscriber, #2304) [Link]
The code was not native code: it was Lua code embedded in a C string and then executed. So, no, not JITted, byt not native GC either.
1-2Mb overhead, well, yes, it seems excessive because it was tuned to find a good tradeoff between GC frequency/intensity and CPU consumption. (I suspect that most of that overhead is actually heap fragmentation, which even a non-GCed program is exposed to.)
(We are in luck sizewise, though: most of the allocations are the same size. Not all, but most.)
McGrath: Proposal for a new Fedora project Posted Oct 3, 2010 22:17 UTC (Sun) by Wol (guest, #4433) [Link]
You've obviously never come across UCSD P-code (or indeed, plenty of other such similar systems ...)
Cheers,
|
|||||||||||||