IP Library Granted Patent US 9,213,638
Granted Patent B1
US 9,213,638 · App. 14/667,380 · Granted Dec 15, 2015

Runtime memory management using multiple memory managers

Inventors: Rodrigo Vitezlav Martucci Kumpera (Boston, MA); Rolf Bjarne Kvinge (Madrid, ES); Aaron Dean Bockover (Raleigh, NC); Christopher Ryan Hamons (Austin, TX); Sebastien Pouliot (Quebec, CA); Miguel de Icaza (Boston, MA)
Assignee: Xamarin Inc.
G06F12/0261G06F12/0269G06F2212/251
View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 9,213,638
App. No.
14/667,380
Granted
Dec 15, 2015
Kind
B1
Abstract

Embodiments are directed towards managing memory for an application be executing in a managed runtime environment. Managed peer objects may be generated to correspond to native objects executing in a native runtime environment such that memory may be allocated for managed peer objects. Garbage collection handles may be generated and associated with the managed peer objects. If the managed application executes instructions that interact with the managed peer objects and the native runtime environment each garbage collection handle associated with the managed peer objects may be modified based on a type of an interaction. The garbage collection handlers may be garbage collection roots for a garbage collector that may be included in the managed runtime memory manager. If a garbage collection event occurs, memory for the managed peer objects may be deallocated based in part on its correspondent garbage collection handle.

Claims (78)

1. A method for managing memory for an application using a computer, wherein the computer performs actions, including:

executing a managed application in a managed runtime environment;

generating one or more managed peer objects that correspond to one or more native objects that are executing in a native runtime environment, wherein memory is allocated for the one or more managed peer objects;

generating one or more garbage collection handles, wherein each garbage collection handle is associated with one of the one or more managed peer objects; and

when the managed application executes one or more instructions that interact with the one or more managed peer objects and the native runtime environment, performing further actions, including:

modifying each garbage collection handle associated with the one or more managed peer objects based on a type of an interaction;

registering the one or more managed peer objects with a managed runtime memory manager; and

when a garbage collection event occurs, deallocating memory for the one or more managed peer objects based in part on its correspondent garbage collection handle.

2. The method of claim 1 , wherein when a garbage collection event occurs, performing further actions, including:

determining a native runtime reference count value for each registered managed peer object; and

modifying the garbage collection handle for each registered managed peer object based on its correspondent native runtime reference count value.

3. The method of claim 1 , further comprising, when a native runtime reference count value that corresponds to a managed peer object is less than two, modifying a correspondent managed peer object's garbage collection handle to become a weak reference garbage collection handle.

4. The method of claim 1 , further comprising, when a native runtime reference count value that corresponds to a managed peer object is greater than one, modifying a correspondent managed peer object's garbage collection handle to become a strong reference garbage collection handle.

5. The method of claim 1 , further comprising, when the type of interaction is an assignment of one of the one or more managed peer objects to a weak peer field of another of the one or more managed peer objects, modifying each garbage collection handle that is correspondent the other of the one or more managed peer objects to become a strong reference garbage collection handle.

6. The method of claim 1 , wherein deallocating memory for the one or more managed peer objects, further comprises, retaining the memory for the one or more managed peer objects that are associated with a strong reference garbage collector handle.

7. The method of claim 1 , wherein the memory allocated for the one or more managed peer objects is managed by a memory manager in the managed runtime environment that is separate from another memory manager that manages memory for the one or more native objects executing in the native runtime environment.

8. The method of claim 1 , wherein the one or more garbage collection handles are garbage collection roots for a garbage collector that is included in the managed runtime memory manager.

9. A system for managing memory for an application, comprising:

a computer, including:

a transceiver that communicates over the network;

a memory that stores at least instructions; and

a processor device that is executes instructions that enable actions, including:

executing a managed application in a managed runtime environment;

generating one or more managed peer objects that correspond to one or more native objects that are executing in a native runtime environment, wherein memory is allocated for the one or more managed peer objects;

generating one or more garbage collection handles, wherein each garbage collection handle is associated with one of the one or more managed peer objects; and

when the managed application executes one or more instructions that interact with the one or more managed peer objects and the native runtime environment, performing further actions, including:

modifying each garbage collection handle associated with the one or more managed peer objects based on a type of an interaction;

registering the one or more managed peer objects with a managed runtime memory manager; and

when a garbage collection event occurs, deallocating memory for the one or more managed peer objects based in part on its correspondent garbage collection handle; and

a development computer, including:

a transceiver that communicates over the network;

a memory that stores at least instructions; and

a processor device that is executes instructions that enable actions, including:

compiling a machine code version of the application.

10. The system of claim 9 , wherein when a garbage collection event occurs, performing further actions, including:

determining a native runtime reference count value for each registered managed peer object; and

modifying the garbage collection handle for each registered managed peer object based on its correspondent native runtime reference count value.

11. The system of claim 9 , further comprising, when a native runtime reference count value that corresponds to a managed peer object is less than two, modifying a correspondent managed peer object's garbage collection handle to become a weak reference garbage collection handle.

12. The system of claim 9 , further comprising, when a native runtime reference count value that corresponds to a managed peer object is greater than one, modifying a correspondent managed peer object's garbage collection handle to become a strong reference garbage collection handle.

13. The system of claim 9 , further comprising, when the type of interaction is an assignment of one of the one or more managed peer objects to a weak peer field of another of the one or more managed peer objects, modifying each garbage collection handle that is correspondent the other of the one or more managed peer objects to become a strong reference garbage collection handle.

