4 ms·

Any limits depend on the particular JVM that you are using. In practice one needs to experiment. A few years back I did some comparisons between Java and Erlan

by mzl 16y ago

Any limits depend on the particular JVM that you are using. In practice one needs to experiment. A few years back I did some comparisons between Java and Erlang with respect to the number of threads the system could handle. Somewhere around a thousand threads was sufficient to make the JVM go very slowly.

Jabbles 16y ago
Surely the number of threads you can handle will depend on your hardware specs, in particular your cache sizes? Also, were these threads proper OS threads, or more lightweight coroutines? Thanks
- davidw 16y ago
  > > comparisons between Java and Erlang with respect to the number of threads the system could handle > Also, were these threads proper OS threads, or more lighweight coroutines? Exactly, it's apples to oranges in terms of what's happening underneath. Erlang has its own scheduler, whereas Java threads are system threads.
  - mzl 16y ago
    > Java threads are system threads AFAIK, Java threads are not required to map directly onto system threads.
    - davidw 16y ago
      Oh - I wasn't aware of that. Are there any of the main implementations where they aren't?
      - mzl 16y ago
        It is possible to manage it manually using Executors. Take a look at thread pools in http://download.oracle.com/javase/tutorial/essential/concurrency/executors.html http://download.oracle.com/javase/tutorial/essential/concurr... for an overview look at what to do. I hope that it works better than the last time I tried, since I will probably have to write some multi-threaded Java code quite soon :)
        lemming 16y ago
        This is a little misleading. It may be true that the Java specification doesn't require Java threads to map onto system threads but for all intents and purposes they're the same in all real implementations. The Executor framework doesn't change this, it gives you a flexible framework for task scheduling using thread pools.
        mzl 16y ago
        A lot of my earlier work was in formal specification of JVM thread behaviour, so I was very interested in what the standard said and required. I agree that in practice, it probably will map to threads, which is unfortunate. The experiments were mostly to satisfy my curiosity on how stuff behaved in the real world.
      - wmf 16y ago
        Back in the dark ages the Sun JVM used green threads. More recently, JRockit added "thin threads" to win VolanoMark. http://download.oracle.com/docs/cd/E13222_01/wls/docs81b/jrockit/threads.html http://download.oracle.com/docs/cd/E13222_01/wls/docs81b/jro...
- mzl 16y ago
  In my case it was about trying to make Java threads work in a situation where pre-emptive scheduling was needed for very many threads. The problem with the JVMs I tried was that they all started too many OS threads, and I couldn't get them to limit this enough. I might have done something wrong though. My general feel is that the threading model is too underspecified in Java. I haven't been doing Java for a while now, but I hope that the situation has become better. The Erlang model of starting threads for all the tasks to do is very alluring once one gets used to it :)
  - lemming 16y ago
    It may be very alluring but it's not going to work on Java since the model is different, and if you try to emulate Erlang on Java you're in for at least one surprise. This doesn't mean it's underspecified, in fact Java has arguably the most completely specified concurrency and memory model around. You just have to understand how it works to get the most out of it, like anything.
    - mzl 16y ago
      The memory model is nicely specified, given that the program is race-free. If it isn't, then all bets are off. There are a lot of programs that are not race-free (although he races in themselves might be benign), and as such have a very weak memory model. The concurrency model does have a very weak specification. It essentially says that a) threads exist, and b) threads with the highest priority will run at some point in time. This specification was left purposefully vague, AFAIK, so that a JVM implementation can rely on OS threads. Unfortunately, it also means that the programmer has to be aware of the specifics of all relevant JVM+OS combinations where a particular program is run. This is what I meant with underspecified, although I understand the reason for it.
      - lemming 16y ago
        This is absolutely not true. If your program is not race free, then you're going to have problems no matter what your concurrency model is. The memory model is not a property of the program, it's a property of the platform - since in Java you're programming to the JVM platform, the fact that the platform is very exactly specified is what allows you to show that your program is race free. I think you're looking for a very different sort of specification than what the JMM provides. It doesn't provide you with exact specifications of exactly how threads will behave, but no system that I'm aware of completely specifies that and any program that relies on that is fundamentally broken on any platform except exactly one version of one platform anyway - that which it was written and tested on. It's simply too dependent on the exact OS and version, the exact version of the processor, and a million other factors you can't control. Instead, the JVM, the JMM and company work together to exactly specify the interactions between threads that are safe. It turns out that this really is all you need to know to write correct concurrent programs, and you don't have to worry about combinations of anything, or how threads are implemented, or how many processors are available, etc etc. Additionally, with the j.u.c libraries in Java 5+ there are sufficiently good abstractions that you don't need to worry about any of this low level gore much. Seriously, if you're going to be writing multithreaded code in Java, read the book. It's awesome.
