Replacing the GroovyClassLoader class cache

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Replacing the GroovyClassLoader class cache

Carlos Ferreyra
Hi,

I'm planning on using groovy on a server for a lot of user-defined scripting. As such, I'm planning on using GroovyClassLoader to parse all scripts to get a better runtime speed (and avoid reparsing) and to also cache all scripts being loaded.

That last item caught my attention: The current class cache is just a map, and if I want to support lots of user scripts, that might not be efficient. That's why I want to replace the class cache with a real cache implementation like ehcache or oscache.

My first attempt was to extend GrooveClassLoader and replace that map with an interface to the real cache, but GrooveClassLoader.classCache is a final property.

Sooo, my questions are:

1. Compiled classes are actual bytecode or are simple classes that call the AST?
2. Is there way to replace that class cache shorter than reimplementing the whole GCL?
3. Does all this sound like I'm asking for trouble or reinventing the wheel (i.e. is there already a solution to this)?

Feel free to respond with your favorite acronyms like RTFM, STFU, etc. :)

Carlos.
Reply | Threaded
Open this post in threaded view
|

Re: Replacing the GroovyClassLoader class cache

Mikhail Antonov
Well, after all it't all Java world internally, so why can't you
change the final property, if you know you need that?
Make sure your don't have SecurityManager (or that it allows
reflective black magic), then get the final property Field,  call
setAccessible(true), reset the final flag on it, than change the
property?

Since it's a map and not compile-time expression, that should work?

- Zorkus

2011/2/15 Carlos Ferreyra <[hidden email]>:

>
> Hi,
>
> I'm planning on using groovy on a server for a lot of user-defined
> scripting. As such, I'm planning on using GroovyClassLoader to parse all
> scripts to get a better runtime speed (and avoid reparsing) and to also
> cache all scripts being loaded.
>
> That last item caught my attention: The current class cache is just a map,
> and if I want to support lots of user scripts, that might not be efficient.
> That's why I want to replace the class cache with a real cache
> implementation like ehcache or oscache.
>
> My first attempt was to extend GrooveClassLoader and replace that map with
> an interface to the real cache, but GrooveClassLoader.classCache is a final
> property.
>
> Sooo, my questions are:
>
> 1. Compiled classes are actual bytecode or are simple classes that call the
> AST?
> 2. Is there way to replace that class cache shorter than reimplementing the
> whole GCL?
> 3. Does all this sound like I'm asking for trouble or reinventing the wheel
> (i.e. is there already a solution to this)?
>
> Feel free to respond with your favorite acronyms like RTFM, STFU, etc. :)
>
> Carlos.
>
> --
> View this message in context: http://groovy.329449.n5.nabble.com/Replacing-the-GroovyClassLoader-class-cache-tp3386078p3386078.html
> Sent from the groovy - user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>



--
Thanks,
Michael Antonov

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Replacing the GroovyClassLoader class cache

Jochen Theodorou
In reply to this post by Carlos Ferreyra
Am 15.02.2011 16:14, schrieb Carlos Ferreyra:
[...]
> Sooo, my questions are:
>
> 1. Compiled classes are actual bytecode or are simple classes that call the
> AST?

compiled classes

> 2. Is there way to replace that class cache shorter than reimplementing the
> whole GCL?

Maybe the field containing the map is final, but you will notice that
the map is not really directly accessed in code that queries the cache.
Instead a method is called for this and the method is not final. So by
overwriting getClassCacheEntry(String), setClassCacheEntry(Class),
getLoadedClasses() and clearCache() you can use your own cache and leave
the original cache simply empty.

> 3. Does all this sound like I'm asking for trouble or reinventing the wheel
> (i.e. is there already a solution to this)?

I don't know about just how many scripts you are talking here and what
exactly your scenario is. But before you claim that a simple Map is
slower you should test with real data if it really is.

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead
http://blackdragsview.blogspot.com/
For Groovy programming sources visit http://groovy.codehaus.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Invoking SOAP webservice

Pierre de Leusse
In reply to this post by Mikhail Antonov
Hello all,

I'm wondering if anybody's tried to call a SOAP WS from groovy code.
I've tried both Groovy SOAP and GroovyWS and neither seem to work.

Any tip/feedback would be welcome :)

all the best,
Pierre

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Replacing the GroovyClassLoader class cache

Carlos Ferreyra
In reply to this post by Jochen Theodorou
Jochen Theodorou wrote
Maybe the field containing the map is final, but you will notice that
the map is not really directly accessed in code that queries the cache.
Instead a method is called for this and the method is not final. So by
overwriting getClassCacheEntry(String), setClassCacheEntry(Class),
getLoadedClasses() and clearCache() you can use your own cache and leave
the original cache simply empty.
That's exactly the info I was looking for.
Knowing that the map is only accessible via those four methods should do the trick.

Jochen Theodorou wrote
I don't know about just how many scripts you are talking here and what
exactly your scenario is. But before you claim that a simple Map is
slower you should test with real data if it really is.
I totally agree with you. There have to be a really high number of heavy script to warrant replacing the cache map. I will try to get some tests and numbers and post them here in case anyone cares.

Thanks Mikhail and Jochen for your responses!

Carlos.