class initialization check overhead

[shudo@computer.org]

From: Jeff Sturm <jsturm@one-point.com>

> Just this week I tried an experiment on class initialization.  I modified
> the frontend to call an alternate initialization function, which alters
> its caller on i686:
>
> void
> _Jv_InitCompiledClass (jclass klass)
> {
>   _Jv_InitClass (klass);
>
>   unsigned char *ra = (unsigned char *) __builtin_return_address (0);
>
>   mprotect ((void *)(((unsigned long)ra) & ~4095),
>     4096, PROT_READ | PROT_WRITE | PROT_EXEC);
>   ra[-5] = 0x90;
>   ra[-4] = 0x90;
>   ra[-3] = 0x90;
>   ra[-2] = 0x90;
>   ra[-1] = 0x90;
> }
>
> This writes NOP instructions over the original call.  It did not prove
> enormously helpful.  The real problem must be the memory and register
> clobbers associated with a call, disrupting the instruction pipeline:

There may be other problems including atomicity of the code patching.
If there are threads just fetching around the code being patched,
such threads can read inconsistent code just being modified.
AFAIK, IBM JDK, Intel ORP and shuJIT take care of the consistency.
Rewriting 1 byte is safe, but we have to give care to 2 byte
rewriting, for example, by using XCHG instruction instead of MOV.

  Kazuyuki Shudo	shudo@computer.org	http://www.shudo.net/