You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Regis <xu...@gmail.com> on 2008/12/01 08:11:57 UTC
[classlib][luni] the same OSMemory.h in windows and unix
Hi,
I just found OSMemory.h has almost the same content in windows and unix,
the only differences are order of function definitions and comments. So
I think if they should be merged and moved to shared directory?
And I go through OSMemory.c quickly, found the most implementation are
also similar, looks like:
windows:
hymem_free_memory ((void *) address);
unix:
hymem_free_memory ((void *) ((IDATA) address));
I'm not clear why we need one more cast here, or is it possible to merge
this two implementations to one? If so, I'm volunteer to do this :)
Re: [classlib][luni] the same OSMemory.h in windows and unix
Posted by Tim Ellison <t....@gmail.com>.
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!
Regards,
Tim
> 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
>>>>
>>>>
>>
>
Re: [classlib][luni] the same OSMemory.h in windows and unix
Posted by Regis <xu...@gmail.com>.
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
>>>
>>>
>
Re: [classlib][luni] the same OSMemory.h in windows and unix
Posted by Tim Ellison <t....@gmail.com>.
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
>>
>>
>
Re: [classlib][luni] the same OSMemory.h in windows and unix
Posted by Regis <xu...@gmail.com>.
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?
>
> When you do the merge, take the double cast version.
>
> Regards,
> Tim
>
>
Re: [classlib][luni] the same OSMemory.h in windows and unix
Posted by Regis <xu...@gmail.com>.
Hi Tim,
Thanks for your informations, it's very helpful :)
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.
>
> When you do the merge, take the double cast version.
>
> Regards,
> Tim
>
>
Re: [classlib][luni] the same OSMemory.h in windows and unix
Posted by Tim Ellison <t....@gmail.com>.
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.
When you do the merge, take the double cast version.
Regards,
Tim
Re: [classlib][luni] the same OSMemory.h in windows and unix
Posted by Regis <xu...@gmail.com>.
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?
I have filed a JIRA [1] for this, and will create patch soon.
[1] https://issues.apache.org/jira/browse/HARMONY-6030
>
> On Mon, Dec 1, 2008 at 3:11 PM, Regis <xu...@gmail.com> wrote:
>> Hi,
>>
>> I just found OSMemory.h has almost the same content in windows and unix, the
>> only differences are order of function definitions and comments. So I think
>> if they should be merged and moved to shared directory?
>> And I go through OSMemory.c quickly, found the most implementation are also
>> similar, looks like:
>> windows:
>> hymem_free_memory ((void *) address);
>>
>> unix:
>> hymem_free_memory ((void *) ((IDATA) address));
>>
>> I'm not clear why we need one more cast here, or is it possible to merge
>> this two implementations to one? If so, I'm volunteer to do this :)
>>
>
>
>
Re: [classlib][luni] the same OSMemory.h in windows and unix
Posted by Tony Wu <wu...@gmail.com>.
I think so. since we already have the OSMemoryWin32 and
OSMemoryLinux32.c for the different implementation.
On Mon, Dec 1, 2008 at 3:11 PM, Regis <xu...@gmail.com> wrote:
> Hi,
>
> I just found OSMemory.h has almost the same content in windows and unix, the
> only differences are order of function definitions and comments. So I think
> if they should be merged and moved to shared directory?
> And I go through OSMemory.c quickly, found the most implementation are also
> similar, looks like:
> windows:
> hymem_free_memory ((void *) address);
>
> unix:
> hymem_free_memory ((void *) ((IDATA) address));
>
> I'm not clear why we need one more cast here, or is it possible to merge
> this two implementations to one? If so, I'm volunteer to do this :)
>
--
Tony Wu
China Software Development Lab, IBM