Re: Embedded sable?

"Grzegorz B. Prokopski" <[email protected]> Sat, 11 Jun 2005 23:56:10 -0400
Newsgroups gmane.comp.java.vm.sablevm.devel
Organization Debian http://www.debian.org - The Free Operating System
Message-ID <[email protected]>
On Sun, 2005-12-06 at 12:27 +1000, William Uther wrote:
> Thanks for the pointers.  The processes are very non-standard. (You  
> get one process for each binary.  They all start on boot.  There is  
> no way to restart them once they terminate, although they can put  
> themselves to sleep and another process can wake them up.)  The  
> threading doesn't exist.  Is there any way to run Sable single threaded?

Should be fine, as long as the apps you want run are single threaded
as well.  You'll just need some stubs here and there probably.

> Other way around.  I want sable to be the library and I'll embed it  
> into my own executable.  Sable will also need to call out to my  
> functions.  JNI would be fine for both types of embedding, but I need  
> sable to be a static library.

Sounds all right for the first part.  See below for the second.

> > We don't  support static compilation ATM, if that's what you had in mind.
> 
> ahh.  That is what I had in mind.  Is that a fundamental limitation,  
> or would I be able to make a libsablevm.a relatively easily?

It's not an inherent limitation, just something that hasn't been worked
on yet.  You will be able to get libsablevm.a but it won't run I am
afraid.  One of the first things it does when you try to execute any
java code is to lt_dlopen class library shared libraries.  This is a
convenient way of doing so, because then we can ask for an address of
a function inside of such library by simply knowing function's name.

But I am pretty sure this problem is solvable and it should not be too
tricky, really.  I've just never gotten arund to look into it closer.

One of the possible solutions is a method we already use in environments
where dlopen(NULL) does not work (like Windows/Cygwin).  We grep thru
the source code and collect addresses of all the JNI functions
libsablevm contains, then we autogenerate C code that will be included
in libsablevm itself and will fill in the list of name-address pairs
at startup.  Sounds complicated, but isn't really.  Just look at
sablevm/src/libsablevm/internal_methods* files and how they're used.

As I mentioned above, I've never played much with static libraries, so
there's pretty good chance that there exists a yet simpler solution to
getting function addresses "by name", which is what is needed.

HTH, I need to get back to studying.

			Grzegorz B. Prokopski
-- 
Grzegorz B. Prokopski           <[email protected]>
SableVM - Free, LGPL'ed Java VM  http://sablevm.org
Why SableVM ?!?                  http://sablevm.org/wiki/Features
Debian GNU/Linux - the Free OS   http://www.debian.org