IPC with gui（Java和Native code）

Question

My application is composed of 2 parts -

Some GUI logics in Java. Native code (mainly Delphi) - the GUI implementation itself.

Java uses the native code for trivial operations such as opening windows and responding to user-input events - the implementation is done via JNI.

I'm interested in dividing both sides to different processes - What would be the best way to implement IPC between them without hanging the gui? I'm leaning towards TCP sockets or shared memory, but before I dive into this I'd love to hear some input. Performance and a simple implementation are my main concerns.

Thanks in advance.

Answer 1

If your problem is about memory consumption

If you're running short of RAM (as suggested by your comments - but you should have better written this in your main question: the more details you give, the better answers you get).

Why are you mixing Java and Delphi? Java is probably not a good candidate do handle more than 1 GB of memory, due to its higher memory consumption for common tasks, and its internal GC. Even if you run the JVM in 64 bit, you'll face new scaling problems: you should have to write very specific code to handle huge memory with Java.

To be fair, the problems doesn't come from Delphi, but from the Java memory consumption. Therefore, IMHO you should better code your data layer in native code. Java is potentially increasing your problems.

You could either:

• Use the Free Pascal Compiler to compile a 64 bit library from Delphi code, then call it from you main 32 bit Delphi application or from Java using JNI using a Memory Mapped file as bridge .
• Change the way you access the data. You'll probably won't need to have all those GigaBytes of data at once. You could lay it on disk, then access to it via indexes, which will remain in RAM. If you use Delphi, you should either use your own file handling (you may use something like our BigTable library for storage and indexed access), or use a database (even SQlite3 is able to handle GB of data since its limit is about 140 terabytes, with the power of SQL for retrieving only the data).
• If you really need to stay in Java , you could probably use some DB instead of plain in-memory structures. You can use SQLite from Java, or a pure Java DB. I suspect it will reduce your memory consumption.

The main approach is: only keep in memory what is needed, and work with Map/Reduce algorithms or some kind of indexes.

If your problem is mixing GUI between Java and Delphi

From my experiment, this could be difficult, because JNI tends to use its own threads, and the VCL expect all its process to be run in the main thread.

So you could either:

1. Create some Delphi methods, running the VCL Synchronize method when called from the JNI to update the screen.
2. Rely on Windows GDI messages communication, ie create your own WM_USER* handler in the Delphi code, then refresh the screen content from you Java code just by sending some low-level PostMessage or SendMessage API. By design, this will be thread-safe.
3. Use a stateless approach: I like it very much. Just like in HTTP, you User Interface will act as a Client, and will ask periodically the Data layer (acting as a Server) for refreshed data. All this process will remain in the main thread, and could be easily made via a Timer. With a timer, a 500 ms period for each refresh is enough, and your main application will remain reactive.

In all cases...

For IPC, Memory Mapped files are faster than sockets, but GDI messages are ideal when it deals with some small amount of data. Sockets are good candidates, and will be fast also on a local machine: the small overhead about Memory Mapped files won't be noticeable if the data amount transmitted is only a few KB (up to 1 MB eg); and if you need to create a light Client version of your application, it will still work.

Answer 2

The question to your answer depends on your requirements (assuming that you have a good reason to divide the application this way):

If you need to do "trivial" tasks, ie not requring much data transfer, then it is probably better to use sockets. You need to create a protocol nevertheless, eg respect byte orders. Please also note, that transmitting data will slow down your gui responses.

If you need to transfer larger amounts of data, using shared memory may be more performant. Please note that here you need to do the bookkeeping yourself, that is done by the tcp implementation (eg a transmit / receive buffer). Using this The problem of requiring a protocol becomes even worse.

Answer 3

If you want a simple implementation then don't divide the application up into two processes. Performance-wise this is not an issue, but you are adding an order of complexity above what is required in a single application. You would need to have an extremely good reason for dividing the application into multiple proceses to overcome the time and effort that it will cost for you to deliver the same functionality with this architecure.