About: Jupiter JVM     Goto   Sponge   NotDistinct   Permalink

An Entity of Type : yago:Software106566077, within Data Space : dbpedia.org associated with source document(s)
QRcode icon
http://dbpedia.org/describe/?url=http%3A%2F%2Fdbpedia.org%2Fresource%2FJupiter_JVM

Jupiter JVM is an open-source Java virtual machine, which has been developed as a master thesis with modularity and extensibility in mind. It uses Boehm garbage collector and GNU Classpath. The Jupiter Virtual Machine main aspects of its design can be simplified as:

AttributesValues
rdf:type
rdfs:label
  • Jupiter JVM (en)
rdfs:comment
  • Jupiter JVM is an open-source Java virtual machine, which has been developed as a master thesis with modularity and extensibility in mind. It uses Boehm garbage collector and GNU Classpath. The Jupiter Virtual Machine main aspects of its design can be simplified as: (en)
foaf:name
  • Jupiter JVM (en)
foaf:homepage
name
  • Jupiter JVM (en)
dcterms:subject
Wikipage page ID
Wikipage revision ID
Link from a Wikipage to another Wikipage
Link from a Wikipage to an external page
sameAs
dbp:wikiPageUsesTemplate
discontinued
  • yes (en)
genre
latest release date
latest release version
license
website
has abstract
  • Jupiter JVM is an open-source Java virtual machine, which has been developed as a master thesis with modularity and extensibility in mind. It uses Boehm garbage collector and GNU Classpath. The Jupiter Virtual Machine main aspects of its design can be simplified as: * Memory locality - Objects are allocated on the heap with little or no consideration for locality. While this approach may be appropriate for uniprocessors or small-scale SMPs, it is unlikely to work well on a cluster of workstations where remote memory access is one or two orders of magnitude slower than local memory access. * - Garbage collection can consume a considerable amount of application time. Typically, JVMs employ "stop-the-world" garbage collectors, where program threads are halted during garbage collection. This approach will not work for large numbers of processors, for two reasons. First, the cost of "stopping the world" is considerably higher when the number of processors is large. Second, using a single thread to collect garbage results in an unacceptably large sequential fraction for any application. * Memory consistency model - To achieve scaling performance on many processors, it is important to exploit the "relaxed" Java Memory Model. Presently no JVM implements the JMM faithfully, and indeed many implement it incorrectly, leading to lack of coherence and loss of optimization opportunities. The specification of the JMM was also revised in 2007. * Efficient threads and synchronization - With many processors, it is critical to provide efficient threading support and synchronization mechanisms that scale well. (en)
gold:hypernym
prov:wasDerivedFrom
page length (characters) of wiki page
latest release date
latest release version
  • 1.0.0 beta
genre
license
foaf:isPrimaryTopicOf
is Link from a Wikipage to another Wikipage of
is Wikipage disambiguates of
is foaf:primaryTopic of
Faceted Search & Find service v1.17_git139 as of Feb 29 2024


Alternative Linked Data Documents: ODE     Content Formats:   [cxml] [csv]     RDF   [text] [turtle] [ld+json] [rdf+json] [rdf+xml]     ODATA   [atom+xml] [odata+json]     Microdata   [microdata+json] [html]    About   
This material is Open Knowledge   W3C Semantic Web Technology [RDF Data] Valid XHTML + RDFa
OpenLink Virtuoso version 08.03.3330 as of Mar 19 2024, on Linux (x86_64-generic-linux-glibc212), Single-Server Edition (378 GB total memory, 61 GB memory in use)
Data on this page belongs to its respective rights holders.
Virtuoso Faceted Browser Copyright © 2009-2024 OpenLink Software