I took a better look. This, as other profilers, work by sampling the process, getting the stack trace all at once.
This is either getting it from tooling baked on the kernel (that is why it doesn't work on windows) or getting the stack sample from the JVM (see the tiny-profiler from part-time nerd above)
Sampling makes sense if you want to be as much non intrusive as possible. That is not how JavaFlame works.
What I do is injecting byte code on every function that matches the filters. This code will update a custom stack that stores not only the function name, but also uses reflection to get the argument and their values. In exit, it also records the return value.
It does record the time the function took to run, but this includes the time to get the values from the arguments. It is not exact, but it is good enough to get an idea of the overall logic.
In short, I don't think you can have the argument values with sampling.
I did not know about this project, I will look into it, thanks for linking :)
But, from a quick peek, I think my motivation is different.
My intention when creating this was not profiling exactly each operation, but understanding the logic (what each function calls do and what parameters are passed).
I see that this, apparently, does not capture argument values and return values (I may be wrong).
If you are profiling, that makes sense. Calling toString on every argument obviously affect the performance.
Another thing is that this is pretty simple, there are not many tweaks you need to do, as the goal is just to glance at the values being passed around at runtime.
If you look at the example page, with the sort algorithms, you will see that you can follow exactly how each one works by looking at the values being passed and returned. You don't get this from only looking at the calls.
Mainly for debugging locally. I use it either to understand which parts of the code will be touched by a certain action or over unit tests to get an overall idea of what values are passed to which parts of the system.
Works well if you need to reproduce a bug and wants to check how did you get to whatever invalid state you are looking into. In contrast, before, I would do the same by adding a bunch of breakpoints and going through the function calls. This is slow, and specially annoying when you have lots of timeouts in your code.
But this is project is very new, I am starting to feel the actual json with the stacktrace is a little bit more useful than the graph itself to peek at the values. In the sort example, this would be https://www.isageek.com.br/javaflame/data.js
I've done this after needing to heavily customize slide using reveal js.
Reveal js programmatically changes the slides and made styling them difficult. Besides, the grid layout is perfect for this kind of whole page design.
I don't remember where did I get this from but it is a cool thing to add to your .bashrc
#!/bin/bash
#teach you some new commands every time you open a new terminal
echo 'Did you know that:'
echo $( whatis $(ls /bin | shuf | head -1))
echo $( whatis $(ls /sbin | shuf | head -1))
echo $( whatis $(ls /usr/bin | shuf | head -1))
The thing is, although the quantum state of the photom collapses instantaneously on both entangled photons, we can't manipulate at which state the photon will collapse, and so, we can't really send information using quantum entanglement.
We can't also confirm the entanglement until we can compare both measurement results or else we could send information from the future as in the quantum eraser experiment https://www.youtube.com/watch?v=2Uzytrooz44
Other commenter here. The text says that any autority (autoridade policial ou administrativa -> police force or administrative power) may require that the metadata be recorded for a period of time , but access to this metadata needs the judges order.
For example, if the cops starts investigating John Doe they may ask the service provider to keep metadata for a fixed period of time, stated on the Marco Civil (six months IIRC). But access to this metadata can only be authorized by a judge.
Edit:
Reread the Marco civil an refreshed my memory. What I said is not entirely correct.
All metadata is kept by default and needs a court order to be accessed.
What authorities may ask without a court order is for the service provider to keep the metadata for a time longer than specified on the Marco civil.
Also, as I said on my previous comment, the intention of the bill was that only metadata was recorded, but the term "registros de conexão -> connections log" is vague enough to be interpreted in other ways :(
It doesn't say contents, it says registros de conexão "connections log".
The intent was to log IP adresses and dates, not content, but it is known that the interpretation of the text would be up to our judicial system. It also does not say without a court order. It says they can require them to log those ips, but access to these information requires a court order (as said on chapter 2 item I)
There are other ambiguities regarding who should keep those logs, ISP or service providers.
Free Whatsapp and facebook does hurt net neutrality. It undermines competition and leads to a division between services that are "free" and the ones which are not, on a ISP level.
That's not what article 2 says, article 2 is a preamble with the intentions of the marco civil and contains no definition of rules nor obligations. The removal of those videos are not based on marco civil, but on other laws and our own constitution.
The problem is not the Marco Civil, but how it is being interpreted.
Our judges do not understand what is cryptography.
Our population don't understand and doesn't care. People are just upset that whatsapp is offline.
I really wish mobile makers tried to deviate from the current mobile design norm.
I am not against touch interfaces, but i sure miss some more physical buttons.
In portuguese 'mamar' means to suck, usually associated with babies. Mother is 'mãe' or 'mamãe'. Actually, the r is usually dropped when speaking, so 'mamar' is usally spoken 'mama'.
"Generating get/set and abstract method bodies is only necessary in Java"
On smalltalk instance variables are private, so if you want get/set it's value you need a getter/setter.
You can argument that this is bad oo design, but it's not java exclusive.
"The DistroWatch Page Hit Ranking statistics are a light-hearted way of measuring the popularity of Linux distributions and other free operating systems among the visitors of this website. They correlate neither to usage nor to quality and should not be used to measure the market share of distributions. They simply show the number of times a distribution page on DistroWatch.com was accessed each day, nothing more."
This is either getting it from tooling baked on the kernel (that is why it doesn't work on windows) or getting the stack sample from the JVM (see the tiny-profiler from part-time nerd above)
Sampling makes sense if you want to be as much non intrusive as possible. That is not how JavaFlame works.
What I do is injecting byte code on every function that matches the filters. This code will update a custom stack that stores not only the function name, but also uses reflection to get the argument and their values. In exit, it also records the return value.
It does record the time the function took to run, but this includes the time to get the values from the arguments. It is not exact, but it is good enough to get an idea of the overall logic.
In short, I don't think you can have the argument values with sampling.