Page 1 of 1

ExtMemObjects...Window vs Actual...

Posted: Sat Sep 09, 2017 8:44 pm
by Belxjander
I'm trying to deal with ExtMemObj's that are outside the normal 2GB addressable memory limit while using a limited size window for what is mapped.

If I allocate 64MB or 128MB and decide to use it as a remap window for a beyond 2GB addressable area that is a multiple of the window size (128MB access window into 1GB allocated for example....)

I'm trying to work out if this is even practical within the current mechanisms of the ExecNG Memory Management.

I do know that this will seem somewhat strange but it is required for the way I am currently dealing with non-native ELF and other Executable formats.

locally mapping the allocations is okay so far but when I am dealing with memory locations I can't safely access without a whole window-size=allocation-size I quickly run out of memory before the application proceeds.

I was thinking of an ExtMemObj handle with some means of walking the memory it refers to in window-size steps and accessing things that way.

maybe there is something I'm missing when reading ExtMemObj usage?

I'm trying to workaround DLL loading limitations without introducing too many fake DLLs or loading DLLs recursively until memory is exhausted.

Re: ExtMemObjects...Window vs Actual...

Posted: Sun Sep 10, 2017 1:18 pm
by chris
You can map parts of extended memory objects. See the documentation for Map() - ... 153#p35042

Re: ExtMemObjects...Window vs Actual...

Posted: Mon Sep 11, 2017 4:45 am
by Belxjander
chris wrote:You can map parts of extended memory objects. See the documentation for Map() - ... 153#p35042
Well THAT solves my memory virtualization issue with size and location,
I'll just need to deal with resource tracking so many ExtMemObj's (one per object loaded and I will need them ALL sharable)

Now the only limit I have for testing is to get access to a machine with more than 4GB of memory and ExtMemObj support enabled
or to find a PCI card that can provide 4GB or more memory as one of it's functions to slot into my sam440flex to provide the ExtMemObj space to work in.

because I definitely need to stress test with multiple load objects trying to cross-access between virtualizations now
so I can debug the EFFI and XFFI mechanisms (E for Entry and X for Cross-Calling...)

they are sketched into place but definitely require debugging, something still doesn't feel right in that code and that always irrationally irritates me until it is proven stable and working/usable.

But the way map is described certainly makes sense for scatter/gather windowing into IO throughput data,
at least for my first impression, Device drivers can simply allocate a window and then Map each scattered block into a locally contiguous block which is then written as a sequential setup before unmap and release...
If I'm reading that autodoc update right...
as long as all the data is in ExtMemObj memory spaces at least.