First I just want to emphasize that this proposal doesn't necessarily
have full endorsement yet from Marshall, Eddie, et al. so I won't
comment on the strategic roadmap questions. I'm just attempting to
make the case for a direction which to me seems very natural.
Logically UIMA is an object graph with some fixed type system, rooted
in one or more collections with different ordering/uniqueness rules.
These are all things Java provides out-of-the box, with a highly
evolved heap/GC engine and numerous powerful SDK collection classes.
Thus I would argue the most simple and "obvious" way to implement the
UIMA specification would be a thin layer on top of these existing
constructs, and there would need to be quite a compelling reason to
deviate significantly from this.
I completely understand that in the past such reasons existed, but
it's now 10 years later and JVMs and hardware have moved on
considerably. I'm fairly certain that those reasons are no longer
valid today, and yet we are still paying the cost of significant
complexity for something with more limitations than we would have
otherwise. By carving out static chunks of heap and doing a
proprietary form of "memory management" within them it prevents the
JVM from optimizing how/where this data is stored and collected. This
is very much working against how the JVM was designed to be used.
The standard UIMA (non-JCas) CAS APIs allow typesystem-agnostic based
CAS manipulation, so my understanding is that the only reason for
performing low level or direct heap access is to get better
performance out of the current array-based impl. I was assuming such
usage would be rare by users of UIMA in general, but I could be wrong
and it's useful to know people out there like you are doing it. I'd
argue though the fact that it is even necessary is another reason for
changing the approach (given that a goal of UIMA is to minimize effort
required by NLP developers). Could you elaborate on your usage of
internal APIs?
Regarding serialization formats, each of them is just a well-defined
serial representation of a CAS, so should not be affected by the
runtime implementation.
I do understand that the current binary formats derive from the CAS
array internals, but it doesn't mean that this new impl couldn't
read/write that same format. I expect here specifically there may be a
relative performance impact because of the 'reconstruction' of the
heaps that would be needed, however:
- In a way, keeping the CAS in this form in memory could be seen as
optimizing for speed of this specific binary format at the expense of
slower and less flexible runtime CAS access
- Alternative binary serialization mechanisms (and formats) could also
be used similar to standard java object serialization, which I expect
would be just as fast (although not default java serialization which
is very inefficient)
- I'd question in any case whether this alone should dictate the
overall architecture choice
I was my impression in the past, that UIMA-Core has always valued
compatibility very high, even to the point of adding switches to
re-enabled buggy/undesired behavior in case somebody depended on it.
I understand this, and I think I managed to keep things functionally
identical. I'm not proposing any change in behaviour.
Changing the implementation of the CAS is probably the most radical
idea I've seen so far in this project.
It might be radical in terms of the implementation change but again I
would argue it's really just a simplification of the internals. It
shouldn't be radical at all for users of UIMA in general.
Are we going to slay the holy cow of compatibility now and if yes at
which levels?
Even for this change, the source incompatibility only applies to JCas
cover classes, and only to those because of their current
implementation-specific format.
What does such a change mean to the various sub-projects (DUCC,
UIMA-AS, RUTA, uimaFIT)?
As long as these projects don't directly manipulate the CAS arrays,
there should be zero impact to them apart from I would hope some
performance benefits. It would also mean in future they could exploit
the thread-safe nature of the CAS for various purposes.
Regards,
Nick
Quoting Richard Eckart de Castilho <[email protected]>:
On 03.04.2015, at 22:51, Marshall Schor <[email protected]> wrote:
It may be good to open a "Brainstorming" Jira, and attach the code you're
thinking of donating, so that people could study it and have a more concrete
idea about this.
If it eventually gets accepted, we would also need a Software Grant
for this, I
think, due to the size.
I was my impression in the past, that UIMA-Core has always valued
compatibility very high, even to the point of adding switches to
re-enabled buggy/undesired behavior in case somebody depended on it.
Changing the implementation of the CAS is probably the most radical
idea I've seen so far in this project. In principle, I very much
like seeing UIMA to evolve, but I do wonder how such a radical
change is imagined to be undertaken.
I'm aware that there are various levels of compatibility. My
impression so far was that source-compatibility was typically not
sufficient in the past.
Are we going to slay the holy cow of compatibility now and if yes at
which levels?
Is there some willingness now to consider setting up a road-map for
a UIMA-Core version 3?
What does such a change mean to the various sub-projects (DUCC,
UIMA-AS, RUTA, uimaFIT)?
Personally, I'd be curious to see how much of e.g. DKPro Core or
WebAnno breaks with such a new implementation. I imagine quite a lot
since I've become quite fond of binary serialization and internal
API usage lately (in some cases I might be able to switch to
official low-level CAS API...). Although I'm very much for evolution
and adopting newer technologies, I'm afraid testing this (and
potentially fixing stuff) will be quite time intensive. Given that
in my context, most of the benefits are not very relevant so far,
such testing would only make sense to me if it was part of a larger
strategic change - and I think that a properly licensed contribution
would be pretty much a pre-requisite to even look at it in detail.
Marshall, Eddie, and Nick do you have some vision of a strategic
UIMA roadmap that you can share with us?
Cheers,
-- Richard
