[OT] Why mobile web apps are slow

[Brian Rogoff]

On Wednesday, 10 July 2013 at 14:01:51 UTC, Paulo Pinto wrote:
> On Wednesday, 10 July 2013 at 13:30:26 UTC, bearophile wrote:
>> thedeemon:
>>
>>> No mature GCed languages behave that bad.
>>
>> I think there is one JavaVM that manages to avoid part of the 
>> problem you explain (and maybe it needs special kernel 
>> support). I think all other JavaVMs suffer it, more or less.
>>
>> Bye,
>> bearophile
>
> Yes, the C4 garbage collector in the Azul JVM
>
> http://www.azulsystems.com/products/zing/whatisit
>
> http://www.azulsystems.com/products/zing/c4-java-garbage-collector-wp
>
> They used to have special hardware, but now they use standard 
> kernels.
>
> RedHat is also planning to have a go at it for the OpenJDK,
>
> http://rkennke.wordpress.com/2013/06/10/shenandoah-a-pauseless-gc-for-openjdk/
>
>
> --
> Paulo

Interesting. There was some discussion of adding a 'pauseless' GC 
to Go as well, here

https://groups.google.com/forum/#!topic/golang-dev/GvA0DaCI2BU

and in that discussion Gil Tene, one of the authors of Azul, 
opines

"Starting with a precise and generational stop-the-world 
implementation that is robust is a must, and a good launching pad 
towards a concurrent compacting collector (which is what a 
"pauseless" collector must be in server-scale environments). Each 
of those qualities (precise, generational) slaps serious 
requirements on the execution environment and on the compilers 
(whether they are pre-compilers or JIT compilers doesn't matter): 
precise collectors require full identification of all references 
at code safepoints, and also require a robust safepoint 
mechanism. Code safepoints must be frequent (usually devolve to 
being at every method entry and loop back edge), and support in 
non-compiler-generated code (e.g. library and runtime code 
written in C/C++) usually involves some form of reference handle 
support around safepoints. Generational collectors require a 
write barrier (a ref-store barrier to be precise) with full 
coverage for any heap reference store operations (in 
compiler-generated code and in all runtime code).

It is my opinion that investing in the above capabilities early 
in the process (i.e. start now!) is critical. Environments that 
skip this step for too long and try to live with conservative GC 
in order to avoid putting in the required work for supporting 
precise collectors in the compilers and runtime and libraries 
find themselves heavily invested in compiler code that would need 
to be completely re-vamped to move forward. ..."

Sounds like that precise GC talk at DConf was quite timely. Let's 
hope that prediction about being too heavily invested in 
conservative GC dependencies isn't too true!

-- Brian