5 ms·

+1. Well said. They're joking themselves if they think Linux + Java is any better. For systems where speed is of the essence and latency is intollerable, a m

+1. Well said. They're joking themselves if they think Linux + Java is any better. For systems where speed is of the essence and latency is intollerable, a managed language will simply not do whether it's .net or java.

chipsy 17y ago
http://en.wikipedia.org/wiki/Real_time_Java http://en.wikipedia.org/wiki/Real_time_Java
eru 17y ago
Why? Are you afraid of automatic memory management? There are incremental real-time garbace collectors available. And that should be preferable to space leaks and seg-faults. Or is there any other reason you advice against using a `managed language'?
- mfairview 17y ago
  Sorry if my comments don't agree with you. I work on a system that takes in multibillion hits a day so do know a little about this argument. What's your background? We use lots of caches to improve our speed but caching doesn't really do well for generational GC's. I do see realtime GC's on the far horizon but currently it's been on the academic front.
  - DrJokepu 17y ago
    While I haven't worked on any project demanding this kind of scalability, I'm struggling to believe that garbage collection would be a bottleneck here. Modern managed environments these days are ridiculously fast and the garbage collectors are shockingly efficient. It's not 1994 anymore. I think they are more likely to have performance issues because of the dozens of complex webservice xml-rpc calls that are required just to get a simple piece of data (as it is usual in enterprise systems).
    - mfairview 17y ago
      Systems can get large enough that it would take a few seconds for GC to complete thereby causing unacceptable latency (especially if you need to meet strict SLAs). Consider a caching datastructure that needs to be constantly updated with fresh data. Objects in the cache remain there long enough to get into the final generation only to be pulled off some time later. Without memory management (e.g. object pooling for one), you'd quickly fill up your long lived generation causing the system to repeatedly want to reclaim.
  - eru 17y ago
    No offense taken. I was just arguing from an academic point of view. In the real world stuff is often much hairier, and if you can make C (or whatever you are using) to behave nicely, that's good for you. (I do not like Java either. Perhaps you should check out Ocaml? It's a nice and fast functional programming languages. The high-frequency traders at Jane Street Capital are quite fond of it. And I guess they are not too tolerant of delays.)
- nitrogen 17y ago
  Space leaks are still possible in a managed language if you forget to nullify every reference to an old object, or if your garbage collector doesn't delete objects that have a chain of circular references, and accessing a null reference still gives a NullPointerException. GC is nice, and real-time garbage collectors (such as rollendurchmesserzeitsammler) make managed languages useful in more situations, but they don't entirely free the programmer from thinking about memory management issues.
  - mfairview 17y ago
    With .Net there's also the issue with disposables of native resources. Also, if you're call takes a bit of time to complete, even automatic objects could get promoted up the generational chain unexpectedly. Take a look at the GC with MSoft's Singularity OS (bartok compiler). Looks promising but much farther down the road.
  - vetinari 17y ago
    If you don't nullify every reference, then the instance really should not be garbage collected, as it is not garbage yet. You should rather consider your application, where you are storing references and whether it is really needed (often better strategy is to make clone of the instance and treat it as disposable). Modern garbage collectors traverse the object graph and dispose everything, that is not in the graph - meaning, that closed chain of object with circular references is not a problem - they will get gc'ed. Accessing null reference does not give NullPointerException, ever. Dereferencing it does.
  - eru 17y ago
    Depending on how I parse your first sentence, it's either true or false. And yes, in general, you can still leak memory in a GC'ed environment, when you don't think about what you need to keep in memory. Or if you use lazy evaluation (like in Haskell), thinks can go out of hand very easily.
  - StrawberryFrog 17y ago
    Space leaks are still possible in a managed language ... if your garbage collector doesn't delete objects that have a chain of circular references. That can be rephrased as "Space leaks are still possible in a managed language ... if your garbage collector is dysfunctional in a way that modern ones aren't". I don't see the relevance.
joe_the_user 17y ago
Where is the Java reference? I have found not articles claiming the new system is in Java. Where???

chipsy 17y ago

http://en.wikipedia.org/wiki/Real_time_Java http://en.wikipedia.org/wiki/Real_time_Java

eru 17y ago

Why? Are you afraid of automatic memory management? There are incremental real-time garbace collectors available. And that should be preferable to space leaks and seg-faults. Or is there any other reason you advice against using a `managed language'?

mfairview 17y ago
Sorry if my comments don't agree with you. I work on a system that takes in multibillion hits a day so do know a little about this argument. What's your background? We use lots of caches to improve our speed but caching doesn't really do well for generational GC's. I do see realtime GC's on the far horizon but currently it's been on the academic front.
- DrJokepu 17y ago
  While I haven't worked on any project demanding this kind of scalability, I'm struggling to believe that garbage collection would be a bottleneck here. Modern managed environments these days are ridiculously fast and the garbage collectors are shockingly efficient. It's not 1994 anymore. I think they are more likely to have performance issues because of the dozens of complex webservice xml-rpc calls that are required just to get a simple piece of data (as it is usual in enterprise systems).
  - mfairview 17y ago
    Systems can get large enough that it would take a few seconds for GC to complete thereby causing unacceptable latency (especially if you need to meet strict SLAs). Consider a caching datastructure that needs to be constantly updated with fresh data. Objects in the cache remain there long enough to get into the final generation only to be pulled off some time later. Without memory management (e.g. object pooling for one), you'd quickly fill up your long lived generation causing the system to repeatedly want to reclaim.
- eru 17y ago
  No offense taken. I was just arguing from an academic point of view. In the real world stuff is often much hairier, and if you can make C (or whatever you are using) to behave nicely, that's good for you. (I do not like Java either. Perhaps you should check out Ocaml? It's a nice and fast functional programming languages. The high-frequency traders at Jane Street Capital are quite fond of it. And I guess they are not too tolerant of delays.)
nitrogen 17y ago
Space leaks are still possible in a managed language if you forget to nullify every reference to an old object, or if your garbage collector doesn't delete objects that have a chain of circular references, and accessing a null reference still gives a NullPointerException. GC is nice, and real-time garbage collectors (such as rollendurchmesserzeitsammler) make managed languages useful in more situations, but they don't entirely free the programmer from thinking about memory management issues.
- mfairview 17y ago
  With .Net there's also the issue with disposables of native resources. Also, if you're call takes a bit of time to complete, even automatic objects could get promoted up the generational chain unexpectedly. Take a look at the GC with MSoft's Singularity OS (bartok compiler). Looks promising but much farther down the road.
- vetinari 17y ago
  If you don't nullify every reference, then the instance really should not be garbage collected, as it is not garbage yet. You should rather consider your application, where you are storing references and whether it is really needed (often better strategy is to make clone of the instance and treat it as disposable). Modern garbage collectors traverse the object graph and dispose everything, that is not in the graph - meaning, that closed chain of object with circular references is not a problem - they will get gc'ed. Accessing null reference does not give NullPointerException, ever. Dereferencing it does.
- eru 17y ago
  Depending on how I parse your first sentence, it's either true or false. And yes, in general, you can still leak memory in a GC'ed environment, when you don't think about what you need to keep in memory. Or if you use lazy evaluation (like in Haskell), thinks can go out of hand very easily.
- StrawberryFrog 17y ago
  Space leaks are still possible in a managed language ... if your garbage collector doesn't delete objects that have a chain of circular references. That can be rephrased as "Space leaks are still possible in a managed language ... if your garbage collector is dysfunctional in a way that modern ones aren't". I don't see the relevance.

joe_the_user 17y ago

Where is the Java reference? I have found not articles claiming the new system is in Java. Where???