Adding Java and C++ to the MQTT benchmarks or: How I Learned to Stop Worrying and Love the Garbage Collector

[Paulo Pinto]

Am 09.01.2014 20:40, schrieb H. S. Teoh:
> On Thu, Jan 09, 2014 at 07:01:59PM +0000, Sean Kelly wrote:
>> On Wednesday, 8 January 2014 at 19:17:08 UTC, H. S. Teoh wrote:
> [...]
>>> Manual memory management is a LOT of effort, and to be quite
>>> honest, unless you're writing an AAA 3D game engine, you don't
>>> *need* that last 5% performance improvement that manual memory
>>> management *might* gives you. That is, if you get it right. Which
>>> most C/C++ coders don't.
>>
>> The other common case is server apps, since unpredictable delays
>> can be quite undesirable as well.  Java seems to mostly get
>> around this by having very mature and capable GCs despite having
>> a standard library that wants you to churn through memory like
>> pies at an eating contest.  The best you can do with D so far is
>> mostly to just not allocate whenever possible, by slicing strings
>> and such, since scanning can still be costly.  I think there's
>> still some work to do here, despite loving the GC as a general
>> feature.
>
> I think we all agree that D's GC in its current state needs a lot of
> improvement. While I have come to accept GCs as a good thing, that
> doesn't mean that D's current GC is *that* good. Yet. I wish I had the
> know-how (and the time!) to improve D's GC, because if D can get a GC
> that's on par with Java's, then D can totally beat Java flat, since the
> existence of value types greatly reduces the memory pressure on the GC,
> so the GC will have much less work to do compared to an equivalent Java
> program.
>
> OTOH, even with D's suboptimal GC, I'm already seeing great productivity
> gains at only a low cost, so that's a big thumbs up for GC's. And the
> nice thing about being able to call malloc from D (which you can't in
> Java) means you can still do manual memory management in critical code
> sections when you need to squeeze out some extra performance.
>
>
> T
>

Well, there are a few options to call malloc from Java:

- Do you own JNI wrapper
- Use Java Native Access
- Use Java Native Runtime
- Use NIO Buffers
- Use sun.misc.Unsafe.allocateMemory (sun.misc.Unsafe is planned to 
become a public API)

--
Paulo