Separating parsing and execution

[Laurent Daynes]

HotSpot doesn't do much sharing at the moment, in particular across 
class loaders.
Sharing is done across the boot class loader, across processes, under 
some particular conditions. JIT-ed code isn't shared.
Sharing across the other loaders is tricky because of the possibility of 
using class loader with non-deterministic class resolution mechanisms... 
There are currently looking at dealing with this for class loader with 
known behavior (namely, "application" class loader).
If you're interested in that particular issue you may have a look at our 
ECOOP 2005 paper which describes one way to generally address sharing 
across class loaders
(including JIT-ed code).

Both private or shared execution profile make sense, depending on your 
target. If your doing server side request handler, chances is that the 
profile is valid
across invocation of the VM as the request logic is limited (e.g., as is 
the case for a particular query plan in Walnut).
Also, you'd rather share a slightly more generalized code and avoid a 
cycle of deoptimization/recompilation given that the requests are 
relatively short.

If your doing multi-tenant client side VM, then the control flow across 
instances of the same program may be very different
When we implemented multi-tenancy in HotSpot in the context of MVM, we 
did share all profile. This didn't seem to impact performance
compared to a standalone system.
We had a more ambitious plan to address the possibility to allow private 
specialized code with on-the-fly cloning of JIT-ed code for those
methods where profiling could hurt but we never got to implement that.
With respect to type representation, we had some very good result with 
sharing them (see the MVM papers in 2001) without causing false polymorphism
most of the time (i.e., when a particular site is monomorphic for one 
tenant, but polymorphic for multiple tenants).
Allowing multiple specializations of the same code for specific method 
could be beneficial there.

Laurent

On 8/4/2015 9:35 AM, Stefan Marr wrote:
> Hi:
>
>> On 04 Aug 2015, at 09:15, Jaroslav Tulach <jaroslav.tulach at oracle.com> wrote:
>>
>>> Where should we store the local execution state then?
>>> For instance, execution profiles?
>> Chris mentioned execution profiles, so I guess the answer is yes (but I have
>> no idea what execution profile is).
> Most languages use nodes to profile which branches are taken, and which values are observed at certain points.
> The knowledge about branches shouldn’t be a real problem, but could be a side-channel in a multi-tenant environment which leaks information that might be security sensitive.
>
> General value profiles might be more of an issue, because it is not clear to me that multiple instances of the interpreter share things like classes. I wonder how HotSpot deals with classes from different class loaders. I imagine, this could lead more easily to polymorphic/megamorphic call sites.
> In my current language of choice, I got non-concrete class-structural information, that could be used to determine identity and is stateless, so safe to share. The actual classes however are independent objects and stateful. So, they are not shared between multiple interpreters in the same VM.
>
> Best regards
> Stefam
>

-- 
Laurent Daynes
Oracle Labs