HohPum1l

The house is recouped by society though inheritance and property tax. You keep the physical object, but it has to be continuously paid for by generations to remain private.

If keeping things copyrighted had a continuous cost then copyright holders would be incentivized to release things to public sooner.

Do you still profit from software you have written for hire 20 years ago?

An "opportunity" they never had with cash in the first place.

In Germany direct debit (pull) is common and the EU is currently rolling out instant wire transfers (push). Either way cuts out the third party as you're paying directly from your bank account and banks are far more regulated wrt. privacy.

> But even if some company offered that all the retailers could still share their data with some aggregator which would effective work around your privacy oriented card not sharing data.

If you buy in a brick and mortar store the retailer would not have your address, only your card number. And a privacy-focusd CC company would allow you to generate new numbers for each transaction so the retailers can't use that to merge datasets.

Ideally it would still stack-allocate where beneficial and only materialize the object once it escapes to the heap, at least that's what graalvm does

On smaller heaps it was already possible to get 5-10ms pauses with the (now deprecated) CMS collector. Unlike Z it was a non-compacting collector though and had some ugly worst-case behaviors.

> It also might be worth pointing out that you now need 16x the page mappings

It doesn't. The article mentions it's only 3 mappings since those bits are colors, not arbitrary combinations of flags.

> I don't know how Java does it's memory management but if it does lots of small mappings (Which I'm guessing it does not) then that could be a concern.

openjdk generally uses large contiguous mappings but it may punch holes in the middle of the heap if it's configured to yield back memory to the OS. But applications that dynamically shrink and expand their heaps are not necessarily those that are concerned about the last quantum of page table overhead.

> And like you mentioned with the TLB

On the other hand it does support huge pages to mitigate costs of TLB entries.