agora inbox for pljava-dev@postgresql.org
help / color / mirror / Atom feed[Pljava-dev] Remote PL/Java, Summary
4+ messages / 0 participants
[nested] [flat]
* [Pljava-dev] Remote PL/Java, Summary
@ 2006-04-01 10:09
0 siblings, 0 replies; 4+ messages in thread
From: @ 2006-04-01 10:09 UTC (permalink / raw)
Hi all,
And thanks for very good input regarding a remote alternative to PL/Java
(thread titled "Shared Memory"). I'm convinced that such an alternative
would be a great addition to PL/Java and increase the number of users.
The work to create such a platform that has the stability and quality of
todays PL/Java is significant (I really do think it is a
production-grade product today). So significant in fact, that I'm
beginning to think of a third alternative. An alternative that would
combine the performance of using in-process calls with the benefits of
sharing a JVM. The answer is of course to make the backend multi-threaded.
This question has been debated before and always promptly rejected. One
major reason is of course that it will not bring any benefits over the
current multi-process approach on a majority of the platforms where
PostgreSQL is used. A process-switch is just as fast as a thread-switch
on Linux based systems. Over the last year however, something has happen
that certainly speaks in the favor of multi-threading. PostgreSQL is
getting widely adopted on Windows. On Windows, a process-switch is at
least 5 times more expensive then a thread-switch. In order to
appropriate locking, PostgreSQL is forced to do a fair amount of
switching during transaction processing so the gain in using a
multi-threaded approach on Windows is probably significant. The same is
true for other OS'es where process-switching is relatively expensive.
There are other benefits as well. PostgreSQL would no longer need shared
memory and semaphores and lot more resources could be shared between
backend processes. The one major drawback of a multi-threaded approach
(the one that's been the main argument for the defenders of the current
approach) is vulnerability. If one thread is messing things up, then the
whole system will be brought to a halt (on the other hand, that can be
said about the current shared-memory approach as well). The cure for
this is to have a system that, to the extent possible, prevents this
from happening. How would that be possible? Well, such systems are
widely used today. Huge companies use them in mission critical
applications all over the world. They are called Virtual Machines. Two
types in particular are gaining more an more ground. The .NET based CLR
and the Java VM.
Although there's an Open Source initiative called Mono that implements
the CLR, I still don't see it as a viable alternative to create a
production-grade multi-platform database. Microsofts CLR is of course
confined to Microsoft platforms. The Java VM's are however a different
matter altogether. And with the java.nio.channels package that was
introduced in Java 1.4 and the java.util.concurrent package from Java
5.0, Java has taken a major steps forward in being a very feasible
platform for a database implementation. There's actually nothing
stopping you from doing a high-performance MVCC system using Java today.
A SQL parser would be based on JavaCC technology (the grammar is already
written although it needs small adjustments to comply with the
PostgreSQL dialect). Lots of technology is there out-of-the-box such as
regular expressions, hash-maps, linked lists, etc. Not to forget an
exceptionally great threading system, now providing atomic operations,
semaphores, copy-on-write arrays etc. In short, everything that a
database implementor could ever wish for.
The third alternative for PL/Java, an approach that gets more viable
every minute I think about it, is to implement the PostgreSQL backend
completely in Java. I'm involved in the development of one of the
commercial JVM's. I know that an enormous amount of resources are
constantly devoted to performance optimizations. The days when a complex
system written in C or C++ could outperform a JVM have passed. A static
optimizer can only do so well. A JVM, that collects heuristics,
communicates with the CPU about cache usage etc., can be a great deal
smarter on how the final machine code will be optimized, and
re-optimized should the conditions change. It would be great if
PostgreSQL could benefit from all this research.
If a commercial JVM is perceived as a problem, then combine^h^h^hpile
the code with GNU gcj instead of gcc like today.
The list of advantages can be made a mile long. There's no point in
listing everything here. From my own standpoint, I'm of course thinking
first and foremost about the advantages with PL/Java. It will become the
absolute most efficient PL of them all. Other languages, for which no
good Java implementation exists (I'm thinking Jython for Python, etc.),
can be implemented using JNI. The most common functions used by say,
PL/Perl could probably be implemented as callbacks into the Java domain
in order to make the changes in the respective PL minimal.
Opinions? Suggestions?
Kind Regards,
Thomas Hallgren
^ permalink raw reply [nested|flat] 4+ messages in thread
* [Pljava-dev] Remote PL/Java, Summary
@ 2006-04-02 04:36
2006-04-02 07:44 ` [Pljava-dev] Remote PL/Java, Summary
2006-04-02 07:56 ` [Pljava-dev] Remote PL/Java, Summary
0 siblings, 2 replies; 4+ messages in thread
From: @ 2006-04-02 04:36 UTC (permalink / raw)
Thomas Hallgren wrote:
> The third alternative for PL/Java, an approach that gets more viable
> every minute I think about it, is to implement the PostgreSQL backend
> completely in Java.
> Opinions? Suggestions?
Well, not speaking for the developers, obviously, but given the recent
discussion of PostgreSQL history, I can't imagine anyone discarding 10+
years of development to rewrite it all in Java. And I'm sure there
would be plenty of argument whether Java is up to the task. Hypersonic
has been around for a couple years, and I'm not aware of anyone using it
for enterprise databases.
Probably the only remotely feasible approach would be for you to
spearhead a team to write a proof of concept that works against the
existing PG database binary format. If that proof of concept could
demonstrate that Java can do some small set of tasks equally as well as
the current C implementation, people *might* be willing to engage in
further discussion.
Are you suggesting a Java backend as a replacement for the current
engine, or as an alternative?
--
Guy Rouillier
^ permalink raw reply [nested|flat] 4+ messages in thread
* [Pljava-dev] Remote PL/Java, Summary
2006-04-02 04:36 [Pljava-dev] Remote PL/Java, Summary
@ 2006-04-02 07:44 `
1 sibling, 0 replies; 4+ messages in thread
From: @ 2006-04-02 07:44 UTC (permalink / raw)
Guy Rouillier wrote:
>
> Are you suggesting a Java backend as a replacement for the current
> engine, or as an alternative?
>
Definitely a replacement. I thought yesterday was the perfect day for such a suggestion ;-)
Regards,
Thomas Hallgren
^ permalink raw reply [nested|flat] 4+ messages in thread
* [Pljava-dev] Remote PL/Java, Summary
2006-04-02 04:36 [Pljava-dev] Remote PL/Java, Summary
@ 2006-04-02 07:56 `
1 sibling, 0 replies; 4+ messages in thread
From: @ 2006-04-02 07:56 UTC (permalink / raw)
Guy Rouillier wrote:
>
> Probably the only remotely feasible approach would be for you to
> spearhead a team to write a proof of concept that works against the
> existing PG database binary format. If that proof of concept could
> demonstrate that Java can do some small set of tasks equally as well as
> the current C implementation, people *might* be willing to engage in
> further discussion.
>
Seriously. That *would* be a fun project. A lot has happen with Java since Hypersonic was
written and there's probably more to come. I doubt I'd be able to muster the resources to
pull something like that off though.
Regards,
Thomas Hallgren
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2006-04-02 07:56 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2006-04-01 10:09 [Pljava-dev] Remote PL/Java, Summary
2006-04-02 04:36 [Pljava-dev] Remote PL/Java, Summary
2006-04-02 07:44 `
2006-04-02 07:56 `
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox