Author Topic: Apache OpenOffice 4.1.1 RC3  (Read 83754 times)

Lewis Rosenthal

  • Jr. Member
  • **
  • Posts: 88
  • Karma: +5/-0
    • View Profile
    • Tales from the Trenches of IT
Re: Apache OpenOffice 4.1.1 RC3
« Reply #30 on: August 23, 2014, 07:52:19 pm »
Code: [Select]
for %a in (*.dll) do highmem -b %a

(highmem does not accept wildcards).

Hrm? For me it does.

That's odd, isn't it. Perhaps I didn't try a wildcard with the parameter, and only highmem * to get a report of status. I'll try again when the time presents itself. Thanks for letting me know.

However, upon closing the last of them, my system trapped (000e).

Do you use the latest kernel (14.106_SMP)?
The bug with trapping on unload of DLLs loaded high has been fixed in 106.

Ah, no. I've been moving between kernels quite a bit recently, and am currently using 14.105_W (this is a ThinkPad T43 with a 2.26GHz Dothan, single core). I planned on swapping in the 14.106_W kernel soon, so it looks like a good time.

It will take me a bit of experimenting to determine just which ones should get loaded high (likely the biggest ones, though the little ones tend to fragment more when unloading, for obvious reasons), but the opportunity is there, at least.

