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

[Daniel Latrémolière]

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.
I don't know if that can be useful, but here is my point of view of 
developer oriented towards the question: "What feature for solving my 
problem?". This contains probably some or many errors, but it is another 
point of view (only mine), if useful.


I will not use strictly projects/proposal list as the structure of my 
mail because content of proposal is changing and it is not my target. I 
am oriented towards the final user, i.e. the developer consuming these 
projects, not the implementer working in each of these projects.


I will preferably split in three scopes following my perceived split of 
job between developer and runtime. The problem is data, then what can do 
JVM/GC with an object? I find two possibilities regarding this domain: 
move it, clone it.


If JVM can clone the object, JVM can also move the object because the 
clone will not have the same address, then we have the following three 
features:

---
1) JVM can clone and move objects (Project Valhalla):
Constraint: no complex constructor/no complex finalizer, because 
lifecycle of object is managed by JVM (JVM can clone, then JVM can 
create and destroy the object like JVM want). Only field affectation 
constructor, possibly with simple conversion of data format.
Constraint: immutable, because we don't know which clone is good when 
one is modified and because modifying all clones simultaneously is 
slow/complex/parallel-unfriendly.
Constraint: non-null because cloning a non-existing object is a 
non-existing problem.


Use-case "Performance": objects to clone for being closer to execution 
silicon and better parallelism (registers or cache of CPU/GPU)
- Runtime: expose features of CPU/GPU like SIMD (mostly like a modern 
version of javax.vecmath).
- Developer: create custom low-level structures for CPU/GPU parallel 
computing.
- Java language: small tuples, like complex numbers (immutable by 
performance choice, like SIMD, for being close to silicon; cloned at 
each pass by value).


Use-case "Language": objects to clone for being closer to registers (in 
stack, then less allocations in heap; simpler than escape analysis)
- Java language: multiple return values from a method (immutable because 
it's a result; cloned, by example, at the return of each delegate or not 
even created when stack-only).


Use-case "Efficiency": others immutable non-null objects possibly 
concerned for reducing indirection/improving cache, given by 
specialization of collection classes
- Database: primary key for Map (like HashMap)/B-Tree (like MapDB)/SQL 
(like JPA). A primary key is immutable and non-null by choice of 
developer, then possible gains.

---
2) JVM can move but not clone objects

It's current state of Java objects:
Constraint: developer need to define lifecycle in object, for being 
triggered by GC (constructor/finalizer) like current Java class.
Constraint: small object, because when GC move a big object, there is 
possibly a noticeable latency.
Constraint: usable directly only in Java code (because native code will 
need an indirection level for finding the real address of the object, 
changing after each move)


Improvement by adding custom layout for objects (Project Panama on heap 
/ ObjectLayout):
Specific constraint: objects which are near identity-less, i.e. only one 
other object (the owner) know their identity/have pointer on it.
Non-constraint: applicable to all objects types, contrary to Project 
Valhalla. Applicable to complex constructor, because complex constructor 
can be inlined in owner code where called. Applicable to mutable objects 
, because no cloning then no incoherency. Applicable to nullable objects 
only by adding a boolean field in the custom layout for storing 
potential existence or non-existence of the inlined object, and updating 
code testing nullability for using this boolean.


Use-case "General efficiency": Custom layout (Inline sub-object in the 
object owning it):

- Reduce memory use with less objects then less headers and less pointers.
- Improve cache performance with better locality (objects inlined are in 
same cache line, then no reference to follow).
- Applicable to many fields containing reference, requiring only the 
referenced object to be invisible from all objects except one (the owner).


By example, a private field containing an internal ArrayList (without 
getter/setter) can probably be replaced by the integer containing the 
used size and the reference to backing array, with inlining of the few 
methods of ArrayList really used.
It need probably to be driven by developer after real profiling for 
finding best ratio between efficiency/code expansion. It will probably 
have much more use-cases when AOT will be available and 
developer-manageable precisely (Jigsaw???), becau

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

[Jochen Theodorou]

