There are still new harvard architecture microcontrollers being designed. It provides some security in the field as well as simplifying the chip layout.
There are still new harvard architecture microcontrollers being designed. It provides some security in the field as well as simplifying the chip layout.
There's a second insight on the tip of my tongue, here: Harvard architectures can emulate Von Neumann ones, and vice versa. And problems, specific problems, can be solved by either. But it seems to me that there's something interesting about emulation too - That Harvard architectures can open themselves up to precisely the same vectors of attacks if you enable "Copy this data block to code memory".
This approach was pretty common in the 80s Lisp days IIRC.
It would be possible to compile everything to machine code ahead of time (pretty much what GraalVM does), but that would compile everything even if it would never end up being executed*. Without JIT compiler, it would not be possible to recompile code to take advantage of tracing information gathered at runtime. Also, newly loaded Java code would not be able to be optimized at all.
There are workarounds for all of these. For example, the JIT compiler could generate a new executable with the optimized code and migrate execution state to a new process. But it seems very clunky.
*: Not really an issue with microservices and stripped-down binaries. A huge deal for IDEs and environments with plugin architecture though.
Some Harvard architecture implementations provide ways of shoving data into executable space and back (like special copy instructions) but it's not general purpose. Generally you compile on Von Neumann and flash to Harvard.