Re: Working around NoClassDefFound

2012-07-04 Thread Charles Oliver Nutter
Thanks Remi, that makes sense. My call paths don't have too many types (4
or 5 maybe) so this might be worth exploring. I assume this includes any
handles to cast back to those types.

Hmm...an idea is forming. I will try to play with this later this week.

- Charlie (mobile)
On Jul 4, 2012 3:59 AM, "Rémi Forax"  wrote:

> On 07/04/2012 03:01 AM, Mark Roos wrote:
> > From Charlie
> >
> > It also doesn't appear to happen with JRuby on the boot
> > classpath...it happens only when JRuby is loaded in a child
> > classloader.
> >
> > That was my experience as well.  The only way I found to avoid it was to
> > put my code into the bootClassPath.  I messed with other ideas ( but not
> > Rémi's) but the error always eventually returned.
> >
> > regards
> > mark
>
> There is only one workaround to avoid the NoClassDefFound error as far
> as I know,
> the signature of all invokedynamic calls must not contain any class
> which is not in the bootclasspath.
> So either you put the runtime classes in the bootclasspath or you erase
> all your signature to only use
> primitive types and Object.
>
> cheers,
> Rémi
>
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


Re: Working around NoClassDefFound

2012-07-04 Thread Rémi Forax
On 07/04/2012 03:01 AM, Mark Roos wrote:
> From Charlie
>
> It also doesn't appear to happen with JRuby on the boot
> classpath...it happens only when JRuby is loaded in a child
> classloader.
>
> That was my experience as well.  The only way I found to avoid it was to
> put my code into the bootClassPath.  I messed with other ideas ( but not
> Rémi's) but the error always eventually returned.
>
> regards
> mark

There is only one workaround to avoid the NoClassDefFound error as far 
as I know,
the signature of all invokedynamic calls must not contain any class 
which is not in the bootclasspath.
So either you put the runtime classes in the bootclasspath or you erase 
all your signature to only use
primitive types and Object.

cheers,
Rémi

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


Re: Working around NoClassDefFound

2012-07-03 Thread Mark Roos
>From Charlie

It also doesn't appear to happen with JRuby on the boot
classpath...it happens only when JRuby is loaded in a child
classloader.

That was my experience as well.  The only way I found to avoid it was to
put my code into the bootClassPath.  I messed with other ideas ( but not
Rémi's) but the error always eventually returned.

regards
mark___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


Working around NoClassDefFound

2012-07-02 Thread Charles Oliver Nutter
Ok folks...last I heard from Christian the new indy backend is not
going to make u6, so I'm actively seeking workarounds for the dreaded
NoClassDefFoundError.

I believe Remi suggested something like erasing the types in the MH
tree and then re-casting them or something, but I can't find the
thread.

I have fixed some instances of it by making sure I generate jitted
Ruby code into isolated classloaders rather than ever sharing the code
across classloaders, but it's not a good general solution.

I don't have an easy reproduction yet. Since it only happens when indy
jits, and since I only use indy once Ruby code jits, it's a bit
unpredictable. It also doesn't appear to happen with JRuby on the boot
classpath...it happens only when JRuby is loaded in a child
classloader.

So...has anyone found a way to work around NCDFE?

- Charlie
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev