That's how 64-bit software works. In my 32-bit Chrome gmail consumes 150MB or less. 64-bit Chrome is needed only in case you run web apps that consume more than 3.5GB per tab.

Oh well. 64 bit still has benefits over 32 bit and I have 6gb of ram on my laptop, so I have plenty to run it. Still, resource management can be further optimized. Chrome has gotten better as far as its reputation as a memory hog, but it still has room for improvement. I don't think 300mb of memory to open gmail is necessary regardless of 64 vs 32 bit. 

Which benefits in case of Chrome specifically in addition to the one I mentioned (more than 3GB per tab)? Have you measured the performance vs 32bit? I know 64bit is noticeably faster only for software that was explicitly optimized to utilize those extra bits i.e. apps for graphics/compression/encoding/video. Whereas unoptimized 64bit software may be slower than 32bit due to exceeding CPU/memory cache size (on my i7 CPU it's 32kB L1, 256kB L2, 8MB L3).

Anyway, to decrease memory consumption caused by the doubled size of all data pointers, Chromium developers would need to rewrite the very basics of C++ language to introduce "short" data pointers and that would probably require something like rewriting the entire codebase of Chromium or C++ compiler, which is hardly doable even theoretically.

Well 64 bit Chrome has been out for years and is well-optimized at this
point performance wise. It's not a massive difference across the board but,
as you mentioned, graphics/multimedia sees a sizeable performance boost.
VP9 decoding gets a performance bump, so youtube video performance
increases. Also, you get security and stability improvements with 64 bit
Chrome. My i5 has 32 kB L1, 256kB L2, and 3MB L3, so it should be able to
handle 64 bit chrome just fine.

See this article

https://www.digitalcitizen.life/google-chrome-64-32-bit-performance-comparison

I understand the challenge involved with memory consumption and the limits
to reducing it. That being said, tweaks to C++ and its compiler can always
be made (and they are). I'm just reminding devs to not ignore the nitty
gritty of baseline code optimization. I know its not glamorous and its not
fun but it is important. I'm just surprised that in the 34 years since the
inception of C/C++, a better wide purpose programming language hasn't been
introduced. I think effort needs to be made to do that. But that's neither
here nor there. Hopefully one day.

Well, I actually agree it would be nice if Chrome implemented its own memory management for 64-bit with short data pointers inside small "heaps" which in turn would be manageable by standard OS memory routines to allow a process use more than 3GB in total.

Tentatively adding component as Blink>MemoryAllocator, such that someone from the team would look into it further.

Thanks!

+benhenry@ and sullivan@, could you ptal? Thank you.

The bug is reported on M63, hence adding M63 as milestone.

1. Is this a regression from <M-63?
2. Can you provide traces so we can dig in if there's something happening on your machine specifically that needs to be addressed? https://www.chromium.org/developers/how-tos/trace-event-profiling-tool/recording-tracing-runs

Otherwise, we do have a number of engineers looking into specific memory projects and issues. CC'ing some folks in case we get a trace which points out any specific issues with memory usage.

1. Not sure if it's a regression or not. I would imagine not.
2. Please find the trace attached. Hopefully it helps.

Trace report is missing form comment#10. Please re-attach it again. This would help in further triaging of the issue.

Thanks!

++ A friendly ping to reporter on comment#10 and #11 to attach a Trace report as it was missing in C#10.

Thanks!

As there is no update from the reporter since a long time, marking this issue as WontFix.
Please feel free to raise a new bug if any issues are observed on the latest Chrome builds.

Thanks..