Now I am not sure if the issue is rooted exactly in this but its the only difference I can think of. Basically, I have a class that has this object in it:
private ExecutorService executor = Executors.newSingleThreadExecutor();
Now when I submit a particular task to it (in this case its a javaFX thing for converting a Frame from the ffmpeg java wrapper to an image so I can display it via ImageView) it takes up absolutely insane memory. About 8.5 gigabyes to be exact and It would likely be more if the allocations didn't happen on the stack (also eventually resulting in the program running out of memory). The exact same process I tried running on the main thread and it uses up practically no resouces. Why is this happening?
#Java same process using insane resources when ran on a separate thread.
53 messages · Page 1 of 1 (latest)
⌛ This post has been reserved for your question.
Hey @narrow briar! Please use
/closeor theClose Postbutton above when you're finished. Please remember to follow the help guidelines. This post will be automatically closed after 300 minutes of inactivity.
TIP: Narrow down your issue to simple and precise questions to maximize the chance that others will reply in here.
Does ffmpeg require that much memory or your Java application?
Can you show your code?
the code is a bit extensive
and no it doesn't
basically the only issue comes from this
here is the definition of the executor
so what happens when the executor hits that line converter.convert is basically an absolute insane spike in memory usage
as I said about 8 gigabytes
I followed where this was going via the debugger and it brought me to this for loop
and this is where shit really hits the fan
for every single one of these .put calls the memory the program uses rises about 3 mb
I tried the same exact thing only difference is I did the conversion directly from main and it barely dented a megabyte throughout the whole ordeal
- didn't read the full question before. ffmpeg doesn't require that much memory, the convert function of JavaFXFrameConverter does.
final JavaFXFrameConverter converter = new JavaFXFrameConverter();
sr for late reply I was showering
ah ok
oh wait
no my bad
its actually a class from the FFMpeg wrapper
I can't send the entire class though message too long
If you want to find out what's really using the memory, you could use a heap dump
well I used the intellij profiler and it also lead to this
and analyze it with a tool like Eclipse MAT
besides I was going line by line with the debugger
I know what's using memory I just don't know why
what exactly is using lots of memory?
And does your application actually crash due to being out of memory?
it crashes rarely I'm assuming due to the JVM pulling back on the memory allocations since all the allocations happen on the stack
I have had times where the program ran out of memory though
and the exact thing that's using a lot of memory is this method:
public <T extends Buffer> void getPixels(int x, int y, int w, int h, WritablePixelFormat<T> pixelformat, T buffer, int scanlineStride) {
int fss = this.frame.imageStride;
if (this.frame.imageChannels != 3) {
throw new UnsupportedOperationException("We only support frames with imageChannels = 3 (BGR)");
} else if (!(buffer instanceof ByteBuffer)) {
throw new UnsupportedOperationException("We only support bytebuffers at the moment");
} else {
ByteBuffer bb = (ByteBuffer)buffer;
ByteBuffer b = (ByteBuffer)this.frame.image[0];
for(int i = y; i < y + h; ++i) {
for(int j = x; j < x + w; ++j) {
int base = 3 * j;
bb.put(b.get(fss * i + base));
bb.put(b.get(fss * i + base + 1));
bb.put(b.get(fss * i + base + 2));
bb.put((byte)-1);
}
}
}
}
if the allocations happen on the stack, it would crash early
and even more specifically its those 2 for loops
well they don't happen on the heap, at least the profiler says so
Did you write the code?
well yeah ByteBuffer allocates off-heap memory
I meant the getPixels method
Is that part of the library?