OS/2, eCS & ArcaOS - Technical > Web applications

QT5 simplebrowser

<< < (4/44) > >>

Remy:

--- Quote from: Lars on November 13, 2020, 08:32:03 am ---Can someone enlighten me why I would use the new highmem at all ? It does the very same thing as all the highmems that already exist but potentially it does them faster.
But it is a one time action to mark DLL code (and data) segments to load high. The change is persistent. You do not do it over and over again.

--- End quote ---

"The change is persistent."  Sure it is

'You do not do it over and over again.'  right, One time is enough

As you know, there is an issue into OS/2. When an application loads the dlls above 512 and when the application is closed, the dlls are unloaded but the corresponding memory range is than unusable... To prevent this, having an alltime active background process just loading the highmem dlls prevents the dlls to be unloaded and preserves the high storage space.   

Lars:

--- Quote from: Dave Yeo on November 13, 2020, 09:15:57 am ---For me, it's just the utility I'm used to to do the marking. Qt5WebC.dll is 243 MBs in size and it seemed to be a candidate to be marked high. I did first run it on my ram drive, formatted as HPFS and marking it high worked. After a trp and losing my ram drive due to having use the power button to reboot, I tried it on a JFS volume and it would hang the system.

--- End quote ---

I see, but this is not a bug introduced by the use of the highmem tool but rather a bug in the OS memory management to properly deal with module objects (code or data) loaded into high memory which, at least from what you are reporting, even relates to the module loading process (where a file is read from disk and its contents loaded into memory).

Was the JFS volume a volume on a hard disk or also on the RAM drive ? If it was on the hard disk, that is really intimidating as it would indicate that even the IFS can introduce a problem in module load. If it was on a RAM drive, I'd more suspect that the RAM drive's use of memory (doing all those tricks to make memory above the 4GB physical address boundary accessible) interferes with the OS's provision of high memory.

All the highmem tools do the same: set some bits in the executable header that set segment properties.

Roderick Klein:
Older versions of highmem.exe read the complete DLL when changing the DLL. And it seems this happens on JFS volumes the system hangs.
The new version of highmem fixes this as it only needs to modify the first part of the binary.

Dave Yeo:

--- Quote from: Roderick Klein on November 13, 2020, 01:12:27 pm ---Older versions of highmem.exe read the complete DLL when changing the DLL. And it seems this happens on JFS volumes the system hangs.
The new version of highmem fixes this as it only needs to modify the first part of the binary.

--- End quote ---

Exactly. the hang was on a JFS formatted hard drive partition when it was reading in the DLL to mark it. I've seen the same behaviour marking xul.dll but more sporadically and often a crtl-c would kill the highmem process.

Dmitriy Kuminov:
Hey, just my few cents. Stuff in /test is surely not for general public. So no bug reports etc. are accepted for that. The new highmem fixes some nasty bug in DosRead on JFS which hangs the system if an app tries to load a few hundred megabytes in one go. It's available in the exp repo as RPM now BTW. And you should NOT mark LIBCN0.DLL or LIBCX0.DLL for loading high — it will break virtually everything on your system.

As for the rest, Chromium behaves really faster and smoother here than Firefox in many situations (especially on heavy JS sites) and in general produces lesser CPU load. YouTube playback is slow not because of JS slowness or such, it's because of some incorrect time scale interpretation somewhere on the pipeline, it's just "ticks" 1 ms per 1 s or so. HTML5/JS animations themselves run in the right time scale (e.g. on qt.io). To be sorted out. But again, this is not for general use yet (although it already can do what FF can not since long - e.g. visiting online banking sites etc.). Please stay tuned and consider a donation to BWW if you want to see it ready for general use.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version