lemming 16y ago
See Kilim (http://www.malhar.net/sriram/kilim http://www.malhar.net/sriram/kilim) for a lightweight thread solution for Java that easily outpaces Erlang for thread creation and message passing. It's the basis for the Erjang project which runs Erlang bytecode on the JVM. While it's faster at a low level, it obviously doesn't provide everything that Erlang does (supervisor hierarchies etc). It's still pretty impressive that this can be achieved on the JVM though.
- silentbicycle 16y ago
  Well, sure. Erlang processes aren't threads. They're more like pre-empted coroutines, with a scheduler that factors in when they're blocking and waiting to receive a message (among many other things).
  - mzl 16y ago
    What would you say the essential difference is betwee pre-empted coroutines with a scheduler and threads? The only thing I could think of is that with coroutines one can explicitly pass control over to another coroutine, but that is something that Erlang does not provide, so I don't really understand what you mean.
    - silentbicycle 16y ago
      Erlang processes are managed by its scheduler, while threads are managed by the OS. Erlang has more info about appropriate stack sizes, garbage collection is done per-process* , it only pre-empts processes that are currently working or recently got a new message, and probably a half dozen other optimizations I'm not aware of. Let me know if you have more questions, I really like Erlang and I've wanted an excuse to research this. :) * And often doesn't need to be done at all, because the process terminates first.
- mzl 16y ago
  Cool, I hadn't seen this before. I will definetly check it out. Thanks for the pointer.

by mzl 16y ago

Jabbles 16y ago

Surely the number of threads you can handle will depend on your hardware specs, in particular your cache sizes? Also, were these threads proper OS threads, or more lightweight coroutines? Thanks

davidw 16y ago
> > comparisons between Java and Erlang with respect to the number of threads the system could handle > Also, were these threads proper OS threads, or more lighweight coroutines? Exactly, it's apples to oranges in terms of what's happening underneath. Erlang has its own scheduler, whereas Java threads are system threads.
- mzl 16y ago
  > Java threads are system threads AFAIK, Java threads are not required to map directly onto system threads.
  - davidw 16y ago
    Oh - I wasn't aware of that. Are there any of the main implementations where they aren't?
    - mzl 16y ago
      It is possible to manage it manually using Executors. Take a look at thread pools in http://download.oracle.com/javase/tutorial/essential/concurrency/executors.html http://download.oracle.com/javase/tutorial/essential/concurr... for an overview look at what to do. I hope that it works better than the last time I tried, since I will probably have to write some multi-threaded Java code quite soon :)
      - lemming 16y ago
        This is a little misleading. It may be true that the Java specification doesn't require Java threads to map onto system threads but for all intents and purposes they're the same in all real implementations. The Executor framework doesn't change this, it gives you a flexible framework for task scheduling using thread pools.
        mzl 16y ago
        A lot of my earlier work was in formal specification of JVM thread behaviour, so I was very interested in what the standard said and required. I agree that in practice, it probably will map to threads, which is unfortunate. The experiments were mostly to satisfy my curiosity on how stuff behaved in the real world.
    - wmf 16y ago
      Back in the dark ages the Sun JVM used green threads. More recently, JRockit added "thin threads" to win VolanoMark. http://download.oracle.com/docs/cd/E13222_01/wls/docs81b/jrockit/threads.html http://download.oracle.com/docs/cd/E13222_01/wls/docs81b/jro...
