Move away from Akka HTTP in favor of some more lightweight library

[bhermann]

Is your feature request related to a problem? Please describe.
The use of Akka HTTP currently prevents us of compiling the CLI down to native code using GraalVM. Despite the fact that the CLI currently works fine, it could be much faster which helps in automating query tasks.

Describe the solution you'd like
Use a light weight http client that can be used in a GraalVM build.

Describe alternatives you've considered
none

Additional context
none

[hariharansrc]

Change DelphiCli.scala based on suggestion oracle/graal#370

[hariharansrc]

Using GraalVM-1.0.0-rc10 for --allow-incomplete-classpath option

[hariharansrc]

Override default java options in sbt using set command.

set javaOptions := Seq("-Djava.lib.path=/usr/lib/jvm/default-java/lib/","-Djavax.net.ssl.trustStore=/usr/lib/jvm/default-java/lib/security/cacerts")

[hariharansrc]

Using environmental variable

• JAVA_LIB_PATH
• JAVA_TRUSTSTORE

[hariharansrc]

• Run graalvm-native-image:packageBin to package
• Execute commands using ./delphi-cli search "[dstore_1 (opcode:72)]<1"

[hariharansrc]

Default delphi client results

 Performance counter stats for './delphi-cli search [dstore_1 (opcode:72)]<1' (10 runs):

       6023.415951      task-clock (msec)         #    2.029 CPUs utilized            ( +-  0.51% )
             5,450      context-switches          #    0.905 K/sec                    ( +-  1.16% )
               488      cpu-migrations            #    0.081 K/sec                    ( +-  2.80% )
            48,341      page-faults               #    0.008 M/sec                    ( +-  0.21% )
   15,39,63,38,853      cycles                    #    2.556 GHz                      ( +-  0.50% )  (49.83%)
   14,25,93,68,246      instructions              #    0.93  insn per cycle           ( +-  0.29% )  (62.45%)
    2,74,66,57,930      branches                  #  455.997 M/sec                    ( +-  0.32% )  (62.33%)
      10,80,12,738      branch-misses             #    3.93% of all branches          ( +-  0.27% )  (62.56%)
    4,28,59,17,118      L1-dcache-loads           #  711.543 M/sec                    ( +-  0.59% )  (62.60%)
      28,20,08,742      L1-dcache-load-misses     #    6.58% of all L1-dcache hits    ( +-  0.43% )  (62.69%)
       6,17,23,160      LLC-loads                 #   10.247 M/sec                    ( +-  0.67% )  (50.09%)
       1,44,40,681      LLC-load-misses           #   23.40% of all LL-cache hits     ( +-  1.01% )  (49.90%)

            2.9691 +- 0.0206 seconds time elapsed  ( +-  0.69% )

[hariharansrc]

Native delphi cli results

Performance counter stats for './delphi-cli search [dstore_1 (opcode:72)]<1' (10 runs):

         47.173724      task-clock (msec)         #    0.127 CPUs utilized            ( +-  6.67% )
                18      context-switches          #    0.371 K/sec                    ( +-  7.44% )
                 2      cpu-migrations            #    0.032 K/sec                    ( +- 31.82% )
             4,170      page-faults               #    0.088 M/sec                    ( +-  0.09% )
       6,75,64,042      cycles                    #    1.432 GHz                      ( +-  7.88% )  (45.05%)
      12,07,66,606      instructions              #    1.79  insn per cycle           ( +-  5.98% )  (61.50%)
       2,18,85,776      branches                  #  463.940 M/sec                    ( +-  3.97% )  (67.20%)
          1,73,236      branch-misses             #    0.79% of all branches          ( +- 10.09% )  (68.53%)
       1,98,86,279      L1-dcache-loads           #  421.554 M/sec                    ( +-  4.30% )  (69.32%)
          9,45,189      L1-dcache-load-misses     #    4.75% of all L1-dcache hits    ( +-  2.51% )  (65.94%)
          1,27,342      LLC-loads                 #    2.699 M/sec                    ( +- 10.39% )  (43.12%)
            56,160      LLC-load-misses           #   44.10% of all LL-cache hits     ( +- 14.75% )  (40.84%)

            0.3726 +- 0.0318 seconds time elapsed  ( +-  8.54% )

[johannesduesing]

I've looked through the current codebase regarding this issue. While it does look resolved, ie Akka HTTP has been replaced by com.softwaremill.sttp.core, there are some things i cannot quite make sense of:

• http4s-dsl, http4s-blaze-client and http4s-circe are referenced in the build file but do not seem to be used
• In the DelphiCLI.scala main method there is commented out code (see snippet below) that sets the attributes java.library.path and javax.net.ssl.trustStore. It says that "[..] is only allowed for GraalVM compiles". Obviously, this code is not used at the moment and could therefore be removed, but i am unsure as to why it is needed and to what extent we want to support GraalVM. @bhermann what is your opinion on that?

delphi-cli/src/main/scala/de/upb/cs/swt/delphi/cli/DelphiCLI.scala

Lines 32 to 40 in 593288e

	def getEnvOrElse(envVar: String, defaultPath: String) = sys.env.getOrElse(envVar, defaultPath)
	val javaLibPath = getEnvOrElse("JAVA_LIB_PATH", "/usr/lib/jvm/default-java/lib/")
	val trustStorePath = getEnvOrElse("JAVA_TRUSTSTORE", "/usr/lib/jvm/default-java/lib/security/cacerts")
	// This only is allowed to be set for GraalVM compiles...
	//System.setProperty("java.library.path", javaLibPath)
	//System.setProperty("javax.net.ssl.trustStore", trustStorePath)

[bhermann]

I think we can safely remove unused dependencies from build.sbt. Right now, I think we shouldn't support a GraalVM native image release. Could you perhaps open an issue for consideration in the future to setup this pipeline?

[johannesduesing]

Closing this issue as it is done. Removed unused libraries and code (#47) and moved discussion for GraalVM to separate issue #48.