大数据/kafka/源码（49）
因为会有多个handler线程并发写入索引文件，所以这些字段使用@volatile，保证线程之间的可见性
protected var mmap: MappedByteBuffer= {
& // 如果索引文件不存在则创建返回true,否则存在返回false
& val newlyCreated
= _file.createNewFile()
& val raf =
new RandomAccessFile(_file,
&&& /* 如有必要进行预分配空间 */
&&& if(newlyCreated) {
&&&&& //maxIndexSize值大小对索引文件分配大小，分配结果是小于maxIndexSize *8
&&&&& if(maxIndexSize
& entrySize)
&&&&&&& throw new IllegalArgumentException(&Invalidmax index size: &
+ maxIndexSize)
&&&&& raf.setLength(roundDownToExactMultiple(maxIndexSize,
entrySize))
&&& /* 内存映射 */
&&& val len
= raf.length()
&&& val idx
= raf.getChannel.map(FileChannel.MapMode.READ_WRITE,
&&& /* 蒋新创建的索引文件的position设置为0，从头开始写文件
&&& if(newlyCreated)
&&&&& idx.position(0)
&&&&& // 对于原来就存在的索引文件，则将position移动到索引项的结束位置，防止数据覆盖
&&&&& idx.position(roundDownToExactMultiple(idx.limit,
entrySize))
& } finally {
&&& CoreUtils.swallow(raf.close())
添加指定offset/location对到索引中
def append(offset: Long, position: Int) {
& inLock(lock) {
&&& require(!isFull, &Attempt to append to a full index (size = & + _entries + &).&)
&&& if (_entries == 0 || offset & _lastOffset) {
&&&&& debug(&Adding index entry %d =& %d to %s.&.format(offset, position, file.getName))
&&&&& mmap.putInt((offset - baseOffset).toInt)
&&&&& mmap.putInt(position)
&&&&& _entries += 1
&&&&& _lastOffset = offset
&&&&& require(_entries * entrySize == mmap.position, entries + & entries but file position in index is & + mmap.position + &.&)
&&& } else {
&&&&& throw new InvalidOffsetException(&Attempt to append an offset (%d) to position %d no larger than the last offset appended (%d) to %s.&
&&&&&&& .format(offset, entries, _lastOffset, file.getAbsolutePath))
查找那些大于或者等于给定的offset的offset和position
def lookup(targetOffset: Long): OffsetPosition = {
& maybeLock(lock) {
&&& val idx = mmap.duplicate // 创建一个副本
&&& val slot = indexSlotFor(idx, targetOffset, IndexSearchType.KEY)
&&& if(slot == -1)
&&&&& OffsetPosition(baseOffset, 0)
&&&&& parseEntry(idx, slot).asInstanceOf[OffsetPosition]
查找那些大于或者等于指定offset存储在哪一个slot上的
protected def indexSlotFor(idx: ByteBuffer, target: Long, searchEntity: IndexSearchEntity): Int = {
& // check if the index is empty
& if(_entries == 0)
&&& return -1
& // check if the target offset is smaller than the least offset
& if(compareIndexEntry(parseEntry(idx, 0), target, searchEntity) & 0)
&&& return -1
& // 二分查找算法
& var lo = 0
& var hi = _entries - 1
& while(lo & hi) {
&&& val mid = ceil(hi/2.0 + lo/2.0).toInt
&&& val found = parseEntry(idx, mid)
&&& val compareResult = compareIndexEntry(found, target, searchEntity)
&&& if(compareResult & 0)
&&&&& hi = mid - 1
&&& else if(compareResult & 0)
&&&&& lo = mid
&&&&& return mid
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：26030次
积分：1352
积分：1352
排名：千里之外
原创：112篇
转载：16篇
(1)(2)(42)(27)(1)(6)(9)(13)(1)(2)(2)(8)(2)(4)(8)kafka（6）
安装Kafka：
我们使用3台机器搭建Kafka集群：
192.168.4.142 & h40
192.168.4.143 & h41
192.168.4.144 & h42
kafka_2.10-0.8.2.0下载地址：
我安装的这个版本有点老了，你也可以下载较新的0.10.1.0版本：
（0.10.1.0版本安装方法和旧版本0.8一样，就是在启动时会比旧版本0.8在界面多输出配置信息，在默认的/tmp/kafka-logs目录下也会多出cleaner-offset-checkpoint和meta.properties这两个文件，在zookeeper客户端中的/kafka/brokers下多出个seqid目录，在/kafka/config下多出个clients目录）
我一般爱装在hadoop用户下面：
创建hadoop用户和组（所有虚拟机）
groupadd hadoop
useradd -g hadoop hadoop
passwd hadoop
[hadoop@h40 ~]$ tar -zxvf kafka_2.10-0.8.2.0.tgz
[hadoop@h40 ~]$ cd kafka_2.10-0.8.2.0
修改配置文件kafka_2.10-0.8.2.0/config/server.properties，修改如下内容为：
zookeeper.connect=h40:1,h42:2181/kafka
这里需要说明的是，默认Kafka会使用ZooKeeper默认的/路径，这样有关Kafka的ZooKeeper配置就会散落在根路径下面，如果你有其他的应用也在使用ZooKeeper集群，查看ZooKeeper中数据可能会不直观，所以强烈建议指定一个chroot路径，直接在zookeeper.connect配置项中指定。
而且，需要手动在ZooKeeper中创建路径/kafka（后来发现不手动创建的话它也会自动生成），使用如下命令连接到任意一台ZooKeeper服务器：
[hadoop@h40 ~]$ cd zookeeper-3.4.5/
[hadoop@h40 zookeeper-3.4.5]$ bin/zkCli.sh
在ZooKeeper执行如下命令创建chroot路径：
[zk: localhost:2181(CONNECTED) 0] create /kafka ''
（我不太明白''有什么作用，可参考http://5ydycm./1768和http://blog.csdn.net/rickesy/article/details/了解zookeeper客户端命令的相关知识）
这样，每次连接Kafka集群的时候（使用--zookeeper选项），也必须使用带chroot路径的连接字符串，后面会看到。
将kafka拷贝到其他两台机器：
[hadoop@h40 ~]$ scp -r kafka_2.10-0.8.2.0/ h41:/home/hadoop/
[hadoop@h40 ~]$ scp -r kafka_2.10-0.8.2.0/ h42:/home/hadoop/
修改server.properties中的broker.id，三台机器都修改
因为Kafka集群需要保证各个Broker的id在整个集群中必须唯一，需要调整这个配置项的值（如果在单机上，可以通过建立多个Broker进程来模拟分布式的Kafka集群，但也需要Broker的id唯一，还需要修改一些配置目录的信息）。
[hadoop@h40 ~]$ vi kafka_2.10-0.8.2.0/config/server.properties
broker.id=0
[hadoop@h41 ~]$ vi kafka_2.10-0.8.2.0/config/server.properties
broker.id=1
[hadoop@h42 ~]$ vi kafka_2.10-0.8.2.0/config/server.properties
broker.id=2
首先启动zookeeper集群，然后三台机器都执行以下命令：
[hadoop@h40 kafka_2.10-0.8.2.0]$ bin/kafka-server-start.sh config/server.properties
创建消息主题topic
可以通过查看日志，或者检查进程状态，保证Kafka集群启动成功。
我们创建一个名称为test的Topic，5个分区，并且复制因子为3，执行如下命令：
[hadoop@h40 kafka_2.10-0.8.2.0]$ bin/kafka-topics.sh --create --zookeeper h40:1,h42:2181/kafka --replication-factor 3 --partitions 5 --topic test
Created topic &test&.
zookeeper只指定一个ip也可以的，比如：
[hadoop@h40 kafka_2.10-0.8.2.0]$ bin/kafka-topics.sh --create --zookeeper h40:2181/kafka --replication-factor 2 --partitions 2 --topic hui
Created topic &hui&.
查看创建的Topic，执行如下命令：
[hadoop@h40 kafka_2.10-0.8.2.0]$ bin/kafka-topics.sh --describe --zookeeper h40:1,h42:2181/kafka --topic test
Topic:test
PartitionCount:5
ReplicationFactor:3
Topic: test
Partition: 0
Replicas: 0,2,1
Isr: 0,2,1
Topic: test
Partition: 1
Replicas: 1,0,2
Isr: 0,2,1
Topic: test
Partition: 2
Replicas: 2,1,0
Isr: 2,0,1
Topic: test
Partition: 3
Replicas: 0,1,2
Isr: 0,2,1
Topic: test
Partition: 4
Replicas: 1,2,0
Isr: 2,0,1上面Leader、Replicas、Isr的含义如下：
Partition： 分区
Leader & ： 负责读写指定分区的节点
Replicas ： 复制该分区log的节点列表
Isr & & &： &in-sync& replicas，当前活跃的副本列表（是一个子集），并且可能成为Leader
注意：在执行命令参数--zookeeper h40:1,h42:2181/kafka中的/kafka一定要和server.properties中的zookeeper.connect=h40:1,h42:2181/kafka为参考，一开始我server.properties中配置的为zookeeper.connect=h40:1,h42:2181
& 执行命令的时候却加了/kafka的话会报这个错：
Error while executing topic command org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode = NoNode for /brokers/ids
org.I0Itec.zkclient.exception.ZkNoNodeException: org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode = NoNode for /brokers/ids
at org.I0Itec.zkclient.exception.ZkException.create(ZkException.java:47)
at org.I0Itec.zkclient.ZkClient.retryUntilConnected(ZkClient.java:685)
at org.I0Itec.zkclient.ZkClient.getChildren(ZkClient.java:413)
at org.I0Itec.zkclient.ZkClient.getChildren(ZkClient.java:409)
at kafka.utils.ZkUtils$.getChildren(ZkUtils.scala:468)
at kafka.utils.ZkUtils$.getSortedBrokerList(ZkUtils.scala:78)
at kafka.admin.AdminUtils$.createTopic(AdminUtils.scala:170)
at kafka.admin.TopicCommand$.createTopic(TopicCommand.scala:93)
at kafka.admin.TopicCommand$.main(TopicCommand.scala:55)
at kafka.admin.TopicCommand.main(TopicCommand.scala)
Caused by: org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode = NoNode for /brokers/ids
at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
at org.apache.zookeeper.ZooKeeper.getChildren(ZooKeeper.java:1472)
at org.apache.zookeeper.ZooKeeper.getChildren(ZooKeeper.java:1500)
at org.I0Itec.zkclient.ZkConnection.getChildren(ZkConnection.java:99)
at org.I0Itec.zkclient.ZkClient$2.call(ZkClient.java:416)
at org.I0Itec.zkclient.ZkClient$2.call(ZkClient.java:413)
at org.I0Itec.zkclient.ZkClient.retryUntilConnected(ZkClient.java:675)
... 8 more启动Producer，并向我们上面创建的名称为my-replicated-topic5的Topic中生产消息，执行如下脚本：
[hadoop@h40 kafka_2.10-0.8.2.0]$ bin/kafka-console-producer.sh --broker-list h40:2,h42:9092 --topic test
新开窗口，创建消费者consumer ：
[hadoop@h40 kafka_2.10-0.8.2.0]$ bin/kafka-console-consumer.sh --zookeeper h40:1,h42:2181/kafka --topic &test &--from-beginning
（--from-beginning参数为将该topic中的消息从头全部读出，不加的话只会读出新增加的消息）
删除topic：
在kafka集群的所有三台机器中修改配置文件server.properties
添加如下配置：delete.topic.enable=true
当执行创建命令bin/kafka-topics.sh --create --zookeeper h40:2181/kafka --replication-factor 2 --partitions 2 --topic hui后，可以查看每个节点的/tmp/kafka-logs（server.properties文件log.dirs配置，默认为&/tmp/kafka-logs&，不同broker下存储的topic不一定相同，所有broker都要看一下）目录的变化：
[root@h40 ~]# ll /tmp/kafka-logs/
drwxrwxr-x 2 hadoop hadoop 4096 Jun 20 16:35 hui-0
drwxrwxr-x 2 hadoop hadoop 4096 Jun 20 16:35 hui-1
-rw-rw-r-- 1 hadoop hadoop & 20 Jun 20 16:35 recovery-point-offset-checkpoint
-rw-rw-r-- 1 hadoop hadoop & 20 Jun 20 16:35 replication-offset-checkpoint
[root@h41 ~]# ll /tmp/kafka-logs/
drwxrwxr-x 2 hadoop hadoop 4096 Jun 20 16:35 hui-1
-rw-rw-r-- 1 hadoop hadoop & 12 Jun 20 16:36 recovery-point-offset-checkpoint
-rw-rw-r-- 1 hadoop hadoop & 12 Jun 20 16:36 replication-offset-checkpoint
[root@h42 ~]# ll /tmp/kafka-logs/
drwxrwxr-x 2 hadoop hadoop 4096 Jun 20 16:36 hui-0
-rw-rw-r-- 1 hadoop hadoop & 12 Jun 20 16:36 recovery-point-offset-checkpoint
-rw-rw-r-- 1 hadoop hadoop & 12 Jun 20 16:37 replication-offset-checkpoint
进入zookeeper客户端查看对应topic：
[hadoop@h40 ~]$ cd zookeeper-3.4.5/
[hadoop@h40 zookeeper-3.4.5]$ bin/zkCli.sh
找到topic所在的目录：
[zk: localhost:2181(CONNECTED) 17] ls /kafka/brokers/topics
[zk: localhost:2181(CONNECTED) 51] ls /kafka/config/topics
查看Toptics：
[hadoop@h40 kafka_2.10-0.8.2.0]$ bin/kafka-topics.sh &--list --zookeeper h40:2181/kafka
重启kafka集群后进行删除操作：
[hadoop@h40 kafka_2.10-0.8.2.0]$ ./bin/kafka-topics.sh --delete --zookeeper h40:2181/kafka --topic hui
再执行查看Toptics命令会发现该Toptic已被删除
如果kafaka启动时加载的配置文件中server.properties没有配置delete.topic.enable=true，那么此时的删除并不是真正的删除，而是把topic标记为：marked for deletion
[hadoop@h40 kafka_2.10-0.8.2.0]$ ./bin/kafka-topics.sh --delete --zookeeper h40:2181/kafka --topic hui &
Topic hui is marked for deletion.
Note: This will have no impact if delete.topic.enable is not set to true.
[hadoop@h40 kafka_2.10-0.8.2.0]$ bin/kafka-topics.sh &--list --zookeeper h40:2181/kafka & & & & & & & & & & & & & & & & & & & & & & & & &&
hui - marked for deletion
被标记为marked for deletion的topic你可以在zookeeper客户端中通过命令获得：ls /admin/delete_topics/【topic name】，
如果你删除了此处的topic，那么marked for deletion标记消失
注意：网上总是说有第二种删除Topic的方法，那就是在配置文件中server.properties没有配置delete.topic.enable=true，然后再删除kafka存储目录（/tmp/kafka-logs）下对应的topic，并且在zookeeper客户端中的/kafka/brokers/topics目录下删掉对应topic：rmr
/kafka/brokers/topics/【topic name】
可是我按上述做法后是可以正常删除相应的Topic，但是在删除后再创建一个一模一样的Topic的话（再次执行bin/kafka-topics.sh --create --zookeeper h40:2181/kafka --replication-factor 2 --partitions 2 --topic hui命令，如果再次创建的Topic名称不一样的话也倒不会出现这个问题），在/tmp/kafka-logs目录下不会再次产生相应的Topic目录，虽然该Topic可以正常生产和消费，但是在启动kafka进程窗口的控制台会报下面这个错：
[ 19:03:25,799] ERROR Uncaught exception in scheduled task 'kafka-log-retention' (kafka.utils.KafkaScheduler)
java.io.FileNotFoundException: /tmp/kafka-logs/hui-0/.index (No such file or directory)
0.10.1.0版本则会一开始在控制台一直循环报这个错：[ 16:13:20,327] ERROR [KafkaApi-0] Error when handling request Name: FetchR Version: 3; CorrelationId: 179; ClientId: ReplicaFetcherThread-0-0; ReplicaId: 2; MaxWait: 500 MinBytes: 1 MaxBytes: RequestInfo: ([hui,1],PartitionFetchInfo(0,1048576)) (kafka.server.KafkaApis)
mon.NotAssignedReplicaException: Leader 0 failed to record follower 2's position 0 since the replica is not recognized to be one of the assigned replicas 0,1 for partition [hui,1].再将kafka进程关闭的时候也会报这个错：[ 16:16:54,583] WARN /tmp/kafka-logs/hui-1/.timeindex (No such file or directory) (kafka.utils.CoreUtils$)
java.io.FileNotFoundException: /tmp/kafka-logs/hui-1/.timeindex (No such file or directory)
解决：将kafka集群重启后又就不会报这个错并且一切正常，并且在/tmp/kafka-logs目录下也会生成相应的Topic
第二种方法虽然可行，但是比较繁琐，所以说我并不建议使用这种方法。既然修改配置文件简单可行，那你为什么又非要舍近求远呢？？？！
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：11921次
排名：千里之外
原创：62篇
本人新浪微博：小强签名设计 链接：/u/
文章：11篇
阅读：1544
(1)(26)(11)(7)(20)(2)win10，大数据套装之kafka安装及使用 - 程序如此灵动~ - 苏南大叔的互联网观察~
, & win10，大数据套装之kafka安装及使用
kafka是apache基金会下面的一个开源项目，定位是类似redis的一个队列应用，设计的初衷是用于大量的日志数据的归集统计分析。当然，完成这个初衷，还需要其他一系列apache系列的开源软件配套支持。本篇文章里面，苏南大叔给大家带来的就是kafka的安装。kafka的安装，需要先安装并启动zookeeper，所以，还没有安装好zookeeper的同学，可以先查看相关文章： 。zookeeper和java的安装及环境变量必须配置好，才能继续本篇文章中的内容。今天的范例里面，苏南大叔的安装环境还是win10。当然，kafka和zookeeper一样，都是基于java的，所以，安装包方面就不用考虑win10还是mac了，都是同一个安装包。 。我们这里选择一个已经编译好的二进制包。苏南大叔选择的是Scala 2.12 - kafka_2.12-0.11.0.0.tgz。至于scala的选择，官方也有说明，就是给有洁癖的兄弟准备的，如果没有特别需要，这2个版本都是可以运行的。苏南大叔，把解压后的文件，放在和zookeeper平行的目录。然后，我们需要编辑一下kafka下面config/server.properties 这个文件里面的log.dirs项目。见下图。然后使用下面的命令启动kafka。再次强调一下，kafka的运行，是以zookeeper的执行为前提的。必须先启动zookeeper。.\bin\windows\kafka-server-start.bat .\config\server.properties下一步就是，我们需要创建一个topic，这个和redis的channel有些类似，不过redis并不需要单独再次创建channel。cd bin\windows
kafka-topics.bat --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test创建好topic之后，就是消费者consumer和生产者producer粉墨登场了。我们先创建一个consumer。cd bin\windows
kafka-console-consumer.bat --zookeeper localhost:2181 --topic test再新开窗口创建一个producer。cd bin\windows
kafka-console-producer.bat --broker-list localhost:9092 --topic test然后，我们就可以从producer愉快的和consumer进行对话了。端口，就是我们在zookeeper和kafka里面设置好的，具体的，大家可以再复习一下相关设置文件哦。不过，创建consumer的时候，这个命令，似乎在提示这种创建consumer的方法有些落伍了。下面是个新的启动consumer的命令。cd bin\windows
kafka-console-consumer.bat --bootstrap-server localhost:9092 --topic test --new-consumer --from-beginning --consumber.config ../../config/consumer.properties基本上讲解完毕，整体的感觉就是，又回到了刀耕火种的年代，这命令行敲的.....头晕眼花的。使用老外出品的开源软件，基本上都是这种感觉，这也就是为啥，会有好事者会出gui版本的某某软件的原因。shell下面的这种命令行模式，真心不是一般人能够接受的。关注大数据，关注苏南大叔。苏南大叔为您带来最新第一手大数据资讯。
关注互联网发展，关注苏南大叔的《》博客
本文章来自：
博客地址为：
原文地址为：
尊重原创内容，转载请保留链接信息，感谢您的阅读
本站采用创作共用版权协议, 要求署名、非商业用途和相同方式共享。
转载本站内容必须也遵循“署名-非商业用途-相同方式共享”的创作共用协议。
如果本文对您有帮助，或者节约了您的时间，欢迎您打赏瓶饮料，建立一下友谊关系。
添加新评论3 -XX Command-Line Options
This chapter describes the -XX command-line options of Oracle JRockit JVM; these options are all prefixed by -XX.
To implement some of the options, specific system requirements must be met, otherwise, the particular option does not work. Oracle recommends that you use these options only if you have a thorough understanding of your system. Improper usage of these options can affect the stability or performance of your system.
In this chapter, all the -XX command-line options that you can use with the JRockit JVM are listed in the alphabetical order.
-XXaggressive
The -XXaggressive option is a collection of configurations that make the JVM perform at a high speed and reach a stable state as soon as possible. To achieve this goal, the JVM uses more internal
however, it requires less adaptive optimization once the goal is reached.
What this option configures is subject to change between releases.
-XXaggressive
java -XXaggressive myApp
Related Options
The -XXaggressive option sets several things, which can be reset or changed by adding the explicit options on the command line after the -XXaggressive option.
-XX:AllocChunkSize
When you combine this option with -XX:+UseAllocPrefetch, the -XX:AllocChunkSize option sets the size of the chunks to be cleared.
-XX:+UseAllocPrefetch -XX:AllocChunkSize=size[k|K][m|M][g|G]
java -XX:+UseAllocPrefetch -XX:AllocChunkSize=1K myApp
Default Value
The default value varies depending on the platform.
Related Options
-XX:+|-CheckJNICalls
If you enable this option at startup, the JRockit JVM verifies all arguments to JNI calls, and when it detects an illegal JNI call, the JVM terminates with an error message describing the transgression.
-XX:+|-CheckJNICalls
java -XX:+CheckJNICalls myApp
Related Options
-XX:+CheckJNICalls is equivalent to .
-XX:+|-CheckStacks
This option specifies whether the JVM should explicitly check for stack overflows on a JNI method entry.
-XX:+|-CheckStacks
java -XX:+CheckStacks myApp
In JRockit versions R28.0.0 to R28.3.1, this option is disabled by default.
In JRockit R28.3.2 and later versions, this option is enabled by default.
-XXcompaction
Compaction moves live objects closer together in the Java heap to create larger, contiguous free areas that can be used for allocation of large objects. When the JVM compacts the heap, all threads should be paused because the objects are being moved around. To reduce pause time, only a part of the heap is compacted.
-XXcompaction:parameter1=value1[,parameter2=value2]
lists the parameters that you can specify for the -XXcompaction option.
Table 3-1 Parameters for -XXcompaction
java -XXcompaction:heapParts=8000,internalPercentage=0.5 myApp
When you set this option on a 2 GB heap, it compacts 10 MB of the heap at each internal compaction.
Exceptions
When using the -XXcompaction option, consider the following:
Do not use parameters that conflict each other in the same -XXcompaction option:
The percentage parameter conflicts with the internalPercentage and externalPercentage parameters.
The full parameter conflicts with other percentage parameters such as percentage, initialPercentage, internalPercentage, and externalPercentage
You cannot set the abortable parameter to false.
When you set the enable parameter to false, a warning is printed
Parameters that are specified later in the command line override parameters specified earlier.
-XXcompactRatio (deprecated)
The -XXcompactRatio option is deprecated in Oracle JRockit R28. The option works in R28, but Oracle recommends that you use -XXcompaction:percentage instead. For more information, see .
For more information about the format and usage of -XXcompactRatio, see the R27 documentation at: .
-XXcompactSetLimit (deprecated)
The -XXcompactSetLimit option is deprecated in Oracle JRockit R28. The option works in R28, but Oracle recommends that you use -XXcompaction:maxReferences instead. For more information, see .
For more information about the format and usage of -XXcompactSetLimit, see the R27 documentation at: .
-XXcompactSetLimitPerObject (deprecated)
The -XXcompactSetLimitPerObject option is deprecated in Oracle JRockit R28. The option works in R28, but Oracle recommends that you use -XXcompaction:maxReferencesPerObject instead. For more information, see .
For more information about the format and usage of -XXcompactSetLimitPerObject, see the R27 documentation at: .
-XXcompressedRefs
The -XXcompressedRefs option governs the use of compressed references, limiting all pointers stored on the heap to 32 bits. Compressed references use fewer Java heap resources and transport less data on the memory bus and improves the performance. This option also frees space on the heap.
-XXcompressedRefs:parameter=value
Use the command with one of the parameters listed in
to specify the behavior of compressed references.
Table 3-2 Parameters for -XXcompressedRefs
java -Xgc:pausetime -XXcompressedRefs:enable=true myApp
java -Xgc:pausetime -XXcompressedRefs:size=32GB myApp
Default Values
If -XXcompressedRefs is not specified, compressed references are enabled on all 64-bit machines as long as the heap size is less than 4 GB. When you use the
option, the default values vary on the heap size as listed in .
Table 3-3 Default Size of Compressed References
Related Options
Other command-line options are affected by -XXcompressedRefs as described here:
If you use this option with an initial heap size () that is too large, execution will stop and an error message are generated.
If you do not specify compressed references explicitly by using the -XXcompressedRefs option and you specify either an initial heap (-Xms) or a maximum heap (-Xmx) that is too large (more than 64 GB) for compressed references, compressed references will not be used. The JVM it will run normally.
Exceptions
If compressed references are not available on a given hardware platform or operating system, a warning is printed and execution stops.
-XX:+|-CrashOnOutOfMemoryError
If this option is enabled, when an out-of-memory error occurs, the JRockit JVM crashes and produces text and binary crash files.
Note that generation of crash files when the JVM crashes is enabled by default. For more information, see "About Crash Files" in the .
-XX:+|-CrashOnOutOfMemoryError
java -XX:+CrashOnOutOfMemoryError
Related Options
-XX:+ExitOnOutOfMemoryError takes precedence over this option.
-XX:+|-DisableAttachMechanism
This option specifies whether tools (such as jrcmd and jconsole) are allowed to attach to the JRockit JVM.
-XX:+|-DisableAttachMechanism
java -XX:+DisableAttachMechanism
-XXdumpFullState
Usually when the JRockit JVM crashes, it saves out the state of the process (called a core dump). When you use -XXdumpFullState, the JVM saves all the process state including the heap. More disk space is used, but it makes much easier for you to use the core dump to find out what the problem was that caused the crash. This option saves a significant amount of information to disk.
-XXdumpFullState
Related Options
-XXdumpFullState is equivalent to -XXdumpsize:large. For more information, see .
-XXdumpSize
The -XXdumpSize option causes a dump file to be generated and allows you to specify the relative size of that file.
-XXdumpsize:size
Use the command with one of the parameters listed in
to specify the relative size of the dump file.
Table 3-4 Parameters for -XXdumpsize
-XX:ExceptionTraceFilter
Specify this option at startup to filter exception logging. JRockit JVM logs only those exceptions that match a type specified by this option.
-XX:ExceptionTraceFilter=java.lang.Exception
Enter this command at startup to log exceptions of type java.lang.Exception class.
Default Values
Related Options
-XX:+|-ExitOnOutOfMemoryError
When you enable this option, JRockit JVM exits on the first occurrence of an out-of-memory error. It can be used if you prefer restarting an instance of JRockit JVM rather than handling out of memory errors.
-XX:+|-ExitOnOutOfMemoryError
Enter this command at startup to force JRockit JVM to exit on the first occurrence of an out of memory error.
Default Values
Related Options
-XX:ExitOnOutOfMemoryErrorExitCode
This option specifies the exit code for termination of the JVM process when an out-of-memory error occurs.
-XX:ExitOnOutOfMemoryErrorExitCode=value
Default Value
Related Options
This option works with the
-XXexternalCompactRatio (deprecated)
The -XXexternalCompactRatio option is deprecated in Oracle JRockit R28. The option works in R28, but Oracle recommends that you use -XXcompaction:externalPercentage instead. For more information, see .
For more information about the format and usage of -XXexternalCompactRatio, see the R27 documentation at: .
-XX:+|-FailOverToOldVerifier
This option specifies whether a failover happens to the old verifier when the new type checker fails.
-XX:+|-FailOverToOldVerifier
-XX:+|-FlightRecorder
This option enables or disables the JRockit Flight Recorder. If JRockit Flight Recorder was disabled at application startup, you cannot enable it at run time.
-XX:-FlightRecorder
This option is enabled, but there are no recordings running by default. Use the
to specify options and to start a recording.
-XX:FlightRecorderOptions
This option enables or disables the JRockit Flight Recorder arguments. It is used only when the JRockit Flight Recorder is enabled.
-XX:FlightRecorderOptions=parameter1=value[,parameter2=value]
lists the parameters for -XX:FlightRecorderOptions.
Table 3-5 Parameters for -XX:FlightRecorderOptions
java -XX:+FlightRecorder -XX:FlightRecorderOptions=disk=true,maxchunksize=10M MyApp
Related Options
This option works only when the
option is enabled.
-XX:+|-FlightRecordingDumpOnUnhandledException
This option, when enabled, generates a Flight Recording dump when a thread is terminated due to an unhandled exception. The dump file is written to the location defined by the
-XX:+|-FlightRecordingDumpOnUnhandledException
java -XX:+FlightRecordingDumpOnUnhandledException myApp
Related Option
-XX:FlightRecordingDumpPath
This option specifies the path and name of the dump file (containing Flight Recorder data), which is created (if the
is enabled) when a thread is terminated due to an unhandled exception.
-XX:FlightRecordingDumpPath=path
java -XX:+FlightRecordingDumpOnUnhandledException -XX:FlightRecordingDumpPath=D:\myapp\jfr
Default Value
The default Flight Recording dump file is present in the working directory as jrockit_pid_thread_id.jfr (where pid represents the JRockit process identifier and thread_id represents the thread for which the unhandled exception is thrown).
Related Options
-XXfullSystemGC
The -XXfullSystemGC option causes the garbage collector to do a full garbage collection every time System.gc() is called. Full garbage collection includes old space collection and the elimination of soft references. Use this option when you want the garbage collector to do maximum garbage collecting every time you explicitly invoke a garbage collection from Java.
This option is useful when the default garbage collector does no however, using it can cause longer garbage collection pauses.
-XXfullSystemGC
When you use this option, if an old space collection is already running when System.gc() is called, it will first wait for it to finish and then trigger a new old space collection. The -XXfullSystemGC option frees all softly referenced objects.
Exceptions
You cannot use -XXfullSystemGC together with .
-XXgcThreads
This option specifies how many garbage collection threads the garbage collector will use. This applies both to parallel nursery and parallel old space collectors as well as the concurrent and deterministic collector.
-XXgcthreads:parameter1=value1,parameter2=value2,...
Use the command with one of the parameters listed in
to specify the number of threads used by the garbage collector.
Table 3-6 Parameters for -XXgcThreads
java -XXgcThreads:yc=4,con=2,par=4
Default Values
By default, these values are based on the number of cores and hardware threads on the machine.
-XX:GCTimePercentage
The -XX:GCTimePercentage option determines the percent of time spent in garbage collection of total run time.
-XX:GCTimePercentage=nn
nn is the time spent in garbage collection.
-XX:GCTimePercentage can be used as an alternative to -XX:GCTimeRatio.
java -XX:GCTimePercentage=5 myApp
When you set -XX:GCTimePercentage to 5, five percent of the total time is spent i it is equivalent to -XX:GCTimeRatio=19.
Default Value
Related Options
-XX:GCTimeRatio
The -XX:GCTimeRatio option specifies the ratio of the time spent outside the garbage collection (for example, the time spent for application execution) to the time spent in the garbage collection.
-XX:GCTimeRatio=nn
nn is a number that specifies the ratio of the time spent (as number of times).
java -XX:GCTimeRatio=50 myApp
Default Value
The default value is 19, which means that the time outside the garbage collection is 19 times the time spent in garbage collection.
Related Options
-XXgcTrigger
This option determines how much free memory should remain on the heap when a concurrent garbage collection starts. If the heap becomes full during the concurrent garbage collection, the Java application cannot allocate more memory until the garbage collection frees some heap space, which might cause the application to pause. While the trigger value will tune itself in run time to prevent the heap from becoming too full, this automatic tuning might take too long. Instead, you can use -XXgcTrigger to set from the start a garbage collection trigger value more appropriate to your application.
If the heap becomes full during the concurrent mark phase, the sweep phase will revert to parallel sweep. If this happens frequently and the garbage collection trigger does not increase automatically to prevent this, use -XXgcTrigger to manually increase the garbage collection trigger.
-XXgcTrigger=nn
where nn is the amount of free heap, as a percent of the heap, available when a garbage collections triggered. Note that the young space is not considered as part of the free heap.
java -XXgcTrigger=50 myApp
With this option set, JRockit JVM will trigger a garbage collection when 50% of the heap. For example, about 512 MB on a 1 GB heap or less remains free. The current value of the garbage collection trigger will appear in the -Xverbose:memdbg outputs whenever the trigger changes.
Default Values
If -XXgcTrigger is not specified, the system tries to automatically find a good percentage value. If -XXgcTrigger=nn is specified, it is used instead and no automatic process is involved.
Exceptions
The garbage collector ignores the -XXgcTrigger value when it runs both parallel mark and parallel sweep, for example if you specify -Xgc:singlepar or -Xgc:genpar on the command line.
-XX:+|-HeapDiagnosticsOnOutOfMemoryError
This option specifies whether the JVM should print Java heap diagnostics when an out-of-memory error occurs. The dump file is written to the location defined by the
-XX:+|-HeapDiagnosticsOnOutOfMemoryError
java -XX:+HeapDiagnosticsOnOutOfMemoryError -XX:HeapDiagnosticsPath=D:\myapp\diag_dumps myApp
-XX:HeapDiagnosticsPath
This option specifies the path and file name of the dump file if you have enabled the
-XX:HeapDiagnosticsPath=path
java -XX:+HeapDiagnosticsOnOutOfMemoryError -XX:HeapDumpPath=D:\myApp\diag_dumps myApp
Default Value
The default name of the dump file is jrockit_pid.oomdiag, and the default path is the working directory.
Related Options
This option works with the
-XX:+|-HeapDumpOnCtrlBreak
The -XX:HeapDumpOnCtrlBreak option adds the hprofdump diagnostic command to the list of commands that run automatically when the Ctrl-break keys are pressed (similar to the print_threads diagnostic command). The HPROF dump file is written to the location defined by the
-XX:+HeapDumpOnCtrlBreak
java -XX:+HeapDumpOnCtrlBreak myApp
-XX:+|-HeapDumpOnOutOfMemoryError
If you enable the -XX:+|-HeapDumpOnOutOfMemoryError option, the JRockit JVM dumps the Java heap in HPROF binary format (.hprof file) when an out-of-memory error occurs.
-XX+|-HeapDumpOnOutOfMemoryError
java -XX:+HeapDumpOnOutOfMemoryError myApp
Related Options
-XX:HeapDumpPath
The -XX:HeapDumpPath option specifies the path and file name of the HPROF dump file if you have used -XX:+HeapDumpOnOutOfMemoryError option.
-XX:HeapDumpPath=path_of_the_dump_file
java -XX:+HeapDumpOnOutOfMemory -XX:HeapDumpPath=D:\myApp\hprof-dumps myApp
Default Value
The default name of the binary dump file is jrockit_pid.hprof, where pid represents the JRockit process identifier, and the default path is the working directory.
Related Options
This option works with the
-XX:HeapDumpSegmentSize
The -XX:HeapDumpSegmentSize option specifies an appropriate segment size when generating a segmented HPROF heap dump.
-XX:HeapDumpSegmentSize=size[k|K][m|M][g|G]
java -XX:+HeapDumpOnOutOfMemory -XX:HeapDumpSegmentSize=512M myApp
Default Values
Related Options
No segments are generated unless heap size is larger than the value specified by the
-XXheapParts (deprecated)
The -XXheapParts option is deprecated in Oracle JRockit R28. The option works in R28, but Oracle recommends that you use -XXcompaction:heapParts instead. For more information, see .
For more information about the format and usage of -XXheapParts, see the R27 documentation at: .
-XXinternalCompactRatio (deprecated)
The -XXinternalCompactRatio option is deprecated in Oracle JRockit R28. The option works in R28, but Oracle recommends that you use -XXcompaction:internalPercentage instead. For more information, see .
For more information about the format and usage of -XXinternalCompactRatio, see the R27 documentation at: .
-XX:+|-JavaDebug
The -XX:+|-JavaDebug option enables or disables the debugging capabilities that the JVM Tools Interface (JVMTI) uses. JVMTI is a low-level debugging interface used by debuggers and profiling tools, to inspect the state and control the execution of applications running in the JVM.
Note that the subset of JVMTI that is most typically used by profilers is always enabled. However, the functionality used by debuggers to be able to step through the code and set break points has some overhead associated with it and is not always enabled. To enable this functionality, use the -XX:+JavaDebug option.
-XX:+|-JavaDebug
java -XX:+JavaDebug -agentlib:jdwp=transport=dt_socket,server=y,suspend=n myApp
For more information about the -agentlib option, see the Java documentation at the following locations:
Java SE 6.0
Related Options
This option is equivalent to the
-XXkeepAreaRatio
The -XXkeepAreaRatio option sets the size of the keep area within the nursery as a percent of the nursery. The keep area prevents newly allocated objects from being promoted to old space too early.
-XXkeepAreaRatio:&percentage&
java -XXkeepAreaRatio:10 myApp
Sets the keep area size to 10% of the nursery size.
Default Value
By default, the keep area is 25% of the nursery size. The keep area should not exceed 50% of the nursery size.
Exceptions
The keep area ratio is only valid when the garbage collector is generational.
-XXlargeObjectLimit (deprecated)
The -XXlargeObjectLimit option is deprecated in Oracle JRockit R28. The option works in R28, but Oracle recommends that you use -XXtlaSize:wasteLimit instead. For more information, see .
For more information about the format and usage of -XXlargeObjectLimit, see the R27 documentation at: .
-XX:MaxCodeMemory
The -XX:MaxCodeMemory option specifies the maximum memory used for generated code.
-XX:MaxCodeMemory=size[g|G|m|M|k|K]
java -XX:MaxCodeMemory=2g myApp
Default Values
On Windows IA32, Linux IA32, Windows x86_64, and Linux x86_64, the default value is unbounded. If the -XX:+ReserveCodeMemory option is specified on these platforms, the default maximum code memory is as follows:
When you use -XX:+UseLargePagesForCode: 64 MB
When you use -XX:-UseLargePagesForCode: 1024 MB
On Solaris SPARC the default maximum code memory is 256 MB.
Related Options
-XX:MaxDirectMemorySize
This option specifies the maximum total size of java.nio (New I/O package) direct buffer allocations.
-XX:MaxDirectMemorySize=size[g|G|m|M|k|K]
java -XX:MaxDirectMemorySize=2g myApp
Default Value
The default value is zero, which means the maximum direct memory is unbounded.
-XX:MaximumNurseryPercentage
The -XX:MaximumNurseryPercentage option allows you to set an upper nursery size limit that is relative to the free heap space available after the latest old collection. You must specify the limit as a percentage value of the available free heap size.
-XX:MaximumNurseryPercentage=&value& [1-95]
If you try to set the upper nursery size limit to a value lower than 1 or higher than 95, an error message is displayed.
java -XX:MaximumNurseryPercentage=80 myApp
Default Value
95 percent
Exceptions
This option has no effect unless a generational garbage collector is being used.
-XX:MaxLargePageSize
This option specifies the maximum size for large pages.
-XX:MaxLargePageSize=size[g|G|m|M|k|K]
java -XX:MaxLargePageSize=2g myApp
Default Value
The default value is zero in JRockit versions R28.0.0 to R28.2.2. This means that this value is specified by the operating system.
For JRockit versions R28.2.3 and later, the default value is 256 MB.
Related Options
The option is valid only if
is specified.
-XX:MaxRecvBufferSize
This option specifies the maximum size of the receive buffer when reading from network sockets.
This option is applicable only to Windows.
-XX:MaxRecvBufferSize=size[g|G|m|M|k|K]
java -XX:MaxRecvBufferSize=32k myApp
Default Value
-XXminBlockSize (deprecated)
The -XXminBlockSize option is deprecated in Oracle JRockit R28. The option works in R28, but Oracle recommends that you use -XXtlaSize:min instead. For more information, see .
For more information about the format and usage of -XXminBlockSize, see the R27 documentation at: .
-XXnoSystemGC
The -XXnoSystemGC option prevents a call to the System.gc() method from starting a garbage collection. For more information about the System.gc() method, see the specification for the java.lang.System at the following locations:
Java SE 6.0
If your application uses System.gc() and you want to the garbage collector itself to decide when to run the collection, you should use this option. This option is useful in some debugging situations and can also enhance performance as it prevents unnecessary garbage collection from happening.
-XXnoSystemGC
Enter the command in the above format at startup. This option can cause longer garbage collection pauses in some cases, but generally, it makes the application perform better.
Exceptions
You cannot use -XXnoSystemGC together with .
-XX:OptThreads
The -XX:OptThreads option specifies the number of threads the JVM uses for the optimization of Java methods. The optimization of Java methods runs in the background.
-XX:OptThreads=nn
java -Xgc:pausetime -XX:OptThreads=3 myApp
Directs the compiler to use three threads for optimization tasks.
Default Value
By default, one thread is used for the optimization of Java methods.
-XX:+|-RedoAllocPrefetch
With this option, an additional chunk (that is, two chunks subsequent) is fetched whenever a new chunk is used.
-XX:+RedoAllocPrefetch
java -XX:+UseAllocPrefetch -XX:+RedoAllocPrefetch myApp
Exceptions
This option will not work unless
-XX:+|-ReserveCodeMemory
When this option is enabled, the JVM reserves the memory for generated code at startup.
-XX:+ReserveCodeMemory
java -XX:+ReserveCodeMemory myApp
This option is enabled by default on Solaris SPARC, Windows x86_64, and Linux x86_64 platforms. The default value depends on the -XX:+|-UseLargePagesForCode option as follows:
When you use -XX:+UseLargePagesForCode: 64 MB
When you use -XX:-UseLargePagesForCode: 1024 MB
On Solaris SPARC the default code memory is 256 MB.
Related Option
-XX:SegmentedHeapDumpThreshold
The -XX:SegmentedHeapDumpThreshold option generates a segmented heap dump (.hprof file, 1.0.2 format) when the heap usage is larger than the specified size.
The segmented hprof dump format is required to correctly generate heap dumps containing more than 4 GB of data. If the value of -XX:SegmentedHeapDumpThreshold option is set more than 4 GB, heap dumps may not be generated correctly.
-XX:SegmentedHeapDumpThreshold=size
java -XX:SegmentedHeapDumpThreshold=512M myApp
Default Value
Related Options
This option can be used with .
-XXsetGC (deprecated)
The -XXsetGC option is deprecated in Oracle JRockit R28. The option works in R28, but Oracle recommends that you use -Xgc instead. For more information, see .
For more information about the format and usage of -XXsetGC, see the R27 release documentation at: .
-XX:+|-StrictFP
When you enable this option, JRockit JVM enables strict floating point arithmetics globally for all methods in all classes. The JVM also calculates with more precision, and with a greater range of values than the Java specification requires. When you use this option, the compiler generates code that adheres strictly to the Java specification to ensure identical results on all platforms. When you do not use this option, the JVM does not enforce floating point values.
This option is similar to the Java keyword strictfp; however, that keyword applies at the class level whereas -XX:+|-StrictFP applies globally. For more details about the strictfp keyword, see the Java Language Specification at:
-XX:+StrictFP
Default Values
Related Options
This option is equivalent to .
-XX:StartFlightRecording
Specify this option at startup to start a Flight Recorder recording for an application that runs on JRockit JVM. This option is equivalent to the start_flightrecording diagnostic command that starts the Flight Recorder at run time. For more information, see Oracle JRockit JDK Tools.
-XX:StartFlightRecording=parameter1=value1[,parameter2=value2]
Use -XX:StartFlightRecording with the parameters listed in .
Table 3-7 Parameters for -XX:StartFlightRecording
java -XX:+FlightRecorder -XX:FlightRecorderOptions=disk=true,maxchunksize=10M -XX:StartFlightRecording=filename=test.jfr myApp
-XXtlaSize
The -XXtlaSize option sets the thread-local area size.
To increase performance JRockit JVM uses thread-local areas (TLA) for object allocation. This option can be used to tune the size of the thread-local areas, which can affect performance.
-XXtlaSize:parameter=size[k|K][m|M][g|G]
lists the parameters.
Table 3-8 -XXtlaSize Parameters
There are no upper or lower limits to -XXtlaSize.
Use this option with caution, as changing the thread-local area size can have severe impact on the performance.
Specify size in bytes, using the normal k,M,G suffixes.
-XXtlasize:min=2k,preferred=16k
Default Value
The default value for both the minimum size and the waste limit is 2 KB. The waste limit cannot be set to a larger value than the minimum size.
The default value for the preferred size depends on the heap size or the nursery size and the garbage collector selected at startup. lists the default sizes for the different configurations.
Table 3-9 Default Preferred TLA Sizes
Related Options
The following relation is true for the TLA size parameters:
-XXtlaSize:wasteLimit &= -XXtlaSize:min &= -XXtlaSize:preferred
If you set two or more of the options, then you must make sure that the values you use fulfil these criteria. By default, the waste limit is set to whichever is the lower value of the minimum TLA size and the preferred TLA size divided by 2.
-XX:TreeMapNodeSize
This option specifies the size of the entry array in each java.util.TreeMap node. This option affects the JVM performance and the default value is appropriate for most of the applications.
-XX:TreeMapNodeSize=array_size
java -XX:TreeMapNodeSize=128 myApp
Default Value
The default size of the key-value array in each TreeMap node is 64 entries.
-XX:+|-UseAdaptiveFatSpin
This option specifies whether threads should spin against a fat lock or not (and directly go to sleep state when failed to acquire the fat lock).
-XX:+|-UseAdaptiveFatSpin
Default Value
By default, adaptive spinning against fat locks is disabled. This behavior cannot be changed during run time.
-XX:+|-UseAllocPrefetch
With this option a Thread Local Area is split into chunks and, when a new chunk is reached, the subsequent chunk is prefetched.
-XX:+|-UseAllocPrefetch
java -Xgc:pausetime -XX:+UseAllocPrefetch myApp
Related Options
This option must be set if you want to use . This option is also used with the
-XX:+|-UseCallProfiling
This option enables the use of call profiling for code optimizations. Profiling records useful run-time statistics specific to the application and can increase performance because the JVM can then act on those statistics.
-XX:+|-UseCallProfiling
java -XX:+UseCallProfiling myApp
-XX:+|-UseCfsAdaptedYield
When enabled, this option uses a version of yield adapted for the Completely Fair Scheduler (CFS). This option should be used only on CFS and only if you are experiencing performance issues with the JVM.
-XX:+|-UseCfsAdaptedYield
java -XX:+UseCfsAdaptedYield myApp
-XX:+|-UseClassGC
This option enables or disables garbage collection of classes.
When you disable garbage collection of classes, you can save some garbage collection time, which minimizes interruptions during the application run. Disabling garbage collection of classes can result in more memory being
so if the option is not used carefully, the JVM throws out-of-memory error.
-XX:-UseClassGC
java -XX:-UseClassGC myApp
The class objects in the application specified by myApp are left untouched during garbage collection and are always considered active.
-XX:+|-UseCPoolGC
This option enables or disables garbage collection of constant pool strings.
When you disable garbage collection of constant pool strings, you may be able to reduce some garbage collection overhead associated with removal of strings from the runtime shared pool. Disabling garbage collection of constant pool strings can result in more memory being permanently occupied. Therefore, if the option is not used carefully, the JVM may throw an out-of-memory error.
Even with constant pool garbage collection disabled, there are still cases where the JVM can determine that certain strings are no longer needed and are removed from the constant pool without the help of the garbage collection system.
-XX:+|-UseCPoolGC
java -XX:-UseCPoolGC myApp
The constant pool strings in the application specified by myApp are left untouched during garbage collection and may never be removed.
This option is enabled by default.
JRockit version R28.3.2.
-XX:+|-UseFastTime
This option specifies the use of hardware support for low-latency timestamps.
-XX:+|-UseFastTime
This option is enabled by default on latest AMD and Intel XEON platforms.
-XX:+|-UseFatSpin
The -XX:-UseFatSpin option disables the fat lock spin code in Java, allowing threads that block trying to acquire a fat lock go to sleep directly.
Objects in Java become a lock as soon as any thread enters a synchronized block on that object. All locks are held (that is, stay locked) until released by the locking thread. If the lock is not going to be released very fast, it can be inflated to a fat lock. Spinning occurs when a thread that wants a specific lock continuously checks that lock to see if it is still taken, spinning in a tight loop as it makes the check. Spinning against a fat lock is generally beneficial although, in some instances, it can be expensive and might affect performance. The -XX:-UseFatSpin allows you to turn off spinning against a fat lock and eliminate the potential performance hit.
-XX:+|-UseFatSpin
-XX:+|-UseLargePagesFor[Heap|Code]
This option enables the use of large pages, if they are available, for the Java heap and code in the JVM. Large pages allow your application to more effectively use the translation look-aside buffer (TLB) in the processor.
-XX:+|-UseLargePagesFor[Heap|Code]
-XX:+UseLargePagesForHeap
Enables the use of large pages for the Java heap.
-XX:+|-UseLazyUnlocking
When -XX:+|-UseLazyUnlocking is enabled, locks are not released when a critical section is exited. Instead, once a lock is acquired, the next thread that tries to acquire such a lock will have to ensure that the lock is or can be released. It does this by determining if the initial thread still uses the lock. A truly shared lock is eventually converted to a normal lock and this improves the performance of locking operations on shared locks.
-XX:+|-UseLazyUnlocking
java -XX:-UseLazyUnlocking myApp
Disables lazy unlocking.
Lazy unlocking is enabled by default on all platforms except when the -Xdebug option is used.
Exceptions
This option is intended for applications with many unshared locks. This option can introduce performance penalties with applications that have many short-lived but shared locks.
-XX:+|-UseLockProfiling
The -XX:+|-UseLockProfiling option enables or disables profiling of Java locks in JRockit Flight Recorder.
To get the Java lock profiling data, the lock events in the JRockit Flight Recorder must also be enabled. For more information, see .
-XX:+|-UseLockProfiling
java -XX:+UseLockProfiling myApp
Enables Java lock profiling.
-XX:+|-UseLowAddressForHeap
This option directs the JVM to use the low 4 GB address space for Java heap, if available.
-X:+|-UseLowAddressForHeap
-XX:+UseLowAddressForHeap
Enables use of the low address space for the Java heap.
-XX:+|-UseNewHashFunction
This option specifies whether a new, faster hash function is enabled for java.util.HashMap. This hash function can improve performance through improved hash spread, but changes the order in which elements are stored in the HashMap.
-X:+|-UseNewHashFunction
-XX:+UseNewHashFunction
Enables the new hash function.
The new hash function is disabled by default in the JRockit JVM that bundles J2SE 5.0.
Related Options
-XXaggressive enables use of the new hash function unless it is explicitly disabled using -XX:-UseNewHashFunction.
-XX:+|-UseThreadPriorities
This option enables you to control the priority of Java threads using java.lang.Thread.setPriority() and related APIs. If this feature is disabled, using these APIs has no effect.
-XX:+|-UseThreadPriorities
-XX:+UseThreadPriorities
Enables use of the java.lang.Thread.setPriority() and related APIs.
Exceptions
Availability of this option is determined by the platform.
Windows: Available.
Linux: A you must have root privileges to use thread priorities on most Linux versions.
Solaris: Not available.