From kfogel at dawsoncollege.qc.ca Fri Aug 8 16:10:32 2025 From: kfogel at dawsoncollege.qc.ca (Kenneth Fogel) Date: Fri, 8 Aug 2025 16:10:32 +0000 Subject: Memory Usage in Java Message-ID: Please let me know where I might ask this question or find the answer if this is not the right place. In a book I am working on I am writing about how Java deals with memory allocation for the primitive types on a 64 bit CPU. I know the size of primitive variable types such as byte is 1, int is 4, etc. and that the size is related to the range of allowable values. From my C/C++ days I learned that the actual amount of RAM used was related to the word size of a CPU so that when a byte is read you are really reading a word. This meant to me that if I had 10 variables of type byte, not in an array, it would consume 80 bytes of RAM. From my reading it appears to be the same in Java except for arrays. Is this accurate? For example, an int is 4 bytes but when Java runs on a 64 bit CPU is it really reading and writing 8 bytes? If it is, can we say that the 4 bytes of padding is RAM dead space that cannot be used for anything else? Thank you for your time, Ken Fogel -------------- next part -------------- An HTML attachment was scrubbed... URL: From shipilev at amazon.de Fri Aug 8 16:35:14 2025 From: shipilev at amazon.de (Shipilev, Aleksey) Date: Fri, 8 Aug 2025 16:35:14 +0000 Subject: Memory Usage in Java In-Reply-To: References: Message-ID: Hi Kenneth, The answers to most of these questions are, ?No, this is not how it works in any modern JVM?. I would really recommend playing with JOL, especially look through its Samples: https://github.com/openjdk/jol https://github.com/openjdk/jol/tree/master/jol-samples/src/main/java/org/openjdk/jol/samples And maybe read this for even more discussion: https://shipilev.net/jvm/objects-inside-out/ Thanks, -Aleksey From: discuss on behalf of Kenneth Fogel Date: Friday, 8. August 2025 at 18:11 To: "discuss at openjdk.org" Subject: [EXTERNAL] Memory Usage in Java CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Please let me know where I might ask this question or find the answer if this is not the right place. In a book I am working on I am writing about how Java deals with memory allocation for the primitive types on a 64 bit CPU. I know the size of primitive variable types such as byte is 1, int is 4, etc. and that the size is related to the range of allowable values. From my C/C++ days I learned that the actual amount of RAM used was related to the word size of a CPU so that when a byte is read you are really reading a word. This meant to me that if I had 10 variables of type byte, not in an array, it would consume 80 bytes of RAM. From my reading it appears to be the same in Java except for arrays. Is this accurate? For example, an int is 4 bytes but when Java runs on a 64 bit CPU is it really reading and writing 8 bytes? If it is, can we say that the 4 bytes of padding is RAM dead space that cannot be used for anything else? Thank you for your time, Ken Fogel Amazon Web Services Development Center Germany GmbH Tamara-Danz-Str. 13 10243 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597 -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Fri Aug 8 16:47:00 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 8 Aug 2025 18:47:00 +0200 (CEST) Subject: Memory Usage in Java In-Reply-To: References: Message-ID: <1705738028.9479753.1754671620447.JavaMail.zimbra@univ-eiffel.fr> C (and Java) tricks you to think that a "short" has a single representation but this is not true, it has two representations, one on stack (local variables) and one on heap (fields and array elements). On stack (or on registers because you do not control exactly where a local variable is stored), values are either 32 or 64 bits This is dues to the fact that 64 bits CPUs only have 32bits / 64 bits registers. On heap, everything is a multiple of 8 bits (Different CPUs may have different alignment constraints depending how you access the memory (plain, volatile, etc) but that's another story). So on stack a char is 32 bits and on heap, a char is 16 bits. Because of that, when you want to compute something using a char, the compiler will have to convert it from char to a 32 bits integer (the conversion has to propagate the sign bit so the 32 bits value is the same as the 16 bits value). That's why in Java, the result of the addition of two shorts is an int, short s = ... short s2 = ... s + s2. // this is an int I hope it helps. regards, R?mi > From: "Kenneth Fogel" > To: "discuss" > Sent: Friday, August 8, 2025 6:10:32 PM > Subject: Memory Usage in Java > Please let me know where I might ask this question or find the answer if this is > not the right place. > In a book I am working on I am writing about how Java deals with memory > allocation for the primitive types on a 64 bit CPU. I know the size of > primitive variable types such as byte is 1, int is 4, etc. and that the size is > related to the range of allowable values. From my C/C++ days I learned that the > actual amount of RAM used was related to the word size of a CPU so that when a > byte is read you are really reading a word. This meant to me that if I had 10 > variables of type byte, not in an array, it would consume 80 bytes of RAM. From > my reading it appears to be the same in Java except for arrays. Is this > accurate? For example, an int is 4 bytes but when Java runs on a 64 bit CPU is > it really reading and writing 8 bytes? If it is, can we say that the 4 bytes of > padding is RAM dead space that cannot be used for anything else? > Thank you for your time, > Ken Fogel -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.dallman at siemens.com Fri Aug 8 16:48:44 2025 From: john.dallman at siemens.com (Dallman, John) Date: Fri, 8 Aug 2025 16:48:44 +0000 Subject: Memory Usage in Java In-Reply-To: References:

