3 ms·
And how do you do that, without operating system support? I mean, you can't of course limit that based on the code, in the JVM there is only a single address sp
by alerighi 5y ago
And how do you do that, without operating system support? I mean, you can't of course limit that based on the code, in the JVM there is only a single address space, thus every method or class can be instantiated from anywhere in the code (despite public/private/etc. that are only for programmer convenience, they are easily circumvented with reflection, they don't provide any security at all).
You can imagine doing something like adding some bytecode instructions that if encountered by the JVM block the network access to every other request done in the call stack after that instruction. Something that reduces efficiency drastically and still can easily be circumvented if you don't implement different address spaces for different parts of the code (something that only the OS can do).
- jayd16 5y agoIf you're asking how th jvm might do it, I can assure you I do not know. If the question is "can this be a language feature" then I say, surely it can be. A language that supports static analysis and can disallow dynamic dispatch would do the trick, no?
- alerighi 5y agoThere are ways to call a function that cannot be caught by static analysis: basically you just need a way to jump to an arbitrary address of memory where a particular function is stored. If we exclude languages that by design sandbox the code (for example JavaScript, and most of the time it isn't enough because engines are bugged and thus browsers also use facilities of the operating system to sandbox the entire engine itself) no other programming language can do that.
- naasking 5y ago> I mean, you can't of course limit that based on the code, in the JVM there is only a single address space You can in principle, just look at the Joe-E language. The article is likely talking about revisions to existing VM designs though, because capabilities are a fundamental, architectural decision that underlie the runtime.