Comment by nickpsecurity | Hacker News Reader

Comment by nickpsecurity | Hacker News Reader

Parent Full thread

All of you arguing with rwmj seem to have missed over a decade of research and deployed software in real-time embedded. Here's one product from 2005 whose company is well known in those circles:

http://www.businesswire.com/news/home/20050307005203/en/Aoni...

The first was in 2003 according to IBM work trying to improve on it in 2007:

http://researcher.watson.ibm.com/researcher/files/us-bacon/F...

I haven't checked on multicore research in a while. A quick Google implies that they're either there or part of the way there for one project on JamaicaVM:

https://www.researchgate.net/publication/221032857_Concurren...

So, yeah, you can do deterministic, hard-real-time GC's. They've been done since 2003 with products shipping since about 2005 for use in safety-critical applications. The DO-178B stuff in particular requires high rigour in how software is designed, coded, analyzed, and tested. That an implementation passed that indicates it can be built with high confidence. Research continues on them. Use in FOSS or popular embedded? Almost nothing.

These collectors have fixed pause time given a fixed heap size. All collectors have that. My toy mark&sweep collector have a fixed worst case pause time of 100 ms on a 128kb heap. The trick is offering a worst case guarantee on an arbitrarily sized heap.

Do hard, real-time, embedded systems usually have arbitrary sized or changing heaps? I thought most avoided dynamic or non-deterministic resource use as much as possible. Restricting the heap to a known size ahead of time then reaping benefits of HRT GC & higher-level language still seems worthwhile in many use-cases.

They don't, so there is certainly many use cases for real time gc:s. But keep in mind that the more parameters are known, such as heap size, memory allocation profile, software to run, hardware and so on the less useful gc becomes.

Often the cost of the extra complexity + specialized hardware outweighs the benefits of using a gc:ed language.

Those points are true. You have to balance these tradeoffs. The main point of my side of this discussion is (a) they exist and (b) they're useful sometimes so worth considering. That's all I'm saying.

I just have to smile. Parallel realtime garbage collector. What do you do, start threads? On an embedded system? What if all the other cores are already occupied with doing something? Do you preempt those threads? There, you lost a couple dozen microseconds until your garbage collector even started doing something (also see: Translation Lookaside Buffer flushes and its costs). I am sorry, I do not believe it. I need to hit timings within that time, accurately. I don't have any time for garbage, I need to get stuff done on the CPU, then and there!

I knew you'd focus on the one I Googled as evidence they're doing something in multicore that's not embedded. It's part of why I left it there. You predictably ignored ones for embedded systems that are hard, real-time along with those I cited deployed in industry for hard, real-time. You continue not believing in hard, real-time GC's despite them in production in real systems that aren't crashing or falling out of the sky. You continue to avoid any exploration of the significant amount of published designs you get just Googling "hard real-time GC" to focus on any peripheral, barely-related point you can.

There's no reason to doubt hard, real-time GC's exist or can work at this point. You should've moved to another goalpost like what tradeoffs were required as others did. You're either trolling us or dodging all evidence due to beliefs only rooted in faith. That is, ignoring all facts contrary to your belief that hard, real-time GC's don't exist or can't work in embedded. So, I'm done arguing with you since nobody can argue against religion that twists or dismisses real-world things to maintain its faith-based ones.

Reply on news.ycombinator.com