# New Ticket Created by Mike Lambert
# Please include the string: [netlabs #634]
# in the subject line of all future correspondence about this issue.
# URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=634
Peter recently submitted a patch to RT that uses a linked-list for free
headers.
# New Ticket Created by Mike Lambert
# Please include the string: [netlabs #636]
# in the subject line of all future correspondence about this issue.
# URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=636
Peter's latest patch also included changes to the logic in terms of what
to do
I've modified his patch to remove some unnecessary calculations.
before after
gc_alloc_new.pbc 4.1559993.756002
gc_alloc_reuse.pbc16.574 9.423002
gc_generations.pbc4.025 5.278002
Results are:
before after
gc_alloc_new.pbc 4.1559990.18
gc_alloc_new seems to have improved a *lot*. This is because
gc_alloc_new allocates a lot of memory using the same headers. It
doesn't tear through headers quickly enough to
On Tue, May 28, 2002 at 07:35:43PM -0700, Hong Zhang wrote:
Parrot has to handle signals, such as SIGSEGV.
That's the one signal I really hope parrot *doesn't* handle.
Dave.
--
A walk of a thousand miles begins with a single step...
then continues for another 1,999,999 or so.
On Wed, May 29, 2002 at 02:08:25AM -0400, Mike Lambert wrote:
gc_alloc_new.pbc
allocates more and more memory
checks collection speed, and the ability to grow the heap
gc_alloc_reuse.pbc
allocates more memory, but discards the old
checks collection speed, and the ability to reclaim the
At 11:17 AM +0200 5/24/02, Sebastian Bergmann wrote:
Hello there!
I'm currently preparing an article on Parrot for a German magazine.
Cool. Can we have a URL when it's done? (An english translation'd be
keen too, but there's always BabelFish to mangle the heck out of it)
While
On Tue, May 28, 2002 at 05:47:56PM -0700, Hong Zhang wrote:
Important given: We can *not* use setjmp/longjmp. Period. Not an
option--not safe with threads. At this point, having considered the
alternatives, I wish it were otherwise but it's not. Too bad for us.
I think this statement
Now I attached all the files :)
I also added now the target disassemble, it will emit on stdout the
disassemble of a pbc, this output is (should be) ready to assemble.
(it might have some issues with strings).
Daniel Grunblatt.
On 27 May 2002, Daniel Grunblatt wrote:
# New Ticket Created by
On Tue, 28 May 2002, Hong Zhang wrote:
Important given: We can *not* use setjmp/longjmp. Period. Not an
option--not safe with threads. At this point, having considered the
alternatives, I wish it were otherwise but it's not. Too bad for us.
I think this statement is not very accurate.
On Wed, May 29, 2002 at 11:45:45AM -0500, David M. Lloyd wrote:
Dan may have been referring to the fact that on some key platforms
(Solaris included) (sig)setjmp/longjmp are officially marked as unsafe for
use inside of threads.
Is it really unsafe on these platforms?
- According to the Unix
gc_alloc_new.pbc
gc_alloc_reuse.pbc
I don't think these two tests are very interesting. They allocate
quite large strings, so they don't put much strain on the GC.
Instead, they measure how fast Parrot is at copying strings.
I believe that's a very good thing to be testing. If the pool
gc_alloc_new.pbc
gc_alloc_reuse.pbc
I don't think these two tests are very interesting. They allocate
quite large strings, so they don't put much strain on the GC.
Instead, they measure how fast Parrot is at copying strings.
I believe that's a very good thing to be testing. If the
At 7:15 AM + 5/29/02, Mike Lambert (via RT) wrote:
We win on the header-intensive stuff. Not sure why it would be slower on
the gc_header_new tests. My best guess is that we know are touching the
contents of the buffer header, which we weren't doing before. And when we
allocate a bunch of new
At 8:24 PM +0200 5/29/02, Jerome Vouillon wrote:
On Wed, May 29, 2002 at 11:45:45AM -0500, David M. Lloyd wrote:
Dan may have been referring to the fact that on some key platforms
(Solaris included) (sig)setjmp/longjmp are officially marked as unsafe for
use inside of threads.
Is it really
On Wed, 29 May 2002, Jerome Vouillon wrote:
On Wed, May 29, 2002 at 11:45:45AM -0500, David M. Lloyd wrote:
Dan may have been referring to the fact that on some key platforms
(Solaris included) (sig)setjmp/longjmp are officially marked as unsafe for
use inside of threads.
Is it really
On Wed, 29 May 2002, Mike Lambert wrote:
Hey all,
After finding out that life.pasm only does maybe 1KB per collection, and
Sean reminding me that there's more to GC than life, I decided to create
some pasm files testing specific behaviors.
Attached is what I've been using to test and
At 10:53 AM +0100 5/29/02, Dave Mitchell wrote:
On Tue, May 28, 2002 at 07:35:43PM -0700, Hong Zhang wrote:
Parrot has to handle signals, such as SIGSEGV.
That's the one signal I really hope parrot *doesn't* handle.
What, you don't think we should wedge ourselves into the system MMU
At 5:47 PM -0700 5/28/02, Hong Zhang wrote:
Okay, i've thought things over a bit. Here's what we're going to do
to deal with infant mortality, exceptions, and suchlike things.
Important given: We can *not* use setjmp/longjmp. Period. Not an
option--not safe with threads. At this point,
Mike,
The GC benchmarks officially count as a Good Thing, and Daniel's
committed them to the repository. If other folks have benchmark
things (Even, or especially, long running and reasonably stressful
code) we can commit them as well, so we can have some handle as to
how we're performing as
On Wed, May 29, 2002 at 03:23:41PM -0400, Dan Sugalski wrote:
At 10:53 AM +0100 5/29/02, Dave Mitchell wrote:
On Tue, May 28, 2002 at 07:35:43PM -0700, Hong Zhang wrote:
Parrot has to handle signals, such as SIGSEGV.
That's the one signal I really hope parrot *doesn't* handle.
What,
I've checked with some Sun folks. My understanding is that if you
don't do a list of what I'd consider obviously stupid things like:
*) longjmp out of the middle of an interrupt handler
*) longjmp across a system call boundary (user-system-user and the
inner jumps to the outer)
*)
Actually I'd been given dire warnings from some of the Solaris folks.
Don't use setjmp with threads!
I've since gotten details, and it's Don't use setjmp with threads
and do Stupid Things.
I used to be at Sun. I knew those warnings too. If we use longjmp
carefully, we can make it. In the
On Wed, 29 May 2002, Hong Zhang wrote:
Actually I'd been given dire warnings from some of the Solaris folks.
Don't use setjmp with threads!
I've since gotten details, and it's Don't use setjmp with threads
and do Stupid Things.
I used to be at Sun. I knew those warnings too. If we
I used to be at Sun. I knew those warnings too. If we use longjmp
carefully, we can make it. In the worst case, write our own version.
..Or we could use setcontext/getcontext, could we not?
The setcontext/getcontext will be much worse than setjmp/longjmp.
The are more platform specific
On Wed, 29 May 2002, Hong Zhang wrote:
I used to be at Sun. I knew those warnings too. If we use longjmp
carefully, we can make it. In the worst case, write our own version.
..Or we could use setcontext/getcontext, could we not?
The setcontext/getcontext will be much worse than
At 15:22 on 05/29/2002 EDT, Dan Sugalski [EMAIL PROTECTED] wrote:
I think we'll be safe using longjmp as a C-level exception handler.
I'm right now trying to figure whether it's a good thing to do or
not. (I'd like to unify C and Parrot level exceptions if I can)
Just make sure that we
*) Expect POSIX's dead-stupid mutexes to magically unlock
Hmmm, are we confident that we can write exception handling and stack
rollback code that will always clean up mutexes?
--
There's something wrong with our bloody ships today, Chatfield.
Admiral Beatty at the Battle of Jutland, 31st May
When I was working on HotSpot JVM, we had some problems with getcontext.
They work 99.99% of time. We added many workaround for the .01% cases. I
believe the Solaris guys have been improving the code. I am not sure of
the current status.
Was that inside of a signal handler or just in
Aplogies if this has already been discussed, but I haven't been following
p6i too closely of late (the lure of being allowed to mess with 5.7.3
has been too strong :-)
Anyway, I presume that the Perl6 theading model will be like Perl 5
ithreads - that is to say, each thread has its own
Melvin Smith wrote:
I'm curious, is it possible to carve out an ICU-lite in ANSI-C89?
It is possible, but it depends on what you want. From what I understand,
the ICU common library would cover most of your basic Unicode needs, and
most of the effort could be put there.
As I recall, the
31 matches
Mail list logo
