RE: Native Compile to Shared Library?

["Boehm, Hans" <hans dot boehm at hp dot com>]

Although perhaps not completely impossible, this probably won't work
straight out of the box.  You would at least have to think about garbage
collection issues:

- There is probably no way for garbage collection to work completely
correctly across the two Java runtimes.  At a minimum, cycles spanning
the two heaps will never be collected.  In some cases that may be OK, in
others not.

- The gcj collector probably wouldn't see the Sun JVM heap, though the
details there would be platform dependent.  Thus gcj objects referenced
by the Sun heap could be prematurely reclaimed.  (Or, if you make the
Sun heap part of the gcj root set, objects referenced by dead parts of
the Sun heap won't be reclaimed on the gcj side.  Either way, this is
bad.)

Hans

> -----Original Message-----
> From: java-owner@gcc.gnu.org [mailto:java-owner@gcc.gnu.org] 
> On Behalf Of Andrew Haley
> Sent: Thursday, November 03, 2005 7:52 AM
> To: Michael Purdy
> Cc: java@gcc.gnu.org
> Subject: Re: Native Compile to Shared Library?
> 
> 
> Michael Purdy writes:
> 
>  > I'm revisiting the use of GCJ for native compilation 
> purposes for  > OSX, LInux, and Windows targets.  I'm 
> wondering if I can compile a  > set of classes to a shared 
> library that can be called via JNI or  > some other method 
> from a Java app running via a Sun JVM.
> 
> While there is no technical reason that would make this 
> impossible, it does sound rather arduous and difficult to maintain.
> 
>  > The goal would be to allow the necessary set of classes to 
> be  > native compiled, but still written in Java.  Thus, we 
> would not  > need to have 3 codebases for the native code in 
> c++ on each  > platform.
> 
> I don't quite know why you want to do this.
> 
> Andrew.
>