Differences in Info.plist

[matentzn]

I noticed that the Contens/Info.plist file looks quite a bit different from the old to the new. Did anyone try to do https://oboacademy.github.io/obook/howto/set-up-protege/#increase-memory-in-protege?

In particular, this stuff seems entirely missing:

<string>org.protege.osgi.framework.Launcher</string>
        <key>JVMClassPaths</key>
        <array>
            <string>bundles/guava.jar</string>
            <string>bundles/logback-classic.jar</string>
            <string>bundles/logback-core.jar</string>
            <string>bundles/slf4j-api.jar</string>
            <string>bin/org.apache.felix.main.jar</string>
            <string>bin/protege-launcher.jar</string>
            <string>bin/maven-artifact.jar</string>
        </array>
        <key>JVMVersion</key>
        <string>1.8+</string>
        <key>JVMOptions</key>
        <array>
            <string>-Dapple.laf.useScreenMenuBar=true</string>
            <string>-Xss16M</string>
            <string>-Xmx24G</string>
            <string>-Xdock:name=Protégé</string>
            <string>-DentityExpansionLimit=100000000</string>
            <string>-Dlogback.configurationFile=conf/logback.xml</string>
            <string>-Dfile.encoding=UTF-8</string>
            <string>-XX:CompileCommand=exclude,javax/swing/text/GlyphView,getBreakSpot</string>
        </array>
        <key>JVMArguments</key>
        <array/>
        <key>LauncherWorkingDirectory</key>
        <string>$APP_ROOT/Contents/Java</string>

Is this intended? Can we safely insert this stuff into Info.plist if we want to increase memory?

cc @gouttegd @hkir-dev

[gouttegd]

Can we safely insert this stuff into Info.plist if we want to increase memory?

You can insert it, it’s safe… but it won’t do anything!

The old macOS launcher used to extract the contents of Info.plist to pass arguments to the JRE. But since we seemingly don’t have the source code for that launcher (all that was ever committed to the repository was a compiled binary), I had to write a completely new launcher (so that it would work on both x86_64 and arm64). And my launcher does not read the Info.plist file (maybe I will improve it later so that it does, but that’s very low on my to-do list right now).

So the new launcher works by simply executing the run.sh script in Protégé.app/Contents/run.sh. It’s in that script that arguments to the Java virtual machine (e.g., -Xms??G) should be added.

[matentzn]

How would you increase the memory for Windows users?

[gouttegd]

No idea, I have not touched the Windows package. @hkir-dev is the lucky guy who got to deal with that.

My personal procedure would be to ① format the C:\ drive, ② install GNU/Linux, ③ install the platform-independent version of Protégé (relying on the JRE provided by your GNU/Linux distribution), ④ edit the run.sh script to amend the java command as needed. But I guess that’s not quite what you want. :p

[matentzn]

This sounds reasonable. In the absence of a tool that can reliably handle spaces in windows paths, a more platform independent config file for memory would probably be great.

This plist thing I think did do that job, as it simply amended the JVM call parameters with Xmx, Xms, etc..

It is out of the question to support the plist file in the new architecture of the runner?

[gouttegd]

Out of question? No. Unlikely to happen in this decade? Yes.

Apple seemingly only documents how to access the Info.plist dictionary from Objective-C or Swift, and I am not learning any of those languages just so that I can rewrite the launcher in them. I'm pretty sure it's possible in C, but without documentation that's going to take a while.

[matentzn]

Alright :) lets close this issue then

[gouttegd]

a more platform independent config file for memory would probably be great.

That would be a much better idea than using the macOS-specific Info.plist file, and something we can probably do without (too) much effort.

If we decide of a very simple configuration file format, like, say,

[jvm_options]
append=-Xmx24G
append=-Xss16M

then we can make use of such a file in the run.sh scripts used in the platform-independent, GNU/Linux, and macOS packages at least. We may also be able to do the same with the run.bat script used for Windows.

We could thus have a single set of instructions for how to increase the memory allocated to Protégé, that would work for all packages.

[matentzn]

I think this is a good idea for future releases! For this one here, @hkir-dev just needs to make sure that there is some way to increase memory on Windows! Thats it.

[gouttegd]

Random thoughts for a platform-independent configuration file (not necessarily for the upcoming 5.6.0 release!).

A pseudo-ini file with up to 4 sections, which could look like the following:

[classpath]
# A list of all the Jar archives to add to the classpath (one per line);
# translated into a single -cp jar1:jar2:jar3:... argument
bundles/guava.jar
bundles/logback-classic.jar
bundles/logback-core.jar
bundles/slf4j-api.jar
bin/org.apache.felix.main.jar
bin/maven-artifact.jar
bin/protege-launcher.jar

[jvm_options]
# Some “known options” for the JVM
# one per line with name=value syntax
max_heap_size=24G # translated into -Xmx24G
min_heap_size=2G # translated into -Xms2G
stack_size=16M # translated into -Xss16M

[properties]
# Java properties, one per line;
# each line translated into -Dname=value
logback.configurationFile=conf/logback.xml
file.encoding=UTF-8
apple.laf.useScreenMenuBar=true
com.apple.mrj.application.apple.menu.about.name=Protege

