[Nestedvm] Planing a large C to Java migration project

[Bertram, Alexander]

On Wed, Aug 31, 2011 at 5:28 PM, Brian Alliet <brian at brianweb.net> wrote:

> On Wed, Aug 31, 2011 at 01:08:26PM +0200, Yaffe, Lior wrote:
> > We never ported this source code to MIPS though.
>
> Hopefully this shouldn't cause any issues. As long as your code doesn't
> make any assumptions about endianness, alignment, etc you shouldn't
> have any trouble.
>
> NestedVM uses newlib, a small libc designed for embedded systems.
> Newlib doesn't have all the features of glibc (but it does fully
> support ANSI C) and might cause you some trouble though.
>
>
I spent a lot of time last year trying to get a large C/Fortran project to
compile in the nestedvm environment and ultimately gave up and embarked on a
much longer process of rewriting the code into java. NestedVM is a brilliant
system but there are some gotchas:

- Newlib is the biggest block. As Brian said, it's a subset of glibc and
nestedvm uses an older version which is even smaller. There is some
functionality missing (iconv, threads) but also a lot of superficial
differences (like no stdint.h) that take time to paper over.
- Your project needs to compile under GCC 3.something... (or you need to
updated NestedVM to use GCC 4)
- You will need to change any dynamic linking to static linking in your
project, which perhaps is only a problem if loading modules at runtime is a
key part of the architechture.

I'd say the bottom line is that if your existing code base is well written
and you're committed to maintaining it in C / GCC 3 / Newlib over the long
term, then NestedVM would be a big win, but prepare to get your hands dirty
wrestling with compilers and C defines. With my own project, I just got to
the point where I decided I would rather spend the energy on rewriting in
Java then jury-rigging header files and fighting with GCC 3.

Good luck!



> > Our existing code is compiled into DLL/SO file and is loaded in runtime
> > using JNI.
>
> NestedVM's bridge to Java is totally different than JNI (although
> writing a JNI-like api on top of the current interface should be
> possible). How intertwined is your native and java code? If they mostly
> communicate at arms length you shouldn't have too much trouble, but if
> you have dozens of functions, complex data types, callbacks to Java,
> etc building the bridge between the two worlds will take some work.
>
> > Given the current status of the NestedVM product would you recommend
> > using NestedVM for this purpose ?
>
> Yes, this sort of thing is exactly what NestedVM was designed for.
>
> The only reason I wouldn't recommend NestedVM would be if your native
> code was performance critical. Your native code will likely only run
> 10%-20% as fast under NestedVM.
>
> > Would be able to assist us in case we run into problems or need product
> > modifications ?
>
> Certainly.
>
> -Brian
>
> _______________________________________________
> Nestedvm mailing list
> Nestedvm at lists.hcoop.net
> https://lists.hcoop.net/listinfo/nestedvm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.hcoop.net/pipermail/nestedvm/attachments/20110901/0d4cee71/attachment.htm