deserializeCASComplete and JCas

[Peter Klügl <pe...@averbis.com>]

Hi,

I wonder if it is necessary to load all JCas cover classes anew if the
jcas is deserialized with deserializeCASComplete.

In JCasImpl line 645, the map is null because the type system instance
changed in the serialization (no equals()).

There there a way to avoid that?

Best,

Peter

Re: deserializeCASComplete and JCas

[Peter Klügl <pe...@averbis.com>]

Hi,

it's the same classloader. 80% of the time is spent in
java.lang.Class.forName(String, boolean, ClassLoader). In my performance
test case the serialization is about 100 times faster if I do not
include the type system (serializeCAS instead of serializeCASComplete)

I'll stick to other serialization methods for now.

Best,

Peter

Am 15.03.2016 um 22:17 schrieb Marshall Schor:
> I'm not sure of your use case in detail, but if the JCas classes have been
> loaded, they can't be "reloaded" - the calls to Class.forName, or
> classLoader.loadClass would find the named object already loaded, and just
> return that.  (This assumes you're using the same class loader, of course).
>
> This whole area is somewhat cleaned up in the experimental UIMA v3.  There, when
> you commit a type system, it's compared to existing type systems previously
> committed, and if one of those is "equal", it's used instead.
>
> This was a bit involved to do; the saving is done using weak references, so
> things would eventually get cleaned up, and there were issues with test cases
> which built type systems programmatically, and kept java references to types and
> features before the commit, which became invalid after the commit (fix was to
> re-compute these handles after the commit).
>
> If you know the type system is identical, you could cobble something up to avoid
> reinitializing it, I think.
>
>
> -Marshall
>
> On 3/15/2016 1:21 PM, Peter Klügl wrote:
>> Hi,
>>
>> I wonder if it is necessary to load all JCas cover classes anew if the
>> jcas is deserialized with deserializeCASComplete.
>>
>> In JCasImpl line 645, the map is null because the type system instance
>> changed in the serialization (no equals()).
> ??? line 645 in trunk:
>
> private void expandTypeArrayIfNeeded() {
>     if (typeArray.length < JCasRegistry.getNumberOfRegisteredClasses()) {
>       TOP_Type[] newTypeArray = new
> TOP_Type[JCasRegistry.getNumberOfRegisteredClasses()];
>       System.arraycopy(typeArray, 0, newTypeArray, 0, typeArray.length);
>       typeArray = newTypeArray;     // <<<<<<<<<<<<<<< Line 645
>     }
>   }
>> There there a way to avoid that?
>>
>> Best,
>>
>> Peter
>>

Re: deserializeCASComplete and JCas

[Marshall Schor <ms...@schor.com>]

I'm not sure of your use case in detail, but if the JCas classes have been
loaded, they can't be "reloaded" - the calls to Class.forName, or
classLoader.loadClass would find the named object already loaded, and just
return that.  (This assumes you're using the same class loader, of course).

This whole area is somewhat cleaned up in the experimental UIMA v3.  There, when
you commit a type system, it's compared to existing type systems previously
committed, and if one of those is "equal", it's used instead.

This was a bit involved to do; the saving is done using weak references, so
things would eventually get cleaned up, and there were issues with test cases
which built type systems programmatically, and kept java references to types and
features before the commit, which became invalid after the commit (fix was to
re-compute these handles after the commit).

If you know the type system is identical, you could cobble something up to avoid
reinitializing it, I think.


-Marshall

On 3/15/2016 1:21 PM, Peter Klügl wrote:
> Hi,
>
> I wonder if it is necessary to load all JCas cover classes anew if the
> jcas is deserialized with deserializeCASComplete.
>
> In JCasImpl line 645, the map is null because the type system instance
> changed in the serialization (no equals()).
??? line 645 in trunk:

private void expandTypeArrayIfNeeded() {
    if (typeArray.length < JCasRegistry.getNumberOfRegisteredClasses()) {
      TOP_Type[] newTypeArray = new
TOP_Type[JCasRegistry.getNumberOfRegisteredClasses()];
      System.arraycopy(typeArray, 0, newTypeArray, 0, typeArray.length);
      typeArray = newTypeArray;     // <<<<<<<<<<<<<<< Line 645
    }
  }
>
> There there a way to avoid that?
>
> Best,
>
> Peter
>