[xHarbour-developers] WITH OBJECT

On Mon, 29 Jun 2015, Andi Jahja wrote:

Hi,

Post by Andi Jahja
Hello,
"WITH OBJECT excessive nesting!"
As per default build, HB_MAX_WITH_OBJECT is preset to 64.
But I am very sure that my application does not have that much nests.
This occurs when I repeatedly execute sub function containing WITH OBJECT.
I suspect the counter is not released after a nest reached an "END"
Anyone?

After short checking current HVM code in xHarbour I can see two possible
reasons:

1. You are using recursion.
Due to limitation in xHarbour implementation FOR EACH and WITH OBJECT
cannot be used in algorithms using recursion because they can reach
HB_MAX_WITH_OBJECTS or HB_MAX_ENUMERATIONS limits.
It's very serious problem I reported nearly 10 years ago.
To resolve it it's necessary to redesign FOR EACH and WITH OBJECT
implementation in xHarbour. It would be nice to also eliminate
overhead caused by current code. Even if programmer does not use
above constructions then HVM in xHarbour executes additional code
to initialize and finally clean FOR EACH and WITH OBJECT counters
and containers on each PRG function call what reduces overall
performance. The implementation in Harbour does not have such
problems so it can be taken as base.

2. Looks that code executed for -gc3 output does not restore FOR EACH
and WITH OBJECT counters. Such additional cleanup it's yet another
overhead in current implementation which can be eliminated new one.
Example below illustrates it:

#include "hbclass.ch"
proc main()
local i
for i := 1 to 100
begin sequence
with object i
if i < 100
break
endif
end with
endsequence
next
return

This can be easy fixed anyhow I strongly suggest to start deeper
modifications which resolved also other problems.

best regards,
Przemek

Andi Jahja

2015-06-30 13:13:19 UTC

Hi Przemek,

Many thanks for explanation. Fixing it is beyond my capabilities. For the time being, xHarbour users have to be careful when playing with With-Object and/or For-Each constructs.

Andi

On Tue, 30 Jun 2015 13:45:41 +0200

After short checking current HVM code in xHarbour I can see two possible
1. You are using recursion.
Due to limitation in xHarbour implementation FOR EACH and WITH OBJECT
cannot be used in algorithms using recursion because they can reach
HB_MAX_WITH_OBJECTS or HB_MAX_ENUMERATIONS limits.
It's very serious problem I reported nearly 10 years ago.
To resolve it it's necessary to redesign FOR EACH and WITH OBJECT
implementation in xHarbour. It would be nice to also eliminate
overhead caused by current code. Even if programmer does not use
above constructions then HVM in xHarbour executes additional code
to initialize and finally clean FOR EACH and WITH OBJECT counters
and containers on each PRG function call what reduces overall
performance. The implementation in Harbour does not have such
problems so it can be taken as base.
2. Looks that code executed for -gc3 output does not restore FOR EACH
and WITH OBJECT counters. Such additional cleanup it's yet another
overhead in current implementation which can be eliminated new one.
#include "hbclass.ch"
proc main()
local i
for i := 1 to 100
begin sequence
with object i
if i < 100
break
endif
end with
endsequence
next
return
This can be easy fixed anyhow I strongly suggest to start deeper
modifications which resolved also other problems.
best regards,
Przemek

Andi

Ron Pinkas

2015-07-08 20:15:25 UTC

Hi Andi,

Could you kindly post a reduced sample?

As long as you are not using -gc3 (as per Przemek observation) and/or recursion which exceeds the fixed limit, then I am not aware of such issue.

Ron

Post by Andi Jahja
Hi Przemek,
Many thanks for explanation. Fixing it is beyond my capabilities. For the time being, xHarbour users have to be careful when playing with With-Object and/or For-Each constructs.
Andi
On Tue, 30 Jun 2015 13:45:41 +0200

Andi
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
xHarbour-developers mailing list
https://lists.sourceforge.net/lists/listinfo/xharbour-developers

Andi Jahja

2015-07-08 21:23:48 UTC

Hi Ron:

