From dev-return-27557-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Tue Jun 05 05:55:11 2007 Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 32980 invoked from network); 5 Jun 2007 05:55:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 5 Jun 2007 05:55:10 -0000 Received: (qmail 40340 invoked by uid 500); 5 Jun 2007 05:55:12 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 40309 invoked by uid 500); 5 Jun 2007 05:55:12 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 40300 invoked by uid 99); 5 Jun 2007 05:55:12 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Jun 2007 22:55:12 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of alexey.v.varlamov@gmail.com designates 64.233.184.233 as permitted sender) Received: from [64.233.184.233] (HELO wr-out-0506.google.com) (64.233.184.233) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Jun 2007 22:55:06 -0700 Received: by wr-out-0506.google.com with SMTP id i22so935364wra for ; Mon, 04 Jun 2007 22:54:45 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MIUg8CA46Mex8onjupVB9T4930SOU5F/20DChNrcMufVp7hVWrG6v0oEDyRxU6WpVZP3E7WNwOOZa2M2lo+bVP9uHPl8DDuQyoE9EgSPrvocPwWyOPnhrsk6iKwCYs46Wx/q39TMEkgnQUVmnBrDHK9C8mlBWfbWrZwZdeWCMhY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LOgljLuTsMlLZWXWE2CPlRpGq/jYVL15wZYiHcq/gmQszogVaeMSe2KPJIJc2ByNl/KqKYUoheBK5ReDMY9EsqQheyfzxmd4li022hvmdiwAo18Ur1f1XiZukdI6+VpUZy1Jrk1bOHSvMKPU4JH7TeKu19l71anoAgzaErUpVH0= Received: by 10.143.1.2 with SMTP id d2mr259957wfi.1181022885354; Mon, 04 Jun 2007 22:54:45 -0700 (PDT) Received: by 10.143.9.6 with HTTP; Mon, 4 Jun 2007 22:54:45 -0700 (PDT) Message-ID: Date: Tue, 5 Jun 2007 12:54:45 +0700 From: "Alexey Varlamov" To: dev@harmony.apache.org Subject: Re: property parsing functions In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Virus-Checked: Checked by ClamAV on apache.org Peter, You might be gratefully surprised if searched in vm\include\open\vm.h header for any of get_boolean_property(), get_int_property(), get_numerical_property() ;) 2007/6/4, Peter Novodvorsky : > Hello, Alexei. > > I encourage you to look at gc_common.cpp. These functions > (get_property_int, get_property_size, get_property_boolean) provide > something that Properties class doesn't and maybe should. Actually there are several duplicates of such code, in particular in each GC impl we have at the moment. I don't think there are some performance considerations (such code is used basically during initialization), just lack of documentation or some ignorance. Yep, maybe indeed implementation should be part of Properties class rather than C VM interface, in particular to avoid intermediate property value copying - Ilya Berezhniuk raised this issue 2 weeks ago [1]. [1] http://article.gmane.org/gmane.comp.java.harmony.devel/26884 -- WBR, Alexey > > Peter. > > On 6/4/07, Alexei Fedotov wrote: > > Hello, Peter, > > > > I like this question. Being a modularity purist I would vote against > > abstract vmcore in favor of a component manager or a porting layer > > since properties might be needed before the whole core is loaded. > > > > From the other side currently both the component manager and the > > porting layer are statically linked to the core, so it is just a > > question of source file placement. > > > > I also want to attract your attention to the fact that vmcore already > > has a fair property support (vm/vmcore/src/init/properties.cpp). > > > > Thanks! > > > > On 6/4/07, Peter Novodvorsky wrote: > > > Hello, > > > > > > I'm working on support of -Xss (stacksize) parameter for harmony jvm. > > > I found that GC guys implemented a number of very useful property > > > parsing functions in gc_common.cpp. I'd like to use them, but they are > > > static and inside GC library, I don't want to make copy of them in > > > jthread files. I was thinking about moving them somewhere to vmcore. > > > Can you suggest me a good place for them? One more question to GC > > > guys: won't it cause huge performance degradation if these functions > > > will be moved out of GC and all calls to them would become > > > cross-library calls? > > > > > > > > > Thanks, > > > Peter. > > > > > > > > > -- > > With best regards, > > Alexei, > > ESSD, Intel > > >