From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8658 invoked by alias); 26 Jun 2009 13:15:11 -0000 Received: (qmail 8646 invoked by uid 22791); 26 Jun 2009 13:15:09 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 26 Jun 2009 13:15:02 +0000 X-RZG-AUTH: :PH8kcEu7frH/iS35MfCwlb7f0DWuyUPE2aUoqiantQ3r9jiZ7Q== X-RZG-CLASS-ID: mo00 Received: from [10.0.1.199] (e178210113.adsl.alicedsl.de [85.178.210.113]) by post.strato.de (mrclete mo2) (RZmta 18.44) with AES128-SHA encrypted ESMTP id Z01838l5QDDv35 ; Fri, 26 Jun 2009 15:14:57 +0200 (MEST) Cc: Bryce McKinlay , java@gcc.gnu.org, Ian Rogers Message-Id: From: =?ISO-8859-1?Q?Patrick_Sch=E4fer?= To: Andrew Pinski In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Howto: Profiling GCJ code? Date: Fri, 26 Jun 2009 13:15:00 -0000 References: <89D1A14F-5454-4E48-8F99-8EAD9C2066A1@ekse.de> <7230133d0906190247s60d1565ew109d48c01a4934ea@mail.gmail.com> <7230133d0906221549r56981795sd907a5ea3a18693c@mail.gmail.com> Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org X-SW-Source: 2009-06/txt/msg00077.txt.bz2 thanx for the help. I finally had time to profile my application using Shark. The results are interesting: 0.1% 63.4% libgcj.9.dylib _Jv_NewPrimArray 0.1% 61.8% libgcj.9.dylib GC_local_malloc_atomic 0.0% 61.5% libgcj.9.dylib GC_malloc_atomic 0.3% 61.0% libgcj.9.dylib GC_generic_malloc 0.1% 60.0% libgcj.9.dylib GC_alloc_large 0.0% 57.9% libgcj.9.dylib GC_collect_or_expand 0.0% 57.9% libgcj.9.dylib GC_try_to_collect_inner 0.0% 56.4% libgcj.9.dylib GC_stopped_mark 0.0% 56.3% libgcj.9.dylib GC_mark_some 38.5% 55.6% libgcj.9.dylib GC_mark_from 0.3% 0.3% libgcj.9.dylib GC_add_to_black_list_normal 0.0% 0.2% libgcj.9.dylib GC_push_roots 0.0% 0.1% libgcj.9.dylib GC_push_next_marked_uncollectable 0.0% 0.0% libgcj.9.dylib GC_next_used_block 0.0% 0.0% libgcj.9.dylib __i686.get_pc_thunk.bx 0.0% 0.1% libgcj.9.dylib GC_stop_world 0.0% 0.0% libgcj.9.dylib GC_start_world 0.0% 0.0% libgcj.9.dylib GC_never_stop_func 0.0% 0.0% libSystem.B.dylib task_threads 0.0% 1.2% libgcj.9.dylib GC_finish_collection 0.0% 0.3% libgcj.9.dylib GC_clear_marks 0.0% 0.0% libgcj.9.dylib GC_promote_black_lists 0.0% 0.0% libgcj.9.dylib GC_start_world 0.0% 0.0% libgcj.9.dylib GC_mark_some 0.2% 2.0% libgcj.9.dylib GC_allochblk 0.1% 0.1% libgcj.9.dylib GC_hblk_fl_from_blocks 0.0% 0.0% libgcj.9.dylib GC_allochblk_nth 0.0% 0.0% libgcj.9.dylib __i686.get_pc_thunk.bx ... This indicates the program is busy allocating memory for almost all the time - even after the connection is lost, the cpu-cost is up at 100%. So there is almost no cpu cost while there is no java.nio connection. As soon as the java.nio connection is established, the cpu- cost goes up to 100% and stays there even after the connection is disconnected. any idea why java.nio has this bad memory allocation behavior or how to solve this? I tried using APR (apache portable runtime) as a transport layer, and, to my surprise, this does solve the problem. Though this is a solution, I am not to happy about using APR, as this adds another native library which has to be on the client to run the application. patrick Am 23.06.2009 um 00:53 schrieb Andrew Pinski: > On Mon, Jun 22, 2009 at 3:49 PM, Bryce McKinlay > wrote: >> In OS X you could try Shark, which comes with Apple's developer >> tools. >> I don't know how well it plays with libgcj, but it's probably worth a >> shot. > > Shark works nicely with GCJ, I have used it before but that was almost > 5 years ago now. :) > > -- Pinski