The JaegerMonkey has landed.

And you might have noticed that it’s really fast. This is the world’s first third-generation JavaScript engine, using Baseline JIT technology similar to engines found in other browsers and kicked up a level with the Tracing engine found in Firefox 3.6. As such, we’re competitive on benchmarks such as Sunspider and V8, but we’re also fast at a whole mess of things that we expect to see in the set of next-generation web applications, hence Kraken.

SpiderMonkey
tracemonkey

各种monkey

Boris wrote on January 15th, 2011 at 8:31 pm:
1) I’m just guessing here, but I think the obvious generations for JS engines would be interpreter-only, jit, and multi-level jit with dynamic recompilation using a compiler that does more optimizations for the hot paths.
2) At the moment JagerMonkey only runs compiled code, but when we decide to trace a loop we drop back into the interpreter for one loop iteration, because the interpreter drives the trace recorder. That’s something we plan to probably change, but it was too much work to get it done in the Firefox 4 timeframe. There have also been some suggestions to run a function in the interpreter a few times before compiling it with JM, to save memory and in some cases time (because compilation costs time, and if a function runs only once it may not be worth compiling it).
3) Not sure what you mean by “based” on, but the tracer records a trace by getting callbacks from the interpreter with the opcodes the interpreter is interpreting. For now.

To better support PC-relative addressing of nmethod constant table entries on SPARC, the constants section should be moved before the instruction section.  This is a preparation for 6961690.

oops should be loaded from the constant table of an nmethod instead of materializing them with a long code sequence.

It's possible today to get cumulative per-thread cpu time via the ThreadMXBean.
It would be very useful to get the cumulative per-thread number of bytes allocated in the Java heap as well for resource management purposes.

As part of the JVM Convergence effort, we plan to enhance the JDK
JMX agent with select features from JRockit, including...

1. New commandline interface (jcmd) for basic JVM diagnostic commands
2. New Lifecycle support to independently start/stop the JMX agent
3. Support for select additional performance counters

This work is planned for JDK7, but requires substantial codebase
restructuring to align with HotSpot. Also, the project requires
careful thought around package organization and associated public,
private, and protected APIs. Work is ongoing and progressing nicely
towards a likely end of March initial delivery. We'll provide updates
and more details as the date approaches.

- Jim

oracletechnet Justin Kestelyn
Reinhold: big data support, improved data integration, metaobject protocol may also be themes in JDK9 #eclipsecon

IanSkerrett Ian Skerrett
Java 9 - continuation, value classes,big data, meta-object protocol, data integration. #eclipsecon

Leveled Garbage Collection by Guanshan Tong and Michael J. O'Donnell:

Generational garbage collection (GGC) is one of the most popular garbage collection techniques. GGC gains a performance advantage by performing minor collections on the younger objects in the heap, reducing the number of major collections of the whole heap. A promotion policy determines when an object moves from the younger generation to the older. The design of GGC has been justified by the plausible assumption that many objects die very young, and a few live a very long time. But, attempts to tune the performance of GGC by adjusting the promotion policy have been disappointing - only the simplest immediate promotion policy has proved attractive. The success of GGC is probably due to simplicity and to avoiding scans of the whole heap, rather than to accurate lifetime predictions.
This paper presents Leveled Garbage Collection (LGC), a new algorithm that is not based on object ages. It uses a heap structure and collection scheme similar to those of generational garbage collectors, and has a non-age-based promotion policy that doesn't promote all of the live objects, but still guarantees ample free space immediately after each garbage collection. By tuning LGC's promotion policy, we can often improve on GGC with immediate promotion.
Performance comparisons show that LGC outperforms GGC with immediate promotion policy in many cases, while losing only slightly on cases favorable to immediate promotion. LGC has a substantial advantage when the heap fits in main memory, and an even greater advantage as the heap gets paged to disk.

Leveled GC is based on a more general heuristic than generational GC, in that it tries to keep as many objects as possible in the nursery because minor collections are so much cheaper. What I found most interesting about this paper is that it scales well with virtual memory, which as we know can degrade performance significantly. They provide benchmarks demonstrating a marked difference when large heap sizes trigger paging (Section 5.2.2). LGC performance is hardly affected, while the runtime of generational GC degrades significantly.

From: Rémi Forax <forax@...>
Subject: Re: Projects, which use JSR292
Newsgroups: gmane.comp.java.openjdk.mlvm.devel
Date: 2011-02-15 17:53:18 GMT (7 hours and 42 minutes ago)
On 02/15/2011 06:13 PM, John Rose wrote:
> On Feb 15, 2011, at 6:50 AM, Kirill Shirokov wrote:
>
>> - JRuby by Charles Oliver Nutter
>> - PHP.reboot by Remi Forax
>> - Smalltalk implementation by Mark Roos (in progress)

