Re: [classpath-0.98 merge branch] update and status

[Andrew John Hughes <gnu_andrew at member dot fsf dot org>]

On 20:58 Wed 24 Sep     , David Daney wrote:
> Andrew John Hughes wrote:
>> On 18:51 Tue 23 Sep     , Andrew Haley wrote:
>>   
>>> Andrew Haley wrote:
>>>     
>>>> Matthias Klose wrote:
>>>>
>>>>       
>>>>> There are still some todo's; not sure which ones are required before 
>>>>> the merge
>>>>> to the trunk:
>>>>>
>>>>>  - Apply the Thread optimization change
>>>>>         
>>>> This isn't important: gcj has its own implementation of ThreadLocal.
>>>>
>>>>       
>>>>>  - Apply the nio change, backout out for the 2008-08-11 classpath 
>>>>> import
>>>>>
>>>>>  - Tom Tromey had a comment that he wanted to add/fix something:
>>>>>    http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36762
>>>>>
>>>>>  - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36763
>>>>>
>>>>>  - * scripts/makemake.tcl: Switch gnu.java.math to BC compilation.
>>>>>    concerns by Andrew Haley.
>>>>>         
>>>> This objection from me isn't very important either.
>>>>
>>>>       
>>>>>  - Build a gjdoc binary.
>>>>>
>>>>> I'll be offline for at least one week, starting tomorrow on Monday.
>>>>>         
>>>> OK, thanks for all the work so far.
>>>>       
>>> I'll now be out of the loop.  I've added a couple of fixes, but the
>>> nio and the gjdoc binary are still to do.  Everything else seems OK.
>>>
>>> Andrew.
>>>     
>>
>> Matthias added gjdoc binary support earlier.  Here's the patch to
>> add the NIO change, which I just applied to the merge tree.
>>
>> Note that this also regenerates some of the antlr generated files.
>> Unfortunately it seems it includes its version in the generated Java
>> files.  There also seem to be some code changes, which I've left
>> because this is a later version than the one used previously.  I also
>> reverted an unmarked local change to configure.ac made by Matthias before
>> the correct fix from Classpath was backported.
>>
>> The issues with merging the NIO patch arose from the use of
>> gnu.classpath.Pointer in these classes and the pointer at which they
>> interact with GCJ local classes in libjava/java/nio, all of which use
>> gnu.gcj.RawData.  For this patch, I've simply patched the Classpath
>> classes to use RawData (with appropriate comments).  The Classpath
>> classes only use this to call a superclass constructor which ends up
>> at java.nio.Buffer, a GCJ local class.  Ian's NIO change makes this
>> pointer final and in the process, sets it once in the Buffer
>> superclass instead of in those classes that use it.
>>
>> Long term, should RawData be replaced with gnu.classpath.Pointer?
>> I've just been reading through the rather long thread when this was
>> introduced back in 2004:
>>
>> http://osdir.com/ml/java.classpath.devel/2004-04/msg00019.html
>>
>> There doesn't seem to be much mention of how this change would work
>> its way back to GCJ, if at all.  From what I can see, technically the
>> two classes are identical but they have different semantics.  RawData
>> is a pointer in itself used by CNI, whereas gnu.classpath.Pointer is
>> an abstraction which is used via Pointer32 and Pointer64 in the
>> reference JNI code.
>>
>> What issues would there be with GCJ (and particularly CNI) using
>> gnu.classpath.Pointer in the same way as RawData is currently used?
>> The advantage is that we would have less maintenance issues with
>> respect to Classpath merges, but the disadvantage is we then possibly
>> confuse these two classes.  Notably, gnu.classpath.Pointer WITH its
>> subclasses is used in the Gtk+ and GStreamer JNI peer code so GCJ
>> would have to use the class differently in the two contexts (CNI and
>> JNI).
>>
>> Thoughts?
>>
>> ChangeLog:
>>
>> 2008-09-25  Andrew John Hughes  <gnu_andrew@member.fsf.org>
>>
>> 	* classpath/configure,
>> 	* classpath/configure.ac:
>> 	Resynchronise with Classpath's configure.
>> 	* classpath/examples/Makefile.in:
>> 	Add equivalent support for building as in
>> 	tools/Makefile.in.
>> 	* classpath/java/nio/Buffer.java,
>> 	* classpath/java/nio/ByteBuffer.java,
>> 	* classpath/java/nio/ByteBufferImpl.java,
>> 	* classpath/java/nio/CharBuffer.java,
>> 	* classpath/java/nio/CharBufferImpl.java,
>> 	* classpath/java/nio/CharSequenceBuffer.java,
>> 	* classpath/java/nio/CharViewBufferImpl.java,
>> 	* classpath/java/nio/DirectByteBufferImpl.java,
>> 	* classpath/java/nio/DoubleBuffer.java,
>> 	* classpath/java/nio/DoubleBufferImpl.java,
>> 	* classpath/java/nio/DoubleViewBufferImpl.java,
>> 	* classpath/java/nio/FloatBuffer.java,
>> 	* classpath/java/nio/FloatBufferImpl.java,
>> 	* classpath/java/nio/FloatViewBufferImpl.java,
>> 	* classpath/java/nio/IntBuffer.java,
>> 	* classpath/java/nio/IntBufferImpl.java,
>> 	* classpath/java/nio/IntViewBufferImpl.java,
>> 	* classpath/java/nio/LongBuffer.java,
>> 	* classpath/java/nio/LongBufferImpl.java,
>> 	* classpath/java/nio/LongViewBufferImpl.java,
>> 	* classpath/java/nio/MappedByteBuffer.java,
>> 	* classpath/java/nio/MappedByteBufferImpl.java,
>> 	* classpath/java/nio/ShortBuffer.java,
>> 	* classpath/java/nio/ShortBufferImpl.java,
>> 	* classpath/java/nio/ShortViewBufferImpl.java:
>> 	Replace use of gnu.classpath.Pointer with gnu.gcj.RawData,
>> 	and fix some formatting issues.
>>   
>
> Are  gnu.gcj.RawData and gnu.classpath.Pointer equivalent?   If so could we 
> patch the compiler to make them an alias for each other?  APH did something 
> similar with the CPStringBuilder.  That way the library code could be 
> shared.
>

