Re: Shared memory

Thomas Hallgren wrote:
> Martijn,
>
> I tried a Socket approach. Using the new IO stuff that arrived with Java
> 1.4 (SocketChannel etc.), the performance is really good. Especially on
> Linux where an SMP machine show a 1 to 1.5 ratio between one process
> doing ping-pong between two threads and two processes doing ping-pong
> using a socket. That's acceptable overhead indeed and I don't think I'll
> be able to trim it much using a shared memory approach (the thread
> scenario uses Java monitor locks. That's the most efficient lightweight
> locking implementation I've come across).
>
> One downside is that on a Windows box, the ratio between the threads and
> the processes scenario seems to be 1 to 5 which is a bit worse. I've
> heard that Solaris too is less efficient then Linux in this respect.
>
> The real downside is that a call from SQL to PL/Java using the current
> in-process approach is really fast. It takes about 5 micro secs on my
> 2.8GHz i386 box. The overhead of an IPC-call on that box is about 18
> micro secs on Linux and 64 micro secs on Windows. That's an overhead of
> between 440% and 1300% due to context switching alone. Yet, for some
> applications, perhaps that overhead is acceptable? It should be compared
> to the high memory consumption that the in-process approach undoubtedly
> results in (which in turn might lead to less optimal use of CPU caches
> and, if memory is insufficient, more time spent doing swapping).
>
> Given those numbers, it would be interesting to hear what the community
> as a whole thinks about this.

Assuming by "community" you mean developers not normally involved in hackers, then:

1) As a developer, the required debugging time increases greatly when one
session can effect (or crash) all the other sessions. This in turn drives up
the cost of development. Unless some guarantees could be had against this sort
of intermittent runtime bugginess, I would be less likely to opt for PL/Java and
exposing myself to the potential cost overruns.

2) As a speed freak, I'm going to code things in C, not Java. So the appeal of
Java must come from something other than speed, such as stability and faster
development cycles.

My opinion is that it all depends whether you can hammer down a reliable
solution that has the necessary stability guarantees. Splitting the middle,
trying to get performance benefits at the cost of stability, would seem to make
PL/Java a sort of lukewarm solution on the speed side, and a lukewarm solution
on the stability side. I doubt I could get excited about it.

mark