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