Re: "Multicore may be bad for Java" (and how about .NET)

roman modic wrote:
Hello!

"Dennis Landi" <nada@xxxxxxxx> wrote in message news:456d3058$1@xxxxxxxxxxxxxxxxxxxxxxxxx
http://www.devwebsphere.com/devwebsphere/2006/11/multicore_may_b.html#comment-25646600

Applicaple to .NET as well?

And what about Win32? I'm thinking about writing
an application that for some non-gui processes
will run multiple executables (configurable limit)
instead of threads. Executables will connect
to different servers and collect the data/results
in the shared local database (like Advantage
Local Database) ...

That is one of the things Java 6 is addressing actually. I am sure NET will too.

Sun has been entertaining the idea for quite some time of developing smaller JVMs that run in independent processes, somewhat like SAP runs its applications. Multi core processors will greatly make this type of functionality a much better reality.

The problem with running multiple exes as you are considering, is that each exe is still dependent upon each other; that is, if one dies in the process, they will all die. That is not what the Java world is talking about. They are speaking of shared processes through multiple VMs that are using thread pool management to maintain user state on each process running. In this manner, you can take advantage of multiple cores running in different processes (and in different cores) through a separate VM process that is assigned through session management. Why is this important? Well think of it this way. Each user has his own session, where the application runs only his instance in his own isolated VM. If that session dies, it is only applicable to that session; others sessions still run, since the VMs are assigned on a session by session basis.


Of course this article, while provocative, also has flaws. The author misapprehends that the J2EE stack runs in a single threaded environment (which it does not). If he were to limit this discussion to SWING alone, he would be correct, since the Swing model uses Listeners that use a wait state (for loopbacks) that are interconnected through a single threadpool. This is not true for J2EE and has never been true for J2EE. Multiple core processing has always been core to the later J2EE implementations. IBMs new VMs and JITs really take advantage of this.
.

Relevant Pages

  • Re: [PHP] PHP - Web/list Question...
    ... I have a list that extends over multiple pages. ... of the selected items from page to page, ... Accumulate them in the session. ... saves on network bandwidth of sending and retrieving the data with each ...
    (php.general)
  • Re: [PHP] PHP - Web/list Question...
    ... I have a list that extends over multiple pages. ... of the selected items from page to page, ... Accumulate them in the session. ... Tamper with the GET data or tamper with ...
    (php.general)
  • Re: Hyperthreading hurts 5.3?
    ... then it means that only the first core is able to ... is just a processor that is halted during system boot. ... the other processors are started by the BSP. ... hog a processor (unless the process runs multiple threads). ...
    (freebsd-questions)
  • Re: [PHP] PHP - Web/list Question...
    ... I have a list that extends over multiple pages. ... of the selected items from page to page, ... Accumulate them in the session. ... but the same possibility of tampering existed with the POST data. ...
    (php.general)
  • Re: Next Generation of Language
    ... by consumers. ... The first multicore (in a single socket macs were the intel boxes, ... and multiple cores per die. ... something for an 8, 16, 32 core box to do. ...
    (comp.lang.lisp)