Linux namespaces can do that, with a UID namespace, you drop the ability to do SUID, and then you can open a mount namespace and bind-mount and chroot as you like.
It so much that JITs became feasible, it's that bigger CPUs were less suitable for Jazelle's approach because of the behaviour of the in-order CPU pipeline.
Because Jazelle converted Java bytecodes into ARM instructions in sequence, there is no opportunity for any instruction scheduling. So a bytecode sequence like:
// public static int get_x(int x, T a, T b) { return a.x+b.x; }
aload_1
getfield #N
aload_2
getfield #N
iadd
There would be a pipeline stall before each instruction marked with a *.
On the first ARM 9 CPUs with Jazelle, the pipeline is fairly similar to the standard 5 stage RISC pipeline (Fetch-Decode-Execute-MemoryAccess-Writeback) so this stall would be 1 cycle. That wasn't too bad - you could just accept that loads took usally 2 cycles, and it would still be pretty fast.
However, on later CPUs with a longer pipeline the load-use delay was increased. By ARM11, it was 2 cycles - so now the CPU is spending more time waiting for pipeline stalls that it spends actually executing instructions.
In contrast, even a basic JIT can implement instruction scheduling and find some independent instructions to do between a load and the use of the result, which makes the JIT much more performant than Jazelle could be.
Not just JITs; An out-of-order scheduler would have no issue reordering those instructions. However, Jazelle was designed for the low-end ARM processors that are all in-order (or were at the time; not sure how true that is today)
> When it started testing simulations of early Pentium prototypes, Intel discovered that a lot of game designers had found that they could shave one instruction off a hot loop by relying on a bug in the flag-setting behavior of Intel's 486 microprocessor. This bug had to be made part of the architecture: If the Pentium didn't run popular 486 games, customers would blame Intel, not the game authors.
Bob Colwell touches on an issue that sounds like it is this one in his talk Engineering Lessons from the Pittsburgh Steelers [1] at around 1:05:02 (link prepositioned). I'll bet that he went into more detail in his book The Pentium Chronicles, but I don't have it handy at the moment, so can't cite a page. It does not seem to be in his oral history [2] (PDF), which I had thought contained pretty much all the meat of his chronicles though.
If you're more interested in just concrete examples of this kind of thing, apparently IBM's System/360 team ran into heaps of this kind of issue when emulating the IBM 1401. It's mentioned in Frederick P. Brooks, Jr.'s book The Mythical Man-Month in the Formal Definitions section of Chapter 6, and I think he probably discussed it in more detail in his (and Blaauw's) book Computer Architecture.
Edit: pasting in a cleaned up version of the relevant part of the transcript:
1:04:56
It's required to run every one of those well, how do I know it does? I can't test them all, so you say well you as long as you design to the architecture spec that should be enough. Right? Ha no for example, inside the architecture spec there are places where it says this condition flag is undefined as a result of this operation so you'll do – I don't know what it was anymore, add operation or something, no, it can't be add pick a different [thing] – there was some instruction that would say I do not guarantee what the carry flag will look like when I'm finished and you go as an architect hey that's cool it means I can do it either way whatever way is easiest. No it doesn't.
Yeah if you think that you're going to get in big trouble. Because what what will happen is – and this literally happened which is why I know about this – you put the chip out and then you discover oh it was easiest for my team to set the bit to a 1 didn't matter because it was undefined right I get to pick, but all the previous chips were setting it to a zero although they were calling it undefined. Now you're in trouble, because what you're going to discover some goofy app out there required that the bit be a zero after that operation even though the book said it was undefined. And they didn't notice because up until now it always was a zero. But your chip comes out, the software doesn't work anymore. Guess who's at fault? You are. Can you go "hey look at what the book says, can't you read?" and they'll say "I don't care what you say your chip doesn't work my software, you're a loser, your chips busted."
Classic example of Hyram’s law - adherence to a non-trivial specification is very difficult to check so the real spec is generally “works with that implementation”.
If you look at the wiki on the UNIX philosophy it does say "Store data in flat text files" and "Write programs to handle text streams, because that is a universal interface."
You can do a surprising amount with flat files. For decades HP / HPE has been using flat files for Serviceguard / SGLX which is a high-availability cluster software that gets used in some very large Enterprise environments.
you can do anything with (flat|text) files, they are after all just an often inefficient binary encoding the same as any other binary blob.
The main thing you can do with them though, is tell yourself that you don't really need a spec or documentation because you can just eyeball the output, and not having to follow a spec makes things feel simple.
For example, tables in relational databases like sqlite are representationally isomorphic to tabular files like the output from `ls -al`. Sqlite has a lot of useful performance optimizations (including eg, not having to encode strings as "\x20" or the like if you want arbitrary bytes), but those come at the cost of a data format that you can't easily (not even notice that you needed to and did) reverse engineer, when either writing new software to consume or emit it, or even just visually inspecting it in a editor that doesn't already speak that format.
> Isn't it surprising that modulo arithmetic, as already employed successfully in TCP sequence numbers and the like, still seems to be incorrectly implemented today
Even in TCP sequence numbers, it can be implemented incorrectly.
applause