Illegal Package-Private Accesses in 3.4

[Bryce McKinlay]

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.