headers
Erik Huelsmann | 1 Jan 2009 15:48
Picon
Gravatar

compiler-subtypep vs subtypep

We seem to have an issue with the compiler using compiler-types -
which don't seem compatible with SUBTYPE, but need COMPILER-SUBTYPE -,
however it uses SUBTYPEP to check for subtypes in many places.

For an example, compilation of this code (taken from
CMUCL-TYPE-PROP.29 ANSI test):

(compile nil '(lambda (p1)
			   (declare (optimize (speed 2) (safety 1) (debug 0) (space 3))
				    (type (integer -4194320 11531) p1))
			   (- (the (integer -6253866924 34530147) p1))))

Produces this output (after optimization):

0 ALOAD_1 NIL NIL NIL
1 INSTANCEOF ("org/armedbear/lisp/Fixnum") NIL NIL
2 IFNE (#:G67) NIL NIL
3 ALOAD_1 NIL NIL NIL
4 GETSTATIC ("org/armedbear/lisp/Symbol" "FIXNUM"
"Lorg/armedbear/lisp/Symbol;") NIL NIL
5 INVOKESTATIC ("org/armedbear/lisp/Lisp" "type_error"
"(Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;")
-1 NIL
6 POP NIL NIL NIL
7 LABEL (#:G67) NIL NIL
8 ALOAD_1 NIL NIL NIL
9 CHECKCAST ("org/armedbear/lisp/Fixnum") NIL NIL
10 GETFIELD ("org/armedbear/lisp/Fixnum" "value" "I") NIL NIL
11 ISTORE (1) NIL NIL
12 NEW ("org/armedbear/lisp/Fixnum") NIL NIL
(Continue reading)

Permalink | Reply | 0 comments |
headers
Erik Huelsmann | 2 Jan 2009 10:31
Picon
Gravatar

New WITH-TRY/CATCH macro for the compiler

Currently, we generate a lot of typechecks like this:

aload N
instanceof <some class>
ifne :label1
aload N
getfield <some symbol field>
invokestatic type_error()
:label1
aload N
checkcast <same class>
invokevirtual do_something

However, in the Java side this is how the same is coded:

try {
   ((some class)argN).do_something();
}
catch (ClassCastException c) {
   type_error(some class symbol, argN);
   return; // not reached
}

In code efficiency, the latter is much better. So, I thought it would
be handy to have a construct like it available "easily" in the
compiler. That's why I created WITH-TRY/CATCH - similar to
HANDLER-CASE.

It allows creating the type check output like the java side:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Erik Huelsmann | 2 Jan 2009 10:31
Picon
Gravatar

New WITH-TRY/CATCH macro for the compiler

Currently, we generate a lot of typechecks like this:

aload N
instanceof <some class>
ifne :label1
aload N
getfield <some symbol field>
invokestatic type_error()
:label1
aload N
checkcast <same class>
invokevirtual do_something

However, in the Java side this is how the same is coded:

try {
   ((some class)argN).do_something();
}
catch (ClassCastException c) {
   type_error(some class symbol, argN);
   return; // not reached
}

In code efficiency, the latter is much better. So, I thought it would
be handy to have a construct like it available "easily" in the
compiler. That's why I created WITH-TRY/CATCH - similar to
HANDLER-CASE.

It allows creating the type check output like the java side:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Erik Huelsmann | 2 Jan 2009 10:31
Picon
Gravatar

New WITH-TRY/CATCH macro for the compiler

Currently, we generate a lot of typechecks like this:

aload N
instanceof <some class>
ifne :label1
aload N
getfield <some symbol field>
invokestatic type_error()
:label1
aload N
checkcast <same class>
invokevirtual do_something

However, in the Java side this is how the same is coded:

try {
   ((some class)argN).do_something();
}
catch (ClassCastException c) {
   type_error(some class symbol, argN);
   return; // not reached
}

In code efficiency, the latter is much better. So, I thought it would
be handy to have a construct like it available "easily" in the
compiler. That's why I created WITH-TRY/CATCH - similar to
HANDLER-CASE.

It allows creating the type check output like the java side:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Erik Huelsmann | 2 Jan 2009 10:37
Picon
Gravatar

Re: New WITH-TRY/CATCH macro for the compiler

> The macro is pasted on the web here: http://paste.lisp.org/display/72919#1

The weirdest thing is that before leaving home this morning, I pasted
the latest version - or so I thought - to that paste as an annotation,
but I can see now it's not up, not even as another page. So, the
latest version will come this afternoon.

Bye,

Erik.

------------------------------------------------------------------------------
Permalink | Reply | 1 comment |
headers
Erik Huelsmann | 2 Jan 2009 10:38
Picon
Gravatar

Re: New WITH-TRY/CATCH macro for the compiler

On Fri, Jan 2, 2009 at 10:37 AM, Erik Huelsmann <ehuels <at> gmail.com> wrote:
>> The macro is pasted on the web here: http://paste.lisp.org/display/72919#1
>
> The weirdest thing is that before leaving home this morning, I pasted
> the latest version - or so I thought - to that paste as an annotation,
> but I can see now it's not up, not even as another page. So, the
> latest version will come this afternoon.

However, they differ little and the one available should work too. The
PRINT in it should be removed, however.

Bye,

Erik.

------------------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Philip Hudson | 3 Jan 2009 00:08
Picon
Favicon

FastStringBuffer migrated to wrap StringBuilder

Here's the patch for changing FastStringBuffer to a wrapper for the  
Java 5 unsynchronized StringBuilder.

If you examine the patch it may look like a no-thought slash-and-burn  
change, but in fact I have examined every change carefully. I used a  
fairly comprehensive JUnit 4.x test to ensure I was maintaining  
identical functionality exactly, until I was confident about knock-on  
impacts within other ABCL code (hereafter 'client code'). This single  
unit test introduces JUnit unit testing to ABCL. I hope it will be a  
welcome change that quickly proves itself indispensable.

Then I made the following changes:

o Implemented CharSequence and Appendable on FastStringBuffer, that  
is, the same call interface as StringBuilder. CharSequence required  
three additional methods, all trivial.

o Excised FastStringBuffer's instance state -- two non-final fields,  
one a char array, the other an int -- instead delegating to a  
composed StringBuilder (final).

o Methods that previously threw unchecked concrete subtypes of  
IndexOutOfBoundsException now throw IOOBE instead, in line with the  
same-signature methods on StringBuilder. The only client code I could  
find was guaranteed never to throw the exception -- it checks the  
buffer's length first.

o Method void setText(String) has no equivalent in StringBuilder and  
no client code in ABCL. I have excised it. The unit test now tests  
for the absence of the method.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Mark Evenson | 3 Jan 2009 13:38
Picon
Favicon

FastStringBuffer migrated to wrap StringBuilder on trunk

Philip Hudson wrote:
> Here's the patch for changing FastStringBuffer to a wrapper for the Java 
> 5 unsynchronized StringBuilder.

Thanks for the patch, [committed to trunk as changeset 11527][11527]!

 From now on, ABCL trunk will use the FastStringBuffer as a delegate to 
StringBuilder.

The tests now work in the Ant-based build via the 'abcl.test' target.

Some notes:

o  The tests require JUnit 4.5 to run, which is now downloaded to a 
top-level directory called '${basedir}/ext'.  I expect this to be the 
most fragile part of the build system.

o  New Junit tests may be created under '${basedir}/test/src'.  Such 
tests must be explicitly added to the 'abcl.test.source.java' and 
'abcl.test.java' targets to be run.  This should be refactored (by me) 
into a common property.

o  ABCL 'trunk' [has moved][trunk] since Philip started his work.

o  I need to work out how to run the tests easily in the Netbeans 
project.  It should work fairly well as is but I need to avoid the junit 
download.

[11527]: http://trac.common-lisp.net/armedbear/changeset/11527
[trunk]: svn://common-lisp.net/project/armedbear/svn/trunk/abcl
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ville Voutilainen | 3 Jan 2009 14:40
Picon

Re: FastStringBuffer migrated to wrap StringBuilder

Hi Philip, glad you're back. Thanks for the patch!

> only performance improvements, especially on HotSpot. What bothers me is the
> lack of unit tests for the rest of the Java code; it feels very creepy
> making changes and not having a JUnit regression test to run. Easy enough to
> remedy, just takes time. That's really the only reason I don't say let's go
> ahead and make the full change straight away.

We mostly use the CL ansi-tests as our regression tests. We talked about
this before, IIRC. The tests are at
svn://common-lisp.net/project/ansi-test/svn/trunk/ansi-tests
For performance issues, you can use cl-bench, which is at
http://www.chez.com/emarsden/downloads/cl-bench.tar.gz

Mark, any chance of getting an ant target for running the tests?

------------------------------------------------------------------------------
Permalink | Reply | 4 comments |
headers
Mark Evenson | 3 Jan 2009 14:46
Picon
Favicon

Re: FastStringBuffer migrated to wrap StringBuilder

Ville Voutilainen wrote:
[…]
> Mark, any chance of getting an ant target for running the tests?

A target for Philip's code exists as 'abcl.test.java' after ABCL trunk 
r11527.

Or did you mean an Ant target for running ANSI-TESTS and CL-BENCH?  I 
would prefer to keep that invocation Lisp-side (ASDF-based), as it 
quickly gets quite complex to manage invocations from 'build.xml'. I 
would put this all in 'build.asd', and then have the 'build.xml' system 
invoke the ASDF operations as needed.

--

-- 
"A screaming comes across the sky.  It has happened before, but there is
nothing to compare to it now."

------------------------------------------------------------------------------
Permalink | Reply | 3 comments |

Gmane