This is now fixed on mono/master
On Fri, Oct 30, 2015 at 5:14 PM Ludovic Henry wrote:
> Hi Bill,
>
> That's an issue in the mini.c code. I will fix it ASAP.
>
> Thank you!
>
> Ludovic
>
> On Fri, Oct 30, 2015 at 3:33 PM Bill Seurer
> wrote:
>
>> The GC safepoint code is causing me compilation p
Hi Bill,
That's an issue in the mini.c code. I will fix it ASAP.
Thank you!
Ludovic
On Fri, Oct 30, 2015 at 3:33 PM Bill Seurer
wrote:
> The GC safepoint code is causing me compilation problems. In mini.h the
> definition of OP_GC_SAFE_POINT is #ifed:
>
> #if defined(TARGET_AMD64) || defined
The GC safepoint code is causing me compilation problems. In mini.h the
definition of OP_GC_SAFE_POINT is #ifed:
#if defined(TARGET_AMD64) || defined(TARGET_X86) || defined(TARGET_ARM)
|| defined(TARGET_ARM64) || defined(TARGET_S390X)
MINI_OP(OP_GC_SAFE_POINT, "gc_safe_point", NONE, IREG,
If I remember correctly (so wait for someone that can be more precise), except
for some debug support, the only real difference between the two implementation
is the worker implementation. Nothing that can really justify this difference,
if we can assume that you use the same collector and the s
Hi,
We were helping someone who was having performance problems with a large
streaming application that they run under .NET and mono. On .NET the app
takes around 7-10 seconds to do its stuff. On Mono on Linux it was taking
47 seconds or so to do the same thing. The mono system had 256G RAM and 48
Mono 2.10 is more than 3 years old.
Precise stack marking only became available a year after that.
Miguel
On Fri, Aug 8, 2014 at 5:40 AM, Zoltán Tóth wrote:
> Thank you Miguel for the answer,
>
> So does "MONO_GC_PARAMS=stack-mark=precise" give me TOTALLY precise
> scanning?
> The reasons i i
Thank you Miguel for the answer,
So does "MONO_GC_PARAMS=stack-mark=precise" give me TOTALLY precise
scanning?
The reasons i insist questioning are that the Release notes page of v_2.10
[1] says that it gives me only "mostly precise fashion" [though obviously
its effect could have changed since 2.
This is now controlled with MONO_GC_PARAMS, you can set the variable to
stack-mark=precise
To use precise stack marking. There are a few reasons that this is not
the default:
- Legacy: many applications embedding Mono assumed that icalls/pinvokes
that manipulated managed objects did not
Hi, I am new here and to Mono. I am considering adopting Mono as my main
platform of programming. I am interested in the precision of the Mono
garbage collector.
A few months ago I already wrote to the mono-gc list, but have not got
answer, looks like that list is inactive.
Mono seems to have an
Boehm under mono does correctly support weak references.
On Sat, Jun 30, 2012 at 3:42 PM, Gleb Golubitsky wrote:
> Does your code use weak references? (maybe indirectly, they may be in use
> inside mono code you call) If so, it's a known boehm problem -- it handles
> weak references as strong.
>
Does your code use weak references? (maybe indirectly, they may be in use
inside mono code you call) If so, it's a known boehm problem -- it handles
weak references as strong.
On Tuesday, June 26, 2012 07:48:22 AM Greg Young wrote:
> We have some code we are running in various environments.
>
>
I realize some in depth test for lockless queue and using bohem the
memory usage was greater that sgen.
Moreover and after some time the memory usage increase a lot like if a
buffer was not released under bohem, while sgen was stable.
I made the test using mono 2.10.9
Best Regards
2012/6/26 Gr
On Tue, Jun 26, 2012 at 7:48 PM, Greg Young wrote:
> We have some code we are running in various environments.
>
> It is stable for memory usage in MS CLR
> It seems to be leaking in boehm (pretty quickly)
> It is stable for memory usage in sgen
>
> My first thought was to start taking memory dum
We have some code we are running in various environments.
It is stable for memory usage in MS CLR
It seems to be leaking in boehm (pretty quickly)
It is stable for memory usage in sgen
My first thought was to start taking memory dumps to see whats going
on but maybe someone knows some kinds of si
I've attached a patch that implements GC safe points via polling. I was
wondering if I could get some feedback since my GSoC work shall largely
be based on the same code.
Simply put, the idea is to stop all threads first and then advance the
ones running managed code to the next nearest safe point
: mono-devel
Subject: Re: [Mono-dev] gc heap & multi-threading
Wonderful! That's music to my ears! :)
- Steve
--
Steve G. Bjorg
http://mindtouch.com
http://twitter.com/bjorg
irc.freenode.net #mindtouch
On May 27, 2009, at 7:29 AM, Rodrigo Kumpera wrote:
It
Wonderful! That's music to my ears! :)
- Steve
--
Steve G. Bjorg
http://mindtouch.com
http://twitter.com/bjorg
irc.freenode.net #mindtouch
On May 27, 2009, at 7:29 AM, Rodrigo Kumpera wrote:
It does TLA under linux and the upcoming GC will be even better at
this.
On Wed, May 27
It does TLA under linux and the upcoming GC will be even better at this.
On Wed, May 27, 2009 at 10:52 AM, Steve Bjorg wrote:
> Sorry for resending this, but I really need to know if my work on
> concurrency optimizations will apply to Mono as well. If so, I'd love
> to contribute back the work
Sorry for resending this, but I really need to know if my work on
concurrency optimizations will apply to Mono as well. If so, I'd love
to contribute back the work-stealing scheduler which is similar to the
one found in .Net 4.0. Thanks.
---
I'm working on some lock-free data structures i
I'm working on some lock-free data structures in c# and have a
question on the internals of the GC on mono. Does each thread have
its own heap that it can allocate from? Or asked differently, does
"new object()" always cause a lock on the global heap or only when the
thread's local heap i
Hi,
Am 29.01.2009 um 18:49 schrieb pablosantosl...@terra.es:
> I'm trying to run Plastic SCM tests on the Mono (2.0.1) build I made
> on
> Solaris x86 (available on Blastwave, testing area. Soon you'll have
> 2.2).
>
> I'm getting this every time I run a mono app:
>
> GC Warning: Large stack
Hi,
I'm trying to run Plastic SCM tests on the Mono (2.0.1) build I made on
Solaris x86 (available on Blastwave, testing area. Soon you'll have 2.2).
I'm getting this every time I run a mono app:
GC Warning: Large stack limit(10485760): only scanning 8 MB
Do you know how can I fix this on my b
Zoltan Varga wrote:
> Hi,
>
> AFAIK, the GC only stops threads which are registered with it. This
> can happen in
> the following ways:
> - threads started by the runtime are registered automatically
> - threads registered using mono_thread_attach ().
> - on unix, if an application includes gc.h,
Hi,
AFAIK, the GC only stops threads which are registered with it. This
can happen in
the following ways:
- threads started by the runtime are registered automatically
- threads registered using mono_thread_attach ().
- on unix, if an application includes gc.h, the header file will
redefine pthrea
Hi,
When the GC is under stress because a lot of managed allocations
happen we get sound stuttering.
It seems very likely that the GC is doing that when it calls Stop
World on all other threads.
Is there any way to make the Garbage collector only stop threads
which are registered using mono_
On 03/10/08 Bill Holmes wrote:
> Should I file a bug report on this?
This is a limitation of our current JIT/GC, there is no need to file a
bug about this. If you move the object creation in it's own method
and call that from Main() it should behave as you expect (at least most
of the time, our GC
I did not want to file a bug on this just yet as it may be related to
https://bugzilla.novell.com/show_bug.cgi?id=319247 . Or it just may
be a bad test case.
The following code under MS.net displays
_activeCount = 1
_activeCount = 0
Where mono displays
_activeCount = 1
_activeCount = 1
Should
On Jun 13, 2006, at 5:16 PM, Allan Hsu wrote:
I've been spending some time trying to fix a mach port leak that
occurs under OS X. The bug (and the progress that I've been making)
is logged here:
http://bugs.ximian.com/show_bug.cgi?id=78628
I think I've fixed this with a patch against libg
I've been spending some time trying to fix a mach port leak that
occurs under OS X. The bug (and the progress that I've been making)
is logged here:
http://bugs.ximian.com/show_bug.cgi?id=78628
I've made a little progress by adding calls to mach_port_deallocate()
in darwin_stop_world.c and
> Just a wild guess: your P4 is a SMP machine (hyperthreading).
> Since VMware (where you said the startup time is fast) doesn't
> simulate SMP, I'd say this is a SMP problem of the GC.
Yes, it is a P4 with HT.
Is long GC startup time on SMP machines a known issue? (if so - why it
does not manife
Hey,
When profiling our startup times on Windows, I noticed that GC_init
takes quite long (~1.5 seconds on P4 3GHz), called from DllMain.
The call graph goes roughly like this: DllMain -> GC_init ->
GC_init_inner -> GC_gcollect_inner (GC_try_to_collect_inner) ->
GC_stopped_mark -> GC_mark_some_
Hi,
When profiling our startup times on Windows, I noticed that GC_init
takes quite long (~1.5 seconds on P4 3GHz), called from DllMain.
The call graph goes roughly like this: DllMain -> GC_init ->
GC_init_inner -> GC_gcollect_inner (GC_try_to_collect_inner) ->
GC_stopped_mark -> GC_mark_some_inn
code
tarball instead of make clean to make sure nothing remains after cleanup.
Kornél
- Original Message -
From: "Gert Driesen" <[EMAIL PROTECTED]>
To: "'Atsushi Eno'" <[EMAIL PROTECTED]>
Cc:
Sent: Saturday, September 10, 2005 8:17 PM
Subject
> -Original Message-
> From: Atsushi Eno [mailto:[EMAIL PROTECTED]
> Sent: zaterdag 10 september 2005 12:01
> To: Gert Driesen
> Cc: mono-devel-list@lists.ximian.com
> Subject: Re: [Mono-dev] GC error bootstrapping on Windows
>
> Hi,
>
> Many of us
Hi,
Many of us experienced that (including me). Make sure to build
clean bootstrap. It was around r48831, not new one.
Atsushi Eno
Gert Driesen wrote:
Hi,
When bootstrapping mono (from SVN) on Windows, I now get the following
error:
** ERROR **: Thread FFFE calling into managed code is
Hi,
When bootstrapping mono (from SVN) on Windows, I now get the following
error:
** ERROR **: Thread FFFE calling into managed code is not registered
with the GC. On UNIX, this can be fixed by #include-ing before
in the file containing the thread creation code.
aborting...
Can someone lo
On 08/22/05 Tomi Valkeinen wrote:
> Yes, I did test it. All compilers seem to produce correct code after the
> change. The interesting part with the bug is that even if the produced
> code is against ARM reference manual, it works with all the ARM9
> processors I have tested, but fails with ARM11.
On Sat, 20 Aug 2005, Paolo Molaro wrote:
On 08/18/05 Tomi Valkeinen wrote:
Oh, and if you are using an ARM11 based board, you may also want to fix
the swp-bug (http://bugzilla.ximian.com/show_bug.cgi?id=75114)
Did you test that change?
Care to research with the libc guys why they wrote it that
On 08/18/05 Tomi Valkeinen wrote:
> I got the GC running after changing the method of finding the stack bottom
> from HEURISTIC1 to LINUX_STACKBOTTOM (gcconfig.h:1755). I don't know why
> LINUX_STACKBOTTOM wasn't used on arm linux by default, the code looks
> arm-runnable to me.
This change is
Tomi Valkeinen wrote:
Hi again,
currently have a functional big endian ARM linux system that I have
used
to successfully build the ARM JIT. However, upon attempting to run a
CIL executable, mono immediately segfaults. A backtrace indicates that
the segfault occurs in the Boehm GC:
Program
Paul F. Johnson wrote:
Hi,
I
currently have a functional big endian ARM linux system that I have used
to successfully build the ARM JIT. However, upon attempting to run a
CIL executable, mono immediately segfaults.
Out of interest, which ARM core are you using? I'm pretty well up
I'm a consultant working under contract for Maraki Corp., a startup that
will eventually be deploying Mono in an embedded ARM environment. My
job at this stage is to get the ARM JIT recently checked into SVN to run
on our ARM boards and contribute back bug fixes/enhancements. I
currently have
Hi again,
currently have a functional big endian ARM linux system that I have used
to successfully build the ARM JIT. However, upon attempting to run a
CIL executable, mono immediately segfaults. A backtrace indicates that
the segfault occurs in the Boehm GC:
Program received signal SIGSEGV,
Hi,
currently have a functional big endian ARM linux system that I have used
to successfully build the ARM JIT. However, upon attempting to run a
CIL executable, mono immediately segfaults. A backtrace indicates that
the segfault occurs in the Boehm GC:
Program received signal SIGSEGV, Segmen
Hi,
I
> currently have a functional big endian ARM linux system that I have used
> to successfully build the ARM JIT. However, upon attempting to run a
> CIL executable, mono immediately segfaults.
Out of interest, which ARM core are you using? I'm pretty well up on the
ARM range and all of
45 matches
Mail list logo
