hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fei Hui (JIRA)" <>
Subject [jira] [Commented] (HIVE-15221) Improvement for MapJoin checkMemoryStatus, adding gc before throwing Exception
Date Tue, 29 Nov 2016 10:16:58 GMT


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:
>             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

View raw message