Sorry for I cannot post a reduced code. The application is quite huge and I do not know where it happened.
Yes, I am using -gc3, but not aware where the recursion is. IMO, Przemek's example should demonstrate it.

Andi

On Wed, 8 Jul 2015 13:15:25 -0700

Post by Ron Pinkas
Hi Andi,
Could you kindly post a reduced sample?
As long as you are not using -gc3 (as per Przemek observation) and/or recursion which exceeds the fixed limit, then I am not aware of such issue.
Ron

Andi

Andi Jahja

2015-07-08 21:41:41 UTC

Yes it is, -gc3 is to produce C source. I think the bug is there, not in the VM engine. So, not using -gc3 may perhaps cure the problem.

Andi

On Wed, 8 Jul 2015 14:35:52 -0700

I am not by my computer, -gc3 is the switch to generate C calls instead of
PCODE?

Post by Andi Jahja
Sorry for I cannot post a reduced code. The application is quite huge and
I do not know where it happened.
Yes, I am using -gc3, but not aware where the recursion is. IMO, Przemek's
example should demonstrate it.
Andi
On Wed, 8 Jul 2015 13:15:25 -0700

Post by Ron Pinkas
Hi Andi,
Could you kindly post a reduced sample?
As long as you are not using -gc3 (as per Przemek observation) and/or

recursion which exceeds the fixed limit, then I am not aware of such issue.

Post by Ron Pinkas
Ron

Post by Andi Jahja
Hi Przemek,
Many thanks for explanation. Fixing it is beyond my capabilities. For

the time being, xHarbour users have to be careful when playing with
With-Object and/or For-Each constructs.

Post by Andi Jahja
Andi
On Tue, 30 Jun 2015 13:45:41 +0200

OBJECT.

Post by Andi Jahja

Post by Przemyslaw Czerpak

Post by Andi Jahja
I suspect the counter is not released after a nest reached an "END"
Anyone?

After short checking current HVM code in xHarbour I can see two

possible

Post by Andi Jahja

Post by Przemyslaw Czerpak
1. You are using recursion.
Due to limitation in xHarbour implementation FOR EACH and WITH

OBJECT

Post by Andi Jahja

Post by Przemyslaw Czerpak
cannot be used in algorithms using recursion because they can reach
HB_MAX_WITH_OBJECTS or HB_MAX_ENUMERATIONS limits.
It's very serious problem I reported nearly 10 years ago.
To resolve it it's necessary to redesign FOR EACH and WITH OBJECT
implementation in xHarbour. It would be nice to also eliminate
overhead caused by current code. Even if programmer does not use
above constructions then HVM in xHarbour executes additional code
to initialize and finally clean FOR EACH and WITH OBJECT counters
and containers on each PRG function call what reduces overall
performance. The implementation in Harbour does not have such
problems so it can be taken as base.
2. Looks that code executed for -gc3 output does not restore FOR EACH
and WITH OBJECT counters. Such additional cleanup it's yet another
overhead in current implementation which can be eliminated new one.
#include "hbclass.ch"
proc main()
local i
for i := 1 to 100
begin sequence
with object i
if i < 100
break
endif
end with
endsequence
next
return
This can be easy fixed anyhow I strongly suggest to start deeper
modifications which resolved also other problems.
best regards,
Przemek

Andi

Andi Jahja

2015-07-08 22:33:11 UTC

+1

I confirm that not using -gc3, the following snippet works fine:

#include "hbclass.ch"
proc main()
local i
for i := 1 to 100
begin sequence
with object i
if i < 100
break
endif
end with
endsequence
next
return

Andi

Ron Pinkas

2015-07-09 00:42:50 UTC

Hi Przemek, :-)

As always your input is greatly appreciated. I am sure I speak for everyone when I invite you to post fixes to problems you recognize. It probably would have taken you less time to fix the -gc3 omissions than writing this message. :-) In such cases it is more productive to simply post the fix, even if you envision a deeper more complete rewrite, as a better ultimate solution.

As to deeper changes and rewrites, they are welcomed too, as long as compatibility is maintained.

Again, many thanks, and I hope to quickly see some of your fixes.

Ron