[PPL-devel] On the performance and expressiveness of the PPL java bindings

Enea Zaffanella zaffanella at cs.unipr.it
Wed Feb 27 13:22:53 CET 2013


On 02/25/2013 11:48 AM, Gianluca Amato wrote:
> Hi all,
> I am using the PPL library from Java (hmm.. Scala, actually) to make
> experiments on abstract interpretation based static analysis. I would
> like to share some considerations about a couple of aspects of the Java
> bindings which I believe could be improved.
>
> First aspect is performance. Obviously, using native libraries in the
> JVM always incurs a certain amount of performance penalty. I tried to
> develop a native implementation of Double_Box, and it is much faster
> than using the Double_Box fron PPL (the native implementation is not
> safe since I cannot control rounding mode within Java, but I do not
> think this impacts performance a lot). Obviously for more complex
> domains the overhead of calling native methods is proportionally lower.
>
> My question is: is it possible to improve performance of the Java
> bindings? I am not an expert in JNI, but from a fast scan of the code,
> it seems the Java code passes to the native methods an object. The
> native code calls some accessor function to get the ptr field (which is
> the pointer to the native PPL object). It should be possible to rewrite
> the native functions so that they receive directly the pointer, and
> therefore do not need to call the accessor methods. From what I have
> heard, calling accessor methods is slow. Has this approach been pursued
> and abandoned or not? Do you think it could produce a noticeable
> improvement in performance?

Hi Gianluca.

I think that the first thing to do is to get a precise idea of where 
these inefficiencies are produced. For this we need some experimental 
evidence. If you provide us with a small testcase, we can try and help 
you in identifying the key spots.

> The other point regards expressiveness. Java classes in PPL form a flat
> hierarchy. This makes difficult to write generic code, parametric w.r.t.
> the abstract domain. In C++ there is a flat hierarchy,  too, but there
> templates may be used to write generic code effectively. In Java, the
> only choices to write generic code are either to use reflection (which
> is quite costly) or to write thin wrappers over the PPL classes, and put
> wrappers in a hierarchy, (which is tedious). Who works in Scala may use
> macros, but in any case, writing generic code is cumbersome, and the
> model of a flat hierarchy is against standard Java best-practices.
>
> Would it be possible to define an interface which declares all the
> methods in common between the PPL domains? The domains could implement
> this interface. This would allow to write generic code by just
> exploiting the subclass relationship.

I guess it would be possible. The problem is that these similar looking 
interfaces are not exactly the same interface: some domains have 
different methods and a common interface would only be able to gather 
the common things, making the abstraction level less interesting.
Also, as you said, it is going to be a tedious/repetitive work (this is 
also worsened by the fact that we are not using the Java bindings on a 
daily basis). This said, if you are willing to have a go on it and want 
to make your generic interface publicly available, we might later 
consider integrating it in the PPL (and maybe add any missing machinery 
to support such an integration).

Enea.


> Sorry for the long mail. I am very interested to know the opinion of the
> PPL developer and users on this points.
>
> Cheers,
> --gianluca
>
> _______________________________________________
> PPL-devel mailing list
> PPL-devel at cs.unipr.it
> http://www.cs.unipr.it/mailman/listinfo/ppl-devel
>




More information about the PPL-devel mailing list