[
https://issues.apache.org/jira/browse/ARTEMIS-3211?focusedWorklogId=572556&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-572556
]
ASF GitHub Bot logged work on ARTEMIS-3211:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 26/Mar/21 09:28
Start Date: 26/Mar/21 09:28
Worklog Time Spent: 10m
Work Description: franz1981 edited a comment on pull request #3521:
URL: https://github.com/apache/activemq-artemis/pull/3521#issuecomment-808067361
@michaelandrepearce
> Yes but you now introduce an issue what happens if next version of jvm
changes maxinline again, yourve basically forced a default which would ignore
the jvms recommendation
Not ignore, just leaving on the ground some free optimization: inlining
should be already tuned to account for the type of application and with
Netty-like application that perform many buffer manipulation, I've seen in
other contexts (eg Vert-x) that raising it would just produce better optimized
code (see https://github.com/netty/netty/pull/10368#issuecomment-650029428 for
an horrible journey trying to improve the situation for default jdk < 14 users
due to lack of this setting in many envs).
This is a type of setting that won't change over time so often (last time
was >10 years ago!), really, but I understand your point here.
> I would leave it out personally and rather recommend users to latest jvm
for performance improvements
Sadly some users cannot move from jdk 8 (yet) for many reasons, I would
rather recommend to do it if they can, is really a free lunch here.
@gtully
> Folks always have to ask their own computer when it comes to performance
tradeoffs.
AFAIK there's no trade off here, but just a conservative setting on jdk 8, I
can come with some numbers if we need, but isn't easy, I suggest to look at the
Netty PR I've referenced that better explain how painful is to workaround on
critical path code lack of this setting...
> btw: what is the string deduplication bit, I imagine that can have a large
impact depending on the use case. There are loads of potentially duplicate
strings and there is some pooling, but surely de-dup would need to work in
concert with that.
Sadly string dedup work mostly for old gen Strings and tends to increase
pause time: that's a fine grain optimization tuning that each user can decide
after profiling (given that is a trade-off).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 572556)
Time Spent: 1.5h (was: 1h 20m)
> Increase MaxInlineLevel to 15 on JVM configuration and remove String
> deduplication
> ----------------------------------------------------------------------------------
>
> Key: ARTEMIS-3211
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3211
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Reporter: Francesco Nigro
> Assignee: Francesco Nigro
> Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> This is going to increase the max inlining level, that won't harm considering
> that's the next default on newer JDKs (see
> https://bugs.openjdk.java.net/browse/JDK-8234863), while removing string
> deduplication, given that it could increase GC pauses time and will mostly
> affect old generation String instances.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
