[rancur]

I'm really surprised this is so new. I'm only beginning to enter the field and falling asleep the other night one of my thoughts was 'why doesn't the GC happen piecemeal?' AKA 'who said we have to collect everything, just unload 2 bins worth'. Mainly WRT use in Android, where it causes perceivable hitching

[on_and_off]

The Android Framework team has been working on improving the runtime and its garbage collector for quite some time. There have been many improvements to the garbage collection strategy. With ART on Lollipop, according to its creator, there should never be a visible GC pause when the app is in the foreground. More information here : http://www.anandtech.com/show/8231/a-closer-look-at-android-... and in various I/O talks. Extremely bad code will still cause problems (but that's true for whatever memory management strategy you rely on) but in my experience, on a nexus 5, GC pauses are no longer a real issue on Android.

Still, Samsung is here to samsung things up. Comparisons of scrolling performances between a flagship samsung device and a nexus are just as expected : https://www.reddit.com/r/GalaxyS6/comments/3ck9no/scrolling_...

That's another topic entirely, but I think that another key factor is to move almost as much as possible of the UI work to a separate thread, not just to make heavy work in the background. It is starting to happen with ripple animations on a RenderThread, but I think that this strategy could be generalized.

[rancur]

> Still, Samsung is here to samsung things up

3rd time I've laughed with more than 60% intensity at something I read on the internet in the last 2 years. thank you!!! hahahaaha

for reference, my last 100% laugh that returned me to the days of cartoons and childhood was this comment about how to install and activate your non-rental-Cable-modem: https://www.reddit.com/r/technology/comments/27szuw/comcast_...

[pjmlp]

On my tablet (not nexus) with Android 5.0 I can surely see when everything comes to a stall.

[on_and_off]

Tablets are indeed complex.

At best they have the same SOC as a good phone but they typically have way more pixels to carry around.

NoName Chinese tablets are often a disaster and even high end tablets are hard to get right.

Even putting graphics aside, things like a slow internal memory can also wreak performances.

[rancur]

might be 5.0 mem leak issues and general bugs

[Gibbon1]

My experience is a lot of people/groups get obsessed with one metric in this case average speed. A pauseless GC is always going to be a bit slower than one that pauses once in a blue moon (meaning all the time from the users standpoint). Requires a really strong will to go against that sort of grain.

Just remembered though: Friend who is a Azul developer said that 0x86 processors did not have the correct instructions to support pausesless GC up until very recently.

So probably a chicken and the egg problem.

[rancur]

can you open that up more? I'm skeptical. Which instructions?

[Gibbon1]

Over my pay grade, which is why I'm slopping away at ARM Cortex firmware instead of at Azul. I'd ask my friend but he's on vacation. I do know Azul originally ran their JVM on custom processors. (Target market high speed trading systems, etc) I can't see why they would have done that unless older 0x86 etc processors just couldn't do what they needed.

A little internet searching, leads to this and some other stuff. https://www.artima.com/lejava/articles/azul_pauseless_gc.htm...

I think the deal is, if the GC moves something, it can leave a bunch of dangling pointers. Those need to be fixed up to point to the new place before they get dereferenced. Except Azul uses a read barrier to trap when a dangling pointer is dereferenced, so the fix up can be lazy.