Edge Rewrite
// HTMLRewriter · presentation

This page was redesigned at the edge.

Cloudflare fetched the original article and streamed it through HTMLRewriter to apply an entirely new visual system without rebuilding the source page.

// request.cf · coarse context

A page that knows where it met you.

Only coarse request metadata is shown. This demo does not display or persist visitor IP addresses.

Country
US
Cloudflare location
CMH
Connection
HTTP/2
Language
Not provided

Ray ID: a2348a0e4f28e88e

Jump to content

// Workers AI · dad joke modeWhy did Jupiter JVM go to therapy? It had a gas with its virtual issues.

From Wikipedia, the free encyclopedia
Jupiter JVM
Final release
1.0.0 beta / July 15, 2002 (2002-07-15)
TypeJava Virtual Machine
LicenseGPL
Websitewww.eecg.toronto.edu/jupiter

Jupiter JVM is an open-source Java virtual machine,[1] which was developed as a master thesis with modularity and extensibility in mind. It uses Boehm garbage collector and GNU Classpath. The 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.
  • Parallel garbage collection - 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.

See also

[edit]

References

[edit]
  1. "The Jupiter Project". www.eecg.toronto.edu. Retrieved 2024-11-19.
[edit]