search for: compressedoop

Displaying 6 results from an estimated 6 matches for "compressedoop".

Did you mean: compressedoops
2011 Mar 07
2
[LLVMdev] llvm.gcroot suggestion
...he address-space method. It seems much more elegant. The only thing that I think would be unusually difficult for the address-space method to handle would be alternative pointer representations, such as those used in the latest version of Hotspot (see http://wikis.sun.com/display/HotSpotInternals/CompressedOops). Essentially, a 64-bit pointer is packed into 32-bits by assuming 8-byte alignment and restricting the heap size to 32GB. I've seen similar object-reference bitfields used in game engines. In this case, there is no "pointer" to attach the address space to. (Yes, I know that Hots...
2011 Mar 07
0
[LLVMdev] llvm.gcroot suggestion
...but it would at least work.) > > The only thing that I think would be unusually difficult for the > address-space method to handle would be alternative pointer representations, > such as those used in the latest version of Hotspot (see > http://wikis.sun.com/display/HotSpotInternals/CompressedOops). > Essentially, a 64-bit pointer is packed into 32-bits by assuming 8-byte > alignment and restricting the heap size to 32GB. I've seen similar > object-reference bitfields used in game engines. In this case, there is no > "pointer" to attach the address space to. >...
2011 Mar 07
0
[LLVMdev] llvm.gcroot suggestion
On Mon, Mar 7, 2011 at 9:35 AM, Talin <viridia at gmail.com> wrote: > On Mon, Mar 7, 2011 at 4:08 AM, nicolas geoffray < > nicolas.geoffray at gmail.com> wrote: > >> Hi Talin, >> >> On Sat, Mar 5, 2011 at 6:42 PM, Talin <viridia at gmail.com> wrote: >>> >>> >>> So I've been thinking about your proposal, that of using a
2011 Mar 07
4
[LLVMdev] llvm.gcroot suggestion
...feature). > >> The only thing that I think would be unusually difficult for the >> address-space method to handle would be alternative pointer representations, >> such as those used in the latest version of Hotspot (see >> http://wikis.sun.com/display/HotSpotInternals/CompressedOops). >> Essentially, a 64-bit pointer is packed into 32-bits by assuming 8-byte >> alignment and restricting the heap size to 32GB. I've seen similar >> object-reference bitfields used in game engines. In this case, there is no >> "pointer" to attach the addres...
2011 Mar 07
2
[LLVMdev] llvm.gcroot suggestion
On Mon, Mar 7, 2011 at 4:08 AM, nicolas geoffray <nicolas.geoffray at gmail.com > wrote: > Hi Talin, > > On Sat, Mar 5, 2011 at 6:42 PM, Talin <viridia at gmail.com> wrote: >> >> >> So I've been thinking about your proposal, that of using a special address >> space to indicate garbage collection roots instead of intrinsics. > > > Great!
2011 Mar 08
0
[LLVMdev] llvm.gcroot suggestion
...t; >>> The only thing that I think would be unusually difficult for the >>> address-space method to handle would be alternative pointer representations, >>> such as those used in the latest version of Hotspot (see >>> http://wikis.sun.com/display/HotSpotInternals/CompressedOops). >>> Essentially, a 64-bit pointer is packed into 32-bits by assuming 8-byte >>> alignment and restricting the heap size to 32GB. I've seen similar >>> object-reference bitfields used in game engines. In this case, there is no >>> "pointer" to a...