gmane.comp.java.openjdk.hotspot.compiler.devel

Re: vcall wish for hotspot

Remi Forax — 2013-05-19T10:57:37

I agree :)
and a debug VM is not a requirement anymore
https://wiki.openjdk.java.net/display/HotSpot/PrintAssembly


Rémi

Re: vcall wish for hotspot

Andrew Haley — 2013-05-19T09:38:56

If I were you I'd stop guessing, build a debug hotspot, and have a look
at the generated code.  The is no substitute.

Andrew.

Re: vcall wish for hotspot

Andy Nuss — 2013-05-19T04:37:42

Well, I guess I don't know what I'm doing after all.

I ported my benchmark to C++, and found that C++ overhead for the virtual call was 6 nanos, way slower than  the 0.5 nanos I was getting for hotspot.

Then I guessed, maybe Clemens is right, hotspot is seeing that Link1 and Link2 are very similar in structure, and even though the iteration thru the list of base types would seem to force a virtual call, hotspot is just turning it into an if-else, and inlining everything else, and the extra 0.5 nanos is simply due to branch mispredict.


So I create 10 variants of my Link class, Link1 thru Link10, and hotspot was about the same as C++, 6 nanos.

But that could mean that hotspot was now using a vtable, or it could mean hotspot was paying for 10 branch mispredictions.

So I tried 20 variants of my Link class, Link1 thru Link20, and hotspot was now about 11 nanos.  So it would seem that hotspot, for simple variants of a base class doesn't use a vtable at all, but just creates one big if-else inline.  Wherea

Re: vcall wish for hotspot

Andy Nuss — 2013-05-19T00:18:32

Ok guys.  I'll try to get setup with github, and provide both cases for you with latest C++ and latest jdk7, or redact my claim.

By the way, there are no branches, as you will see from my benchmark.

________________________________
 From: Clemens Eisserer <linuxhippy-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>
To: Andy Nuss <andrew_nuss-/E1597aS9LQAvxtiuMwx3w< at >public.gmane.org>; hotspot-dev-0nJqbsLSQw0FDOXUYO6UHQ< at >public.gmane.org 
Sent: Saturday, May 18, 2013 4:22 PM
Subject: Re: vcall wish for hotspot

Hi Andy,

You have not benchmarked it, yet claim to "know" C++ compilers emot
"much much" faster code for this case?

The difference you see with your benchmark is not only the pure
overhead of bimorphic call logic, but far more important, branch
misprediction caused by the alternating branch targets.

- Clemens

Re: vcall wish for hotspot

Andy Nuss — 2013-05-18T16:20:30

After stuggling for some time for an easy way to force jvm to make bimorphic call and compare it with the same iterative loop not doing so, I hit upon this:

public class Test {

     private static Randomrandom = new Random();

     abstract class Link {
           Link next;
           abstract int get ();

     }

     class Link1 extends Link {
            private int v = random.nextInt();
            int get ()
            {
                  return v+1;
             }
      }

      clase Link2 extends Link {
              private int v = random.nextInt();
              int get ()
              {
                     return v+2;
              }
      }

