Quantcast

[10] RFR: 8178387: Reduce memory churn when creating java.lang.invoke entities

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[10] RFR: 8178387: Reduce memory churn when creating java.lang.invoke entities

Claes Redestad
Hi,

another startup optimization for java.lang.invoke, this one collecting a
set of small fixes I've been wanting to get done for a while, including:

- no need to generate the signature strings in
BoundMethodHandle.makeCbmhCtor
- trusted MethodType lookups could be promoted without constructing new
objects
- InvokerBytecodeGenerator: creation of className and sourceFile can be
done lazily, which reduces String allocations in those cases where
there's a pre-generated form to be found
- MethodType lookup done twice when looking up pregenerated members (oops!)
- A lot of vararg array creation during startup in various places. A
larger rewrite could be warranted, but we can some startup gain by
simply constant-izing oft-used constant arguments such as
MethodType.invokerType

Webrev: http://cr.openjdk.java.net/~redestad/8178387/jdk.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8178387

Test: java.lang.invoke jtreg tests, verified each change in this patch
(and JDK-8178384) reduces the amount of bytecode executed during lambda
bootstrap.

Thanks!

/Claes
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [10] RFR: 8178387: Reduce memory churn when creating java.lang.invoke entities

Paul Sandoz
Hi,

Looks good.

LambdaForm.java
--

 851         MethodType invokerType = methodType();
 852         assert(vmentry == null || vmentry.getMethodType().basicType().equals(invokerType));



1183             assert(checkArgumentTypes(arguments, methodType()));



1201                 assert(checkArgumentTypes(arguments, methodType()));

I am always wary of removing asserts, do you think these are redundant?




From this and the last fixes how much have you cut from the start up time?

Paul.

> On 10 Apr 2017, at 08:37, Claes Redestad <[hidden email]> wrote:
>
> Hi,
>
> another startup optimization for java.lang.invoke, this one collecting a set of small fixes I've been wanting to get done for a while, including:
>
> - no need to generate the signature strings in BoundMethodHandle.makeCbmhCtor
> - trusted MethodType lookups could be promoted without constructing new objects
> - InvokerBytecodeGenerator: creation of className and sourceFile can be done lazily, which reduces String allocations in those cases where there's a pre-generated form to be found
> - MethodType lookup done twice when looking up pregenerated members (oops!)
> - A lot of vararg array creation during startup in various places. A larger rewrite could be warranted, but we can some startup gain by simply constant-izing oft-used constant arguments such as MethodType.invokerType
>
> Webrev: http://cr.openjdk.java.net/~redestad/8178387/jdk.01/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8178387
>
> Test: java.lang.invoke jtreg tests, verified each change in this patch (and JDK-8178384) reduces the amount of bytecode executed during lambda bootstrap.
>
> Thanks!
>
> /Claes

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [10] RFR: 8178387: Reduce memory churn when creating java.lang.invoke entities

Claes Redestad
Hi,


On 2017-04-10 18:48, Paul Sandoz wrote:
> Hi,
>
> Looks good.

Thanks!

>
> LambdaForm.java
> --
>
>   851         MethodType invokerType = methodType();
>   852         assert(vmentry == null || vmentry.getMethodType().basicType().equals(invokerType));

This one was accidentally removed, will put it back (without the local
invokerType var).

>
> …
>
> 1183             assert(checkArgumentTypes(arguments, methodType()));
>
> …
>
> 1201                 assert(checkArgumentTypes(arguments, methodType()));

The checkArgumentTypes method has been shortcutted for quite some time
(if (true) return true;),
so the asserts aren't doing anything but making -Xcomp tests run slower
and emit a lot of warnings
in my IDE.

>
> I am always wary of removing asserts, do you think these are redundant?
>
>
> —
>
>  From this and the last fixes how much have you cut from the start up time?

Don't expect too much! These two add up to about ~60k fewer bytecode
executed to bootstrap j.l.invoke
and run a trivial lambda, which is about 13% of the total and shows up
as around or somewhat less than a
millisecond improvement on my machine (out of the ~19-20ms it now takes
to bootstrap and execute the
first lambda on my machine).

Thanks!

/Claes

