Re: [9] RFR (XS): 8071787: Don't block inlining when DONT_INLINE_THRESHOLD=0

[John Rose]

Good.  Consider fixing the typo in 'makeBlockInlningWrapper'.  — John

On Jan 28, 2015, at 9:12 AM, Vladimir Ivanov  
wrote:
> 
> http://cr.openjdk.java.net/~vlivanov/8071787/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8071787
> 
> For testing & performance measurements, sometimes it's useful to replace 
> block inlining wrappers with trivial reinvokers.
> 
> This change extends DONT_INLINE_THRESHOLD in the following manner:
>  DONT_INLINE_THRESHOLD = -1: no wrapper
>  DONT_INLINE_THRESHOLD =  0: reinvoker
>  DONT_INLINE_THRESHOLD >  0: counting wrapper
> 
> Before that DONT_INLINE_THRESHOLD=0 meant a counting wrapper which is removed 
> on the first invocation. After the change, it's DONT_INLINE_THRESHOLD=1.
> 
> Testing: manual, java/lang/invoke
> 
> Best regards,
> Vladimir Ivanov

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: [9] RFR (XXS): 8071788: CountingWrapper.asType() is broken

[John Rose]

Good.

On Jan 28, 2015, at 9:22 AM, Vladimir Ivanov  
wrote:
> 
> The fix is to use adapted MethodHandle to construct LambdaForm.

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

What's the status of / relation between "JEP 169: Value Objects" / "Value Types for Java" / "Object Layout"

[Volker Simonis]

Hi everybody,

I've recently did some research on Java "value objects" / "value
types" / "object layout" (I'll be actually giving a short talk on the
topic at FOSDEM[0] this weekend). I just want to quickly summarize my
current findings here and gently ask for feedback in case you think
I've totally misunderstood something. Of course any comments and
additional information is highly welcome as well.

1. JEP 169: Value Objects [1]
 - Created by John Rose in 2012 (last update in Sep. 2014)
 - Still in "Draft" state
 - Proposes a new "lockPermanently()" operator which marks objects as immutable
 - Seems to be only a little "helper functionality" to simplify
automatic boxing/unboxing and escape analysis
 - Referenced the mlwm mailing list and repository but the mlwm repo
seems dead since about 15 month now

Question: is JEP 169 still under active development or has it been
merged into the more general "Value types for Java" proposal below?

2. "Value types for Java" / "State of the Values" [2]
 - By J. Rose, B. Goetz and Guy Stele
 - Based on earlier ideas from "Value Types in the VM" [3]
 - Newest and most elaborate proposal
 - Proposes general (i.e. function arguments, return values,
variables, arrays), "immutable" value types
 - Requires fundamental changes to the VM as well as to the Java language
 - Related to the "State of the Specialization" proposal [4] about
support for generics over primitive and value types by B Goetz.
 - Discussed and developed in the OpenJDK "Valhalla" [5] project
 - Still very early stage (i.e. no "code" available yet)

3. PackedObjects as provided by the IBM J9 [6,7]
 - Flattens the memory layout of "@Packed" object fields and array
 - Removes object headers of and references to "@Packed" objects
 - Object headers can be generated on the fly (kind of "auto-boxing")
 - Currently the most complete and mature solution
 - Not Java-compatible (e.g. can not write to a nested "@Packed"
fields). Must be enabled as an experimental extension.

4. ObjectLayout [8]
 - A pure Java, layout-optimized data structure package
 - Designed similar to "@ValueSafe"/"ValueType" in [3] and "Value-base
classes" in Java 8 [9]
 - Designed such that it can be tranparently optimized within the VM
 - VM can transparently layout "@Intrinsic" objects within other objects
 - All objects are still complete Java object with valid header
 - The Java part of the library is mature, first native
VM-optimizations on the way [10]

The "Value types for Java" approach clearly seems to be the most
general but also the most complex proposal. It's out of scope for Java
9 and still questionable for Java 10 and above. The "PackedObject" and
"ObjectLayout" approaches are clearly simpler and more limited in
scope as they only concentrate on better object layout. However the
"ObjectLayout" proposal demonstrates that this is still possible
within the current Java specification while the "PackedObjects"
proposal demonstrated that an optimizing implementation is feasible.
I've recently built a prototype which intrinsifies/optimizes some
parts of the "ObjectLayout" proposal in the HotSpot [10].

Question: is there a chance to get a some sort of Java-only but
transparently optimizable structure package like "ObjectLayout" into
Java early (i.e. Java 9)?

In my eyes this wouldn't contradict with a more general solution like
the one proposed in the "Value types for Java" approach while still
offering quite significant performance improvements for quite a big
range of problems. And if carefully designed, it could be easily
retrofitted to use the new, general "Value Types" once they are
available.

Question: what would be the right place to propose something like the
"ObjectLayout" library for Java 9/10? Would that fit within the
umbrella of the Valhalla project or would it be done within its own
project / under it's own JEP?

Thanks for your patience,
Volker


[0] https://fosdem.org/2015/schedule/event/packed_objects/
[1] http://openjdk.java.net/jeps/169
[2] http://cr.openjdk.java.net/~jrose/values/values-0.html
[3] https://blogs.oracle.com/jrose/entry/value_types_in_the_vm
[4] http://cr.openjdk.java.net/~briangoetz/valhalla/specialization.html
[5] http://openjdk.java.net/projects/valhalla
[6] 
http://www.slideshare.net/rsciampacone/javaone-2013-introduction-to-packedobjects?related=1
[7] http://medianetwork.oracle.com/video/player/2623645005001
[8] http://objectlayout.org
[9] http://docs.oracle.com/javase/8/docs/api/java/lang/doc-files/ValueBased.html
[10] 
https://github.com/simonis/ObjectLayout/tree/hotspot_intrinsification/hotspot
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: [9] RFR (M): 8063137: Never-taken branches should be pruned when GWT LambdaForms are shared