14. The system of claim 9 , wherein deallocating memory for the one or more managed peer objects, further comprises, retaining the memory for the one or more managed peer objects that are associated with a strong reference garbage collector handle.

15. The system of claim 9 , wherein the memory allocated for the one or more managed peer objects is managed by a memory manager in the managed runtime environment that is separate from another memory manager that manages memory for the one or more native objects executing in the native runtime environment.

16. The system of claim 9 , wherein the one or more garbage collection handles are garbage collection roots for a garbage collector that is included in the managed runtime memory manager.

17. A computer for managing memory for an application, comprising:

a transceiver that communicates over the network;

a memory that stores at least instructions; and

a processor device that executes instructions that enable actions, including:

executing a managed application in a managed runtime environment;

generating one or more managed peer objects that correspond to one or more native objects that are executing in a native runtime environment, wherein memory is allocated for the one or more managed peer objects;

generating one or more garbage collection handles, wherein each garbage collection handle is associated with one of the one or more managed peer objects; and

when the managed application executes one or more instructions that interact with the one or more managed peer objects and the native runtime environment, performing further actions, including:

modifying each garbage collection handle associated with the one or more managed peer objects based on a type of an interaction;

registering the one or more managed peer objects with a managed runtime memory manager; and

when a garbage collection event occurs, deallocating memory for the one or more managed peer objects based in part on its correspondent garbage collection handle.

18. The computer of claim 17 , wherein when a garbage collection event occurs, performing further actions, including:

determining a native runtime reference count value for each registered managed peer object; and

modifying the garbage collection handle for each registered managed peer object based on its correspondent native runtime reference count value.

19. The computer of claim 17 , further comprising, when a native runtime reference count value that corresponds to a managed peer object is less than two, modifying a correspondent managed peer object's garbage collection handle to become a weak reference garbage collection handle.

20. The computer of claim 17 , further comprising, when a native runtime reference count value that corresponds to a managed peer object is greater than one, modifying a correspondent managed peer object's garbage collection handle to become a strong reference garbage collection handle.

21. The computer of claim 17 , further comprising, when the type of interaction is an assignment of one of the one or more managed peer objects to a weak peer field of another of the one or more managed peer objects, modifying each garbage collection handle that is correspondent the other of the one or more managed peer objects to become a strong reference garbage collection handle.

22. The computer of claim 17 , wherein deallocating memory for the one or more managed peer objects, further comprises, retaining the memory for the one or more managed peer objects that are associated with a strong reference garbage collector handle.

23. The computer of claim 17 , wherein the memory allocated for the one or more managed peer objects is managed by a memory manager in the managed runtime environment that is separate from another memory manager that manages memory for the one or more native objects executing in the native runtime environment.

24. A processor readable non-transitory storage media that includes instructions for managing memory for an application, wherein a computer that executes at least a portion of the instructions is enabled to perform actions, comprising:

executing a managed application in a managed runtime environment;

generating one or more managed peer objects that correspond to one or more native objects that are executing in a native runtime environment, wherein memory is allocated for the one or more managed peer objects;

generating one or more garbage collection handles, wherein each garbage collection handle is associated with one of the one or more managed peer objects; and

when the managed application executes one or more instructions that interact with the one or more managed peer objects and the native runtime environment, performing further actions, including:

modifying each garbage collection handle associated with the one or more managed peer objects based on a type of an interaction;

registering the one or more managed peer objects with a managed runtime memory manager; and

when a garbage collection event occurs, deallocating memory for the one or more managed peer objects based in part on its correspondent garbage collection handle.

25. The media of claim 24 , wherein when a garbage collection event occurs, performing further actions, including:

determining a native runtime reference count value for each registered managed peer object; and

modifying the garbage collection handle for each registered managed peer object based on its correspondent native runtime reference count value.

26. The media of claim 24 , further comprising, when a native runtime reference count value that corresponds to a managed peer object is less than two, modifying a correspondent managed peer object's garbage collection handle to become a weak reference garbage collection handle.

27. The media of claim 24 , further comprising, when a native runtime reference count value that corresponds to a managed peer object is greater than one, modifying a correspondent managed peer object's garbage collection handle to become a strong reference garbage collection handle.

28. The media of claim 24 , further comprising, when the type of interaction is an assignment of one of the one or more managed peer objects to a weak peer field of another of the one or more managed peer objects, modifying each garbage collection handle that is correspondent the other of the one or more managed peer objects to become a strong reference garbage collection handle.

29. The media of claim 24 , wherein deallocating memory for the one or more managed peer objects, further comprises, retaining the memory for the one or more managed peer objects that are associated with a strong reference garbage collector handle.

30. The media of claim 24 , wherein the memory allocated for the one or more managed peer objects is managed by a memory manager in the managed runtime environment that is separate from another memory manager that manages memory for the one or more native objects executing in the native runtime environment.

Assignments (2)
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Jul 1, 2020
From: XAMARIN INC.
To: MICROSOFT TECHNOLOGY LICENSING, LLC
Reel/Frame 053103/0633 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Mar 24, 2015
From: KUMPERA, RODRIGO VITEZLAV MARTUCCI; KVINGE, ROLF BJARNE; BOCKOVER, AARON DEAN; HAMONS, CHRISTOPHER RYAN; POULIOT, SEBASTIEN; DE ICAZA, MIGUEL
To: XAMARIN INC.
Reel/Frame 035245/0513 →