Re: [Jython-dev] Question about old python.proxy.savedir

[<bc...@wo...>]

[Humbel Otmar]

>first many thanks for moving Jython on!
>
>I admit I was'nt fully able to follow (mean: understand) the latest
>discussion on proxies and cache design, so please forgive me if the
>questions below sound too naive.
>
>How is the relation of the new cache/proxy design to the old JPython 1.0.3.
>style proxy savedir ?
>	[snippet from good old registry file:]
>		#Only enable this if you're SURE you want it
>		python.proxy.savedir = n:/java/lib

The proxy cache recently discussed here is the in-memory mapping from
class names to the PyJavaClass which represent the class. Calling it a
cache is probably wrong, the PyJavaClass.classes hashtable is not about
performance, but about ensuring a 1-1 mapping between a class and its
PyJavaClass. The problem we have been talking about is how to ensure
this 1-1 mapping when the java class haven't been loaded yet (what we
call "lazy loading") and when the java class gets reloaded (different
class with the same name).

The proxy.savedir option were OTOH a true performance cache with the
name of the java class as cache-key. The option was never enabled for
JPython-1.1. There were several reasons for this omission:

- The proxies classes does not have a uniquely identifiable name
  anymore. The generated proxy class name include a serial number
  that makes it difficult to use a cache like the one in 1.0.3.
- JPython-1.1 included new and much improved ways of freezing. If
  the dynamic proxy creation is too slow, jpythonc can create the
  proxies for you in advance.
- Having a performance cache without any means of flushing the cache
  when it gets stale is bad design. We still have no way of detecting
  when a java have changed.

>Do we still need these proxies with Jython 2.0 ? We definitely need them in
>JPython 1.0.3 and we almost rebuilt them again for JPython 1.1 - for runtime
>performance reasons.

We always need better performance. I have been thinking a little about a
design where the generated proxies is stored at the end of the $py.class
file. This would still not solve the flushing issue, but it would make a
manual flush of the cached proxy much easier.

regards,
finn