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

2015-01-29 Thread 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

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

2015-01-29 Thread 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

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

2015-01-29 Thread 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

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

2015-01-29 Thread 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 vladimir.x.iva...@oracle.com wrote: http://cr.openjdk.java.net/~vlivanov/8071787/webrev.00/

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

2015-01-29 Thread 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 vladimir.x.iva...@oracle.com mailto:vladimir.x.iva...@oracle.com wrote: The fix is to use adapted MethodHandle to construct LambdaForm.

Re: Invokedynamic and recursive method call

2015-01-29 Thread 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 head...@headius.com wrote: This could explain performance regressions we've seen on the

Re: Invokedynamic and recursive method call

2015-01-29 Thread Christian Thalinger
On Jan 29, 2015, at 4:48 PM, John Rose john.r.r...@oracle.com wrote: On Jan 7, 2015, at 8:13 AM, Remi Forax fo...@univ-mlv.fr mailto:fo...@univ-mlv.fr wrote: But if fibo is called through an invokedynamic, instead of emitting a direct call to fibo, the JIT generates a code that push

Re: Invokedynamic and recursive method call

2015-01-29 Thread John Rose
On Jan 7, 2015, at 8:13 AM, Remi Forax fo...@univ-mlv.fr 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

Re: Invokedynamic and recursive method call

2015-01-29 Thread Remi Forax
On 01/30/2015 01:48 AM, John Rose wrote: On Jan 7, 2015, at 8:13 AM, Remi Forax fo...@univ-mlv.fr mailto:fo...@univ-mlv.fr 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