Jump to page: 1 2 3
Thread overview
GCs are complicated beasts: .NET Core, 35000 lines
Feb 03, 2015
Tourist
Feb 03, 2015
Orvid King
Feb 03, 2015
Paulo Pinto
Feb 04, 2015
Russel Winder
Feb 04, 2015
Paulo Pinto
Feb 04, 2015
Russel Winder
Feb 04, 2015
Walter Bright
Feb 06, 2015
Russel Winder
Feb 06, 2015
Russel Winder
Feb 07, 2015
Jacob Carlborg
Feb 05, 2015
Jacob Carlborg
Feb 06, 2015
Muahmmad Adel
Feb 06, 2015
Paulo Pinto
Feb 06, 2015
Paolo Invernizzi
Feb 06, 2015
ketmar
February 03, 2015
Source code:
https://raw.githubusercontent.com/dotnet/coreclr/master/src/gc/gc.cpp

Origin:
http://www.reddit.com/r/programming/comments/2unrll/net_core_is_on_github/coa2uot
February 03, 2015
On Tuesday, 3 February 2015 at 22:19:08 UTC, Tourist wrote:
> Source code:
> https://raw.githubusercontent.com/dotnet/coreclr/master/src/gc/gc.cpp
>
> Origin:
> http://www.reddit.com/r/programming/comments/2unrll/net_core_is_on_github/coa2uot

The thing to realize about the .net GC is that it is precise, generational, compacting, and asynchronous. It also has a low-latency mode which is primarily used for ASP.net, which limits the maximum time spent in performing a single collection. It also supporting pinning allocations. In comparison, D's GC is simple, as are most GC implementations.
February 03, 2015
On Tuesday, 3 February 2015 at 22:27:38 UTC, Orvid King wrote:
> On Tuesday, 3 February 2015 at 22:19:08 UTC, Tourist wrote:
>> Source code:
>> https://raw.githubusercontent.com/dotnet/coreclr/master/src/gc/gc.cpp
>>
>> Origin:
>> http://www.reddit.com/r/programming/comments/2unrll/net_core_is_on_github/coa2uot
>
> The thing to realize about the .net GC is that it is precise, generational, compacting, and asynchronous. It also has a low-latency mode which is primarily used for ASP.net, which limits the maximum time spent in performing a single collection. It also supporting pinning allocations. In comparison, D's GC is simple, as are most GC implementations.

And I bet commercial JVMs even have more LOCs given the pluggable set of GCs they come with.

Oracle is planning to drop some of them by Java 9 exactly because of maintenance costs.

http://openjdk.java.net/jeps/214

--
Paulo
February 04, 2015
On Tue, 2015-02-03 at 22:40 +0000, Paulo Pinto via Digitalmars-d wrote:
> […]
> 
> And I bet commercial JVMs even have more LOCs given the pluggable set of GCs they come with.

On the other hand does anyone use anything other than G1 these days?

> Oracle is planning to drop some of them by Java 9 exactly because of maintenance costs.
> 
> http://openjdk.java.net/jeps/214

And because G1 provably does the job.

BTW The Go team have completely rewritten the Go GC 1.4 → 1.5. Of course they have also completely rewritten the entire Go toolchain. Compiler, linker, runtime all written in Go now, no more C.
-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

February 04, 2015
On Wednesday, 4 February 2015 at 12:09:36 UTC, Russel Winder wrote:
> On Tue, 2015-02-03 at 22:40 +0000, Paulo Pinto via Digitalmars-d wrote:
>> […]
>> 
>> And I bet commercial JVMs even have more LOCs given the pluggable set of GCs they come with.
>
> On the other hand does anyone use anything other than G1 these days?

Yes.

You just have to witness a discussion on HN or Reddit to see how the
majority of developers that don't optimize for performance are unaware
of GC options across the Java world.

>
>> Oracle is planning to drop some of them by Java 9 exactly because of maintenance costs.
>> 
>> http://openjdk.java.net/jeps/214
>
> And because G1 provably does the job.
>
> BTW The Go team have completely rewritten the Go GC 1.4 → 1.5. Of
> course they have also completely rewritten the entire Go toolchain.
> Compiler, linker, runtime all written in Go now, no more C.

I really like that they decided to do that.

First because I always enjoyed following the bootstrap route when playing
with compiler development back in my degree days.

Second, because it gets rid of C so it earns brownie points.

Many times language designers use C due to multiple reasons, some of them make good sense like using it as portable assembler or fast bootstrap of the runtime, and not because it isn't possible to avoid it.

However the naysayers without compiler design background, use the C dependency as argument for language X cannot be done without C, ergo C rulez.

So looking forward for Go 1.5 and also SDC.
February 04, 2015
On 2/4/15 4:09 AM, Russel Winder via Digitalmars-d wrote:
> BTW The Go team have completely rewritten the Go GC 1.4 → 1.5. Of
> course they have also completely rewritten the entire Go toolchain.
> Compiler, linker, runtime all written in Go now, no more C.

How does the rewrite compare against the originals? -- Andrei
February 04, 2015
On Wed, 2015-02-04 at 08:31 -0800, Andrei Alexandrescu via Digitalmars-d wrote:
> On 2/4/15 4:09 AM, Russel Winder via Digitalmars-d wrote:
> > BTW The Go team have completely rewritten the Go GC 1.4 → 1.5. Of course they have also completely rewritten the entire Go toolchain. Compiler, linker, runtime all written in Go now, no more C.
> 
> How does the rewrite compare against the originals? -- Andrei

I haven't tried them as yet. I switched from compiling the Go toolchain from Mercurial to just using released distributions (*). I think I will have to clone the Git repository and compile from there (**)


(*) Fedora Rawhide packages take about 2-days to be released, Debian Sid is in freeze so they are already so far out of date with Go as to be annoying.

(**) Yes you read that right, the Go team have switched from Mercurial to Git. This is not because they were unhappy with Mercurial, it is because they were unhappy with Rietveld and switched to Gerrit for their changeset handing. The Go team do not use pull requests at all, everything goes through a review manager, now that is Gerrit. Mayhap D could follow the Go example?
-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

February 04, 2015
On 2/4/2015 10:31 AM, Russel Winder via Digitalmars-d wrote:
> The Go team do not use pull requests at all,
> everything goes through a review manager, now that is Gerrit. Mayhap D
> could follow the Go example?

We'd need an awful good reason to ditch the PR system we use now.

February 04, 2015
On 2/4/15 10:31 AM, Russel Winder via Digitalmars-d wrote:
> (**) Yes you read that right, the Go team have switched from Mercurial
> to Git. This is not because they were unhappy with Mercurial, it is
> because they were unhappy with Rietveld and switched to Gerrit for
> their changeset handing. The Go team do not use pull requests at all,
> everything goes through a review manager, now that is Gerrit. Mayhap D
> could follow the Go example?

Not sure what you're proposing. I am positive we are on git and not on mercurial :o). -- Andrei

February 05, 2015
On 2015-02-04 17:31, Andrei Alexandrescu wrote:

> How does the rewrite compare against the originals? -- Andrei

I don't have much practical experience with Go but I think that the custom linker makes the overall build time faster. For D, the linker is a problem, even though the compiler is fast but the overall user experience counts too.

-- 
/Jacob Carlborg
« First   ‹ Prev
1 2 3