to make sure upfront that we actually will be able to use
that amount of RAM….
Do you care about the length of GC pause times? I mean the absolute
length, not the relative amount of time the GC consumes. (If your
programs do anything but batch processing then you probably do).
Mark
--
Mark
On Wed, Sep 21, 2011 at 1:20 PM, Daniel Kirstenpfad dan...@sones.de wrote:
Well actually we're about to introduce some changes into our import
functionality which will be as cautious as possible to not create
intermediate objects but only objects that stay. So mainly it will be a
growing
We don't remove weak links from monitors, which is a problem on
shutdown with SGen and might lead to a crash. One way to reproduce
this is to run xsp2 with SGen with hi.aspx
(http://gist.github.com/551015), let it server a bit (ab -n 1 -c
20 -k http://127.0.0.1:8080/hi.aspx), then quit it by
On Tue, Aug 3, 2010 at 2:23 PM, Sergei Dyshel qyron.priv...@gmail.com wrote:
I tried to build recent trunk version and got following error:
mini-ppc.c: In function ‘calculate_sizes’:
mini-ppc.c:999: error: ‘gsctx’ undeclared (first use in this function)
mini-ppc.c:999: error: (Each undeclared
On Tue, Aug 3, 2010 at 4:17 PM, Sergei Dyshel qyron.priv...@gmail.com wrote:
Thanks, seems to get built OK (don't know how to check correctness though).
Run make check in mono/tests.
Mark
___
Mono-devel-list mailing list
On Fri, Jul 30, 2010 at 3:12 AM, Mark Probst mark.pro...@gmail.com wrote:
If nobody objects I'll push that to the public repository and never
write a ChangeLog entry again.
Which is what I've just done. The last commit with a compulsory
ChangeLog entry was this:
http://github.com/mono/mono
On Wed, Jul 28, 2010 at 5:12 PM, Mark Probst mark.pro...@gmail.com wrote:
If nobody else does it I'm volunteering - I really, really want to get
rid of ChangeLogs :-)
And here is the script:
http://github.com/schani/mono/tree/commit-to-changelog
Here are a few test cases:
http
On Thu, Jul 29, 2010 at 5:49 PM, Raja R Harinath harin...@gmail.com wrote:
What happens if I use a directory prefix? Additional log information?
http://github.com/schani/mono/commit/3132fb81d52bc31446e856e6e14f44e8e80f0f36
Mark
___
Mono-devel-list
On Thu, Jul 29, 2010 at 6:00 PM, Raja R Harinath harin...@hurrynot.org wrote:
We can choose a flag day, say this weekend, when we stop adding
ChangeLogs. The script already seems to handle stray ChangeLog updates,
but it can trim the history it needs to scan by using
git log --no-merges
On Thu, Jul 29, 2010 at 5:44 PM, Geoff Norton gnor...@novell.com wrote:
I think this looks great, but before we can get rid of them we probably need
to integrate this into make dist so that its automatic, so we need some way
of determining the start commit programatically if at all possible.
, really want to get
rid of ChangeLogs :-)
The question is what kind of format we want:
Do we want to keep the per-file comments?
Let's say my commit touches metadata/sgen-gc.c and metadata/sgen-gc.h.
Do we want
---
2010-07-28 Mark Probst mark.pro...@gmail.com
* sgen-gc.c, sgen-gc.h: Important
On Tue, Jul 27, 2010 at 11:42 PM, Rodrigo Kumpera kump...@gmail.com wrote:
I have another proposition to make. Can we stop using Changelog files? Those
can be generated from the commit logs for tarballs and releases without
losing anything at all. Commit messages would still have to be at least
On Tue, Jul 27, 2010 at 11:37 PM, Dale Ragan dale.ra...@sinesignal.com wrote:
+1 on the commit message change
I'd also like to vote, along with work branches be in user's forks, to use
this model:
http://nvie.com/git-model
One detail I really like about this is the non-fast-forwarding merge
On Fri, Jul 23, 2010 at 9:35 AM, Leszek Ciesielski skol...@gmail.com wrote:
what is current status of F# tail calls on Mono? I am doing a master
thesis on functional languages in .Net and, for the practical part, I
am planning to improve Mono F# support. Judging from the materials on
the web,
The mono_sgen_is_worker_thread() will be needed soon when SGen
actually uses worker threads, for parallel mark and concurrent sweep.
Please review, Geoff.
Mark
sgen-darwin-exception-thread
Description: Binary data
___
Mono-devel-list mailing list
On Sat, Jun 19, 2010 at 2:07 AM, Geoff Norton gnor...@novell.com wrote:
This time with the actual patch.
The patch doesn't include sgen-os-*.c, but since they only consist of
mono_sgen_thread_handshake() there's not much that can go wrong.
Other than that it looks perfect SGen-wise! Thanks!
On Thu, Jun 17, 2010 at 10:02 PM, Geoff Norton gnor...@novell.com wrote:
I finished up arm support for sgen this morning. Attached is a patch which
implements support for linux/arm and darwin/arm, but I've only tested
linux/arm so far.
Awesome! Looks good to me.
Mark
On Thu, Jun 17, 2010 at 4:54 PM, Geoff Norton gnor...@novell.com wrote:
Comments?
Why is it necessary to have mono_ wrappers for arch-neutral Mach
functions, like mach_port_deallocate()?
It would be nice to have at least the larger Mach-centric parts in a
separate file sgen-mach.c, or
On Fri, Jun 11, 2010 at 2:57 PM, cs_eps christian.sch...@eps.ch wrote:
We are developing an Application that we want to run on an embedded linux
with mono.
We have limited RAM and some longtime memory problem, which possibly can be
avoideded with a compacting GC.
SGen is not a compacting GC
optimized out, end=3)
at sgen-gc.c:1121
...
I've attached the first two patches adapted to the new LOS code.
It would be nice if all the block map code was in a separate file
(sgen-blockmap.c).
Mark
From: Mark Probst mark.pro...@gmail.com
---
mono/metadata/ChangeLog |7 +++
mono
On Tue, May 25, 2010 at 4:25 PM, Jonathan Gagnon
jonathan.gag...@croesus.com wrote:
Here's a simple test case that doesn't behave properly with sgen. The
runtime doesn't crash, but I get a NullReferenceException where I shouldn't.
Fixed. Thanks!
Mark
Hi Jonathan,
I did some tests with May 19th tarballs and I'm impressed to see that the
memory usage in one of my test is a lot lower when using sgen compared to
boehm.
That's good to hear! We're getting similar reports from the Plastic SCM folks.
Stability also seemed to be great until I
Hey Rodrigo,
+static void
+null_ephemerons_for_domain (MonoDomain *domain)
+{
+ EphemeronLinkNode *current = ephemeron_list, *prev = NULL;
+
+ while (current) {
+ MonoObject *object = (MonoObject*)current-array;
+
+ /*No need to look inside the array as the
On Tue, Apr 27, 2010 at 5:41 PM, Rodrigo Kumpera kump...@gmail.com wrote:
The problem with old gen arrays is due to their content not been marked it
might end up pointing to freed memory.
Maybe I misunderstand, but by scanning the remsets like usual all
nursery objects reachable from old gen
On Mon, Apr 26, 2010 at 10:25 PM, Rodrigo Kumpera kump...@gmail.com wrote:
Once this is properly working, two additional improvements should be done.
Split the registered arrays in two, for nursery and oldgen and use remset
information to know which old gen arrays needs to be scanned.
I doubt
On Tue, Mar 30, 2010 at 1:06 AM, Sanjoy Das
san...@playingwithpointers.com wrote:
Patch fixed. Will not work unless the patch to driver.c (attached) is
also applied.
Committed. Thanks.
Mark
___
Mono-devel-list mailing list
On Wed, Mar 24, 2010 at 12:40 AM, Sanjoy Das
san...@playingwithpointers.com wrote:
Patch (subject to a #define) allows the user to set the nursery size
using the environmental variable MONO_GC_PARAMS.
Sorry I took so long to review this.
This patch doesn't work. First of all, it never sets
On Wed, Mar 24, 2010 at 11:37 AM, Paolo Molaro lu...@ximian.com wrote:
One solution is to introduce a function similar to
GC_call_with_alloc_lock() in the Boehm GC, so that the unsafe table
manipulation can be done without risk of interruption from the GC.
Another one is to expose the critical
The first patch make mono-ehash SGen-aware, the second implements
CEE_MONO_TLS on Darwin/x86.
Mark
sgen-fix-ehash
Description: Binary data
sgen-darwin-x86-tls
Description: Binary data
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
On Sat, Mar 20, 2010 at 2:03 PM, Sanjoy Das
san...@playingwithpointers.com wrote:
Patch with the mentioned issues taken care of. Passes all corlib tests
other than the interned string one.
Looks very good, thanks!
Please take the first hunk out, though - we'll still want the aligned
nursery by
Committed. Thanks!
Mark
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
? If the
latter is true, I would love to get some pointers to where all work is
required to get it working.
As far as I can see the only thing preventing the non-aligned nursery
from working is the missing case in mono_gc_get_write_barrier(), but
you never know until you try :-)
Mark
--
Mark
against nursery_start?
Also, unless you have a good reason, you should use short-circuit
evaluation, i.e. instead of
a b cgt
d e clt
and
brtrue exit
continue:
do
a b ble continue
d e bge continue
br exit
continue:
Mark
--
Mark Probst
http://www.complang.tuwien.ac.at/schani
Hello everybody,
SGen, our new garbage collector, has improved quite a bit since my
last plea for testers about a month ago, so here I go again... We've
improved stability, performance, and, most importantly, memory
consumption, to the point where SGen now uses less memory than Boehm
for the
Sorry, I forgot to post this on the list as well.
-- Forwarded message --
From: Mark Probst mark.pro...@gmail.com
Date: Tue, Dec 8, 2009 at 11:42 AM
Subject: Re: [Mono-dev] 21 test(s) did not pass.
To: KISHIMOTO, Makoto ksmak...@dd.iij4u.or.jp
Cc: Zoltan Varga var...@gmail.com
SGen, our new garbage collector, doesn't explicitly store an object's
size but determines it via the object's vtable and, in the case of
arrays and strings, via the length field. String.InternalSetLength
changes that length field, which means that, from SGen's view, the
string's size changes.
On Wed, Nov 18, 2009 at 2:25 AM, Rodrigo Kumpera kump...@gmail.com wrote:
Yes, sgen is planned to work on mac, but it hasn't been ported yet.
Actually, SGen already compiles without __thread - the check in the
configure script is not necessary anymore. I'll remove it.
Whether SGen works on
On Tue, Nov 10, 2009 at 4:57 PM, Alden Torres alde...@yahoo.com wrote:
I'm trying to compile mono from the latest revision in the trunk with sgen
GC.My OS is Ubuntu 8.04 in a 1and1 VPS. I'm getting the following error:
Could you please try configuring mono with the additional option
On Mon, Sep 28, 2009 at 11:41 PM, Miguel de Icaza mig...@novell.com wrote:
The problem with AppDomains is that upon unloading there is a potential
for leaking vtables, something that I do not particular think is as
important as being able to scan the AppDomains precisely.
This is one of the
On Tue, Sep 29, 2009 at 8:28 PM, Miguel de Icaza mig...@novell.com wrote:
I am not sure I understand from the description above how would leaking
the vtables kill SGen.
The problem is not leaking VTables, but leaking objects across
domains, i.e. having references from objects in one domain to
On Fri, Sep 11, 2009 at 4:28 PM, Dick Porter dpor...@codicesoftware.com wrote:
If you'd like to help, I'll write up a document with what I've learned
debugging SGen.
Yes please.
Here it is. It's mostly a description of some SGen-internals and a
rationale for why some things are the way they
On Fri, Sep 11, 2009 at 3:02 PM, Dick Porter dpor...@codicesoftware.com wrote:
Is there a known list of jobs needed for sgen, or is it just a case of
working through the failures and bugs?
At this point we're still in the bug-fixing stage, which means finding
and fixing more and more obscure
On Fri, Sep 11, 2009 at 8:35 PM, Rodrigo Kumpera kump...@gmail.com wrote:
It's worth pointing out that SGEN won't build on windows or OSX at the
moment
since it requires a working __thread implementation. Mark has been working
on
lifting this requirement but the code haven't been committed
On Thu, Sep 10, 2009 at 6:52 PM,
pablosantosl...@terra.espablosantosl...@terra.es wrote:
We tried to build it today since we're experiencing issues with libgc under
really heavy load.
SGen is not production-ready yet. It cannot even run the corlib
testsuite completely, yet, so I doubt it will
On Sun, Aug 23, 2009 at 11:02 PM, Rodrigo Kumperakump...@gmail.com wrote:
Mono doesn't really needs to support tail call on all valid positions, doing
as well as MS is enough for F# workloads.
Doing well enough as MS does require callee-pops-args. If we don't
have that the most we can do is
On Sun, Aug 23, 2009 at 10:07 PM, Rodrigo Kumperakump...@gmail.com wrote:
Mono doesn't support TCO as well as .NET.
It's planned to be fixed eventually. The problem is that the mono team at
Novell
doesn't have available manpower to fix this anytime soon.
So, if you do care about F# on mono,
On Fri, Jun 12, 2009 at 4:45 PM, Lucas Meijerlu...@lucasmeijer.com wrote:
I'm getting this stacktrace. (embedded mono trunk, windows). If I
replace the trunk dll with a mono 2.4 dll, things work fine.
Please file a bug report on
https://bugzilla.novell.com/
and include enough information
On Sun, Jun 7, 2009 at 3:49 AM, Zoltan Varga var...@gmail.com wrote:
Also the marshalbool.cs test is still failing for both PPC32 and PPC64.
I assume that the required managed-to-native wrapper is not being
build/inserted into the call path for this case.
No idea why that would happen, on my
On Thu, Jun 4, 2009 at 10:48 AM, Seo Sanghyeon sanx...@gmail.com wrote:
I know sgen GC is work-in-progress, etc., but attached patch lets me
try it on x86. Or anyone else who haven't moved to 64-bit paradise
yet...
With r135405 SGen should work (i.e. at least bootstrap mono) out of
the box (on
Hi,
The first patch moves the NumberFormatter out of Thread. As it is now,
the NumberFormatter is shared between AppDomains.
The second patch makes sure that an array obtained in another AppDomain
is not retained in the calling domain but copied.
Mark
Index:
On Fri, Apr 10, 2009 at 6:14 PM, Eyal Alaluf ey...@mainsoft.com wrote:
Isn't the thread instance specific to the app-domain?
No.
Are there cases where one thread instance belongs to several different
app-domains?
A thread instance only belongs to one app-domain, but another
app-domain can
Hi Paul,
echo #define XSLT_PATTERN Mono.Xml.Xsl/PatternTokenizer.cs
cat System.Xml.XPath/Tokenizer.cs Mono.Xml.Xsl/PatternTokenizer.cs
MCS [basic] System.Xml.dll
Stack overflow in unmanaged: IP: 0xf860154, fault addr:
0xff51fed0
Stacktr
ace:
at
2009/3/27 Sebastien Pouliot sebastien.poul...@gmail.com:
The current check for the overrides is not correct. Here's a fix for it
(which also moves the coreclr checks code into security-core-clr.c*).
The patch includes additional tests for coreclr-security.cs
Looks good!
Mark
2009/3/25 Sebastien Pouliot sebastien.poul...@gmail.com:
and the last one...
Looks good!
Mark
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
On Tue, Mar 24, 2009 at 2:48 PM, Sebastien Pouliot
sebastien.poul...@gmail.com wrote:
Here's an updated patch. I fix another case (thanks to jb's test) where
results vary between platform and application code. It also has a bit
more comments/documentation.
Looks good!
Mark
Hey Sebastien,
Here's the patch to add the extra coreclr checks, which affect bindings
and accessibility, when a delegate is created (unit tests in [1]).
It also cover the case where delegate are internally used (optimization)
to replace some reflection calls (see unit tests for PropertyInfo
Hey Sebastien,
This patch adds the reflection checks for fields and also reworks (and
move*) how the checks are done on methods.
Looks good. One question, though: are you sure that in CoreCLR even
critical methods cannot via reflection access fields and methods that
they usually couldn't via
Hey Sebastien,
Here's another patch. This one adds some* checks for dynamic methods.
The checks are located in security-core-clr.c and the caller
(reflection.c) has been adjusted for the task.
I don't understand why these checks are necessary - they should be
performed when the method is
2009/3/19 Sebastien Pouliot sebastien.poul...@gmail.com:
A second mini-patch. This one contains the simplification of the code
inside security-core-clr.c.
Looks good, too.
Mark
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
Hey Rodrigo,
Thanks for the suggestions!
This change increases the JIT working set significantly. Have you thought
about doing something like
struct MonoCallInst?
Yes, I have, and I've started implementing it, but it requires quite a
bit of reworking of some of mini' passes, because we
Hey Sebastien,
This (small) patch is a similar simplification when checking overrides.
Looks good.
Mark
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Hey Sebastien,
Here's the first of the coreclr mini-patches. It work (commit-ready)
independently of the other changes.
Looks fine to me.
Mark
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
Hi Sebastien,
Apart from what Rodrigo said I only two tiny issues with the patch.
First it would be nice if you could split it up between the part that
handles field access, the part that handles wrappers and the part that
handles the image stuff. And then there's this:
+ for (i = 0; i
Hey Sebastien,
Now one thing remains unanswered, could you share your lights on:
static gboolean
method_is_safe (MonoMethod *method)
{
- /*
+ /* FIXME: looks somewhat incomplete
I think this is just dead code used during
On Thu, Feb 5, 2009 at 2:54 PM, Scott Peterson sc...@ssblack.co.nz wrote:
If other people are interested in geeking out over language features,
I suggest we get ourselves a little organized. We could hold forth
right here, on this list, or we could create our own Google Group.
Bugzilla is
something without a change in the JIT.
Mark
--
Mark Probst
http://www.complang.tuwien.ac.at/schani/
http://www.flickr.com/photos/schani/
http://schani.wordpress.com/
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http
of the assembly not to change in the future, but also on the
implementation, which is a very bad idea.
Mark
--
Mark Probst
http://www.complang.tuwien.ac.at/schani/
http://www.flickr.com/photos/schani/
http://schani.wordpress.com/
___
Mono-devel-list
On Thu, 2009-01-22 at 09:03 -0600, Steven Munroe wrote:
this patch completes the PPC64 port and enables Thread Local Storage
under Linux/NPTL. This patch also provides the infrastructure for
detecting PPC hardware attributes (via the SYSV Aux Vector) that we will
need to optimize JIT code. For
On Fri, Dec 19, 2008 at 3:27 AM, Steven Munroe munro...@us.ibm.com wrote:
found the bug. The update to mini-ppc.c (emit_memcpy) replaced ppc_lwzu
macro with ppc_load_reg_update, but the definition of
ppc_load_reg_update for PPC32 in ppc-codegen.h did not account for
reorders parms (ppc_lwz (c,
Hi Steven,
Hello, I have been asked to do a mono port for powerpc64. I am new to
mono and still learning my way around and so would appreciate any
pointers from experienced mono developers.
I would especially like to chat with the original and/or current
maintainer of the powerpc32 port.
I
Hi,
This patch lets the JIT optimize the GetTypeFromHandle in the
synchronized wrapper, which speeds up static synchronized methods a bit.
Paolo: Please review.
Mark
Index: metadata/marshal.c
===
--- metadata/marshal.c (revision
Probst [EMAIL PROTECTED]
+ * mini-x86.h, mini-x86.c, exceptions-x86.c: Align stack on all
+ platforms, with definable stack alignment value. Set to 16 now
+ for all platforms.
+
+2008-10-17 Mark Probst [EMAIL PROTECTED]
+
* method-to-ir.c (mono_method_to_ir2): refanytype produces
Hi Zoltan,
Looks good. Why is this part needed:
+ if (cfg-method-wrapper_type ==
MONO_WRAPPER_NATIVE_TO_MANAGED ||
+ cfg-method-wrapper_type ==
MONO_WRAPPER_RUNTIME_INVOKE) {
+ x86_pop_reg (code,
/ChangeLog (revision 116185)
+++ mini/ChangeLog (working copy)
@@ -1,5 +1,11 @@
2008-10-17 Mark Probst [EMAIL PROTECTED]
+ * mini-x86.h, mini-x86.c, exceptions-x86.c: Align stack on all
+ platforms, with definable stack alignment value. Set to 16 now
+ for all platforms.
+
+2008-10-17 Mark
Hi,
The attached patch fixes the Remoting regressions that were caused by
the fast generic virtual method invoking code. The problem is that
remoting methods need a remoting wrapper, but invoking a generic method
via the vtable cannot provide that wrapper, so I added a new trampoline
type which
Hi Rodrigo,
@@ -1991,7 +1990,7 @@
iter = NULL;
j = 0;
while ((cm = mono_class_get_methods (interf, iter)))
-pvt-vtable [slot + j++] = mono_method_signature
(cm)-generic_param_count ? cm : arch_create_remoting_trampoline (cm,
On Wed, Oct 1, 2008 at 8:12 PM, Paolo Molaro [EMAIL PROTECTED] wrote:
It would be nice to also see some speedup numbers from this change:)
Running the same benchmark (attached again) that I did on my first,
memory-eating implementation of fast virtual generic method calls I
get these numbers:
Hello again,
Here's the patch again, updated with code to keep track of how many
times a generic virtual method is invoked and to insert it in the thunk
only if a threshold (currently 100) is reached.
Mark
Index: metadata/domain.c
Hey,
Jonathan found a generic code sharing bug connected with the
constrained. prefix, which this patch fixes. I don't know what the
original reasoning behind the inflation with the class context was, but
it seems to be wrong, since the method is taken out of that class, so
it's already inflated
Hi Rodrigo,
Makes sense, the space is already these. Does it handle dispatching of
interface generic methods? The code in method-to-ir.c suggests not.
No, it doesn't. I don't think interfaces should be too hard, though.
All we need to do is to pass the fully instantiated MonoMethod* as the
Hey everybody,
This is my second attempt at implementing fast virtual generic method
calls. The implementation is very close to Paolo's proposal here:
https://bugzilla.novell.com/show_bug.cgi?id=324481
The main difference is that I don't hash the methods into slots but use
the (until now
Hi,
This patch enabled generic code sharing for value types. The important
difference to reference types is that value types don't have a vtable
pointer, which means that the RGCTX needs to be provided separately. We
do this in the same way we as with static methods, namely via an
implicit
Hey,
The attached program triggers the following bug when generic sharing is
enabled (MONO_GENERIC_SHARING=all):
The call to the delegate constructor in makeDel() needs to look up the
constructor in the RGCTX, because the delegate type is a generic for
which code cannot be shared in the general
Hey,
I can't spot any platform specific code in in
exceptions-ppc.c::arch_handle_exception
comparing to mini-exceptions.c::mono_handle_exception_internal.
Actually the later one have some userfull additions missing in the ppc code.
Do you mind taking a look if we can remove this big chunk
Hey,
This makes Linear IL work with PPC on darwin. A few runtime and corlib
tests fail, but they also failed before the merge. I'm working on them,
though.
Zoltan: Could you please take a look at the patch?
Mark
Index: mini/method-to-ir.c
On Tue, Jul 22, 2008 at 1:31 AM, Zoltan Varga [EMAIL PROTECTED] wrote:
Architectures which _should_ work: x86/amd64/arm/s390/sparc/itanium. I don't
know the status of ppc.
PPC will be ported by me.
Mark
___
Mono-devel-list mailing list
On Tue, Jul 22, 2008 at 2:06 PM, Andreas Färber [EMAIL PROTECTED] wrote:
Do you already know what parts of the files will need to be changed? Does
this affect, e.g., the whole opcode-to-machine-code translation and thus the
ppc64 port[1] in progress?
I haven't started looking into it, yet, so
On Fri, Jul 18, 2008 at 5:27 PM, Miguel de Icaza [EMAIL PROTECTED] wrote:
Is attaching to a non --debug Mono process a widely used feature?
A better question to ask is whether developers routinely attach to
running processes to debug with other debuggers, and I think the answer
to that is
Hi everybody,
I've improved the implementation of virtual generic method calls, at
least in terms of speed. Now I'd like to ask if anybody knows of
reasonably easy to install applications which use virtual generic
methods extensively, so that I can test and improve the code with
real-world
Hey everybody,
As I already mentioned on #monodev, my preferred solution for 2.0
would be to disable generic sharing if Mono runs with --debug. In
that case the debugger would work fine without any further changes,
and the users would still benefit from generic sharing when they run
without
On Tue, Jul 15, 2008 at 6:57 PM, Rodrigo Kumpera [EMAIL PROTECTED] wrote:
How about disabling generic sharing for the 2.0 release and have a better
debugger experience for our users?
For me if gsharing breaks the debugger we can't say it's done. Enabling by
default something that breaks a
On Tue, Jul 15, 2008 at 7:23 PM, Martin Baulig [EMAIL PROTECTED] wrote:
But keep in mind that we still need to write that check.
That check would be needed in any case, right? Otherwise the debugger
would crash when generic code sharing is turned on, regardless of
whether it's turned on by
2008/6/21 Debacker [EMAIL PROTECTED]:
Mono 1.9.1 does no seem to optimize tail virtcall's. As a consequence, I
get a stackoverflow.
Using Microsoft .NET 2.0 is works as expected.
I have attached the IL source code (no C# since C# does not support tail
optimization AFAIK).
Is it a known
information in a RGCTX, so they could share the RGCTXs of their
generic superclasses.
Does this sound like a sensible plan? Am I missing something crucial?
Does anybody have any suggestions or better ideas?
Mark
--
Mark Probst
http://www.complang.tuwien.ac.at/schani/
http://www.flickr.com/photos
Hey Rodrigo!
Thanks for the feedback!
Isn't possible or better to do RGCTX free'ing at GC time? It would be
simpler, the hardest
part would be guarding against parking threads inside RGCTX related code,
which can be done with
some link time trickery and a lit of changes on stack scanning
Hey Rodrigo,
Anyway, this would only make sense if freeing is something that happens
enough to
justify the extra work.
I don't think freeing would happen often enough. I'm actually more
concerned about the impact of the write barrier I'd need for the
hazard pointer, which would be used
On Mon, Apr 14, 2008 at 6:04 PM, Rodrigo Kumpera [EMAIL PROTECTED] wrote:
Other thing, how does sharing and inlining play together? I guess inlined
generic code
uses rgctx a bit less as it has precise type information at hand. If so,
wouldn't
more aggressively inlining generic code reduce
Hey Kornél!
r91443 broke Windows build:
/mono/mono/mono/metadata/threads.c:2526: undefined reference to
`__wapi_thread_signal_self'
/mono/mono/mono/metadata/threads.c:2543: undefined reference to
`__wapi_thread_signal_self'
Hi Paolo, Dick, and everybody else!
Here's the new shutdown code which should fix bugs #337383 and #347676.
We have two shutdown paths in Mono:
* Implicit exit: All threads shut down normally
* Explicit exit: Some thread calls System.Environment.Exit()
In implicit exit the main thread shuts
Hey!
@@ -762,7 +774,8 @@
THREAD_DEBUG (g_message (%s: Attached thread ID %G_GSIZE_FORMAT
(handle %p), __func__, tid, thread_handle));
-handle_store(thread);
+may_start = handle_store(thread);
+g_assert (may_start);
Why are you asserting here? Shouldn't the thread just
1 - 100 of 107 matches
Mail list logo
