harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Regis <xu.re...@gmail.com>
Subject Re: [classlib][luni] the same OSMemory.h in windows and unix
Date Mon, 01 Dec 2008 15:56:57 GMT
Hi Tim,

Thanks for your patience, that's very clear.

BTW, I have attached a patch on JIRA. I just tested it on linux32 and 
windows32, it seems ok for me, anyone want to try/review it?

Tim Ellison wrote:
> 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