When the first build of AOO4 came up, I've got it running well with DLLs loaded high as well, and I simply did highmem *.dll in all directories where I found any DLLs (it's not the `program' one only).

By the way, I also run with all Qt4 DLLs loaded high (the webkit one is pretty huge, heh), with no apparent problem.

Good to know, Boris; thanks. I'll do some more experimenting, but I've certainly gotten a lot farther along than I did with 4.0.

Cheers
Lewis
-------------------------------------------------------------
Lewis G Rosenthal, CNA, CLP, CLE, CWTS
Managing Member
Arca Noae, LLC                               www.arcanoae.com

David McKenna

  • Hero Member
  • *****
  • Posts: 743
  • Karma: +24/-0
    • View Profile
Re: Apache OpenOffice 4.1.1 RC3
« Reply #31 on: August 23, 2014, 08:06:51 pm »
 Using the HIGHMEM utility on my OpenOffice \program directory made a HUGE difference. I used 'highmem -b *.dll' from the command line and so far all apps always start, I have not had any traps (using Kernel 14.106) nor have I been able to get the WPS to crash anymore.  So good I went to try it on SeaMonkey, but SeaMonkey wouldn't start afterwards, so I undid the highmem setting and re-tried with 'highmem -c *.dll'. That worked great (not sure why the difference). I need to study this little gem some more....

Joop

  • Hero Member
  • *****
  • Posts: 633
  • Karma: +5/-0
    • View Profile
Re: Apache OpenOffice 4.1.1 RC3
« Reply #32 on: August 23, 2014, 08:18:24 pm »
I used 'highmem -b *.dll' , 'highmem -c *.dll'. That worked great (not sure why the difference).
Hi David,
usage: HIGHMEM [-options] {DLL module file} ...
Without options, current DLL object information are dumped.
Options:
 --quiet   -q  quiets (no message)
 --verbose -v  verbose output (-v -v even more verbose)
 --code    -c  marks pure 32bit code objects as 'loading above 512MB'
 --data    -d  marks pure 32bit data objects as so
 --both    -b  marks both of pure 32bit code and data objects
 --unmark  -u  unmarks 'loading above 512MB' pure 32bit code/data objects
 --exclude -x file  list of files to be excluded (max 1024 entries
 --help    -?  show this help

Got it form highmem-20140406-os2.zip.

David McKenna

  • Hero Member
  • *****
  • Posts: 743
  • Karma: +24/-0
    • View Profile
Re: Apache OpenOffice 4.1.1 RC3
« Reply #33 on: August 23, 2014, 08:47:42 pm »
Joop,

  Yes... I saw that and that is why I tried the -c switch. But why does -b work on OpenOffice but not SeaMonkey? SeaMonkey DLL's have both code and data segments according to highmem -v...

  I have also now loaded all the XCenter plugin DLL's high... even more free shared memory!

dbanet

  • Guest
Re: Apache OpenOffice 4.1.1 RC3
« Reply #34 on: August 23, 2014, 09:21:18 pm »
Joop,

  Yes... I saw that and that is why I tried the -c switch. But why does -b work on OpenOffice but not SeaMonkey? SeaMonkey DLL's have both code and data segments according to highmem -v...

  I have also now loaded all the XCenter plugin DLL's high... even more free shared memory!

Actually very close to all of existing application DLLs may be loaded high. This option should be considered stable and used extensively.

guzzi

  • Sr. Member
  • ****
  • Posts: 331
  • Karma: +0/-0
    • View Profile
Re: Apache OpenOffice 4.1.1 RC3
« Reply #35 on: August 23, 2014, 10:15:50 pm »
Joop,

  Yes... I saw that and that is why I tried the -c switch. But why does -b work on OpenOffice but not SeaMonkey? SeaMonkey DLL's have both code and data segments according to highmem -v...


Don't know about seamonkey, but in FF24 only xul.dll will fail with data segments loaded high. According to the testing I've done loading data segments high does not yield much extra free shared low memory.

I also have odin and java load high. (except user32.dll and WINMM.dll, which will give problems with java when loaded high). It would be nice if developers would have rpm/yum package with modules already marked high)

David McKenna

  • Hero Member
  • *****
  • Posts: 743
  • Karma: +24/-0
    • View Profile
Re: Apache OpenOffice 4.1.1 RC3
« Reply #36 on: August 23, 2014, 11:04:23 pm »

Actually very close to all of existing application DLLs may be loaded high. This option should be considered stable and used extensively.

  Yes... I am beginning to understand that. It brings up a new question: when should 'shared memory' be used and when 'high memory'? What are the advantages and disadvantages? Is 'shared memory' for shared code? If so, it would seem like QT, Java and Odin would be better off staying in shared memory. If they are loaded high, are they not shared among different apps? I'm just trying to get my head around how this dual memory concept is supposed to be used....

dbanet

  • Guest
Re: Apache OpenOffice 4.1.1 RC3
« Reply #37 on: August 24, 2014, 02:24:03 am »

Actually very close to all of existing application DLLs may be loaded high. This option should be considered stable and used extensively.

  Yes... I am beginning to understand that. It brings up a new question: when should 'shared memory' be used and when 'high memory'? What are the advantages and disadvantages? Is 'shared memory' for shared code? If so, it would seem like QT, Java and Odin would be better off staying in shared memory. If they are loaded high, are they not shared among different apps? I'm just trying to get my head around how this dual memory concept is supposed to be used....

There are (DISCLAIMER: this is how I understand and what I know, I may be highly inaccurate, or even completely wrong! Think on your own!) generally four user memory arenas: low (<512 MiB) private and shared and high (>=512 MiB) private and shared ones. Yes, shared memory is for shared objects like DLLs, which are Qt (it's spelled Qt, not QT) and Odin (partly).

Dividing memory on low and high memory arenas make it possible to seamlessly run 16-bit applications, which is one of the greatest advantages of OS/2 (well, was?).

Low memory is also used for interaction with device drivers, as the current way it is organized limits it to low memory: the main driver code may be 32-bit, but some external parts of it must be 16-bit (it is possible it will get changed within the OS/4 project).

There are possibly some other places where low memory must be used, but that shouldn't be significant, as the amounts of memory used by system components are hardly comparable to the amounts used by modern applications like FFox or AOO.

When you mark a DLL as loadable high, it gets loaded to the high shared arena, which means that it's still shared, as well as that scarce low memory (limited to 512 megs minus amount of allocated low private memory) isn't wasted.
« Last Edit: August 24, 2014, 10:36:36 am by Boris »

dbanet

  • Guest
Re: Apache OpenOffice 4.1.1 RC3
« Reply #38 on: August 24, 2014, 02:27:41 am »
Don't know about seamonkey, but in FF24 only xul.dll will fail with data segments loaded high. According to the testing I've done loading data segments high does not yield much extra free shared low memory.

I also have odin and java load high. (except user32.dll and WINMM.dll, which will give problems with java when loaded high). It would be nice if developers would have rpm/yum package with modules already marked high)

It would be cool if you document your experience with loading DLLs into the high memory and the results you get (workability, stability) on the OS/2World Wiki.

David McKenna

  • Hero Member
  • *****
  • Posts: 743
  • Karma: +24/-0
    • View Profile
Re: Apache OpenOffice 4.1.1 RC3
« Reply #39 on: August 24, 2014, 03:05:12 am »
Thanks Boris! You have made it crystal clear...


There are (DISCLAIMER: this is how I understand and what I know, I may be highly inaccurate, or even completely wrong! Think by your own!)

  Well... of course, this should be the 'small print' on the entire Internet.. 8-D

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: Apache OpenOffice 4.1.1 RC3
« Reply #40 on: August 24, 2014, 04:41:56 am »
So where are people downloading the latest  highmem?

Lewis Rosenthal

  • Jr. Member
  • **
  • Posts: 88
  • Karma: +5/-0
    • View Profile
    • Tales from the Trenches of IT
Re: Apache OpenOffice 4.1.1 RC3
« Reply #41 on: August 24, 2014, 04:56:24 am »
So where are people downloading the latest  highmem?

Hey, Dave...

It should be the last item on the list, here:

https://www.dropbox.com/sh/350r8h2dpuxsg8w/AAAjVtD4f5_FaFghfUg_l6BYa/aoo

The source is included. Yuri has included his copyright 2012-2014, and the Apache license, and states that it is based on above512.

Cheers
Lewis
-------------------------------------------------------------
Lewis G Rosenthal, CNA, CLP, CLE, CWTS
Managing Member
Arca Noae, LLC                               www.arcanoae.com

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: Apache OpenOffice 4.1.1 RC3
« Reply #42 on: August 24, 2014, 05:40:42 am »
Thanks, that definitely helped SeaMonkey. For others, don't forget components/suite.dll.

Lewis Rosenthal

  • Jr. Member
  • **
  • Posts: 88
  • Karma: +5/-0
    • View Profile
    • Tales from the Trenches of IT
Re: Apache OpenOffice 4.1.1 RC3
« Reply #43 on: August 24, 2014, 09:57:41 pm »
Code: [Select]
for %a in (*.dll) do highmem -b %a

(highmem does not accept wildcards).

Hrm? For me it does.

Indeed, it does. As I mentioned, the help text is misleading, as:

Code: [Select]
[j:\] highmem *.dll

would appear to list the status of the tested modules, yet only reveals:

Code: [Select]
Processing module : <module>

instead, it is necessary to use the -v switch (or any other switch). Oddly though, my first time around, I got an actual error, so there must be another highmem which was in %PATH% getting picked up, I guess.

However, upon closing the last of them, my system trapped (000e).

Do you use the latest kernel (14.106_SMP)?
The bug with trapping on unload of DLLs loaded high has been fixed in 106.

Well, switching to 14.106_W4 got me the same trap. Changing the flag to only load the code high seems to have resolved it (I think).

Thanks again.
Lewis
-------------------------------------------------------------
Lewis G Rosenthal, CNA, CLP, CLE, CWTS
Managing Member
Arca Noae, LLC                               www.arcanoae.com

guzzi

  • Sr. Member
  • ****
  • Posts: 331
  • Karma: +0/-0
    • View Profile
Re: Apache OpenOffice 4.1.1 RC3
« Reply #44 on: August 25, 2014, 12:10:50 am »

It would be cool if you document your experience with loading DLLs into the high memory and the results you get (workability, stability) on the OS/2World Wiki.

I wrote a how-to but have no idea how to add it to the wiki. I am not familiar with HTML. I have it as an odt file. Any volunteers to proof read / edit  / add it to the wiki?
« Last Edit: August 25, 2014, 12:30:22 am by guzzi »