I have a program loaded in the memory. Now I want to access the memory directly and change the OPCODE and DATA in the memory for that program. For this I need to write a Java program.
Can you please tell me if this is feasible? If yes, please let me know how to write such a program.
Thanks in advance!
Java is not designed for this.
The main aim of Java is to let the JVM manage the memory for you. Thus, your programs are sandboxed.
However, there seems to be a backdoor in HotSpot JVM:
Java was initially designed as a safe, managed environment.
Nevertheless, Java HotSpot VM contains a “backdoor” that provides a
number of low-level operations to manipulate memory and threads
directly. This backdoor – sun.misc.Unsafe – is widely used by JDK
itself in the packages like java.nio or java.util.concurrent. It is
hard to imagine a Java developer who uses this backdoor in any regular
development because this API is extremely dangerous, non portable, and
volatile. Nevertheless, Unsafe provides an easy way to look into
HotSpot JVM internals and do some tricks. Sometimes it is simply
funny, sometimes it can be used to study VM internals without C++ code
debugging, sometimes it can be leveraged for profiling and development
tools.
Source: http://highlyscalable.wordpress.com/2012/02/02/direct-memory-access-in-java/
The Unsafe class is, however, undocumented. You may want to have a look at this SO answer for more details: https://stackoverflow.com/questions/5574241/interesting-uses-of-sun-misc-unsafe
Unoffical Docs: http://mishadoff.github.io/blog/java-magic-part-4-sun-dot-misc-dot-unsafe/
Absolute Beginners' Guide http://java-performance.info/string-packing-converting-characters-to-bytes/
http://javapapers.com/core-java/address-of-a-java-object/
P.S. I am aware that I must post some of the content of the link here but since the articles are really very detailed, I have skipped that part
You cannot directly reference memory in java, as their is no concept of pointers in java like c/c++
You must go through this referencing memory address
Hope it helps.
Related
All the operating systems till date have been written in C/C++ while there is none in Java. There are tonnes of Java applications but not an OS. Why?
Because we have operating systems already, mainly. Java isn't designed to run on bare metal, but that's not as big of a hurdle as it might seem at first. As C compilers provide intrinsic functions that compile to specific instructions, a Java compiler (or JIT, the distinction isn't meaningful in this context) could do the same thing. Handling the interaction of GC and the memory manager would be somewhat tricky also. But it could be done. The result is a kernel that's 95% Java and ready to run jars. What's next?
Now it's time to write an operating system. Device drivers, a filesystem, a network stack, all the other components that make it possible to do things with a computer. The Java standard library normally leans heavily on system calls to do the heavy lifting, both because it has to and because running a computer is a pain in the ass. Writing a file, for example, involves the following layers (at least, I'm not an OS guy so I've surely missed stuff):
The filesystem, which has to find space for the file, update its directory structure, handle journaling, and finally decide what disk blocks need to be written and in what order.
The block layer, which has to schedule concurrent writes and reads to maximize throughput while maximizing fairness.
The device driver, which has to keep the device happy and poke it in the right places to make things happen. And of course every device is broken in its own special way, requiring its own driver.
And all this has to work fine and remain performant with a dozen threads accessing the disk, because a disk is essentially an enormous pile of shared mutable state.
At the end, you've got Linux, except it doesn't work as well because it doesn't have near as much effort invested into functionality and performance, and it only runs Java. Possibly you gain performance from having a single address space and no kernel/userspace distinction, but the gain isn't worth the effort involved.
There is one place where a language-specific OS makes sense: VMs. Let the underlying OS handle the hard parts of running a computer, and the tenant OS handles turning a VM into an execution environment. BareMetal and MirageOS follow this model. Why would you bother doing this instead of using Docker? That's a good question.
Indeed there is a JavaOS http://en.wikipedia.org/wiki/JavaOS
And here is discuss about why there is not many OS written in java Is it possible to make an operating system using java?
In short, Java need to run on JVM. JVM need to run on an OS. writing an OS using Java is not a good choice.
OS needs to deal with hardware which is not doable using java (except using JNI). And that is because JVM only provided limited commands which can be used in Java. These command including add, call a method and so on. But deal with hardware need command to operate reg, memory, CPU, hardware drivers directly. These are not supported directly in JVM so JNI is needed. That is back to the start - it is still needed to write an OS using C/assembly.
Hope this helps.
One of the main benefits of using Java is that abstracts away a lot of low level details that you usually don't really need to care about. It's those details which are required when you build an OS. So while you could work around this to write an OS in Java, it would have a lot of limitations, and you'd spend a lot of time fighting with the language and its initial design principles.
For operating systems you need to work really low-level. And that is a pain in Java. You do need e.g. unsigned data types, and Java only has signed data types. You need struct objects that have exactly the memory alignment the driver expects (and no object header like Java adds to every object).
Even key components of Java itself are no longer written in Java.
And this is -by no means- a temporary thing. More and more does get rewritten in native code to get better performance. The HotSpot VM adds "intrinsics" for performance critical native code, and there is work underway to reduce the overall cost of native calls.
For example JavaFX: The reason why it is much faster than AWT/Swing ever were is because it contains/uses a huge amount of native code. It relies on native code for rendering, and e.g. if you add the "webview" browser component it is actually using the webkit C library to provide the browser.
There is a number of things Java does really well. It is a nicely structured language with a fantastic toolchain. Python is much more compact to write, but its toolchain is a mess, e.g. refactoring tools are disappointing. And where Java shines is at optimizing polymorphism at run-time. Where C++ compilers would need to do expensive virtual calls - because at compile time it is not known which implementation will be used - there Hotspot can aggressively inline code to get better performance. But for operating systems, you do not need this much. You can afford to manually optimize call sites and inlining.
This answer does not mean to be exhaustive in any way, but I'd like to share my thoughts on the (very vast) topic.
Although it is theoretically possible to write some OS in pure java, there are practical matters that make this task really difficult. The main problem is that there is no (currently up to date and reliable) java compiler able to compile java to byte code. So there is no existing tool to make writing a whole OS from the ground up feasible in java, at least as far as my knowledge goes.
Java was designed to run in some implementation of the java virtual machine. There exist implementations for Windows, Mac, Linux, Android, etc. The design of the language is strongly based on the assumption that the JVM exists and will do some magic for you at runtime (think garbage collection, JIT compiler, reflection, etc.). This is most likely part of the reason why such a compiler does not exist: where would all these functionality go? Compiled down to byte code? It's possible but at this point I believe it would be difficult to do. Even Android, whose SDK is purely java based, runs Dalvik (a version of the JVM that supports a subset of the language) on a Linux Kernel.
I am wondering how this happens: how is a Java program mapped to an OS process (like the one shown for Linux below):
In C, it's a straightforward association in how a program is written and how the whole call stack proceeds in the OS. I was wondering how is the mapping achieved in Java? Does a method meth(), called on an object: obj, just translate to locating the address of obj.meth() & from then on stack is used the way it is in C?
Thanks in advance!
Edit: I'd also be curious to know the model that other OOP languages use in general (C++, Python etc).
That's a pretty complex problem. Here is a pretty good article about this topic. In short, Java got two execution modes which hugely affects memory layout.
Some code is executed by intepreter
Some code are compiled to native code for better performance.
See this wiki page: http://en.wikipedia.org/wiki/Just-in-time_compilation.
And JVM got more type of memory region, like perm-gen, memory for JIT, etc.
This is well-discussed in other threads:
java and memory layout
jdk1.6 memory layout
Most Java JVMs are plain C programs. So the picture will be the same write up to the first class file being interpreted/executed.
After that it depends on the JVM implementation. Typically they would use the stack storage to keep track of control type information such as which classes are loaded, which threads are running etc. For the actual "program" storage the interpreter and garbage collector will use plain "malloc"/"mfree" to allocatate and free memory plus some fairly complex control structures to enable the garbage collector to function.
What is the easiest way in Java for achieving multi-core? And by this, I mean, to specifically point out on what core to execute some parts of the project, so good-old "normal" java threads are not an option.
So far, I was suggested JConqurr (which is an Eclipse toolkit for multi-core programming in java), JaMP (which extends Java for OpenMP), and MPJ express, of which I don't know much. Which of the above do you consider the best, or do you have other suggestions? It would be preferable to somehow mesure the performance boost/gain, but not exclusive.
Any help would be much appreciated.
Thanks,
twentynine.
Even though it is easy to write multi-threaded code in Java, there is nothing in the Java standard runtime which generically allow you to tell the JVM or the operating system how to schedule your program.
Hence you will need to have code specifically for your JVM and/or your operating system, and that code may not be doable in Java (unless you dive into JNI or JNA). External programs can pin processes to a CPU in many Unix versions (and probably Windows too), but I don't think you can do this for individual threads.
Scala is quite popular for this. It runs on the JVM and has bindings for Java to hook them together.
what i'm looking for is what gets put into the call stack once a function is called recursively, how the arguments are laid on top of each other (are local variables pushed in order? are paremeters pushed in the reverse order?), what bytes exist in an array besides those you asked to have for...
searching on the internet, i've only found simple coding tutorials or information about the java memory model, which seems to be about preventing concurrency and doesn't really explain memory management the way i need.
Perhaps a read on the Java Virtual Machine Specification will help you.
It explains among other things how java works on Suns VM and/or how they should work when other implement it ( IBM, BEA, etc )
I think it's definitely worth looking at the Java Language Specification to see if it answers some of your questions. I've also written a few pages about the memory usage of Java objects that may interest you, essentially based on Hotspot. Other sources include white papers published by Sun or other technical documentation produced by your favourite purveyor of JVMs (IBM are also quite reasonable about releasing technical details if you dig around a bit).
If you're feeling particularly "hard core", then you can also download the debug JDK, which allows you to get a dump of all code generated by the JIT compiler (turn on -XX:+PrintOptoAssembly).
You should also ask yourself:
do you really care, say, what order method parameters are written to the stack? so long as the answer is "the order in which the called method expects them", what difference does it make? (N.B. If the JIT compiler inlines the method, the answer in some cases could be "it does not write the parameters to the stack"...)
can you find the answers to your underlying problem empirically? (e.g. if what you really want to know is "to what recursion depth can I go with a method that takes these parameters and declares these local variables each time", why not just write a test program to find that out from within Java?
This white paper offers the best introduction I've seen:
http://www.oracle.com/technetwork/java/memorymanagement-whitepaper-150215.pdf
Once you understand that document, you can find more detailed resources, such as the GC tuning guides provided by Sun:
http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html
I would have replied quite the same as Oscar Reyes did if he hadn't been first. You will definitely find stuff like that in the VM spec.
However, why do you want to know it so exactly, as you can't access this storage in Java anyway?
use javap and read the ByteCode, your intution will help you much faster and better.
Keep in mind when reading the JVM Spec that although it defines how much of Java's memory model should work, it does leave certain areas (like garbage collection) open to interpretation so it might also help to try and find documentation/specifications for the memory model for virtual machines other than Suns.
I know that you can run almost all Java in Dalvik's VM that you can in Java's VM but the limitations are not very clear. Has anyone run into any major stumbling blocks? Any major libraries having trouble? Any languages that compile to Java byte code (Scala, Jython etc...) not work as expected?
There is a number of things that Dalvik will not handle or will not handle quite the same way as standard Java bytecode, though most of them are quite advanced.
The most severe example is runtime bytecode generation and custom class loading. Let's say you would like to create some bytecode and then use classloader to load it for you, if that trick works on your normal machine, it is guaranteed to not work on Dalvik, unless you change your bytecode generation.
That prevents you from using certain dependency injection frameworks, most known example being Google Guice (though I am sure some people work on that). On the other hand AspectJ should work as it uses bytecode instrumentation as a compilation step (though I don't know if anyone tried).
As to other jvm languages -- anything that in the end compiles to standard bytecode and does not use bytecode instrumentation at runtime can be converted to Dalvik and should work. I know people did run Jython on Android and it worked ok.
Other thing to be aware of is that there is no just in time compilation. This is not strictly Dalviks problem (you can always compile any bytecode on the fly if you wish) but that Android does not support that and is unlikely to do so. In the effect while microbenchmarking for standard Java was useless -- components had different runtime characterstics in tests than as parts of larger systems -- microbenchmarks for Android phones totally make sense.
If you see "Dalvik Virtual Machine internals" Google IO session, you can find Dalvik does not support generational GC.
So, it could degrade performance of frequent object creation and deletion. Java VM supports generational GC so, it would show better GC performance for the same situation.
And also, Dalvik uses trace-granuality JIT instead of method granuality JIT.
Another thing that I guess could be added here is that Dalvik apparently does not preserve field order when listing the fields of a class using the reflection API. Now, the reflection API does not make any guarantees on it anyway (so ideally you shouldn't depend on it anyway), but most of the other VMs out there do preserve the order.
Just to add to the conversation, not intended to revive an old thread. I just ran across this in my search, and want to add that Jython does not work out of the box with Dalvik either. Simply trying to do a hello world example will yield the following: