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...