Thanks for the commentary to all. I learn something new each time.
My use of callsites, lookups etc are such that there are lots of lookups (
at least
one per generated callsite + class pair). And lookups vary greatly in
time, from a quick
IV access to a full generation and compile of the meth
On 08/20/2011 08:14 AM, John Rose wrote:
> On Aug 19, 2011, at 9:15 PM, Mark Roos wrote:
>
>> The end fallback/lookup is synchronized and so there is only one update at a
>> time, but the
>> new GWT is added to the start of the chain and the second thread is past
>> that point. So
>> when the s
Am 20.08.2011 08:14, schrieb John Rose:
> On Aug 19, 2011, at 9:15 PM, Mark Roos wrote:
>
>> The end fallback/lookup is synchronized and so there is only one update at a
>> time, but the
>> new GWT is added to the start of the chain and the second thread is past
>> that point. So
>> when the se
On Aug 19, 2011, at 9:15 PM, Mark Roos wrote:
> The end fallback/lookup is synchronized and so there is only one update at a
> time, but the
> new GWT is added to the start of the chain and the second thread is past that
> point. So
> when the second gets to the fallback it still thinks the
rom: John Rose
> To: Da Vinci Machine Project
> Date: 08/19/2011 08:14 PM
> Subject: Re: Thread safety and nethod handle chains
> Sent by: mlvm-dev-boun...@openjdk.java.net
>
> On Aug 11, 2011, at 3:01 PM, Rémi Forax wrote:
>
> > Yes, you can have duplicate GWTs
On Aug 11, 2011, at 3:01 PM, Rémi Forax wrote:
> Yes, you can have duplicate GWTs and
> I'm also interested if someone find a better approach :)
You can use a custom subclass of MutableCallSite which synchronizes its updates.
That way two racing threads cannot install duplicate case-handling logi
On 08/11/2011 11:39 PM, Mark Roos wrote:
As I start to look at the multithreading aspects of the Smalltalk
implementation I can see a situation where
two threads could be running down the GWT lookup path both looking for
the same implementation. I was
thinking of making the lookup synchronized