[extra_jvm_options]
# Non-standard JVM options, one per line;
# each line translated into -Xname=value
X:CompileCommand=exclude,javax/swing/text/GlyphView,getBreakSpot
dock:name=Protege
dock:icon=app/Protege.icns

Up then to the launcher to parse that file and to build the required command line to spawn the JVM with Protégé.

• On GNU/Linux and in the platform-independent package, this would be done by the run.sh script (this might require to assume that awk is present on the system, because parsing such a file in pure sh could be tricky).
• On macOS, this could either be done also in run.sh, or directly by the binary launcher that currently execs run.sh (in which case we would not even need run.sh anymore).
• On Windows, err, Error: Idea Not Found.

[gouttegd]

On second thought, I actually dislike my own proposal above…

The problem is that it mixes options that the user might legitimately want to change (such as the heap size) with options that are actually needed for Protégé to work correctly and that no user should ever modify (e.g. the classpath).

Better to keep the second class of options somewhere inside the launcher binaries or scripts (“out of reach” for most users except the most adventurous ones), and to have a simpler configuration file for the user-modifiable options. Maybe just:

max_heap_size=24G # translated to -Xmx24G
min_heap_size=2G # translated to -Xms2G
stack_size=16M # translated to -Xss16M
append=XYZ # intended to allow passing arbitrary options just in case; `XYZ` is simply appended to the JVM command line with no translation

[gouttegd]

Another thought: We should look for the configuration file somewhere in the user’s configuration directory first (on GNU/Linux, under $XDG_CONFIG_HOME; on macOS, under $HOME/Library/Application Support; on Windows, need to check what is the “standard” location – something like %APPDATA%… I think?), before looking into the directory where Protégé is installed. Users should not have to create or edit a file within the application’s installation directory.

[hkir-dev]

I think this is a good idea for future releases! For this one here, @hkir-dev just needs to make sure that there is some way to increase memory on Windows! Thats it.

In 5.6.0-beta-1 the Windows JVM options can be adjusted by editing the Protege.I4J.ini or editing the run.bat file as mentioned in wiki

[gouttegd]

We’ll need to update the wiki page after (or at the same time as) the 5.6.0 release to reflect how memory settings can now be set on macOS. When we do that, we can also fix an error in the Windows documentation:

-Xms200M -Xmx500M -Xss16M
Xmx is the one you want to edit (I would recommend you make a copy of the original file first). That specifies the maximum amount of memory Protege can use. Xms is the initial memory that will be allocated and Xss defines the increments used when allocating more memory.

The -Xss parameter is not the increment to the heap size. It has nothing to do with the heap. It is the stack size, it limits how deep the stack can get before we run into a StackOverflowError. I think most users would not actually need to touch that setting, unless they are using native plugins such as Fact++, apparently

[gouttegd]

It is out of the question to support the plist file in the new architecture of the runner?

Out of question? No. Unlikely to happen in this decade? Yes.

Well, this was a short decade after all… It turns out reading the info.plist file from a C launcher is not that hard (and the C API is documented, contrary to what I thought).

So for the sake of backward compatibility, I propose that the macOS launcher behave as follows:

• First, look for a file in $HOME/.protege/conf/jvm.conf; if that file exists, read the options from there and don’t look anywhere else (this will ultimately be the recommended way of setting the options, as it dispenses the user from having to modify anything within the application bundle itself).
• Second, look for a file in Protege.app/Contents/conf/jvm.conf; if that file exists, read the options from there and don’t look anywhere else (this is for the sake of completeness; can theoretically be useful on multi-users machines, to allow an administrator to set the memory settings once and for all for all users; not sure whether it’s actually useful since Apple computers are typically mono-user machines anyway…).
• Third, look into the Info.plist file within the application bundle for the JVMOptions array (this is the “legacy” method, that current users are already familiar with).

The jvm.conf file (either found in the user’s home directory or within the bundle) will use the syntax shown in my previous comment above. The Info.plist will use the same syntax as in the current version of Protégé:

<key>JVMOptions</key>
<array>
    <string>-Xmx8G</string>
    <string>-Xms200M</string>
</array>

[matentzn]

This is tear-sheddingly great.

[gouttegd]

Pet project for the Christmas break: a universal launcher for Protégé. This will allow to use a single code for GNU/Linux, macOS, and Windows versions of Protégé, and thus to ensure a consistent behavior across platforms.

With that launcher, all 3 versions will be able to use the jvm.conf mechanism (including the Windows version), but the macOS and Windows versions will also support their respective “legacy” configuration mechanism (Info.plist for macOS and Protege.l4j.ini for Windows).

The new launcher is in a pretty good shape already, it has been tested on Slackware Linux, macOS 13, and Windows 10. Further testing will be needed, but I think it can be ready in time for the 5.6.0 release.

[gouttegd]

Closing as the universal launcher mentioned in the previous message fixes everything that is discussed here.

We now have a mechanism to set Java options that is common to all variants of Protégé (the conf/jvm.conf file), and in additions, the mechanisms that existed in the previous macOS (Info.plist file) and Windows (Protege.l4j.ini file) variants are still supported.