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