Am 29.01.2015 12:02, schrieb Daniel Latrémolière:



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.

I don't know if that can be useful, but here is my point of view of
developer oriented towards the question: "What feature for solving my
problem?". This contains probably some or many errors, but it is another
point of view (only mine), if useful.

[...]

3) JVM can not move or clone objects (Project Panama off heap /
PackedObjects)
Constraint: developer need to manage externally the full lifecycle of
object and need to choose when creating or destroying it. Object is
off-heap and an handle is on-heap for managing off-heap part.
Constraint: potential fragmentation of free memory when frequently
creating and removing objects not having the same size (taking attention
to object size vs. page size is probably important).

Use-case "GC Latency": big data structure inducing GC latency when moved
if stored in heap
- All big chunks of data, like Big Data or textures in games, etc.
- Few number of objects for being manageable more explicitly by
developer (without too much work).

Use-case "Native": communicate with native library
- Modern version of JNI


From that view it makes me wonder if that is really in the scope of JEP 
169.


bye Jochen

--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org

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

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

[Brian Goetz]

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


It has been merged into the more general Value Types for Java proposal.


The "Value types for Java" approach clearly seems to be the most
general but also the most complex proposal.


For some meanings of "complex".  It is certainly the most intrusive and 
large; new bytecodes, new type signatures.  But from a user-model 
perspective, value types are actually fairly simple.



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.


To your list, I'd add: Project Panama, the sister project to Valhalla. 
Panama focuses on interop with native code and data, including layout 
specification.  A key goal of Packed was to be able to access off-heap 
native data in its native format, rather than marshalling it across the 
JNI boundary.  Panama is focused on this problem as well, but aims to 
treat it as a separate problem from Java object layout, resulting in 
what we believe to be a cleaner decomposition of the two concerns.


Packed is an interesting mix of memory density (object embedding and 
packed arrays) and native interop.  But mixing the two goals also has 
costs; our approach is to separate them into orthogonal concerns, and we 
think that Valhalla and Panama do just that.  So in many ways, while a 
larger project, the combination of Valhalla+Panama addresses the problem 
that Packed did, in a cleaner way.



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)?


It would depend on a lot of things -- including the level of readiness 
of the design and implementation, and the overlap with anticipated 
future features.  We've reviewed some of the early design of 
ObjectLayout and provided feedback to the projects architects; 
currently, I think it's in the "promising exploration" stage, but I 
think multiple rounds of simplification are needed before it is ready to 
be considered for "everybody's Java."  But if the choice is to push 
something that's not ready into 9, or to wait longer -- there's not 
actually a choice to be made there.


I appreciate the desire to "get something you can use now", but we have 
to be prepared to support whatever we push into Java for the next 20 
years, and deal with the additional constraints it generates -- which 
can be an enormous cost.  (Even thought the direct cost is mostly borne 
by Oracle, the indirect cost is borne by everyone, in the form of slower 
progress on everything else.)  So I am very wary of the motivation of 
"well, something better is coming, but this works now, so can we push it 
in?"  I'd prefer to focus on answering whether this is right thing for 
Java for the next 20 years.



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.


The goals of the ObjectLayout effort has overlap with, but also differs 
from, the goals of Valhalla.  And herein is the problem; neither 
generalizes the other, and I don't think we do the user base a great 
favor by pursuing two separate neither-coincident-nor-orthogonal 
approaches.  I suspect, though, that after a few rounds of 
simplification, ObjectLayout could morph into something that fit either 
coincidently or orthogonally with the Valhalla work -- which would be 
great.  But, as you know, our resources are limited, so we (Oracle) 
can't really afford to invest in both.  And such simplification takes 
time -- getting to that "aha" moment when you realize you can simplify 
something is generally an incompressible process.



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?


