From harmony-dev-return-12830-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org Mon Sep 04 21:22:22 2006 Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 88048 invoked from network); 4 Sep 2006 21:22:18 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 4 Sep 2006 21:22:18 -0000 Received: (qmail 85352 invoked by uid 500); 4 Sep 2006 21:22:10 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 85307 invoked by uid 500); 4 Sep 2006 21:22:10 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 85295 invoked by uid 99); 4 Sep 2006 21:22:10 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Sep 2006 14:22:10 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of gshimansky@gmail.com designates 64.233.182.187 as permitted sender) Received: from [64.233.182.187] (HELO nf-out-0910.google.com) (64.233.182.187) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Sep 2006 14:22:08 -0700 Received: by nf-out-0910.google.com with SMTP id x4so1227576nfb for ; Mon, 04 Sep 2006 14:21:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:reply-to:to:subject:date:user-agent:mime-version:content-disposition:content-type:content-transfer-encoding:message-id; b=pskA/tC6dopmV62hAQUPAUvGZ5pNfvJJHmAtldDnkLYtKbFYH4vgR2ZcVp2PaYs9GVlOyiGru/Bm24maxcMgZKMzObhpDVx5rDA2dGccHnVEgJBjQvPz389BhXLk2yYJbsu9nVC/Fl7i1R+HN8oemDAjerAVp5+dV10V7RIXS60= Received: by 10.48.14.4 with SMTP id 4mr7078355nfn; Mon, 04 Sep 2006 14:21:46 -0700 (PDT) Received: from ppp85-141-182-177.pppoe.mtu-net.ru ( [85.141.182.177]) by mx.gmail.com with ESMTP id o53sm1395458nfa.2006.09.04.14.21.33; Mon, 04 Sep 2006 14:21:46 -0700 (PDT) From: Gregory Shimansky Reply-To: harmony-dev@incubator.apache.org To: harmony-dev@incubator.apache.org Subject: [drlvm] [jvmti] Implementation of SingleStep event through TRAP breakpoints Date: Tue, 5 Sep 2006 01:21:07 +0400 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200609050121.07810.gshimansky@gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Hello Now that DRLVM has some basic implementation of breakpoints in JIT mode as HARMONY-1363 has been created I've decided the same mechanism may be used for implementation of SingleStep JVMTI event [1]. I've thought of some draft design for SingleStep implementation using just int3 breakpoints which are already written in HARMONY-1363. It seems to be enough to satisfy JVMTI spec requirements. The way how I think SingleStep could be implemented is setting a new breakpoint on every new bytecode in compiled code. The breakpoint handler would remove SingleStep breakpoints instrumentation from compiled code and set new ones for the next executable location. The tricky parts is to find the next executable location have the following points 1. Turning SingleStep event state on. When this state is turned on all threads should be switched into SingleStep mode. All of them have to have the next after currently executed bytecode marked with SingleStep type breakpoint. 2. New threads when started and SingleStep state is on have to mark the first bytecode marked with SingleStep breakpoint. 3. Any native to Java transition have to mark first executable bytecode of the method with SingleStep type breakpoint. 4. When exception occurs the SingleStep breakpoints have to be removed from the places of the next executable location and set to exception handler starting address instead. 5. Breakpoints handler which would handle SingleStep type breakpoints as well has to distinguish agent set Breakpoints and synthetic SingleStep ones. 6. When SingleStep state is turned off all breakpoints for the next bytecode in all threads have to be deleted. The implementation would require "next bytecode predictor" which would allow the handler of breakpoints to set them on the next bytecode to be executed. For conditional situations it is easiest to have a set of possibly executable locations, or otherwise it would require parsing current Java stack state. The breakpoints predicted for the next bytecode should certainly be kept in TLS for every thread. There is going to be some subtle logic for distinguishing plain breakpoints and synthetic SingleStep ones and turning SingleStep on/off while in SingleStep and/or Breakpoint callback. So in places like #4, #5 and #6 "predicted" breakpoints would have to be added and removed in sets potentially with more than one target address. At the moment I don't see any flaws in this simple design and I'm going to start working on its implementation. Let me know what you think about it. Surely it is a subject for improvement. I am mostly keeping the whole idea in my head and never tried to write it down completely, I may miss describing some nuances since I may think of them as obvious so feel free to ask me. [1] http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#SingleStep -- Gregory Shimansky, Intel Middleware Products Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org For additional commands, e-mail: harmony-dev-help@incubator.apache.org