On 01/30/13 Nikolay Igotti wrote:
1. all code/data access has to be in lower 1G range of address space
2. all branch targets have to be 16 bytes (bundle) aligned, unless
it's direct branch to the instruction which need no masking (see 3.)
3. code with register arguments (loads,
--
-
lu...@debian.org debian/rules
lu...@ximian.com Monkeys do it better
---BeginMessage---
On 12/10/10 Duane Wandless wrote:
I'm trying out the profiler on OSX
On 12/10/10 Duane Wandless wrote:
That has the same result as before.
Could you post the output of the following commands in mono/profiler?
make clean
make V=1
make install
mono-sgen --version
mono-sgen --profile=log:heapshot,report app.exe
Thanks
lupus
--
On 11/30/10 KISHIMOTO, Makoto wrote:
I saw
https://github.com/mono/mono/commit/30cba27527d5076896bf6bead5b9aa9c44d32d6f ,
IMHO, use of symbol ELF_CLASS is better than SIZEOF_VOID_P .
I'm not sure that there is a standard for the ELF_CLASS definition, so I
did the safe thing for now. If and
On 11/30/10 KISHIMOTO, Makoto wrote:
In my FreeBSD Box, proflog.c compile failed.
Could you try current trunk?
I committed a change that should fix the issue.
lupus
--
-
lu...@debian.org
On 11/11/10 J.P. wrote:
I try to build the source from git. but I have a problem below this. This
problem is on x64 and x86 CentOS. I think it maybe caused by recently fix
about decode and log profiler. Isn't it?
Please fix the problem. I wanna use fixed mono version that solved thread
On 11/03/10 J.P. wrote:
I have a error while compile the mono of git source. I think it caused by
mono_gc_base_init function.
Please correct this problem. I have configured normally on my x64 linux
machine.
You likely need to run autogen.sh in the top dir again.
Using autogen is required
On 09/14/10 Sergei Dyshel wrote:
So I have too stay with 'mini' :-). I've made some tweaks to it but still
its division of vregs to local and global sometimes drastically decreases
code performance by making a lot of redundant moves.
So I started to think that may be global allocator is the
On 07/13/10 Miguel de Icaza wrote:
typedef void* (*MonoDlFallbackLoad) (const char *name, int flags, char
**err, void *user_data);
typedef void* (*MonoDlFallbackSymbol) (void *handle, const char *name, char
**err, void *user_data);
typedef void* (*MonoDlFallbackClose) (void *handle,
On 07/02/10 Michael Hutchinson wrote:
This interface is not suitable as a fallback mechanism, it would be too
cumbersome to use and it's probably not ideal even for its intended
purpose. What about a callback registration system instead?
The intended purpose, AFAIK, is to expose
On 07/01/10 Michael Hutchinson wrote:
The mono_dl_register_library function can currently be used to
register P/Invoke mappings for platforms that do not have a dynamic
linker. The attached patch makes it also function as a fallback when
the system's dynamic linker cannot resolve the library,
On 07/01/10 Michael Hutchinson wrote:
The attached patch adds a new mono_exception_get_message_string
function to the Mono public API, extracted from mono_print_exception.
This makes it possible for embedders easily to convert exceptions to
strings without printing them and without using
On 06/23/10 Geoff Norton wrote:
Attached is a patch which enables sigaltstack for OSX (x86 and amd64).
The configure.in check passes on amd64 and fails on x86 for some reason (the
signal isn't delivered to the child ?)
but the support appears to work correctly on both.
---
On 05/04/10 Rodrigo Kumpera wrote:
Once this patch is accepted I'll move into finishing the managed side of it.
Right now CWT is implemented doing linear search, but the idea is to switch
to
open addressing. To do that, the only change required to sgen is to store a
tombstone instead of NULL
On 04/19/10 Jonathan Pryor wrote:
Index: mono/io-layer/collection.c
===
--- mono/io-layer/collection.c(revision 155735)
+++ mono/io-layer/collection.c(working copy)
@@ -58,7 +58,10 @@
ret =
On 04/07/10 Phil Garcia wrote:
Since we are implementing everything in .NET/C# we don?t need InternalCalls
to call external API bindings. In fact, the external declarations in the
source code get into the way. So we have moved the InternalCalls method
declarations into separate partial class
On 03/30/10 Andreas Färber wrote:
--- a/mono/metadata/mono-config.c
+++ b/mono/metadata/mono-config.c
@@ -39,6 +39,8 @@
#define CONFIG_OS aix
#elif defined(__hpux)
#define CONFIG_OS hpux
+#elif defined(__HAIKU__)
+#define CONFIG_OS haiku
#else
This is ok to commit.
lupus
--
On 03/30/10 Andreas Färber wrote:
--- a/mono/metadata/console-unix.c
+++ b/mono/metadata/console-unix.c
@@ -43,7 +43,8 @@
#ifdef HAVE_SYS_FILIO_H
#include sys/filio.h
#endif
-#ifndef TIOCGWINSZ
+/* Haiku has FIONREAD in sys/ioctl.h */
+#if !defined(TIOCGWINSZ) || !defined(FIONREAD)
On 03/24/10 Rodrigo Kumpera wrote:
--- a/mono/mini/mini-exceptions.c
+++ b/mono/mini/mini-exceptions.c
[...]
+static gboolean
+find_last_handler_block (MonoDomain *domain, MonoContext *ctx, MonoJitInfo
*ji, gpointer data)
+{
+ int i;
+ gpointer ip;
+ FindHandlerBlockData
On 03/24/10 Mark Probst wrote:
Here's an updated patch that fixes this problem, both for mono-ehash
as well as for mono-hash.
--- a/mono/metadata/boehm-gc.c
+++ b/mono/metadata/boehm-gc.c
@@ -932,5 +932,11 @@ mono_gc_get_write_barrier (void)
#endif
+void
On 03/24/10 Mark Probst wrote:
The first patch make mono-ehash SGen-aware, the second implements
CEE_MONO_TLS on Darwin/x86.
--- a/mono/utils/mono-ehash.c
+++ b/mono/utils/mono-ehash.c
[...]
+#ifdef HAVE_SGEN_GC
+ if (type 0 || type MONO_HASH_KEY_VALUE_GC)
+ g_error
On 03/22/10 Andreas Färber wrote:
SA_SIGINFO and sigaction are part of the optional POSIX XSI feature.
In mini, there's MONO_ARCH_USE_SIGACTION but it doesn't cover everything
[...]
+#ifdef SA_SIGINFO
+ if (save_sigcont.sa_flags SA_SIGINFO) {
if (save_sigcont.sa_sigaction != NULL
On 03/09/10 Rodrigo Kumpera wrote:
One is to patch the return address of a finally clause to jump into runtime
code that will handle raising the ThreadAbortException.
This is very tricky because we need to store precise unwind information to
be able to figure out where that value is. The
On 03/04/10 cpMon wrote:
I never get a signal when System.Threading.Monitor::Exit gets called too many
times.
We used to raise an exception, but IIRC, the MS runtime doesn't throw it
either, so we don't anymore.
Further, I traced it down into the mono 2.6.1 code tree, and
mono_monitor_exit
On 02/22/10 Rodrigo Kumpera wrote:
On Sat, Feb 20, 2010 at 2:07 AM, Jerry Maine - KF5ADY crashfou...@gmail.com
I remember you talking about instead of having marcos and defines
describe certain attributes of IR instructions, having them be defined
in a single data structure like what is
On 12/03/09 Mark Probst wrote:
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
On 08/20/09 Rodrigo Kumpera wrote:
I don't like MONO_ERROR_ON_SIGNAL_CONTEXT: most code is not going to
know in what mode it was called in. Simply always use the message
buffer.
I changed this to have a MONO_ERROR_STORE_FULL_MESSAGE flag. My reasoning
behind this is
that some messages
On 08/18/09 Rodrigo Kumpera wrote:
Still open is how this would be integrated on 2.6
I think we should keep this internal for 2.6 and expose it in 2.8 wth
the other API changes, once we have gained experience with the new API.
and if functions should
error out if passed an already set error
On 06/26/09 Rodrigo Kumpera wrote:
The attached patch changes class.c/inflate_generic_type to not abort the
runtime when facing a bad instantiation.
My only issue is that I'm not sure if mono_class_inflate_generic_type* and
mono_class_inflate_generic_class should
set a loader error when
On 04/23/09 Mark Mason wrote:
As for splitting MIPS/MIPS64 - I think keeping them together may be
more appropriate. The MIPS64 code generator is less of a divergence
from MIPS32 than PPC64 is from PPC --- there's a lot of potential code
reuse to be had by keeping them together. That's
On 04/24/09 Ian Dichkovsky wrote:
And we have prepared ChangeLogs and added them to
https://bugzilla.novell.com/show_bug.cgi?id=497320
ChangeLog.diff
ChangeLog_libgc.diff
ChangeLog_mono_arch.diff
ChangeLog_mono_io-layer.diff
ChangeLog_mono_mini.diff
Thanks for the port!
A few general
On 04/23/09 Miguel de Icaza wrote:
The cons are:
* We still need to deprecate/break the API for the functions
listed in [1]
At some point we need to break API/ABI anyway, since it's required for
the new GC, we need to hide some implementation details that are
currently
On 04/10/09 Mark Probst wrote:
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.
This looks fine
On 02/09/09 Rodrigo Kumpera wrote:
The attached patch adds a new hook to allow threads to shutdown after the
GC finalizer has finished.
The motivation for it is to improve profiler's reliability at shutdown
time.
The new callback notifies the thread when regular shutdown starts and
On 01/31/09 Basile Starynkevitch wrote:
Apparently mono has some way to get it, since mono-2.2 contains the file
mono/utils/mono-time.[ch] with functions
gint64 mono_100ns_ticks(void) MONO_INTERNAL;
gint64 mono_100ns_datetime (void) MONO_INTERNAL;
I blindly guess that MONO_INTERNAL
On 02/01/09 Andreas Färber wrote:
There might be a mono port for AIX, which might run in the PASE
environment, but i don't know the status of that.
Some folks recently tried a new port to AIX/ppc64. They gave up last
week because, supposedly, Mono relies on an undefined behaviour of
On 01/28/09 Steven Munroe wrote:
if there WAS a problem will some chip in the past we address that
separately. But this changes are important to the server class machines
and I have carefully crafted this patch to only optimize for the case
where we know (from the auxv) what the hardware
On 01/28/09 Miguel de Icaza wrote:
The current patch splits out the OS-specific functionality into
three files mini-darwin.c, mini-posix.c and mini-windows.c, these mostly
deal with setting up exceptions today.
This looks fine to me. I wouldn't bother with the configure changes,
though and
On 01/25/09 Steven Munroe wrote:
What you consider superfluous addresses an annoying bug where the
mkbundle generates code that can never be assembled and results in a 2GB
a.out file. This is a result of brain-dead code the than can't handle
biarch builds (where the build is for the
On 11/17/08 Phillip N. wrote:
Failed tests:
exception.exe
remoting2.exe
remoting3.exe
generics-sharing.2.exe
generic-null-call.2.exe
thunks.exe
bug-78549.exe
gmake: *** [testjit] Error 1
*** Error code 2
I was building a LiveCD for taking the problem closer to any of you, but
On 11/11/08 Jonathan Chambers wrote:
1) We should consider using MSVC as the default compiler for C code on
Windows. I can compile the entire Visual Studio solution for the runtime in
minutes. It takes 20-30 seconds if I do a parallel build. We can also use
the Visual Studio debugger on
On 11/13/08 Jonathan Chambers wrote:
I have started writing this tool in C#. It correctly generates a csproj file
from the Makefile and the library.dll.sources files. It already works on
most assemblies in mcs/class. I'm working on generating the corresponding
NUnit projects as well.I'll
On 11/10/08 Cedric Vivier wrote:
This patch implements these ops as two 64-bit bitwise ops [2] instead
of processing
Sadly this is not safe as the alignment we currently can guarantee is
only to 4 bytes and a few architectures don't support loading
a 64 bit value unless it's 8-byte aligned.
On 11/10/08 Alan McGovern wrote:
The only other option is for there to be a place on disk which is:
A) Guaranteed to be writable
B) Guaranteed to have enough space to create the package.
If those guarantees can be given, I'll gladly make the change. If they
can't, then I don't want to
On 11/06/08 Alan McGovern wrote:
However this use case is likely to never be hit in System.IO.Packaging. The
API requires that when you 'write' data to a zip archive, the data is also
kept in memory. If you did try to use a 2gb file with this API, you'd end up
trying to allocate a 2gb block of
On 11/07/08 Christophe Guillon wrote:
It seems that as soon as the Mono.Simd primitives have a well defined
semantic it is not useful to specify which architecture feature is able to
emulate each of these primitives. I would have expected this to be the
choice of the virtual execution
On 11/06/08 Nicolò Chieffo wrote:
Hello, I would like to run mono in a low resources machine (ARM cpu,
low ram) which is the minimum resource requirement to run mono?
(I need system.timers, system.runtime.remoting, events and delegates
with BeginInvoke)
See
On 11/05/08 Alan McGovern wrote:
2) minizip exposes 'long' types in it's public API. At the moment I've
wrapped these as IntPtr types. This will run on all platforms except
Win64. To resolve this, we'd need to create a wrapper API which exposes
the 'long' types as int64_t.
When dealing with
On 10/18/08 Cedric Vivier wrote:
Please review attached patch implementing Diagnostics.Debugger.IsAttached.
Please be careful with your patches and don't include whitespace changes
mixed with functionality changes.
Thanks.
lupus
--
On 10/13/08 Andoni Morales wrote:
I'm having a very strange problem on Windows
I've created a multimedia player based on GStreamer an Gtk that runs both on
Windows and Linux. The GStreamer backend is written in C and wrapped to C#
using the GAPI tools, importing my own dll called
On 10/09/08 Mark Probst wrote:
Anyway, updated patch attached.
The changes look fine to me.
Maybe it's a good idea to have a remoting test that triggers this also
in the runtime tests.
lupus
--
-
[EMAIL PROTECTED]
On 10/10/08 FirstName LastName wrote:
I have a general question regarding GC. When the GC runs, does it
stop all threads in the process, even those created in unmanaged.
Only the ones it knows about, but see below.
I asking the following because I'm wondering what would happen if the
GC
On 10/10/08 Carsten Harnisch wrote:
As I understood mono is using phreads and epoll, so having created a
mono-thread and using this thread to call an unmanged piece of code, will
this unmanaged code be run in the context of the underlaying pthread? Or
does the mono i/o layer call the unmanaged
On 10/10/08 Kornél Pál wrote:
Currently mono_image_fixup_vtable actually compiles methods that causes
type loads as well and requires the assembly to be loaded.
Please help with letting me know how could I avoiding this by using JIT
trampolines. I have no idea how to create them and late
On 10/10/08 Bojan Rajkovic wrote:
How does Mono deal with SSE-capable processors (or Altivec capable
processors)? That is, does the JIT emit any SSE calls when there's a
chance to use them, or are they totally unused in Mono?
We use some of the SSE instructios if available on x86.
On amd64
On 10/11/08 Dax wrote:
Paolo Molaro wrote:
We don't auto vectorize from IL code, but we're developing an extension
that allows people to take advantage of sse instructions with
intrinsics (people watching the changes list can see it already).
That said, what versions of SSE
On 10/06/08 [EMAIL PROTECTED] wrote:
I'd like to try System.Threading and System.Threading.Collections on
Linux to work a little bit with ParallelFX.
Is it going to be included together with the mono sources or should I
just go to the Mono GSoc repository?
We'll include them in mono when
On 10/07/08 FirstName LastName wrote:
I have been doing some tests with Mono quite a while. I'm working with Mono
on a ARM.
When I try to call a managed callback from the unmanaged world in a unmanaged
thread, I get the following:
** ERROR **: file mini.c: line 10315
On 10/03/08 [EMAIL PROTECTED] wrote:
Ok, I'm using the included one but, any clue why I can't get the
monolite to work?
monolite should simply not be used, it's an expert option
that is not fool proof and is not guaranteed to work,
there are too many issues with it that are not even worth
On 09/29/08 James Mansion wrote:
Rodrigo Kumpera wrote:
These are shortcomings of the current AOT implementation of mono
that are easier to fix than implement a fast interpreter.
Who said anything about fast?
The mono interpreter already operated on a different internal
representation, not
On 10/01/08 Mark Probst wrote:
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.
100 seems high, especially since the lookup can be a O(n) list walk.
Maybe
On 07/30/08 Kornél Pál wrote:
Zoltan Varga wrote:
This patch replaces a small, fast, simple piece of code
in mono_emit_inst_for_method () with something far more complex. Also,
The three icall builders are reference implementations for demonstrating
what icall builders can do. I don't
On 03/21/08 Kornél Pál wrote:
From: Paolo Molaro [EMAIL PROTECTED]
Sure, the existing unsafe methods are perfectly fine, there is no need
to add more virtual unsafe methods (this is about 2.0). In 1.1 the
unsafe methods would simply become internal.
This is unfortunately unture because we
On 03/20/08 Kornél Pál wrote:
cases). So you'd need at least another icall that says if the Copy
operations are allowed on the array. It's better to have a single icall
that does it all, returning 0 for the cases where the copy is not
allowed. In that case the name GetElementSize would be
On 03/20/08 Kornél Pál wrote:
- Unsafe code is required anyway because Encoding has public unsafe methods.
Handling strings and character arrays in a single function requires unsafe
code as well. Using a single implementation avoids accidental differences
between string, array and pointer
On 02/22/08 Kornél Pál wrote:
If there were something like a fast Array.GetElementSize() that could be
used in Marshal.UnsafeAddrOfPinnedArrayElement as well as in System.Buffer
methods. System.Buffer is supposed to be used over Array.Copy for better
performance so I believe that having a
On 03/14/08 Kornél Pál wrote:
I didn't receive any comments or approval on the following patches:
Sorry for the delay, here are a few quick comments:
http://lists.ximian.com/pipermail/mono-devel-list/2008-March/027166.html
The changes look fine to me, but someone using windows will have to
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
On 03/10/08 Bill Holmes wrote:
On Mon, Mar 10, 2008 at 6:52 PM, Bill Holmes [EMAIL PROTECTED] wrote:
Please review the attached diff file and let me know if it is OK to
commit. It is fixes for a couple of build errors, and bugs with eglib
on Windows.
Looks fine to me, Please commit.
On 03/07/08 Casey Marshall wrote:
The attached patches add a partial implementation of DynamicILInfo --
basically enough that you can specify the IL code and locals for a
method, and have that method runnable.
I might work on this more if I have time, *plus* I'm not sure if this
here is too
On 01/29/08 Massimiliano Mantione wrote:
Anyway, the patch passes everything here.
Did you run the corlib tests, too?
--- mono/metadata/class.c (revision 94247)
+++ mono/metadata/class.c (working copy)
+#if USE_NEW_INTERFACE_VTABLE_CODE
+ // Loop on all implemented interfaces...
On 01/28/08 Jonathan Pryor wrote:
On Mon, 2008-01-28 at 17:13 -0500, Jonathan Pryor wrote:
On Mon, 2008-01-28 at 21:10 +0100, Paolo Molaro wrote:
Deregistration is handled incorrectly: if there are two handlers for the
same signal it gets disabled at the first uninstall.
This has been
On 01/24/08 Jonathan Pryor wrote:
After talking on IRC, the sane interface is to provide
Stdlib.signal_default(), Stdlib.signal_error(), and
Stdlib.signal_ignore() methods instead of using Stdlib.signal() with
Well, those methods shouldn't be in that namespace and the names
are not really
On 01/28/08 Jonathan Pryor wrote:
It is important (as in my initialy API sketch) that this function take
the signal_info and not the dignal number, as this implementation allows
only just an handler per signal in the API.
This has been corrected. We now support up to 64 signal handlers
On 01/08/08 Jonathan Chambers wrote:
Here is the first attempt at a patch. Nothing is changed with the
default configuration. Things are controlled via an environment variable
(MONO_COM), and extensible using the dllmap in the config file. The only
other current configuration is MONO_MS,
On 01/02/08 Jonathan Pryor wrote:
That said, I think that there should be a way to use signals from C#.
Even if such use is severely limited -- e.g. only setting a volatile
variable within the signal handler -- signals are required for decent
integration with Unix platforms, so saying don't
On 01/06/08 Robert Jordan wrote:
Robert Jordan wrote:
Since the current handling of CurrentThread.CultureInfo
isn't quite perfect (changes of CurrentThread.CultureInfo's
object state isn't reflected back into another app domains,
like on MS.NET), I wonder why we don't use a more efficient
On 12/21/07 pablosantosluac wrote:
Ok, I think I got a bit lost here... how should I proceed then?
There is no guarantee that you can hook to signal handlers
from C#, we don't support that usage and its inclusion in Mono.Posix is
a mistake.
I'm actually going to add code to mono to detect such
On 12/19/07 C.J. Adams-Collier wrote:
Zoltan asked that I make a change to configure.in as well, but I wanted
to send this before I forgot about it.
The configure.in change is what is more important as you need to make
sure you won't break the correct systems in your quest for supporting
an old
On 12/14/07 Sebastian Good wrote:
I am compiling an embedding library which #includes
mono/metadata/threads.h, however in 1.2.6 this file does not compile
cleanly. threads.h apparently further includes
mono/metadata/threads-types.h, which is no longer shipped with mono.
Commenting out
On 12/17/07 Kornél Pál wrote:
(for example the original C implementation has a bug and
in your code it's duplicated several times)
What is that bug?
Integer overflow when doing the array range check.
and you also managed to hide
the assignment of a local var inside of a conditional
On 12/20/07 C S Vadiraj wrote:
--- mono/mini/driver.c 2007-12-19 15:04:53.0 -0800
+++ mono/mini/patched-driver.c 2007-12-19 15:05:20.0 -0800
@@ -706,8 +706,16 @@
#if HAVE_SCHED_SETAFFINITY
if (getenv (MONO_NO_SMP)) {
+# ifdef
On 12/18/07 Avery Pennarun wrote:
I've been looking at using mkbundle myself for my own work. It's
network stuff, not graphical, so I wouldn't expect gdiplus to be a
problem for me.
But what exactly is that case that it can't cope with?
Dynamically-linked elf libraries? Could I just
On 12/19/07 Joe Audette wrote:
Was wondering if its theoretically possible to run xsp2 directly from
a cd. I've seen some posts about embedding mono but don't really know
what is involved. If anyone can confirm whether its possible or point
me to any information that might help I'd appreciate
On 12/19/07 Jonathan Chambers wrote:
COM Interop support in mono works pretty well for most basic uses, but
has some limitations when it comes to strings. Mainly, BSTR marshalling on
non-Windows platforms is just a default implementation. The problem is that
most COM systems (both
On 12/17/07 Kornél Pál wrote:
Can I commit this patch or should Marshal.Copy remain unmanaged or do you
have any other objections?
I'm not opposed to have this stuff implemented in managed code, but I
don't like the specific way it has been done as it involves lots of
duplicate code (for
On 12/05/07 Rodrigo Kumpera wrote:
One thing missing are functions to probe the version/capabilities of the
library. Since the idea is to have the debugger use as much of the dbg api
as possible but falling back to the current code in case the lib doesn't
support specific stuff.
This is
On 12/05/07 Martin Baulig wrote:
Maybe it would also be a good idea to use the existing debugger to test
this rather than having just for debugging purposed something which is
100% broken and has to be removed later anyways.
Many of the functions are there exatly because this way we can test
On 12/05/07 Martin Baulig wrote:
There is just one important thing to keep in mind:
public TargetAddress MonoClassGetMonoImage (ITargetMemoryAccess memory,
TargetAddress klass)
{
IntPtr image =
Hi.
The attached patch implements part of the debugging library
the runtime will provide for use in the debugger, to reduce
the dependencies the debugger has on the runtime internals.
Note this is very basic for now and also includes stuff the debugger
won't use, but that will be essential to
On 12/01/07 Robert Jordan wrote:
Since strings are immutable, shouldn't it be possible to compute the
hashcode once and store it rather than recomputing it over and over again?
Is there some really obvious reason that i can't think of that would make
this a bad idea?
This idea already
On 11/30/07 Csaba Balazs wrote:
class ParentClass {
private int tval = 1;
public int PValue {
get {
return 2*tval;
}
}
}
[...]
It says, the ParentClass.PValue (get_PValue) is not used, but we can see its
value on the
On 11/22/07 pablosantosluac wrote:
And the following results:
compareCompare.exe
val is 599 and time 3525
c:\Archivos de programa\Mono-1.2.5.2\bin\mono.exe compareCompare.exe
val is 599 and time 11577
Please provide also info on the cpu specs (which cpu and frequency).
On a 2.4
On 11/19/07 Zoltan Varga wrote:
The problem with the trampoline is that since the class to init is
dynamically
decided, there is nothing to patch, so all calls will go through the
generic trampoline
code, which is much slower than a simple managed-to-native transition.
No, here is again
On 11/19/07 Mark Probst wrote:
I don't really understand why a new trampoline is needed here. Since
the argument
to the trampoline is dynamic, it is not possible to patch the caller code,
so a
normal call to mono_runtime_class_init () would be sufficient.
To be honest, I don't see
On 11/19/07 Zoltan Varga wrote:
A simpler solution would be to emit the code below inline instead of
making a call
to a trampoline at all.
This moves the memory overhead at the callsite, increasing icache
footprint (we're talking about 10 bytes for x86 and 16+ bytes
for other architectures).
On 11/14/07 David Wolinsky wrote:
In mono version r88278 ... this code crashes really bad (see
below). I just wanted to know if anyone was actively working on this?
Also is anyone working on the FileIOPermission?
Please file a bug report, though implementing CAS is not a priority for
On 11/13/07 David Miller wrote:
https://bugzilla.novell.com/tr_list_runs.cgi?plan_id=702
Do I really have to create a novell login just to
look at the test runs?
I've been trying to avoid having to create an account,
and I can understand requiring it for submitting new
bugs, but for
On 11/12/07 David Miller wrote:
In fact, significant chunks special list handling code got removed.
And I am certain many other significant cleanups and simplifications
become possible after this patch goes in.
I agree with the general change, but it's better to just add
a prev field in
On 11/08/07 Sanghyeon Seo wrote:
mono(1) lists type as a possible value for MONO_LOG_MASK, but it
doesn't seem to do anything. I thought it would log when types are
loaded (is that the intended purpose?).
Is there other way to see what types are loaded?
There is curently no trace event
1 - 100 of 408 matches
Mail list logo