Message-ID: Hi, Kenneth, > From my C/C++ days I learned that the actual amount of RAM used was related to the word size of a CPU > so that when a byte is read you are really reading a word. This meant to me that if I had 10 variables of > type byte, not in an array, it would consume 80 bytes of RAM. I'm afraid you are confused about that, too. There have been computers that would do that, but they have been obsolete for decades. I'm pretty sure Java has never run on a "word addressed" machine. On any remotely modern processor architecture, ten byte-sized variables will only occupy ten bytes of space. The way they get fetched into the processor is somewhat complicated but ensures that several of them will normally be fetched in one read. With best regards, -- John Dallman (he/him) Siemens Industry Software Limited DI SW PLM PE OT PC PDE Kett House, Station Road, Cambridge CB1 2JH, United Kingdom mailto:john.dallman at siemens.com www.sw.siemens.com [Logo] Siemens Industry Software Limited registered office: Pinehurst 2, Pinehurst Road, Farnborough, Hampshire, GU14 7BF, United Kingdom. Registered in England and Wales No. 03476850. This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the addressee. If you are not the addressee please note that any distribution, reproduction, copying, publication or use of this communication or the information is prohibited. If you have received this communication in error, please contact us immediately and also delete the communication from your computer. From: discuss On Behalf Of Shipilev, Aleksey Sent: 08 August 2025 17:35 To: Kenneth Fogel ; discuss at openjdk.org Subject: Re: Memory Usage in Java Hi Kenneth, The answers to most of these questions are, "No, this is not how it works in any modern JVM". I would really recommend playing with JOL, especially look through its Samples: https://github.com/openjdk/jol https://github.com/openjdk/jol/tree/master/jol-samples/src/main/java/org/openjdk/jol/samples And maybe read this for even more discussion: https://shipilev.net/jvm/objects-inside-out/ Thanks, -Aleksey From: discuss > on behalf of Kenneth Fogel > Date: Friday, 8. August 2025 at 18:11 To: "discuss at openjdk.org" > Subject: [EXTERNAL] Memory Usage in Java CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Please let me know where I might ask this question or find the answer if this is not the right place. In a book I am working on I am writing about how Java deals with memory allocation for the primitive types on a 64 bit CPU. I know the size of primitive variable types such as byte is 1, int is 4, etc. and that the size is related to the range of allowable values. From my C/C++ days I learned that the actual amount of RAM used was related to the word size of a CPU so that when a byte is read you are really reading a word. This meant to me that if I had 10 variables of type byte, not in an array, it would consume 80 bytes of RAM. From my reading it appears to be the same in Java except for arrays. Is this accurate? For example, an int is 4 bytes but when Java runs on a 64 bit CPU is it really reading and writing 8 bytes? If it is, can we say that the 4 bytes of padding is RAM dead space that cannot be used for anything else? Thank you for your time, Ken Fogel Amazon Web Services Development Center Germany GmbH Tamara-Danz-Str. 13 10243 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2730 bytes Desc: image001.gif URL: From alex.buckley at oracle.com Fri Aug 8 17:30:26 2025 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 8 Aug 2025 10:30:26 -0700 Subject: Memory Usage in Java In-Reply-To: <1705738028.9479753.1754671620447.JavaMail.zimbra@univ-eiffel.fr> References: <1705738028.9479753.1754671620447.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <1a84b2d5-74c2-4148-ba62-2bb7877ba0cf@oracle.com> On 8/8/2025 9:47 AM, Remi Forax wrote: > C (and Java) tricks you to think that a "short" has a single > representation but this is not true, > it has two representations, one on stack (local variables) and one on > heap (fields and array elements). ... > That's why in Java, the result of the addition of two shorts is an int, > ? short s = ... > ? short s2 = ... > ? s + s2. // this is an int The reason why the result of adding two shorts is an int is _because the JLS says so_. The physical representation of short values on the stack and on the heap -- whether in 1995 or 2025 -- is immaterial to the strongly typed result of a numeric operator. You could ask _why_ the JLS promotes each short to int before performing the addition, then adds two ints producing an int. The answer is that preferring to operate on 32-bit values made sense in 1995 and is still acceptable today. Alex From forax at univ-mlv.fr Fri Aug 8 18:09:21 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 8 Aug 2025 20:09:21 +0200 (CEST) Subject: Memory Usage in Java In-Reply-To: <1a84b2d5-74c2-4148-ba62-2bb7877ba0cf@oracle.com> References: <1705738028.9479753.1754671620447.JavaMail.zimbra@univ-eiffel.fr> <1a84b2d5-74c2-4148-ba62-2bb7877ba0cf@oracle.com> Message-ID: <1081057424.9506423.1754676561570.JavaMail.zimbra@univ-eiffel.fr> ----- Original Message ----- > From: "Alex Buckley" > To: "discuss" > Sent: Friday, August 8, 2025 7:30:26 PM > Subject: Re: Memory Usage in Java > On 8/8/2025 9:47 AM, Remi Forax wrote: >> C (and Java) tricks you to think that a "short" has a single >> representation but this is not true, >> it has two representations, one on stack (local variables) and one on >> heap (fields and array elements). > ... >> That's why in Java, the result of the addition of two shorts is an int, >> ? short s = ... >> ? short s2 = ... >> ? s + s2. // this is an int > > The reason why the result of adding two shorts is an int is _because the > JLS says so_. The physical representation of short values on the stack > and on the heap -- whether in 1995 or 2025 -- is immaterial to the > strongly typed result of a numeric operator. > > You could ask _why_ the JLS promotes each short to int before performing > the addition, then adds two ints producing an int. The answer is that > preferring to operate on 32-bit values made sense in 1995 and is still > acceptable today. But why it makes sense in 1995 (or today) to do that ? It makes sense because on the runtime side you have to do a conversion, if there is no integer promotion, the runtime has to convert the resulting 32bits integer back to a 16bits integer. So to nudge users on the right path, to make the performance model more explicit, the JLS explains to users how the sausages are made, i.e. that the runtime has to do an integer promotion when you want to do arithmetic operation of a 16bits value. > > Alex R?mi From kfogel at dawsoncollege.qc.ca Fri Aug 8 19:35:18 2025 From: kfogel at dawsoncollege.qc.ca (Kenneth Fogel) Date: Fri, 8 Aug 2025 19:35:18 +0000 Subject: Memory Usage in Java In-Reply-To: References: Message-ID: First, thank you to those who replied and to those who may still reply. Let me apologize for neglecting the last 25+ years of hardware design. >From what you have written or had on your blog, the issue of how much RAM a data type consumes, is not significant, at least to someone just starting their programming career. Back in my C/C++ days in the 1990s I worked on the assumption that for performance reasons your preferred data types were the word size of your CPU, like an int, because, and it could likely be because I misunderstood what was happening in the hardware, a program ran faster if you used, say, an int. I had not planned to get into these details on what I am working on but this morning I thought there might be some value to knowing precisely how primitive types consume memory. I think I will just stick with explaining what a stack and a heap are. I don't think someone learning Java, it is a textbook I am writing, would gain any insight into coding knowing how data is laid out in RAM. Correct me if I am wrong. Thanks again, Ken From: discuss > On Behalf Of Kenneth Fogel Sent: August 8, 2025 12:11 PM To: discuss at openjdk.org Subject: Memory Usage in Java Please let me know where I might ask this question or find the answer if this is not the right place. In a book I am working on I am writing about how Java deals with memory allocation for the primitive types on a 64 bit CPU. I know the size of primitive variable types such as byte is 1, int is 4, etc. and that the size is related to the range of allowable values. From my C/C++ days I learned that the actual amount of RAM used was related to the word size of a CPU so that when a byte is read you are really reading a word. This meant to me that if I had 10 variables of type byte, not in an array, it would consume 80 bytes of RAM. From my reading it appears to be the same in Java except for arrays. Is this accurate? For example, an int is 4 bytes but when Java runs on a 64 bit CPU is it really reading and writing 8 bytes? If it is, can we say that the 4 bytes of padding is RAM dead space that cannot be used for anything else? Thank you for your time, Ken Fogel From: discuss On Behalf Of Kenneth Fogel Sent: August 8, 2025 12:11 PM To: discuss at openjdk.org Subject: Memory Usage in Java Please let me know where I might ask this question or find the answer if this is not the right place. In a book I am working on I am writing about how Java deals with memory allocation for the primitive types on a 64 bit CPU. I know the size of primitive variable types such as byte is 1, int is 4, etc. and that the size is related to the range of allowable values. From my C/C++ days I learned that the actual amount of RAM used was related to the word size of a CPU so that when a byte is read you are really reading a word. This meant to me that if I had 10 variables of type byte, not in an array, it would consume 80 bytes of RAM. From my reading it appears to be the same in Java except for arrays. Is this accurate? For example, an int is 4 bytes but when Java runs on a 64 bit CPU is it really reading and writing 8 bytes? If it is, can we say that the 4 bytes of padding is RAM dead space that cannot be used for anything else? Thank you for your time, Ken Fogel -------------- next part -------------- An HTML attachment was scrubbed... URL: From fweimer at redhat.com Sat Aug 9 18:12:53 2025 From: fweimer at redhat.com (Florian Weimer) Date: Sat, 09 Aug 2025 20:12:53 +0200 Subject: Memory Usage in Java In-Reply-To: (John Dallman's message of "Fri, 8 Aug 2025 16:48:44 +0000") References:

