Smalltalk and tiered compile data

[Mark Roos]

Thanks Rémi

Off to give it a try

mark



From:   Rémi Forax <forax at univ-mlv.fr>
To:     mlvm-dev at openjdk.java.net
Date:   02/09/2012 11:08 AM
Subject:        Re: Smalltalk and tiered compile data
Sent by:        mlvm-dev-bounces at openjdk.java.net



On 02/08/2012 10:47 PM, Mark Roos wrote:
> Hi Rémi

Hi Mark,

>
> I think I am starting to get it.
>
> My normal fallback creates a GWT and does a getTarget + setTarget on 
> the root callsite to put this GWT at the
> head of the chain.  I assume that this use of setTarget is as expected 
> and causes no problems.  I think I
> found this technique in some of your early code.

yes !

>
> For the switchPoint approach I would set the first (root) target to a 
>  switchPoint which invokes a new callsite
> which then takes the normal fallback. This keeps the switchPoint at 
> the head with the GWT chain now
> growing from the second callsite.
>
> The invalidate path has a method handle which will create a new 
> switchPoint with fallbacks and place it
> in the root callsite replacing the now dead switchPoint.  This 
> setTarget will occur on the next invocation
> of the root callSite after the invalidation.
>
> This state is similar to the first after a bootstrap.

yes !

>
> So I am going to do a lot of setTargets.  One for each method cache 
> miss and again for every call site which
> is invalidated plus any lookups it needs to do.
>
> Given that every setTarget involves a safe point this sounds like it 
> could get expensive.  Should I be
> concerned?

No :)
setTarget() doesn't implies automatically a safepoint. There is a 
safepoint if
you do a setTarget() on a Callsites which have been used to generate a 
compiled code.

>
> thanks
>
> mark
>

cheers,
Rémi

_______________________________________________
mlvm-dev mailing list
mlvm-dev at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120209/dc6bc914/attachment.html