mzl 16y ago
In my case it was about trying to make Java threads work in a situation where pre-emptive scheduling was needed for very many threads. The problem with the JVMs I tried was that they all started too many OS threads, and I couldn't get them to limit this enough. I might have done something wrong though. My general feel is that the threading model is too underspecified in Java. I haven't been doing Java for a while now, but I hope that the situation has become better. The Erlang model of starting threads for all the tasks to do is very alluring once one gets used to it :)
- lemming 16y ago
  It may be very alluring but it's not going to work on Java since the model is different, and if you try to emulate Erlang on Java you're in for at least one surprise. This doesn't mean it's underspecified, in fact Java has arguably the most completely specified concurrency and memory model around. You just have to understand how it works to get the most out of it, like anything.
  - mzl 16y ago
    The memory model is nicely specified, given that the program is race-free. If it isn't, then all bets are off. There are a lot of programs that are not race-free (although he races in themselves might be benign), and as such have a very weak memory model. The concurrency model does have a very weak specification. It essentially says that a) threads exist, and b) threads with the highest priority will run at some point in time. This specification was left purposefully vague, AFAIK, so that a JVM implementation can rely on OS threads. Unfortunately, it also means that the programmer has to be aware of the specifics of all relevant JVM+OS combinations where a particular program is run. This is what I meant with underspecified, although I understand the reason for it.
    - lemming 16y ago
      This is absolutely not true. If your program is not race free, then you're going to have problems no matter what your concurrency model is. The memory model is not a property of the program, it's a property of the platform - since in Java you're programming to the JVM platform, the fact that the platform is very exactly specified is what allows you to show that your program is race free. I think you're looking for a very different sort of specification than what the JMM provides. It doesn't provide you with exact specifications of exactly how threads will behave, but no system that I'm aware of completely specifies that and any program that relies on that is fundamentally broken on any platform except exactly one version of one platform anyway - that which it was written and tested on. It's simply too dependent on the exact OS and version, the exact version of the processor, and a million other factors you can't control. Instead, the JVM, the JMM and company work together to exactly specify the interactions between threads that are safe. It turns out that this really is all you need to know to write correct concurrent programs, and you don't have to worry about combinations of anything, or how threads are implemented, or how many processors are available, etc etc. Additionally, with the j.u.c libraries in Java 5+ there are sufficiently good abstractions that you don't need to worry about any of this low level gore much. Seriously, if you're going to be writing multithreaded code in Java, read the book. It's awesome.

lemming 16y ago

See Kilim (http://www.malhar.net/sriram/kilim http://www.malhar.net/sriram/kilim) for a lightweight thread solution for Java that easily outpaces Erlang for thread creation and message passing. It's the basis for the Erjang project which runs Erlang bytecode on the JVM. While it's faster at a low level, it obviously doesn't provide everything that Erlang does (supervisor hierarchies etc). It's still pretty impressive that this can be achieved on the JVM though.

silentbicycle 16y ago
Well, sure. Erlang processes aren't threads. They're more like pre-empted coroutines, with a scheduler that factors in when they're blocking and waiting to receive a message (among many other things).
- mzl 16y ago
  What would you say the essential difference is betwee pre-empted coroutines with a scheduler and threads? The only thing I could think of is that with coroutines one can explicitly pass control over to another coroutine, but that is something that Erlang does not provide, so I don't really understand what you mean.
  - silentbicycle 16y ago
    Erlang processes are managed by its scheduler, while threads are managed by the OS. Erlang has more info about appropriate stack sizes, garbage collection is done per-process* , it only pre-empts processes that are currently working or recently got a new message, and probably a half dozen other optimizations I'm not aware of. Let me know if you have more questions, I really like Erlang and I've wanted an excuse to research this. :) * And often doesn't need to be done at all, because the process terminates first.
mzl 16y ago
Cool, I hadn't seen this before. I will definetly check it out. Thanks for the pointer.