agora inbox for pljava-dev@postgresql.org  

help / color / mirror / Atom feed

From: Mark Dilger <pgsql@markdilger.com>
To: Thomas Hallgren <thomas@tada.se>
Subject: Re: Shared memory
Date: Tue, 28 Mar 2006 17:14:04 -0800
Message-ID: <4429DF5C.4010503@markdilger.com> (raw)
In-Reply-To: <4427A8F1.3020009@tada.se>
References: <4423CF32.3060406@tada.se>
	<20060324125851.GC8718@svana.org>
	<4427A8F1.3020009@tada.se>

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

view thread (22+ messages)

Message-ID: <4429DF5C.4010503@markdilger.com>
Permalink:  ../4429DF5C.4010503@markdilger.com/
Also on:    postgresql.org/message-id/4429DF5C.4010503@markdilger.com

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pljava-dev@postgresql.org
  Cc: pgsql@markdilger.com, thomas@tada.se
  Subject: Re: Shared memory
  In-Reply-To: <4429DF5C.4010503@markdilger.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox