You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Peter Klügl <pe...@averbis.com> on 2015/08/24 12:31:32 UTC
Debugging JCasHashMapSubMap.getReserve()
Hi,
I currently try to learn a bit about UIMA's internal JCas cover
class/object management in the context of UIMA-4568. When I try to debug
JCasHashMapSubMap.getReserve() I get different results compared to a
normal run. Each time a slot is reserved.
Can someone of those who know about UIMA internals comment on that?
Advices and comments on UIMA-4568 in general are of course also welcome :-)
Best,
Peter
Re: Debugging JCasHashMapSubMap.getReserve()
Posted by Peter Klügl <pe...@averbis.com>.
Oracle jdk1.7.0_75 here... I will investigate it further....
Am 24.08.2015 um 16:13 schrieb Marshall Schor:
>
> On 8/24/2015 10:02 AM, Peter Klügl wrote:
>> Ok, thanks. I need to study the code some more...
>>
>> Do you have any advice for me what could have went wrong when I get
>> wrong values for this method in the debugger in a single thread scenario?
> I've debugged this (in Eclipse, using Oracle or IBM Java), without an issue...
> so I don't know what might have gone wrong in your case - you're not using some
> other Java by any chance?
>
> -Marshall
>
>> Best,
>>
>> Peter
>>
>>
>> Am 24.08.2015 um 15:18 schrieb Marshall Schor:
>>> To find out who's worked on a particular class, you can use SVN - in eclipse,
>>> right click the class, and do team -> show history.
>>>
>>> The getReserve() method is supposed to either get the JCas cover class from the
>>> map, or (if it doesn't exist) it's supposed to "reserve" the slot where the JCas
>>> cover class would be (were it in the table). The caller, if it gets "not found"
>>> is supposed to generate the JCas cover class and do a "put" to add it to the
>>> hash map. The "reserve" is there to cause any multi-threaded access to the
>>> identical FeatureStructure to pause while the "winner" of the getReserve reserve
>>> action finishes creating the JCas cover class instance and adding it to the
>>> table. (There's one JCas cover class per CAS, regardless of how many threads
>>> might be trying to access it - this multithreading support was put in some time
>>> ago to support multiple threads doing read actions on a (read-only) CAS).
>>>
>>> -Marshall
>>>
>>> On 8/24/2015 6:31 AM, Peter Klügl wrote:
>>>> Hi,
>>>>
>>>> I currently try to learn a bit about UIMA's internal JCas cover
>>>> class/object management in the context of UIMA-4568. When I try to debug
>>>> JCasHashMapSubMap.getReserve() I get different results compared to a
>>>> normal run. Each time a slot is reserved.
>>>>
>>>> Can someone of those who know about UIMA internals comment on that?
>>>> Advices and comments on UIMA-4568 in general are of course also welcome :-)
>>>>
>>>> Best,
>>>>
>>>> Peter
>>>>
Re: Debugging JCasHashMapSubMap.getReserve()
Posted by Marshall Schor <ms...@schor.com>.
On 8/24/2015 10:02 AM, Peter Klügl wrote:
> Ok, thanks. I need to study the code some more...
>
> Do you have any advice for me what could have went wrong when I get
> wrong values for this method in the debugger in a single thread scenario?
I've debugged this (in Eclipse, using Oracle or IBM Java), without an issue...
so I don't know what might have gone wrong in your case - you're not using some
other Java by any chance?
-Marshall
>
> Best,
>
> Peter
>
>
> Am 24.08.2015 um 15:18 schrieb Marshall Schor:
>> To find out who's worked on a particular class, you can use SVN - in eclipse,
>> right click the class, and do team -> show history.
>>
>> The getReserve() method is supposed to either get the JCas cover class from the
>> map, or (if it doesn't exist) it's supposed to "reserve" the slot where the JCas
>> cover class would be (were it in the table). The caller, if it gets "not found"
>> is supposed to generate the JCas cover class and do a "put" to add it to the
>> hash map. The "reserve" is there to cause any multi-threaded access to the
>> identical FeatureStructure to pause while the "winner" of the getReserve reserve
>> action finishes creating the JCas cover class instance and adding it to the
>> table. (There's one JCas cover class per CAS, regardless of how many threads
>> might be trying to access it - this multithreading support was put in some time
>> ago to support multiple threads doing read actions on a (read-only) CAS).
>>
>> -Marshall
>>
>> On 8/24/2015 6:31 AM, Peter Klügl wrote:
>>> Hi,
>>>
>>> I currently try to learn a bit about UIMA's internal JCas cover
>>> class/object management in the context of UIMA-4568. When I try to debug
>>> JCasHashMapSubMap.getReserve() I get different results compared to a
>>> normal run. Each time a slot is reserved.
>>>
>>> Can someone of those who know about UIMA internals comment on that?
>>> Advices and comments on UIMA-4568 in general are of course also welcome :-)
>>>
>>> Best,
>>>
>>> Peter
>>>
>
Re: Debugging JCasHashMapSubMap.getReserve()
Posted by Peter Klügl <pe...@averbis.com>.
Ok, thanks. I need to study the code some more...
Do you have any advice for me what could have went wrong when I get
wrong values for this method in the debugger in a single thread scenario?
Best,
Peter
Am 24.08.2015 um 15:18 schrieb Marshall Schor:
> To find out who's worked on a particular class, you can use SVN - in eclipse,
> right click the class, and do team -> show history.
>
> The getReserve() method is supposed to either get the JCas cover class from the
> map, or (if it doesn't exist) it's supposed to "reserve" the slot where the JCas
> cover class would be (were it in the table). The caller, if it gets "not found"
> is supposed to generate the JCas cover class and do a "put" to add it to the
> hash map. The "reserve" is there to cause any multi-threaded access to the
> identical FeatureStructure to pause while the "winner" of the getReserve reserve
> action finishes creating the JCas cover class instance and adding it to the
> table. (There's one JCas cover class per CAS, regardless of how many threads
> might be trying to access it - this multithreading support was put in some time
> ago to support multiple threads doing read actions on a (read-only) CAS).
>
> -Marshall
>
> On 8/24/2015 6:31 AM, Peter Klügl wrote:
>> Hi,
>>
>> I currently try to learn a bit about UIMA's internal JCas cover
>> class/object management in the context of UIMA-4568. When I try to debug
>> JCasHashMapSubMap.getReserve() I get different results compared to a
>> normal run. Each time a slot is reserved.
>>
>> Can someone of those who know about UIMA internals comment on that?
>> Advices and comments on UIMA-4568 in general are of course also welcome :-)
>>
>> Best,
>>
>> Peter
>>
Re: Debugging JCasHashMapSubMap.getReserve()
Posted by Marshall Schor <ms...@schor.com>.
To find out who's worked on a particular class, you can use SVN - in eclipse,
right click the class, and do team -> show history.
The getReserve() method is supposed to either get the JCas cover class from the
map, or (if it doesn't exist) it's supposed to "reserve" the slot where the JCas
cover class would be (were it in the table). The caller, if it gets "not found"
is supposed to generate the JCas cover class and do a "put" to add it to the
hash map. The "reserve" is there to cause any multi-threaded access to the
identical FeatureStructure to pause while the "winner" of the getReserve reserve
action finishes creating the JCas cover class instance and adding it to the
table. (There's one JCas cover class per CAS, regardless of how many threads
might be trying to access it - this multithreading support was put in some time
ago to support multiple threads doing read actions on a (read-only) CAS).
-Marshall
On 8/24/2015 6:31 AM, Peter Klügl wrote:
> Hi,
>
> I currently try to learn a bit about UIMA's internal JCas cover
> class/object management in the context of UIMA-4568. When I try to debug
> JCasHashMapSubMap.getReserve() I get different results compared to a
> normal run. Each time a slot is reserved.
>
> Can someone of those who know about UIMA internals comment on that?
> Advices and comments on UIMA-4568 in general are of course also welcome :-)
>
> Best,
>
> Peter
>