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: Illegal Package-Private Accesses in 3.4


Bryce McKinlay writes:
 > On Tuesday, Aug 12, 2003, at 00:16 Pacific/Auckland, Andrew Haley wrote:
 > 
 > >>> No, that's not right.  There are some severe problems with using
 > >>> byte[] instead of RawData.  In particular, the previous equivalent of
 > >>> this code broke because byte[] and pointer references have differing
 > >>> alignments.
 > >>
 > >> Doh. I presume we've tried to go down the path of giving the data 
 > >> field
 > >> of all array types pointer alignment?
 > >
 > > I thought of it, and then dismissed the idea fairly quickly.  It's
 > > wasteful and unnecessary apart from these weird corner cases.
 > 
 > One other case where is might be useful is in java.nio where you can 
 > have ByteBuffer with a bunch of methods like putInt() that insert a 
 > native-endian int. If we (eventually) want to implement this 
 > efficiently , we might need to increase alignment of arrays.

No, this would surely be the wrong thing to do.  It's better to tell
the compiler that this is an unaligned pointer than add another word
to every array.

Also, I have a philosophical objection to aligning avery array.  It's
surely better, if you need full alignment, to solve the problem by
actually telling the compiler what you are doing rather than relying
on arrays to be maximally aligned.

Finally, maximal alignemnt would cause additional space to be
allocated on x86, where this kind of trickery isn't required at all.

 > >>>  I suspect that the Right Thing here would be to create an
 > >>> array of RawData instead of using _Jv_Malloc.
 > >>
 > >> Either that or JvAllocBytes, and introducing another RawData type 
 > >> which
 > >> doesn't prevent the GC from marking it.
 > >
 > > Well, how exactly could you do that?  RawData isn't necessarily a
 > > pointer to memory that is accessible to the gc.
 > 
 > Perhaps, but the GC doesn't care if it isn't a valid pointer. In all 
 > cases I know of in libgcj (except java.lang.ref), RawData is used to 
 > store a pointer to non-Java data that is associated with a Java object. 
 > The trouble is that in many cases we really want to GC allocate this 
 > non-Java data, but because of the way RawData works  people have been 
 > using Malloc instead, which is ugly and opens up the risk of leaks.

Certainly, and I can see where that might be useful.

 > >> Maybe RawData should actually be marked, and we could have a
 > >> separate RawDataUnmarked for the cases where thats useful.
 > >
 > > Umm.  Just using an array of RawData is surely the cleanest solution.
 > 
 > In this case it probably is.

Ah, okay.  We were talking at cross purposes, I think.

 > But there are other places where a "GC-able RawData" is needed - eg
 > java.lang.Thread:
 > 
 >    // Our native data - points to an instance of struct natThread.
 >    private Object data;

Hmm.  Is there any reason you believe an array of RawData isn't
suitable for this job?  (Either that or Per's byte array + alignment
offset, but that seems a little bit kludgey.)

Andrew.


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