Talk:Java virtual machine: Difference between revisions
OneClickArchiver archived Architecture description |
The Sky Bot (talk | contribs) Notifying target talkpage of move discussion on Talk:JVM (disambiguation) |
||
(26 intermediate revisions by 9 users not shown) | |||
Line 1: | Line 1: | ||
{{ |
{{Talk header}} |
||
{{WikiProject |
{{WikiProject banner shell|class=C|vital=yes|1= |
||
{{WikiProject |
{{WikiProject Computing|importance=|software=yes}} |
||
{{WikiProject Java|importance=top}} |
|||
}} |
|||
{{Broken anchors|links= |
|||
* <nowiki>[[Endianness#Big-endian|Big]]</nowiki> The anchor (#Big-endian) has been [[Special:Diff/959779065|deleted by other users]] before. <!-- {"title":"Big-endian","appear":{"revid":86526666,"parentid":86520919,"timestamp":"2006-11-08T17:40:43Z","replaced_anchors":{"Bit Endianness":"\"Bit Endianness\""},"removed_section_titles":["Bit Endianness"],"added_section_titles":["Big-endian","Little-endian","Bi-Endian","Middle-endian","\"Bit Endianness\""]},"disappear":{"revid":959779065,"parentid":959775659,"timestamp":"2020-05-30T15:44:56Z","removed_section_titles":["Examples","Big-endian","Little-endian","Middle-endian","Big","Little"],"added_section_titles":["Special cases"]}} --> |
|||
}} |
|||
== |
== 64-bit == |
||
⚫ | Regarding [https://en.wikipedia.org/w/index.php?title=Java_virtual_machine&diff=833609833&oldid=833181368 this edit] and [https://en.wikipedia.org/w/index.php?title=Java_virtual_machine&action=history 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. |
||
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? |
|||
⚫ | |||
[[User:Janburse|Jan Burse]] ([[User talk:Janburse|talk]]) 01:25, 9 November 2012 (UTC) |
|||
⚫ | 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. |
||
== Meaningless statement == |
|||
⚫ | 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." |
||
As of 2014 most[quantify] JVMs use JIT compiling, not interpreting, to achieve greater speed.--[[User:Michelle Ridomi|Michelle Ridomi]] ([[User talk:Michelle Ridomi|talk]]) 20:08, 17 September 2014 (UTC) |
|||
⚫ | 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. --[[User:Bigpeteb|Bigpeteb]] ([[User talk:Bigpeteb|talk]]) 16:07, 4 April 2018 (UTC) |
||
== JVM languages -> complete mess and nonsense == |
|||
⚫ | :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 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.--[[User:Michelle Ridomi|Michelle Ridomi]] ([[User talk:Michelle Ridomi|talk]]) 11:39, 23 September 2014 (UTC) |
|||
⚫ | ::"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." |
||
== C to bytecode compilers == |
|||
⚫ | : "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. [[User:Comp.arch|comp.arch]] ([[User talk:Comp.arch|talk]]) 16:35, 15 July 2018 (UTC) |
||
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?--[[User:Michelle Ridomi|Michelle Ridomi]] ([[User talk:Michelle Ridomi|talk]]) 13:04, 20 October 2014 (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."[https://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.7] 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). [[User:Comp.arch|comp.arch]] ([[User talk:Comp.arch|talk]]) 16:51, 15 July 2018 (UTC) |
||
== Bytecode verifier?! == |
|||
== Why was the section C to jvm compilers erased? == |
|||
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? |
|||
There are links to a section in this article about a list of C language compilers targeted for JVM. |
|||
It's a very bad approach that creates only confusion.--[[User:Michelle Ridomi|Michelle Ridomi]] ([[User talk:Michelle Ridomi|talk]]) 19:19, 23 October 2014 (UTC) |
|||
Where is that section? |
|||
:Still, the JVM has a [http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.10 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. [[User:Martijn Hoekstra|Martijn Hoekstra]] ([[User talk:Martijn Hoekstra|talk]]) 16:38, 28 October 2014 (UTC) |
|||
Bravo editors Boycotting Wikipedia! |
|||
**No one denies the bytecode verifier existence. Pay attention to the place of the verifier in the JVM architecture. Bad approach in the article.--[[User:Michelle Ridomi|Michelle Ridomi]] ([[User talk:Michelle Ridomi|talk]]) 17:24, 28 October 2014 (UTC) |
|||
The pretext to erase that section is stupid |
|||
***Oh, ok. This article is in pretty bad shape, I fully agree. Is there anything I can do to help you make it better? [[User:Martijn Hoekstra|Martijn Hoekstra]] ([[User talk:Martijn Hoekstra|talk]]) 18:40, 28 October 2014 (UTC) |
|||
Why should a section about C compilers targeting the JVM is a so strange subject deserving to be erased? |
|||
****I'll take care of improving class loader. The Licensing section shall be rewritten; makes no sense as is.--[[User:Michelle Ridomi|Michelle Ridomi]] ([[User talk:Michelle Ridomi|talk]]) 19:32, 28 October 2014 (UTC) |
|||
I wont enter in and edition war, I just will search more reliable sources on the web. |
|||
When I see thinks like this, I wonder if those Boycotting editors are paid to do that. |
|||
Bravo, bravo, bravo! |
|||
oops concept |
|||
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? [[User:Bayle Shanks|Bayle Shanks]] ([[User talk:Bayle Shanks|talk]]) 08:03, 24 January 2015 (UTC) |
|||
== |
== Current Version == |
||
I'd glad if someone could point out, why there is V15.x.y stated as current version (info box, citing a JDK download page), whereas the online installer from Oracle gives me V1.8. |
|||
I've removed |
|||
''or into another intermediate language (for example, [[Google Web Toolkit]] compiles Java source code into [[JavaScript]])'' |
|||
Somewhere, I noticed that "15.x" is short for "1.15.x", but even then -- why is there 15 stated and I get 8? --[[Special:Contributions/2001:4DD4:F333:1:99E0:6841:8281:A0CA|2001:4DD4:F333:1:99E0:6841:8281:A0CA]] ([[User talk:2001:4DD4:F333:1:99E0:6841:8281:A0CA|talk]]) 22:25, 7 February 2021 (UTC) |
|||
== |
== Java == |
||
A Java virtual machine (JVM) is a virtual machine that enables a computer to run Java programs as well as programs written in other languages that are also compiled to Java bytecode. The JVM is detailed by a specification that formally describes what is required in a JVM implementation. Having a specification ensures interoperability of Java programs across different implementations so that program authors using the Java Development Kit (JDK) need not worry about idiosyncrasies of the underlying hardware platform. [[Special:Contributions/2409:4042:2D01:A237:0:0:5D8B:4703|2409:4042:2D01:A237:0:0:5D8B:4703]] ([[User talk:2409:4042:2D01:A237:0:0:5D8B:4703|talk]]) 11:27, 25 May 2022 (UTC) |
|||
Can't we get the actual name, ''Java Runtime Environment'' (abbreviation ''JRE'') back into this article? --[[User:Mortense|Mortense]] ([[User talk: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? [[User:Martijn Hoekstra|Martijn Hoekstra]] ([[User talk:Martijn Hoekstra|talk]]) 18:44, 29 January 2015 (UTC) |
|||
== Java script displaced Java applets and JVM too, wow but this article is about JVM not about JS == |
|||
: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. --[[User:Pdevaere|Pdevaere]] ([[User talk:Pdevaere|talk]]) 10:46, 5 March 2015 (UTC) |
|||
::This better? [[WP:BOLD|Feel free to make any edits that you think improve the article]]. [[User:Martijn Hoekstra|Martijn Hoekstra]] ([[User talk:Martijn Hoekstra|talk]]) 13:28, 5 March 2015 (UTC) |
|||
its ok but what about other languages compilers targeting JVM not JS, that goes in the JS article |
|||
:: 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. [[User:Pdevaere|Pdevaere]] ([[User talk:Pdevaere|talk]]) 06:31, 6 March 2015 (UTC) |
|||
$plastic machine and bussieness factory [[Special:Contributions/156.196.222.120|156.196.222.120]] ([[User talk:156.196.222.120|talk]]) 17:27, 3 July 2024 (UTC) |
|||
== Undoing revision 653853606 (Intro: Reword phrase that uses questionable terms.) == |
|||
& steel machine break and bussieness factory [[Special:Contributions/156.196.222.120|156.196.222.120]] ([[User talk:156.196.222.120|talk]]) 17:28, 3 July 2024 (UTC) |
|||
[https://en.wikipedia.org/w/index.php?title=Java_virtual_machine&curid=16389&diff=653853606&oldid=653330672 Java_virtual_machine&curid=16389&diff=653853606&oldid=653330672] |
|||
Java virtual machine and keyboard [[Special:Contributions/156.196.222.120|156.196.222.120]] ([[User talk:156.196.222.120|talk]]) 17:30, 3 July 2024 (UTC) |
|||
*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'''. |
|||
$ [[Special:Contributions/156.196.222.120|156.196.222.120]] ([[User talk:156.196.222.120|talk]]) 17:31, 3 July 2024 (UTC) |
|||
I want to point out that 1) both terms are not questionable and are used in this context, as the following headlines ilustrate |
|||
Paperwork factory [[Special:Contributions/156.196.222.120|156.196.222.120]] ([[User talk:156.196.222.120|talk]]) 17:32, 3 July 2024 (UTC) |
|||
* [http://www.epa.gov/pesticides/regulating/laws/fqpa/fqpa_implementation.htm '''Implementation of Requirements''' under the Food Quality Protection Act (FQPA)] |
|||
* [http://www.healthcareitnews.com/resource/making-healthcare-content-easier-share-hipaa-compliant-manner Making healthcare content easier to share '''in a''' HIPAA '''Compliant Manner'''] |
|||
* [http://www.mazars.co.za/Home/News/Articles/Walking-the-regulation-tightrope-in-a-socially-and-ethically-compliant-manner Walking the regulation tightrope '''in a''' socially and ethically '''compliant manner'''] |
|||
== Move discussion in progress == |
|||
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. <small><span class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:TvojaStara|TvojaStara]] ([[User talk:TvojaStara|talk]] • [[Special:Contributions/TvojaStara|contribs]]) 18:44, 31 March 2015 (UTC)</span></small><!-- Template:Unsigned --> <!--Autosigned by SineBot--> |
|||
There is a move discussion in progress on [[Talk:JVM (disambiguation)#Requested move 16 July 2024|Talk:JVM (disambiguation)]] which affects this page. Please participate on that page and not in this talk page section. Thank you. <!-- Talk:JVM (disambiguation)#Requested move 16 July 2024 crosspost --> —[[User:The Sky Bot|The Sky Bot]] 16:04, 17 July 2024 (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. [[Special:Contributions/66.155.23.67|66.155.23.67]] ([[User talk: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 [https://twitter.com/BoulderTodd @BoulderTodd] was responsible for the death of JonBenet Ramsey. Don't let this wicked man to get away with his wretched deeds!" <!-- Template:Unsigned --><small class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:YoruFeisu|YoruFeisu]] ([[User talk:YoruFeisu#top|talk]] • [[Special:Contributions/YoruFeisu|contribs]]) 18:34, 16 September 2017 (UTC)</small> <!--Autosigned by SineBot--> |
|||
== 64-bit == |
|||
⚫ | Regarding [https://en.wikipedia.org/w/index.php?title=Java_virtual_machine&diff=833609833&oldid=833181368 this edit] and [https://en.wikipedia.org/w/index.php?title=Java_virtual_machine&action=history 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. |
||
⚫ | |||
⚫ | 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. --[[User:Bigpeteb|Bigpeteb]] ([[User talk: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. [[User:Comp.arch|comp.arch]] ([[User talk: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."[https://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.7] 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). [[User:Comp.arch|comp.arch]] ([[User talk:Comp.arch|talk]]) 16:51, 15 July 2018 (UTC) |
Latest revision as of 16:04, 17 July 2024
This is the talk page for discussing improvements to the Java virtual machine article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
Archives: 1 |
![]() | This ![]() It is of interest to the following WikiProjects: | |||||||||||||||||||||||
|
![]() | This article links to one or more target anchors that no longer exist.
Please help fix the broken anchors. You can remove this template after fixing the problems. | Reporting errors |
64-bit
[edit]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)
Why was the section C to jvm compilers erased?
[edit]There are links to a section in this article about a list of C language compilers targeted for JVM. Where is that section? Bravo editors Boycotting Wikipedia! The pretext to erase that section is stupid Why should a section about C compilers targeting the JVM is a so strange subject deserving to be erased? I wont enter in and edition war, I just will search more reliable sources on the web. When I see thinks like this, I wonder if those Boycotting editors are paid to do that. Bravo, bravo, bravo!
oops concept
Current Version
[edit]I'd glad if someone could point out, why there is V15.x.y stated as current version (info box, citing a JDK download page), whereas the online installer from Oracle gives me V1.8.
Somewhere, I noticed that "15.x" is short for "1.15.x", but even then -- why is there 15 stated and I get 8? --2001:4DD4:F333:1:99E0:6841:8281:A0CA (talk) 22:25, 7 February 2021 (UTC)
Java
[edit]A Java virtual machine (JVM) is a virtual machine that enables a computer to run Java programs as well as programs written in other languages that are also compiled to Java bytecode. The JVM is detailed by a specification that formally describes what is required in a JVM implementation. Having a specification ensures interoperability of Java programs across different implementations so that program authors using the Java Development Kit (JDK) need not worry about idiosyncrasies of the underlying hardware platform. 2409:4042:2D01:A237:0:0:5D8B:4703 (talk) 11:27, 25 May 2022 (UTC)
Java script displaced Java applets and JVM too, wow but this article is about JVM not about JS
[edit]its ok but what about other languages compilers targeting JVM not JS, that goes in the JS article
$plastic machine and bussieness factory 156.196.222.120 (talk) 17:27, 3 July 2024 (UTC)
& steel machine break and bussieness factory 156.196.222.120 (talk) 17:28, 3 July 2024 (UTC)
Java virtual machine and keyboard 156.196.222.120 (talk) 17:30, 3 July 2024 (UTC)
$ 156.196.222.120 (talk) 17:31, 3 July 2024 (UTC)
Paperwork factory 156.196.222.120 (talk) 17:32, 3 July 2024 (UTC)
Move discussion in progress
[edit]There is a move discussion in progress on Talk:JVM (disambiguation) which affects this page. Please participate on that page and not in this talk page section. Thank you. —The Sky Bot 16:04, 17 July 2024 (UTC)
- C-Class vital articles
- Wikipedia level-5 vital articles
- Wikipedia vital articles in Technology
- C-Class level-5 vital articles
- Wikipedia level-5 vital articles in Technology
- C-Class vital articles in Technology
- C-Class Computing articles
- Unknown-importance Computing articles
- C-Class software articles
- Unknown-importance software articles
- C-Class software articles of Unknown-importance
- All Software articles
- All Computing articles
- C-Class Java articles
- Top-importance Java articles
- WikiProject Java articles