I had a problem with e-mail client so my previous mail is incomplete. Here comes the rest.
2009/8/14 Vegard Nossum <vegard.nos...@gmail.com>: > I don't get this part either. Why would we even try to call > fixup_static() with patching sites that are not compiled yet? And if > we do, how can we make sure that they ARE compiled afterwards? We attach static fixup sites to the class during instruction selection. After that and before we finish code emission another thread might be executing some method which also contains static fixup sites of the same class and will triggers class initialization. During that, list of all static fixup sites is browsed and sites are patched. We can not patch sites which come from the method which is not yet compiled, because site address is not yet available (code is not emitted). My patch fixes this issue by skipping patching of those sites which are not yet ready to be patched. When method which contains sites that were not patched will be executed, then fixup_static_at() will be called again, and will call fixup_static() again, and those sites will finally be patched. Currently we synchronize on cu->mutex to check if method is compiled. I think we should synchronize on fixup site's mutex (to be introduced), because we'll have smaller delays then. >(I think) this function is only supposed to be called once per class, > when the class is initialized... It will be called whenever static_guard_page is accessed, right ? > Hm, I have a feeling that our static > handling is horribly broken anyway, and I think we should try to fix > that before adding more cludges to it. Can you specify what is exactly wrong with that ? > > (For example, jit_magic_trampoline locking is screaming for help and > the locking in fixup_static_at is a bit confused (we should never > reach the end of the function -- better insert a die() there or > something), yeah, fixup_static_at() might need some cleanup. > in any case, what ARE our locking rules wrt nesting of > vmc->mutex and compilation_unit->mutex...) We must acquire cu mutex first, then vmc mutex. It can't be other way because during compilation we cu is locked first. -- Tomek Grabiec ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Jatovm-devel mailing list Jatovm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jatovm-devel
