_Jv_InitPrimClass?

[Boehm, Hans]

> From: Bryce McKinlay [mailto:bryce@waitaki.otago.ac.nz]
> Adam Megacz wrote:
> 
> >BTW, is there any way we could put the PrimClasses on the heap? 
> >
> 
> Not for now, it would require substantial changes to the front end.
> 
> >This is the only reason hash synchronization won't work on 
> Win32 (mingw
> >linker is broken and refuses to 8-byte-align static data), and AFAIK
> >these are the only non-heap-allocated Java objects in gcj.
> >
> 
> ... except for all the java.lang.Class objects which are statically 
> generated by the compiler. I had the same problem getting 
> things 8-byte 
> aligned on PowerPC linux, but I added an "__attribute__ 
> ((aligned))" to 
> the primclass declarations in prims.cc and it did the trick. See the 
> patch I recently posted, except it now occurs to me that I forgot to 
> include the prims.cc change in it.
> 
Unfortunately, this has turned into more of an issue than I anticipated.

I think there is a fairly easy workaround, provided we know that distinct
objects used for locking are at least 8 bytes apart.  All of the locking
primitives in natObject.cc take a jobject (either implicitly or as the
"this" parameter), and then immediately convert it to an obj_addr_t.  I
think the only thing that would break if you dropped the last 3 bits at
this point is that the call to GC_REGISTER_FINALIZER_NO_ORDER wouldn't
get a proper object address.  But if the only misaligned objects are
outside the heap, that wouldn't matter either.

Of course, I haven't actually tried this ...

Unfortunately, I think this needs to be done in a platform dependent way.
We still want to insist on the alignment in Linux, both because it gets us
a tiny amount of added performance and, more importantly, because it
makes it easier to detect any accidental alignment problems.

Hans