Hacker News Reader

Comment by cmrdporcupine | Hacker News Reader

One problem is that GC'd languages also tend to have programming practices that encourage the generation of garbage, while languages with manual stack/heap allocation make you think about it a bit more. The sheer number of String and other lightweight (but existent) instances in a running Java program is astounding, because the language simply doesn't encourage you to be parsimonious with creating them.

For most people's applications this is totally fine. But, yeah, you can end up with a scenario where GC pauses are just totally unacceptable, or where you need absolutely predictable behaviour and then you might resort to radical things like what you're describing here and it starts to feel like you've just chosen the wrong tool for the job.

I say this as a person who wrote an RTB ad server in Java, many moons ago... and never would again.

View on HN

> The sheer number of String and other lightweight (but existent) instances in a running Java program is astounding, because the language simply doesn't encourage you to be parsimonious with creating them.

I agree with this. Java promotes a profligate programming style where allocation (and reclamation) are considered free. (They aren't). This is baked into the JDK deeply. E.g. with standard APIs it is not even possible to parse an integer out of a string without allocating memory. Those are language and library design choices that have a huge confounding effect on trying to measure GC.

For example, I wrote the Avrora AVR emulator and sensor network simulator, which is one of the DaCapo benchmarks. It's a CPU emulator for very small devices and uses almost no standard JDK stuff in its core work. As such it allocates very little and has a pretty small heap. It often shows up weird (sometimes obnoxiously small or uninteresting) in papers that study memory management because it really isn't very Java-like in its behavior.

> with standard APIs it is not even possible to parse an integer out of a string without allocating memory

Not true anymore :)

https://docs.oracle.com/en/java/javase/17/docs/api/java.base...

Wonders never cease :)

I d simply take a noop GC in the most recent jvm (I cant yet in my conservative bank), and make people suffer through it in prod until everything is constrained correctly, but you're right, String are banned where I work, and what a pain it has to be to do everything via char buffer but it's taking a dev like maybe 10 minutes per "String" handling instead of 5 second during code writing (to massage the buffer all the way from the input signal to the output destination, be it a log file, a storage structure, a comparator or a map key), so it's a giganormous increase of dev time relatively, but in absolute time it's quite trivial over the last 20 years. Yeah we wasted time per feature on String handling but... like maybe a few hours per feature per dev and we generate billions out of the trading backend so...

Maybe Java had the wrong assumption and really should just have made C-string optional first class citizens or something.

One thing is sure though, our C++ colleagues in the algo team are so slow to deliver, so prone to crazy bugs, so wild and wizardy, so unable to onboard new joiners, they re getting replaced this year by... a brand new Java algo engine... So not sure what to think.

Initially Java has been created with totally different application scope in mind comparatively to what it is now. I know it may look like a mess but maybe they should've added new optimized string type in addition to already available.

As for C++ - I do just that. All my servers are C++ and while I will not claim "bug free" I do not really remember when was the last time I've had memory related bug (alloc / boundary / use after free / etc). Modern C++ along with sanitizers helps greatly in this department. All fixed bugs were logical.

I did my share of Java development big while ago and got sick of trying to make it performant enough. In order for me to achieve the goal I've spent way more time caring about memory / resource related issues in Java than I would do in "dangerous languages. Granted it was high performance servers. Doing different type of task in Java could've cost way less aggravation.

I know exactly what to think: salaries offered for your C++ colleagues are not competitive, so you are collecting competitors' dregs. It can be very hard to come back from that, maybe impossible.

In other shops, the notion of conducting trading in Java, GC'd or no, would get you laughed from the room. But Java coders certainly are cheaper.

The City in London is full of people with humour and deep pockets.

I m in Asia, we need the ability to validate 13 different exchange regulations and Java helps more than C++ as far as I can observe in team work, modularity, forcing some sort of okay common practice etc. The guys in the US have it easy with regard to logic so can throughput fast enough in Java to only switch fast clients to FPGA without the need for C++ in between.

The guys in London have nowhere near the volumes of APAC or the US. They can trade with excel if they want.

Might be, doesn't change the fact that plenty of business in finance have moved into GC based languages, reducing their use of C++ into niche use cases.

Just like using C or C++ hasn't taken away that some niche use cases still require coding in Assembly.

It isn't only Java, C#, F#, Haskell and OCaml are also tooling they reach for.

Well we do Java for the slow path and fpga for the fast path. C++ for the algo decisions, but even when we do java we jni everything that would be slower than C++. Nobody's laughing, everyone is just profiling and fitting constraints, so far Java worked, we ll switch if we must...

Problem with FPGA is that it s pointless to try to correct client mistakes or validate exchange regulation with it, so it's only for upstreams who have the whole chain clean, it's a slow transition.

See now this all sounds very interesting and exciting. I love both FPGA and C++.

Too bad it's finance :-)

I had a colleague who called it "automated stealing".

I think there is a time threshold above which it defensibly is not, and another below which you would have to agree, but I am not sure of the values.

There's no stealing if all parties consent. If you don't consent, convince others and vote better. Why blame finance when house representatives dont even understand they shouldnt insider trade, something even I, a "stealing automation engineer" would never even think of ?

For the record, I don't think of you as a stealing automation engineer. You perform a valued service for an appreciative employer. (My employer, meantime, provides valued services for just such employers, maybe even yours.)

But your employers take home very large annual bonuses while contributing what, exactly, to society? If they and their sub-ms competitors did not do it, would anyone miss it? Suppose, e.g., trades did not register until 1000ms after entry?

Rhetorical questions.

I'm curious, is there a reason why GC'd languages don't use some form of escape analysis so that only allocations that can possibly live beyond the current scope need to be heap allocated?

Lots of GCed languages do use escape analysis. That's what escape analysis was invented for!

Reply on news.ycombinator.com