Eclipse Community Forums: Standard Widget Toolkit (SWT) » Why is there a limit on no of widgets, based on no of handles?

Messages: 608
Registered: July 2009

Senior Member

What is the underlying reson for having limited no of handles for widgets?
why is it not only dependend on the amount of memory available?
which resource is captured,when u use up a handle by creating a widget?

---------------------
why, mr. Anderson, why, why do you persist?
Because I Choose To.
Regards,
Vijay

[Updated on: Fri, 12 August 2011 04:16]

(no subject) [message #714757 is a reply to message #714721]

Thu, 11 August 2011 12:51

Eclipse User

Originally posted by:

On 2011-08-11 13:29, vijay wrote:
> What is the underlying reson for having limited no of handles for
widgets?

Because this is an OS-specific property.

> why is it not only dependend on the amount of memory available?

It is a very persistent misunderstanding that "resources" and "memory
resources" are not the very same thing. Would you also expect that the
number of open files depends on the available memory? If yes: This is
another misunderstanding, even though the available memory is of-course
a *further* limitation.

> which resource is captured,when u use up a handle by creating a widget?

I don't understand this question. But for feedback reasons it makes
sense to ask, why you need to know this? You should always ensure that
non-Java-memory are properly released, otherwise you will have severe
problems.

HTH & Greetings from Bremen,

Daniel Krügler

Re: (no subject) [message #715002 is a reply to message #714757]

Fri, 12 August 2011 03:58

Messages: 608
Registered: July 2009

Senior Member

We have a large application with lots of views and multipage editors and we encounter out of handles a lot of time(note:all font,image,color etc resources have been checked for and optimized)
The reason is,there are simply more no of controls and there is no solution for this apart from reducing the no of controls even if i improve my hardware.

So i was wondering,even if handles is a OS limitation,what exactly is it? is it a memory address?which due to OS type(32bit/64bit) will be limited to int max or long max times? or is it something else...

what if i have to increase this no of handles?

--
With Regards,
Vijay

---------------------
why, mr. Anderson, why, why do you persist?
Because I Choose To.
Regards,
Vijay

Re: (no subject) [message #715228 is a reply to message #715002]

Fri, 12 August 2011 20:36

Messages: 2150
Registered: July 2009

Senior Member

Sometimes SWT throws a No More Handles error when it doesn't know what
caused a failure, but this does not necessarily mean that the pool of OS
handles has been exhausted (unless you're on Windows 98 or earlier). Is
there a specific scenario where you see this error happen? Or does it
seem random?

Grant

On 8/11/2011 11:58 PM, vijay wrote:
>
> We have a large application with lots of views and multipage editors and
> we encounter out of handles a lot of time(note:all font,image,color etc
> resources have been checked for and optimized)
> The reason is,there are simply more no of controls and there is no
> solution for this apart from reducing the no of controls even if i
> improve my hardware.
>
> So i was wondering,even if handles is a OS limitation,what exactly is
> it? is it a memory address?which due to OS type(32bit/64bit) will be
> limited to int max or long max times? or is it something else...
>
> what if i have to increase this no of handles?
>

Re: (no subject) [message #715239 is a reply to message #715228]

Fri, 12 August 2011 21:22

Messages: 608
Registered: July 2009

Senior Member

Yes it comes up in a specific scenario only,like we have a multipage editor with 15 pages,with each page having many widgets.
If this editor is opened more then 13 times out of handles is thrown.
this can be again reproduced by just opening 10 multipage editors and some more other views..

---------------------
why, mr. Anderson, why, why do you persist?
Because I Choose To.
Regards,
Vijay

Re: (no subject) [message #716114 is a reply to message #715239]

Tue, 16 August 2011 13:32

Messages: 2150
Registered: July 2009

Senior Member

Do the multi-page editors contain many OleClientSite controls (the
Browser is an example of one of these on win32)? I know of a case where
Browser creation was failing with a No More Handles exception after ~160
simultaneously-open instances, because each instance creates a temporary
working file, and some OS limit was being reached (not exactly sure
which limit). Could this be what you're seeing? Or do your 15-page
editors just contain simple controls like Buttons, Texts, etc?

Grant

On 8/12/2011 5:22 PM, vijay wrote:
> Yes it comes up in a specific scenario only,like we have a multipage
> editor with 15 pages,with each page having many widgets.
> If this editor is opened more then 13 times out of handles is thrown.
> this can be again reproduced by just opening 10 multipage editors and
> some more other views..

Re: (no subject) [message #716681 is a reply to message #716114]

Thu, 18 August 2011 04:46

Messages: 608
Registered: July 2009

Senior Member

The editor contains only standard controls....
(although browser issue was new info,thanks Grant for this,is there any issue logged for the same)

apart from coding malpractices,lets suppose say there is a genuine need for more controls,
I was wondering given that there is a OS limit on handles ,what are the ways to increase it?
i know swing can be used to work around this problem since there are many controls there,which are rendered instead of using the underlying controls..but then again performance overheads creep up there..

---------------------
why, mr. Anderson, why, why do you persist?
Because I Choose To.
Regards,
Vijay

Re: (no subject) [message #716787 is a reply to message #716681]

Thu, 18 August 2011 13:25

Messages: 2150
Registered: July 2009

Senior Member

There isn't a bugzilla report regarding the OleClientSite thing I
mentioned, it's just something I was shown internally.

I don't think there's a way to increase the number of native handles
available, but unless you're on a very old Windows release, the upper
limit on handles is quite high and should not realistically be hit, even
by a big/complex app. I wonder if you're actually running into another
problem (eg.- out of memory) and SWT is throwing a NO_MORE_HANDLES
exception because a native call that should never fail is failing as a
result.

This may seem like a disconnected question, but is your app being
launched by pointing at a JRE's java executable (java.exe/javaw.exe), or
by pointing at its jvm.dll? And if you aren't specifying a "-vm"
argument at launch time then see if your app's .ini file is (eg.-
eclipse.ini). I ask because in the case with too many Browser instances
this actually proved to make a big difference; specifying -vm to point
at java.exe/javaw.exe launches a separate process, which avoids these
NO_MORE_HANDLES errors for much longer.

Grant

On 8/18/2011 12:46 AM, vijay wrote:
> The editor contains only standard controls....
> (although browser issue was new info,thanks Grant for this,is there any
> issue logged for the same)
>
> apart from coding malpractices,lets suppose say there is a genuine need
> for more controls,
> I was wondering given that there is a OS limit on handles ,what are the
> ways to increase it?
> i know swing can be used to work around this problem since there are
> many controls there,which are rendered instead of using the underlying
> controls..but then again performance overheads creep up there..

Re: (no subject) [message #717028 is a reply to message #716787]

Fri, 19 August 2011 05:52

Messages: 608
Registered: July 2009

Senior Member

Its a plain RCP application with program arguments and vmarguments,
the -vm argument is not there, so will try it with that and get back to you with the results..(although there are no browser or OLE instances in my scenario but still)

But i thought a standalone RCP application or for that matter any java application starts in its own process right?,so i am not clear what you are pointing to.
Thanks Grant

---------------------
why, mr. Anderson, why, why do you persist?
Because I Choose To.
Regards,
Vijay

Re: (no subject) [message #718505 is a reply to message #717028]

Wed, 24 August 2011 14:03

Messages: 2150
Registered: July 2009

Senior Member

The eclipse launcher changed at some point to load the JRE into the
launcher's process by default. As a result if you look at the Task
Manager you'll see a process such as eclipse.exe, but not an
accompanying javaw.exe. When you launch an app from a running eclipse
then javaw.exe appears in the Task Manager because the JRE is simply
launched in a new process. There's not an obvious reason why these two
scenarios would cause different behaviours, but the Browsers case did
demonstrate this happening. The cause has not been determined yet.

Grant

On 8/19/2011 1:52 AM, vijay wrote:
> Its a plain RCP application with program arguments and vmarguments,
> the -vm argument is not there, so will try it with that and get back to
> you with the results..(although there are no browser or OLE instances in
> my scenario but still)
>
> But i thought a standalone RCP application or for that matter any java
> application starts in its own process right?,so i am not clear what you
> are pointing to.
> Thanks Grant

Re: (no subject) [message #720984 is a reply to message #718505]

Wed, 31 August 2011 15:17

Messages: 2150
Registered: July 2009

Senior Member

FWIW the Eclipse bug, including the cause of this difference, is in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=356354 .

Grant

On 8/24/2011 10:03 AM, Grant Gayed wrote:
> The eclipse launcher changed at some point to load the JRE into the
> launcher's process by default. As a result if you look at the Task
> Manager you'll see a process such as eclipse.exe, but not an
> accompanying javaw.exe. When you launch an app from a running eclipse
> then javaw.exe appears in the Task Manager because the JRE is simply
> launched in a new process. There's not an obvious reason why these two
> scenarios would cause different behaviours, but the Browsers case did
> demonstrate this happening. The cause has not been determined yet.
>
> Grant
>
>
> On 8/19/2011 1:52 AM, vijay wrote:
>> Its a plain RCP application with program arguments and vmarguments,
>> the -vm argument is not there, so will try it with that and get back to
>> you with the results..(although there are no browser or OLE instances in
>> my scenario but still)
>>
>> But i thought a standalone RCP application or for that matter any java
>> application starts in its own process right?,so i am not clear what you
>> are pointing to.
>> Thanks Grant
>