5 ms·

I don't know whether it would have been a good thing (really don't know). It seems that GC's developed so far are basically inseparable from individual languag

by sixbrx 13y ago

I don't know whether it would have been a good thing (really don't know). It seems that GC's developed so far are basically inseparable from individual language implementations, or rather closely related families of languages, which have similar approaches to programming (e.g. rooted in single virtual dispatch on heap referenced objects). These systems require complete buy in to a particular approach to computing in order to be usable from new languages, forcing them to use the same object layouts, calling convention, stack usage conventions, unwinding support, view of concurrency, etc, which can all be very limiting. [Edit for clarity: the high performance GC and access to existing libraries is the honey, the forced view of computing is the resulting bee sting.] I think if such a siloed GC VM system would have become dominant, we would not have such a huge set of reusable routines to call from really innovative new languages. That's something for which we can be grateful to C I think, despite all of its flaws. So I think even the high performance VM's delivered by the JVM and CLR are too limiting, really. I'm a lot more excited by the prospect of LLVM making precise GC easier for language implementers. From what I understand, the API is being standardized now, so maybe in a few years we can start enjoying some common work on high performance GC's usable by a really wide variety of languages which don't all have the same narrow approach to computing.

pjmlp 13y ago
> I think if such a siloed GC VM system would have become dominant, we would not have such a huge set of reusable routines to call from really innovative new languages. No, it would just mean you would have GC as an another OS service, and use whatever OS ABI was in place. > So I think even the high performance VM's delivered by the JVM and CLR are too limiting, really They already good enough to replace C++ systems in high performance trading systems. I only use C++ in hobby projects nowadays. At work, when I get to see C++ code in enterprise systems, it is usually as part of migration projects to replace them by JVM/.NET based ones.
- joe_the_user 13y ago
  Cheers to the discussion between pjmlp and sixbrx - classic hn. I feel like computing is such a large beast that one can find two very informed people disagreeing while each being right in wide area. I don't think you can even call memory allocation "just another OS service", (much less garbage collection). Memory allocation is going to be ubiquitous in any application and if it's performance degrades, so will the application's performance. Further, one knows nothing about "what's behind the curtain", performance will degrade for any medium performance or higher application. Java is perfect for enterprise code because most enterprise software is more forcused on data-safety and generally playing well with the rest of the data zoo. Enterprise software isn't high performance and thus the costs of c++ outweigh the benefits. Or even more C++ is needed in system programming and shrink-wrap software where performance is crucial. On the other, other hand, if a dominant OS forty years ago had imposed a GC model that became ubiquitous, perhaps the sweet-zone where the programmer doesn't have to worry about the allocation process would have been larger and the area where you did have to worry about the allocation process might not have been harder to deal with. Especially, a single ubiquitous program layout model would force hardware makers to adapt and what I understand is that a lot of the need for multiple memory/program-layout models comes from innovative hardware getting the last once of performance through constant novelty in low-level memory access.
  - pjmlp 13y ago
    +1 for the comment. Just some info on my side. Like many developers I do have my issues with C++, but I do like it, since my Turbo C++ days. However, my experience with GC enabled system programming languages dates back to being an Oberon user in the mid-90's. So I experienced first hand that such systems are possible and have been ever since dismayed by the lack of attention from mainstream OS vendors.

by sixbrx 13y ago

pjmlp 13y ago

> I think if such a siloed GC VM system would have become dominant, we would not have such a huge set of reusable routines to call from really innovative new languages. No, it would just mean you would have GC as an another OS service, and use whatever OS ABI was in place. > So I think even the high performance VM's delivered by the JVM and CLR are too limiting, really They already good enough to replace C++ systems in high performance trading systems. I only use C++ in hobby projects nowadays. At work, when I get to see C++ code in enterprise systems, it is usually as part of migration projects to replace them by JVM/.NET based ones.

joe_the_user 13y ago
Cheers to the discussion between pjmlp and sixbrx - classic hn. I feel like computing is such a large beast that one can find two very informed people disagreeing while each being right in wide area. I don't think you can even call memory allocation "just another OS service", (much less garbage collection). Memory allocation is going to be ubiquitous in any application and if it's performance degrades, so will the application's performance. Further, one knows nothing about "what's behind the curtain", performance will degrade for any medium performance or higher application. Java is perfect for enterprise code because most enterprise software is more forcused on data-safety and generally playing well with the rest of the data zoo. Enterprise software isn't high performance and thus the costs of c++ outweigh the benefits. Or even more C++ is needed in system programming and shrink-wrap software where performance is crucial. On the other, other hand, if a dominant OS forty years ago had imposed a GC model that became ubiquitous, perhaps the sweet-zone where the programmer doesn't have to worry about the allocation process would have been larger and the area where you did have to worry about the allocation process might not have been harder to deal with. Especially, a single ubiquitous program layout model would force hardware makers to adapt and what I understand is that a lot of the need for multiple memory/program-layout models comes from innovative hardware getting the last once of performance through constant novelty in low-level memory access.
- pjmlp 13y ago
  +1 for the comment. Just some info on my side. Like many developers I do have my issues with C++, but I do like it, since my Turbo C++ days. However, my experience with GC enabled system programming languages dates back to being an Oberon user in the mid-90's. So I experienced first hand that such systems are possible and have been ever since dismayed by the lack of attention from mainstream OS vendors.