Early-access build b95 of JDK 9 is available for download
by Rory O'Donnell
Hi Galder,
Early-access builds of JDK 9 with Project Verona [0] in b95 are
available for download here <https://jdk9.java.net/download>.
The goal of this Project is to implement the new JDK version string as
described in JEP-223 <http://openjdk.java.net/jeps/223> [1].
The new version-string scheme is designed to easily distinguish major,
minor, and security-update releases.
For more information please see Iris Clark's email [2] , also see
Dalibor Topic's blog on this topic [3].
Please send usage questions, feedback and experience reports to the
verona-dev <http://mail.openjdk.java.net/mailman/listinfo/verona-dev>
mailing list.
Note: If you haven’t already subscribed to that mailing list then please
do so first, otherwise
your message will be discarded as spam.
Rgds,Rory
[0] http://openjdk.java.net/projects/verona/
[1] http://openjdk.java.net/jeps/223
[2]
http://mail.openjdk.java.net/pipermail/verona-dev/2015-November/000293.html
[3] https://blogs.oracle.com/java-platform-group/entry/a_new_jdk_9_version
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
8 years, 6 months
Memory consumption of org.infinispan.marshall.core.JBossMarshaller
by Christian Beikov
Hello,
In a recent heap dump analysis I found that
org.infinispan.marshall.core.JBossMarshaller consumes a lot of
memory(about 46 MB) that seems to be unused.
This is due to PerThreadInstanceHolder having ExtendedRiverMarshaller
objects that contain big IdentityIntMap objects. Some of those
IdentityIntMap instances have a size of 2 million entries, but most of
them have sizes of a few 100 thousands.
When I look into these IdentityIntMap instances, it seems that the
entries are all unused.
Is that kind of memory consumption expected or does that indicate a
possibly wrong configuration?
I am using Infinispan 7.2.4.Final on Wildfly 9.0.1.Final.
8 years, 6 months
Consolidating temporary per-key data
by Radim Vansa
Hi again,
examining some flamegraphs I've found out that recently the
ExpirationInterceptor has been added, which registers ongoing write in a
hashmap. So at this point we have a map for locks, map for writes used
for expiration, another two key-addressed maps in L1ManagerImpl and one
in L1NonTxInterceptor and maybe another maps elsewhere.
This makes me think that we could spare map lookups and expensive writes
by providing *single map for temporary per-key data*. A reference to the
entry could be stored in the context to save the lookups. An extreme
case would be to put this into DataContainer, but I think that this
would prove too tricky in practice.
A downside would be the loss of encapsulation (any component could
theoretically access e.g. locks), but I don't find that too dramatic.
WDYT?
Radim
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
8 years, 6 months