And Java lambda in JDK8.
The current prototype already use JSR 292.

>
> I think this recent thread is about an OCaml implementation by Xavier Clerc:
>    http://mail.openjdk.java.net/pipermail/mlvm-dev/2011-February/002464.html

I have also a metaclass core prototype named Gru (as a possible core for
Groovy 2)
but it's far from being usable by anybody.
And a not yet finished implementation of JSR 292 on Android.

As an implementer, the first benefit of JSR 292 is to greatly simplify
the implementation
of several common patterns:
- invokedynamic+CallSite.setTarget() allows to easily implement any kind
of inlining caches
    (one element cache or bymorphic cache, tree of decision, etc.)
    which are the mothers of all optimizations of any dynamic languages.
- MutableCallSite.syncAll() allows to do thread safe deoptimization which is
   the root of all optimistic optimizations. No guard anymore ! (in
reality, less guards).
- MethodHandle give you lambda for free.
- Predefined method handles avoid code generation for doing the plumbing
   required by features like varargs, spreads, named parameters.
   i.e adaptation between the calling and the target method.
- MethodHandles.asInstance() avoid code generation when bridging Java
core interfaces like
   Comparator, Runnable, Callable and MethodHandle.
- invokedynamic bootstrap method ease the implementation of lazy
intialization.
- ClassValue ease the storage of Class metadata.
- invokedynamic bootstrap method constants ease the storage of callsite
metadata.

And I'm sure I forget some features.

The second benefit is performance.
Some performance improvement are already visible by example using metod
handle for
doing reflection is more efficient than using java.lang.reflect
especially when you deal with primitive types.
Some improvement are yet to appear like inlining of the whole callsite
target tree.
Some will come later just because they require more works

About performance of the dynamic language runtimes, because JSR 292
simplifies
the implementation of the runtime, I expect that existing runtime will
introduce
more optimizations just because the code is now simpler. PHP.reboot is
all about that.

> -- John

Rémi

@headius: Maxine VM appears to be only 2.5x slower than Hotspot client mode now, and still 99.9% written in Java: https://gist.github.com/836314

@@ -434,10 +434,17 @@
     if (supports_lzcnt()) {
       if (FLAG_IS_DEFAULT(UseCountLeadingZerosInstruction)) {
         UseCountLeadingZerosInstruction = true;
       }
     }
