Re: binfmt_misc and persistent interpreters [fwd]

Adam J. Richter (
Tue, 28 Jul 1998 04:45:32 -0700

In article <> you write:
>On Mon, 27 Jul 1998, Brian Jepson wrote:
>> Richard,
>> I was wondering if you had considered the possibility of extending
>> binfmt_misc to work with a persistent interpreter. For example, instead
>> of executing the java executable each time someone runs a java program,
>> binfmt_misc would start a Java VM once, and then load the specified class
>> within a thread in that VM. Essentially, there would be one Java VM
>> running on a given server, and all Java processes would run within that
>> VM.
>> This approach should work for any VM that supports threading (Java, Perl),
>> and the performance benefits would be fantastic. Eventually, some sort of
>> load-balancing scheme could be devised, and VMs running on the same
>> network could effectively provide clustering capabilities.
>> Have you given any thought to how binfmt_misc could support this sort of
>> thing, or has anyone else raised this issue? I might be interested in
>> working on this, depending on how much time I have, but I would not want
>> to duplicate the effort, if anyone is already doing this.
>I have not even thought about that, because (initially) I wanted to
>keep it as simple as possible. To make it work you have to run the
>VMs as a daemon-like program that could be signalled from the kernel,
>or little more complicated and uglier be notified by SYSV-messages.
>Hmm... the more I think about it - it would be necessary to make
>a new syscall (like request_binary_to_run) that gets the command
>and args of the program/script to be executed. The daemon/VM would
>call this after beeing signalled by the kernel.
>This would be clean, I think (I like it - but I wont use it...).
>So If you need it and think it would be really worth the effort,
>you could do it like this.

This can easily be done without any kernel changes. Just have
some small helper program similar to the ELF loader
(/lib/ that would rendezvous with your server process
and map the program through shared memory or something.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 205     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to Please read the FAQ at