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: Tom Tromey <tromey at redhat dot com>
- To: Bryce McKinlay <mckinlay 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: 25 May 2004 12:57:40 -0600
- 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>
- Reply-to: tromey at redhat dot com
>>>>> "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.
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.
Tom