4 ms·

>smaller, low-power embedded/IoT device Do you want a GC there anyways?

by Redoubts 11y ago

kasey_junk 11y ago
Yes, very much so. GC on powerful servers is a well trodden path. Low power devices much less so.
- lelandbatey 11y ago
  Isn't it a less troden path because it's sacrificing too much and gaining too little, especially when we have languages coming up like rust with the memory safety of a GC but no gc runtime cost? I ask because I don't have much low-level/embedded experience, and I'm unaware of why you'd want a gc on such low power systems. If there's a use case though, I'd love to learn about it!
  - mehrdada 11y ago
    I think the question is easier to answer if we view "garbage collection" as automatic memory management in general, rather than a more specific case of automatic memory management via a runtime task colloquially known as the garbage collector. I believe automatic memory management is a universally desirable property whether you are running on a server or a small device. However, since you brought up Rust, I also think it is valid to debate the value of a runtime GC as opposed to another automatic memory management technique like automatic reference counting. I don't think that question is embedded-specific though: it applies just as much to the server environment.
    - pcwalton 11y ago
      How is tracing GC vs. pervasive reference counting relevant to Rust?
      - mehrdada 11y ago
        I merely used automatic reference counting as one alternative automatic memory management technique. Rust, as I understand it, uses a similar alternative, which is, at least on paper, similar to enforcing a max refcount of one on pointers, statically. I'm far from a Rust expert so feel free to correct me if I'm wrong.
        kibwen 11y ago
        I'd say that "reference counting" implies a dynamic/runtime component, which is not how Rust manages memory (unless you're specifically using the `Rc` pointer in the stdlib). I think it's important to be clear here because Swift and Objective-C rely on a technology known as "Automatic Reference Counting" (ARC), which does imply the usual dynamic cost of reference counting.
nickpsecurity 11y ago
There's a market for embedded Java. Atego makes a variety of runtimes for real-time use. http://www.ptc.com/developer-tools/perc http://www.ptc.com/developer-tools/perc Latency under 1ms per their material.
- thrownaway2424 11y ago
  That's interesting, from a business perspective. How did they arrive at that market via CAD?
  - nickpsecurity 11y ago
    What do you mean arrive "via CAD?" What is CAD in this context?
    - thrownaway2424 11y ago
      I mean how did PTC go from selling solid modelling software for IRIX to hawking an embedded JVM?
      - nickpsecurity 11y ago
        Hell, I didn't even know they were PTC now. On an acquisition or name-changing spree it seems lol. Aonix developed and marketed the Java technology. Got acquired by Atego and now apparently PTC. You will probably find the Wayback Machine's copy more informative with the non-JS links on left leading to PDF's showing its capabilities: https://web.archive.org/web/20111101211755/http://www.aonix.com/perc.html https://web.archive.org/web/20111101211755/http://www.aonix.... They had standard Java support, a better native API, GC pauses down to 100 microseconds, AOT compilation, and so on. I especially liked how they supported separation kernels like INTEGRITY and non-x86 architectures. The ability to use strong, user-mode isolation on the VM plus obfuscation of codebase and processor ISA makes for high resistance to whatever Internet throws at you. ;) Plus, embedded boards can be really cheap w/ Freescale's doing I/O, crypto, and TCP acceleration. So, I thought it was cool shit that could've benefited mainstream market if they thought of things like this and applied it properly. Could always build, in parallel, a FOSS-based setup in case they pulled out or some other crap that happens with proprietary companies. Can just painlessly move off their stack. Meanwhile, their stack rocked in its domain, still does given numbers I'm seeing in Go etc, and it's worth copying in some ways.

>smaller, low-power embedded/IoT device Do you want a GC there anyways?

kasey_junk 11y ago

Yes, very much so. GC on powerful servers is a well trodden path. Low power devices much less so.

lelandbatey 11y ago
Isn't it a less troden path because it's sacrificing too much and gaining too little, especially when we have languages coming up like rust with the memory safety of a GC but no gc runtime cost? I ask because I don't have much low-level/embedded experience, and I'm unaware of why you'd want a gc on such low power systems. If there's a use case though, I'd love to learn about it!
- mehrdada 11y ago
  I think the question is easier to answer if we view "garbage collection" as automatic memory management in general, rather than a more specific case of automatic memory management via a runtime task colloquially known as the garbage collector. I believe automatic memory management is a universally desirable property whether you are running on a server or a small device. However, since you brought up Rust, I also think it is valid to debate the value of a runtime GC as opposed to another automatic memory management technique like automatic reference counting. I don't think that question is embedded-specific though: it applies just as much to the server environment.
  - pcwalton 11y ago
    How is tracing GC vs. pervasive reference counting relevant to Rust?
    - mehrdada 11y ago
      I merely used automatic reference counting as one alternative automatic memory management technique. Rust, as I understand it, uses a similar alternative, which is, at least on paper, similar to enforcing a max refcount of one on pointers, statically. I'm far from a Rust expert so feel free to correct me if I'm wrong.
      - kibwen 11y ago
        I'd say that "reference counting" implies a dynamic/runtime component, which is not how Rust manages memory (unless you're specifically using the `Rc` pointer in the stdlib). I think it's important to be clear here because Swift and Objective-C rely on a technology known as "Automatic Reference Counting" (ARC), which does imply the usual dynamic cost of reference counting.

nickpsecurity 11y ago

There's a market for embedded Java. Atego makes a variety of runtimes for real-time use. http://www.ptc.com/developer-tools/perc http://www.ptc.com/developer-tools/perc Latency under 1ms per their material.

thrownaway2424 11y ago
That's interesting, from a business perspective. How did they arrive at that market via CAD?
- nickpsecurity 11y ago
  What do you mean arrive "via CAD?" What is CAD in this context?
  - thrownaway2424 11y ago
    I mean how did PTC go from selling solid modelling software for IRIX to hawking an embedded JVM?
    - nickpsecurity 11y ago
      Hell, I didn't even know they were PTC now. On an acquisition or name-changing spree it seems lol. Aonix developed and marketed the Java technology. Got acquired by Atego and now apparently PTC. You will probably find the Wayback Machine's copy more informative with the non-JS links on left leading to PDF's showing its capabilities: https://web.archive.org/web/20111101211755/http://www.aonix.com/perc.html https://web.archive.org/web/20111101211755/http://www.aonix.... They had standard Java support, a better native API, GC pauses down to 100 microseconds, AOT compilation, and so on. I especially liked how they supported separation kernels like INTEGRITY and non-x86 architectures. The ability to use strong, user-mode isolation on the VM plus obfuscation of codebase and processor ISA makes for high resistance to whatever Internet throws at you. ;) Plus, embedded boards can be really cheap w/ Freescale's doing I/O, crypto, and TCP acceleration. So, I thought it was cool shit that could've benefited mainstream market if they thought of things like this and applied it properly. Could always build, in parallel, a FOSS-based setup in case they pulled out or some other crap that happens with proprietary companies. Can just painlessly move off their stack. Meanwhile, their stack rocked in its domain, still does given numbers I'm seeing in Go etc, and it's worth copying in some ways.