mandarax8

Because in your benchmark all std::map nodes were allocated in succession, most likely being placed in adjacent memory locations...

This likely won't be true in a real application with a non-trivial allocation pattern.

> I actually don't understand the tearing they're talking about. If the fields are final then you can't modify the Value Type anyway?

You can assign the object again to overwrite it 'in place'.

> And a simple write-lock bit for fat Value Types would solve everything while maintaining most of the performance benefits (both on read and write)

They even already have an extra 'null' bit tacked on to the value object.

Is there any reason that you couldn't implement this on Xorg?

Please read up some more about Java and GCs. Memory allocation and GC are heavily intertwined.

Indeed I misread. I figured the NMI must have been nested or otherwise they wouldn't have gone through all this trouble just to drop samples :)

Not OP: how would you handle the second interrupt during the interrupt handler here then? I can see how you could use two separate ring buffers for different contexts, but I don't see how to handle the nested interrupt. Also indeed they just drop all these samples that get deadlocked.

Actually, as long as you use different ring buffers for interrupt/non-interrupt context, it should be fine to just drop if you encounter a deadlock due to interrupting an already running interrupt handler.

One thing wasn't clear for me in the article: is there only one such ringbuffer defined by the kernel or can the eBPF program specify as many ringbuffers as it wants?

I give up, tell me the AABB trick please

The entire point of the article is that you cannot throw from a destructor. Now how do you signal that closing/writing the file in the destructor failed?

Maybe we can even find some correlation in the bit pattern of the input and the Boolean table!

The pixel position has to be known, how else are you rasterizing something?

Their current OpenGL 4.1 actually does run on top of metal making it even more blatantly obvious that they just don't want to.

I'm not sure exactly what you mean, but you can both output line primitives directly from the mesh shader or output mitered/capped extruded lines via triangles.

As far as other platforms, there's VK_EXT_line_rasterization which is a port of opengl line drawing functionality to vulkan.

That said MSVC,GCC and clang all implement it to allocate an exact value.