This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: Alignment of stack traces
- To: "Boehm, Hans" <hans_boehm at hp dot com>
- Subject: RE: Alignment of stack traces
- From: Jeff Sturm <jsturm at one-point dot com>
- Date: Thu, 1 Mar 2001 17:37:21 -0500 (EST)
- cc: Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>, "'java at gcc dot gnu dot org'" <java at gcc dot gnu dot org>
On Thu, 1 Mar 2001, Boehm, Hans wrote:
> Are there enough other uses for this that it's worth doing?
Perhaps, though not in libgcj itself. When I migrate a source library for
use with java, the simplest step is to create wrapper classes with CNI.
The library is still using malloc/free, and gnu.gcj.RawData is appropriate
for storing pointers to native structs. This style of mixed memory
management often requires extensive use of finalizers.
An alernative short of rewriting the entire library in java is to make it
"gcj aware", e.g. by replacing malloc/free with GC_malloc and friends.
(It would be helpful if CNI exported some of its GC routines.) No CNI
field type has the right semantics for this currently (though a generic
java.lang.Object could be abused accordingly, I suppose... the GC
doesn't care yet whether fields are Java types or not).
This isn't all hypothetical, I've done it with some libraries, but don't
have the proof that it works well. For libraries that can allocate large
numbers of native structs (such as TclJava does) I expect some measurable
benefit. (I already posted some experimental results to comp.lang.tcl
regarding the benefits of conversative GC in general.)
Jeff