Suggesting a version number at this point would be putting the cart 
before the horse (you'll note that we've not even proposed a version 
number for Valhalla; the closest we've gotten to that is "after 9".)


OpenJDK Projects are a tool for building a community around a body of 
work; JEPs are a project-management tool for defining, scoping, and 
tracking the progress of a feature.  Given where OL is, it would be 
reasonable to start a Project, which would become the nexus of 
collaboration that could eventually produce a JEP.


Hope this helps,
-Brian
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Volker Simonis]

Hi Daniel,

thanks a lot for sharing your point of view.

I haven't been aware of the fact that Project Panama is also working
on similar topics (I always thought it is only about the Foreign
Function Interface and the next generation JNI). In [1,2] John Rose
nicely explains that new data layouts in the JVM heap are very well on
the agenda of Project Panama and he also mentions IBM's PackedObjects
and Gil Ten's Object Layout proposals.

Regards,
Volker

[1] http://mail.openjdk.java.net/pipermail/panama-dev/2014-October/42.html
[2] https://blogs.oracle.com/jrose/entry/the_isthmus_in_the_vm

On Thu, Jan 29, 2015 at 12:02 PM, Daniel Latrémolière
 wrote:
>
>> 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.
>
> I don't know if that can be useful, but here is my point of view of
> developer oriented towards the question: "What feature for solving my
> problem?". This contains probably some or many errors, but it is another
> point of view (only mine), if useful.
>
> I will not use strictly projects/proposal list as the structure of my mail
> because content of proposal is changing and it is not my target. I am
> oriented towards the final user, i.e. the developer consuming these
> projects, not the implementer working in each of these projects.
>
> I will preferably split in three scopes following my perceived split of job
> between developer and runtime. The problem is data, then what can do JVM/GC
> with an object? I find two possibilities regarding this domain: move it,
> clone it.
>
> If JVM can clone the object, JVM can also move the object because the clone
> will not have the same address, then we have the following three features:
> ---
> 1) JVM can clone and move objects (Project Valhalla):
> Constraint: no complex constructor/no complex finalizer, because lifecycle
> of object is managed by JVM (JVM can clone, then JVM can create and destroy
> the object like JVM want). Only field affectation constructor, possibly with
> simple conversion of data format.
> Constraint: immutable, because we don't know which clone is good when one is
> modified and because modifying all clones simultaneously is
> slow/complex/parallel-unfriendly.
> Constraint: non-null because cloning a non-existing object is a non-existing
> problem.
>
> Use-case "Performance": objects to clone for being closer to execution
> silicon and better parallelism (registers or cache of CPU/GPU)
> - Runtime: expose features of CPU/GPU like SIMD (mostly like a modern
> version of javax.vecmath).
> - Developer: create custom low-level structures for CPU/GPU parallel
> computing.
> - Java language: small tuples, like complex numbers (immutable by
> performance choice, like SIMD, for being close to silicon; cloned at each
> pass by value).
>
> Use-case "Language": objects to clone for being closer to registers (in
> stack, then less allocations in heap; simpler than escape analysis)
> - Java language: multiple return values from a method (immutable because
> it's a result; cloned, by example, at the return of each delegate or not
> even created when stack-only).
>
> Use-case "Efficiency": others immutable non-null objects possibly concerned
> for reducing indirection/improving cache, given by specialization of
> collection classes
> - Database: primary key for Map (like HashMap)/B-Tree (like MapDB)/SQL (like
> JPA). A primary key is immutable and non-null by choice of developer, then
> possible gains.
> ---
> 2) JVM can move but not clone objects
>
> It's current state of Java objects:
> Constraint: developer need to define lifecycle in object, for being
> triggered by GC (constructor/finalizer) like current Java class.
> Constraint: small object, because when GC move a big object, there is
> possibly a noticeable latency.
> Constraint: usable directly only in Java code (because native code will need
> an indirection level for finding the real address of the object, changing
> after each move)
>
> Improvement by adding custom layout for objects (Project Panama on heap /
> ObjectLayout):
> Specific constraint: objects which are near identity-less, i.e. only one
> other object (the owner) know their identity/have pointer on it.
> Non-constraint: applicable to all objects types, contrary to Project
> Valhalla. Applicable to complex constructor, because complex constructor can
> be inlined in owner code where called. Applicable to mutable objects ,
> because no cloning then no incoherency. Applicable to nullable objects only
> by adding a boolean field in the custom layout for storing potential
> existence or non-existence of the inlined object, and updating code testing
> nullability for using this boolean.
>
> Use-case "General efficiency": Custom layout (Inline sub-object in the
> object owning it):
> - Reduce memory use with less objects then less headers and less poi

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

