This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: Patch: Document and prototype JvAllocBytes() for CNI
- From: Bryce McKinlay <mckinlay at redhat dot com>
- To: tromey at redhat dot com
- Cc: Paul Gear <paul at gear dot dyndns dot org>, java at gcc dot gnu dot org, java-patches at gcc dot gnu dot org
- Date: Tue, 25 May 2004 15:22:10 -0400
- Subject: Re: Patch: Document and prototype JvAllocBytes() for CNI
- References: <40B1E532.8000805@gear.dyndns.org> <05179991-ADA0-11D8-ABA0-003065F97F7C@waitaki.otago.ac.nz> <40B24E6F.8000109@gear.dyndns.org> <87hdu5ik45.fsf@fleche.redhat.com> <40B33119.9090200@gear.dyndns.org> <40B39663.50709@redhat.com> <874qq4gwrf.fsf@fleche.redhat.com>
Tom Tromey wrote:
"Bryce" == Bryce McKinlay <mckinlay@redhat.com> writes:
Bryce> +This function can be useful if you need to associate some native data with a
Bryce> +Java object (perhaps stored in a RawData field - @pxref{Mixing with C++,,The
Bryce> +RawData Type}),
Actually you don't want to store _Jv_AllocBytes results in a RawData
field. It will just be collected instantly as these fields are not
scanned.
Hmm, good point. I keep forgetting about that.
I wonder whether we should support _Jv_AllocBytes as a user API at
all. I suppose it is useful for local allocations. But do we really
want to support storing the result of _Jv_AllocBytes in a field with
type Object? I'm concerned that we may want, at some future date, to
be able to assume that field types are actually meaningful.
I think we need a varient of the RawData type that is scanned. There are
places in libgcj where we use "Object" to store native data.
Regards
Bryce