>
> Paul.
>
>> On 10 Apr 2017, at 08:37, Claes Redestad <[hidden email]> wrote:
>>
>> Hi,
>>
>> another startup optimization for java.lang.invoke, this one collecting a set of small fixes I've been wanting to get done for a while, including:
>>
>> - no need to generate the signature strings in BoundMethodHandle.makeCbmhCtor
>> - trusted MethodType lookups could be promoted without constructing new objects
>> - InvokerBytecodeGenerator: creation of className and sourceFile can be done lazily, which reduces String allocations in those cases where there's a pre-generated form to be found
>> - MethodType lookup done twice when looking up pregenerated members (oops!)
>> - A lot of vararg array creation during startup in various places. A larger rewrite could be warranted, but we can some startup gain by simply constant-izing oft-used constant arguments such as MethodType.invokerType
>>
>> Webrev: http://cr.openjdk.java.net/~redestad/8178387/jdk.01/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8178387
>>
>> Test: java.lang.invoke jtreg tests, verified each change in this patch (and JDK-8178384) reduces the amount of bytecode executed during lambda bootstrap.
>>
>> Thanks!
>>
>> /Claes

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [10] RFR: 8178387: Reduce memory churn when creating java.lang.invoke entities

Paul Sandoz

> On 10 Apr 2017, at 10:31, Claes Redestad <[hidden email]> wrote:
>
> Hi,
>
>
> On 2017-04-10 18:48, Paul Sandoz wrote:
>> Hi,
>>
>> Looks good.
>
> Thanks!
>
>>
>> LambdaForm.java
>> --
>>
>>  851         MethodType invokerType = methodType();
>>  852         assert(vmentry == null || vmentry.getMethodType().basicType().equals(invokerType));
>
> This one was accidentally removed, will put it back (without the local invokerType var).
>

Ok.


>>
>> …
>>
>> 1183             assert(checkArgumentTypes(arguments, methodType()));
>>
>> …
>>
>> 1201                 assert(checkArgumentTypes(arguments, methodType()));
>
> The checkArgumentTypes method has been shortcutted for quite some time (if (true) return true;),
> so the asserts aren't doing anything but making -Xcomp tests run slower and emit a lot of warnings
> in my IDE.
>

Ok.


>>
>> I am always wary of removing asserts, do you think these are redundant?
>>
>>
>> —
>>
>> From this and the last fixes how much have you cut from the start up time?
>
> Don't expect too much! These two add up to about ~60k fewer bytecode executed to bootstrap j.l.invoke
> and run a trivial lambda, which is about 13% of the total and shows up as around or somewhat less than a
> millisecond improvement on my machine (out of the ~19-20ms it now takes to bootstrap and execute the
> first lambda on my machine).
>

Keep chipping away, every bit helps :-)

Separately, i am curious how much GC activity occurs at startup before the main method is called. Would it be possible to overlay hotspot activity on the Java flame graph?

Paul.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [10] RFR: 8178387: Reduce memory churn when creating java.lang.invoke entities

Claes Redestad


On 2017-04-10 19:41, Paul Sandoz wrote:
>> On 10 Apr 2017, at 10:31, Claes Redestad <[hidden email]> wrote:
>> Don't expect too much! These two add up to about ~60k fewer bytecode executed to bootstrap j.l.invoke
>> and run a trivial lambda, which is about 13% of the total and shows up as around or somewhat less than a
>> millisecond improvement on my machine (out of the ~19-20ms it now takes to bootstrap and execute the
>> first lambda on my machine).
>>
> Keep chipping away, every bit helps :-)
>
> Separately, i am curious how much GC activity occurs at startup before the main method is called. Would it be possible to overlay hotspot activity on the Java flame graph?

Depends on the GC and initial heap sizes, but on the small tests I'm
looking at, G1 has typically not even started a concurrent cycle, so choice
of GC doesn't matter that much... (G1 has some minor issues shutting
down promptly - seeing delays of up to 15ms to get all theads to realize
they should stop what they're doing - which causes some headache though)

... on the other hand I'm seeing a lot of noise on my 2-socket
workstation when not pinning to a single socket, that appears to come
from JIT
threads *and* the main java thread spending more time. My best guess
right now is some interaction between interpreter and JIT threads,
possibly some contention/sharing effects when installing compiled
methods, and have been starting to ask around for someone who can give
me a tour through that code to investigate deeper... :-)

W.r.t. overlaying native and java flame graphs then it's quite easy to
generate native-only and java-only startup graphs separately, but
surprisingly(?)
hard to create something mixed that capture what happens during the
earliest bootstrap with any precision. There's some wonderful work out
there
using agents to map JIT disassembly to perf output and such, but I'm not
sure it's feasible to use that approach to see what's happening during
interpreter-heavy/warmup phases.

Thanks!

/Claes


Loading...