Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of gcjhd-harmony-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@harmony.apache.org
From: George Timoshenko <george.timoshenko@gmail.com>
Subject: Re: [drlvm][jvmti] RedefineClasses.
Date: Thu, 03 May 2007 15:08:50 +0700
Lines: 20
Message-ID: <f1c5aj$sic$1@sea.gmane.org>
References: <e0f125db0705010956r195a6c26s35afc811b27fe13e@mail.gmail.com>
	 <0vqslagsa75.fsf@gmail.com>
	 <e0f125db0705012148s460c745di9d566b406957d382@mail.gmail.com>
	 <46382A1D.8000009@gmail.com>
 <e0f125db0705022230w227842f0mf6a88fc4c5efd0f9@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
In-Reply-To: <e0f125db0705022230w227842f0mf6a88fc4c5efd0f9@mail.gmail.com>
Sender: news <news@sea.gmane.org>

I see now. Thanks for clarification.

As we are using "merged cp" inside DRLVM, can we just not take care of 
exceeding 16-bit boundary and keep cp indexes as 32-bit values?

Or we export this information somewhere...?


Pavel Pervov wrote:
> In current codebase "merged" constant pool will cause many problems for
> interpreter and one problem for JIT - if call to "throw_linking_exception"
> stub is compiled into some method. As you may remember it contains 
> immediate
> value of constant pool index of a referenced class.
> 
> Also, Mikhail noted new functionality currently being implemented - lazy
> resolution. It will also be heavily affected with constant pool merging.
> 
> Regards,
>    Pavel.