Talk:Java virtual machine

Opening heading

"Compare javaw" -> what the hell? This sentence makes no sentence, you have to read the linked article to understand what the author means. And it is not relevant to the topic. Delete this sentence (it is confusing) or elaborate. — Preceding unsigned comment added by 77.2.240.180 (talk) 21:44, 17 December 2011 (UTC)

Perhaps optimistically

The phrase "perhaps optimistically", referring to the statement "We intend that this specification should sufficiently document the Java Virtual Machine to make possible compatible clean-room implementations." was deleted by Intqr as "clearly POV". As someone who HAS participated in the design/construction of a (not quite cleanroom) independent implementation of Java I can tell you that I was being polite -- the statement is an outright lie.

Would Intqr like to propose different wording? drh 02:55, 4 May 2007 (UTC)

It is not a "lie," it reflects the intent of the specification. If you could cite a source and add an additional comment about its incompleteness then that would be great. Stating that it is "optimistic" is a judgment, e.g., a point of view, and not a very informative one at that. -- intgr 19:07, 4 May 2007 (UTC)

You can count on one hand the independent implementations of Java, and most are considered proprietary enough that not much detail is published about them. Therefore there's not much in the way of references to use. My name is on one publication about the Java implementation I've participated in, but that's ten years old, and didn't delve into this issue.

But my point is that that quotation from the Java spec is, without further qualification, very misleading. No one can build an independent "cleanroom" implementation of Java without significant reverse engineering of Sun's test suite. In many cases the test suite is in direct contradiction of the specification, and the test suite always wins if you want to be "certified". drh 23:12, 5 May 2007 (UTC)

Remove Inappropriate words

