This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: [classpath-0.98 merge branch] update and status
- From: Andrew Haley <aph at redhat dot com>
- To: Andrew John Hughes <gnu_andrew at member dot fsf dot org>
- Cc: David Daney <ddaney at avtrex dot com>, Matthias Klose <doko at ubuntu dot com>, GCJ-patches <java-patches at gcc dot gnu dot org>
- Date: Tue, 07 Oct 2008 08:30:51 +0100
- Subject: Re: [classpath-0.98 merge branch] update and status
- References: <48CD6C5B.70201@ubuntu.com> <48CE58F9.1070006@redhat.com> <48D92CA5.7080504@redhat.com> <20080925034746.GA25897@rivendell.middle-earth.co.uk> <48DB0C63.4060402@avtrex.com> <20080925205218.GD27651@rivendell.middle-earth.co.uk> <48E9DAC3.7060101@redhat.com> <17c6771e0810061651x7db0125bj2b987ce963db53ca@mail.gmail.com>
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.