Delay instantiation of cachedValues to save memory

[holzensp]

I'm putting this up as a discussion piece, more than anything. Wins are minimal, at best.

The thinking was that every VmObject gets its cachedValues initialised by default, but only the ones that are forced get those values filled. However, cachedValues.entries is null by default. There appears to be a bigger possible win to address the fact that a lot of EconomicMaps have entries be an oversized array (Object[8] by default).

[odenix]

If the wins are minimal, I'm not sure they are worth the additional code and runtime checks. For typed objects, cachedValues could probably be removed altogether by switching to Truffle's static object model.

Speaking of small wins, there are several places in the codebase where EconomicMap.create() could be safely replaced with EconomicMap.emptyMap() because the map is effectively read-only. I tried this a few weeks ago but didn't send a PR because I had too many pending PRs.

[holzensp]

I agree. I am still looking into replacing members with something a little more compact, because of frequent over-allocation there. I'm skeptical it'll be significant, but it's worth the experiment, at least.

[odenix]

How do you do your memory profiling? members is often shared between objects created by the same new/amend expression. Are specific code constructs, such as for-generators, responsible for what you're seeing?