_Jv_InitPrimClass?

Mon Mar 4 11:37:00 GMT 2002

I would be inclined to define a flag, say MISALIGNED_STATICS on platforms
that have alignment issues, unconditionally drop the three low order bits on
those, but replace the 
 assert(!(addr & FLAGS));
with an earlier assertion just before the truncation.
Something like this:
 obj_addr_t addr = (obj_addr_t)obj;
# ifdef MISALIGNED_STATICS
	// Addr is either 8-byte aligned or outside the heap.
	// In the latter case, distinct addresses must be >= 8 bytes apart.
 assert(!(addr & FLAGS) || GC_base(addr) == 0);
 addr &= ~FLAGS;
# else
	assert(!(addr & FLAGS));
# endif
That's a less stringent sanity test than the one for just PrimClasses, but
it seems a bit cleaner. It adds another direct call to the collector, but
we have a couple of those here already. Performance should be acceptable,
even with assertions enabled.
I would expect that most alignment problems will be caught either by this
test, or by running the same test on Linux with full alignment checking.
Does this sound tolerable?
Hans
> -----Original Message-----
> From: Adam Megacz [mailto:gcj@lists.megacz.com]
> Sent: Monday, March 04, 2002 10:28 AM
> To: java@gcc.gnu.org
> Subject: Re: _Jv_InitPrimClass?
>>>> "Boehm, Hans" <hans_boehm@hp.com> writes:
> > I think there is a fairly easy workaround, provided we know 
> that distinct
> > objects used for locking are at least 8 bytes apart.
>> Yes, this was my hack (which is why I can confidently say "hash
> locking works on Win32 modulo the PrimClasses") -- I just added a line
> to clear the bottom three bits of the object address on entry to all
> the hash-locking functions.
>> Since we know that all objects are always at least 8 bytes apart, this
> won't cause problems. However, I figured it was too much of a hack, or
> too dangerous to commit. If you all are okay with it, I'll submit a
> patch.
>> Perhaps a sanity check is in order to counterbalance the risk -- if
> any of the bottom three bits of the address are set, confirm that the
> object being locked is one of the primclasses; if it is not, abort
> with an error message. This would cause a slight slowdown when locking
> on one of the primclasses (due to the sanity check), though I doubt it
> happens often enough to make a big difference.
>>> > Of course, I haven't actually tried this ...
>> I have. It works.
>>> > makes it easier to detect any accidental alignment problems.
>> This is my biggest concern; what do you think about the sanity check?
>>> - a
>>> -- 
> "If I put copyrighted material into the 'chewy nougat center', I can
> claim the crunchy chocolate coating is an 'Access Control
> Mechanism'." --lynx_user_abroad
>> Why Windows NT/2k/XP is unreliable: www.zappadoodle.com
>