JNI memory allocation

Performance Tuning
#1

When you call native methods via JNI and those methods allocate memory (say loads a sound stream using OpenAL) do they expend the JVM’s memory heap, or the underlying OS memory heap?

#2

OS Heap. Only java objects (not even the memory blocks used by NativeByteBuffers) are on the Java heap as far as I know.

#3

[quote]OS Heap. Only java objects (not even the memory blocks used by NativeByteBuffers) are on the Java heap as far as I know.
[/quote]
That’s right. NativeByteBuffers are often used to allocate memory specifically because its outside of the JVMs own heap space.

God bless,
-Toby Reyelts

#4

Hmmm… this brings up an interesting security concern. Can an Applet allocate massive NativeByteBuffers and thus steal all the memory in a system - likely leading to a crash?
Things that make you go hmmmm…

#5

[quote]Hmmm… this brings up an interesting security concern. Can an Applet allocate massive NativeByteBuffers and thus steal all the memory in a system - likely leading to a crash?
Things that make you go hmmmm…
[/quote]
I’m not sure how that is any different than setting the max heap size parameter in your JNLP file to something huge and then eating up that memory.

God bless,
-Toby Reyelts

#6

I suppose, but Web Start seems to be less restricted in general. The user is more aware that they are launching a program. Applets just happen. I guess ultimately it isn’t that much different.

#7

[quote]Hmmm… this brings up an interesting security concern. Can an Applet allocate massive NativeByteBuffers and thus steal all the memory in a system -.
[/quote]
Nope, because only native (called through JNI) code can create a Native Byte Buffer.

And native code may only be called by trusted Java code.

If you could create arbitrary native byte buffers from the java side that would constitute a COMPLETE break of security as you could touch any memory in the system you wanted to.

#8

I think he’s referring to a perfectly easy DOS attack:


ArrayList a = new ArrayList(100000);
for (;;) {
a.add(ByteBuffer.allocateDirect(1000000000));
}

That’ll just chew into swapspace into milliseconds and grind the system to a halt, before finally running out of memory. You could even catch the OutOfMemoryError and then sit in an infinite busy loop writing bytes into the memory as well just to make sure it kept swapping like crazy.

Of course that’s no more sophisticated than:


for (;;) {
new Thread() { public void run() { for (;;); } }.start();
}

which will rapidly consume all the available OS resources if it doesn’t run out of thread stack memory.

There is possibly a requirement highlighted here that the JVM has a security mechanism in place to prevent such DOS attacks by limiting the availability of some resources by default.

Cas :slight_smile:

#9

[quote]Nope, because only native (called through JNI) code can create a Native Byte Buffer.
[/quote]
allocateDirect doesn’t work from an Applet?? Or does it just give you a non-direct buffer?

#10

Sorry I was thinking of Native Direct Byte buffers, wher you control the memory mapping.

I dopn’t know if allocateDirect works from applets or not, actually. Its also unclear whether a DirectByte Buffer is native memory or not on any given platform. (See the “Direct v. Non-Direct” buffers part of the docs.)

In any event allocation is up to the VM. Its free to deny you the allocation if it thinks doing so will harm the system.

#11