OPAL-Project/Lobby

Discussion of all aspects related to the OPAL library (www.opal-project.de)

Michael Reif

@mreif

Good :-)

Alexander Gössl

@majestocx

@florian-kuebler I implemented your snippeet about the call graph. I have org.opalj.fpcf.EOptionP[org.opalj.br.DefinedMethod,org.opalj.br.fpcf.cg.properties.CallersProperty]. Is there a method to get from that to an svg?

Florian Kübler

@florian-kuebler

Unfortunately, the answer is no

Alexander Gössl

@majestocx

Alexander Gössl

@majestocx

Is it possible to get the TAC from a class inside the jdk ? Like java/lang/String ?

Florian Kübler

@florian-kuebler

If the JDK is part of the project, it works just as for any other class. The File constant org.opalj.bytecode.RTJar, is the File of the current Java Runtime.

Alexander Gössl

@majestocx

Ok thanks for the information @florian-kuebler. I tried to get the TAC but method.body seems to be None. The jdk is part of the Analysis and libraryClassFilesAreInterfacesOnly is set to false.

Michael Eichberg

@Delors

How do you load the library? The method body should only be None if the method doesn’t have one (native or abstract) or if it is discarded while loading it. BTW libraryClassFilesAreInterfacesOnly actually doesn’t change how the classes are loaded - it basically reflects how the classes are expected to be loaded. That is, it might be possible that the “discarding" loader was used but libraryClassFilesAreInterfacesOnly is still false.

Alexander Gössl

@majestocx

Ok i will check wether the method is native / abstract. This is how the librarie is loaded:

val libraryClassFiles = Java9LibraryFramework.AllClassFiles(opalInit.libraries.map(new File(_)) :+ org.opalj.bytecode.RTJar )

Michael Eichberg

@Delors

ok…. Java9LibraryFramework kills the method bodies

you should use the “normal” Java9Framework

it is interessting that libraryClassFilesAreInterfacesOnly is false … there is clearly some issue somewhere!

Alexander Gössl

@majestocx

Ok now my Tests need some extra Memory but i still get the same exception:

nfo] - Load Project with jdk and libraryClassFilesAre not InterfacesOnly FAILED
[info] "java.util.NoSuchElementException: None.get
[info] at scala.None$.get(Option.scala:366)
[info] at scala.None$.get(Option.scala:364)
[info] at org.opalj.tac.TACNaive$.apply(TACNaive.scala:70)
[info] at org.opalj.tac.ToTxt$.$anonfun$apply$9(ToTxt.scala:319)
[info] at scala.Option.getOrElse(Option.scala:138)
[info] at org.opalj.tac.ToTxt$.apply(ToTxt.scala:318)
[info] at opal.extension.vscode.OPALProject.$anonfun$getTacForClass$2(OPALProject.scala:124)
[info] at opal.extension.vscode.OPALProject.$anonfun$getTacForClass$2$adapted(OPALProject.scala:116)
[info] at org.opalj.collection.immutable.RefArray.foreach(RefArray.scala:289)
[info] at opal.extension.vscode.OPALProject.getTacForClass(OPALProject.scala:116)

Michael Eichberg

@Delors

First - have you tried using the AI based variant of the TAC instead of TACNaive? If the first one works, it is a bug in the latter :-)

If does work with TACAI but doesn’t work with TACNaive can you tell which class causes the troubles?

Alexander Gössl

@majestocx

Unfortunately it does not work with both options...

The error occurres at the TACNaive.scala at Line 70: val code = method.body.get (body is None)

Michael Eichberg

@Delors

Hi Everybody, I just wanted to let you know that I just updated all subprojects to make them compatible with Java 11. That is, all projects can now be compiled and run on Java 11. Furthermore, Hermes (Core) doesn’t have any relevant JavaFX dependencies anymore. Given that all JavaFX libs are pulled from Maven, it should now be possible to build all of OPAL even in headless settings. (Of course, executing the Hermes UI requires a proper/complete JavaFX installation.)

BTW If you want to run the Hermes UI, don’t use the Eclipse J9 JVM - at least I didn’t get it working.

Ben Hermann

@bhermann

That is great! Especially the headless option is very helpful for me! Thank you!

mariotrageser

@mariotrageser

Bildschirmfoto 2019-05-04 um 14.33.55.png

Michael Eichberg

@Delors

Hi - such a bug may happen if you use the same (fully qualified) class name in different projects.

mariotrageser

@mariotrageser

When IntelliJ tries to compile OPAL, I get this error since one week.
I have to remove the sub modules „Demos“ and „Validate“ from the project every time. They seem to be duplicates of „OPAL-Developer Tools“ and „OPAL-Validate“. Did you change the project structure in the last days?

