[vmkit-commits] Breaking change for openjdk

[Will Dietz]

Thanks for the heads-up and description.

Looking at classpath's implementation (String.java, VMString.java) I
don't see why we couldn't do exactly the same thing for the OpenJDK
port.

Only issue is that there is no equivalent of VMString.java in OpenJDK,
perhaps we could just pull it in (the file I mean) and use it in both
ports?  That would be the simplest and fine with me.

An alternative is to basically duplicate the equivalent code into
VMKit somewhere?  The code would create a WeakHashMap early on and
would have a method that does exactly what VMString::intern does in
VMString.java, which would be straightforward.

Engineering details aside your change sounds fine and if the above
ideas don't immediately sound good then just do what you were going to
do and I'll sort out the OpenJDK version when I get a chance :).

In related news, last night I successfully got eclipse running! :D
Was a nice milestone, and wanted to share.  Still can't run all the
dacapo codes yet, though :).

~Will

On Thu, Dec 1, 2011 at 3:15 PM, Nicolas Geoffray
<nicolas.geoffray at gmail.com> wrote:
> Will,
> I plan on submitting this patch that I know will break openjdk. Basically,
> I'm changing the way we intern strings to call a Java method defined in the
> classlib. For GNU Classpath, it's easy, it just calls VMString::intern. I
> don't know if OpenJDK has a Java implementation that can be called directly.
> Note that calling VMString::intern comes pretty early in the game: the first
> time a string is created in J3, it will call it.
> An easy fix for the openjdk port is to set JavaUpcalls::internString to
> NULL. The Jnjvm::constructString method will then not attempt to intern the
> string and call a Java  method. Of course that is not spec compliant,
> because some strings must be interned, but at least it should not crash on
> you.
> The rationale behind that change is that the current implementation did not
> really work and was adding unneeded complexity on top of vmkit (more or less
> adding C++ weak references). It was also storing Java objects into a
> std::map, and I'd like to avoid that.
> Will, let me know if the change and my intermediate fix proposal is ok with
> you.
> Cheers,
> Nicolas