thank you, it would be of great help if you could explain the following... > the functionality of the EmitCore routine in the file > jitinterfacex86.cpp > is clear, but i am not able to decipher the following.. > After one checks whether alloc request can be satisfied EDX contains the > updated heap address (old address + allocation size). How does the > control > flow, pass on this updated address to the caller. the series of emit > calls > puts the code generated into a memory buffer as i understand. After that > what follows isnt clear.
regards archana On Wed, 18 Jun 2003, Jan Kotas wrote: > The logic to determine which allocator to use for the given object is in > CEEInfo::getNewHelper. It picks the fastest possible allocator for the > given type of object. > > The allocator generated by EmitCore is really fast, but it only works > for the simple objects (no finalizer, etc.) > > -Jan > > 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 Archana > Sent: Wednesday, June 18, 2003 8:36 AM > To: [EMAIL PROTECTED] > Subject: [DOTNET-ROTOR] Allocation in vm/i386/jitinterfacex86.cpp > > Hi, > the functionality of the EmitCore routine in the file > jitinterfacex86.cpp > is clear, but i am not able to decipher the following.. > After one checks whether alloc request can be satisfied EDX contains the > updated heap address (old address + allocation size). How does the > control > flow, pass on this updated address to the caller. the series of emit > calls > puts the code generated into a memory buffer as i understand. After that > what follows isnt clear. > Also am i right in assuming that the allocator in EmitCore doesnt > consider registering finalizable objects etc.. since its just a > bare-bones > allocator > can someone pls help > > thanks & regards > archana >
