Native files like Deflater.c and Inflater.c call calloc() and free() directly.
If calloc() is different from sysCalloc() used by the VM, then there needs
to be a way for native code to call the same version of sysCalloc() that the
VM uses in a portable way. I heard somewhere that calling sys_api functions
from native code is a no-no. If so, then I think access to the sys* functions
should be added to the JNU interface. If calling sys* functions from native
code is OK, then I think zip code should call sysCalloc, sysFree, and sysRead
instead of calling calloc/free/read directly.
dean.long@Eng 1998-04-20
I've changed the synopsis so that it talks about a general "embedding" API.
It would be nice to have an interface to I/O and memory calls that native
code can call. The VM may want to have native code call nativeMalloc,
which is different from sysMalloc, both of which could be built on top of
malloc(). So ideally a general interface would be better than just giving
access to sys API functions, because it could be useful to have a different
implementation for sysMalloc and nativeMalloc, for example. Also, if the
native embedding interface includes things like nativeRead and nativeWrite
and other I/O calls, then green threads wouldn't have to jump through hoops
to make read and write safe.
dean.long@Eng 1998-04-20
If calloc() is different from sysCalloc() used by the VM, then there needs
to be a way for native code to call the same version of sysCalloc() that the
VM uses in a portable way. I heard somewhere that calling sys_api functions
from native code is a no-no. If so, then I think access to the sys* functions
should be added to the JNU interface. If calling sys* functions from native
code is OK, then I think zip code should call sysCalloc, sysFree, and sysRead
instead of calling calloc/free/read directly.
dean.long@Eng 1998-04-20
I've changed the synopsis so that it talks about a general "embedding" API.
It would be nice to have an interface to I/O and memory calls that native
code can call. The VM may want to have native code call nativeMalloc,
which is different from sysMalloc, both of which could be built on top of
malloc(). So ideally a general interface would be better than just giving
access to sys API functions, because it could be useful to have a different
implementation for sysMalloc and nativeMalloc, for example. Also, if the
native embedding interface includes things like nativeRead and nativeWrite
and other I/O calls, then green threads wouldn't have to jump through hoops
to make read and write safe.
dean.long@Eng 1998-04-20
- duplicates
-
JDK-4071525 (porting) malloc/free used instead of sysMalloc/sysFree
-
- Closed
-