On Friday, January 18, 2019 at 5:37:58 AM UTC-8, Rémi Forax wrote
>
> no, CHA only works on class, not on interface.
>
> You're probably know better than me. I seem to remember there's something
like that for interfaces but very limited such as if you ever only have
ever one implementation. I suppose you could create a class at runtime that
fills out an abstract class which implements Supplier. You'd just create a
class with a static final field that returns it as an abstract method impl.
> It's not the same semantics, you can not change a StableField more than
> once so you have the guarantee that once the field is initialized, no
> deoptimization can occur.
> The other things is the object is not constant, you will get an exception
> so it's hard to misuse that API.
> The last point is that i expect that at some point i will change the
> implementation so the slowpath will cost less than the slowpath of
> MostlyConstant, but i've never had the time to think how to do that in a VM
> independant way (i know how to do that with Hotspot only).
>
Probably better just to omit it until you can actually make it behave
differently. By the way, how can you get Hotspot to do it?
but it means that you have if/else branch for String that the program has
> never encounter.
> I prefer to not add all the branches statically but add then at runtime
> dynamically when i know i need then.
>
You just have to be extra lazy about it. It's usually bad style but nothing
prevents you from doing something like:
private static final class Helper {
static final Config CONFIG = initConfig(configStr);
}
private String configStr = null;
public static Config getConfig() {
return Helper.CONFIG;
}
private static Config initConfig(String initStr){
// ...
}
>
>
> It will not be inlined by the VM :(
>
Yeah I abandoned trying to make my own ThreadLocalCallSite implementation
for now. I couldn't work out many of the details.
>
> About having a ThreadLocalCallSite, as part of project Loom, we are
> discussing about how associate a value to a part of the callstack.
> Anyway, the VM doesn't have a code cache per thread, there is only a
> global code cache.
>
It seems like for a lot of things it is just simpler to have separate
isolated processes. I wonder if something like Graal could be hacked to
have separate separate Java subinterpreters for separate threads.
Another option is to clone key classes/methods per core but I wasn't sure
about how heavyweight that would be.
--
You received this message because you are subscribed to the Google Groups
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