      class Link3 {
             Link3 next;
             private int v = random.nextInt();
             int get ()

Re: vcall wish for hotspot

Andrew Haley — 2013-05-18T14:59:26


Is this benchmark available somewhere?


How much faster?


I think so.  But does it matter whether a class has interfaces?  Many
of them do, even if it's just something like Cloneable.

Andrew.

Re: RFR (S) : 8014362 : Need to expose some processor features viaUnsafe interface

Christian Thalinger — 2013-05-18T01:51:53

On May 17, 2013, at 2:28 PM, David Chase <david.r.chase-QHcLZuEGTsvQT0dZR+AlfA< at >public.gmane.org> wrote:


"true" :) "false"

What's the smiley doing there?  Is this all a joke?  True or false?

hg: hsx/hotspot-comp/hotspot: 37 new changesets

2013-05-18T01:25:25

Changeset: 1cdbd42c3e49
Author:    katleman
Date:      2013-05-16 12:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1cdbd42c3e49

Added tag jdk8-b90 for changeset 1ae0472ff3a0

! .hgtags

Changeset: 712a1e9c91f3
Author:    coleenp
Date:      2013-05-07 09:46 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/712a1e9c91f3

8013063: nsk/jvmti/RetransformClasses/retransform001 failed debug version on os::free
Summary: Clear out class_file_bytes so they aren't deallocated twice
Reviewed-by: dcubed, sspitsyn

! src/share/vm/prims/jvmtiRedefineClasses.cpp

Changeset: 4674e409a9e6
Author:    coleenp
Date:      2013-05-07 18:51 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4674e409a9e6

8014024: NPG: keep compiled ic methods from being deallocated in redefine classes
Summary: Walk the compiledIC relocation records to keep Method* from being deallocated.
Reviewed-by: dlong, kvn

! src/share/vm/code/nmethod.cpp

Changeset: a1cc1d1e7ce5
Autho

Re: RFR (L): JDK-8014786: Cleaning up the split code in the registerallocator of C2

Vladimir Kozlov — 2013-05-18T00:03:30

Can the fix be done separate from clean up to make sure it is the cause 
of regression?
The main part of changes is renaming. It would be nice to push it 
separate because it is hard to see the fix and other changes.
It will also help bugs tail analysis.

I would suggest to do it next steps as separate changes:

1. Make bugs fix first.
2. Variables and methods renaming: lrgs --> live_ranges and others.
3. Make changes in reg_split.cpp without renaming - we can't do review 
of current changes in split.cpp. Why you need to rename it?

In general, do not make changes which are hard to review.

And you can ignore jetstream results - they are not reliable.
I also surprise that your stdev is so small.

Thanks,
Vladimir

RFR (L): JDK-8014786: Cleaning up the split code in the registerallocator of C2

Niclas Adlertz — 2013-05-17T23:37:03

Hi all.

I've been trying to refactor and cleanup the split code currently located at src/share/vm/opto/reg_split.cpp. Here is the result of that.
This fix also fixes bugs https://jbs.oracle.com/bugs/browse/JDK-8005956 and https://jbs.oracle.com/bugs/browse/JDK-8013830. 
The first bug is resolved by removing rematerialization of reaches to phi nodes. 
This comes with a slight performance degradation [0]. However, since this rematerialization is causing JVM crashes, I would say it's worth it.

When reviewing this fix, please use the existing reg_split.cpp found at src/share/vm/opto/reg_split.cpp as a reference. 

JBS: https://jbs.oracle.com/bugs/browse/JDK-8014786
WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8014786/webrev00/

Kind Regards,
Niclas Adlertz

[0] Results from refworkload on 1) x64 Linux and 2) SPARCV9 Solaris. 
Baseline and fix with 12 iterations each. 

1) x64 Linux
============================================================================
refworkload_base: reference_server
  Benchmark

Re: RFR (S) : 8014362 : Need to expose some processor features viaUnsafe interface

Vladimir Kozlov — 2013-05-17T22:01:42

Good.

Thanks,
Vladimir

On 5/17/13 2:28 PM, David Chase wrote:

Re: RFR (S) : 8014362 : Need to expose some processor features viaUnsafe interface

David Chase — 2013-05-17T21:28:39

