I want to use Uprobe in eBPF to trace the Java program I wrote, but I do not know how to find the symbol table corresponding to the Java program. In C language, platform-related executable files will be generated after compilation, and the corresponding address of the method can be obtained through the executable file.But Java is an interpreted language, there are no executable files, and eBPF is a Linux tool, do not know the Java language related information.I know that methods in the JVM can be traced using USDT, such as method__entry, but that doesn't give you information about the arguments to the methods, so is there a way to trace Java functions using eBPF?
BCC,using USDT to print a method flow graph in high-level languages.
Not a Java tracing expert, but I think that you need to look at perf-map-agent.
This is what Brendan Greggs mentions in his posts on perf and on CPU flame graphs, and I believe it applies to eBPF as well as perf. This post gives an example on how to call the tool from a container, to produce flame graphs with BCC tools.
Related
I want to develop a tool that performs certain optimizations in a program based on the program structure. For example, let's say I want to identify if-else within a loop, and my tool shall rewrite it into two loops.
I want the tool to be able to rewrite programs from a wide range of languages, example Java, C++, Python, Javascript, etc.
I am exploring if GraalVM can be used for this purpose, to act as the common platform in which I can implement the same optimizations for various languages.
Does GraalVM have a common intermediate representation (something like the LLVM IR)? I looked at the documentation but I am not sure where to get started. Any pointers?
Note: I am not looking for inter-operability between languages. You can assume that the programs I want to rewrite are written in one single language; the language may be different for different programs.
GraalVM has two components that are relevant for this:
compiler, which compiles Java bytecode to native code
truffle, which is a framework for implementing other programming languages on top of GraalVM.
Languages implemented with the Truffle framework get partially evaluated to Java bytecode, which is then compiled by the Graal compiler. This article/talk gives more details including the IR used by Graal compiler: https://chrisseaton.com/truffleruby/jokerconf17/. Depending on your concrete use case you may want to hook into Truffle, Truffle partial evaluator or Graal compiler.
I would like to write some pieces of code in Scala . It is important for me that this code can be called from matlab. AFAIK java code can easily be integrated with matlab. http://www.mathworks.co.uk/help/matlab/ref/javamethod.html
Is this valid also for scala code?
It is also valid for Scala code. Just pretend that you're doing Java interop (e.g. a method called + would actually be $plus) and make sure scala-library.jar is in Matlab's classpath (e.g. using javaaddpath).
Incidentally, I've done Java/Matlab interop before, and it's not as "easily integrated" as one might hope. Passing data is kind of awkward and you tend to trip on classloader and/or classpath issues every now and then.
I'd be wary of planning a big project with lots of tightly-connected interop. In my experience it usually works better using the Unix mindset: make independent tools that do their own thing well, and chain them together to get what you want. For instance, I routinely have Scala write Matlab code and call Matlab to run it, or have Matlab use system to fire up a Scala program to process a subset of the data.
So--calling Scala from Matlab is completely possible, and for simple interfaces looks just like Java. Just try to keep the interface simple.
You could encapsulate your Scala code in another language that's easily called by Matlab, such as Java of C. Since you seem to know about Java, you could use these examples to learn to encapsulate your Scala methods inside Jave methods that you can call from Matlab. A number of other methods are available to you with different languages (MEX-files, loadlibrary, etc...)
I would like to know which programming languages can be called by matlab.
for example I am quiet sure that matlab can use C function and maybe java.
I need this stuff for an industrial project so I need something that works well.
For example I have found some tutorial to call python function in matlab but they look to me not very good and stable solution.
I am not an expert of the field and my knowledge of matlab is very limited. So please be patience with the answer.
This project is related to machine learning and the software will probably run on a cluster.
EDIT according to this post Embedding Python in MATLAB seems that there are problem when importing numpy using python.
The only reason to use python in this environment is the numpy library.
Without that it is almost useless to me.
Do you think that I will encounter similar problem using java or c calling some mathematics libraries?
Most interfaces are listed here:
http://www.mathworks.de/de/help/matlab/external-interfaces.html
For Python I see different solutions:
COM on Windows platforms. This requires to register an application, check if this is possible and allowed on the cluster.
XMLRPC or SOAP. You may need to use Java-Classes in Matlab, but as you already realised this is very simple. Verify that the cluster has a Java VM available, many run matlab without java.
You can embed python code into c, which allows you to write mex functions which run c code: http://docs.python.org/2/extending/embedding.html
Use the command line interface for python.
Besides the documented limitations, I don't see any problem with these solution. If you are familiar with C or Matlab, I would choose the second or third option. This allows you to write a wrapper to access python with a very fundamental knowledge of matlab.
There are two main methods to achieve this:
Write MEX functions, which is basically C/C++ or Fortran methods, which use Matlab-specific API. You can then call these methods like you would any function written in M-language file. This is described here.
Call external libraries written in Java, .Net, C/C++, and COM servers. This is described here.
Both methods require good understanding of what you are doing, although I would argue that writing MEX function is much harder then referencing an existing library.
I'm not sure about programming language but You can do it by EXE file by running run('C:\someCompiledProgram.exe')
And if you need result you can use:
[status, result] = system('command')
You can read about it here:
http://nf.nci.org.au/facilities/software/Matlab/techdoc/ref/system.html
I have a function written in C (Say in HelloWorld.c file).
I want to compile this and need to create a staic object file HelloWorld.a
Finally I need to call this from a Perl program (HelloWorld.pl).
To call from perl to C one usually compiles a shared, not a static, library from his c code, and then loads that into the perl interpreter using the XSLoader or DynaLoader module.
To then be able to call the C code from perl space there's many ways. The most common one is writing something called XSUBs, which have a perl-side interface, map the perl calling-conventions to C calling-conventions, and call the C functions. Those XSUBs are usually also linked into the shared library that'll be loaded into perl, and written in a language called XS, which is extensively documented in perlxs and perlxstut.
There's also other ways to build that wrapper layer, like various XS code generators, as well as SWIG. But you could also call to the C functions directly using an NCI. Perl also has many of those. The P5NCI is one example of those, the ctypes module developed in this year's Google Summer of Code program is another.
Another related technique that should probably be mentioned here is Inline::C, and the other modules of the Inline family. They allow you to write code in other languages directly in perl, and call to it. Under the hood Inline::C just builds XS code and loads the result of that into the interpreter.
As #rafl says, you should use a shared library.
If you must use a static library, then you have to rebuild Perl with the static library built in. You'll need some XS glue too. However, this is messy enough that you really, really don't want to do it.
According to perlxstut:
It is commonly thought that if a system does not have the capability to dynamically load a library, you cannot build XSUBs. This is incorrect. You can build them, but you must link the XSUBs subroutines with the rest of Perl, creating a new executable. This situation is similar to Perl 4.
This tutorial can still be used on such a system. The XSUB build mechanism will check the system and build a dynamically-loadable library if possible, or else a static library and then, optionally, a new statically-linked executable with that static library linked in.
Should you wish to build a statically-linked executable on a system which can dynamically load libraries, you may, in all the following examples, where the command "make" with no arguments is executed, run the command "make perl" instead.
If you have generated such a statically-linked executable by choice, then instead of saying "make test", you should say "make test_static". On systems that cannot build dynamically-loadable libraries at all, simply saying "make test" is sufficient.
I am doing a compilers discipline at college and we must generate code for our invented language to any platform we want to. I think the simplest case is generating code for the Java JVM or .NET CLR. Any suggestion which one to choose, and which APIs out there can help me on this task? I already have all the semantic analysis done, just need to generate code for a given program.
Thank you
From what I know, on higher level, two VMs are actually quite similar: both are classic stack-based machines, with largely high-level operations (e.g. virtual method dispatch is an opcode). That said, CLR lets you get down to the metal if you want, as it has raw data pointers with arithmetic, raw function pointers, unions etc. It also has proper tailcalls. So, if the implementation of language needs any of the above (e.g. Scheme spec mandates tailcalls), or if it is significantly advantaged by having those features, then you would probably want to go the CLR way.
The other advantage there is that you get a stock API to emit bytecode there - System.Reflection.Emit - even though it is somewhat limited for full-fledged compiler scenarios, it is still generally enough for a simple compiler.
With JVM, two main advantages you get are better portability, and the fact that bytecode itself is arguably simpler (because of less features).
Another option that i came across what a library called run sharp that can generate the MSIL code in runtime using emit. But in a nicer more user friendly way that is more like c#. The latest version of the library can be found here.
http://code.google.com/p/runsharp/
In .NET you can use the Reflection.Emit Namespace to generate MSIL code.
See the msdn link: http://msdn.microsoft.com/en-us/library/3y322t50.aspx