This is the mail archive of the java-patches@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: [classpath-0.98 merge branch] update and status


Andrew John Hughes wrote:
> 2008/10/6 Andrew Haley <aph@redhat.com>:
>> Andrew John Hughes wrote:
>>
>>> 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).
>> I suppose so, but I don't want to see a bunch of unnecessary changes,
>> especially if they adversely impact performance.  It's OK to make such
>> changes for NIO, but please leave all the RawData* for gcj-specific code.
> 
> I agree, that's why I left it as something to consider long-term.
> 
> The code I'm talking about is GCJ-specific code, but the main reason
> it is is because
> it uses gnu::gcj::RawData instead of gnu::classpath::Pointer.  I don't
> think just changing
> the NIO code to use Pointer would be enough, as it relies on the type
> being treated
> specially by the GC.

Sure, I get that.  I have no problem with reducing divergences, as long as
doing so doesn't lead to a singificant performance regression.

> The main issue I foresee would be that our JNI code uses Pointer in a
> completely different manner;
> as an object which wraps a 32 or 64-bit integer.  In contrast, RawData
> IS the data, not just a pointer
> to it.  If we simply unify the two types as Pointer, we risk a conflict.

Right.  What I don't want to see is the worst case where we keep gcj-specific
CNI code but convert it to using Pointer.  That would be a Bad Thing.

Andrew.


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