There was a spacing change that did not get reverted.
This time, for sure.
Note that this sets a property that won't get reset without a companion change in the JDK.
(And the companion change is getting a bit of a pushback, though I hope to find, once I digest
all the benchmarks I ran this afternoon, that it's not as scary as feared.)

http://cr.openjdk.java.net/~drchase/8014362/webrev.04

On 2013-05-17, at 4:30 PM, Vladimir Kozlov <vladimir.kozlov-QHcLZuEGTsvQT0dZR+AlfA< at >public.gmane.org> wrote:

Re: RFR (S) : 8014362 : Need to expose some processor features viaUnsafe interface

Vladimir Kozlov — 2013-05-17T20:30:02

Somehow globals.hpp showed up in the webrev. Otherwise changes are good.

Vladimir

On 5/17/13 1:28 PM, David Chase wrote:

Re: RFR (S) : 8014362 : Need to expose some processor features viaUnsafe interface

David Chase — 2013-05-17T20:28:28

New webrev:

http://cr.openjdk.java.net/~drchase/8014362/webrev.03/

It compiles (and runs) on both x86 and Sparc.

David

On 2013-05-16, at 11:32 PM, Vladimir Kozlov <vladimir.kozlov-QHcLZuEGTsvQT0dZR+AlfA< at >public.gmane.org> wrote:

Re: RFR (XS): JDK-8014430: JRE crashes instead of stop compilationon full Code Cache. Internal Error (c1_Compiler.cpp:87)

Vladimir Kozlov — 2013-05-17T17:24:03

Albert,

I assigned 7170965 to you. Close it if it is duplicate (which is, I 
think). But there is no mach info there (no call stack).

Could you check all places in C1 which may ask for allocation in codecache?

Thanks,
Vladimir

On 5/17/13 10:05 AM, Christian Thalinger wrote:

Re: RFR (XS): JDK-8014430: JRE crashes instead of stop compilation onfull Code Cache. Internal Error (c1_Compiler.cpp:87)

Christian Thalinger — 2013-05-17T17:05:53

On May 17, 2013, at 6:21 AM, Albert Noll <albert.noll-QHcLZuEGTsvQT0dZR+AlfA< at >public.gmane.org> wrote:


src/share/vm/c1/c1_Compiler.cpp:

  97     env->record_failure("Full CacheCache\n");

Typo.  In fact, can we use the same failure message as C2?

    C->record_failure("CodeCache is full");

Otherwise this looks good to me.

Re: vcall wish for hotspot

Andy Nuss — 2013-05-17T15:57:07

By the way, I have a simple abstract class with 2 abstract functios (before(), and after()), that are a big bottleneck in my program because generally the impls for before() and after() involve just incrementing counters in the parent class (as the impl of the abstract class is provided by an inner class).  There might be lots of programs like this, and fixing the performance for pure abstract calls for class hierarchies that have no interfaces would not only correct a big performance delta relative to C++ for simple vcalls, but would make downcasts for such classes also much much faster when the programmer needs to make downcasts.

Then this funny quote from My Bunny would no longer be true:

http://www.jelovic.com/articles/why_java_is_slow.htm


And there would be less need for hotspot to aggressively inline small functions, consequently less bloat relative to C++ programs, and maybe even less need for hotspot to even identify and target certain functions that do simple composition wrapper forwarding as n

vcall wish for hotspot

Andy Nuss — 2013-05-17T15:40:03

Hi,

I profiled virtual calls on a very fast machine (core i7) after Aleksey pointing out some micro benchmark deficiencies in my benchmarking technique.  Corrected those.

Nailed down the time of a virtual call on core i7: with or without interfaces involved, if a bimorphic call is enforced on hotspot due to inability to inline, the overhead is very close to 0.5 nanos, whether the method is in the base class or in an interface.

Knowing nothing about java's evolving design for interfaces and generics, I do know that C++ compilers can emit much much faster vcalls, especially when the class is not involving multiple inheritance.

My wish:

That if Java knows that a class does not have interfaces, then theoretically, the bimorphic call thru the vtable of such a class should approach C++ speeds.

Is this wish ever achievable?

Andy

Re: RFR (XS): JDK-8014430: JRE crashes instead of stop compilationon full Code Cache. Internal Error (c1_Compiler.cpp:87)

Albert Noll — 2013-05-17T13:21:25

Hi,

I implemented the same behavior for C1 as there is in C2, if there is 
insufficient memory in the code cache to instantiate the compiler. I.e., 
only the interpreter is used.

However, I am not quite sure if the current patch considers all 
variables that must be set (if there are any?) when compilation is 
aborted due to insufficient memory. So please take a close look!

Many thanks,
Albert

webrev: http://cr.openjdk.java.net/~anoll/8014430/webrev.01/

On 16.05.2013 17:57, Vladimir Kozlov wrote:

hg: hsx/hotspot-comp/langtools: 17 new changesets

2013-05-17T04:27:09

Changeset: ed918a442b83
Author:    jlahoda
Date:      2013-04-17 15:54 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/ed918a442b83

8008174: DocTree API should provide start and end positions for tree nodes
Summary: Adding DocSourcePositions to allow access to DocTree starting/ending position
Reviewed-by: jjg, darcy
Contributed-by: Ralph Benjamin Ruijs <ralphbenjamin-gVrGfPuBK2Jg9hUCZPvPmw< at >public.gmane.org>, Jan Lahoda <jlahoda-gVrGfPuBK2Jg9hUCZPvPmw< at >public.gmane.org>

+ src/share/classes/com/sun/source/util/DocSourcePositions.java
! src/share/classes/com/sun/source/util/DocTrees.java
! src/share/classes/com/sun/source/util/SourcePositions.java
! src/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/share/classes/com/sun/tools/javac/parser/DocCommentParser.java
! src/share/classes/com/sun/tools/javac/tree/DCTree.java
+ test/tools/javac/doctree/positions/TestPosition.java
+ test/tools/javac/doctree/positions/TestPosition.out
+ test/tools/javac/doctree/positions/TestPositi

hg: hsx/hotspot-comp/nashorn: 40 new changesets

2013-05-17T04:28:13

Changeset: aa8170c0dec9
Author:    sundar
Date:      2013-04-15 20:12 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/aa8170c0dec9

8012240: Array.prototype.map.call({length: -1, get 0(){throw 0}}, function(){}).length does not throw error
Reviewed-by: lagergren, jlaskey

! src/jdk/nashorn/internal/runtime/arrays/MapIterator.java
+ test/script/basic/JDK-8012240.js

Changeset: 486d92559c37
Author:    sundar
Date:      2013-04-17 16:52 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/486d92559c37

8012457: Function.prototype.apply should accept any array-like argument for function arguments
Reviewed-by: lagergren, jlaskey

! src/jdk/nashorn/internal/objects/NativeFunction.java
+ test/script/basic/JDK-8012457.js

Changeset: d4468316fe73
Author:    jlaskey
Date:      2013-04-17 08:48 -0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/d4468316fe73

Merge


Changeset: 04b36c02c0e2
Author:    jlaskey
Date:      2013-04-17 15:36 -0300
URL: