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 16:42:18 GMT
Regis wrote:
> Thanks for your patience, that's very clear.

any time

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

Sure, thanks!


> 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

View raw message