This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Invoke shared gcj binary from JVM?


In addition to various other issues, you should also consider that you
will end up with a system that uses two different garbage collectors
for different pieces.  This is almost always a bad idea.

If one of the collectors doesn't see references to its heap from the
other, you will end up with premature collection problems.  If they each treat
references from the other heap as roots, you can't collect cycles
spanning both heaps.  You may also end up doing basically twice as much
work in the GC.

Exactly which problem you run into with a gcj/HotSpot combination depends
on the details and the platform.  With some tweaking, you might be able
to get it to work if there are few references between heaps.  But in
general, I wouldn't want to encourage this approach.

As far as performance goes, in my experience gcj is likely to be a large win for
non-huge, short-running applications, due to start-up issues.  For larger
applications HotSpot's dynamic optimization can do some things that gcj can't,
and gcj can do some things Sun's JVM can't.  I think we've seen postings
stating that either one is significantly faster than the other on different
benchmarks.  There's no substitute for an experiment.

Hans

> -----Original Message-----
> From: Daniel Naab [mailto:dann@broadjam.com]
> Sent: Friday, October 10, 2003 11:51 AM
> To: 'java@gcc.gnu.org'
> Subject: Invoke shared gcj binary from JVM?
> 
> 
> As a GCJ newbie, I'm hoping someone can clue me in to a few things.
> 
> I'm responsible for a Java client-side application which we currently
> distribute with the Sun JRE (1.4.1).  For various reasons (primarily
> performance) we're pursuing gcj compilation of memory/cpu 
> intensive portions
> of the application and, at least for now, keeping our Swing UI intact.
> 
> First question: is this possible?  The only solution I can 
> conceive is to
> compile to static binaries and manually create JNI wrappers 
> over the DLLs.
> This is cumbersome because the first target for native 
> compilation is the
> database layer (HSQLDB), which has a large interface to wrap. 
>  Are there
> code generators to automate this process?
> 
> Secondly, should I even expect performance gains using a dual Sun/gcj
> environment?  Empirically, we've realized noticeable changes 
> compiling with
> JET on Windows, but JET isn't a cross-platform solution.
> 
> Any comments would be appreciated.
> 
> Thanks,
> Dan
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]