[John Rose]

On Jan 28, 2015, at 1:00 AM, Vladimir Ivanov  
wrote:
> I polished the change a little according to your comments (diff against v03):
> http://cr.openjdk.java.net/~vlivanov/8063137/webrev.03-04/hotspot 
> 

+1  Glad to see the AndI folds up easily; thanks for the cleanup.___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

[9] RFR (XXS): 8071788: CountingWrapper.asType() is broken

[Vladimir Ivanov]

http://cr.openjdk.java.net/~vlivanov/8071788/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8071788

There's a type mismatch between MethodHandle and LambdaForm in 
CountingWrapper.asTypeUncached(). Sometimes, it leads to a VM crash.


The fix is to use adapted MethodHandle to construct LambdaForm.

There's no way to reproduce this problem with vanilla 8u40/9 binaries, 
because CountingWrapper is used only to block inlinining in GWT 
(MHI::profile() on target and fallback MethodHandles).


It means there's no way to call CountingWrapper.asType() on wrapped 
MethodHandles outside of java.lang.invoke code, and there are no such 
calls inside it.


Testing: manual, java/lang/invoke

Thanks!

Best regards,
Vladimir Ivanov
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

[9] RFR (XS): 8071787: Don't block inlining when DONT_INLINE_THRESHOLD=0

[Vladimir Ivanov]

http://cr.openjdk.java.net/~vlivanov/8071787/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8071787

For testing & performance measurements, sometimes it's useful to replace 
block inlining wrappers with trivial reinvokers.


This change extends DONT_INLINE_THRESHOLD in the following manner:
  DONT_INLINE_THRESHOLD = -1: no wrapper
  DONT_INLINE_THRESHOLD =  0: reinvoker
  DONT_INLINE_THRESHOLD >  0: counting wrapper

Before that DONT_INLINE_THRESHOLD=0 meant a counting wrapper which is 
removed on the first invocation. After the change, it's 
DONT_INLINE_THRESHOLD=1.


Testing: manual, java/lang/invoke

Best regards,
Vladimir Ivanov
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: [9] RFR (M): 8063137: Never-taken branches should be pruned when GWT LambdaForms are shared

[Vladimir Ivanov]

Looking very good, thanks.  Ship it!

Thanks, John!


Actually, can you insert a comment why the injected counts are not scaled?  (Or 
perhaps they should be??)
Sure! I intentionally don't scale the counts because I don't see any 
reason to do so. Profiling is done on per-MethodHandle basis, so the 
counts should be very close (considering racy updates) to the actual 
behavior.



Also, we may need a followup bug for the code with this comment:
   // Look for the following shape: AndI (ProfileBoolean) (ConI 1))

Since profileBoolean returns a TypeInt::BOOL, the AndI with (ConI 1) should 
fold up.
So there's some work to do in MulNode, which may allow that special pattern 
match to go away.
But I don't want to divert the present bug by a possibly complex dive into 
fixing AndI::Ideal.

Good catch! It's an overlook on my side.
The following change for ProfileBooleanNode solves the problem:
-  virtual const Type *bottom_type() const { return TypeInt::INT; }
+  virtual const Type *bottom_type() const { return TypeInt::BOOL; }

I polished the change a little according to your comments (diff against 
v03):

http://cr.openjdk.java.net/~vlivanov/8063137/webrev.03-04/hotspot

Changes:
  - added short explanation why injected counts aren't scaled

  - adjusted ProfileBooleanNode type to TypeInt::BOOL and removed 
excessive pattern matching in has_injected_profile()


  - added an assert when ProfileBooleanNode is removed to catch the 
cases when injected profile isn't used: if we decide to generalize the 
API, I'd be happy to remove it, but current usages assumes that injected 
counts are always consumed during parsing and missing cases can cause 
hard-to-diagnose performance problems.


Best regards,
Vladimir Ivanov



(Generally speaking, pattern matching should assume strong normalization of its inputs.  Otherwise 
you end up duplicating pattern match code in many places, inconsistently.  Funny one-off idiom 
checks like this are evidence of incomplete IR normalization.  See 
http://en.wikipedia.org/wiki/Rewriting for some background on terms like "normalization" 
and "confluence" which are relevant to C2.)

— John

On Jan 27, 2015, at 8:05 AM, Vladimir Ivanov  
wrote:


Thanks for the feedback, John!

Updated webrev:
http://cr.openjdk.java.net/~vlivanov/8063137/webrev.03/jdk
http://cr.openjdk.java.net/~vlivanov/8063137/webrev.03/hotspot

Changes:
  - renamed MHI::profileBranch to MHI::profileBoolean, and ProfileBranchNode to 
ProfileBooleanNode;
  - restructured profile layout ([0] => false_cnt, [1] => true_cnt)
  - factored out profile injection in a separate function 
(has_injected_profile() in parse2.cpp)
  - ProfileBooleanNode stores true/false counts instead of taken/not_taken 
counts
  - matching from value counts to taken/not_taken happens in 
has_injected_profile();
  - added BoolTest::ne support
  - sharpened test for AndI case: now it checks AndI (ProfileBoolean) (ConI 1) 
shape

Best regards,
Vladimir Ivanov



___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev