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


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.


 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.


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. 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;

Regards

Bryce.


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