[
https://issues.apache.org/jira/browse/HIVE-15221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15704892#comment-15704892
]
Fei Hui commented on HIVE-15221:
--------------------------------
hi, all
Somebody worries about 'System.gc will not guarantee a garbage collection cycle'
i have explained that. If DisableExplicitGC is false, then System.gc explicit
will call GC, and default value of DisableExplicitGC is false. When running
hive querys, No one almost set the argument DisableExplicitGC to jvm. I deep
into openjdk hotspot jvm code, and im sure that's right.
Even if gc not occurs, the improment does not bring any disadvantages. Isn't it
?
i think the improment is very usefule for queries running successfully
> Improvement for MapJoin checkMemoryStatus, adding gc before throwing Exception
> ------------------------------------------------------------------------------
>
> Key: HIVE-15221
> URL: https://issues.apache.org/jira/browse/HIVE-15221
> Project: Hive
> Issue Type: Improvement
> Components: Query Processor
> Affects Versions: 2.1.0, 2.0.1
> Reporter: Fei Hui
> Assignee: Fei Hui
> Attachments: HIVE-15221.1.patch
>
>
> i see in the current master version
> percentage = (double) usedMemory / (double) maxHeapSize;
> if percentage > maxMemoryUsage, then throw MapJoinMemoryExhaustionException
> in my opinion, running is better than fail. after System.gc, ' if percentage
> > maxMemoryUsage, then throw MapJoinMemoryExhaustionException' maybe better
> And original checking way has a problem: 1) consuming much memory cause gc
> (e.g young gc), then check after adding row and pass. 2) consuming much
> memory does not cause gc, then check after adding rows but throw Exception
> sometimes 2) occurs, but it contians less rows than 1).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