This should be posted here(it's originally posted at the starting/opening.Editors please take note here.I am not sure who wrote this,but you all should read this "this is not clear. What does 22se stand for? Why, when I click on a link to get a java virtual machine, do I go to a web site where the word "virtual" doesn't exist, but there are links for other things, with no explanations of what they are? So I come here, to find out, and there is no explanation whatsoever. Is J2SE a virtual machine? Why don't you say so? "

I am not that good on java things,so someone please add a new page on:Acrobat Viewer Bean Iane

Dubious

The JVM is distributed along with a set of standard class libraries which implement the Java API (Application Programming Interface). The virtual machine and API have to be consistent with each other and are therefore bundled together as the Java Runtime Environment.

Why does the API has to be consistent with the virtual machine ? In principle the API should be completely independent from the virtual machine (that is, the API A should work with either JVM J or JVM K). --hdante (talk) 22:13, 17 January 2008 (UTC)

There are certain features of the API, such as weak references and class loading capabilities, that require extra support from the JVM. The interfaces for providing such support are not defined by any specifications, so the JVM and API are interdependent in these areas. —Preceding unsigned comment added by 129.97.83.181 (talk) 22:38, 26 February 2008 (UTC)

The jre is tied to the specific jvm implementation. The examples I give are specific to sun's vm but I believe it is the most popular and therefore the most relevant context with which to discuss this.

There are many hooks into the core of the vm. See the sun.misc.Unsafe class. Many graphics operations are optimized through accessing blocks of memory allocated with this class. It is also how reflection is implemented both through native accessors and loading class code that purposely br For assistance on the image use policy, see Wikipedia:Media copyright questions. --23:33, 16 September 2008 (UTC)

Java

Hi I want complete information regarding java compiler —Preceding unsigned comment added by 121.242.7.207 (talk) 07:17, 22 April 2009 (UTC)

how many instructions does JVM has ? —Preceding unsigned comment added by 122.183.67.150 (talk) 13:25, 6 June 2009 (UTC)

what is the latest version of JVM

I believe the JVM is the same as when it was originally released (spec-wise, implementations obviously differ). Is this true? I think it should be documented (I'm talking about the VM, *NOT* the language, to be clear) 78.146.186.6 (talk) 01:24, 7 July 2009 (UTC)

Correction, I think that there must at least be an update for java 1.5 as the memory model changed for volatiles at the very least. Or was the underlying JVM changed for each update of java (1.0, 1.1, ... 1.7)? Any light shed would be helpful. 89.243.42.41 (talk) 23:14, 16 July 2009 (UTC)

How many JVM instances per core

75.34.99.83 (talk) 04:55, 31 August 2009 (UTC) This page would be improved if someone clarified how many instances of a JVM run simulatenouly on a given machine or core.

A real microprocessor core (that processes machine code /assembly language) can not duplicate itself.

But a VM can be duplicated, this presents the natural conceptual question, - do concurrent Java threads or applications spawn separate instances of the JVM?

If this is done, are their some simple guidelines to understanding when new JVM instances are generated? —Preceding unsigned comment added by 75.34.99.83 (talk) 04:55, 31 August 2009 (UTC)

Defining the JVM Heap

The article starts by saying that "The Java Virtual Machine heap is the area of memory used by the Java Virtual Machine (and specifically HotSpot)"

The Heap is an area defined in the JVM Spec - which despite being an abstraction all implementations of the JVM have. Do we need to single out HotSpot here?NagaSrinivas (talk) 19:42, 22 October 2009 (UTC)

The Heap definition and generation: young/old/permgen is a JVM specific. Some JVMs do not have an explicit permgen and some are not copy collector. The section needs to be wholly rewritten Bestsss (talk) 07:54, 27 October 2011 (UTC)

Why talk about generations?

The idea of having generations and details of garbage collection are specific to an implementation of the JVM. Why do we need to single out Sun's HotSpot JVM when we want to talk about the JVM heap? NagaSrinivas (talk) 19:38, 22 October 2009 (UTC)

Architecture description

I cannot find a link or description of the actual architecture of the JVM. I don't know enough about it to add it myself . I also suggest to add a description of the memory model with regards to multi-threading (the happens before relation). 94.224.194.209 (talk) 19:11, 26 May 2012 (UTC)

OpenJDK

The section that mentions clean room implementations of the JVM, lists Kaffee and IBM. How about OpenJDK, isn't it also a clean room JVM implementation?

Jan Burse (talk) 01:25, 9 November 2012 (UTC)

Java "Runtime" (??)

Is there any difference at all between "Java" and "Java Runtime"? Presumably, every Java implementation "runs" at some "time" or other. --lifeform (talk) 01:32, 4 June 2014 (UTC)

Better introductory needed

"Java virtual machine (JVM) is a process virtual machine that can execute Java bytecode. It is the code execution component of the Java platform. Sun Microsystems has stated that there are over 5.5 billion JVM-enabled devices.[1]"

First of all, there are three notions of the JVM: the abstract specification, a concrete implementation, or a runtime instance

"Java virtual machine (JVM) is a process virtual machine.." The Java Virtual Machine is an abstract computing machine -> per http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-1.html

".. that can execute Java bytecode?". Wrong, it interprets the code based on the set of underlying processor machine instruction set.

"Sun Microsystems has stated that there are over 5.5 billion JVM-enabled devices.[1]" -> This belongs to a trivia section, not to the introductory.--Michelle Ridomi (talk) 19:01, 25 August 2014 (UTC)

Meaningless statement

As of 2014 most[quantify] JVMs use JIT compiling, not interpreting, to achieve greater speed.--Michelle Ridomi (talk) 20:08, 17 September 2014 (UTC)

Architecture

JVM architecture shall be exclusively based on the JVM specification. Therefore, no place for languages (java, python), implementations (ARM, Intel), or operating systems in the JVM architecture description.--Michelle Ridomi (talk) 11:38, 22 September 2014 (UTC)

JVM languages -> complete mess and nonsense

The text of this section is imprecise, unclear and all links to references are broken. I've rewritten the section according to the Java7 JVM specification.--Michelle Ridomi (talk) 11:39, 23 September 2014 (UTC)

C to bytecode compilers

I am not sure why we have this section? If it's about JVM as an interpreter idea, then no need to tie it to C language. Any thoughts about this section?--Michelle Ridomi (talk) 13:04, 20 October 2014 (UTC)

Bytecode verifier?!

For what reason it is taken out of the JVM architecture context: The class File Format -> Verification of class Files -> Verification by Type Inference -> Bytecode Verifier?

It's a very bad approach that creates only confusion.--Michelle Ridomi (talk) 19:19, 23 October 2014 (UTC)

Still, the JVM has a bytecode verifier. Do you mean that it's a bad approach in the implementation, or a bad approach in the article? To me it seems bytecode verification has a place in the article. Martijn Hoekstra (talk) 16:38, 28 October 2014 (UTC)

• • No one denies the bytecode verifier existence. Pay attention to the place of the verifier in the JVM architecture. Bad approach in the article.--Michelle Ridomi (talk) 17:24, 28 October 2014 (UTC)
    • Oh, ok. This article is in pretty bad shape, I fully agree. Is there anything I can do to help you make it better? Martijn Hoekstra (talk) 18:40, 28 October 2014 (UTC)
      • I'll take care of improving class loader. The Licensing section shall be rewritten; makes no sense as is.--Michelle Ridomi (talk) 19:32, 28 October 2014 (UTC)

Hi, I see that the verifier section is now gone (i am referring to the content at https://en.wikipedia.org/w/index.php?title=Java_virtual_machine&oldid=631130134#Bytecode_verifier ). I found it much more useful than the replacement text ("ensures the correctness of the imported type"), and i don't understand why it was removed. It contained much useful information that is now gone, such as the philosophy behind verification, an introductory explanation of what kinds of things are being verified and why, and the connection to efficient execution on a register architecture. Any objections if i put it back? Bayle Shanks (talk) 08:03, 24 January 2015 (UTC)

Google Web Toolkit

I've removed

or into another intermediate language (for example, Google Web Toolkit compiles Java source code into JavaScript)

because finding it misplaced. The JVM has no use of Google Web Toolkit.--65.220.39.77 (talk) 12:24, 20 January 2015 (UTC)

JRE def.

Can't we get the actual name, Java Runtime Environment (abbreviation JRE) back into this article? --Mortense (talk) 18:14, 29 January 2015 (UTC)

I just put it back in to the lede (completely unreferenced. I shouldn't do that). Since JRE is a redirect here, I think there either should be more, or the JRE needs its own article. Maybe refocussing this article to be about the JRE and moving it to JRE is the best option. Ideas? Martijn Hoekstra (talk) 18:44, 29 January 2015 (UTC)

Currently the article suggest that any combination of a JVM and standard libraries would form a JRE. However JRE is a trademark from Oracle (see http://docs.oracle.com/javase/7/docs/) I think this should be clearer from the article. --Pdevaere (talk) 10:46, 5 March 2015 (UTC)

This better? Feel free to make any edits that you think improve the article. Martijn Hoekstra (talk) 13:28, 5 March 2015 (UTC)

Yeps, thanks! I'll be bold next time. I'm not sure about wether the JCL is an implementation or a specification. In fact, I can't seem to find any info on the term JCL on the oracle website. And googling it pretty much only finds the wikipedia hits. But I guess that's a discussion for on the Java Class Library page. I'll come back to edit when I'm more certain. Pdevaere (talk) 06:31, 6 March 2015 (UTC)

Undoing revision 653853606 (Intro: Reword phrase that uses questionable terms.)

Java_virtual_machine&curid=16389&diff=653853606&oldid=653330672

• Before: A JVM implementation i a computer program that implements requirements of the JVM specification in a compliant and preferably performant manner
• After: A JVM implementation is a computer program that meets the requirements of the JVM specification in a competent manner.

I want to point out that 1) both terms are not questionable and are used in this context, as the following headlines ilustrate

• Implementation of Requirements under the Food Quality Protection Act (FQPA)
• Making healthcare content easier to share in a HIPAA Compliant Manner
• Walking the regulation tightrope in a socially and ethically compliant manner

and 2) the replacement of compliant with competent is a nonsense. I do not strictly object to the first change (implement/meet) and therefore I will reapply it. — Preceding unsigned comment added by TvojaStara (talk • contribs) 18:44, 31 March 2015 (UTC)

Joint Runtime Extension

JRE can also be an abbreviation for Joint Runtime Extension, aswell as Java Runtime Environment. However, currently JRE links directly to this wiki article. See main JREAP wiki article. 66.155.23.67 (talk) 08:01, 16 July 2015 (UTC)

Page messed up by vandalism?

There seems to be an issue with this specific page. The pages' contents are gone, replaced by a yellow background and red text reading: "ATTENTION WIKIPEDIA READERS: I have evidence that suggests @BoulderTodd was responsible for the death of JonBenet Ramsey. Don't let this wicked man to get away with his wretched deeds!" — Preceding unsigned comment added by YoruFeisu (talk • contribs) 18:34, 16 September 2017 (UTC)

64-bit

Regarding this edit and subsequent reversion made by User:Comp.arch, I still don't see how it's relevant. There is no such thing as "64-bit Java". Java bytecode only understands 32-bit words, with longs and doubles being handled as double-words. That's what JVMs must interpret and execute. They can do so on any hardware they want, but it doesn't change the fact that the Java bytecode is still using 32-bit words.

If you could write a JVM for the PDP-10, you would not have "36-bit Java". You would have a JVM that runs 32-bit Java bytecode on a 36-bit machine.

It doesn't matter that the heap can be larger when you run on a 64-bit machine; the JVM doesn't require any particular implementation of the heap and references, so this is just an artifact of using different techniques to implement the heap and references in JVM implementations for 64-bit platforms. I'm certain it's possible to use techniques on 32-bit platforms to get a heap larger than 4GB, but it would just be unusably slow because it wouldn't all fit in RAM, so nobody has bothered to do it.

The quoted source even clearly explains all of this. "You can think of this environment as being just another platform to which we've ported the SDK." Exactly my point. And they are equally clear that the Java bytecode is unchanged. "We did not increase the size of Java integers from 32 to 64... Array indexes, which are defined in the Java Virtual Machine Specification, are not widened from 32 to 64."

This text just amounts to saying "You can also implement a JVM on a 64-bit platform, but it changes nothing about Java bytecode or the JVM's capabilities." Not interesting, not informative, and also not relevant in an article that's describing the characteristics of abstract JVMs rather than characteristics of JVM implementations. I maintain that this text is unnecessary and should be removed. --Bigpeteb (talk) 16:07, 4 April 2018 (UTC)

You say the text amounts to 64-bit data model "changes nothing about [..] the JVM's capabilities." I believe you're simply wrong there, as 64-bit addressing, means virtually unlimited heap size (only limited by RAM (or virtual memory, RAM+swap)). This is the most common reason people want and go for 64-bit CPUs. Saying the "64 bit data model" is "misleading" and dropping sourced information, as it's "misleading" is a WP:NPOV-violation, when I can also say NOT having the information is misleading". Unlimited heap size vs. much lower down to 1.4 GB:

"The maximum theoretical heap limit for the 32-bit JVM is 4G. Due to various additional constraints such as available swap, kernel address space usage, memory fragmentation, and VM overhead, in practice the limit can be much lower. On most modern 32-bit Windows systems the maximum heap size will range from 1.4G to 1.6G. On 32-bit Solaris kernels the address space is limited to 2G."

"I'm certain it's possible to use techniques on 32-bit platforms to get a heap larger than 4GB, but it would just be unusably slow because it wouldn't all fit in RAM, so nobody has bothered to do it." That's not (just) the reason. 32-bit x86 CPUs have long allowed up to 64 GB of RAM, with Physical Address Extension (PAE), "total physical address size increases from 32 bits to 36 bits", usable for the OS and all programs combined, but each one still uses 32-bit pointers, thus limited to 4 GB (not total RAM size). I.e. the pointer size matters (not just integers size), and the "[base] pointer" (or in Java "reference") is enlarged in the 64 bit data model. comp.arch (talk) 16:35, 15 July 2018 (UTC)

One more thing, note: "Writes to and reads of references are always atomic, regardless of whether they are implemented as 32-bit or 64-bit values."[1] I.e. 64-bit is supported that way (and is important), as opposed to for integer (or double) types what happen to be 64-bit in length. For such 64-bit values, it's implementation defined (but yes can be atomic, but not to be relied on). comp.arch (talk) 16:51, 15 July 2018 (UTC)