Shared and executable memory is locked implicitly for 68K backwards compatibility reasons. Use AVT_Lock (or equivalent) to ensure your shared and executable memory is not locked.
Why on earth is executable memory locked for 68k backward compatibility when only PPC code is executable??! Seems like a complete waste of locked memory. This means that when monster apps like MPlayer, OWB and TW crashes or hangs (mostly hangs) the system can't swap out the large chunk of executable code.
Software developer for Amiga OS3 and OS4. Develops for OnyxSoft and the Amiga using E and C and occasionally C++
Why on earth is executable memory locked for 68k backward compatibility when only PPC code is executable??! Seems like a complete waste of locked memory. This means that when monster apps like MPlayer, OWB and TW crashes or hangs (mostly hangs) the system can't swap out the large chunk of executable code.
Task switching is still done in an interrupt. If the new task's code is currently swapped out the scheduler would have to wait for the pages to be swapped in again. But waiting for an arbitrary long time is not possible in an interrupt and you cannot tell how long the low lever hard disk driver will need to perform the swap in job. Thus executeable code must be accessible at any time and hence must be locked to prevent it from being swapped out.
What I have problems understanding is that this blog is taking about shard memory. But shard memory should be available to all applications, so it does not make sense to swap it out, stack that consists many of local variables, private memory, should how ever be swappable.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
OWB and TW crashes or hangs (mostly hangs) the system can't swap out the large chunk of executable code.
if you just thinking freeing physical memory, that might work, but you might have a slowdown if the program counter jumps in to swapped memory.
There are lots of API’s that depends on hooks, and there are lots of pluggins that depends on program code being sheared, it might not be performance vice smart having that memory being swapped in and out.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
But shard memory should be available to all applications, so it does not make sense to swap it out
Swapping memory out does NOT prevent it from being accessed (except from an interrupt). Therefore paging out shared memory is perfectly fine, since it can be swapped back in automatically.
The problem with memory paging in AmigaOS is that nobody can really tell what the memory is used for, and when it will be accessed. So backward compatibility dictates a rather "conservative" memory locking, basically, everything that is not implicitly marked as available for paging has to be locked in memory.
Code is sadly one of those, since you can never know what code can be executed in what context. If code is run in a task context other than the disk devices and the pager itself, it could be paged out, but as soon as code is executed in a environment that does not allow waiting, it can not be paged out.
Having said that, we are working on "fixing" this situation. For example, we have plans for running interrupts like tasks, i.e. an interrupt from a hardware would basically just signal a task that such an interrupt occurred and the interrupt handler code would run in a high priority task. That way, it *can* wait and thus would be able to wait for paging operations.
This is just an example, of course, there are other problem areas, but rest assured that we are working on those.
There are lots of API’s that depends on hooks, and there are lots of pluggins that depends on program code being sheared, it might not be performance vice smart having that memory being swapped in and out.
The pager favors old data for page-out operations, so memory that is frequently accessed, or (in theory) code that is run often wold be relatively "hot" and thus would be unlikely to be paged out.
What I have problems understanding is that this blog is taking about shard memory.
I think that is an area that is prone to misunderstanding, that's true. Most people associate shared memory with locked memory, and private memory with unlocked (page-able) memory.
However, there is no connection between shared/private and locked/unlocked memory, only the fact that shared memory is by default allocated as locked. This is simply because most of the time, shared memory is assumed to be used for things like system structures, messages etc, everything that has to be accessed by multiple processes.
Private memory, on the other hand, is supposed to be accessed only by the application allocating it. As such, it is allocated in an unlocked state by default since the MEMF_PRIVATE has to be explicitly given, and the application is supposed to "know what it's doing".
Currently, these two types of memory are also only semantically different, they are, however, not really different in the sense that even now, MEMF_PRIVATE could be accessed from other processes as well (although it would be considered a programming error), simply because the system does not yet offer real per-task memory contexts. This will change in the future though.
Why on earth is executable memory locked for 68k backward compatibility when only PPC code is executable??
This is a bit misleading in it's wording. It does not have anything to do with 68k code, but rather the fact that no program (especially not programs that are basically ports from OS3) has the ability to flag parts of it's code as interrupt executable. Therefore, any ode has to be assume interrupt executable (the other way around would be problematic).
So it's not 68k compatibility, but rather backward compatibility in general.
Task switching is still done in an interrupt. If the new task's code is currently swapped out the scheduler would have to wait for the pages to be swapped in again.
Actually, that's not quite true. The scheduler just restored the task context, it does not bother about the tasks code. It does not access the actual task's code. So, assuming that a task is rescheduled and the task's current code is paged out, the scheduler would just load the context, and restart the task. Of course, the newly launched task would then not find the code in memory, would page fault, which would cause it to be suspended again and cause a page-in operation on the page that was to be executed. Only then would it launch successfully.
The same is basically true for any task that is launched by the scheduler that was interrupted on a page fault that has not been served up to then, data or code doesn't matter.
I have one question: Do you plan to make AmigaGuide or HTML format version of Autodocs from Software Developer Kit for AmigaOS 4? For now they are only in plain text format. Or can you give permission to place the documentation in such format? Or the Wiki is to be the only place where the updated documentation is placed?
I have one question: Do you plan to make AmigaGuide or HTML format version of Autodocs from Software Developer Kit for AmigaOS 4?
Yes of course. However, I don't consider it a priority. The real meat of the documentation is what is not in the autodocs and includes. That is the stuff people also don't want to write because it is difficult.
My goal is to automate the generation of the autodocs and have them uploaded to the server automatically. When that is working you'll find them on the official site as well. But again, that is the easy part.
tfrieden wrote: Private memory, on the other hand, is supposed to be accessed only by the application allocating it. As such, it is allocated in an unlocked state by default since the MEMF_PRIVATE has to be explicitly given, and the application is supposed to "know what it's doing".
Is it OK to allocate MEMF_PRIVATE memory, and then pass it to a library? I've never been quite clear on whether libraries are classed as separate processes.
Is it OK to allocate MEMF_PRIVATE memory, and then pass it to a library? I've never been quite clear on whether libraries are classed as separate processes.
Libraries are just code. They run on the task / process that caled the code. so something MEMF_PRIVATE could be passed to the library as it's being called in your own task/ process.
so something MEMF_PRIVATE could be passed to the library as it's being called in your own task/ process.
Unless of course the library decides to spawn it's own task/process, such as I imagine the asyncio.library does... But I guess this isn't very common, and arguably it should be up to the library to either document this requirement or (better) copy the supplied data into memory that is sharable.
broadblues wrote: Libraries are just code. They run on the task / process that caled the code. so something MEMF_PRIVATE could be passed to the library as it's being called in your own task/ process.
OK, cool, that's what I thought (otherwise MEMF_PRIVATE memory would be almost useless) but good to have it confirmed.
Is it OK to allocate MEMF_PRIVATE memory, and then pass it to a library? I've never been quite clear on whether libraries are classed as separate processes.
As has been said, MEMF_PRIVATE means private to the process. If it is not accessed outside of the process, it's OK.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