+
+    // On family 21 processors default is no sw prefetch
+    if ( cpu_family() == 21 ) {
+      if (FLAG_IS_DEFAULT(AllocatePrefetchStyle)) {
+        AllocatePrefetchStyle = 0;
+      }
+    }
   }
 
   if( is_intel() ) { // Intel cpus specific settings
     if( FLAG_IS_DEFAULT(UseStoreImmI16) ) {
       UseStoreImmI16 = false; // don't use it on Intel cpus

Method.invoke(), Contrstuctor.newInstance() and Field.getFieldAccessor() all have a needless
critical section, causing large slowdowns. This patch a replaces the synchronizations by volatile
references. Finally, the changes remove a doubled reference to another volatile variable.  This also
simplifies the generated code by commoning up the corresponding load instruction used in the fast
execution path.

Speedups from this change are uniformly 2x or better.

The proposed improvement and patch was originated by John Rose.

Thanks,

Mike

I just discovered that the ARM-specific interpreter stuff that Ed Nevill wrote (and then abandoned) last year has a hack that disables it when run with -XX:+PrintCommandLineFlags. I guess this is one problem when you have 6,000 lines of assembler nobody understands: you don’t know what secret weird sh*t is buried in there.

From Stephen.Bohne at Sun.COM  Wed Jan  2 08:02:21 2008
From: Stephen.Bohne at Sun.COM (Steve Bohne)
Date: Wed, 02 Jan 2008 11:02:21 -0500
Subject: Advice of how to implement ahead of time compilation.
In-Reply-To: <daa40b5d0712261042l7b0d9bc7pb690151b42f726db@mail.gmail.com>
References: <daa40b5d0712261042l7b0d9bc7pb690151b42f726db@mail.gmail.com>
Message-ID: <477BB58D.9080404@sun.com>

Hi Ram?n,

Ram?n Garc?a wrote:
> Hello,
>
> I am interested in implementing ahead of time compilation. Testing
> with Mono (a free .NET implementation) I see that ahead of time
> compilation greatly improves startup time, turning about 0.7 s of a
> compilation (equivalent to javac) into 0.08 s. Therefore, I think that
> it would be useful to have this option for interactive applications,
> that could be compiled to native during installation, and then
> executed directly. This would not harm the cross platform nature of
> Java, because applications would be still distributed in bytecode
> format.
>
> I need advice about what path should I follow.
>
> - One way would be to extend the current support of class data sharing
> to user supplied code, so that the virtual machine could load several
> data sharing archives, one for the system classes, and another for the
> current application.

First you'd have to extend class data sharing to cache compiled system
code, which it doesn't do.  (Maybe that was already implied in what you
wrote.)

FWIW, a while back we did some internal experiments to determine the
benefit of caching compiled code for client/desktop type applications.
At the time there wasn't much benefit.  The consensus explanation was
that the HotSpot client compiler is actually very fast to compile code,
and the initial interpreter + compilation overhead doesn't cost all that
much for real applications.

That is not to say that a well optimized AOT scheme couldn't have
benefit - just some anecdotal evidence.

>
> - An alternative method, the virtual machine would load a shared
> library containing the compiled application code. Tools must be
> provided to compile a collection of classes (and JARS) into a shared
> library, where all internal references are resolved.

It seems like the first option would be easier to port and maintain.
The class data sharing archive file format is the same across all
platforms we support, while shared libraries aren't.

Steve

>
> I see that unit of compilation must be the classloader, that is,
> classes intended to be loaded in the same classloader should be
> compiled together. Otherwise, it would be incorrect to compile a call
> to a class into a concrete call, because one cannot know if the class
> referenced will be overridden by some other class earlier in the
> classpath; and it seems that linking is an important part of compiling
> time. In fact, the JSR 294 of Java Superpackages subtitle says
> "Language extensions in support of information hiding and separate
> compilation". I understand that the mechanism of superpackages, by
> modifying the access rules, allow one class to be compiled knowing
> which concrete classes is referenced, and thus make it possible ahead
> of time compilation of the superpackage into a shared library.
>
> Ramon

jdk的这个bug(6u23/6u24里当设置了java.io.tmpdir后，jps、jstack等就不能用了)还是挺要命的，为啥优先级只是low呢，郁闷，看来还是用openjdk自己compile的靠谱

Oracle is converging the HotSpot and JRockit JVMs to produce a "best of breed JVM". Internally the project is sometimes referred to as the HotRockit project. There is already a large influx of ideas and solutions provided by the JRockit JVM into the Open JDK.

Examples of improvements include:
·Better monitoring and profiling
·Improved performance
·Better ergonomics
This talk will discuss what to expect from the converged JVM over the next two years, and how this will benefit the Eclipse community.

It took us years to learn to optimize calls to Java methods.  Now we are beginning to learn how to optimize uses of method handles.  This new learning curve won't take as long as the old one, since we can reuse our existing knowledge.  But it won't be instantaneous either.  I expect both JDK 7 and JDK 8 to include important performance improvements to method handles and invokedynamic.

To help us track our progress and manage our tuning work, we will (from time to time) file issues having to do with JSR 292 performance.

Issue 7023639 applies to people who are using method handles as function pointers for Java.  If this affects your use of 292, please let us know.

Other issues likely to arise have to do with performance disparities between method handles obtained from MethodHandles.Lookup and the corresponding bytecoded and reflective operations.

Onward!

-- John Rose

P.S. Here's the bug text:

7023639 JSR 292 method handle invocation needs a fast path for compiled code

This is a tracking issue for calls to non-constant method handles to and from "hot" compiled code.

Internally to the JVM, method handle argument list transformations are implemented on the interpreter stack.  This means that when compiled code invokes a method handle with argument transforms, it goes through a C2I adapter, transforms the argument list in interpreted format, and then (presumably) goes through an I2C adapter.

At least the most important transforms should go through customized code.  These include:
- direct access (no transforms)
- receiver binding (the bindTo transformation)
- trivial asType transformations
- invokeGeneric (argument and return value conversions to and from Object)

Probably all of the core transforms on MethodHandle virtual methods (not necessarily MethodHandles static methods) should get favorable treatment for compiled-to-compiled calls.

An important customer is Project Lambda, which should be using method handles in preference to anonymous classes.  Getting the above paths right for compiled code will enable this choice.

Note that this bug does not apply to users invokedynamic, since method handles at invokedynamic call sites are routinely inlined into optimized code.