3 ms·

How many engineers work on, say, the Unreal Engine. The linux kernel? Windows? Do you think any of that stuff would work even marginally well running on the JVM

How many engineers work on, say, the Unreal Engine. The linux kernel? Windows? Do you think any of that stuff would work even marginally well running on the JVM (assuming the JVM had native driver support)? I don't quite follow your claims, nor do I put any stock in the tenure of your programming career. As for the off-shoring point, off-shoring is going to create questionable quality code regardless of the programming language.

pjmlp 11y ago
> How many engineers work on, say, the Unreal Engine. The linux kernel? Windows? So you just provided me examples where developers tend to be highly skilled just to get a foot in the door. Yet, the CVE list gets updated regularly with memory corruption exploits for them. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=double+free https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=double+free Or if you prefer, just for Linux https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=linux+double+free https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=linux+doubl... > Do you think any of that stuff would work even marginally well running on the JVM (assuming the JVM had native driver support)? Actually, are you aware that some military weapon systems are being driven with JVMs? Anyway automatic memory management doesn't mean automatically a JVM, there are quite a few other ways. Another fun fact, Unreal Engine and Windows are written mostly in C++. A language considered too bloated and slow to be usable for anything serious by mainstream developers in the early 90's. Also both use automatic memory management on their systems. Unreal has a kind of GC library. Windows nowadays has COM almost everywhere with reference counting. > I don't quite follow your claims, nor do I put any stock in the tenure of your programming career. Apparently some well known Fortune 100 companies and research institutes had another opinion. > As for the off-shoring point, off-shoring is going to create questionable quality code regardless of the programming language. The point being that those projects tend to go for cheap developers, so no, not everyone can deal with manual memory management.
- banachtarski 11y ago
  > So you just provided me examples where developers tend to be highly skilled just to get a foot in the door. Yep these are people I want to work with :) > Yet, the CVE list gets updated regularly with memory corruption exploits for them Security is not the concern of every piece of software. You can harden the pieces you care about. Honestly, not all of us are doing crypto, and for that, the recommendation is to leverage an existing library and sandbox it anyways (regardless of memory management strategy). > Actually, are you aware that some military weapon systems are being driven with JVMs? God help them > Another fun fact, Unreal Engine and Windows are written mostly in C++. A language considered too bloated and slow to be usable for anything serious by mainstream developers in the early 90's. I was developing in C and C++ in the 90s. C++ is a strict subset of C. The criticisms made no sense then and they make no sense now. C++03 was arguable an small incremental improvement over C++98 but C++11 is a huge step function in usability without sacrificing performance (which Rust has taken many good cues from). The point is, if something bad is happening, I can look at the dissassembly and see exactly what's going on. I can't do this with Java, Python, Ruby, etc. > Also both use automatic memory management on their systems. Unreal has a kind of GC library. Windows nowadays has COM almost everywhere with reference counting. The scripting engine in Unreal supports GC if you want it. It's trivial to embed Lua or something. That's part of the point. For the non-performance sensitive bits, sure do whatever. The COM interface is terrible, and a necessary evil for those in the industry. There's a reason DirectX12 is looked forward to. I don't want Windows reference counting my things any more unless I tell it to. > Anyway automatic memory management doesn't mean automatically a JVM, there are quite a few other ways. ... yes, I honestly can't imagine anyone in this thread would think otherwise. Heck, I've written a GC for a homebrew scripting language. > Apparently some well known Fortune 100 companies and research institutes had another opinion. My point is that how long you worked is sort of irrelevant in an actual academic discussion. Where you worked is just as irrelevant.
  - pjmlp 11y ago
    > Yep these are people I want to work with :) Which comes back to my point that only developers able to get hired at that level are able to do manual memory management in large scale. And even then, they resort to automatic memory management at higher levels in their stacks. > I can look at the dissassembly and see exactly what's going on. I can't do this with Java, Python, Ruby, etc. Just get a commercial JVM compiler, JIT Watch, Intel Amplifier. All of them provide the option to show the generated machine code. > There's a reason DirectX12 is looked forward to. I don't want Windows reference counting my things any more unless I tell it to. Better stop developing for Windows then. The Universal Windows Application model is the continuation of WinRT, an evolution of COM. In case you missed the note, DirectX 12 is still based on COM. Also the new User Driver Model is based on COM.
    - banachtarski 11y ago
      Yea still COM based but part of what is being removed is a huge swath of underlying automatic reference counting for a huge number of things. Constant buffers resources etc. Sure you can look at machine code generated from a virtualized language but I'd have a tough time understanding it in the context of the whole runtime, let alone being able to practically do anything about it.
      - pjmlp 11y ago
        > Sure you can look at machine code generated from a virtualized language but I'd have a tough time understanding it in the context of the whole runtime, let alone being able to practically do anything about it. It is no different than using -S and check what happens for several code patterns.
        banachtarski 11y ago
        Look man, I don't know what to tell you except that you view code fundamentally differently. My point is that yes, obviously everything gets turned into x64/x86 assembly at some point, and that yes, I'm sure seeing it is very easy. But if I need to prevent a GC pause from happening at some point in the frame my hands are tied. Debating this is like pulling teeth, and I'm inclined to say that if you can't follow at this point, just use your GC everywhere.

