This is the mail archive of the java@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: _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


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