Hi Jan,

2009/2/16 Jan Pannecoeck <j...@mgb-tech.com>:
> Hello Robert,
>
> I'm using JamVM 1.5.0 at the ARM and JamVM 1.4.5 at my desktop pc. Is the
> problem you described also in those versions, or only in the 1.5.1 version?
>

Yes, the problem is in both 1.4.5 and 1.5.0 (JSR 166 support was added
in 1.4.5, with an inefficient park/unpark implementation -- this has
finally been replaced in 1.5.2).

Rob.

> Thanks for your reply!
> Jan
>
> Robert Lougher wrote:
>>
>> Hi Jan,
>>
>> 2009/2/16 Jan Pannecoeck <j...@mgb-tech.com>:
>>
>>>
>>> Hello everyone,
>>>
>>> I'm a Java Developer and I'm working mainly with embedded devices. Now
>>> I'm
>>> running JamVM with GNU Classpath on an ARM processor. This is all working
>>> fine, and I didn't had any big problems until now... I'll try to explain
>>> my
>>> problem as good as possible, but if someone needs some more information,
>>> you
>>> can contact me ofcourse!
>>>
>>> So, I'm using the Smack API to get an XMPPConnection with my XMPPServer.
>>> This is working, but my CPU is running at 100%! I do have the same
>>> problem
>>> (CPU at 100%) when I try to run this java program on my desktop computer
>>> with JamVM and GNU Classpath. When I run it using Sun's JVM, the CPU load
>>> is
>>> around 0-1 %.
>>>
>>> I don't have any clue what this problem could be causing, I'm trying to
>>> find
>>> out what part of the Smack API is causing the problems, but at the moment
>>> I
>>> log-in to the server, the CPU jumps to 100%... Could this be caused by
>>> some
>>> encryption that's been used by Smack? Since the Smack API needs a
>>> KeyStoreType, I'm using the gkr type since that's the one supported by
>>> GNU
>>> Classpath...
>>>
>>> If anyone had this kind of problems before with GNU Classpath, or could
>>> solve my problem, this would be great!! Any help would be welcome since
>>> I'm
>>> quite stuck with this...
>>>
>>>
>>
>> What version of JamVM are you using?  It's possible some code you're
>> running is using the new concurrency API (JSR 166).  In JamVM 1.5.1,
>> park/unpark was incomplete and could use 100% CPU.  This is fixed in
>> 1.5.2.
>>
>> Rob.
>>
>>
>>>
>>> Kind regards,
>>> Jan
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>

Reply via email to