pjmlp 11y ago

> How many engineers work on, say, the Unreal Engine. The linux kernel? Windows? So you just provided me examples where developers tend to be highly skilled just to get a foot in the door. Yet, the CVE list gets updated regularly with memory corruption exploits for them. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=double+free https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=double+free Or if you prefer, just for Linux https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=linux+double+free https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=linux+doubl... > Do you think any of that stuff would work even marginally well running on the JVM (assuming the JVM had native driver support)? Actually, are you aware that some military weapon systems are being driven with JVMs? Anyway automatic memory management doesn't mean automatically a JVM, there are quite a few other ways. Another fun fact, Unreal Engine and Windows are written mostly in C++. A language considered too bloated and slow to be usable for anything serious by mainstream developers in the early 90's. Also both use automatic memory management on their systems. Unreal has a kind of GC library. Windows nowadays has COM almost everywhere with reference counting. > I don't quite follow your claims, nor do I put any stock in the tenure of your programming career. Apparently some well known Fortune 100 companies and research institutes had another opinion. > As for the off-shoring point, off-shoring is going to create questionable quality code regardless of the programming language. The point being that those projects tend to go for cheap developers, so no, not everyone can deal with manual memory management.

banachtarski 11y ago
> So you just provided me examples where developers tend to be highly skilled just to get a foot in the door. Yep these are people I want to work with :) > Yet, the CVE list gets updated regularly with memory corruption exploits for them Security is not the concern of every piece of software. You can harden the pieces you care about. Honestly, not all of us are doing crypto, and for that, the recommendation is to leverage an existing library and sandbox it anyways (regardless of memory management strategy). > Actually, are you aware that some military weapon systems are being driven with JVMs? God help them > Another fun fact, Unreal Engine and Windows are written mostly in C++. A language considered too bloated and slow to be usable for anything serious by mainstream developers in the early 90's. I was developing in C and C++ in the 90s. C++ is a strict subset of C. The criticisms made no sense then and they make no sense now. C++03 was arguable an small incremental improvement over C++98 but C++11 is a huge step function in usability without sacrificing performance (which Rust has taken many good cues from). The point is, if something bad is happening, I can look at the dissassembly and see exactly what's going on. I can't do this with Java, Python, Ruby, etc. > Also both use automatic memory management on their systems. Unreal has a kind of GC library. Windows nowadays has COM almost everywhere with reference counting. The scripting engine in Unreal supports GC if you want it. It's trivial to embed Lua or something. That's part of the point. For the non-performance sensitive bits, sure do whatever. The COM interface is terrible, and a necessary evil for those in the industry. There's a reason DirectX12 is looked forward to. I don't want Windows reference counting my things any more unless I tell it to. > Anyway automatic memory management doesn't mean automatically a JVM, there are quite a few other ways. ... yes, I honestly can't imagine anyone in this thread would think otherwise. Heck, I've written a GC for a homebrew scripting language. > Apparently some well known Fortune 100 companies and research institutes had another opinion. My point is that how long you worked is sort of irrelevant in an actual academic discussion. Where you worked is just as irrelevant.
- pjmlp 11y ago
  > Yep these are people I want to work with :) Which comes back to my point that only developers able to get hired at that level are able to do manual memory management in large scale. And even then, they resort to automatic memory management at higher levels in their stacks. > I can look at the dissassembly and see exactly what's going on. I can't do this with Java, Python, Ruby, etc. Just get a commercial JVM compiler, JIT Watch, Intel Amplifier. All of them provide the option to show the generated machine code. > There's a reason DirectX12 is looked forward to. I don't want Windows reference counting my things any more unless I tell it to. Better stop developing for Windows then. The Universal Windows Application model is the continuation of WinRT, an evolution of COM. In case you missed the note, DirectX 12 is still based on COM. Also the new User Driver Model is based on COM.
  - banachtarski 11y ago
    Yea still COM based but part of what is being removed is a huge swath of underlying automatic reference counting for a huge number of things. Constant buffers resources etc. Sure you can look at machine code generated from a virtualized language but I'd have a tough time understanding it in the context of the whole runtime, let alone being able to practically do anything about it.
    - pjmlp 11y ago
      > Sure you can look at machine code generated from a virtualized language but I'd have a tough time understanding it in the context of the whole runtime, let alone being able to practically do anything about it. It is no different than using -S and check what happens for several code patterns.
      - banachtarski 11y ago
        Look man, I don't know what to tell you except that you view code fundamentally differently. My point is that yes, obviously everything gets turned into x64/x86 assembly at some point, and that yes, I'm sure seeing it is very easy. But if I need to prevent a GC pause from happening at some point in the frame my hands are tied. Debating this is like pulling teeth, and I'm inclined to say that if you can't follow at this point, just use your GC everywhere.