Request for tracking down C1 optimizations: handwritten cartesian product similar to flatmap/map performance!

Paul Sandoz paul.sandoz at
Fri May 30 13:36:19 UTC 2014

On May 30, 2014, at 2:48 PM, Aggelos Biboudis <biboudis at> wrote:

> The quick thing to do, was to produce the log including the generated code:
> These are what I know:
> 	• The execution happens inside copyInto
> 	• we have three forEachRemaining calls (of, flatMap, map) that are delegated via the accept methods of the wrapped sink.

Just two, there is no loop for the map operation.

In the log search for the compiled method at address 0x00007f1b4909e8d0, then within that search for the instruction imul, then look how the code loops surrounding that instruction.

I can just about fake an understand of x86 machine code :-) AFAICT the capturing instance of LongUnaryOperator passed to the map operation is unboxed.

I have not tried it yet, but JITWatch might help to analyse the logs:


> 	• the second lambda which is captured is obtained via a method internalMemberName
> If scalar replacement happens I should expect to see the captured lambda spilled on the stack and accessed accordingly when the execution reaches a request to the reference of the mapper lambda inside flatMap. From what I understand, this should have happened in the accept of flatMap where the inner lambda is linked and more specifically "inside" the mapper.apply of LongPipeline:286, right (in terms of runtime execution)? And even more specifically when accepting the captured lambda (lambda$8 to my understanding). 
> On a side note, I'll produce a debug build of the vm to examine this better. ;-) Thx for the direction.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <>

More information about the hotspot-compiler-dev mailing list