Michael Eichberg

@Delors

yes I did

you may have to reimport everything

mariotrageser

@mariotrageser

Ok, I try to do so. Thank you

Are Demos and Validate the new projects, which replace the two others?

Michael Eichberg

@Delors

Not exactly

Demos exists “forever"

OPAL-Validate => Validate

mariotrageser

@mariotrageser

I meant Tools and OPAL-Developer Tools. So „OPAL-Developer Tools“ should also no longer exist?

Michael Eichberg

@Delors

OPAL-DeveloperTools => Tools

Yes

mariotrageser

@mariotrageser

I had to remove them manually, but now everything works. Thank you

Javor Nikolov

@bubbazz

there is a way to get the current program counter from the classes "SimpleBranchInstruction" and "LOOKUPSWITCH".

Michael Eichberg

@Delors

No - this information is generally only implicitly available. If you use Code’s iterate and foreach methods you are always provided with the current pc. Does this help? If not, can you provide us with a short sample?

ewontfix

@ewontfix

Is there an easy way to get all primitive expressions (expressions which don't contain subexpressions) which occur in a TAC Stmt? Stmt.forallSubExpression seems to be a bit overkill for this use case.

Michael Eichberg

@Delors

In general, the TAC code is flat; i.e., a statement’s expressions are either Vars or Consts - that’s it. (OPAL has the ability to represent nested (sub) expressions, but this feature is reserved for future usage related to decompling code.) Hence, Stmt.forallSubExpression combined with a simple match over the two mentioned types of expressions should be sufficient in most to all cases. Does this help?

ewontfix

@ewontfix

Yes, thanks. My Code already works with Stmt.forallSubExpressions. It just takes somewhat longer than expected to execute and I guessed unnecessary exploring of a lot of intermediate expressions might be the cause. But if expressions are already flat, there is probably another cause.

Michael Eichberg

@Delors

One of the most frequent sources of performance isssues that I see when people use OPAL is the “naive” usage of Scala collections.

For example: val x = Set(..); x.filter(…).map(..).toList creates two intermediate sets before the list is finally created. Rewriting such code to avoid the creation of intermediate collections (e.g., by using foldLeft and withFilter) can lead to very significant performance improvements. But, this is only a wild guess given that I don’t know your code at all...

ewontfix

@ewontfix

To be more specific: I'm working on exercise 4 in APSA. My Analysis works for the provided AllocationFreeness class. But each time I run it against the whole JDK (rt.jar) it fails with an OutOFMemoryError after roughly 7 minutes. I stripped down my analysis step by step. Now I have reached a minimal bare-bones version, in which the analyze method immediately returns a Result. Still if I run this analysis against the JDK it fails with the same error. This is the complete code of my stripped down analyze method:

def analyze(method: DeclaredMethod): PropertyComputationResult = {
    if (!method.hasSingleDefinedMethod)
      return Result(method, MethodWithAllocations);

    if (method.definedMethod.isNative)
      return Result(method, MethodWithAllocations);

    return Result(method, MethodWithAllocations);
  }

ewontfix

@ewontfix

Here's the full diff against the provided template for this version:

44,45c44,45
<     allocationFreeMethods.map(_.e).mkString("allocation free: ", "\nallocation free: ", "\n")+
<     methodsWithAllocations.map(_.e).mkString("with allocations: ", "\nwith allocations: ", "\n")+
---
> //    allocationFreeMethods.map(_.e).mkString("allocation free: ", "\nallocation free: ", "\n")+
> //    methodsWithAllocations.map(_.e).mkString("with allocations: ", "\nwith allocations: ", "\n")+
65c65
<     ???
---
>     return Result(method, MethodWithAllocations);

Am I correct that at least this really minimal code should work?

roterEmil

@roterEmil

I had the same problem, that the analysis works on the given AllocationFreeness class but gets an OutOFMemoryError when running it against the JDK. When running the given template without my analysis against the JDK it also gets this error.

Michael Eichberg

@Delors

When you want to analyze the JdK you should at least allocate 6gb to the analysis! Depending on the concrete Analysis even much more memory may be required

David Kretzmer

@david-k_gitlab

Hi, I don't quite understand how to specify the entry points. In particular, what is the meaning of the Fact that must be associated with a DeclaredMethod in entryPoints?

Florian Kübler

@florian-kuebler

Without spoiling the solution:
The IFDS algorithm is a graph reachability problem, and the map of entrypoints specifices the starting points for the graph exploration.
More specific that are the Methods and Facts that are true before analyzing the methods. If these facts do not need to store any specific information, tautology facts are used.
Does that help?

Where communities thrive

People

Repo info

Activity