
JVM Internals (2013) - mohsinhijazee
http://blog.jamesdbloom.com/JVMInternals.html
======
sorokod
Perm. Generation was removed in Java 8

[https://www.google.co.uk/url?sa=t&source=web&rct=j&ei=zoczVe...](https://www.google.co.uk/url?sa=t&source=web&rct=j&ei=zoczVejCEvK07QbUyYHABw&url=https://blogs.oracle.com/poonam/entry/about_g1_garbage_collector_permanent&ved=0CC0QFjAF&usg=AFQjCNF4QzNUlcnBz2m1O3iiJuiP5Mqebg&sig2=uwZeba7-exlnPKskw4p3lQ)

~~~
the8472
link without google tracking:
[https://blogs.oracle.com/poonam/entry/about_g1_garbage_colle...](https://blogs.oracle.com/poonam/entry/about_g1_garbage_collector_permanent)

------
ed_blackburn
I'm a CLR man myself. Just the path my career has taken me really. Does anyone
know if there are equivalent documents for CLR or CLR Core?

I don't see LLVM, JVM or the CLR going anywhere. They'll evolve, get smaller,
reach more devices and platforms etc but personally I'd like to appreciate the
how and the why better.

It'd be useful to know if there are any reasons why I may pick one over the
other in certain circumstances I appreciate how there ecosystems and culture
are different but I'm curious from a purely technical perspective too.

~~~
pron
Well, LLVM is something else altogether, as it doesn't try to abstract away
the OS, while the JVM does[1]. As to the JVM, well, first of all, there is no
"the JVM". There are many JVMs by many vendors, and many _types_ of JVMs (from
smart-cards, through various embedded devices, and all the way to desktops,
servers and mainframes). Some of the most interesting -- and most important --
ones are made by companies you've probably never heard of, like Aicas and
Atego that make hard realtime JVMs for use in avionics, medical devices and
other safety-critical systems. The best-known JVMs are HotSpot, OpenJDK's JVM
(which serves as the basis for Oracle and Azul's JVMs) and J9, IBM's JVM. When
many people say "the JVM" they mean the SE (i.e. "standard edition") of
HotSpot.

While HotSpot and the CLR are more similar -- at least in their goals -- than
different, and each is ahead of the other in some respects and behind in
others, I'd say that the most interesting features of HotSpot are its JIT and
GCs (it comes with a few) that are years ahead of anything else used in any
other environment in the industry (well, except Azul that sells a modified
HotSpot with a "pauseless" GC that never pauses the application for more than
a few microseconds). In my opinion, the most exciting development regarding
HotSpot is the work being done on HotSpot's next generation optimizing JIT
called Graal, that comes with an a complementary language toolkit called
Truffle[2]. It pushes the envelopes further with regards to HotSpot's defining
feature -- speculative optimization and deoptimization -- and lets the user
(if they wish) control the code generation through a clever API.

Another important feature of any compliant SE JVM is bytecode manipulation. It
allows modifying libraries after they've been compiled -- either on disk or
during the class loading process. One use is dependency namespacing, aka
shadowing (if your program depends on libraries A and B, and they each depend
on different, incompatible versions of library C, shadowing can hide the two
versions of C from each other). But one of the coolest things is the ability
to transform (and de-transform) bytecode of running classes (to inject, say,
tracing).

Since HotSpot is part of OpenJDK, all work on it (including Graal and Truffle)
is open-source (and has been for a few years now). The OpenJDK as a whole is
probably the world's second largest open-source project (in terms of
contributors), after the Linux kernel. The main contributors are, of course,
Oracle and IBM (the latter to a much lesser degree), but also Google, Intel,
Apple, Twitter and many more.

[1]:
[https://www.youtube.com/watch?v=uL2D3qzHtqY](https://www.youtube.com/watch?v=uL2D3qzHtqY)

[2]:
[https://wiki.openjdk.java.net/display/Graal/Publications+and...](https://wiki.openjdk.java.net/display/Graal/Publications+and+Presentations)

~~~
tokenizerrr
> When many people say "the JVM" they mean the SE (i.e. "standard edition") of
> HotSpot

This changed in Java 7. OpenJDK is now the reference implementation, and thus
"the JVM"

~~~
pron
OpenJDK is a lot more than just the JVM (it's also the runtime libraries).
Open JDK's JVM is named HotSpot.

~~~
tokenizerrr
I think the only JVM named HotSpot is the one distributed by Oracle.

~~~
pron
They are one and the same. Oracle's JVM _is_ the OpenJDK's JVM, slightly
modified (they mostly add monitoring capabilities that were part of the
JRockit JVM), and Oracle's JDK (which contains the JVM) _is_ OpenJDK with some
minor additions.

------
pjmlp
While a very interesting article, and it provides a broad overview of what is
to be expected by any JVM implementing the "JVM Specification", not all JVMs
are made alike.

For example, JikesRVM, Aonix, IBM Websphere Real Time, OS/400 JVM (which makes
use of OS/400 kernel JIT and TIMI) and many others.

------
amelius
I'd like to see this as a book.

~~~
needusername
Java 8 update 40 has a commercial feature called "Application Class Data
Sharing" [1] that extends Class Data Sharing to application classes. However
almost no documentation is available. Likely it is almost useless because
likely it only works with the default system classloader.

[1]
[http://www.oracle.com/technetwork/java/javase/8u40-relnotes-...](http://www.oracle.com/technetwork/java/javase/8u40-relnotes-2389089.html)

