well done guys.. but it will use AllocVec or AllocVecNew or what??
it is a joke..

Anonymous..

_________________
http://www.amigasoft.net

Quote:

2) What other systems use this architecture?

Eg. Linux

Last edited by miksuh on 13-Dec-2005 at 11:38 PM.
Last edited by miksuh on 13-Dec-2005 at 11:37 PM.

Quote:

How does the memory-system of OS4 compare to that of Windows/Linux/Mac OSX?

Linux uses a similar scheme... originally, it was developed for Solaris with the goal of supporting uptimes of a year or more

Quote:

Is this the most 'modern' way of memory handling?

It represents current state of the art, yes

_________________
Thomas, the kernel guy

"I don't have a frigging clue. I'm norwegian" -- Ole-Egil

All opinions expressed are my own and do not necessarily represent those of Hyperion Entertainment

@afxgroup
Not everybody reads utilitybase
(I'm not the anonymous, anyway I agree with the clean, non-duplicating concepts, compared to AllocVecNew, AllocVecNew2, ... )

But it was a good read.
rgds

Great . We'll to this

_________________
---------
AmigaClyde

µA1-C 750GX@800 using OS4.1

Quote:

1) Slab architecture was onbviously developed by Sun (see the references) - do they hold a patent on its use?

If it would, our lawyer would have stopped me.

Quote:

2) What other systems use this architecture? It appears to have been around since 1994 (in theory at least!) - if it hasn't been used, then is there a valid reason why not?

Linux uses it.

Quote:

3) Could we have an illustration/example showing how the slab allocation process would deal with the fragmentation problem from the first set of examples (i.e. so we can compare what went wrong with the previous model, and how this has been resolved by this newer method)?

Well, the slab allocation in this context (malloc/free emulation) uses segregated memory lists... as such , a case like in the first example can not really happen... It CAN happen on a page level (i.e. not enough contiguous pages for a single allocation), but since it's not necessary to have the pages contiguous in memory, this is no problem (if required, pages can be physically copied and remapped).

Quote:

4) Does the implementation of this (radically different) memory allocation process break backwards compatibility, or is there a wrapper of some sort that mediates between the two methods? (Note however that I don't really give two hoots about full backwards compatibility - the quality of modern emulation is more than satisfactory!)

If an application doesn't access the memory list, this scheme will not break the compatibility. Note that Alloc[Vec|Mem] and Free[Vec|Mem] still work.

Quote:

5) Is there an upper limit on the amount of memory that this architecture will support?

No, only the "usual" limitation that we have only 32 bit pointers.

Quote:

6) The process of caching object "hot spots" sounds interesting - is this something that a developer has to specifically expose to the memory API, or is it automatically and dynamically handled during run-time?

It's handeled automatically... one object cache consists of multiple slabs, and each new slab will be prepared with a new "color" (while retaining the required alignment for the cache, of course).


Quote:

7) Do you actually have an operational version of your code which runs on multiple CPUs (and therefore *know* that it scales up in a linear manner) or is this something taken from the second reference (as indicated in the article) and is being borne in mind for the future...?

AmigaOS in it's current form does not work on multiple CPU's. There are unresolved issues (i.e. Forbid/Permit semantics).

However, the second link points to a paper that describes the methods employed, as well as test data that shows the result.

If you're intereseted, the papers linked are understandable even without background knowlede in memory allocation...

_________________
Thomas, the kernel guy

"I don't have a frigging clue. I'm norwegian" -- Ole-Egil

All opinions expressed are my own and do not necessarily represent those of Hyperion Entertainment

Quote:

well done guys.. but it will use AllocVec or AllocVecNew or what??

You can still use AllocVec, however, the cache interface is exposed, and the main strength of the system is in the object caching.

Actually, there is a new AllocVec type function, called AllocVecTags/AllocVecTagList. You can control some aspects of memory allocation. For example, there's a tag AVT_Alignment which can be used to allocate memory with a certain alignment...

_________________
Thomas, the kernel guy

"I don't have a frigging clue. I'm norwegian" -- Ole-Egil

All opinions expressed are my own and do not necessarily represent those of Hyperion Entertainment

Thanks for the info guys.

Naturally, some of it went straght over my head. Howevrr, I understood the title

FuZion.

@ FuZion

Quote:

Thanks for the info guys. Naturally, some of it went straght over my head. Howevrr, I understood the title FuZion.

You are not alone, amigo. However, I am glad that they understand it.

______________________

Moxee

_________________
Moxee
AmigaOne X1000
AmigaOne XE G4
I'd agree with you, but then we'd both be wrong.

Great work Hyperion!
And a good article EntilZha, Drummond and Andrew.

Sounds very promising What's next? Resource tracking? Full memory
protection?


@EntilZha

Btw AmigaOS really needs to "fix" the dos.library limitation that makes 2GB
the memory and file size limit. Is this on the todo list for 4.1 or maybe already
being worked on perhaps?

Last edited by Samwel on 14-Dec-2005 at 06:51 AM.
Last edited by Samwel on 14-Dec-2005 at 03:08 AM.
Last edited by Samwel on 14-Dec-2005 at 02:57 AM.

_________________
/Harry

[SOLD] µA1-C - 750GX 800MHz - 512MB - Antec Aria case

Avatar by HNL_DK!

@ Samwel
Quote:

@EntilZha Btw AmigaOS really needs to "fix" the dos.library limitation that makes 2GB the memory and file size limit. Is this on the todo list for 4.1 or maybe already being worked perhaps?

I presume it is too late to implement large file support for a 4.0 release. If Hyperion wants to do it "properly" it would mean enabling large file support in the entire O/S. This would be a *huge* number of code changes. As EntilZha recently said, they are basically in bug fixing mode at this point.

However, having said that, there is nothing stopping them from already working on the next release (4.1) while 4.0 is out there being beaten up. In fact I would be surprised if that kind of work is not already taking place.

Please Hyp folks don't do what some UNIX vendors went and did - provided large file support in the kernel but then didn't go back through the O/S commands and implement it across the board. That is even worse than no large file support.

And yes... two thumbs way up on the new memory management implementation!!

Last edited by gregthecanuck on 14-Dec-2005 at 04:58 AM.
Last edited by gregthecanuck on 14-Dec-2005 at 03:50 AM.
Last edited by gregthecanuck on 14-Dec-2005 at 03:49 AM.

I love you. (and I love your beer too)

Nothing funny ;)

I always loved Andy's articles in CU *cheers*

Steve

P.S anyone for some Kwak or Duvel?

_________________
A1200T - OS4.0,OS3.9: 603e PPC 200mhz,060 50mhz, 256mb ram, FastATA MK-III, BVision, 160gb,20gb HDDs

A1200 - OS3.1: Blizzard IV 030, 64mb ram, 400mb HDD

OS4.x - Flying the AMIGA flag

It was disclosed at the Alchimie show in France in October, 64bit I/O functions.

_________________
Philippe 'Elwood' Ferrucci
Sam460 1.10 Ghz
AmigaOS 4 betatester
Amiga Translator Organisation

Excellent article. If only this was being published in CU...

Thanks once again to everyone involved.

I should/will have OS4 (providing there is hardware on sale) in the New Year.

Bring on 2006...

Steve

Last edited by stevieu on 14-Dec-2005 at 08:59 AM.

_________________
A1200T - OS4.0,OS3.9: 603e PPC 200mhz,060 50mhz, 256mb ram, FastATA MK-III, BVision, 160gb,20gb HDDs

A1200 - OS3.1: Blizzard IV 030, 64mb ram, 400mb HDD

OS4.x - Flying the AMIGA flag

@Entilzha:

That's pretty cool stuff! and I can totally relate to the boredom of the bugfix stage in software development, I work in the software biz too (although I'm in the finding end of things, rather than fixing). Just about the most exciting thing that happens at this stage in the game is arguing with a dev manager that the crashing bug you just found does meet the current quality bar, and yes customers are going to hit it and no, it's not just one of those weird things us testers come up with


@Elwood:

Details, please?

[edit] fixed typo...

Last edited by CodeSmith on 14-Dec-2005 at 09:03 AM.

This is exciting on at least 3 fronts:

1. New "cutting edge" technology for the Amiga.
2. A new update from Hyperion, thanks EntilZha.
3. Richard and Andrew are still involved, thanks guys!

_________________

Quote:

@elwood It was disclosed at the Alchimie show in France in October, 64bit I/O functions.

Any hints as to which release this would be available in? 4.0? 4.n?

Does this 64bit I/O imply a 64bit memory model as well? Can't hurt since the memory manager just got a little, tiny upgrade.

@EntilZha

Quote:

This one was written by me, and then proof-read, clarified and largely re-written by two well-known Amiga writers, Richard Drummond and Andrew Korn

Thanks to all for sharing these nice information (and for the actual job of introducing the new memory system, of course )
However, I have one point of curiosity that remained unsatisfied: what about the logical subdivision (virtual, chip, fast, etc.) of the memory? I remember that that was bound to chance... has it changed? Is there a cleaner system in place now?

saimo

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@gregthecanuck

64bit memory pointers and the ability to use 64bit files are two totally seperate issues, with different problems and issues.

Just becaus DOS has support for 64bit file I/O, doesn't suddenly make OS have a 64bit memory model.

_________________
Playstation Network ID: xeron6

@FuZion

Quote:

Naturally, some of it went straght over my head. Howevrr, I understood the title

Glad I wasn't the only one then

_________________
SAM 460 with 2GB or RAM, 1000GB HD, 4 port SATA, DVDRW drive and Radeon HD 4650 GFX card.