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: 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


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