Idea how to implement VT/VO compatibility in JVM

[Maurizio Cimadamore]

On 22/01/15 08:24, Stéphane Épardaud wrote:
> Note that what I'm really looking for here is a whole in my proposal. 
> I haven't found one yet (except for the limitation on public fields) 
> but that's probably because I'm not as used to the problem as you guys 
> are. If there's really no hole and it's really a plausible 
> implementation I'm willing to help test it, possibly by implementing 
> it. I've some knowledge of the internals of javac and the bytecode, 
> thought nothing on the VM front I'm afraid. 
Hi Stephane,
I don't think there's an 'hole' as such in your proposal - but there are 
'unknowns'.

Performance-wise, I think the 'risk' is that if we keep the API the way 
they are today (i.e. removeAll(Collection<?>) and friends), the boxing 
path will pretty much be the norm. Now, in a perfect world, as value 
types are non-polymorphic (or their polymorphism is very restricted) and 
immutable, that would suggest that VM should have enough of an hint to 
perform boxing elimination and such, so that the cost you end up paying 
is negligible. How much of this is reality? As you, I'm not a VM guru - 
but I think it's a question worth asking. It seems a likely scenario 
that the JVM will do great in most cases, and have some bad performance 
cliffs in others - is that something we are willing to sign up for?

On the language-side unknowns, how much code out there is relying on 
being able to access fields on Foo<?> or raw Foo types? This is perhaps 
not common, but I think we need to gather data points on this i.e. by 
looking at existing open source projects (help welcome here!). Other 
possible weak points are that this doesn't necessarily address all the 
issue w.r.t. language uniformity - i.e. how is an ArrayList<int> 
supposed to answer to a question of the kind 'is instance of List<?>' ?

I'm not denying there's something there worth exploring (as I have in 
fact already said), but it seems to me that, while you can go a long way 
with bridges, there are still questions that bridges alone simply do not 
have an answer for.

Maurizio