I was told when a reference has been changed in jvm , using g1 gc will insert pre write barrier to change the remember set accordingly ,but where is the code ? i check the byte code implementation such as putstatic ,but i can't find where the pre barrier occur ? where and how dose the g1 gc insert the pre write barrier?
Probably already obvious from Holger's comment, but this will not be present at the bytecode level, but generated by JIT.
The best explanation is in the source code itself, which in some case is excellent and at times very clear:
G1 also requires to keep track of object references between different regions to enable evacuation of old regions, which is done as part of mixed collections. References are tracked in remembered sets and is continuously updated as reference are written to with the help of the post-barrier.
You can also find what remembered sets are, for example, or how they are constructed.
And here is the post_barrier method that C2 compiler uses. Though some things I can understand from that source code, some are too complicated for me, as such, happy reading the code :)
Related
I've learned something about thread local storage(TLS). From my point of view, this is a totally black box - you give it a key, and it gives you the thread local data back. No idea what the key is like and where these local data is saved.
Recently I've found some hacky ways to retrieve TLS data, but couldn't figure out how they work.
In project async-profiler(at src/vmStructs.cpp line:347), pthread key is an int, why? I read the source code about pthread manipulation of Hotspot JVM and didn't find any clue. Hotspot doesn't specify the type of pthread key (and I don't think it can either). And why we could guarantee to find the pthread key with just a simple integer loop? Not sure this is a TLS question or a Hotspot question. :(
pthread_tis an address of pthread. I think it points to some OS thread instance that we may not parse it directly. But, according to Phoenix87's answer, we could regard pthread_t as an address of pthread_t list in which we could find TID(the return of gettid()) with a simple loop (a simple loop, again). You could find it in Austin (at src/linux/py_proc.h line: 613). How does it work?
Both of these make assumptions about the pthread implementation they are working on.
Such assumptions are not warranted in general, and are almost guaranteed to break with a different implementation.
Don't write code like that unless absolutely necessary, and if you do write code like that, please clearly state exactly which implementation(s) and which versions you support.
I am integrating SQL-Connection to one or our existing Siemens S7-1200 PLCs right now.
After copying a Function Block from a working project, one of the data types has changed and is causing trouble now.
Original:
Copied FB:
Does anybody know, how to fix this?
Someone in the Siemens-Forum could answer my question right away.
Leaving his answer here for the next person with my problem :
With the introduction of the OUC library in version V4.x, the TCON instruction, among other things, has changed. Try to update the program on the CPU. In this case, the prerequisite is that the CPU must have at least firmware version V4.1. There is also the risk that translation errors will occur in other places where the older versions were previously used. In this case, the PLC code would have to be adjusted accordingly.
I was wondering if there were a way to compute the size of a reg in Verilog. I researched it quite a bit, and found $size(a), but it's only in SystemVerilog, and it won't work in my verilog program.
Does anyone know an alternative for this??
I also wanted to ask as a side note; I'm having some trouble with my test bench in the sense that when I update a value in the file, that change is not taken in consideration when I simulate. I've been told I might have been using an old test bench but the one I am continuously simulating is the only one available in this project.
EDIT:
To give you an idea of what's the problem: in my code there is a "start" signal and when it is set to 1, the operation starts. Otherwise, it stays idle. I began writing the test bench with start=0, tested it and simulated it, then edited the test bench by setting start to 1. But when I simulate it, the start signal remains 0 in the waveform. I tried to check whether I was using another test bench, but it is the only test bench I am using in this project.
Given that I was on a deadline, I worked on the code so that it would adapt to the "frozen" test bench. I am getting now all the results I want, but I wanted to test some other features of my code, so I created a new project and copy pasted the code in new files (including the same test bench). But when I ran a simulation, the waveform displayed wrong results (even though I was using the exact same code in all modules and test bench). Any idea why?
Any help would be appreciated :)
There is a standardised way to do this, but it requires you to use the VPI, which I don't think you get on Modelsim's student edition. In short, you have to write C code, and dynamically link it to the simulator. In the C code, you can get object properties using routines such as vpi_get. Useful properites might be vpiSize, which is what you want, vpiLeftRange, vpiRightRange, and so on.
Having said all that, Verilog is essentially a static language, and objects have to be declared with a static width using constant expressions. Having a run-time method to determine an object's size is therefore of pretty limited value (since you should already know it), and may not solve whatever problem you actually have. Your question would make more sense for VHDL (and SystemVerilog?), which are much more dynamic.
Note on Icarus: the developers have pushed lots of SystemVerilog stuff back into the main language. If you take advantge of this you may find that your code is not portable.
Second part of your question: you need to be specific on what your problem actually is.
In c2 architecture specific file i see the above variable. Please share
1. what it is?
2. Whether does it has any relation to the run time constant pool.
Thank you.
An IR graph node that represents a base address of the compiled method's constants table in a machine-specific manner. This node actually does nothing on x86, since the architecture allows to reference the whole range of 32-bit or 64-bit addresses inline.
Generally, no. Though some constants from the constant pool (particularly, floating point) may appear in that table.
P.S. I guess HotSpot Compiler guys are too busy to browse StackOverflow :) The better place for asking C2 implementation-specific questions is hotspot-compiler-dev list.
I searched the internet but did not find a concrete answer that why decompilers are unable to produce original source code. I dint get a satisfactory answer. Somewhere it was written that it is similar to halting problem but dint tell how. So what is the theoretical and technical limitation of creating a decompiler which is perfect.
It is, quite simply, a many-to-one problem. For example, in C:
b++;
and
b+=1;
and
b = b + 1;
may all get compiled to the same set of operations once the compiler and optimizer are done. It reorders things, drops in-effective operations, and rewrites entire sections of code. By the time it is done, it has no idea what you wrote, just a pretty good idea what you intended to happen, at a raw-CPU (or vCPU) level.
It is even smart enough to remove variables that aren't needed:
{
a=5;
b=func();
c=a+b;
d=func2(c);
}
## gets rewritten as:
REGISTERA=func()
REGISTERA+=5
return(func2(REGISTERA))
For starters, the variable names are never preserved when your program is compiled. ...so the best it could possibly do would be to use meaningless variable names throughout your re-constituted program. Compiling is generally a one-way transformation - like a one-way hashing function. Like the hash, it may be possible to generate something else that could hash to the same value, but it's highly unlikely the decompiled program will be the exact same as your original.
Compilers throw out information; not all the information that is in the source code is in the compiled code. For example in compiled Java, you can't tell the difference between a parameterized and unparameterized generic type because the information is only used by the compiler; some annotations are only used at compile time and are not included in the compiled output. That doesn't mean you couldn't get some sort of source code by decompiling; it just wouldn't match nor would be as informative as the actual source code.
There is usually not a 1-to-1 correspondence between source code and compiled code. If an essentially infinite number of possible sources could result in the same object code (given unbounded variable name lengths, etc.), how is a decompiler to guess which one to spit out?