| Thread overview | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
February 03, 2015 GCs are complicated beasts: .NET Core, 35000 lines | ||||
|---|---|---|---|---|
| ||||
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 Re: GCs are complicated beasts: .NET Core, 35000 lines | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Tourist | 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 Re: GCs are complicated beasts: .NET Core, 35000 lines | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Orvid King | 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 Re: GCs are complicated beasts: .NET Core, 35000 lines | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Paulo Pinto | 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 Re: GCs are complicated beasts: .NET Core, 35000 lines | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Russel Winder | 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 Re: GCs are complicated beasts: .NET Core, 35000 lines | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Russel Winder | 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 Re: GCs are complicated beasts: .NET Core, 35000 lines | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 Re: GCs are complicated beasts: .NET Core, 35000 lines | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Russel Winder | 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 Re: GCs are complicated beasts: .NET Core, 35000 lines | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Russel Winder | 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 Re: GCs are complicated beasts: .NET Core, 35000 lines | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 | |||
Copyright © 1999-2021 by the D Language Foundation
Permalink
Reply