> >
> > I have a lot of ideas about improving GC, such as making it a copying generational collector, implementing hardware write barriers, and using
type
> > info to mark whole regions as "not containing any pointers", etc. There
is a
> > LOT that can be done to boost performance.
>
> Implementing hardware write barriers?  I didn't think that the hardware was there on most memory controllers.
>
I took that to be; marking the page as read only. and catching the page fault.

Mike Wynn wrote:
>>Implementing hardware write barriers?  I didn't think that the hardware
>>was there on most memory controllers.
>>
> 
> I took that to be; marking the page as read only. and catching the page
> fault.

From what I have read, can't find the link right now, that usually results in a decrease in performance, because the whole page needs to be scanned once the barrer is faulted.  You only know that the page is dirty, not how dirty, and then have to scan 4MB for what is possibly only one allocated object.  I for one would rather go with real software read and write barriers, which can then be replaced with hooks to real hardware read and write barriers once they finally start being reincluded in memory chips, which I figure that they will be before too long, now that microsoft is pressing on the whole garbage collected C#/.NET thing.

Evan

"Evan McClanahan" <evan@dontSPAMaltarinteractive.com> wrote in message news:b25v5t$2bms$1@digitaldaemon.com...
> Mike Wynn wrote:
> >>Implementing hardware write barriers?  I didn't think that the hardware was there on most memory controllers.
> >>
> >
> > I took that to be; marking the page as read only. and catching the page fault.
>
>  From what I have read, can't find the link right now, that usually
> results in a decrease in performance, because the whole page needs to be
> scanned once the barrer is faulted.  You only know that the page is
> dirty, not how dirty, and then have to scan 4MB for what is possibly
> only one allocated object.  I for one would rather go with real software
> read and write barriers, which can then be replaced with hooks to real
> hardware read and write barriers once they finally start being
> reincluded in memory chips, which I figure that they will be before too
> long, now that microsoft is pressing on the whole garbage collected
> C#/.NET thing.
>
on a pentium the page can be 4K or 4M
and I believe there is a 2M page too (May be PPro)

and I agree that it well designed software write barriers are most likely
cheaper (performance, maintance and development)
3 colour non copying concurrent collectors only actually require write and
return barriers

the people I used to know who write GC's don't believe in h/w gc, partly because it restrict what you can do with the object layouts and partly because you can't change or upgrade the gc. h/w that would assist one type of GC might hinder another.

I think it will be a while before hardware gc becomes standard, there are
CPU's that don't even have basic MM
most old consoles and pda's (although I think WinCE devices have to have MM,
I know PalmOS does not require it).
and I think the PS2 has MM 'cos it can run  linux (not uLinux)

and of course if your device has a JavaVM, why bother with hardware MM, when you can do it all in software and save on sillicon. or use Tao intent or similar system. I would expect a CLR bytecode cpu, like the Sun and Arm attempts with Java Bytecode aware CPU's before h/w GC

Mike.

Evan McClanahan wrote:
> Mike Wynn wrote:
> 
>>> Implementing hardware write barriers?  I didn't think that the hardware
>>> was there on most memory controllers.
>>>
>>
>> I took that to be; marking the page as read only. and catching the page
>> fault.
> 
> 
>  From what I have read, can't find the link right now, that usually results in a decrease in performance, because the whole page needs to be scanned once the barrer is faulted.  You only know that the page is dirty, not how dirty, and then have to scan 4MB for what is possibly only one allocated object.  I for one would rather go with real software read and write barriers, which can then be replaced with hooks to real hardware read and write barriers once they finally start being reincluded in memory chips, which I figure that they will be before too long, now that microsoft is pressing on the whole garbage collected C#/.NET thing.
> 
> Evan

Every time the page status is changed the TLB cache would
need to be flushed (an expensive operation), this change would also
have to be reflected across multiple processors on a SMP system.
All of this would probably require support from the operating system,
at least with respect to hooks to preset/reset/get the read/write
flag of the page.

The scanning of the page could be limited by picking a smaller
page size, the 80x86 supports 4Kb as well as 4Mb pages (and 2Mb
pages with page addressing extensions - see CR4.5 & CPUID(2)/EDX.6)

C 2003/2/9