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

Reply via email to