On 2008-09-05 03:06:24 +0200, Christopher Wright <dhasenan@gmail.com> said:

> Tomas Lindquist Olsen wrote:
>> Manfred_Nowak wrote:
>>> Denis Koroskin wrote:
>>> 
>>>> You can read the whole story at www.google.com/googlebooks/chrome/
>>> 
>>> On page 16 they mention "precise GC".
>>> 
>>> -manfred
>>> 
>> 
>> Are you suggesting we should start talking about how this could be done in D ?
>> 
>> -Tomas
> 
> A major benefit of a precise GC is that you can turn it into a moving GC. Without a precise GC, you might change some random sequences of bytes to something else because it looks like a pointer to something you moved; not so with a precise GC.

well as long as you have unions, then you have to be *very* careful about not moving them.
In safe D this is not an issue.

Fawzi

Fawzi Mohamed wrote:
> On 2008-09-05 03:06:24 +0200, Christopher Wright <dhasenan@gmail.com> said:
>> A major benefit of a precise GC is that you can turn it into a moving GC. Without a precise GC, you might change some random sequences of bytes to something else because it looks like a pointer to something you moved; not so with a precise GC.
> 
> well as long as you have unions, then you have to be *very* careful about not moving them.
> In safe D this is not an issue.
> 
> Fawzi
> 

Ach, bugger the unions.

Now you need two bits per word: one for whether it contains pointers and one for whether it pins anything it points to, assuming it's a pointer. Unions containing pointers (punions) would be pinning pointers, and you could probably use some sort of pragma to indicate that a pointer should pin whatever it points to.

In the presence of a punion, a garbage collector would be conservative. Otherwise it could be precise.

On Wed, 03 Sep 2008 16:46:57 +0100, davidl <davidl@126.com> wrote:

> 在 Wed, 03 Sep 2008 22:08:27 +0800，Alexander Panek <alexander.panek@brainsware.org> 写道:
>
>> Denis Koroskin wrote:
>>> You already know that Google is making a buzz with their new Chrome browser.
>>> Go download and test it if you didn't do yet (www.google.com/chrome/, Windows only for now).
>>>  It is heavily multi-threaded and uses separate process for each window, each tab, each plugin etc. When one tab hags or a plugin crashes, nothing bad happens. The browser continues working as if nothing changes. It even has a built-in process manager, try opening youtube.com and killing a flash player plugin.
>>>  You can read the whole story at www.google.com/googlebooks/chrome/
>>>  This is an example of process-based designs implementation which is what D2 aims at, and it is clearly a success.
>>
>> It's funny, just a week ago or so Bartosz Milewski published a blog entry about how processes scale better than threads..
>>
>> I tried Chrome and I'm really impressed by how responsive it is. Also, the UI is kept very minimalistic, yet it doesn't lack any features. The website-application feature is also a very handy thing.
>>
>> Overall, I'd say Google Chrome is quite an impressive product. Would love having a D port. :P
>
> Who will ever want to port a such big project? 437MB Source tarball(WTF, a browser bigger than OS source base)
>
> Google goes the wrong way. It just extends the current web crap not reinvent something smarter.
>
Porting code is a lot easier than writing code from scratch, though it assumes you have a
good design and a good reason to port. Assuming the design is adequate the reason to port
would be to demonstrate why D was a better langage than whatever its written in. They
don't seem keen to advertise it but it looks like C++ from a quick google.

