[
https://issues.apache.org/jira/browse/TRAFODION-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15957851#comment-15957851
]
ASF GitHub Bot commented on TRAFODION-2566:
-------------------------------------------
Github user zellerh commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/1045#discussion_r110039725
--- Diff: core/sql/udrserv/udrserv.cpp ---
@@ -236,7 +238,27 @@ void
InitializeJavaOptionsFromEnvironment(LmJavaOptions &javaOptions
int maxHeapEnvvarMB = DEFAULT_JVM_MAX_HEAP_SIZE;
sprintf(maxHeapOption, "-Xmx%dm", maxHeapEnvvarMB);
javaOptions.addOption((const char *)maxHeapOption, TRUE);
-
+
--- End diff --
You talked in the conversation thread about avoiding duplication of code.
Selva and I also talked about that. The Language manager has the nice feature
of being able to pass JVM options from the outside. If we allow this for
JavaObjectInterface::createJVM() as well, couldn't we then combine the code? If
I ever have time to do this, I'll attempt it, but right now it doesn't look
like that will happen anytime soon.
For now, this looks good to me. If you like we can file a JIRA to combine
JVM startup and to call JavaObjectInterface::createJVM() in the language
manager instead of using its own code. Note that we may call this
LanguageManager code from the executor as well, although it's probably highly
unlikely right now.
> Reduce the virtual memory allocated in Trafodion processes with JDK1.8
> ----------------------------------------------------------------------
>
> Key: TRAFODION-2566
> URL: https://issues.apache.org/jira/browse/TRAFODION-2566
> Project: Apache Trafodion
> Issue Type: Improvement
> Components: sql-exe
> Affects Versions: 2.1-incubating
> Reporter: Selvaganesan Govindarajan
> Assignee: Selvaganesan Govindarajan
>
> It is observed that JDK1.8 uses native memory to store class metadata in lieu
> of permanent generation of earlier releases. By default, JVM mmaps 1 GB of
> virtual address space to the process. Because Trafodion SQL processes are not
> generic JVM processes, it is viable to reduce the default JVM mmap for the
> class metadata
> In JVM1.8
> A simple hello world java program shows the following:
> Heap Configuration when java invoked as
> java -Xmx512m Sample
> MinHeapFreeRatio = 0
> MaxHeapFreeRatio = 100
> MaxHeapSize = 536870912 (512.0MB)
> NewSize = 178782208 (170.5MB)
> MaxNewSize = 178782208 (170.5MB)
> OldSize = 358088704 (341.5MB)
> NewRatio = 2
> SurvivorRatio = 8
> MetaspaceSize = 21807104 (20.796875MB)
> CompressedClassSpaceSize = 1073741824 (1024.0MB)
> MaxMetaspaceSize = 17592186044415 MB
> G1HeapRegionSize = 0 (0.0MB)
> Heap Configuration when Java is invoked as
> java -XX:MaxMetaspaceSize=256m -XX:CompressedClassSpaceSize=256m -Xmx=512m
> Sample
> MinHeapFreeRatio = 0
> MaxHeapFreeRatio = 100
> MaxHeapSize = 536870912 (512.0MB)
> NewSize = 178782208 (170.5MB)
> MaxNewSize = 178782208 (170.5MB)
> OldSize = 358088704 (341.5MB)
> NewRatio = 2
> SurvivorRatio = 8
> MetaspaceSize = 21807104 (20.796875MB)
> CompressedClassSpaceSize = 268435456 (256.0MB)
> MaxMetaspaceSize = 268435456 (256.0MB)
> G1HeapRegionSize = 0 (0.0MB)
> With JDK 1.7
> $JAVA_HOME/bin/java -Xmx512m Sample
> Heap Configuration:
> MinHeapFreeRatio = 0
> MaxHeapFreeRatio = 100
> MaxHeapSize = 536870912 (512.0MB)
> NewSize = 1310720 (1.25MB)
> MaxNewSize = 17592186044415 MB
> OldSize = 5439488 (5.1875MB)
> NewRatio = 2
> SurvivorRatio = 8
> PermSize = 21757952 (20.75MB)
> MaxPermSize = 85983232 (82.0MB)
> G1HeapRegionSize = 0 (0.0MB)
> Permanent Generation in 1.7 is equivalent to MaxMetaDataSpace. I am planning
> to reduce both MaxMetaspaceSize and CompressedClassSpace Size to 128MB.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
