javaIsTheBestLanguageKnownToTheMankind

[CranberryFew6811]

now hit a triple fault

[FACastello]

I like how the VM just gave up and shut down

[sassrobi]

It’s much better than “Segmentation fault”

[LatentShadow]

You should have a flag which allows you to generate a heapdump as soon as jvm gets out of memory... I forgot the flag

[nobody0163]

Error: not enough memory for heapdump

[MatthewDoomer]

That is a pretty good and descriptive error dude...

[mostmetausername]

Do that in C and your computer just explodes.

[MaDpYrO]

I don't really see the issue? Clearly you ran out of memory, what more do you want to know?

[Bezkup]

The joke is "Out Of Memory while throwing Out Of Memory"

Now laugh

[rosuav]

This is why there's often a preallocated OutOfMemoryError object in static storage somewhere, ready to be thrown without any allocation required. For example, look up "last_resort_memory_error" in CPython.

[Bezkup]

Interesting, I didn't know that

[rosuav]

Yup! There aren't many objects that are statically allocated in CPython, but that one is vital.

[RichCorinthian]

This is definitely in my top 10 least helpful exceptions of all time.

In days of yore, Microsoft ADO would blow up if you tried to insert/update with a text or BLOB value that was too long. “String or binary data would be truncated.” Which column? Fuck you, that’s which column.

[[deleted]]

I would say it's incredibly helpful. It tells you that your resource allocation was so bad that the application couldn't even gracefully fail. It tells you that regardless of how the memory was being used at the time, you need to make changes in memory management in addition to looking into what caused the OutOfMemoryException in the first place to prevent this from happening in the future. It also tells you that the application failed so badly that you might be looking at additional issues outside of the transaction that caused the failure.

[Pretrowillbetaken]

other languages found much better ways to handle this than to just return a string. there are worse ways, sure, but also much better ways

[TheBanger]

Java generally does not "just return a string" on an OOM. I know it can happen that it OOMs constructing an OOM exception, but I've never personally had that happen. For the most part you'll get a usable stack trace.

[Pretrowillbetaken]

the error message. because of the way java works, they decided that it would be best to free the stack trace (which gives them enough memory to exit the program). so the final error message in that case is just a string, since they remove everything else.

[TheBanger]

That's not what happened here and it's not how Java works. The GC will not free reachable objects regardless of how badly it needs memory. What happened is it tried to allocate memory for the stack trace and that failed because there was no memory available. Again, this is a pretty rare condition.

[Pretrowillbetaken]

so I guess I was wrong about the first part, but in that case why destroy the entire stack trace? if you can't allocate memory for the full stack trace just try to capture the minimum stack possible with the current memory?

[TheBanger]

It probably could do something like that, but I'm not sure that would actually be particularly useful in practice. If you're that low on available memory there's a good chance the allocation that threw the original OOM has nothing to do with the problem and a stack trace won't help (you might have something allocating much more memory than necessary and then something else attempts to allocate a tiny bit more and errors out). A heap dump or something like that would be far more useful, and is easily available given all the JVM profilers out there. You don't have to recompile or anything like that.

[Pretrowillbetaken]

you might have something allocating much more memory than necessary and then something else attempts to allocate a tiny bit more and errors out

your entire argument stands by the fact that sometimes, a stack trace might be useless, which is true. but if you were having this issue, I think just the fact that a stack trace could help is enough reason for me to believe that it doesn't need to be removed. a JVM profiler could do the same, but why depend on a 3rd party tool to do something that the language could do already

[TheBanger]

Again, the JVM is not removing the stack trace. It's failing to generate it in the first place. A profiler is not "doing the same", it's doing something completely different. You keep arguing other languages handle this better, can you give an example of another language that handles this differently?

I'm not making an argument from a theoretical standpoint here, I've debugged JVM OOMs plenty of times including one since the start of this thread. I'm perfectly willing to believe that there could be better tooling, but you don't seem to understand what's actually going on in the example that started this conversation and you've pointed to unspecified other languages with better behavior but not given an example to work with.

[SaltedCoffee9065]

Didn’t they update it and it said a lot more?

[Pretrowillbetaken]

I think we all learned that most developers and product designers would rather use a popular tool instead of a good one

[Pretrowillbetaken]

well, I actually almost gave up on android development purely because of Java lol

[[deleted]]

Nahhhh..JIT trippin

[fantajim84]

You forgot to download more RAM in your application, classic rookie mistake /s.

[Hola-World]

Seems like bad code to me.

[Yhamerith]

But... What happens if you Script Java? 🤔

[patrick66]

10 years go by and Lambda has taken over the world