[Vladimir Ivanov]

Thanks, John!

Best regards,
Vladimir Ivanov

On 1/29/15 6:10 AM, John Rose wrote:

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

[Vladimir Ivanov]

Thanks, John!

Best regards,
Vladimir Ivanov

On 1/29/15 6:11 AM, John Rose wrote:

Good.

On Jan 28, 2015, at 9:22 AM, Vladimir Ivanov
mailto:vladimir.x.iva...@oracle.com>> 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

Re: Invokedynamic and recursive method call

[Christian Thalinger]

Trying to remember compiler implementation details this sounds reasonable and 
is a bug (or an enhancement, actually ;-).  Can someone file a bug?

> On Jan 7, 2015, at 10:07 AM, Charles Oliver Nutter  
> wrote:
> 
> This could explain performance regressions we've seen on the
> performance of heavily-recursive algorithms. I'll try to get an
> assembly dump for fib in JRuby later today.
> 
> - Charlie
> 
> On Wed, Jan 7, 2015 at 10:13 AM, Remi Forax  wrote:
>> 
>> On 01/07/2015 10:43 AM, Marcus Lagergren wrote:
>>> 
>>> Remi, I tried to reproduce your problem with jdk9 b44. It runs decently
>>> fast.
>> 
>> 
>> yes, nashorn is fast enough but it can be faster if the JIT was not doing
>> something stupid.
>> 
>> When the VM inline fibo, because fibo is recursive, the recursive call is
>> inlined only once,
>> so the call at depth=2 can not be inlined but should be a classical direct
>> call.
>> 
>> But if fibo is called through an invokedynamic, instead of emitting a direct
>> call to fibo,
>> the JIT generates a code that push the method handle on stack and execute it
>> like if the metod handle was not constant
>> (the method handle is constant because the call at depth=1 is inlined !).
>> 
>>> When did it start to regress?
>> 
>> 
>> jdk7u40, i believe.
>> 
>> I've created a jar containing some handwritten bytecodes with no dependency
>> to reproduce the issue easily:
>>  https://github.com/forax/vmboiler/blob/master/test7/fibo7.jar
>> 
>> [forax@localhost test7]$ time /usr/jdk/jdk1.9.0/bin/java -cp fibo7.jar
>> FiboSample
>> 1836311903
>> 
>> real0m6.653s
>> user0m6.729s
>> sys0m0.019s
>> [forax@localhost test7]$ time /usr/jdk/jdk1.8.0_25/bin/java -cp fibo7.jar
>> FiboSample
>> 1836311903
>> 
>> real0m6.572s
>> user0m6.591s
>> sys0m0.019s
>> [forax@localhost test7]$ time /usr/jdk/jdk1.7.0_71/bin/java -cp fibo7.jar
>> FiboSample
>> 1836311903
>> 
>> real0m6.373s
>> user0m6.396s
>> sys0m0.016s
>> [forax@localhost test7]$ time /usr/jdk/jdk1.7.0_25/bin/java -cp fibo7.jar
>> FiboSample
>> 1836311903
>> 
>> real0m4.847s
>> user0m4.832s
>> sys0m0.019s
>> 
>> as you can see, it was faster with a JDK before jdk7u40.
>> 
>>> 
>>> Regards
>>> Marcus
>> 
>> 
>> cheers,
>> Rémi
>> 
>> 
>>> 
 On 30 Dec 2014, at 20:48, Remi Forax  wrote:
 
 Hi guys,
 I've found a bug in the interaction between the lambda form and inlining
 algorithm,
 basically if the inlining heuristic bailout because the method is
 recursive and already inlined once,
 instead to emit a code to do a direct call, it revert to do call to
 linkStatic with the method
 as MemberName.
 
 I think it's a regression because before the introduction of lambda
 forms,
 I'm pretty sure that the JIT was emitting a direct call.
 
 Step to reproduce with nashorn, run this JavaScript code
 function fibo(n) {
  return (n < 2)? 1: fibo(n - 1) + fibo(n - 2)
 }
 
 print(fibo(45))
 
 like this:
  /usr/jdk/jdk1.9.0/bin/jjs -J-XX:+UnlockDiagnosticVMOptions
 -J-XX:+PrintAssembly fibo.js > log.txt
 
 look for a method 'fibo' from the tail of the log, you will find
 something like this:
 
  0x7f97e4b4743f: mov$0x76d08f770,%r8   ;   {oop(a
 'java/lang/invoke/MemberName' = {method} {0x7f97dcff8e40} 'fibo'
 '(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;I)I' in
 'jdk/nashorn/internal/scripts/Script$Recompilation$2$fibo')}
  0x7f97e4b47449: xchg   %ax,%ax
  0x7f97e4b4744b: callq  0x7f97dd0446e0
 
 I hope this can be fixed. My demonstration that I can have fibo written
 with a dynamic language
 that run as fast as written in Java doesn't work anymore :(
 
 cheers,
 Rémi
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>> 
>>> ___
>>> mlvm-dev mailing list
>>> mlvm-dev@openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> 
>> 
>> ___
>> mlvm-dev mailing list
>> mlvm-dev@openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

