Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 84079200CA6 for ; Tue, 9 May 2017 00:56:09 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 827F5160BA5; Mon, 8 May 2017 22:56:09 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id D0925160BC7 for ; Tue, 9 May 2017 00:56:08 +0200 (CEST) Received: (qmail 91079 invoked by uid 500); 8 May 2017 22:56:07 -0000 Mailing-List: contact issues-help@drill.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@drill.apache.org Delivered-To: mailing list issues@drill.apache.org Received: (qmail 90943 invoked by uid 99); 8 May 2017 22:56:07 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 May 2017 22:56:07 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id E657EC030F for ; Mon, 8 May 2017 22:56:06 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -99.202 X-Spam-Level: X-Spam-Status: No, score=-99.202 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id n-8SB9mlalxa for ; Mon, 8 May 2017 22:56:05 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id 6B5605FAF9 for ; Mon, 8 May 2017 22:56:05 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id CC41AE0BE1 for ; Mon, 8 May 2017 22:56:04 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 4DE8C21DF9 for ; Mon, 8 May 2017 22:56:04 +0000 (UTC) Date: Mon, 8 May 2017 22:56:04 +0000 (UTC) From: "Paul Rogers (JIRA)" To: issues@drill.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Comment Edited] (DRILL-5488) Useless code in VectorTrimmer, fixed-width vector setValueCount() MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Mon, 08 May 2017 22:56:09 -0000 [ https://issues.apache.org/jira/browse/DRILL-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16001706#comment-16001706 ] Paul Rogers edited comment on DRILL-5488 at 5/8/17 10:55 PM: ------------------------------------------------------------- Consider the {{setValueCount()}} method again: {code} public void setValueCount(int valueCount) { final int currentValueCapacity = getValueCapacity(); ... while(valueCount > getValueCapacity()) { reAlloc(); } if (valueCount > 0 && currentValueCapacity > valueCount * 2) { ... {code} The {{if}} statement is very probably wrong. We get the current capacity. If too small, we realloc. Then, we check the value, after the possible reallocation, without updating the capacity. It is not clear if we are trying to do check the before or after. Then: {code} if (valueCount > 0 && currentValueCapacity > valueCount * 2) { incrementAllocationMonitor(); // is ++allocationMonitor } else if (allocationMonitor > 0) { allocationMonitor = 0; } {code} It seems we are trying to guess if we did a realloc rather than simply incrementing the monitor when we actually do the reAlloc. It is also not clear that the if-statement mimics the if that does the reAlloc. In fact, a close inspection of the {{setValueCount()}} method, shows that it does not even work correctly. It is allocating enough space to hold the value count, which will implicitly set the unused slots to 0. But, this is an offset vector; we should be copying forward the last set offset. Consider an example: \[0, 3, 9] as set values. Set row count as 5. What we create is: \[0, 3, 9, 0, 0] What we should have set is: \[0, 3, 9, 9, 9] was (Author: paul-rogers): Consider the {{setValueCount()}} method again: {code} public void setValueCount(int valueCount) { final int currentValueCapacity = getValueCapacity(); ... while(valueCount > getValueCapacity()) { reAlloc(); } if (valueCount > 0 && currentValueCapacity > valueCount * 2) { ... {code} The {{if}} statement is very probably wrong. We get the current capacity. If too small, we realloc. Then, we check the value, after the possible reallocation, without updating the capacity. It is not clear if we are trying to do check the before or after. Then: {code} if (valueCount > 0 && currentValueCapacity > valueCount * 2) { incrementAllocationMonitor(); // is ++allocationMonitor } else if (allocationMonitor > 0) { allocationMonitor = 0; } {code} It seems we are trying to guess if we did a realloc rather than simply incrementing the monitor when we actually do the reAlloc. It is also not clear that the if-statement mimics the if that does the reAlloc. > Useless code in VectorTrimmer, fixed-width vector setValueCount() > ----------------------------------------------------------------- > > Key: DRILL-5488 > URL: https://issues.apache.org/jira/browse/DRILL-5488 > Project: Apache Drill > Issue Type: Bug > Affects Versions: 1.10.0 > Reporter: Paul Rogers > Priority: Trivial > > Consider this code in a generated fixed-width vector, such as UInt4Vector: > {code} > @Override > public void setValueCount(int valueCount) { > ... > final int idx = (VALUE_WIDTH * valueCount); > ... > VectorTrimmer.trim(data, idx); > data.writerIndex(valueCount * VALUE_WIDTH); > } > {code} > Consider the {{trim()}} method: > {code} > public class VectorTrimmer { > ... > public static void trim(ByteBuf data, int idx) { > data.writerIndex(idx); > if (data instanceof DrillBuf) { > // data.capacity(idx); > data.writerIndex(idx); > } > } > } > {code} > This method is called {{trim}}, but it actually sets the writer index in the buffer (though we never use that index.) Since all buffers we use are {{DrillBuf}}, the if-statement is a no-op: we simply set the writer index twice. > But, notice that the {{setValueCount()}} method itself calls the same {{writerIndex()}} method, so it is actually being called three times. > It seems this code can simply be discarded: it is called from only two places; neither of which end up using the writer index. -- This message was sent by Atlassian JIRA (v6.3.15#6346)