FWIW, in Kaffe we use macros KMALLOC/KCALLOC/KFREE.
We used to redefine malloc/calloc/free, but that was so error-prone
we dropped it.
As an aside,
the malloc side is actually the easier part of the problem.
The harder part is protecting non-reentrant libc functions
in non-native thread implementations, for which JNI doesn't give
you any direction either.
- Godmar
>
> Artur Biesiadowski wrote:
> >
> > After browsing some classpath native code it seems that malloc is used
> > for allocating native memory. I'm not sure how portable it is between
> > various VMs.
> > I'm afraid that in some cases it can just crash vm which manages brk by
> > itself. Maybe some level of indirection can be used (memory interface by
> > pointers, or just #defines).
>
> There is no well-defined, published way to allocate memory from within
> native code. If you are writing a JIT compiler for Sun's VM, part of the
> vector of support functions it gives you are the VM's memory allocation
> functions (safe for use within your JIT) but this interface is specific
> to Sun's JVM.
>
> Probably the best solution would be to have a classpath_malloc and a
> classpath_free that are implemented in terms of JNI functions to
> allocate arrays of bytes, if portability is desired. There are
> potentially some efficiency concerns with this though as the obvious
> implementation winds up locking down blocks of memory that the GC would
> probably rather move.
>
> alex
>