Re: Invokedynamic and recursive method call

[John Rose]

On Jan 7, 2015, at 8:13 AM, Remi Forax  wrote:
> 
> But if fibo is called through an invokedynamic, instead of emitting a direct 
> call to fibo,
> the JIT generates a code that push the method handle on stack and execute it
> like if the metod handle was not constant
> (the method handle is constant because the call at depth=1 is inlined !).

Invocation of non-constant MH's had a performance regression with the LF-based 
implementation.
As of JDK-8069591 they should be no slower and sometimes faster than the old 
implementation.
— John

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

Re: Invokedynamic and recursive method call

[Christian Thalinger]

> On Jan 29, 2015, at 4:48 PM, John Rose  wrote:
> 
> On Jan 7, 2015, at 8:13 AM, Remi Forax  > wrote:
>> 
>> But if fibo is called through an invokedynamic, instead of emitting a direct 
>> call to fibo,
>> the JIT generates a code that push the method handle on stack and execute it
>> like if the metod handle was not constant
>> (the method handle is constant because the call at depth=1 is inlined !).
> 
> Invocation of non-constant MH's had a performance regression with the 
> LF-based implementation.
> As of JDK-8069591 they should be no slower and sometimes faster than the old 
> implementation.

Maybe but what Remi is saying that the MH is constant and we could emit a 
direct call.

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

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

Re: Invokedynamic and recursive method call

[Remi Forax]

On 01/30/2015 01:48 AM, John Rose wrote:
On Jan 7, 2015, at 8:13 AM, Remi Forax > wrote:


But if fibo is called through an invokedynamic, instead of emitting a 
direct call to fibo,
the JIT generates a code that push the method handle on stack and 
execute it

like if the metod handle was not constant
(the method handle is constant because the call at depth=1 is inlined !).


Invocation of non-constant MH's had a performance regression with the 
LF-based implementation.
As of JDK-8069591 they should be no slower and sometimes faster than 
the old implementation.

— John



In my case, the method handle is constant (I think it's also the case 
when you write fibo in javascript).

At depth=1, the call is correctly inlined.
At depth=2, the call is not inlined because it's a recursive call and by 
default hotspot only inline recursive call once,
this is normal behavior. The bug is that instead of doing a call (using 
the call assembly instruction),
the JIT pushes the method handle on stack and do an invokebasic, which 
is slower.


Rémi

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