On 9/6/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:

Weldon,
The replacement of the 'new' opcode call with another call is relatively
easy task.

To send a working patch I need the following information:
1) Which Java method to call? Is it an instance method or a static?


Its an instance method.  Ideally you can use the same approach as the one
used when adding write barriers to Jitrino.JET.  Specifically
PlanLocal.javain Jira Harmony-816.  The API is:

public Address alloc(int bytes, int align, int offset, int allocator, int
site);

The only parameter I care about at this time is bytes.  This must  be
accurate.  I will ignore the rest of the parameters.  In other words, to
allocate a 52 byte object, the call site should look like:

alloc( 52, 0, 0, 0, 0);

Make sure the JIT loads the vtable ptr (and array length if required).

2) How to test the implementation? I can get and deploy all of your changes
or just to call some stub methods in a specialized testcase before sending
the result to you.



It would be best to test with a stub that is similar to what's in
Harmony-816.  It would also be great if the object allocator can chosen by
pattern matching on the method name.  A similar facility already exists for
the write barrier -- it might be a simple cut/paste.

The above will work fine during the single thread stage of this project.
Once we decide to turn on multiple Java threads, we will need to stuff a
thread specific MMTk object in DRLVM's thread block.  Then during execution
of JITed code, use vmmagic to load fs:14+offset_of_the_alloc_object into,
for example, EBX.  Do a "mov eax, [ebx]" to get the vtable pointer into
eax.  And finally, "call [eax + offset_of_the_alloc_method].

Let me know if you have further questions.



?


On 9/6/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
>
> A question for Jitrino.JET developers.  How hard would it be to modify
the
> existing Jitrino.JET code  so that the "new" opcode calls MMTk alloc()?
>
> Thanks
> --
> Weldon Washburn
> Intel Middleware Products Division
>
>


--
Mikhail Fursov




--
Weldon Washburn
Intel Middleware Products Division

Reply via email to