Jump to content

The 16bit heaps expander thread


Recommended Posts

Not fair to spoil exectations, but i'm here again with some news.

New USER salvation is delayed due to my work on KernelEx 4 (finally) as well as other busy things.

The news, i've figured out how to theoretically implement GDI heap expander without breaking compatibility, performance and memory usage. This includes a lot of things to hax: global memory manager, local heap handle manager and GDI insides, but seems possible unless I bump into hard compatibility problems.

But theoretically, it can be very-very promising; i won't spoil numbers.

Or did rloew already implemented one?

That's all great news Tihiy.

I might be wrong but I don't think rloew is into an heap expander at all as he's mentioned ongoing research into 512 MB graphic card and multiprocessor support and did not answer a question aboit a heap expander I made to him sometimes ago.

Link to comment
Share on other sites


Not fair to spoil exectations, but i'm here again with some news.

New USER salvation is delayed due to my work on KernelEx 4 (finally) as well as other busy things.

The news, i've figured out how to theoretically implement GDI heap expander without breaking compatibility, performance and memory usage. This includes a lot of things to hax: global memory manager, local heap handle manager and GDI insides, but seems possible unless I bump into hard compatibility problems.

But theoretically, it can be very-very promising; i won't spoil numbers.

Or did rloew already implemented one?

That's all great news Tihiy.

I might be wrong but I don't think rloew is into an heap expander at all as he's mentioned ongoing research into 512 MB graphic card and multiprocessor support and did not answer a question aboit a heap expander I made to him sometimes ago.

I haven't been working on the Resource problem in a while. Early analysis showed that there is no central block of code that handles them. It appears that many if not all particular Resources are coded individually. I haven't worked with 16-bIT Thunks, so it would take me a lot longer to identify and Patch all of the code that handles Resources. Even Patching one Resource at a time would not be easy since I don't know an easy way of determining all of the pathways to a given Resource.

I have only been looking at the 512MB Graphics Card issue for a matter of days. So far only one person has contacted me about testing.

I have thought about making use of Multiple Pocessors or Cores but only under Program Control, not the OS. I have not done the research or written any code yet.

Link to comment
Share on other sites

  • 1 month later...

I'm back with news, and news are not bad: a functional alpha version of GDI extender was created.

My theory of decoupling handles from objects seems applicable (although there were lot of problems to make friends with GDI).

For now, only one type of object is extended: DIB bitmap. DIB bitmaps are actively used in a lot of programs (unfortunately, most leaky programs like Foxs*** pdf reader, your card game, that VB tool are likely to use DDB bitmaps) and are very heavy (2 global memory objects + selector array). Applying extender on them allowed to increase best case object count from 1'200 to 12'000! That means you can potentially open 10 times more tabs in Opera 9. My favorite 3xImgBurn test showed twice resource usage drop, allowing me to open 6xImgBurn copies (with user heap extender alpha enabled too).

Performance hit is negligible - 5% max in tests on my VM.

So, wanna wanna wanna? I'm planning to include both technologies in Revolutions Pack 10 (with completely rewritten core).

Beta testing may be possible, but i'm not promising any time / deadline.

Edited by Tihiy
Link to comment
Share on other sites

I'm back with news, and news are not bad: a functional alpha version of GDI extender was created.

My theory of decoupling handles from objects seems applicable (although there were lot of problems to make friends with GDI).

For now, only one type of object is extended: DIB bitmap. DIB bitmaps are actively used in a lot of programs (unfortunately, most leaky programs like Foxs*** pdf reader, your card game, that VB tool are likely to use DDB bitmaps) and are very heavy (2 global memory objects + selector array). Applying extender on them allowed to increase best case object count from 1'200 to 12'000! That means you can potentially open 10 times more tabs in Opera 9. My favorite 3xImgBurn test showed twice resource usage drop, allowing me to open 6xImgBurn copies (with user heap extender alpha enabled too).

awesome, with this image not displaying in browser could be remedied somewhat.

the problem was like this:

browser just showing blank white image yet it said that image has been completely downloaded, but if you looking for image files in cache, you can view it just fine with (dos) image viewer.

So, wanna wanna wanna?
you bet!
Link to comment
Share on other sites

Nobody is interested?

Then i'll tell you how to increase GDI 32-bit heap now.

32-bit GDI heap is 2MB by default, that's pretty much; but, GDI actively utilizes this heap for storing small images and discarding DCs there. While it's not that easy to fill this heap, it is possible. With default 2MB heap worst case filling scenario would be ~200 48x48 images or ~5000 DCs (only likely if you're using leaky programs).

So it's good thing to increase GDI 32-bit heap size. It would be required for heap extender to go all-out, too.

Remember, this value is maximum size, not commited-at-once size. Don't ever set it smaller than 2MB.

You can change this value by adding line in win.ini section [windows]

[windows]

GDIMaxHeapSize=2048

(value in KB)

I would think of values like:

<128MB of RAM: 4096 (4MB)

128-256MB of RAM: 8192 (8MB)

256-512MB of RAM: 16384 (16MB)

>512MB of RAM: 32000 (~32MB, maximum value you can set).

Not likely you often run into this limit, but this knowledge is nice to recall.

Link to comment
Share on other sites

...

So, wanna wanna wanna?...

I second that! - Yes, yes, yes!

GDI heap extender and User heap extender will be awesome!

RP10 will be some pack indeed!

BTW, nice tip about how to increase the GDI 32-bit heap.

Edited by RetroOS
Link to comment
Share on other sites

Tihiy, you know I'm always interested in testing/using such enhancements. You can count on me for alpha/beta testing at any time. Just use PM for details/links since I'm no longer using instant messaging.

Link to comment
Share on other sites

@Tihiy: Supposedly, you can also go to HKEY_CURRENT_USER/Control Panel/Desktop/ and create the string value USERMaxHeapSize there, to control the max 32-bit USER heap size. While USERMaxHeapSize indeed exists inside USER.EXE, what I always found strange is: (i) why the control for USER is inside the registry, while the one for GDI is at WIN.INI?; (ii) why is it a string and not a DWORD or binary value? (iii) why WIN.INI instead of SYSTEM.INI?

It occurs to me that they may be alternative places, and that using both in the indicated place at the resgistry or both in WIN.INI would work the same, but, if so, why? Moreover, why, before you mentioned it, I'd only found these settings in french sites, which apparently cite one another (this one, for instance)? I know, I know... that's too many questions! :blushing: But I just wasn't able to resist posing you them since you wrote about GDIMaxHeapSize.

And, yes, yes, yes! You can count on me too to alpha/beta test, whenever you want it.

@Drugwash: Have you given Miranda up? :blink: I see you've purged it from your sinature too! What happened?

Link to comment
Share on other sites

Applying extender on them allowed to increase best case object count from 1'200 to 12'000! That means you can potentially open 10 times more tabs in Opera 9.

:w00t:

Nobody is interested?

Come on, Tihiy ... We are all waiting for this ...

Link to comment
Share on other sites

I have been experimenting a bit with GDIMaxHeapSize and USERMaxHeapSize.

Setting a value for GDIMaxHeapSize in win.ini results in DrWatson reporting after reboot that <unknown> has altered Windows system files. In the Patches tab it says that the module display has been patched in memory by <unknown>.

Setting a value for USERMaxHeapSize in either the registry as indicated or in win.ini in the same section as GDIMaxHeapSize yelds nothing that I can see.

Link to comment
Share on other sites

<unknown> has altered Windows system files.
RP9 causes this message, it's not related.

And i must confirm other sites, GDIMaxHeapSize is in win.ini while USERMaxHeapSize is in registry. That's how it is.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...