Sean Kelly wrote:
> Chris R. Miller wrote:
>> Sean Kelly wrote:
>>> Denis Koroskin wrote:
>>>> You already know that Google is making a buzz with their new Chrome
>>>> browser.
>>>> Go download and test it if you didn't do yet (www.google.com/chrome/,
>>>> Windows only for now).
>>>>
>>>> It is heavily multi-threaded and uses separate process for each
>>>> window, each tab, each plugin etc. When one tab hags or a plugin
>>>> crashes, nothing bad happens. The browser continues working as if
>>>> nothing changes. It even has a built-in process manager, try opening
>>>> youtube.com and killing a flash player plugin.
>>>>
>>>> You can read the whole story at www.google.com/googlebooks/chrome/
>>>>
>>>> This is an example of process-based designs implementation which is
>>>> what D2 aims at, and it is clearly a success.
>>> It's probably worth mentioning that IE has offered an option to make
>>> each window its own process for as long as I can remember.  That said,
>>> the idea of rethinking browsers in general is a good one, if "web as a
>>> platform" is ever going to make headway.
>>
>> Ehrm, I think that the Window as a Process feature is in Explorer only,
>> not Internet Explorer.  I quickly checked my Internet Explorer and
>> didn't find that feature (though I know it's there for just plain-old
>> Explorer).  Explorer isn't a web browser AFAIK, so IE really hasn't been
>> doing anything special along those lines.
> 
> Huh... I could have sworn there was an IE setting for this.  Ah well.
> 
> 
> Sean

Nope, but you can control it somewhat: in IE6 (and IE7 too I think) if you open a new browser from an existing one (Open in New Window) it will use the same process. But if you run the iexplorer.exe executable it will launch a new process.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bill Baxter wrote:
> On Thu, Sep 4, 2008 at 10:14 PM, Steven Schveighoffer
> <schveiguy@yahoo.com> wrote:
>> "Denis Koroskin" wrote
>>> You can read the whole story at www.google.com/googlebooks/chrome/
>> Hey, this comic is really awesome for explaining things!  The author did a
>> great job.  Any artists out there that can explain the D benefits this way?
>> I think that might go a long way for newb's.
>>
>> -Steve
> 
> I was reading that comic thinking man this guy *must* have really
> studied those "understanding comics" books because he's using all the
> techniques just like they're described in that book.
> 
> Turns out the comic was done by Scott McCloud, who *is* the
> Understanding Comics books guy.
> 
> So looks like all we have to do is pay Scott McCloud large sums of
> cash and he will make us a nice comic for D too!
> 
> --bb

Let's have him do a comic explaining Walter why C-legacy is bad, and why Java style is (usually) good.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Chris R. Miller a écrit :
> Chris R. Miller wrote:
>> Alexander Panek wrote:
>>> davidl wrote:
>>>> 在 Wed, 03 Sep 2008 22:08:27 +0800，Alexander Panek
>>>> <alexander.panek@brainsware.org> 写道:
>>>>> Overall, I'd say Google Chrome is quite an impressive product. Would
>>>>> love having a D port. :P
>>>> Who will ever want to port a such big project? 437MB Source
>>>> tarball(WTF, a browser bigger than OS source base)
>>> I suppose you noticed the emoticon (":P") at the end of that sentence.
>> 437MB?  I gotta go check that out (as in verify, not load my poor disk
>> with even more stuff).
> 
> I ran, I checked, I became intrigued, so I downloaded and decompressed.
> 
> Firstly, it's 1.682 GB of raw sources.
> 
> Secondly, I ran an HDGraph scan of the tree to see where everything is.
> 
> 199.16 MB of hunspell dictionaries
> 147.46 MB of Chrome test data
> 228.31 MB of Chrome tools test data marked as a "reference build"
> 147.87 MB of webkit layout test results data
> = 722.8 MB of non-code data
> 
> Therefore 1.682 GB - 722.8 MB = 959.2 MB total of source code
> 
> The Chrome source itself, minus the data and tools data, etc. is only
> 57.75 MB of source code for the browser itself.  The rest is third party
> libraries, such as Cygwin libraries and what looks to be the better part
> of 77 MB of a Perl interpreter and attached libraries, 158 MB of "icu38"
> library sources, etc.  It's really no wonder it's such a large download,
> since all you need to build the browser is MSVC 2005 and the Windows
> SDK.  Otherwise you don't need to go download any of the other things
> yourself.  So on closer inspection is does seem like a more appropriate
> level of data for a browser.
> 
> Looking at a few of the source files individually, it does appear that
> much of the code is reasonable, and that most of the data is just tools
> for unit tests, etc.
> 
> Just thought I'd share.

Thanks a lot for this detailed explanation.

BR,
renoX