From: thhal at mailblocks.com (Thomas Hallgren) Date: Thu, 03 Feb 2005 20:35:37 +0100 Subject: [Pljava-dev] Re: [ANNOUNCE] ANN: PLJava 1.0.0 released In-Reply-To: <42023C0B.7040204@chemaxon.hu> References: <41F43B63.1080706@mailblocks.com> <42023C0B.7040204@chemaxon.hu> <42027D09.6060502@mailblocks.com> Message-ID: P?ter, > Are the java classes run in a bytecode-interpreted mode or are they > compiled into native code using HotSpot or similar? That depends on the JVM. The Sun JVM will detect hotspots and do JIT compilations as needed. The same goes for JRockit. If you use GCJ, then the current version will utilize native code for pljava's own Java code and the stuff loaded with install_jar will be interpreted. This is of course subject to improvement. You can preload precompiled .so files also, the same way the pljava.so is loaded, but that circumvents the normal classloader semantics. > Does the one session - one JVM archticture means that a large number > of sessions require large number of memory. E.g. 200 session needs ca. > 200*30MB = 6GB memory? Since the backend is single-threaded and starts a new process for each session, there's no way to have multiple sessions running in one JVM unless some inter-process communication protocoll is added. Please read the rationale behind choice of technology here: http://gborg.postgresql.org/project/pljava/genpage.php?jni_rationale. The pl-j project at http://plj.codehaus.org took another approach. They use one JVM and instead suffer from the IPC overhead. From a pure "java-in-the-backend" perspective, it would have been better if the postmaster spawned threads rather than processes. There are many other perspectives though as you will find out if you bring the subject up on one of the PostgreSQL mailing lists :-) Regards, Thomas Hallgren