Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linear Address Spaces: Unsafe at any speed (2022)

queue.acm.org

Post reply on HN
Print view View original

81–90 of 183 posts

Re: Linear Address Spaces: Unsafe at any speed (2022)

#81

Post by SulphurCrested »

mpweiher wrote: post #45

> Why do we even have linear physical and virtual addresses in the first place, when pretty much everything today is object-oriented? Because the attempts at segmented or object-oriented address spaces failed miserably. > Linear virtual addresses were made to be backwards-compatible with tiny computers with linear physical addresses but without virtual memory. That is false. In the Intel World, we first had the iAPX…

The Burroughs large system architecture of the 1960s and 1970s (B6500, B6700 etc.) did it. Objects were called “arrays” and there was hardware support for allocating and deallocating them in Algol, the native language. These systems were initially aimed at businesses (for example, Ford was a big customer for such things as managing what parts were flowing where) I believe, but later they managed to support FORTRAN with its unsafe flat model.

These were large machines (think of a room 20m square) and with explicit hardware support for Algol operations including the array stuff and display registers for nested functions, were complex and power hungry and with a lot to go wrong. Eventually, with the technology of the day, they became uncompetitive against simpler architectures. By this time too, people wanted to program in languages like C++ that were not supported.

With today’s technology, it might be possible.

Re: Linear Address Spaces: Unsafe at any speed (2022)

#82

Post by RachelF »

mpweiher wrote: post #45

> Why do we even have linear physical and virtual addresses in the first place, when pretty much everything today is object-oriented? Because the attempts at segmented or object-oriented address spaces failed miserably. > Linear virtual addresses were made to be backwards-compatible with tiny computers with linear physical addresses but without virtual memory. That is false. In the Intel World, we first had the iAPX…

> iAPX 432 Yes, this was a failure, the Itanium of the 1980's

I also regard ADA as a failure. I worked with it many years ago. ADA would take 30 minutes to compile a program. Turbo C++ compiled equivalent code in a few seconds.

Re: Linear Address Spaces: Unsafe at any speed (2022)

#83

Post by adgjlsfhk1 »

LegionMammal978 wrote: post #77
inkyoto wrote: post #65

Earlier quoted context omitted.

> Because the attempts at segmented or object-oriented address spaces failed miserably. > That is false. In the Intel World, we first had the iAPX 432, which was an object-capability design. To say it failed miserably is overselling its success by a good margin. I would further posit that segmented and object-oriented address spaces have failed and will continue to fail for as long as we have a separation into two di…

I don't see how any amount of memory technology can overcome the physical realities of locality. The closer you want the data to be to your processor, the less space you'll have to fit it. So there will always be a hierarchy where a smaller amount of data can have less latency, and there will always be an advantage to cramming as much data as you can at the top of the hierarchy.

while that's true, CPUs already have automatically managed caches. it's not too much of a stretch to imagine a world in which RAM is automatically managed as well and you don't have a distinction between RAM and persistent storage. in a spinning rust world, that never would have been possible, but with modern nvme, it's plausible.

Re: Linear Address Spaces: Unsafe at any speed (2022)

#84

Post by mikewarot »

suspended_state wrote: post #75
drob518 wrote: post #48

Earlier quoted context omitted.

And that address is going to be contained in a linear address space (possibly with some holes).

But that address doesn't have to be visible at the ISA level.

Code has to have addresses for calls and branches. Debuggers need to be able to control it all.

Re: Linear Address Spaces: Unsafe at any speed (2022)

#85

Post by adgjlsfhk1 »

duped wrote: post #78
inkyoto wrote: post #65

Earlier quoted context omitted.

> Because the attempts at segmented or object-oriented address spaces failed miserably. > That is false. In the Intel World, we first had the iAPX 432, which was an object-capability design. To say it failed miserably is overselling its success by a good margin. I would further posit that segmented and object-oriented address spaces have failed and will continue to fail for as long as we have a separation into two di…

I shudder to think about the impact of concurrent data structures fsync'ing on every write because the programmer can't reason about whether the data is in memory where a handful of atomic fences/barriers are enough to reason about the correctness of the operations, or on disk where those operations simply do not exist. Also linear regions make a ton of sense for disk, and not just for performance. WAL-based systems…

otoh, WAL systems are only necessary because storage devices present an interface of linear regions. the WAL system could move into the hardware.

Re: Linear Address Spaces: Unsafe at any speed (2022)

#86

Post by dmitrygr »

“Why don’t we do $thing_that_decisively_failed instead of $thing_that_evolved_to_beat_all_other_approaches?” Usually this sort of question comes from a lack of understanding of the history of the failure of the first and the success of the second.

The fence principle always applies “don’t tear down a fence till you understand why it was built”

Linear address spaces allow for how computers actually operate - layers. Objects are hard to deal with by layers who don’t know about them. Bytes aren’t. They are just bytes. How do you page out “an object”? Do I now need to solve the knapsack problem to efficiently tile them on disk based on their most recent use time and size? …1000 other things…

Re: Linear Address Spaces: Unsafe at any speed (2022)

#88

Post by saagarjha »

altairprime wrote: post #56
Veserv wrote: post #52

Earlier quoted context omitted.

And they addressed exactly none of the relevant points, instead supporting their arguments by waving in the general direction of outcompeted designs and speculative designs. CHERI is neat, but, as far as I am aware, still suffers from serious unsolved problems with respect to temporal safety and reclamation. Last I looked (which was probably after 2022 when this post was made), the proposed solutions were hardware ga…

> And they addressed exactly none of the relevant points Clarification: They addressed exactly none of the points you declare as relevant. You identify as an expert in the field and come across as plausibly such, so certainly I’ll still give your opinion on what’s relevant some weight. Perhaps the author was constrained by a print publication page size limit of, say, one? Or six? That used to be a thing in the past,…

These are obvious and trivial counters to their points. They should have been addressed.

Re: Linear Address Spaces: Unsafe at any speed (2022)

#89

Post by saagarjha »

dmytroi wrote: post #32

armv8/VMSAv8-64 has huge table support with optional contiguous bit allowing mapping up to 16GB at a time [0] [1]. Which will result in (almost) no address translations on any practical amount of memory available today. Likely the issue is between most user systems not configuring huge tables and developers not keen on using things they can't test locally. Though huge tables are prominent in single-app servers and ga…

You still need address translations, they’re just coming out of the TLB most of the time.

Re: Linear Address Spaces: Unsafe at any speed (2022)

#90

Post by saagarjha »

smj-edison wrote: post #46
indolering wrote: post #11

CHERI is undeniably on the rise. Adapting existing code generally only requires rewriting less than 1% of the codebase. It offers speedups for existing as well as new languages (designed with the hardware in mind). I expect to see it everywhere in about a decade.

Interesting, what causes the speedup?

You can skip some bounds checks and then get 50% slower because the hardware is not very powerful
Post reply on HN