You can assume that the objects are zeroed out. This is required to
assured that all object references are either NULL or valid. The method
table pointer will also be filled by the GC at allocation time. So the
object will look like the diagram below with the pointer returned
pointing at MT:

<0> MT <0> <0> <0> ......

Thanks,

Vladimir

P.S. My reply below wasn't quite correct but Jan caught it right in
time. We did end up using a part of the optimized code path on x86 but
we always use
JIT_NewFast on PowerPC.  

This posting is provided "AS IS" with no warranties, and confers no
rights.
-----Original Message-----
From: Discussion of the Rotor Shared Source CLI implementation
[mailto:[EMAIL PROTECTED] On Behalf Of Yuan Yu
Sent: Wednesday, August 06, 2003 1:45 PM
To: [EMAIL PROTECTED]
Subject: Re: [DOTNET-ROTOR] How does FJit::compileCEE_NEWOBJ work?

Thanks for the replies. I have a related question. For a new piece of
memory allocated by GC, can I always assume that its content is zero?

-Yuan

>Rotor always uses JIT_NewFast to allocate objects. There is a mechanism
>to allow for use of highly tuned per platforms allocators via use of
>getNewHelper(...), but it is not used in Rotor for portability reasons.
>
>Here is x86 dissasembly for the following IL:
>
>IL_0000:  newobj     instance void MainApp::.ctor()
>IL_0005:  stloc.0
>
>03457bb1 b8b844d700       mov     eax,0xd744b8   // MT for MainApp
>03457bb6 50               push    eax
>03457bb7 b83a4c9500       mov     eax,0x954c3a   // Address of
>JIT_NewFast
>03457bbc ffd0             call    eax
>03457bbe 83c404           add     esp,0x4
>
>03457bc1 8bf0             mov     esi,eax        // Save the pointer to
>the
>03457bc3 8bc8             mov     ecx,eax        // blank object in esi
>03457bc5 51               push    ecx
>03457bc6 b8fc44d700       mov     eax,0xd744fc
>03457bcb ff10             call    dword ptr [eax]// Call the
constructor
>03457bcd 83c404           add     esp,0x4
>03457bd0 8bc6             mov     eax,esi        // Get the object ref
>from
>03457bd2 be00000000       mov     esi,0x0        // esi and store it in
>a
>03457bd7 8945f0           mov     [ebp-0x10],eax // local
>
>(Note esi is set to NULL because it is in the root set for the GC)
>
>The code paths for allocating valuetypes and arrays are different. Let
>me know which one you are interested in.
>
>Thanks,
>
>Vladimir
>
>This posting is provided "AS IS" with no warranties, and confers no
>rights.
>
>-----Original Message-----
>From: Discussion of the Rotor Shared Source CLI implementation
>[mailto:[EMAIL PROTECTED] On Behalf Of Yuan Yu
>Sent: Friday, August 01, 2003 6:12 PM
>To: [EMAIL PROTECTED]
>Subject: [DOTNET-ROTOR] How does FJit::compileCEE_NEWOBJ work?
>
>I have been trying to understand how the newobj instruction is jitted.
>For
>a simple class like
>
>   class Foo { int x = 5; }
>
>and an instruction
>
>   newobj     instance void Foo
>
>Rotor calls FJit::compileCEE_NEWOBJ, and goes to the "allocate normal
>object" case where the first line is
>
>  helper_ftn = jitInfo->getHelperFtn(jitInfo->getNewHelper(targetClass,
>methodHandle));
>
>The value of jitInfo->getNewHelper(targetClass, methodHandle) appears
to
>be CORINFO_HELP_NEWSFAST, and, according to the table hlpFuncTable, it
>seems to map to JIT_NewFast. So, I thought the helper function
>helper_ftn
>must have been JIT_NewFast. However, it does not seem to be the case.
>So,
>what is the value of helper_ftn?
>
>Thanks,
>-Yuan

Reply via email to