vitalyd

17 ms·

91.
by vitalyd 11y ago
Yes your example is bad. If JIT inlines through, the code is trivially dead and can be removed. So yes, please use proper bench harness (JMH).
92.
by vitalyd 11y ago
One of the hotly debated aspects of java is that even with java 8 additions the language is fairly simple and there really aren't that many ways to express the same thing.
93.
by vitalyd 11y ago
It has type inference already. Are you talking about omitting type when declaring a variable, e.g. let/var x = 5 type of thing?
94.
by vitalyd 11y ago
I don't think the 100M entries example suffers from inlining or profile pollution. It's just that the manual loop is going to be as tight as you can get it and it's likely the stream version leaves artifacts behind that are
95.
by vitalyd 11y ago
Yes, perhaps that part is in the hand written assembly portion that's mentioned.
96.
by vitalyd 11y ago
By stale I meant holding a ref to a cache about to be deleted.
97.
by vitalyd 11y ago
This is both clever and terrifying :). How do they prevent compiler from scheduling the load early, observing, and using the stale cache pointer? Do they have at least a compiler fence on the read side?
98.
by vitalyd 11y ago
You could but it's likely to perform worse for common case. Where are you going to record the addresses? How are you going to size that buffer? Card table is fixed size, and doesn't care whether you're using compressed point
99.
by vitalyd 11y ago
Hotspot JVM C2 compiler does this optimization, with varying degree of success but generally brittle and completely opaque. It doesn't actually stack allocate them technically speaking, just scalarizes them into registers. Should als
100.
by vitalyd 11y ago
Ok, we keep talking about malloc -- which malloc impl are you specifically referring to? There are many allocators out there these days, so let's be a bit more concrete. If not specific name, at least the class of allocator. Most of
101.
by vitalyd 11y ago
>I'm going to mention this too. I don't understand what you mean by "they point to objects in the arbitrary cost anyway". The fact of the matter is that you have to trace all objects at some point. I think he means th
102.
by vitalyd 11y ago
A performant GC for mobile is inherently a much harder problem than for servers.
103.
by vitalyd 11y ago
I'm not sure memory locality effects can be considered secondary, unless their effects are completely dwarfed by something else the app is doing (e.g. there's no point in discussing this topic for i/o bound workloads). I don&
104.
by vitalyd 11y ago
Right, that's why it bothers me when TLAB and stack are compared.
105.
by vitalyd 11y ago
> True, but you could do the same thing in any region of memory. The only thing that using "the stack" buys you is that there are a few special instructions to allocate / deallocate one machine word at a time (if you store
106.
by vitalyd 11y ago
There's also push/pop.
107.
by vitalyd 11y ago
The inherent benefit to the stack is the memory region stays hot in cache due to natural use of the stack. That's your fast reusable buffer for temporaries. In addition, of course, cleanup/reclaim of the stack space is pointer bu
108.
by vitalyd 11y ago
> Working on GC-managed memory is faster still. Care to elaborate?
109.
by vitalyd 11y ago
GC does help with ABA style concurrent problems, and it also simplifies the places where you simply don't care (slow/uncommon paths). But concurrent data structures are a special case, and likely, not always the best anyway since
110.
by vitalyd 11y ago
A card in the card table covers more than one object, so the entire dirty card needs to be scanned. Card marks only help with old->young references, and stack based roots still need to be visited each time, irrespective of what happened
111.
by vitalyd 11y ago
I really dislike the comparisons of TLAB to stack allocation. Stack, by its nature, is going to be hot in cache. TLAB, once filled up, will be retired and possibly assigned to a different thread. But even if it's not assigned, it&#x
112.
by vitalyd 11y ago
It may also be beneficial to move some processing to a different core (perhaps even different socket) to avoid execution resource contention (e.g. d/i-cache, execution ports, etc).
113.
by vitalyd 11y ago
For low latency messaging like this you'd typically want to avoid cross socket data transfers. However, IIRC cacheline snooping across sockets is a bit quicker (Intel QPI at least) than remote dram access so if the lines stay in cache