On Wednesday, 10 July 2013 at 22:22:41 UTC, H. S. Teoh wrote:
> On Wed, Jul 10, 2013 at 11:32:29PM +0200, John Colvin wrote:
>> On Wednesday, 10 July 2013 at 21:05:32 UTC, Jonathan A Dunlap wrote:
>> >My 2cents: for D to be successful for the game development
>> >community, it has to be possible to mostly sidestep the GC or opt
>> >into a minimal one like ARC. Granted, this is a bit premature
>> >considering that OpenGL library support is still in alpha quality.
>> 
>> I've noticed that when you reply to a thread, you reply to the most
>> recent response, irrelevant of context. This is a bit confusing to
>> those of us who view the group in a threaded layout. For example
>> here Walter is talking about not having inflight audio on a
>> discontinued? military recon plane and then there's you listed as a
>> replying to him, talking about ARC and GCs!
>
> There's a long-standing bug in the mailing list interface to the forum
> that rewrites message IDs when it shouldn't, thus breaking threads. This
> problem has been irking me for a long time now, but it seems nobody is
> interested to fix it. :-(
>
>
> T

There is, but I don't think this was one of those cases. That manifests as an entirely new thread in the forum interface.

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

> There is, but I don't think this was one of those cases. That manifests as an entirely new thread in the forum interface.

Your correct John, totally my bad. I'll be more vigilant in which post I reply to as I didn't realize that anyone really read into the reply's source.

I'm critical about D's GC as I am super passionate about being able to one day use D for professional game development. =)

On 2013-07-10 20:43, Paulo Pinto wrote:

> What sometimes goes missed between the lines is that one of the
> decisions to go ARC instead of GC, is because the Objective-C GC never
> worked properly and ARC offers a better fit for the current state of
> Objective-C world.
>
> First of all, GC was an opt-in and very few libraries supported it.

Wasn't it possible to use the GC with all libraries but not the other way around?

> Then we have the typical issues with a conservative GC in a C based
> language, which lead to tons of issues if one looks into developer forums.

The GC only worked for the Objective-C part.

-- 
/Jacob Carlborg

On Thursday, 11 July 2013 at 07:34:48 UTC, Jacob Carlborg wrote:
> On 2013-07-10 20:43, Paulo Pinto wrote:
>
>> What sometimes goes missed between the lines is that one of the
>> decisions to go ARC instead of GC, is because the Objective-C GC never
>> worked properly and ARC offers a better fit for the current state of
>> Objective-C world.
>>
>> First of all, GC was an opt-in and very few libraries supported it.
>
> Wasn't it possible to use the GC with all libraries but not the other way around?

No, it depended how you compiled the code.

https://developer.apple.com/legacy/library/#documentation/Cocoa/Conceptual/GarbageCollection/Articles/gcEssentials.html#//apple_ref/doc/uid/TP40002452-SW1

Using -fobjc-gc-only meant your library could only work with GC enabled applications.

Or another quote from the documentation:

"Not all frameworks and technologies support garbage collection; for example, iCloud is not supported in applications that use garbage collection."


>
>> Then we have the typical issues with a conservative GC in a C based
>> language, which lead to tons of issues if one looks into developer forums.
>
> The GC only worked for the Objective-C part.

True, but you were forced to do manual hacks like calling objc_assign_global() for write barriers in global and static variables.

There is the compiler flag -Wassign-intercept to show where write barriers are being generated as a help method if everything is being generated properly.

The Core Foundation needs to be used in a slight different way when interacting with GC enabled objects.

With ARC all these problems do not exist, because the compiler does what the developers would be expected to do manually anyway.

This is way there was such a joy when ARC was announced, not because GC per se is bad.

--
Paulo

On Wednesday, 10 July 2013 at 13:33:15 UTC, Michel Fortin wrote:
> On 2013-07-09 18:12:25 +0000, Paulo Pinto <pjmlp@progtools.org> said:
>
>> A bit off-topic, but well worth reading,
>> 
>> http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
>
> What I'm retaining from this is that garbage collectors are wasteful. They're viable if you have a lot of RAM to spare.


But I think that this is why newer Android phone have a lot of RAM: a GS4 has 2GB of RAM.

> They cause noticeable hiccups at unpredictable times unless you have a battery-hungry overpowered CPU that makes pauses impossible to notice.

Yes and "pauseless GCs" have even higher CPU usage..

renoX




> And while those pauses are not that bad for non-realtime apps, all iOS apps are considered realtime by Apple because you don't want hiccups messing smooth scrolling and animations.
>
> Also, non-deterministic deallocation makes it hard for an app to fit within a fixed memory limit.

On Thursday, 11 July 2013 at 08:53:07 UTC, renoX wrote:
>> They cause noticeable hiccups at unpredictable times unless you have a battery-hungry overpowered CPU that makes pauses impossible to notice.
>
> Yes and "pauseless GCs" have even higher CPU usage..
>

It is more about floating garbage than CPU usage. But yes, they have drawbacks.

On 2013-07-11 10:46, Paulo Pinto wrote:

> This is way there was such a joy when ARC was announced, not because GC
> per se is bad.

Guess I didn't know about all these flaws in the GC.

-- 
/Jacob Carlborg

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.

HotSpot and, I suppose, other mature JVMs provide generational GCs, so you won't get 5 seconds delay after each 8 MB of allocated data there.

thedeemon:

> HotSpot and, I suppose, other mature JVMs provide generational GCs, so you won't get 5 seconds delay after each 8 MB of allocated data there.

They need a certain amount of seconds for each GB of heap memory (assuming an average amount of pointers in that GB of data structures. Java data structures contain many pointers, unlike C# and D). The G1 garbage collector helps spread this computation.

Bye,
bearophile