Message-ID: * John Dallman: > On any remotely modern processor architecture, ten byte-sized > variables will only occupy ten bytes of space. The way they get > fetched into the processor is somewhat complicated but ensures that > several of them will normally be fetched in one read. That's not true for local variables, though. I don't know if Hotspot has a clear preference, but other compilers tend not to use byte-level access for local variables. The reasons vary. Register pair or multi-register stores and loads are usually not available at the byte level, and the instruction encoding for byte accesses might be less compact. Thanks, Florian From forax at univ-mlv.fr Sat Aug 9 18:49:52 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 9 Aug 2025 20:49:52 +0200 (CEST) Subject: Memory Usage in Java In-Reply-To: References:

Message-ID: <1207403958.10175716.1754765392739.JavaMail.zimbra@univ-eiffel.fr> ----- Original Message ----- > From: "Florian Weimer" > To: "Dallman, John" > Cc: "Shipilev, Aleksey" , "Kenneth Fogel" , "discuss" > > Sent: Saturday, August 9, 2025 8:12:53 PM > Subject: Re: Memory Usage in Java > * John Dallman: > >> On any remotely modern processor architecture, ten byte-sized >> variables will only occupy ten bytes of space. The way they get >> fetched into the processor is somewhat complicated but ensures that >> several of them will normally be fetched in one read. > > That's not true for local variables, though. I don't know if Hotspot > has a clear preference, but other compilers tend not to use byte-level > access for local variables. The reasons vary. Register pair or > multi-register stores and loads are usually not available at the byte > level, and the instruction encoding for byte accesses might be less > compact. Yes, Java is weird because you have this mixed execution, part of the code is executed by the interpreter, part of the code is JITed to assembly code. In the interpreter, the local variables are 32 bits values (or a pair of 32 bits values for long and double), this is how the bytecode works. In fact, it's even weirder because the bytecode has no concept of local variable declaration, a variable is "created" when the interpreter execute a store at an index (the size of all the local variables of a method is in the .class format). For the JITed code, local variables are not stored on the stack but inside CPU registers, apart if there are not enough registers but this is quite rare with usual 64 bits CPUs. So in both cases, local variable values are represented as 32/64 bits. > > Thanks, > Florian regards, R?mi From thomas.stuefe at gmail.com Mon Aug 11 05:25:59 2025 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 11 Aug 2025 07:25:59 +0200 Subject: Memory Usage in Java In-Reply-To: References: Message-ID: Adding to what Aleksey wrote... On Fri, Aug 8, 2025 at 6:10?PM Kenneth Fogel wrote: > Please let me know where I might ask this question or find the answer if > this is not the right place. > > > > In a book I am working on I am writing about how Java deals with memory > allocation for the primitive types on a 64 bit CPU. I know the size of > primitive variable types such as byte is 1, int is 4, etc. and that the > size is related to the range of allowable values. From my C/C++ days I > learned that the actual amount of RAM used was related to the word size of > a CPU so that when a byte is read you are really reading a word. This meant > to me that if I had 10 variables of type byte, not in an array, it would > consume 80 bytes of RAM. > This would not be the case on C/C++ either. Any allocator that uses 8 bytes for a single byte would be terrible. On C++, 10 stack variables of type byte, sitting right alongside each other, would still consume 10 bytes, unless you interleave them with other variables that come with different alignment requirements. If you place them on the heap with new or malloc as individual items, you would use more memory, but that overhead depends on the libc allocator implementation. Small allocations like this are typically placed into segregated-fits-lists, which may or may not impose an overhead depending on the train the allocation is placed into. But that has nothing to do with the width of the memory access of the CPU. Cheers, Thomas >From my reading it appears to be the same in Java except for arrays. Is > this accurate? For example, an int is 4 bytes but when Java runs on a 64 > bit CPU is it really reading and writing 8 bytes? If it is, can we say that > the 4 bytes of padding is RAM dead space that cannot be used for anything > else? > > > > Thank you for your time, > > > > Ken Fogel > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.firmstone at zeus.net.au Wed Aug 20 05:21:16 2025 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 20 Aug 2025 15:21:16 +1000 Subject: Usage of Virtual Threads and ScopedValue Message-ID: <22e7968e-e720-4bcf-957c-7094bb93fca3@zeus.net.au> Hello OpenJDK folk, Just thought I'd mention our use of Virtual Threads and replacing the usage of ThreadLocal with ScopedValue. I've been hacking a fork of OpenJDK on github, pfirmstone/jdk-with-authorization: JDK main-line development It uses a heavily modified Authorization implementation to lock down the vm and replace vintage SM implementation code that has either been removed or is scheduled for future removal, it also supports permission checks on virtual threads.? ?The implementation focuses on scalability with immutability with non blocking weak caches.? ?AccessControlContext uses a factory cache to minimise the number of immutable AccessControlContext instances, for example, many virtual threads will share context. The cache implementation is injected to avoid dependencies during jvm bootstrap. Virtual threads are used in the SM implementation to execute permission checks in parallel, and avoid blocking native threads, such as SocketPermission etc. jdk-with-authorization/src/java.base/share/classes/au/zeus/jdk/authorization/sm/CombinerSecurityManager.java at trunk ? pfirmstone/jdk-with-authorization Basically ScopedValue is used to detect and limit recursion, which can occur when a permission check requires other permission checks to complete.? ?The implementation is relatively basic, but it works well, eg, for more info see the link above. @Override ? ? public void checkPermission(Permission perm) throws SecurityException { ? ? ? ? Integer call = TRUSTED_RECURSIVE_CALL.isBound() ? TRUSTED_RECURSIVE_CALL.get() : null; ? ? ? ? if (call != null && call > 7) { ? ? ? ? ? ? /* This is a recursive permission check, there's a permission on ? ? ? ? ? ? ?* the stack that requires privilege to determine whether it is implied. ? ? ? ? ? ? ?* We can't continue indefinitely, as it will cause a stack overflow, ? ? ? ? ? ? ?* however we can allow a limited number of nested permission checks, ? ? ? ? ? ? ?* the same permission check may be repeated numerous times, in recursion. ? ? ? ? ? ? ?*/ ? ? ? ? ? ? throw new AccessControlException("Too many recursive permission checks", perm); ? ? ? ? } ? ? ? ? Object context = getSecurityContext(); ? ? ? ? checkPermission(perm, context); ? ? } For the curious, the trusted platform has been reduced to only the java.base module, furthermore modifications have been made to limit trust of certain classes within the trusted platform domain, to allow JAAS Subject policy based authorization to take priority. There's a tool to generate policy files at deployment, only the permissions needed to perform required functionality and execution paths are generated.? ?Additional execution paths that are not exercised that require privileges will not have permission to execute. Static permissions, such as URLPermission granted by URLClassLoader have been removed, to prevent URL injection attacks and allow policy to determine allowed URL's. There are additional permission's such as LoadClassPermission, NativeAccessPermission, SerialObjectPermission and additional ManagementPermission checks in native code. No effort will be made to sandbox untrusted code, instead the focus is on preventing the VM from executing untrusted code by requiring authentication and authorization. StackWalker with ScopedValue was tested to replace the native stack walk, however this lead to difficulties in early loading of java class dependencies and memory stability issues.? ?The native stack walk itself is a relatively small section of code and has been retained, as have permission check hooks. AccessControlContext's implementation has been simplified and made immutable for virtual thread support. Permission implementations are no longer Serializable, some minor breaking changes have been made that OpenJDK dev's wouldn't have been permitted to make.? Needless to say the implementation is modern and easier to maintain. My reason for hacking OpenJDK: pfirmstone/JGDMS: Infrastructure for providing secured micro services, that are dynamically discoverable and searchable over ipv6 networks -- Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.bateman at oracle.com Wed Aug 20 10:30:24 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Wed, 20 Aug 2025 11:30:24 +0100 Subject: Usage of Virtual Threads and ScopedValue In-Reply-To: <22e7968e-e720-4bcf-957c-7094bb93fca3@zeus.net.au> References: <22e7968e-e720-4bcf-957c-7094bb93fca3@zeus.net.au> Message-ID: On 20/08/2025 06:21, Peter Firmstone wrote: > : > > It uses a heavily modified Authorization implementation ... > > Basically ScopedValue is used to detect and limit recursion, which can > occur when a permission check requires other permission checks to > complete.? ?The implementation is relatively basic, but it works well, > eg, for more info see the link above. > > ScopedValue is a good choice for authorization as the current "security context" or "identity" is an implicit method parameter. In the JDK, the Subject API was recently re-implemented to use a scoped value. Detecting reentrancy, or limiting recursion in your example, is another good usage. In the JDK there are several cases, provider lookup/discovery in particular, where reentrancy needs to be detected. One of these (Charset) was recently changed to detect reentrancy based on whether a ScopedValue a bound or not. Experience using ScopedValue is always useful. If you have feedback or experience to report then bringing it to the loom-dev list would be best. -Alan