Chromium project finds that 70% of security defects are memory safety problems

Re:Chromium project finds that 70% of security defects are m... by teknopaul on Sunday May 24, 2020 @03:58AM (#23289955)

Where I work architects agree with you.

Yet fairly modest requirements like 4000 concurrenct connections or a 16gb cache can be hard to achieve.

We almost exclusivly write for the JVM. I see systems with 20 - 30 - 40 jvms with huge CPU and RAM demands, to meet modest perf requirements.

Sometimes I do wonder if we shouldn't write a little more carefully written C and a lot less memory safe Java.

[ Parent | on HN ]

Re:Chromium project finds that 70% of security defects are m... by lmm on Sunday May 24, 2020 @04:55AM (#23290198)

Handling large numbers of connections is more easily done in Java, in my experience, since Java's async support is relatively straightforward.

I would lay money that the language isn't your real bottleneck. Switching languages might save you a factor of 2, using better algorithms or datastructures can save you a factor of 1000 or more. How much profiling do you do?

[ Parent | on HN ]

Re:Chromium project finds that 70% of security defects are m... by dirtydroog on Sunday May 24, 2020 @05:24AM (#23290308)

Look at the networking sourc code for Redis. It meets all your requirements and isn't that big.

[ Parent | on HN ]