5 ms·

> Modifying the code segment to include direct function references is also not a great approach because it means being unable to share the code segment between

> Modifying the code segment to include direct function references is also not a great approach because it means being unable to share the code segment between processes Realistically how big of a deal is this? I feel like it's overblown, no? Literally the only huge program I have that sneezes out a gazillion instances of itself is Chrome. On everything else there's usually only one and most a few instances.

MereInterest 8y ago
If you work on a non-Windows platform, then many executables will rely on libraries provided by the package manager. Your code might not be using that library from within a different process, but that doesn't mean that somebody else isn't.
- mehrdadn 8y ago
  Yeah sorry I wasn't clear, I was talking about Windows since this is the approach Windows takes. And somehow (perhaps mistakenly) I assumed "executable" meant EXE, not DLL (since I refer to the two as "binaries"). Otherwise yeah I agree [1]. [1] https://news.ycombinator.com/item?id=17175361 https://news.ycombinator.com/item?id=17175361
- pjmlp 8y ago
  Not all non-Windows platforms have package managers, or are UNIX clones.
bjourne 8y ago
All JIT:ted VM:s modify their code segments. So not a big deal at all. Code modification is done to implement dynamic dispatch efficiently. For example, suppose the compiler generates code for "a + b" If it can't infer the types of a and b, it generates a call to a stub function. When that stub function is called, it looks at the types of a and b and generates efficient dispatch code. For example, if a and b were ints it would generate code like: "if (type(a)==int && type(b)==int) { return fast_add(a, b); } else { slow_but_generic_add(a, b); }" A sophisticated JIT could even keep track on how frequently the fast track is taken and generate a new stub based on that. It could even inline the stub into the calling function and recompile that one.
- mpweiher 8y ago
  > So not a big deal at all. Er...a big problem that all JITted VMs share. For one, not permitted on iOS, and memory pressure from dirty pages is much bigger than from clean pages, exacerbated by the fact that they're not shared.

MereInterest 8y ago

If you work on a non-Windows platform, then many executables will rely on libraries provided by the package manager. Your code might not be using that library from within a different process, but that doesn't mean that somebody else isn't.

mehrdadn 8y ago
Yeah sorry I wasn't clear, I was talking about Windows since this is the approach Windows takes. And somehow (perhaps mistakenly) I assumed "executable" meant EXE, not DLL (since I refer to the two as "binaries"). Otherwise yeah I agree [1]. [1] https://news.ycombinator.com/item?id=17175361 https://news.ycombinator.com/item?id=17175361
pjmlp 8y ago
Not all non-Windows platforms have package managers, or are UNIX clones.

bjourne 8y ago

All JIT:ted VM:s modify their code segments. So not a big deal at all. Code modification is done to implement dynamic dispatch efficiently. For example, suppose the compiler generates code for "a + b" If it can't infer the types of a and b, it generates a call to a stub function. When that stub function is called, it looks at the types of a and b and generates efficient dispatch code. For example, if a and b were ints it would generate code like: "if (type(a)==int && type(b)==int) { return fast_add(a, b); } else { slow_but_generic_add(a, b); }" A sophisticated JIT could even keep track on how frequently the fast track is taken and generate a new stub based on that. It could even inline the stub into the calling function and recompile that one.

mpweiher 8y ago
> So not a big deal at all. Er...a big problem that all JITted VMs share. For one, not permitted on iOS, and memory pressure from dirty pages is much bigger than from clean pages, exacerbated by the fact that they're not shared.