Syntactically, they are both marker interfaces.  The semantics applied to them
differ.  RawData _is_ a pointer and GCJ won't garbage collect it e.g. from
gcc/java/boehm.c:

      if (JREFERENCE_TYPE_P (TREE_TYPE (field))
         /* An `object' of type gnu.gcj.RawData is actually non-Java                                                     
             data.  */
          && TREE_TYPE (field) != rawdata_ptr_type_node)

In GNU Classpath, Pointer is an abstraction which _wraps_ a pointer rather than
being one itself.  GNU Classpath's reference implementation provides two
subclasses, Pointer32 and Pointer64, which are used in the reference JNI
implementations such as Gtk+ and GStreamer.

What I'm asking is whether the root Pointer class could be used instead of
RawData to provide the CNI no-garbage-collect semantics, thus removing
a source of merge issues between the two (most of our NIO differences are
due to this).

> David Daney
>> 	* classpath/tools/gnu/classpath/tools/gjdoc/expr/JavaLexer.java,
>> 	* classpath/tools/gnu/classpath/tools/gjdoc/expr/JavaLexer.smap,
>> 	* classpath/tools/gnu/classpath/tools/gjdoc/expr/JavaRecognizer.java,
>> 	* classpath/tools/gnu/classpath/tools/gjdoc/expr/JavaRecognizer.smap,
>> 	* classpath/tools/gnu/classpath/tools/gjdoc/expr/JavaTokenTypes.java,
>> 	* classpath/tools/gnu/classpath/tools/gjdoc/expr/JavaTokenTypes.txt:
>> 	Regenerated (later version of antlr).
>> 	* java/nio/Buffer.h: Regenerated.
>> 	* java/nio/Buffer.java: Ported changes from Classpath.
>> 	* java/nio/ByteBuffer.h,
>> 	* java/nio/CharBuffer.h: Regenerated.
>> 	* java/nio/DirectByteBufferImpl.java: Ported changes from
>> 	Classpath.
>> 	* java/nio/DoubleBuffer.h,
>> 	* java/nio/FloatBuffer.h,
>> 	* java/nio/IntBuffer.h,
>> 	* java/nio/LongBuffer.h,
>> 	* java/nio/MappedByteBuffer.h,
>> 	* java/nio/MappedByteBufferImpl.h: Regenerated.
>> 	* java/nio/MappedByteBufferImpl.java: Ported changes from
>> 	Classpath.
>> 	* java/nio/ShortBuffer.h: Regenerated.
>>
>>   
>
>

-- 
Andrew :)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint = F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8