#ByteBuffer leak

53 messages · Page 1 of 1 (latest)

ocean spade
#

So i read that ByteBuffer allow you to allocate outside jvm, but can it memory leak?

eager sandalBOT
#

<@&987246399047479336> please have a look, thanks.

#

Here is an AI assisted attempt to answer your question 🤖. Maybe it helps! In any case, a human is on the way 👍. To continue talking to the AI, you can use </chatgpt:1108714622413963314>.

opal moss
#

idk if we can call it leak. they stand on top of threadlocal variables, that store the largest buffer allocated on the thread. that buffer remains there until the thread dies if you continue using that region of memory, even with much less data and operations on it, so then you have that extra allocated memory that looks like a leak.

#

at some point, the jvm can still decide to collect that bytebuffer!

#

it's not leaked in the sense that the gc forgets about it and if we do not manage it ourselves it remains there permanently.

final haven
ocean spade
#

Uh huh

#

Tho

#

Can java leak memory that is?

final haven
#

sure

#

like a "leak" is relative

#

something can be managed by the GC and just never collectable

opal moss
#

^^^

final haven
#

or it can be not managedby the GC and never manually collected

#

both are "leaks"

#

really a "leak" is when you use too much memory or memory usage keeps growing in a way it doesn't need to for your program to run

# 
static final ArrayList<Object> list = new ArrayList<>();

while (true) {
    list.add(new Object());
}
#

like, is this a memory leak?

#

certainly the program does nothing but consume more and more memory the longer it runs

ocean spade
#

Looks like it's cleaned by gc

final haven
#

nope, because the list is always referenced

ocean spade
#

O

final haven
#

the fact that a GC is involved just changes the timing and conditions by which something will be collected

#

you can still make things uncollectable

ocean spade
#

So if it can't collect to clean it up, it just leaks?

final haven
#

if it can't collect it doesn't collect

ocean spade
#

If it's unreachable then?

final haven
#

if that is unintentional, you call it a "leak"

final haven
# 
static ArrayList<Object> list = new ArrayList<>();

int x = 10000;
while (x > 0) {
    list.add(new Object());
    x--;
}

list = new ArrayList<>();
#

then the GC would eventually get around to cleaning up that memory

#

key word: eventually

ocean spade
#

oh I see it

final haven
#

and also maybe you still consider it a leak because you used more than you intended

ocean spade
#

Would that cause jvm to die if it's larger than the direct memory max?

final haven
#

usually not

opal moss
#

well, yeah.

final haven
#

the JVM will crash, but usually in an ordered fashion

#

there is an OutOfMemory error

opal moss
#

out of memory errors still exist. i havent seen one tho. but i think the gc gets more aggressive in terminal phase, if i aint wrong

#

i dont know in these cases what it would try

final haven
#

and hypothetically you can recover from it, but its hard to be sure and usually its best to let it all die

#

basically say you gave the JVM 10 GB to work with

#

it wont collect anything until it has to

#

so you will "run out of memory" and then the VM could just decide to clean up some of its trash to deal with that

#

sometimes there isnt enough that is trash, but its not super straight forward

ocean spade
#

Okie

#

Thx for the clarification

cyan charm
ocean spade
#

But I was confused how deallocation works

#

Is why I'm here

#

Bc ig those peoples explain it well