harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib][luni] the same OSMemory.h in windows and unix
Date Mon, 01 Dec 2008 11:11:35 GMT
Regis wrote:
> Tim Ellison wrote:
>> Regis wrote:
>>> Tony Wu wrote:
>>>> I think so. since we already have the OSMemoryWin32 and
>>>> OSMemoryLinux32.c for the different implementation.
>>> Thanks your reminder, I just noticed that :)
>>> So in my understanding, the platform dependent code should be placed in
>>> OSMemoryWin32/OSMemoryLinux32, others should be moved to "shared"
>>> directory, right?
>>
>> Yes, that is right.
>>
>> FYI
>> On 64-bit platforms we use the full range of jlong to hold the allocated
>> memory pointer, but on 32-bit platforms we only use half of it.
>> The extra cast ((void *) ((IDATA) address)) is to ensure that the
>> address value is first cast to an int the right width for a platform
>> pointer, or else the compiler will rightly complain about the truncated
>> value.
> Does it mean ((void *) ((IDATA) address)) has the same effect as
> ((void *))(address), the first cast just make compiler happy?

Yes.

An IDATA is defined as a '64-bit signed int' on 64 bit systems, and a
'32-bit signed int' on 32-bit systems.

Casting from a 64-bit jlong straight to a 32-bit void* pointer will
produce a compiler error on some Linux systems; however, if you go from
64-bit jlong to an IDATA that will cast it to a 32-bit int first, and
you can go from there to a 32-bit pointer with no troubles.  Obviously,
on 64-bit systems that first cast of jlong to IDATA is a no-op.

This is required because the _Java_ code for OS memory manipulation
always deals with jlong pointers, so that the Java code is portable
across different architectures.

Makes sense?
Tim


>> When you do the merge, take the double cast version.
>>
>> Regards,
>> Tim
>>
>>
> 

Mime
View raw message