Remove QoS throttle on MacOS

[jogger]

We must reverse the change made by #1430, which lacked proper research.

Read everything here: ​https://arstechnica.com/gadgets/2013/10/os-x-10-9/13/

Long story short: The scheduler batches together activations of our threads. There are > 20ms pauses which can be seen as DELAYED on the /jobs page. Apps without a gui default to much lower scheduler priority even on an idle machine. taskinfo reports for i2p:

effective policy
	eff role: TASK_UNSPECIFIED (PRIO_DARWIN_ROLE_DEFAULT)
	eff latency qos: LATENCY_QOS_TIER_UNSPECIFIED
	eff thruput qos: THROUGHPUT_QOS_TIER_UNSPECIFIED

with a gui we get:

effective policy
	eff role: TASK_BACKGROUND_APPLICATION (PRIO_DARWIN_ROLE_UI_NON_FOCAL)
	eff latency qos: LATENCY_QOS_TIER_0
	eff thruput qos: THROUGHPUT_QOS_TIER_0

A short test with two threads looping endlessly over locking the same object confirmed this. 20% average CPU from the command line, 45% CPU when put into a Swing Hello World app.

Removing the awt.headless from the i2prouter script resulted in 30% more CPU allocated and less idle wakeups, so i2p was getting longer batches of runtime. Also saw a bit more traffic and more participating tunnels.

This is still not perfect, it just reduces the occurrence of those ultra-long pauses.

[zzz]

Assigning to meeh, who closed #1430. Also please fix the milestone in #1430 to the actual version the change was made. cc'ing zab as it may be helpful to have an a/b test on his test setup.

[jogger]

To judge differences you can use some totally undocumented top parameter to bring together CPU, idle wakeups and context switches:

top -stats pid,command,cpu,idlew,csw -o cpu -c d

[Meeh]

After a lot of testing and struggle, I've found a alternative to awt.headless - however it must then involve the "Start I2P Router.app" bundle, so it executes in the correct context with it's Info.plist.

The addition to the plist would be similar to the default run mode of the OSX I2PLauncher, "Agent mode".

<key>LSUIElement</key>
<string>1</string>

Apple docs on LSUIElement: ​https://developer.apple.com/documentation/bundleresources/information_property_list/lsuielement

[Meeh]

The "Start I2P Router.app" bundle is really just a shell script invoking "i2prouter start". And the bundle itself can be invoked by running "open Start\ I2P\ Router.app" (no GUI interaction) from the installation directory, so it's embeddable into our "i2prouter" and "runplain.sh" scripts, I'll have a look into how this can be done as clean as possible.

In "i2prouter"'s case it should in the case subcommand is start - figure out if it's in the bundle context, if not, invoke itself via the bundle and exit - while the bundle contexted one will do the actual start.

Objections, suggestions?

[Meeh]

I've not tested this yet, but there might be in-java-awt switches for this.

System.setProperty("apple.awt.UIElement", "true");
        java.awt.Toolkit.getDefaultToolkit();

Alternatively we could test this, but if it works and we'll add it to the source, where should this be added, opinions @zzz ?

[zzz]

@meeh I suggest you start by trying to reproduce the issue before you try to fix it

I also don't understand exactly what you did to fix 1430 or when that happened, could you research that?

I'm also confused by your comment 4. StartI2PRouter calls i2prouter, but you're proposing to reverse that and have i2prouter call StartI2PRouter?

It appears that OP's complaint is this change you made to i2prouter:

      94055174.. by 'meeh' 01/02/2015: # Mac OSX 10.10 requires the parameter bellow to run without a icon in the Dock.
                                     : if [ "`uname -s`" = "Darwin" ]; then
                                     :     export JAVA_TOOL_OPTIONS="-Djava.awt.headless=true"
                                     : fi
                                     : 

So I presume whatever fix you make would be in the same place?
The other place we try to set headless to true or false is in RouterConsoleRunner?, which is where we start DTG.

But you MUST start by trying to confirm or deny the OP's asssertion that this is a performance issue.