Re: memory allocation

[Brian Jones]

Etienne Gagnon <address@hidden> writes:

> Archie Cobbs wrote:
> > The only way I could think of would be e.g. allocating memory by creating
> > byte[] arrays instead of using malloc(). This seems awkward.
> 
> Allocating a byte array and then obtaining a direct pointer to its
> elements (or non-moveable copy) using GetByteArrayElements is
> effectively the cleanest approach to allocate memory ** through JNI
> **.  [Note that the native code must also call
> ReleaseByteArrayElements to "free" the array.]
> 
> Now, the only advantage I see to this approach is that it allows the
> JVM's garbage collector to free this memory on exit.  Yet, this can
> also be a problem if the native code needs to access this memory
> after calling DestroyVM.
> 
> This brings the following question:
> 
> What's wrong with using malloc/free in native code, in the first
> place?

I don't know, I believe I was referring to a post you made on the
subject some time back actually.

> Personally I think that there shouldn't be any problem for native
> code to directly call malloc & free.

Great.

> On the other hand, the GetByteArrayElements/ReleaseByteArrayElements
> pair should be used to store pointers to native data in Java
> objects.  One shouldn't use int/long fields as pointer size is
> inherently platform dependent (16,16,32,64,128 bits).

It looks like the native state code uses an int field to do exactly
this.  Probably something to fix.

Brian
-- 
Brian Jones <address@hidden>