RE: _Jv_InitPrimClass?

["Boehm, Hans" <hans_boehm at hp dot com>]

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
>