This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Language extensions ?
- From: "Robin Garner" <robin dot garner at iname dot com>
- To: java at gcc dot gnu dot org
- Date: Tue, 01 Apr 2003 23:19:50 -0500
- Subject: Re: Language extensions ?
> >>>>> "Andrew" == Andrew Haley <aph at redhat dot com> writes:
>
> Tom> You can use gnu.gcj.RawData as a system-dependent pointer-sized
> Tom> value. However you can't really do anything with this value
> Tom> other than pass it around. It isn't treated like a real pointer;
> Tom> for instance the GC doesn't examine fields of this type.
>
> Andrew> Ouch. Do we really want to support gnu.gcj.RawData as part of
> Andrew> our API?
>
.
Tom> Second, why not just use CNI in this situation? That's what it is
Tom> there for, and it isn't like code using RawData extensions would be
Tom> portable Java anyway.
In a word, performance. Unless you can inline a CNI native method, a write barrier would need to incur a procedure call, and this would be disastrous for performance. For those that don't know much about generational garbage collectors, every pointer update has to be wrapped in a write barrier that checks whether the pointer crosses a generation boundary.
I could use a RawData field as long as I could convert between it and an int/long without the overhead of a procedure call, and do comparisons. Arithmetic would then be a nice-to-have.
The argument that "java doesn't need to do it because that's what CNI is for" is missing the point of what I'm suggesting. I'm saying that by adding a few features to Java there should be less need to drop out to C/C++, and this would be a Good Thing.
cheers,
Robin
--
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup